Add setting "eslint.globalSeverity", Implements #468

Add an eslint.globalSeverity setting. Addresses my feature request #468.
Just FYI, I added es7 to compilerOptions.lib in server/tsconfig.json to support the .includes() method I utilized on line 229 of eslintServer.ts

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: ashrafhadden sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

@ashrafhadden thanks for the PR. Looking through it I am wondering if the ESLint extension is the right place to do this. Wouldn't it make a lot more sense to have this in eslint itself? The problem will be that as soon as one of the ESLint tasks are run which spawn a separate eslint command line all these will be reported as errors again.
So far I was very relucent to add features to the ESLint extension that deviates the behavior from what you are seeing when running eslint in a terminal.

@dbaeumer All good points! I figured I'd at least submit the PR since I had already hacked it on my local ESLint extension. Also this was my 1st PR ever so I did it for the experience as well. Thanks for looking over it at least! This was less intimidating for me to approach than the ESLint codebase, I think it's a lot bigger, but I'll definitely look into it! Thanks again for reviewing it! 🙏

@ashrafhadden any objections to close the PR give my comments https://github.com/Microsoft/vscode-eslint/pull/561#issuecomment-432967284

@dbaeumer Nope, go ahead close! Thx!

I'd really like to see this feature. I'm trying to move from TSLint given its deprecation, and I'm missing the alwaysShowRuleFailuresAsWarnings option. I liked having my TypeScript errors indicated with red squiggles and my lint errors indicated with green/yellow. It's all about the visual indicator. The rule could still even call out it's an error on hover, if desired.
I found some rationale relating to this feature being added to TSLint: https://github.com/microsoft/vscode-tslint/issues/199#issuecomment-299246484

My objection is that you can also have a task that runs eslint over all files and in this case everything would be reported as an error again. Does anyone know how this got solved in TSLint?

@dbaeumer that concern is unrelated, no? This extension just shows a GUI on top of ESLint complaints. If a user runs a task that reports lint complaints, it's up to that task how it would want to report errors.

how this got solved in TSLint

https://marketplace.visualstudio.com/items?itemName=ms-vscode.vscode-typescript-tslint-plugin
A config flag in ms-vscode.vscode-typescript-tslint-plugin: ``tslint.alwaysShowRuleFailuresAsWarnings`. "Always show rule failures as warnings, ignoring the severity configuration in the tslint.json configuration."
...so roughly what this rule option does, just TSLint is slightly less configurable.

@dbaeumer Maybe the naming of the setting is confusing?
The root issue as far as I understand (and also have) is that ESLint errors become indistinguishable from hard JS/TS syntax errors while working on a file - it's not about overriding the ESLint severity, but rather to tweak the mapping of an ESLint error levels to a visual VS Code diagnostic severity.
Different name and default values would be:
eslint.diagnosticSeverities.warn: "Warning"
eslint.diagnosticSeverities.error: "Error"

I personally would tweak on my machine to be this:
eslint.diagnosticSeverities.warn: "Warning"
eslint.diagnosticSeverities.error: "Warning"

The TSLint config setting name also hints at this being purely visual:

alwaysShowRuleFailuresAsWarnings (vs. for example: alwaysTreatRuleFailuresAsWarnings)

I would like to rewrite the PR taking into account all the feedback. I especially like @sirlantis's recommendation of mapping ESLint severity to VSCode's problem severity. It seems the most intuitive. Also the most flexible since it unlocks the ability to use VSCode's specific Hint and Information types. What does everyone think of this? @dbaeumer @JoshuaKGoldberg @justinbayctxs
ESLint's severity is the key, VSCode's diagnosticSeverity is the value.
Possible Keys: 0, 1, 2, "off", "warn", "error"
Possible Values:  "Hint", "Information", "Warning", "Error" (case-insensitive)
// settings.json
// ...

  "eslint.severityMap": {
    "0": "hint",
    "1": "information",
    "2": "warning",
  },
  "eslint.severityMap.exclude": ["semi", "no-console", "no-debugger"],

// ...

Other options for names could be...
eslint.problemSeverityMap
eslint.visualSeverityMap
This implementation would make eslint.alwaysShowRuleFailuresAsWarnings unnecessary although I could still include it as an extra option that overrides all others. Personally I don't like the naming. failure appears nowhere in ESLint's or VSCode's documentation AFAIK, it really means alwaysShowRuleErrorsAsWarnings. I'd rather submit a similar to PR to TSLint and see if they would be up for integrating this more flexible implementation.
I am using the problemSeverity term over diagnosticSeverity because the latter seems only to be used internally, so I think only extension authors would be familiar with it.

I like @sirlantis's idea. Good combo of clear, intuitive and flexible. I will include a link to the DiagnosticSeverity documentation in the hover tooltip. Thoughts? @dbaeumer @JoshuaKGoldberg @justinbayctxs
Possible Values:  "hint", "information", "warning", "error" (case-insensitive, to match documentation)
  "eslint.diagnosticSeverity": {
	  "off": "hint",
	  "warn": "information",
	  "error": "warning"
  },
  // exceptions to the above setting
  "eslint.diagnosticSeverity.exclude": ["semi", "no-console", "no-debugger"],

I try to explain myself again since I think I was not clear: VS Code has the ability to run tasks, scan the output and turn them into problems. If you have such a task there is no way to intercept the severity and to map it to different values. So in such cases problems might swap between error and warning (in the editor and the problems view) depending on whether the problem came from the task or from the ESLint plugin itself. This is why I stayed away from this so far.

@dbaeumer Unless I'm misunderstanding, I don't this as an issue since the setting is only meant to target ESLint's problems, thus "eslint.diagnosticSeverity", not VSCode's or any other source. Although this does give me the idea that perhaps it may be possible to create a setting or extension that can globally control severity mappings in VSCode.

@ashrafhadden the task contributed by the ESLint extension to lint all files in a workspave also creates problems owned by eslint. So there is a case where the task generates error problems which the ESlint reconciler generates as warning.

@dbaeumer Ah okay, I understand now I just never used the ESLint task. Is there no way to modify/intercept the task problems from within this repo (vscode-eslint)?

The only way to intercept them is by generating them in the plugin itself using the new CustomTask API in VS Code.

We're also very keen to see something like this implemented.
We have also migrated from TSLint and getting red lines due to the formatting settings in your eslint config is very distracting.

+1, this would be super valuable. ESLint in vscode is a very common use case and it's super distracting to see linting problems formatted as code errors.

So this PR has gone stale. :(
I really, really wish to visually distinguish typing errors from code style errors.

@dbaeumer can anything be done to move this forward? This has been an issue since 2018, and a major usability issue for those using eslint in vscode.

My objections have not changed. One solution I could think of to allow the task and in file validation to use a different eslint configuration file. Then configuring this is something that happens on the ESLint level and can also create the same results when run in the terminal.

This is where the TSLint Language Service Plugin makes use of the configuration option alwaysShowRuleFailuresAsWarnings: https://github.com/microsoft/typescript-tslint-plugin/blob/1c0f74a52dbc38823d14c3a5c1b819a33015a2a9/src/plugin.ts#L386-L388
I don't have full understanding of how VSCode plugins work, but is there something different about ESLint that we can't follow the same pattern here?

This is not about technical difficulties, this is about having the same feature set in the extension and the terminal. This is why I would like to have a solution that uses ESLint mechanisms since then the same output can be generated in the terminal and hence when used as a task insider VS Code.
Does anyone know if a ESLint plugin exists that changes the severity of all problems?

What I'm looking for (and I think anyone else who's used the alwaysShowRuleFailuresAsWarnings setting for tslint) is not to mess with the terminal output, but only to stop seeing red squiggly lines within the code editor for code style issues. That way, we can distinguish them from actual TypeScript errors that will fail to compile our code.
I agree that what this PR introduced was beyond the scope of this plugin. I think it tried to introduce a level of control that ESLint itself doesn't provide.
But, I think showing rule failures as warnings within the editor is a sensible option that could belong to the plugin itself. Any extra configuration options could be argued as meddling with ESLint configuration itself.
I'm sorry if I'm still missing the point of your objection @dbaeumer.

I'm with @Merott here. My stand on this matter seems to be aligned with theirs:
My goal is to be able to  visually distinguish between:

errors that (potentially) break code execution
violations of the code style guide that do not affect code execution in any way (and are likely to be fixed automatically with eslint --fix, e. g. on saving or in a pre-commit hook!)

My (incompetent) guess is that the easiest way to achieve this would be to have an option in the VS Code's ESLint extension that forces it to treat any errors reported by ESLint as warnings. A single checkbox that causes a simple override.
I believe, this feature request has nothing to do with the terminal output. I fail to imagine a use case where I would need to reduce ESLint errors to warnings in the terminal.

VS Code has support to parse the output of tasks run in the terminal and generate errors from it. If you run such a task in which the terminal shows an ESLint problem as an error the editor will render the problem as an error and not as a warning (since the error is not going through the eslint extension code). Hence we are back to were we are right now.
This is why I think the best would be to have two .eslintrc config files were one depends on the other and the second one simple configures everything as a warning. Then you could even use that one when running a task in the terminal.
I for example usually do that with my TS compiler errors were I have relaxed rules when developing but tighter rules when compiling for production. But I didn't ask to have a special setting for that in the tool. I simply maintain two tsconfig.json files.

@dbaeumer I just checked, and the TSLint extension doesn't do anything about the output of the tasks. That doesn't bother me more than seeing lint errors mixed up with TS compile errors, but I see your point, and not sure I can argue against it.
Since we don't have a better solution yet, I've decided to just hack the extension for my own use. If anyone's interested, here it is: https://github.com/Merott/vscode-eslint/commit/e12486512c86d90c32f828bcf9721d9edb7c11b6

@Merott Thank you! 🙏 🙇♂
If you add a checkbox to extension settings, you could file your own PR...

@lolmaus you're welcome.

If you add a checkbox to extension settings, you could file your own PR...

@dbaeumer doesn't agree with this option being part of the extension, and a PR won't do any good until we have a solution we can all agree with.
Until then, I guess I'll just run my sed command every time the extension updates! 😅

So:

There's a problem that many VS Code users face.
There's a simple solution that efficiently fixes the problem.
It is rejected because this solution is not solving another problem (with the terminal) that nobody is actually facing.

Is this how it goes?

This is why I think the best would be to have two .eslintrc config files were one depends on the other and the second one simple configures everything as a warning. Then you could even use that one when running a task in the terminal.

Creating a separate eslint config in every project I'm opening, then configuring each project's workspace to use that config — is a ridiculous amount of effort.
It gets even worse when VCS is concerned. That config file has nothing to do with the codebase, so it has to be gitignored, which means that I need to commit a gitignore entry to every project I'm opening, which in turn means I have to rationalize the necessity of it to every project's maintainer.
And if I don't gitignore it, I'm prone to accidentally commiting the config itself.
You can't reasonably expect people to be doing all that.
All we want is for ESLint squiggles to be yellow! Can we please have a checkbox that does it?

No this is not the case. The problem is that adding this will result in more requests having a more fine grained configuration. I used the terminal as an example to explain this. Take TypeScript ESlint as an example: there are quite some rules in TS ESLint for which even if I type I want to see them as an error and others (for example auto fixable rules) I want to see as a warning. So the next feature request will be that I have to support this as well (e.g. make everything a warning except these five rules, ....). This is what I want to avoid. So IMO the best solution would be if this can be implemented using normal eslint configuration / eslint plugin. Then the full power of ESLint configuration rules can be used to allow customization.

@dbaeumer I see your point, but I explained why manipulating ESLint configs is troublesome.
This could be fine if you're working on a single project, and either you're the owner or the owner also happens to use VS Code (or at least is sympathetic to minor issues like this) and would accept a PR irrelevant to the project).
But there are lots of people who work on lots of projects every day. E. g. I've checked out a new codebase from GitHub just an hour ago. And I want ESLint squiggles to be yellow in it too, without me spending 20 minutes on wiring it together.
I want a global setting.

So the next feature request will be that I have to support this as well (e.g. make everything a warning except these five rules, ....)

Please don't take it as sarcasm, but that's a very reasonable thing to do! I honestly believe that it would be awesome to have exceptions from this global rule.

I agree with the majority here. While ESLint rules can be categorised into 'warning' and 'error', the vast majority of configurations I've seen use just 'error' almost exclusively. This also isn't something I necessarily have control over - whether it be through off-the-shelf configs such as Standard, or an existing mature project. Like others I also don't  want to worry about fighting with my tooling when switching projects.

VS Code has support to parse the output of tasks run in the terminal and generate errors from it.

Aah good spot, I didn't know that was even a feature! I can't say I really see the point of it though. Why wouldn't I have an interactive report for open files contributed by an extension in such a case, especially a tool like a linter?

So the next feature request will be that I have to support this as well (e.g. make everything a warning except these five rules, ....)

Added maintenance burden isn't great no, but don't a lot of VS Code's features respect the spirit of customisation? I see few extra useful customisation options this extension could have above that. The effective rules are defined by the project configuration, how I want to see the linter within my IDE should be up to me, within reason... Of course a line will have to be drawn somewhere subject to code complexity and technical restraints.

@dbaeumer I kindly ask you to reconsider please. I propose we add a checkbox to override ESLint diagnostics to be seen as warnings as found in TSlint and #978 (which is based on https://github.com/standard/vscode-standardjs/pull/108):

Based on the comments on this pull and linked issue, there is definitely community interest in having such an option.
We can document a known limitation or caveat around parsed errors from task output. I think the number of people utilising that functionality and being caught out by this proposed option would be very minimal. I imagine a quick sentence in the setting description would suffice.
As TSLint's downfall is coming, many users will eventually be migrating to this extension over time. We should try and match the featureset available in TSLint - which as far as I can tell is just this option really. With regard to future asks we could assess that another time? I believe the focus and justification should be on feature parity for an incoming wide userbase. XKCD 1172 springs to mind!
Comparing other extensions, the most popular one for JetBrains' IDEs also has such an option. The SublimeLinter has a much more complex configuration (which I guess is ultimately what you're trying to avoid, and I agree!) but may be able to achieve a similar result. Others I looked at provided relatively few options but I admit not looking in great detail.

I guess the ultimate solution would be for ESLint to have a native CLI option for this (and we tweak args in the extension) so it can work equally in all IDEs, or VS Code to have customisable Diagnostic types and colours. Both of these seem really far fetched; the user request here could be summed up to "make all linting yellow, red mean code broke". Can we not cave to that, even if it feels a bit irrational? I haven't seen anybody other than yourself opposing in this thread. (and I don't mean to highlight that in a disrespectful way)
Thank you. 🙂

@jamesorlakin thanks for your thoughtful and considerate reply. It is not that I don't understand your desire to have that feature. But as you pointed out as well it is about maintaining a feature that has several problems and if added will cause more work in the long term:

no consistent implementation inside VS Code (editor, terminal).
does conceptually belong into the ESLint CLI / API. Have any of you every filed a issue against ESLint asking for this?
only a small minority of vscode eslint users have ask for this so far. The feature request has 15 votes. I am not trying to say that all the other users of the extension are against it but it doesn't seem important for them. They happily work without having this feature.

And I personally don't understand the use case.  I personally have the extension globally turned off and selectively turn it on in projects I actively work on and care about the warnings and errors. Can someone please explain why this is not a possible solution?
What I am willing to do is the following: merge a PR that adds one setting to globally overwrite the severity. I would also like to see:

that someone that cares about this opens an issue against ESLint asking for the feature there as well.
signs up maintaining the feature. If there are requests for a more fine grained configuration or bugs I will assign the issues to that person :-)

And I personally don't understand the use case.

There are two main factors:

The use case is to be able to visually distinguish errors that cause code to fail from formatting nit-picking, most of which is likely to be auto-fixed with eslint --fix.

During development, I don't care about linting errors. I only need to fix them before committing.
But at the same time, I still want to see them in the editor — in case I'm in the mood of fixing them right away, rather then revisiting the file later.

I want this to be consistent across all projects, as a default, without a need to set up a separate ESLint config file in every file.

only a small minority of vscode eslint users have ask for this so far.

This is only a problem for TypeScript users, because they're the ones who need to be able to distinguish typing errors from code style warnings. This is not like turning ESLint off. You don't ignore all of them, you just make them show up as warnings so you know that your code is still valid TypeScript, and will compile once you save the file. You can continue to test out your changes without worrying about those warnings, until the point you decide to commit and push your changes.
There are a lot of TSLint users who haven't yet migrated to ESLint. I have TypeScript projects right now that are still using TSLint, and I know they'd be a nightmare if we had to switch them to ESLint right now, because of this issue.

I personally have the extension globally turned off and selectively turn it on in projects I actively work on and care about the warnings and errors. Can someone please explain why this is not a possible solution?

I'm not sure why this needs explanation. If a project has ESLint configured, then turning off the ESLint extension doesn't make them go away. We still have to deal with them, and it's a lot easier to deal with them with the extension turned on. Why would you turn off the extension in a project that has ESLint configured?

Thanks @dbaeumer. I had a look at the ESLint repo and there have been a couple of relevant issues about this:
https://github.com/eslint/eslint/issues/10346 - A similar request as here by the same author. VS Code warnings and errors have a different meaning to ESLint ones. It was decided that this isn't ESLint's responsibility as it's just reporting factually based on the configured ruleset. The takeaway was it's up to the IDE extension to interpret this and display it to the user as they wish.
I understand and agree with your points about the ESLint extension essentially lying to the user about results at that point if we were to implement this but, rather irrationally, I'm just a fan of yellow! When looking at the JetBrains plugins it seems the JetBrains IDEs have very granular options for severity. It's the limitation of VS Code's diagnostic display that sends us down the easier 'always make it a warning route' in order to differentiate language server problems.
One possible future proposal could be for VS Code to have configurable severity/colours for diagnostcs based on the contributing extension. However, this would really be out of my comfort zone! The recent rollout of semantic hightlighting at least indicates the colouring of items does matter in themes - maybe they would open to extension of diagnostic colours too?
Something like:
"workbench.colorCustomizations": {
    "[Monokai]": {
        "extensionOverrides": {
          "dbaeumer.vscode-eslint": {
            "diagnostic.error": "#FFC0CB",
            "diagnostic.warning": "#FFFF00"
          }
        },
        "sideBar.background": "#347890"
    }
}

I don't see this being an easy feat but this ideally would ensure the ESLint output matches what's seen in the problems panel in VS Code whilst still visually providing a difference for us yellow-fanatics.

this isn't ESLint's responsibility as it's just reporting factually based on the configured ruleset.

it's up to the IDE extension to interpret this and display it to the user as they wish.

👆 Exactly!

agree with your points about the ESLint extension essentially lying to the user about results at that point if we were to implement this

I don't agree. As you have said above, ESLint is simply reporting the facts.
I think, the matter will become easier to reason about if we make the following distinction:
There are two separate cases for ESLint:
— CI is responsible for not letting any formatting errors to be merged into main branches. Any linting issue is an error for CI.
— During development, syntax and typing errors are much more important for the developer because they require immediate attention, whereas formatting/styling issues can be dealt with later.
ESLint does not and should not be aware of visual preferences of the user. That's the concern of the IDE.

I'm now using @Merott's fork, and it makes development so much more ergonomic. E. g. without the proposed feature, I can't tell if this squiggle means my code is broken or simply unformatted:

With the proposed feature enabled, it's clear there's a logical error. When I fix the error, it looks like this:

It's now immediately visible that this error is minor, I can ignore it and switch to the browser and see the result, the app will not crash. The pre-commit hook will remove the lint automatically.
And I didn't need to create the second ESLint config file, negotiate with my teamlead for it to be committed, or apply --assume-unchanged to it and then risk it being committed by accident.

For anyone using a Mac and looking for a temporary patch, here it is:
cd ~/.vscode/extensions/dbaeumer.vscode-eslint-{VERSION}/server/out

sed -i -e 's/switch(e){case 1:return i.DiagnosticSeverity.Warning;/return i.DiagnosticSeverity.Warning;switch(e){case 1:return i.DiagnosticSeverity.Warning;/g' ./eslintServer.js

If you're not on a Mac, I'm sure you can figure out how to adjust the above for your own system.

Just for the record: I am only coding TypeScript and lint exclusively with this extension.
If I summaries the discussion: it is not about turning ESLint off for a project you open to read some code and you are not interested in any off the linting errors.
You basically want to define two different configurations. One for CLI and one for the IDE.
I can understand this since I do the same for the TS compiler. But I decided that I use two configuration sets for this to make it more clear and not IDE dependent (see tsconfig.json & tsconfig-watch.json in this repository: https://github.com/microsoft/vscode-languageserver-node.git).
Given my experience with this I highly doubt that having one switch that makes everything yellow will satisfy the needs especially in TypeScript where ESLint can validate based on symbol information as well. I think devs will immediately ask for a more fine grained configuration. I for example use the rule of no dangling Promises and this one is something devs might want to always see as an error and not as a warning even in the IDE.
I also understand that maintaining two files (like I do for TypeScript compiler) is a pain and I already thought about writing me a tool that generates the one from the other.
But I don't want to make this a VS Code settings problem either since the extension will end up supporting all ESLint config features in VS Code settings.
So here is another idea: since the extension uses the Node API (does not call the CLI) we could do the following:

first call calculateConfigForFile
then read a second (dev config file) that redefines some rules. We can use the same calculateConfigForFile method.
merge the two files
call the linter with the configuration.

So I slightly rephrase my offer from the last post:
What I am willing to do is the following: merge a PR that adds one setting to globally overwrite the severity. I would also like to see someone signing up maintaining the feature. Specially about requests for a more fine grained configuration. Anyone out there?

I also understand that maintaining two files (like I do for TypeScript compiler) is a pain and I already thought about writing me a tool that generates the one from the other.

That's like offering a painkiller instead of removing the source of pain. :(

devs will immediately ask for a more fine grained configuration

But I don't want to make this a VS Code settings problem either since the extension will end up supporting all ESLint config features in VS Code settings.

How bad can it really get?
I can imagine the following option:

Treat ESLint errors as warnings
🔘 Never
🔘 Only for the following properties:
⚫ For all properties except:
typescript-eslint/no-floating-promises

That would be extremely convenient.
A quick, efficient, frustration-free configuration without having to figure out how to generate the second config file.
As an IDE user working with many codebases, I don't want to even bother making a decision of where to store those generated configs. I just want ESLint squiggles to be yellow, why does it have to be that hard for end users? 😕

What I am willing to do is the following: merge a PR that adds one setting to globally overwrite the severity. I would also like to see someone signing up maintaining the feature. Specially about requests for a more fine grained configuration. Anyone out there?

Looks like @ashrafhadden's PR (this PR) already covers most of what I imagined above.
@dbaeumer Do you agree with this approach (apart from dependencies being checked in by accident)?

I will try to restate what I would like to see happening since I think I didn't express myself correctly

a PR that I can merge that only adds an option to control the severity off all generated ESLint problems.
a name or a group of names that is willing to work on another PR that adds a more configurable solution (regardless how it will look like) and that is willing to maintain it.

Here is a starting point with no conflicts: https://github.com/microsoft/vscode-eslint/tree/dbaeumer/468
Setting name is eslint.rules.customizations (inspired by @jamesorlakin) which currently only allows a value:
{
    "!": "info" | "warn" | "error"
}

Setting already travels to the server (https://github.com/microsoft/vscode-eslint/blob/dbaeumer/468/server/src/eslintServer.ts#L209). Anyone willing to continue on this?

I've opened a PR based on what I think the agreed solution is. It seems fairly simple in retrospect, I'm just trying to think of what a more configurable solution would look like or achieve?

@jamesorlakin thanks. Will have a look the next couple of days.

https://github.com/microsoft/vscode-eslint/pull/1164 got merged so I will close this one


Hook for modifying config files after prepare (AndroidManifest.xml, Plist, etc.)

I love what you guys did regarding the hook for icons/splashscreens.  One thing that is pretty common is the need to modify the android maneifest, IOS PList (may be more but these are all I can think of at this moment).  I understand that it's best practice to NOT version control the platform folder.
It would be great if there was a hook that on after prepare, either merged, or copied these files or contents.  Any thoughts on this?
Thanks,
Devin

Ok disregard the above meesage, I ended up going a different route and using the same logic as the plugin.xml uses for modifying the AndroidManifest and *-Info.plist files, which uses config-file elements. These config-file elements along with a few extra custom preferences, can be added to the config.xml and the hook will update the specified target file.
Documentation on how this works can be found in the hook in my forked repo at https://github.com/djett41/generator-ionic/blob/master/templates/hooks/after_prepare/update_platform_config.js
Pull request to follow.


What are some possible reasons behind 'Warning: Unknown prop rowKey on  tag.'

Here is the stack trace:
in tr (created by BodyRow)
    in BodyRow (created by Body)
    in tbody (created by Body)
    in Body (created by PaginatingTable)
    in table (created by Provider)
    in Provider (created by PaginatingTable)
    in div (created by PaginatingTable)
    in PaginatingTable (created by Connect(PaginatingTable))
    in Connect(PaginatingTable) (created by PartnersList)
    in div (created by PartnersList)
    in div (created by PartnersList)
    in PartnersList (created by Connect(PartnersList))
    in Connect(PartnersList) (created by Schedules)
    in div (created by Schedules)
    in section (created by Schedules)
    in Schedules (created by BusinessAdmin)
    in BusinessAdmin (created by RouterContext)
    in div (created by App)
    in div (created by StyleRoot)
    in StyleRoot (created by App)
    in App (created by Connect(App))
    in Connect(App) (created by RouterContext)
    in RouterContext (created by Router)
    in ScrollBehaviorContext (created by Router)
    in Router
    in RadiumWrapper
    in AltContainer

Some background information: I'm attempting to upgrade to React 15 from 14. I was using Reactabular-table 8.6 when I saw the warning initially. I then updated to the most recent version 8.12.0 to see if the warning disappears and it did not get rid of it. What can I do to do away with this warning?
I'm a bit of a newbie, so let me know if I haven't provided enough info!

Could you set up an example I can run? The warning says rowKey is leaking to tr for some reason but I would have to see your code to tell why.

@bebraw you were right. After some investigation I noticed we were passing this function:
  _onRow = (row, { rowIndex }) => {
    return {
      className: rowIndex % 2 ? 'row-even' : 'row-odd',
      rowKey: row.id,
    };
  }

to Table.Body context:
          <Table.Body
            rows={ rows }
            rowKey={ rowKey }
            onRow={ onRowHandler }
          />

By removing the rowKey attribute, we got rid of the warning. Thank you for your help!


[A11y] 1.4.10 Reflow – Two Dimensional Scrolling is Present

[Raised for reference, likely to be resolved on completion of development]
Tester has observed that when viewing the page at 1280px width and 400% zoom, two dimensional scrolling is required to view content. It is expected that at zoom up to 400%, no parts of the content should require two dimensional scrolling except for parts of content where two dimensional scrolling is required for usage or meaning.
On the 'Coronavirus (COVID-19) cases in the UK' main page the 'In Development' text causes horizontal scrolling
This does not comply with WCAG Level AA 2.1:
1.4.10 Reflow - https://www.w3.org/WAI/WCAG21/Understanding/reflow.html
Steps to Recreate:

Navigate to URL at 400% zoom 1280px wide viewport
Review content on site
Observe issue

This has been observed on the following pages:
Coronavirus (COVID-19) cases in the UK
Environment:
Windows 10 – Chrome 80
This issue is known to occur on:
Believed to be global
Reproduction rate:
100% - Consistently reproducible. Occurs every time that it is attempted.
Supporting material:
Screenshot/Video
Version:
https://coronavirus.data.gov.uk/
3.Minor Impact on Functionality


Import Export Actions

I can see that I can no longer select the fields to export after the last update so is this a bug or how can I export based on the selected records as ExportActionModelAdmin no longer exists?

okay it works when I use search of filter which is needed, thanks for you efforts I love your package saved a lot of time for me <3


Stronghold path included in .cfg file?

My idea is to separate the selection and options to two different files.
The path should not be in the selection file because it can have some trouble with users who want install the patch from other users.
For edge case of multi Paths and Configs i have the idea to use Start arguments as follow:
Config="arrayofconfigs" example: Config="test1.cfg,test2.cfg,test3.cfg,test4.cfg,test5.cfg,etc"
Path="PathToStronghold"
On start show a Dialog for selection of .cfg file
If we add Displaying the .cfg file name in title we can also dismiss the Selection Dialog and just use the W/S keys to loop trough the .cfg files forwards and backwards.
Also if we show the Path somehow(maybe only if applied it will added to the Titlebar or somewhere else) we can make it as a array(Path="PathToStronghold,OtherPath,etc") and loop with 2 keys trough it. Keys only enabled if a start argument got applied. Maybe add the keys to use as start argument to change them to whatever the user likes. :)

For using multiple configs, I think it might be worth to consider adding a /config/ subfolder in the ucp directory that will automatically be searched for cfg files, instead of putting a list with all config filepath strings into some commandline argument. (Independent of that, for the ucp cli would get an argument specifying the one config file that should be applied, ofc.)
Also, right now that I think of it, I'm not sure at what point in time the used config file is actually written to currently... every time some checkbox is clicked inside the ucp gui, or only when exiting the ucp gui, or...?
Because I'm thinking if the ucp supports multiple configs, and the ucp gui allows editing config files (making it, among other things, a config editor as a matter of fact), then having some save / save as, apply / revert functionality might be nice.
Anyway, one issue I see with having paths be independent of cfg files entirely and in all cases is that the mapping config <-> installation path is then a manual process that has to be re-executed manually every single time, which seems tedious / error-prone, and thus a quality of life detriment compared to the current status quo.
Nonetheless, I certainly agree a split between ucp "game settings config" (or "config" for short) and "ucp gui settings config" (or "options" for short) generally makes sense for several reasons. Having path be dependent on config in all cases does have issues as well - particularly when sharing a config with other users that may have a different setup for their install paths, causing obvious (installation not found) or unnoticed (wrong installation picked) errors.
Thus I would favour, a system that allows both, config with and without install path in some understandable, comfortable and hopefully fail-save way, if possible.

Use cases to consider for any implementation (I hope I thought of everything relevant here, but feel free to correct me and suggest more):

I want to use/switch a config file created by someone else (to play multiplayer with others, or to play singleplayer with aiv/aic sets created by someone else that go with the config). Note: I want this to be particularly easy and intuitive, as I may not be willing or able to deal with complicated, lengthy or error-prone procedures for this (especially for jumping into multiplayer matches).

I want to create an own config file to use or test a set of changes (to develop an own aic, customize aivs or adjust other settings for singleplayer to my personal taste). I may want to share that config with others later.

I want to use multiple configurations of the ucp in parallel on different SHC installations on my computer.

I want to reference resource assets (e.g. aivs, aics, maps?) in several config files (without having to duplicate them to the location of every config file referencing them).

I want to keep track of which configs are currently used on what SHC installations. (Ideally, I also have some indication of what version of a config file is installed / if that file has changed since last installing it, but that may be difficult and low priority?)

I want to have all of the aforementioned stuff (if applicable) usable for both ucp gui and ucp cli.

For using multiple configs, I think it might be worth to consider adding a /config/ subfolder in the ucp directory that will automatically be searched for cfg files, instead of putting a list with all config filepath strings into some commandline argument. (Independent of that, for the ucp cli would get an argument specifying the one config file that should be applied, ofc.)
Also, right now that I think of it, I'm not sure at what point in time the used config file is actually written to currently... every time some checkbox is clicked inside the ucp gui, or only when exiting the ucp gui, or...?
Because I'm thinking if the ucp supports multiple configs, and the ucp gui allows editing config files (making it, among other things, a config editor as a matter of fact), then having some save / save as, apply / revert functionality might be nice.
Anyway, one issue I see with having paths be independent of cfg files entirely and in all cases is that the mapping config <-> installation path is then a manual process that has to be re-executed manually every single time, which seems tedious / error-prone, and thus a quality of life detriment compared to the current status quo.
Nonetheless, I certainly agree a split between ucp "game settings config" (or "config" for short) and "ucp gui settings config" (or "options" for short) generally makes sense for several reasons. Having path be dependent on config in all cases does have issues as well - particularly when sharing a config with other users that may have a different setup for their install paths, causing obvious (installation not found) or unnoticed (wrong installation picked) errors.
Thus I would favour, a system that allows both, config with and without install path in some understandable, comfortable and hopefully fail-save way, if possible.
Use cases to consider for any implementation (I hope I thought of everything relevant here, but feel free to correct me and suggest more):
1. I want to use/switch a config file created by someone else (to play multiplayer with others, or to play singleplayer with aiv/aic sets created by someone else that go with the config). Note: I want this to be particularly easy and intuitive, as I may not be willing or able to deal with complicated, lengthy or error-prone procedures for this (especially for jumping into multiplayer matches).

2. I want to create an own config file to use or test a set of changes (to develop an own aic, customize aivs or adjust other settings for singleplayer to my personal taste). I may want to share that config with others later.

3. I want to use multiple configurations of the ucp in parallel on different SHC installations on my computer.

4. I want to reference resource assets (e.g. aivs, aics, maps?) in several config files (without having to duplicate them to the location of every config file referencing them).

5. I want to keep track of which configs are currently used on what SHC installations. (Ideally, I also have some indication of what version of a config file is installed / if that file has changed since last installing it, but that may be difficult and low priority?)

6. I want to have all of the aforementioned stuff (if applicable) usable for both ucp gui and ucp cli.

In the new UCP you can save and load Configs, maybe yes a folder would be nice to load more than one Config or a search of all subfolder where UCP is in, but how display them? (on start with selection which one you want to use and which currently is applied to that Stronghold path you have currently?)
AIC/AIV you want to be inside of the config or how you mean that, because this should be later in the Modloader some Guys want to build?(i mean the aic/aiv files)

Same thing Load/Save config in UCP with new GUI will be easy

3.How you want them in parallel, every time a new UCP window or maybe with a selection Window of all found Configs you set paths for with also selectable Stronghold Paths from a extra file you just have Paths to different Strongholds?
4.This will  be need some more discussions if this will be in UCP or in a modlader.
In future UCP will be for Modder and a Modloader for users that want specific mods?

Yeah some indications would be nice inside of Stronghold like ModPack(nameoftheConfig) used in Stronghold? Or maybe Hash all selection together for version?

Should be possible with the redo of GUI and UCP library behind. they will use the same name keys for the selection names.


pre-commit: PR110630

Link: https://github.com/llvm/llvm-project/pull/110630
Requested by: @dtcxzyw

/add-label reviewed

/close


Publishing messages only works some of the time

Observed behavior
I'm trying to publish a very basic message to my synadia account and I get maybe one message through every couple of days using the node client, but I can send them consistently through golang.
Expected behavior
Every message sent ends up in my synadia account or an error message is thrown if there is an issue
Server and client version
server: whatever synadia is using
windows client:
> nats --version
v0.1.4

node dependency: "nats": "^2.28.2",
Host environment
Running it locally on windows 11 as well as some amazon boxes
Steps to reproduce
package.json:
{
	"dependencies": {
		"nats": "^2.28.2",
		"uuid": "^11.0.3"
	}
}

test.js:
const { connect, credsAuthenticator } = require("nats");
const fs = require('fs');
const path = require('path');
const { v4: uuidv4 } = require('uuid');

const test = async () => {
	const filePath = path.join(__dirname, './~~~synadia~~~.creds');
	const data = fs.readFileSync(filePath, 'utf8');
	const natsConnection = {
		servers: "tls://connect.ngs.global",
		authenticator: credsAuthenticator(new TextEncoder().encode(data)),
	};
	const nc = await connect(natsConnection);
	if (!nc) {
		throw new Error("NATS connection is not established");
	}
	const done = nc.closed();

	const transactionId = uuidv4();

	const testEmailToSend = {
			"message": "Never gonna give you up....but, actually I might. We just aren't clicking. I'm sorry, it's over. Find someone else. Or don't, I don't care. You broke my heart, Ethel, I'm not gonna let you do it again!",
			"image_url": "https://media1.tenor.com/m/x8v1oNUOmg4AAAAd/rickroll-roll.gif"
	};

	try {
		console.log('sending', emailToSend);
		nc.publish("communications", JSON.stringify(emailToSend));
		console.log("Sent!");
	}
	catch (error) {
		console.error("Failed to send email to: ", error);
	}
}

test();

Running node test.js shows the console logs but nothing shows up in synadia. However a golang version using the same credentials & connection information & test message shows up just fine

I think somehow you are closing/killing the connection before data is sent out.
Try something like;
import {connect, delay, createInbox} from "nats"

const c = await connect({servers: "demo.nats.io"});
const inbox = createInbox();
c.subscribe(inbox, {callback: (err, msg) => {
    console.log(msg.json());
}})

const timer = setInterval(async () => {
    // wait as if you are doing something
    await delay(500);
    const start = Date.now();
    const nc = await connect({servers: "demo.nats.io"});
    nc.publish(inbox, JSON.stringify({
        date: new Date().toISOString(),
        message: "hello world doing something",
        payload: new Uint8Array(30)
    }));

    await nc.drain();
    console.log(Date.now() - start, "ms");
}, 2000)

await delay(20000);
clearInterval(timer);
c.close();

If you want to be sure you sent something, you can only do so if you send a request:
import {connect, delay, createInbox} from "nats"

const c = await connect({servers: "demo.nats.io"});
const inbox = createInbox();
c.subscribe(inbox, {callback: (err, msg) => {
    console.log(msg.json());
    msg.respond();
}});

const timer = setInterval(async () => {
    // wait as if you are doing something
    await delay(500);
    const start = Date.now();
    const nc = await connect({servers: "demo.nats.io"});
    await nc.request(inbox, JSON.stringify({
        date: new Date().toISOString(),
        message: "hello world doing something",
        payload: new Uint8Array(30)
    }));

    await nc.close();
    console.log(Date.now() - start, "ms");
}, 2000)

await delay(20000);
clearInterval(timer);
c.close();

Also note that:
	const nc = await connect(natsConnection);
	if (!nc) {
		throw new Error("NATS connection is not established");
	}

Is not really a check - the connect fails, it rejects a promise, which means that nothing will go out, but you should see an error on your side.

I think somehow you are closing/killing the connection before data is sent out.
Try something like;
import {connect, de~~~
c.close();

That's what my assumption as well, and I'd actually added the .drain() call thinking that might do it, but it doesn't seem to actually make it go through.
I put it in a loop, added the delays, and let it run but although I was getting feedback and nothing was throwing errors, the messages never showed up on synadia's side. It (seems to) work fine with demo.nats.io, the subscribe seems to come back with stuff. If I replace the demo.nats.io with the connection information, the subscribe seems to come back as well, however it doesn't appear on the synadia site and the apps we have listening on that subject aren't activated.


fix longstanding error in pthread_attr_t definition

Describe the bug
It looks like there was a copy-paste error made several years ago when defining pthread_attr_t.
https://github.com/zephyrproject-rtos/zephyr/commit/c8aa6570c14dfc64ccfafd2c73a924bebc227a56
typedef struct pthread_attr_t {
...
} pthread_attr_t;

To Reproduce
Discovered during CI build of #25527
Expected behavior
Expected build to succeed
Impact
Blocks #25527
Screenshots or console output
https://app.shippable.com/github/zephyrproject-rtos/zephyr/runs/73710/1/console
pthread_attr_t defined as wrong kind of tag
...
conflicting types for pthread_attr_t

Environment (please complete the following information):
CI (see shippable link)
Additional context

Ah... looks like it might be specific to the nrf52_bsim.
This kind of gives it away:
-include /home/buildslave/src/github.com/zephyrproject-rtos/zephyr/arch/posix/include/posix_cheats.h

I should adjust my #ifdefs accordingly.


Statistics tests for ORC files written by GPU

When the GPU writes an ORC file, it's important to get the file, row group, and page statistics correct. We should have better tests, ideally including tests at larger scale than a few thousand rows typical for unit/integration tests, for verifying the statistics written to the ORC file are correct.

Found cuDF issue: https://github.com/rapidsai/cudf/issues/13837

Link other cuDF ORC statistic issues:
https://github.com/rapidsai/cudf/issues/13793
https://github.com/rapidsai/cudf/issues/13817


Update versions of K3S root, flannel and cni_plugins

K3S_ROOT
FLANNEL
CNI_PLUGINS

Signed-off-by: Manuel Buil<EMAIL_ADDRESS>

Proposed Changes

Types of Changes

Verification

Linked Issues

https://github.com/k3s-io/k3s/issues/5034
User-Facing Change

Update to flannel v0.16.2

Further Comments

Rebasing to have the wonderful Derek's CI fix


Add migrations

Figure out how to perform migrations between 0.2 and upcoming 0.4 (note there is no cirrus 0.3 planned, as it's being bumped to match minor versions with cirrus-lib).

@matthewhanson Is this still applicable?

No, we may need to add migrations later if we update schema, but this is OBE


Add README.rst title and PyAnsys badge

Adds a title to the README.rst file and includes a PyAnsys badge.

@jorgepiloto Nice to see the 'pyansys' badge.


A&R -> Display no records user message instead of a loading image when loading Historical subarea data

Description
How to replicate:

Navigate to the A&R on TEST: A&R Admin
Log in and navigate to the Enter Data page
Select a date, Park (Garibaldi park) and a Subarea with the Historic tag
Click on the Go button and see how the data is displayed

Expected Behavior:

Should display a waiting style until the data is loaded before the user message for no data is displayed.

Issue:

Display the user message for No data before the data actually loads.
https://api.media.atlassian.com/file/cc4850e6-d8af-4d2c-85e8-a2dfe3f860a3/artifact/video_1280.mp4/binary?client=388df08e-596c-468b-8d69-8aea68058aa1&collection=&max-age=2592000&token=eyJhbGciOiJIUzI1NiJ9.eyJpc3MiOiIzODhkZjA4ZS01OTZjLTQ2OGItOGQ2OS04YWVhNjgwNThhYTEiLCJhY2Nlc3MiOnsidXJuOmZpbGVzdG9yZTpmaWxlOmNjNDg1MGU2LWQ4YWYtNGQyYy04NWU4LWEyZGZlM2Y4NjBhMyI6WyJyZWFkIl19LCJleHAiOjE2OTgzNDYwNTgsIm5iZiI6MTY5ODM0NTE1OH0.ZtfMaE3deIRoNo3jYL-bPco_5H2oJTcC7EOYRdibvJs

Linked issues
relates to

[x] ~BRS-972~

if the link of the video above doesn't work, then navigate to the original video attachment in jira ticket
BRS-1138


Improve error output for fastlane

Tasks

[ ] Wrap Ruby Standard Error with Fastlane Error.

Description
This is an umbrella task for improving the user friendliness of the output of Fastlane. Currently fastlane has the current issues when there is an error:

If an error occurs you need to re-run it in verbose mode in order to get all the steps, for some builds this means a 30 minute turnaround time.
Some trivial errors have a verbose and unhelpful output and force you to look into the sentry file to find out what the error actually was.
The path to the sentry file is buried by the output of the environment variables, lane table and new update prompt.

#Example Pseudo-Output 1 - The User sets an ENV to a boolean instead of a string
fastlane lane
< Lane Output >
Error "Ruby::JumpError"
< Really long stack trace to do with the jump error but doesn't help you know what the error is >
< Environment Variable Dump - Very long especially if you use the change log action >
< Lane Table >
< Sentry file link >
< Really long stack trace to do with the jump error but doesn't help you know what the error is >
< Fastlane update prompt including really long change log >

If you open the sentry file, the actual error isn't even at the top of the file, once you figure out the format of the log it's easy to see that ENV["MY_VAR"] = true should be `ENV["MY_VAR"] = "1"
In this case I would have preferred:
fastlane lane
< Lane Output >
Error "Cannot convert true to String"
< For more debug information go to this file - link to sentry file - on CI we could echo the contents of this file in a way thats obvious its the error  >
< Your fastlane is out of date, no change log >

#Example Pseudo-Output 2 - A tool fails for some reason
fastlane lane
< Lane Output >
< Command line error >
Error "Ruby::JumpError"
< Really long stack trace to do with the jump error but not useful at all >
< Environment Variable Dump - Very long especially if you use the change log action >
< Lane Table >
< Sentry file link >
< Really long stack trace to do with the jump error but not useful at all >
< Fastlane update prompt including really long change log >

Again way too much information and we then have to run verbose to get the important information which isn't in the sentry file.

It would be awesome if Fastlane in non verbose mode could log the commands to a external file for debugging.
When there is an error with the command it would be great if we just saw what failed and then had the link to the sentry log, nothing more, nothing less.

#Overview
Steps:

Log commands to a special log file when not in verbose mode so user doesn't have to re-run lane just to get what was done.
Only dump lane table and environmental variable on an error into the sentry log.
Only dump stack trace in sentry log.
When there is an error, print the descriptive error in the sentry log not the "Ruby::JumpError" message. Ideally we could have some helpful hints on how to fix it for the user.
Don't print the whole change log for the new version of fasltane, just letting us know there is a new version is enough when there is an error.
Ran under CI the contents of the sentry file could be echoed out followed by the friendly error message, so the user can look at their CI logs to see the issue and simply copy over to here.
[Bonus] Fastlane could output a template for a github issue, (See how CocoaPods does this).

I'm a bit unsure about how much value we get with Sentry, I'm thinking about just removing it, since we usually tell users to post their stack trace anyway.

@KrauseFx we should probably look into pre-filling a template like CocoaPods does and perhaps copying to to the clipboard so users can post directly into an issue.
Maybe @orta from that team can point to how they did that.

We use the same thing in Danger, where we wrap the standard error with our own - also gh-issues-inspector can improve that experience

We actually already wrap all of our exceptions in our own classes (https://github.com/fastlane/fastlane/blob/master/fastlane_core/lib/fastlane_core/ui/interface.rb#L114-L120), but don't have custom printing yet.
We don't do that for actual Ruby crashes though, only when we raise one

@KrauseFx As a first step maybe wrap the standard error ?

https://github.com/fastlane/fastlane/pull/4756 Should help with this.


Adding python3 version of lambda and tests.

Added a python3 version of lambda and tests.
Updated cloudformation template to add SNS topic, and updated lambda role to push to topic
Updated README to mention python3 lambda version, and how to run tests.
Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

NOTE:  This does not affect the current python2 version of the lambda.  Everything for the existing version is un-touched (other than adding an SNS topic to CF template and updating role).  Run tox to see tests.  Currently have 73% coverage.  Waiting for some moto changes in order to increase coverage.

Hi @jicowan
could you help in supporting this repo also?
It would be good to look into some PRs and Issues.
Thanks.


Macro-enabled document created with CreateFromTemplate() cannot be opened by Word

Describe the bug
As described in this stackoverflow question and my answer, Microsoft Word does not open a macro-enabled document (.docm) created from a macro-enabled template (.dotm) with the WordprocessingDocument.CreateFromTemplate() method. When using the same code to create a "normal" document (.docx) from a template (.dotx), Word opens the document without any issue.
When validating both documents (i.e., .docm and .docx) with the OpenXmlValidator, no validation errors are reported (unless the template is attached, in which case one validation error related to the attached template is emitted in each case).
To Reproduce
public sealed class CreateFromTemplateTests
{
    private readonly ITestOutputHelper _output;

    public CreateFromTemplateTests(ITestOutputHelper output)
    {
        _output = output;
    }

    [Theory]
    [InlineData("c:\\temp\\MacroEnabledTemplate.dotm", "c:\\temp\\MacroEnabledDocument.docm")]
    [InlineData("c:\\temp\\Template.dotx", "c:\\temp\\Document.docx")]
    public void CanCreateDocmFromDotm(string templatePath, string documentPath)
    {
        // Let's not attach the template, which is done by default. If a template is attached, the validator complains as follows:
        // The element has unexpected child element 'http://schemas.openxmlformats.org/wordprocessingml/2006/main:attachedTemplate'.
        using (var wordDocument = WordprocessingDocument.CreateFromTemplate(templatePath, false))
        {
            // Validate the document as created with CreateFromTemplate.
            ValidateOpenXmlPackage(wordDocument);

            // Save that document to disk so we can open it with Word, for example.
            wordDocument.SaveAs(documentPath).Dispose();
        }

        using (WordprocessingDocument wordDocument = WordprocessingDocument.Open(documentPath, true))
        {
            // Validate the document that was opened from disk, just to see what Word would open.
            ValidateOpenXmlPackage(wordDocument);
        }
    }

    private void ValidateOpenXmlPackage(OpenXmlPackage openXmlPackage)
    {
        OpenXmlValidator validator = new(FileFormatVersions.Office2019);
        List<ValidationErrorInfo> validationErrors = validator.Validate(openXmlPackage).ToList();

        foreach (ValidationErrorInfo validationError in validationErrors)
        {
            _output.WriteLine(validationError.Description);
        }

        if (validationErrors.Any())
        {
            // Note that Word will most often be able to open the document even if there are validation errors.
            throw new Exception("The validator found validation errors.");
        }
    }
}

The above unit tests pass and no validation errors are reported.
I could not attach the templates. However, I only created super-simple templates with one line of text and a hello world macro in the case of the macro-enabled template.
Observed behavior
The Word document (.docx) created by the test can be opened as expected. The macro-enabled document (.docm) cannot be opened. In my case, Word neither displays the document nor reports any error. In the case of the original poster of the stackoverflow question, a runtime error seems to occur (which I could not reproduce).
Expected behavior
Using WordprocessingDocument.CreateFromTemplate(), the Open XML SDK should be able to create a macro-enabled document (.docm) from a valid, macro-enabled template (.dotm) that can be opened by Microsoft Word.
Desktop (please complete the following information):

OS: Windows 10 (in my case)
Office version: Word 365 version 16.0.14931.20648 32bit (OP on stackoverflow), Microsoft Word for M365 MSO (Version 2022 Build 16.0.14931.20858) 64-bit (in my case)
.NET Target: .NET 7.0 and net472 (in my case)
DocumentFormat.OpenXml Version: 2.19.0 (in both cases)

I am attaching the problematic .dotm files from my case.
The difference between them is that one has a module with a macro and the other does not.
A file created from a template with VBA code does not open.
TemplatesAndFiles.zip

Thanks for sending the files from your case. I'm seeing the same issue you, are and I also don't receive an errors, the file just doesn't open. I will try and see if I can find the underlying issue.

Some observations posted as comments by me on StackOverflow with some additions:
"When Word creates a new document from a .dotm it creates a macro-free document. The file created by CreateFromTemplate from a .dotm has VBA-related parts but the type specified in [Content_Types].xml for the main document is for a regular .docx. If you change it to a .docm type (i.e. ). the document opens, but does not find its macros. CreateFromTemplate should probably be creating a .docx and should not be creating the macro-related parts and relationships."
When I looked at the documentation for CreateFromTemplate on the relevant Microsoft site it wasn't at all clear what the expectation should be. As @ThomasBarnekow mentioned, when CreateFromTemplate is passed a .dotm, perhaps the result should be a .docm with macros, linked to the .dotm. Perhaps this is actually specified somewhere in some other, more complete, version of the documentation.
The other (probably unrelated) thing I noticed when looking at the .docx/.docm package was that the [Content_Types].xml file for the document created by CreateFromTemplate  specifies a default content type for the .xml extention that is a very specific type, rather than a general type.
i.e. it has <Default Extension="xml" ContentType="application/vnd.openxmlformats-package.core-properties+xml/>
IMO you might expect that as an Override for the core-properties part, but not as a Default - elsewhere, I think the following is more typical:

Probably not a big deal if every xml part has a suitable override, but perhaps the code is working harder than it needs to.


points cropped with map view

points cropped as screencap, any advise?

Is that a local installation or carto.com hosted version?

local installation

Can you check you don't have a low row limit: https://github.com/CartoDB/Windshaft-cartodb/blob/6597851b480ceb3712d7751c5092a300daac64f7/config/environments/development.js.example#L65 ?

row_limit: 65535,
but my dataset contains 17m rows
will this cause the problem?

That configuration value limits the number of features that can be rendered by [meta]tile. That's, probably, why you are having some points missing in one of the tiles because that tile is already rendering 65535 features.
If you want to render all of them (I don't encourage that if you have 17M rows), simply use row_limit: 0.
I just added a comment to the configuration examples to clarify that config parameter: https://github.com/CartoDB/Windshaft-cartodb/commit/25de018f7dd024800c3ecd869ad9d6b818163f56.
HTH.

i still getting the same result even row_limit:<PHONE_NUMBER>00

i have turned row_limit to 0,
but the point cannot be rendered , some error shown from my browser console
Failed to load resource: the server responded with a status of 502 (Bad Gateway) http://xxxxxxxxx/user/dev/api/v1/map/adb5b045fb8840f6ef5e2f281e906878:147…c0f5&api_key=xxxxxxxxx&cache_policy=persist
i have tried to set the timeout in config.socket_timeout and renderer.http.timeout to a very big value, but still no luck

About the 502 error: are you running it behind a reverse proxy?
Have in mind that point rendering takes linear time, if you have a lot of points behind a tile it will take a lot of time to render it.

ya, i am running with nginx and already set the timeout to an hour, is there any timeout setting i may missed? i am actually using https://hub.docker.com/r/sverhoeven/cartodb/

@rochoa
i have tried to config the map api serve from 8181 directly instead of nginx,
some png still cannot load Failed to load resource: net::ERR_EMPTY_RESPONSE

You are probably hitting other limits, like database statement timeout. Do you know how many points are in those tiles? Do you really need to render all of them?

still cannot works with my dataset, checked no statement timeout, and no error log generated from  postgresql

I encourage you to try to isolate the debugging on of the failing requests. I usually do it by using "Copy as cURL": https://daniel.haxx.se/blog/2015/11/23/copy-as-curl/.

seems there are a 2 mins timeout , do you have any idea? thanks a lot!

That's most likely a Google Chrome client timeout. That's why I suggested using cURL to replay the requests.


Direction overlay disables open/close swipe action

After one of the last updates of Home Assistant, this card displays an arrow informing the last movement of the shade:

However this disables the normal function of the card when we try to pull the shade up or down.
It's like there's an overlay.
Card Config:
type: vertical-stack
cards:
  - type: custom:shutter-card
    entities:
      - entity: cover.shade1
        name: Shade 1
        buttons_position: right
      - entity: cover.shade2
        name: Shade 2
        buttons_position: right

I've come to realize that the status of my blinds upon stopping does not update to "open" but stays in "opening" - therefore the overlay in the card.
This issue can be closed.


Erratic vertical sync timing

When using the VK_PRESENT_MODE_FIFO_KHR presentation mode for a swapchain on a window with a 60 Hz refresh rate, I have found that I cannot guarantee that the rendering rate is both fixed at 60 FPS (i.e. the time cost of each frame is fixed at 16.6 ms), even though I am not rendering anything. The actual duration of each frame (actually the present call) can sometimes reach 2 vertical sync periods (i.e. 32 ms) and sometimes is not even an integer multiple of a vertical sync period (e.g. 25 ms). I've tested some different graphics cards from different vendors and with different drivers, but they all have this phenomenon. Is there something I missed?

What example does this issue refer to? Or is this is just a general question? If so, this isn't the right place to ask.


Timestamps are not saved on stored carts

HI! I see you added $table->nullableTimestamps(); in the shoppingcart table migration that comes with the package, but in fact they are always null.
Is there some additional configuration I didn't see?
I'm using stored carts to let the customer care see what's in the user cart and it may be useful to let them see timestamps, not essential though.

I just think that's something I've overlooked actually.
So you didn't miss any configuration, it's just not setting the timestamps ;)

I am not able to add items above price 885.Any reason


debugging with node package.json broken in August update 1.71

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: 1.71
OS Version: Mac OS 12.5.1

Steps to Reproduce:

our node.js server project uses a package.json with various "scripts" for running/debugging
running the debugger from VSCode works fine in 1.70, but hangs/never starts anything in 1.71

Lost an entire day to track it down to VSCode being the thing that changed.

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.71.0. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

Your bot reply is not helpful.  I am using that version!  My bug report clearly shows I am using 1.71 and that is the problem

I had the same issue and reverting to version 1.70.2 fixed it.

@ianfairbairn yes, me too, I reverted, but that seems like a temporary fix at best.  we need to be able to move forward!
@weinand hello there!  been many years since Taligent/UBILAB, but seems our paths have crossed again.  Sorry my bug report is very lame, but I'm really unclear what else to say.  Glad to see I'm not alone.  Happy to help debug / share my screen, do whatever might help you :-)

/duplicate #159881

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.
Happy Coding!

This is fixed in the latest Insiders and will be included in the next recovery release.

Same bug here. Also temporarily fixing it with downgrading. But whenever I close and open it again it has been updated to the latest broken version. Does someone know how to turn it off?

@emersonjr07 there's a setting for Application Update

I had to set that, THEN downgrade again, but then it remains on the version.


Add configured pre-commit hook for bandit (security linting)

https://github.com/PyCQA/bandit
as detailed on
https://pre-commit.com/hooks.html
Bandit docs (if necessary): https://bandit.readthedocs.io/en/1.7.3/start.html

Would you mind if I picked this up? Just a heads up it would be my first issue.


Firebase registration token is not updated when app is restored on a new iphone device

scenario:
I updated my phone from iPhone 7 to iPhone 8. My app uses the callback method:
(void)messaging:(nonnull FIRMessaging *)messaging didRefreshRegistrationToken:(nonnull NSString *)fcmToken
to get a new firebase token (we allow the swizzling of the didRegisterForRemoteNotificationForDeviceToken) and save to our backend server. If I reinstall our app, this method is called with a new firebase token after user allows remote notifications. When I upgrade from my phone restoring my backed up app to a new iphone, this method was not called when the app is first launched. Our backend server still thinks the firebase token is the same, but we are no longer able to send notifications using it. According to Apple documentation, a new APNS token is generated when you restore your app to a new device. Since the other apps on my phone are sending notifications, I'm wondering if there's a bug for Firebase for this scenario. We are using FirebaseMessaging (= 2.0.2) and FirebaseInstanceID (~> 2.0)

What's the version of FirebaseInstanceID you're using? If you haven't already, does upgrading to 2.0.4 fix the issue?

It is using version 2.0.0 for FirebaseInstanceID. Let me update to the latest version to see if that resolves this issue.

@mgorkani is this still an issue?


[Snyk] Upgrade se.swedenconnect.security:credentials-support from 1.2.5 to 1.3.2

Snyk has created this PR to upgrade se.swedenconnect.security:credentials-support from 1.2.5 to 1.3.2.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 4 versions ahead of your current version.

The recommended version was released on 6 months ago.

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:

🧐 View latest project report
📜 Customise PR templates
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

https://github.com/swedenconnect/ca-engine/pull/43


Rule Q000-Q002 started to cause panic

ruff 0.3.4
(latest changes from main branch)
ruff  *.py --select Q000 --no-cache --fix --unsafe-fixes --preview --output-format concise --isolated

file content:
NEWLINE_SEQUENCE: "te.Literal['\\n', '\\r\\n', '\\r']" = "\n"

error
All checks passed!

error: Panicked while linting /opt/tmp_folder/2097975619179584230.py: This indicates a bug in Ruff. If you could open an issue at:

    https://github.com/astral-sh/ruff/issues/new?title=%5BLinter%20panic%5D

...with the relevant file contents, the `pyproject.toml` settings, and the following stack trace, we'd be very appreciative!

panicked at crates/ruff_linter/src/rules/flake8_quotes/rules/check_string_quotes.rs:331:47:
begin <= end (1 <= 0) when slicing `C`
Backtrace:    0: ruff::panic::catch_unwind::{{closure}}
             at ./ruff/crates/ruff/src/panic.rs:31:25
   1: <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/alloc/src/boxed.rs:2029:9
   2: std::panicking::rust_panic_with_hook
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:783:13
   3: std::panicking::begin_panic_handler::{{closure}}
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:657:13
   4: std::sys_common::backtrace::__rust_end_short_backtrace
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/sys_common/backtrace.rs:171:18
   5: rust_begin_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:645:5
   6: core::panicking::panic_fmt
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:72:14
   7: core::str::slice_error_fail_rt
   8: core::str::slice_error_fail
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/str/mod.rs:88:9
   9: core::str::traits::<impl core::slice::index::SliceIndex<str> for core::ops::range::Range<usize>>::index
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/str/traits.rs:231:21
  10: core::str::traits::<impl core::ops::index::Index<I> for str>::index
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/str/traits.rs:61:15
  11: ruff_linter::rules::flake8_quotes::rules::check_string_quotes::strings::{{closure}}
             at ./ruff/crates/ruff_linter/src/rules/flake8_quotes/rules/check_string_quotes.rs:331:47
  12: <core::slice::iter::Iter<T> as core::iter::traits::iterator::Iterator>::any
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/slice/iter/macros.rs:285:24
  13: ruff_linter::rules::flake8_quotes::rules::check_string_quotes::strings
             at ./ruff/crates/ruff_linter/src/rules/flake8_quotes/rules/check_string_quotes.rs:322:23
  14: ruff_linter::rules::flake8_quotes::rules::check_string_quotes::check_string_quotes
             at ./ruff/crates/ruff_linter/src/rules/flake8_quotes/rules/check_string_quotes.rs:456:9
  15: <ruff_linter::checkers::ast::Checker as ruff_python_ast::visitor::Visitor>::visit_expr
  16: ruff_python_ast::visitor::walk_expr
             at ./ruff/crates/ruff_python_ast/src/visitor.rs:546:17
  17: <ruff_linter::checkers::ast::Checker as ruff_python_ast::visitor::Visitor>::visit_expr
  18: <ruff_linter::checkers::ast::Checker as ruff_python_ast::visitor::Visitor>::visit_expr
  19: ruff_linter::checkers::ast::Checker::visit_deferred_string_type_definitions
             at ./ruff/crates/ruff_linter/src/checkers/ast/mod.rs:2020:21
  20: ruff_linter::checkers::ast::Checker::visit_deferred
             at ./ruff/crates/ruff_linter/src/checkers/ast/mod.rs:2094:13
  21: ruff_linter::checkers::ast::check_ast
             at ./ruff/crates/ruff_linter/src/checkers/ast/mod.rs:2206:5
  22: ruff_linter::linter::check_path
             at ./ruff/crates/ruff_linter/src/linter.rs:156:40
  23: ruff_linter::linter::lint_fix
             at ./ruff/crates/ruff_linter/src/linter.rs:544:22
  24: ruff::diagnostics::lint_path
             at ./ruff/crates/ruff/src/diagnostics.rs:280:14
  25: ruff::commands::check::lint_path::{{closure}}
             at ./ruff/crates/ruff/src/commands/check.rs:194:9
  26: std::panicking::try::do_call
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:552:40
  27: std::panicking::try
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:516:19
  28: std::panic::catch_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panic.rs:142:14
  29: ruff::panic::catch_unwind
             at ./ruff/crates/ruff/src/panic.rs:40:18
  30: ruff::commands::check::lint_path
             at ./ruff/crates/ruff/src/commands/check.rs:193:18
  31: ruff::commands::check::check::{{closure}}
             at ./ruff/crates/ruff/src/commands/check.rs:94:17
  32: <rayon::iter::filter_map::FilterMapFolder<C,P> as rayon::iter::plumbing::Folder<T>>::consume
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-1.9.0/src/iter/filter_map.rs:123:36
  33: rayon::iter::plumbing::Folder::consume_iter
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-1.9.0/src/iter/plumbing/mod.rs:179:20
  34: rayon::iter::plumbing::Producer::fold_with
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-1.9.0/src/iter/plumbing/mod.rs:110:9
  35: rayon::iter::plumbing::bridge_producer_consumer::helper
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-1.9.0/src/iter/plumbing/mod.rs:438:13
  36: rayon::iter::plumbing::bridge_producer_consumer
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-1.9.0/src/iter/plumbing/mod.rs:397:12
  37: <rayon::iter::plumbing::bridge::Callback<C> as rayon::iter::plumbing::ProducerCallback<I>>::callback
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-1.9.0/src/iter/plumbing/mod.rs:373:13
  38: <rayon::slice::Iter<T> as rayon::iter::IndexedParallelIterator>::with_producer
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-1.9.0/src/slice/mod.rs:777:9
  39: rayon::iter::plumbing::bridge
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-1.9.0/src/iter/plumbing/mod.rs:357:12
  40: <rayon::slice::Iter<T> as rayon::iter::ParallelIterator>::drive_unindexed
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-1.9.0/src/slice/mod.rs:753:9
  41: <rayon::iter::filter_map::FilterMap<I,P> as rayon::iter::ParallelIterator>::drive_unindexed
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-1.9.0/src/iter/filter_map.rs:46:9
  42: <rayon::iter::fold::Fold<I,ID,F> as rayon::iter::ParallelIterator>::drive_unindexed
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-1.9.0/src/iter/fold.rs:59:9
  43: rayon::iter::reduce::reduce
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-1.9.0/src/iter/reduce.rs:15:5
  44: rayon::iter::ParallelIterator::reduce
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-1.9.0/src/iter/mod.rs:998:9
  45: ruff::commands::check::check
             at ./ruff/crates/ruff/src/commands/check.rs:165:10
  46: ruff::check
             at ./ruff/crates/ruff/src/lib.rs:415:13
  47: ruff::run
             at ./ruff/crates/ruff/src/lib.rs:192:33
  48: ruff::main
             at ./ruff/crates/ruff/src/main.rs:65:11
  49: core::ops::function::FnOnce::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:250:5
  50: std::sys_common::backtrace::__rust_begin_short_backtrace
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/sys_common/backtrace.rs:155:18
  51: std::rt::lang_start::{{closure}}
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/rt.rs:166:18
  52: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:284:13
  53: std::panicking::try::do_call
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:552:40
  54: std::panicking::try
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:516:19
  55: std::panic::catch_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panic.rs:142:14
  56: std::rt::lang_start_internal::{{closure}}
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/rt.rs:148:48
  57: std::panicking::try::do_call
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:552:40
  58: std::panicking::try
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:516:19
  59: std::panic::catch_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panic.rs:142:14
  60: std::rt::lang_start_internal
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/rt.rs:148:20
  61: main
  62: <unknown>
  63: __libc_start_main
  64: _start

python_compressed.zip
Probably caused by #10312
CC @dhruvmanila

Thanks! Let me look at it tonight.

This is happening because the checker is analyzing the string inside the annotation (three strings inside Literal). The ranges aren't correct in that case. We need to find a holistic solution to this because it's happening to all rules working on strings.
For example, here UP025 is triggered for the u'\\n' which is inside the string type annotation.
/Users/dhruv/playground/ruff/src/UP025.py:1:12: UP025 [*] Remove unicode literals from strings
  |
1 | NEWLINE_SEQUENCE: "te.Literal[u'\\n', '\\r\\n', '\\r']" = "\n"
  |            ^^^^^ UP025
  |
  = help: Remove unicode prefix

ℹ Safe fix
1   |-NEWLINE_SEQUENCE: "te.Literal[u'\\n', '\\r\\n', '\\r']" = "\n"
  1 |+NEWLINE_SEQENCE: "te.Literal[u'\\n', '\\r\\n', '\\r']" = "\n"

Found 1 error.
[*] 1 fixable with the --fix option.

We could potentially fix the range for the rules to be useful in the context of type annotation or ignore them completely. Nevertheless, we should completely avoid rules which might update the quotes because otherwise we need the context of the quote which contains the actual type annotation.


PHOENIX-5561: Replace Java8 code

I see you're checking this into master. Just want to point out that this is only a problem in the 4.x branches; JDK 8 is fine in master. It's also fine if you want to keep the code in sync in both places.

Thanks @gjacoby126 ! Yes I would like to keep them in sync

JIRA is resolved, closing PR


The maintainer of the library openly supports the Ukrainian war

Before proceeding

[X] I didn't find a similar issue

Problem
Ilya Lesikov who is a maintainer of this project supports the Ukrainian. If you go to his LinkedIn, you can find a post that he has liked: https://www.linkedin.com/in/ilya-lesikov/recent-activity. You can translate and read the post by yourself, but TLDR:
I'm a patriot, war is bad, but if my government thinks it's okay, then I support this.
Consider not using this project and replacing it ASAP. Loyal to the Russian government developers may place backdoors by the government's request, so be very careful with this too.
Solution (if you have one)
No response
Additional information
No response

Hi! I am a co-founder of Flant, the company behind werf.
First of all, I'd like to anticipate that the liked post you're referring to contradicts our company's position. Our position was publicly stated on our resources (e.g. Twitter).
Despite this unambiguous position which was well-explained and well-known to our employees, we still might face different opinions, e.g. revealed by "liking" what is somehow relevant to what someone personally thinks. Thank you for bringing our attention to this specific case, and we'll discuss it with Ilya ASAP.
As for potential backdoors, our project has been Open Source since its inception (more than 6 years ago), so there is a rich public history you can consider while evaluating such risks. Another important thing is all werf releases have to be signed by a quorum of developers before they go public. It means that in case of malicious intentions of some specific developer become real, they will be verified by the teammates before users are affected.


fix(template): typehint default config file

Before submitting the PR, please make sure you do the following

[ ] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
[ ] This message body should clearly illustrate what problems it solves.
[ ] Ideally, include a test that fails without this PR but passes with it.

Tests

[ ] Run the tests with pnpm test and lint the project with pnpm lint

Changesets

[ ] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpx changeset and following the prompts

Is this for VS Code support? Seems like a bug there if this is required, but I'm fine with changing it here to workaround it anyway. It looks like we already do this in the default template

Yeah, it's the only correct way to actually apply JSDoc typehints – has to be applied to a variable/function

Does this become a non-issue when we switch to ESM configs? Can you type an export default?

Nope, still variables and functions only

There is an @exports directive but I've never got that to work. Even then, due to the age, it was probably CommonJS-specific

actually just realised that this PR won't change anything, the edited file gets replaced by either this one or this one.
But now that I look at those files, I see this —

— in other words I'm pretty sure this only applies to ESM? Annoying that it fails with export default but works fine with export const, feels like something that could be fixed in TS. (Better still, let us type modules!)


Improve facility display logic on Admin user details page

Description
Currently, on the user details page of an admin user, the message "Added to 0 facilities" is displayed, even though the user has access to all facilities. This inconsistency in the displayed information can lead to confusion and misinterpretation of the user's access privileges. To enhance clarity and accuracy, this enhancement proposes improving the facility display logic to accurately reflect the admin user's access to facilities.
Additional information
https://jam.dev/c/4bd5bc75-bc92-48d2-be92-4544177b8aca

Will add UI here

@Adameddy26 can you share if the ability to view all facilities is checked based on a specific permission? Or is it based on security group? I think it's permission, and if so, what is the permission ID that is check.

@Adameddy26 can you share if the ability to view all facilities is checked based on a specific permission? Or is it based on security group? I think it's permission, and if so, what is the permission ID that is check.

STOREFULFILLMENT_ADMIN - If this permission is given to any group, then each user in that group will be able to perform operations for every facility

@Adameddy26 @dt2patel
What should be the action item here? Should we display the count for all facilities for the admin/super user and disable the modal that opens to manage the user's facilities? If not, what should the behavior of the facilities modal be?

Sorry looks like I forgot to attach UI:

Changes verified and working fine in release v1.11.0.  Hence, closing this ticket.


use cStringIO on py2

six.BytesIO is StringIO on python 2.
@abhinav @breerly @junchaowu

Do we have concern about the Unicode part?

@junchaowu I think at this layer everything should be utf8-encoded bytes but @abhinav can confirm.

:+1:


Manual spot change

In This PR

Manually updating user spot id incase things get weird (things have already gotten weird)

[ ] Checked on staging

Should definitely add logging for these actions


Overflow hidden is broken on android 0.36

Description
Overflow hidden worked on android before as expected and after upgrade to 0.36 it's broken now. Overflow is visible, but it's not consistent sometimes on update overflow will work and on initial render will be broken. Also I have noticed if you put backgroundColor: 'transparent' it will work fine
Not sure what is changed, because I can't find anything in changelogs that will cause this to broke.
Reproduction
It's showing like this

but it should be like this

class OverflowTest extends Component {
  render() {
    return (
      <View style={{ overflow: 'hidden', width: 100, height: 100 }}>
        <Image
          source={{ uri: 'https://placeholdit.imgix.net/~text?txtsize=33&txt=200×200&w=200&h=200' }}
          style={{ position: 'absolute', width: 200, height: 200 }}
        />
      </View>
    );
  }
}

https://github.com/gorangajic/react-native-overflow-bug
Additional Information

React Native version: 0.36.1
Platform: Only Android
Operating System: MacOS

I'm seeing exactly the same, but thanks for finding the backgroundColor: "transparent" fix. That works a treat in the short term!

Related to this: https://github.com/facebook/react-native/issues/3198

Closed because this one is a dupe

Just to note that this worked fine before the update, and it's broken now

@gorangajic I think they know, the FB team are working on a fix that they will opensource soon.


Nuscenes detection errors on validation set

Hello! Thanks for the great work!
Could you please share what errors you get for Nuscenes detection on the validation set? By errors, I mean mATE, mASE, mAOE, mAVE, mAAE.
Thank you!

Thank you for your interest in our project. This repository is no longer actively maintained, so we will be closing this issue. Please refer to the amazing implementation at MMDetection3D. Thank you again!


cleanup: delete unnecessary workflow

What type of PR is this?
/kind cleanup

What this PR does / why we need it:
cleanup: delete unnecessary workflow
Which issue(s) this PR fixes:

Fixes #none
Special notes for your reviewer:
none
Does this PR introduce a user-facing change?

/lgtm


VS Code HTML highlight doesn't know WebC's @-prefixed properties

Perhaps this extension will help: https://github.com/hawkticehurst/webc-vscode. I didn't test highlighting with it because I only ran the language server from the repository in the Helix editor, and it worked well.


[WB-8604] Fix kfp tests to use pytest shards

Fixes WB-8604
Description
Mostly a workaround for the test flake coming from kfp.  There is something going on that appears to not work well when run in parallel tests.
The idea of sharding pytests are:

We should stop adding packages to requirements_dev.txt.  This has bad performance consequences
We have some incompatibilities when running tests in parallel, this allows some more isolation
Sharded tests make it easier to reproduce a failure locally or focus on a class of tests

Testing
These are tests!
Checklist

Name PR "[WB-NNNN][WB-MMMM] Add support for..." similar to entries in CHANGELOG.md
Include reference to internal ticket "Fixes WB-NNNN" (and github issue "Fixes #NNNN" if applicable)

Dang, I'm late to the party :(
Awesome PR! I'd ask splitting the base tests into a few parts while we're at it, but let me just submit another PR on that.


GitHub Topics is BROKEN - Nov 2019 +

Hi there. The functionality of Topics is currently broken.
https://github.com/topics
https://github.com/stars?filter=topics
Add topics to categorize your repository and make it more discoverable.

The restricted search results make Topics completely useless for any practical purposes.
It is frustrating ( and broken ) now because Topics no longer works the way it says it works in the documentation.
Is it a bug ?
Does anyone know what's going on ?
#edit - Topics almost works as long as no more than 8 people use the same tag.
https://github.com/topics/topics-is-broken

https://twitter.com/maxwellterry/status/1192812733630165000

Здравствуйте,могли бы вы перефразировать суть вопроса.

Looks fixed. I'm very happy. Thank you !!!!
https://github.com/topics/javascript
Here are 131,867 public repositories matching this topic...


[FLINK-33529][python] Updated GET_SITE_PACKAGES_SCRIPT to include pur…

What is the purpose of the change
Currently, the PYTHONPATH includes only platlib (lib64/python3.7/site-packages) in Python 3.7. Some of the Python packages, like cloudpickle, are installed in purelib (lib/python3.7/site-packages) instead of platlib, and so the pyflink jobs are failing with the below error. This change is to include both purelib and platlib as part of PYTHONPATH.
No module named 'cloudpickle
[hadoop@ip-1-2-3-4 tmp]$ python --version
Python 3.7.16

[hadoop@ip-172-31-44-103 tmp]$ python -m sysconfig | grep site
	platlib = "/usr/lib64/python3.7/site-packages"
	purelib = "/usr/lib/python3.7/site-packages"

[root@ip-1-2-3-4 container_1699102054926_0016_01_000002]# ls -lrt /mnt1/yarn/usercache/hadoop/appcache/application_1699102054926_0016/python-dist-bdc13f5d-ee1b-454e-b312-a7fc43634616/python-requirements/lib/python3.7/site-packages/ | grep cloudpickle
drwxr-xr-x 3 yarn yarn    110 Nov 13 09:33 cloudpickle
drwxr-xr-x 2 yarn yarn    102 Nov 13 09:33 cloudpickle-2.2.1.dist-info

Brief change log

Updated the variable GET_SITE_PACKAGES_PATH_SCRIPT inside of the file PythonEnvironmentManagerUtils to include purelib (lib/python3.7/site-packages) along with existing platlib (lib64/python3.7/site-packages).

Verifying this change
This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, * ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? no
If yes, how is the feature documented? not applicable

@ColtenP  @dianfu  Please review this patch when you have time. Thanks.

Thanks @dianfu and @ColtenP for the review.


fix: match geography/geometry OIDs correctly

This is probably not a particularly important change, but I happened to notice that geography and geometry got swapped here, so I figured I might offer a drive-by fix.

Great catch, thanks!


Unable to click in fuzzy finder or command menu

If you open the menu, and attempt to click an item, it will actually click through the menu and click whatever is behind it. I noticed this when it opened a file that was in the sidebar.

Looks like a Revery bug where we're not handling the mouse events properly (we're not picking up the cursor in the menu's flatlist region).

I set up a debug visualizer in Revery to show where it 'thinks' we're hovering over... and it's clear it's not the menu. Seems like a bug in our logic there to get the mouse-over-node

It seems like there is a bug in our algorithm that hit-tests the mouse - it's getting the deepest Node in the hierarchy that intersects with the mouse, as opposed to the topmost element that intersects with the mouse.


orcropus-gpageseg: UnboundLocalError: local variable 'gray' referenced before assignment

Current Behavior
If I use the CLI option --gray and no .nrm.png is provided, an UnboundLocalError is thrown.
Possible Solution
In line 380 of ocropus-gpageseg, add one indent level to the checktype test and an error message which complains about the missing grayscale file (since it is a prerequisite for --gray, cf. line 431). Also an update of the CLI option help might be useful.
I would have liked to create a pull request for that one. But it is not possible to fork the same github project twice (https://stackoverflow.com/questions/6675994/is-it-possible-to-fork-a-fork-in-github) and I already forked the fork kraken.

Can you create a PR from a different branch, i.e. something like
git remote add ocropy https://github.com/tmbdev/ocropy.git
git fetch ocropy
git checkout -b ocropy ocropy/master

?

Fixed in #287


Objects passed in to callbacks are typed more precisely

As https://github.com/seatsio/seatsio-types/issues/9 pointed out, we can make the type definitions for objects passed in to callbacks such as objectIcon better.
This PR sets an object type for seats, areas, booths and tables. So instead of having to write this:
objectLabel: (object, _defaultLabel, _extraConfig) => {
    if(object.objectType === 'Seat') {
        let seat = object as Seat
        ...
    }
}

You can now just write:
objectLabel: (object, _defaultLabel, _extraConfig) => {
    if(object.objectType === 'Seat') {
        ... // The compiler knows it's a Seat
    }
}

I also renamed SeatsProps to Seat, TableProps to Table etc.

 Look at issue in seatsio-types ("SelectableObjectProps missing some keys")


Docker cli tries to execute old shell

Docker Kitematic 0.9.5, Mac OS X El Capitan
After executing Docker cli in iTerm 2.1.4 got:
bash: /usr/local/bin/fish: No such file or directory
In history:
bash -c "clear && DOCKER_HOST=tcp://<IP_ADDRESS>:2376 DOCKER_CERT_PATH=/Users/valbudkin/.docker/machine/machines/default DOCKER_TLS_VERIFY=1 /usr/local/bin/fish"
Fish shell was installed previously but now default shell is zsh:
/bin/zsh```

I also reseted all Terminal.app settings, but it didn't help. Where can I look to set shell for Kitematic to my current shell?

Sounds like there are some leftover issues in your bashrc/zshrc/terminal pref.
I would clear those first.

@vabue I am running into the same issue. Did you have any luck?


[BUG][PATTERN] - Pipeline fails due to long cluster name

For the following stages, the cluster name is too long and fails provisioning due to ClusterAutoscaler cluster value character limit (128 characters):
us-west-1-managed-blueprints
us-east-2-managed-blueprints
Suggestion: change the naming to usw1-managed and use2-managed to avoid the problem.

This has been fixed on the patterns repo. Closing the issue.