Support defining enabled and disabled lints in a configuration file

This issue started its life in clippy (https://github.com/rust-lang-nursery/rust-clippy/issues/1313). Once it was realized this should apply to built-in lints as well, it migrated to rust (https://github.com/rust-lang/rust/issues/45832). There @kennytm suggested that it should be Cargo's responsibility to pass the -D/-W/-A flags to rustc.
Motivation
Currently project-wide lint configuration needs to be included in the crate sources. This is okay when the project consists of a single crate, but gets more cumbersome when the project is a workspace with dozen crates.
Being able to define the lints in an external file that will be used when building the crates would have several benefits:

Sharing one configuration file for all the crates in a workspace.
A canonical place to check for lint configuration when contributing to a new project.
An easy way to examine the version history for lint changes.

Proposal

A configuration lints.toml (or [lints] in Cargo.toml?) file that specifies the lints.
The lints can be specified on the workspace level and for individual packages. Anything on the package level will override the workspace setup on per lint basis.
The configuration file is cfg/feature-aware and can specify different lints depending on features. Specifying clippy-lints will result in clippy complaining about unknown lints if clippy isn't used.

Also... unlike what @oli-obk suggested in the rust issue, personally I'd prefer the following format:
[lints]
allow_unused = "allow"
non_snake_case = "allow"

While this is more verbose than allow = [ "allow_unused", "non_snake_case" ], I think the diff benefits and the ability for the user to group logically similar lints together even if some of them are deny and some allow outweighs the increased verbosity.
Also if Cargo/rustc ever support lint configurations, this would be more future proof:
cyclomatic_complexity = { state = "allow", threshold = 30 }

Example configuration
[lints]
allow_unused = "deny"
non_snake_case = "allow"

[lints.'cfg(feature = "clippy")']
cyclomatic_compexity = "deny"

The feature syntax is lifted from Cargo's dependency syntax - at least that was the intention. Personally I'm not a fan of it, but I guess that's a limitation of toml. Don't really have a better proposal for it, given I don't really know what's available int he toml syntax. :<

I am strongly in favor. We should also probably specify that unknown lints should be a warning, not an error, for the purposes of backwards compatibility.

Forgot to mention: I'm also interested in contributing code for the implementation, if there is consensus on what should happen. Also do Cargo changes, such as this, go through the RFC process?

This seems potentially worthy of an RFC, but I could see it going either way. There doesn't seem to be much design space. @alexcrichton can probably say more.

This seems plausible to me! I think it'd be fine to add this to Cargo.toml on an unstable basis (behind a nightly feature) and we can decide to stabilize at a later date.

Do we have a chance for rustc to report where the linter settings are coming from? Given the increasing amount of knobs and switches, it would be very nice to have rustc report that allow_unused was denied and that deny was specified by the workspace's root Cargo.toml or the commandline.
As rustc knows nothing about these, we could introduce a new switch to rustc that specifies the source of the following linter settings (e.g. --LS "/home/myproject/foobar/Cargo.toml" -D ... --LS "/home/myproject/Cargo.toml" -D ...).
Is this a thing?

I'm not sure if these should be in the Cargo.toml, as we many want to be able to specify them globally for a group of projects.

Is this a thing?

rustc already reports whether something was

defined by command line
defined by default settings
defined by code

so we just add another variant for config file there.

I'm really interested in this, too.

Also if Cargo/rustc ever support lint configurations, this would be more future proof:
cyclomatic_complexity = { state = "allow", threshold = 30 }

It could be cyclomatic_complexity = { state = "allow" } from the start, then we would have the option to add further options in a second step.

This Rollup PR from rust demonstrates how rust itself could benefit from a shared lint config, too: https://github.com/rust-lang/rust/pull/52268 (note all the 'deny bare trait object' PRs; and there's a few more)

I'd like to start working on this, unless @phansch or @Rantanen started on this already.
Seems like the lints.toml name is the one I've seen used most, so let's go with that.
As for the syntax, allow_unused = "allow" seems reasonable and more ergonomic than requiring the cyclomatic_complexity = { state = "allow" } syntax.

I'm not sure if these should be in the Cargo.toml, as we many want to be able to specify them globally for a group of projects.

A Cargo.toml file can already be used for a workspace, unless you meant a group of workspaces?

I'd prefer that we centralize this into Cargo.toml rather than adding an additional file, but that can likely be decided in further detail at a later point in time.

The argument against Cargo.toml is that you can have a single lints.toml for multiple projects. Or even hierarchical lints.tomls

@detrumi I didn't start any work on this, and won't have that much time either. From my side, feel free to start :+1:

@oli-obk Right, which is what workspaces are for IMO. I'd prefer to avoid "one more" file in every Rust directory.

That would mean that companies need one enormous workspace for all the crates in their company if they want to have a consistent lint setup. This is the very use case that started the discussion about lint configuration files. A company-wide uniform linting experience. Maybe specializeable for crates, but they can already do that via #![allow(foo)] in their lib.rs. If we leave the door open for importing lint configurations in a dependency-style manner, doing it in Cargo.toml seems fine though.

Why not use .cargo/config here ? This seems like the obvious candidate for a file shared across repositories/workspaces/crates. Plus, one can commit a .cargo/config file per repository in OSS scenarios.

Alright, placing it in Cargo.toml seems like a better place to start then.

That would mean that companies need one enormous workspace for all the crates in their company if they want to have a consistent lint setup.

Hierarchical Cargo.toml files might be a solution to the enormous workspaces, but that's something that can be added later.

I'd like to start working on this, unless @phansch or @Rantanen started on this already.

Feel free to! I have been waiting for some kind of a decision on how to proceed, so haven't done anything for this myself.

@oli-obk, @Mark-Simulacrum: My company has one enormous workspace indeed. And we are highly in need of DRY linting/warnings/etc. configuration with local exceptions (preferably down to the statement-level) So if industrial use cases/productivity are the motivation, perhaps we can survey a bit as for the requirements?

down to the statement-level

that part is no problem, you can configure lints in source code just fine.
And if you have one enormous workspace, then the Cargo.toml solution will work just fine for you I think.

Suppose we settle on configuring this in Cargo.toml, then in a later stage we can design a more general feature, namely supporting Cargo.toml override files. Such override files could e.g. patch sections such as the lints and warnings configuration. We can then circumvent the discussion about the need for a separate configuration file. The name of the section is more important, since compiler warnings and clippy lints may be merged in some form later.

Is this dead currently? For projects with a hierarchical structure and lots of lints this is a fairly vital feature. Hoping to see this gain activity soon!

@marrub-- A more detailed proposal was posted at https://internals.rust-lang.org/t/proposal-cargo-lint-configuration/9135.

I very much don't want to see this go into a separate configuration file. I've worked with C and similar for decades, where warning options live in the build system rather than in source code, and that leads to quite a bit of skew where source code doesn't have the information needed to build.
I definitely think this information should not be in .cargo/config or anywhere that needs separate setup, and it shouldn't be in a workspace's Cargo.toml if that information doesn't get published in a .crate file. I could live with Cargo.toml, though I'd prefer sticking with code (and having a dependency crate that encompasses a pile of options for an include-like mechanism).

The main thing I'm hoping to avoid is the repetition of lints in every crate in a workspace. I don't much care about it being in a config file vs. source code as long as there's some way to inherit/include the list of lints from some source.

Maybe we could come up with a scheme where you can import the lint configuration from another crate? So making it a language feature where you can define a crate that does nothing but set lint flags, and then you have another crate depend on it and import these flags into its own scope.

@joshtriplett: I do not understand your argument. The proposal is not to remove static analysis configuration from Rust source files, but to also support setting this configuration in an external file.
You mention being able to build from source alone, rather than source complemented with packaging metadata. Presently, Rust source code in the open source ecosystem of crates.io often cannot be built from source alone. The configuration in Cargo.toml is rather crucial. I define building from source alone as just using rustc and then input and appropriate output files, across many command lines.

@sanmai-NL I think part of his argument was that some of those configuration files don't end up being published with the crate, especially if you're in a workspace. So having the lints live in a top-level Cargo.toml or something means that it wouldn't be included in individual crate sources, and information required to build the source properly would be missing.
I don't know how often people try to build crates from the source published on crates.io though; I would always go to the original repository to make sure I'm getting the full source code.

@dbeckwith: But even if the configuration isn't being included in the source distribution via crates.io,  builds won't fail because of it. Clippy does not break builds when run as standalone tool. In the past there was a compiler plugin, but I do not see documentation about it in the current README.md. Now suppose there is some possibility that Clippy is used within rustc's compilation pipeline and that the configuration to it is the only way to unbreak this pipeline. Only then, for under those conditions, Clippy could be designed to not accept out-of-source configuration. That would solve the problem.
The use case for this feature request is of course within a context of Clippy being run separately, during a build pipeline (Continuous X).
Also, clippy.toml already exists as a configuration mechanism. So @joshtriplett's concern is not specific to the proposal here.

@sanmai-NL What about #deny rules? If there are any of those, then building with vs. without clippy would provide different results in regards to whether the code will build successfully or not, which is important for repeatability.
I agree though, maybe this point is not relevant to this feature request, and your point about clippy.toml is a good one.

Suppose the scenario @joshtriplett tries to get at happens: the external config hasn't been distributed together with the source code.

If there are Clippy deny rules in the code, these will be enforced as before.
If there are Clippy deny rules in the original external configuration, these will not impede the build, since the external configuration is absent now.

So what @dbeckwith describes isn't a valid failure scenario.
The only valid failure scenario I can think of is the following. There are allow rules that except default deny rules. The allow rules are (only) present in external configuration, which itself is absent.
There are, however, no default deny rules, according to https://rust-lang.github.io/rust-clippy/master/index.html. Only within the clippy::correctness lint group, which isn't enabled by default. So this scenario is currently impossible.
Now let's concede the following conditions: the maintainership of some software solution in Rust has enabled the clippy::correctness lint group, and then made exceptions to that in external configuration. You want to build this solution to a release artifact using the Rust compiler only. Let's also concede that a Clippy compiler plugin is configured in the source code to be run unconditionally. Let's furthermore concede that a release build does not cap lints. Only then, perhaps, we have a valid failure scenario.
I find this wildly far-fetched and at so many steps the maintainers and consumers would be going against best practices, that I find it hard to see @joshtriplett reservation as warranted.
Not to mention, by making one or more simple design decisions we can defuse the scenario.  As I wrote in my previous comment: Clippy could be designed to not accept out-of-source configuration under some conditions, for example when there is Clippy configuration within the source code already.

On March 21, 2019 6:02:09 AM PDT, Sander Maijers<EMAIL_ADDRESS>wrote:

@dbeckwith: But even if the configuration isn't being included in the
source distribution via crates.io,  builds won't fail because of it.
Clippy does not break builds when run as standalone tool. In the past
there was a compiler plugin, but I do not see documentation about it in
the current
README.md.
Now suppose there is some possibility that Clippy is used within
rustc's compilation pipeline and that the configuration to it is the
only way to unbreak this pipeline. Only then, for under those
conditions, Clippy could be designed to not accept out-of-source
configuration. That would solve the problem.
The use case for this feature request is of course within a context of
Clippy being run separately, during a build pipeline (Continuous X).
Also, clippy.toml already
exists
as a configuration mechanism. So @joshtriplett's concern is not
specific to the proposal here.

Note that this isn't just about clippy, it's also about compiler lints.

To clarify something: I can live with lint configuration in the Cargo.toml shipped with a crate (though based on experience with many C packages I feel that will still cause problems). However, lint configuration in a file not shipped in the .crate file will cause problems for distributions. That includes shipping lint configuration in some other .toml file that Cargo doesn't ship, or shipping lint configuration in a configuration file of a workspace, or shipping lint configuration in .cargo/config.

I think it is important that there is support for a separate lints.toml file, even if lint configuration is added to Cargo.toml. This will make it much easier to share common linting standards across multiple projects.

At a minimum, the lint configuration from a workspace needs to be inherited by child crates.
Ideally, it should be possible to create a single lint configuration outside the project and just create a symlink to it within the project itself. This would be tricky to do if configuration was only supported in Cargo.toml.

Ideally, it should be possible to create a single lint configuration outside the project and just create a symlink to it within the project itself.

That is exactly the kind of situation I'd like to avoid.
At a minimum, Cargo would need to understand the mechanism in question well enough to undo it when uploading a .crate file, so that the crate is fully self-contained.

That makes sense. However, there is still a need to share common lint settings across projects. The exact mechanism isn't importan,  but the obvious workaround to use include! in the root of every crate, isn't very good either.

To clarify something: I can live with lint configuration in the Cargo.toml shipped with a crate (though based on experience with many C packages I feel that will still cause problems). However, lint configuration in a file not shipped in the .crate file will cause problems for distributions. That includes shipping lint configuration in some other .toml file that Cargo doesn't ship, or shipping lint configuration in a configuration file of a workspace, or shipping lint configuration in .cargo/config.

Given --cap-lints is used when compiling dependencies, is there any need for the lint config to be part of the published package? It feels like it is really only relevant during development, once published users only care whether the crate compiles or not.
I guess a binary that allows a deny-by-default lint wouldn't compile without it, but distributions should probably be building with --cap-lints specified on the top-level themselves to avoid failing to build with new future-compat lints anyway.

This RFC for deduplicating Cargo workspace information looks relevant to configuring lints in Cargo.toml.

I share @joshtriplett’s concern about self-contained .crate files, but I don’t see the logical implication that lint config must be defined within the packaged source: can the effective lint settings not be included in the .crate file during packaging? One mechanism to do so would be to have a [lint] section in Cargo.toml, which is transformed by the packaging process to include settings that came from other sources at the location where the crate was built. Making this process reproducible is important, so I’d favour configuration within the source repo, for example in the workspace’s Cargo.toml. This is a lot less hassle than requiring the ceremony of remembering to add a bunch of text to lib.rs whenever starting a new crate.

are there any update for lint config?

I'd like to help get this solved if I can.
Having read through the above, it seems like there's a bit of a tension between (a) the view of "lint as developer aid" and (b) that of "lint as compiler flag".
For (a), I don't think the issue of lint config making crates not self-contained is an issue at all, since consumers of the crate aren't it's developers and (as said above) "users only care whether the crate compiles or not". Whereas (b) does seem to imply that lint config needs to be contained within the shipped crate.
In my experience (a) is what's more commonly understood by the idea of "lints". This more naturally leads to a much more liberal configuration scheme where organisations, workspaces, users, etc. can all define and customise the lint scheme to suit themselves during development (perhaps with lint.toml files searched for up the filesystem tree as mentioned above). CI can then enforce a "canonical" set of denied lints and everyone gets on with their day.
The only thing I've noticed in the above discussion which seems to force the (b) view is the idea that there may be "deny by default" lints, thus implying that not shipping lint config could break the build of a crate. The idea of a "deny by default" lint initially feels somewhat oxymoronic to me, but I'm happy to be informed if I'm wrong on that.
For what it's worth, my initial feeling is to forbid the concept of "deny by default" lints and let people have as many lint.toml files in as many places as they'd like.
tl;dr: a sensible config scheme seems to depend on what we think "lint" means exactly (is it the same as a compiler warning? a compilation option? something else?) Please let me know what I can do to move things forward.

The only thing I've noticed in the above discussion which seems to force the (b) view is the idea that there may be "deny by default" lints, thus implying that not shipping lint config could break the build of a crate. The idea of a "deny by default" lint initially feels somewhat oxymoronic to me, but I'm happy to be informed if I'm wrong on that.

Deny by default lints are common for rustc's future incompatibility lints: They move from a gradual progression of allow -> warn -> deny -> hard error. In addition, arithmetic overflow is an example of a deny-by-default lint.
https://doc.rust-lang.org/rustc/lints/listing/deny-by-default.html

Yeah I do not see what the issue with deny by default is. Dependencies are built with lint levels capped, this is no different from lint levels being specified in the source.
Ideally this can be specified at the workspace level too.

I was not aware of that detail! So for dependencies they're probably not at all a concern. I was mostly just expressing they're useful as an intermediate step between "this is totally invalid and doesn't make sense" and "this almost certainly shouldn't actually compile, but I can compile it if you really want me to".
Which, on that note: I think whatever is arrived at should probably offer a good alternative to the current #![deny(warnings)] antipattern.

I'm actually not sure if that antipattern still applies given that cap-lints exists. The patterns book is old and partially maintained, and cap-lints was not always a thing.
Again, if a crate is a dependency there is no way to cause it to fail to compile by tweaking lint levels.
It's not a huge deal if a crate fails to compile under deny(warnings), if you're building the crate itself you probably are developing on it (not using it as a dep). Except perhaps for binary crates.

@workingjubilee: I don’t think it’s an antipattern at all.

One big problem with #![deny(warnings)] is that you have to add it to lib.rs, main.rs, all your example .rs files, otherwise you might not notice warnings in CI, if that's your intent of #![deny(warnings)]. At that point it's way easier to add -D warnings to RUSTFLAGS. Ideally you'd have a central file that cargo reads the lints from, which this issue is about, because then it doesn't just apply to CI but local builds as well.

Am I missing something, or is the discussion of #![deny(warnings)] entirely tangential to this issue?
AFAICT, so long as --lint-caps=allow is used when compiling dependency crates or shipped binary crates (e.g. with cargo install), then a lint config file (e.g. lint.toml) described as above can just be added with no breaking changes. It clearly seems to be a desirable feature.

Yes, it is, as I've pointed out earlier.

Erm, @est31's remark is all that I meant, as effectively I was merely noting it as another desirable, as someone who has in fact had to tediously go through every crate in a large workspace and clean up #![deny(warnings)] (and #![deny(warnings, ...)], #![deny(..., warnings, ...)], and #![deny(..., warnings)]) from each one in order to make it manageable to fix up a crate, and would have preferred to have one line to diff, so I would be very happy about there being an obvious feature for that? ^^;

Oh, I see what you mean. Sorry, I was looking at the "reasons why this is an antipattern" on the patterns repo you linked to and noting they were outdated. Yes, it would definitely be nice to centralize that effort.

I've been playing around with different ways to do this. You can get part of the way there by using rustflags in .cargo/config.toml. The problem is, that doesn't understand the clippy:: lints, since those are only installed in rustc when run through clippy-driver. So, I wonder if we could have clippy-driver set a clippy cfg setting, and then we could add the following to config.toml:
[target.'cfg(clippy)']
rustflags = [
  "-Dclippy::foo",
  "-Aclippy::bar",
]

It's maybe not as pretty as adding lints.toml, but it seems like it'd be a small change that'd get something that works. What do people think? Are there cases I'm missing with this approach?

The problem is, that doesn't understand the clippy:: lints, since those are only installed in rustc when run through clippy-driver.

My understanding of the design of clippy:: was that rustc should ignore them when passed through without clippy, so if it's not doing that that's a bug in rustc.

My understanding of the design of clippy:: was that rustc should ignore them when passed through without clippy, so if it's not doing that that's a bug in rustc.

Hmm, interesting. When I try to specify clippy lints with command line options I get the following:
> rustc -A clippy::imprecise_flops .\src\main.rs
error[E0602]: unknown lint: `clippy::imprecise_flops`
  |
  = note: requested on the command line with `-A clippy::imprecise_flops`

I assumed this was intentional, but it is weird that this behavior is different than with the #[allow(clippy::foo)] attributes.

I'd say it's unintentional

Oh yeah, it seems like it is. It looks like we don't parse out the lint tool name for lints given on the command line argument.
I have a fix for it at https://github.com/eholk/rust/commit/e0c3fdb0ff34f3323f542b5e4ae71aee3350c380. I'm going to clean it up a little more in the morning and then I'll submit a PR for it.

Is there a 3rd party cargo- clippy wrapping crate that fixes this now while we work out a perfect solution to put forward as unstable?

I see someone's solved this: https://crates.io/crates/cargo-lints . Good stuff. Ttfn.

Re-reading everything, it looks like https://github.com/rust-lang/cargo/pull/9684 will be very impactful (as has been previously mentioned) - maybe we should wait till that lands?
Meanwhile, now that the PR ignoring clippy rust flags has landed, the workaround works with a slight change: the clippy feature is named cargo-clippy ( https://github.com/rust-lang/rust-clippy/pull/1057 ).
The following .cargo/config.toml seems to work fine:
[target.'cfg(feature = "cargo-clippy")']
rustflags = [
  "-Dclippy::foo",
  "-Aclippy::bar",
]

Can we use this as a reasonable workaround for now?
(cargo-lints works fine but a built-in method is preferable)

Trying to piece together what the end result might look like...

Lint levels may be specified in a crate's metadata, either in [lints] or lints.toml.
A crate should be able to optionally publish it's lint config to be used by other crates[lib]
publish_lint_config = true

or should it be a crate type? (or maybe a broader crate type like "metadata"?)[lib]
crate_type = "lint-config"

Lint configs from other crates should be import-able[dev-dependencies]
my_lint_config = "*"

[lints]
includes = ["my_lint_config"]
[lints.levels]
"clippy::pedantic" = "warn"

Can we pursue #1 independently? And can we defer the lints.toml idea for now? It seems like [lints] would be a good MVP, and is wanted with or without the option of lints.toml.

Thinking more about lints.toml. It seems like the main concern with it is that it creates too much decoupling of lint config from a crate's metadata. That is, lint config should be considered a component of crate metadata because it influences how/whether it compiles. This is a conflict of interest because people want lint config to be decoupled so that it can be shared between multiple crates. The solution is allow cargo to facilite this sharing through dependencies/workspaces rather than using a symlink or some filesystem-based solution. This is different from rustfmt.toml because formatting has no influence on how a crate is compiled.
We could theoretically still support lints.toml as an "extension" to Cargo.toml, perhaps with something like [lints.external] = true, but I think it's better not to do this for simplicity.

Would a [lints] section be usable at a workspace-level?

I think that's where https://github.com/rust-lang/cargo/issues/8415 comes in.

Setting with [target.'cfg(feature = "cargo-clippy")'] as @gilescope recommended works but it has a very large downside of causing cargo clippy and cargo build to clobber each other's build caches since the rustflags have changed.

@wagenet We've so far worked around that by using [target.'cfg(all())'] rustflags = ...: https://github.com/EmbarkStudios/rust-ecosystem/pull/68#issuecomment-945863477

Would be nice to take inspiration from older ecosystems, like ESLint. JS/TS community has one of the best dev experiences with regards to static analysis, and I believe they "solved" linting.

https://eslint.org/
Config example: https://github.com/facebook/react/blob/4175f05934d3954827c00b7633c1ce8e4e87d227/.eslintrc.js#L35-L123

In the .eslintrc.js file they have a rules object, where the keys are the names of the lints. They allow any string/object/array as value and simply pass this value into the corresponding rule implementation. This way, the config stays unopinionated and does not restrict rule implementations in any way. This also allows to skip the discussion of what is "the best" config layout - let the rule implementors to decide!
Additionally, there are some nice features that reduce friction of creating new lints, and of sharing them with the community:

ESLint allows plugins, the packages which users can install to add new rules. Example: eslint-plugin-react.
The extends section allows reusing existing configs, for example configs used by large, well-known companies, or configs tailored for specific environments (e.g. in Rust, embedded community can have their own lints). These configs can be packaged and installed as well. Example: eslint-config-airbnb

For me, a Rust newcomer with extensive experience in other languages, cargo check/clippy is a huge pain to configure, even though the lints themselves are fantastic.
When I dive into a new ecosystem, I tend to learn its best practices from lints, because they are a dense, summarized form of the essential knowledge, carefully crafted by the experienced community members. I feel like these gurus helping me out and teaching me, while I am writing code. However, sometimes clippy is configured to be to shy, even if I am eager to learn about more strict rules. But then I need to paste a huge blob of attributes in every library,  binary, test and example to enable this knowledge. This is ridiculously bad.
I believe Rust should be making more emphasis on dev experience related to lints to help newcomers.

But then I need to paste a huge blob of attributes in every library, binary, test and example to enable this knowledge. This is ridiculously bad.

I don't see this workaround suggested here, but you can use a cargo alias (in your home directory, maybe) to set a preferred invocation. Here's an example: https://github.com/rust-lang/rust-analyzer/blob/5008e5682159965c6f3b174aed3523c0b5e2fc08/.cargo/config#L6=.

@lnicola Thanks! This is not a bad workaround and would work for CLI usage. Will not work for text editors though, and is of course nowhere near the great dev experience that I believe Rust is  providing in other aspects.

Thinking more about lints.toml. It seems like the main concern with it is that it creates too much decoupling of lint config from a crate's metadata. That is, lint config should be considered a component of crate metadata because it influences how/whether it compiles. This is a conflict of interest because people want lint config to be decoupled so that it can be shared between multiple crates.

We could flatten the lint configs into a single file when publishing the crate. Does that help?

@ivan-aksamentov Note that eslint is in the middle of completely reworking their configuration.
https://github.com/eslint/eslint/issues/13481

@ehaynes99 Interesting, thanks! Not sure what it's prompted by. I am quite happy with the existing ESLint config. But will delay my judgement until something comes up.

Over in https://github.com/rust-lang/rust/issues/54726, someone mentioned the idea of using custom inner attributes to expand to a set of linting rules.
Could this possibly be a complete replacement for this feature? Sharing a lint config across a workspace could then be implemented as a proc-macro that reads a configuration file, be it a company-wide file hosted somewhere or locally within the workspace.
The only downside would be that the proc-macro needs to be included in every crate but that seems acceptable to me for the benefit of implementing this entire idea through an existing feature. Proc-macros can already be published to crates-io so we additionally get the whole "publish and reuse lints from other people" for free.

@thomaseizinger

Sharing a lint config across a workspace could then be implemented as a proc-macro that reads a configuration file

I'd consider this a clever hack. And in fact that's how I learn that macro cannot contain attributes - I tried to write one. It would be a copy-pasting machine that hides the defect. Also it's easy to forget to add the macro to a new workspace package, or accidentally remove it, and then it will not not be properly linted.
Why it was decided that the whole linter config should be in attirubutes? It does not belong there. That's where things went wrong and that's what needs to be fixed IMO.
Linter is a tool. Tools need configs. Clippy is one of the Rust linters. I love it. But why is that Clippy so special it requires my source code to be polluted with it all over the place?
Also you cannot setup the precise options for rules in the attributes, at least currently. i.e. I want cyclomatic complexity 200, instead of default. There is currently no way to do it with attributes, so there is clippy.toml file anyways, but it's almost unused and detached from the real config.

We're not. There's general consensus that we should do this here, there's just not enough work being done on design and implementation.
I'd ask people to limit this kind of decision so that this issue can be used to actually talk about designing said feature. The pointless discussions and "me too" comments do not help and tend to make it more likely that anyone on the teams working on this stuff will mute the thread.

I started writing up a RFC with the MVP @joshtriplett suggests. I never got to finishing it due to limited time. I plan to work on this in the near future though. However, I'm aware about the feature freeze of cargo. But I think we should get the ball rolling with making a community accepted design choice (should it be a config file, included in Cargo.toml, a mix of both, ...?) through an RFC.

if Cargo.toml is chosen it might be a good idea to extend workspace inheritance. It would make sharing lints easier.
If that is the case I think allow = [ "allow_unused", "non_snake_case" ] would be better and make toml parsing easier. Not having to make a field for each lint would be much better overall. Ideally, the Cargo.toml would look like below
# [PROJECT_DIR]/Cargo.toml
[workspace.lints]
allow = [ "allow_unused", "non_snake_case" ]

# [PROGJCT_DIR]/bar/Cargo.toml
[lints]
workspace = true
deny = [ "allow_unused" ]

I don't know if this has been brought up before, but what about something a little more general like Python's pyproject.toml [tool] section from PEP 518? After having worked with Python for a little over a year, I found this rather pleasant to use since it means all tools (that support it) use the same format, in the same file, which helps with uniformity, ease-of-use, and reduces file clutter. Cargo already has [package.metadata] and [workspace.metadata] too which sound pretty similar.

Hey @flip1995, you mentioned you started on an RFC? I'd be more than happy to help, or pickup the work if you've become too busy?

Yes, I started one some time ago, but can't find it anymore. :facepalm: There is this attempt at an RFC: https://hackmd.io/@flip1995/HJteAAPgO But it is really sparse and not at a point where I would continue with it, but rather start fresh.

For anyone looking for a workaround for this issue, I have been using cargo cranky for the past six months, and I'm really liking it: https://github.com/ericseppanen/cargo-cranky

Since #12115 is merged, I'm closing this as resolved.


fix(dojo-bindgen): array length before array items

add array length to calldata before adding the serialized array items

Any test we can add here or in a subsequent PR? :)

It's a bit hard as it would involve doing a full integration test where we would;
katana & migrate -> compile unity code -> run the c# in some way -> use dojo.c -> check if error from katana 😅


Could not login Jenkins with KubeSphere admin account

Recently, we are integrating our ks-devops into KubeSphere, the result is Jenkins endpoint can not with KubeSphere admin account, but can login with random password we generated in advance.
/kind bug

/priority high

I've fix this issue in ks-installer. It works well after I change the securityRealm.type into ldap.
https://github.com/kubesphere-sigs/ks-devops/blob/35fb9f2f48f12b37e64c076cd70a694e359b8ae9/charts/ks-devops/charts/jenkins/values.yaml#L449-L452
Please redeploy ks-installer to take effect.

/close


TabBar not showing on devices with a home button

The TabBar is not showing on devices that have a physical home button such as the iphone SE, 8, etc.

This seems to be related to .replace, if I comment out loadHome() in viewDidLoad() it shows the tabBar. If I navigate to one of my buttons, the tabBar does not show once the replace loads. If I navigate to a page within that view with advance, the TabBar then shows.

Something else i found is that if you rotate the screen, the tabBar shows up.

I was able to find a solution, adding tabBar.invalidateIntrinsicContentSize() to the loadTabs function resolved the issue. I will submit a pull request.


[CU-86871v3nv] Replaces localStorage feature flags with db field

Task linked: CU-86871v3nv Migrate user featureFlag toggles to db user.settings field


Flutter 3.13.6: Incompatible classes were found in dependencies.

When building a simple example with latest Flutter (Channel stable, 3.13.6),
I receive first an message saying to update the minsdkVersion to 21 to build on Android
Once this modification is done, the following error appears
Incompatible classes were found in dependencies. Remove them from the classpath or use '-Xskip-metadata-version-check' to suppress errors
Could somebody tell me how to work around this if already encountered?

Same. Any updage?

can you try updating kotlin version?
ext.kotlin_version = '1.9.10'

same here
after update kotlin version to 1.9.10 app is not launching (activity closing after starting)

Sorry, in may case i have wrong android main package name...
update kotlin version to 1.9.10 help me!

We downgraded the Kotlin version in the plugin from 1.9.0 to 1.7.22
Does this help for this issue? (fix has not been published yet, but you could test with the master branch of mobile_scanner to verify, using https://dart.dev/tools/pub/dependencies#git-packages)

@navaronbracke Thanks for the update comment... This issue is preventing our app from building, but we're using FlutterFlow, so restricted to Kotlin 1.7.10.
I see you downgraded to 1.7.22 — I'm not too familiar with Kotlin/Gradle but am I right in assuming semver applies, so it will still build? (Hopefully! 🤞) Any advice greatly appreciated — thanks.

Yes, I would think so. The main point here is that we are back to Kotlin 1.7.x, the patch version doesn't affect things.

@navaronbracke Thanks 🙏 Any ETA on publishing the release? FlutterFlow doesn't let me import from master branch unfortunately.

@JackWH I will try to get this released this week if possible. I understand that getting these fixes published is a high priority.

The fix for the Kotlin version is available from v3.5.0 onwards.

Hello @1Dimitri
I've sent the details directly to your inbox.
Responding in regards to your flutterflow.io forum post.
Please check your messages or feel free to contact me using the information provided below for further assistance
Email: jack(at)technogiq(dot)com
Skype: live:.cid.a0f06a69cf1c6478
Looking forward to hearing from you.
Regards,
Jack


As a moderator, I can see all cards before revealing all cards

I only added the two in "Needs Work" and the top card in "Kudoz"
This does not happen when viewing the board NOT as a moderator.

This was intentional behavior, see #84
We thought it would make more sense to allow the moderator to see all the cards to delete and sort them before allowing the other users to see them.
Will leave this open for now if you have another suggestion, (maybe split into "Reveal for Just Me" and "Reveal for All" buttons?)


Is http-server is HTTP server or HTTP GET server?

Do you want to request a feature or report a bug?
Feature.
HTTP means not only GET. If so it shall be called static-http-server
If the issue is a bug report, please provide the steps to reproduce it. Please include the actual command causing the issue if applicable.

What did you expect to happen?
What actually happened? Please include the actual error trace and / or stack trace if applicable.

If the issue is a feature request, what is the motivation / use case for it?
Tell us about your environment

http-server version:
Platform:

Other information (related issues, suggestions for a fix, etc):

Renaming a project is not trivial. Besides, static-http-server already exists


Firing an incendiary slug crashes the server in debug mode

Description

Spawning in and firing an incendiary slug from a shotgun causes a hard crash on the debug server. Other shotgun shells work fine.

[FATL] unhandled: Robust.Shared.Utility.DebugAssertException: Exception of type 'Robust.Shared.Utility.DebugAssertException' was thrown.
at Robust.Shared.Utility.DebugTools.Assert(Boolean condition) in C:\...\RMC-14\RobustToolbox\Robust.Shared\Utility\DebugTools.cs:line 37
at Content.Server.Weapons.Ranged.Systems.GunSystem.LinearSpread(Angle start, Angle end, Int32 intervals) in C:\...\RMC-14\Content.Server\Weapons\Ranged\Systems\GunSystem.cs:line 338
at Content.Server.Weapons.Ranged.Systems.GunSystem.g__CreateAndFireProjectiles|28_0(EntityUid ammoEnt, AmmoComponent ammoComp, <>c__DisplayClass28_0&) in C:\...\RMC-14\Content.Server\Weapons\Ranged\Systems\GunSystem.cs:line 285
at Content.Server.Weapons.Ranged.Systems.GunSystem.Shoot(EntityUid gunUid, GunComponent gun, List1 ammo, EntityCoordinates fromCoordinates, EntityCoordinates toCoordinates, Boolean& userImpulse, Nullable1 user, Boolean throwItems) in C:\...\RMC-14\Content.Server\Weapons\Ranged\Systems\GunSystem.cs:line 133
...
C:\...\RMC-14\bin\Content.Server\Content.Server.exe (process 12268) exited with code -532462766 (0xe0434352).

Reproduction

Start a debug server, spawn in a box of incendiary slugs, load into a shotgun, and fire.
Screenshots

https://github.com/user-attachments/assets/a803283d-bc39-4f2f-bcd9-faf1da226b53
Additional context

Running on local debug server, production doesn't cause a crash.

This is because it has spread with a count of 1. Like the normal slug the fix is just to remove projectileSpread. Not really important since incendiary slugs aren't implemented yet.


Issue reporter: icon for duplicate issues are not aligned

re #44457

Maybe we should align the left border of icons instead of center.

I think there are still issues:

the default height should be good enough to not cut issues in half
the summary of each issue should be aligned at the same vertical spot
as such, I would make the open/closed badge equal width


[Image Update] Helm to 3.8.2

This is a request to update the helm version installed with cloudshell.   With Kubernetes 1.22 helm 3.4 which is installed right now does not support some of the new API's so customers cannot update their helm releases.   This is needed du to API deprecations in 1.22
https://github.com/helm/helm/releases/tag/v3.8.2
3.8 is the version that adds support for 1.22 Updating to Kubernetes 1.22.4 packages https://github.com/helm/helm/commit/c2da47e22bde420602b46d9e6b6e3152c63f7a90 (Matt Farina)
AB#14503410

Currently the following error message is seen when updating helm chart for 1.22 with current helm version is cloudshell.
"Error: UPGRADE FAILED: current release manifest contains removed kubernetes api(s) for this kubernetes version and it is therefore unable to build the kubernetes objects for performing the diff. error from kubernetes: [unable to recognize "": no matches for kind "ClusterRole" in version "rbac.authorization.k8s.io/v1beta1", unable to recognize "": no matches for kind "ClusterRoleBinding" in version "rbac.authorization.k8s.io/v1beta1", unable to recognize "": no matches for kind "Deployment" in version "apps/v1beta2"]"

@jamote : Can you help us understand what command you tried that gave the above error and what is the expected result? So that we can add the appropriate test in the command list.

Running helm version shows that the version now installed in Cloud Shell is 3.9.0.


Merging changes from Master into Live

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

biztalk/core/distinguished-fields-in-disassembler-pipeline-components.md
:white_check_mark:Succeeded
View

biztalk/core/feature-pack-add-build-release-definitions.md
:white_check_mark:Succeeded
View

biztalk/core/how-to-import-bpel4ws.md
:white_check_mark:Succeeded
View

biztalk/core/walkthrough-testing-the-policy.md
:white_check_mark:Succeeded
View

biztalk/esb-toolkit/the-resolver-and-adapter-provider-framework.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Localization issue

Greetings.
I find there is something wrong with the localization script, when I add it to my demo, the renderers remain English while others are okay, I think this code's causing this:
opts = $.extend(true, {}, localeDefaults, $.extend({}, defaults, inputOpts))
Because we wanna enable the plugins, so these codes are used according to the samples:
var renderers = $.extend(
$.pivotUtilities.renderers,
$.pivotUtilities.c3_renderers,
$.pivotUtilities.d3_renderers,
$.pivotUtilities.export_renderers
);
$.getJSON("/static/mps.json", function (mps) {
$("#div").pivotUI(
mps,
{
renderers: renderers
},
false,
"fr"
);
});
This variable renderers is that "inputOpts" above which is not localized, but "defaults" is localized.
I find a way to solve this issue, you DO NOT need to pass the renderers param at all, c3/d3 renders are added automatically, ALSO "Horizontal Bar Chart" and "Horizontal Stacked Bar Chart" are missing in those localization scripts.

Yes, if you override the renderers you get the ones you're overriding with, rather than the ones from the locale file. The fr locale file is indeed missing some renderers, as are most locale files. My general recommendation is that you tweak the locale file to your liking :)


Update --allContigs to --allReferences.

Also updated terminology regarding data with non-variant segments.

Coverage decreased (-0.06%) to 31.58% when pulling c2ae637fe3741fff00f025131928c0d7e7d6fc6c on deflaux:master into 3b9c4310d1883fdeed5c763a2aaea925544352cb on googlegenomics:master.


Shadow classes

I think shadow classes would be nice, could you include them in next versions?

Of course. I will add them in next version.


SRIOV IP and interface lost inside container after upgrade from 2.5 to 2.6

We upgraded from sriov-CNI v2.5 to v2.6, and device-plugin from v3.3.1 to v3.3.2. And multus from v3.6 to v3.7.2. We are NOT using Openshift operator. We have deployed the daemonsets manually using our own operator.
After upgrade, the SRIOV Pods lost the IP and net1 interface from within. But Pod IP annotation still shows the IP under "kubectl describe", "ip link" even shows the VF assigned MAC/vlan still, and device plugin still reports the resources allocated on the node. All the daemonsets are running fine.
New Pods created after get an IP configured fine, it is just pre-existing Pods that lost connectivity and net1 is lost in the container.
The Pods don't show as recreated - their Running and start time is older than the recreations of Multus/SRIOV-cni/device plugin.
Also, not seen for Calico or macvlan Pods. Our macvlan network also uses same version of whereabouts. Seems like an issue specific to SRIOV.

Why are pre-existing IPs/net1 lost inside the container during upgrade?
Checked for logs but the DS containers for multus + sriov-cni don't show much, my guess since they don't do the actual work. Is there a way to get better logs?

/cc @wizhaoredhat

False alarm! We have another service that configures the VFs and drivers. The VF driver was getting reconfigured during upgrade.
Just wondering FYI by what mechanism does reconfiguring the VF driver, to even the same one, cause the net1 to disappear from container?
The process for configuring VF driver for us is:

write PCI addr of existing VF to /sys/bus/pci/drivers/<old_drivername>/unbind
write name of new driver to /sys/class/net//device//driver_override
write PCI address of existing VF to  /sys/bus/drivers/<new_drivername>/bind

We are not changing the number of VFs and the driver is staying the same. Any reason why this may hapen?


Jupyter book: Publish

I think we may want to publish our Jupyter book online once it is finalized for milestone 2.
Opening an issue as a reminder for us.
Instructions here: https://jupyterbook.org/start/publish.html

Perhaps either @nicovandenhooff or @arijc76 can submit to Canvas this week? As submitter you can also:

Publish Jupyter book
Check whether we missed out anything
Release 0.02

Sure @ytz  - I don't mind submitting this week, and then @arijc76 can submit next week if that works?


fix redirect loop on password expiration warning

Enabling LPPE causes a redirect loop. This is due to the execution parameter not being URL encoded causing it to decode improperly when it includes + characters. These get decoded to spaces by the web server before it gets passed to the application.

:+1:
Thank you! I assume you are on 4.1 now and this should be backported for patch releases?

As far as I can tell this affects all of 4.x. I'm on 4.1 and I checked HEAD. Based on a couple posts on cas-users, it's in 4.0.x as well.

Cool. We can backport.


IndShockConsumerType.calc_jacobian() changes cFunc_terminal_

The calc_jacobian method improperly accesses and changes cFunc_terminal_, which is supposed to be a class object. I'm reworking things so that cFunc_terminal_ won't exist at all in the near future, but instances of a class shouldn't be changing objects defined at the class level. There is a way to do what calc_jacobian wants to do, but it went about it the wrong way.
This might be related to another issue we ran into lately, with a mysteriously needed duplicative call to update_solution_terminal() in order to pass tests for calc_Jacobian.

@wdu9 @Mv77 this might be relevant to you

I mean sure, its hacky.
But @wdu9 did it to get hark to do something it was not meant to do. It would be really annoying to have had to define a new class to do it properly.
The way I did it when I needed to do the same in my own branch was to add an optional extra argument to solve which would be a solution to serve as the start of backward induction. It makes it ignore the default terminal solution.
Should I make a PR with that change?

No, don't make any changes. There's another change that can be made only to
the Jacobian stuff. I'll tackle it shortly.
The gist is to overwrite the local terminal cFunc, not the class-based
one.
On Fri, Apr 26, 2024 at 1:48 PM Mateo Velásquez-Giraldo <
@.***> wrote:

I mean sure, its hacky.
But @wdu9 https://github.com/wdu9 did it to get hark to do something it
was not meant to do. It would be really annoying to have had to define a
new class to do it properly.
The way I did it when I needed to do the same in my own branch was to add
an optional extra argument to solve which would be a solution to serve as
the start of backward induction. It makes it ignore the default terminal
solution.
Should I make a PR with that change?
—
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/issues/1421#issuecomment-2079824987,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADKRAFMFCJ3PALVUWCP423DY7KHPRAVCNFSM6AAAAABG3BRI2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZZHAZDIOJYG4
.
You are receiving this because you were assigned.Message ID:
@.***>


Ability to set the Mermaid securityLevel configuration property

Some Mermaid elements (such as sequence diagram menus) require the library be configured using a non-default securityLevel. It would be great to have a means of setting such values from Blazor, perhaps via an optionally set MermaidDiagram.SecurityLevel property.

Fixed by PR #11.


Revise snapshot feature copy

There's a thread (make sure to read this) in a dev PR, related to the copy used in the snapshot feature, that has gotten somewhat long, that I'd like to hereby extract from that PR and turn into a separate discussions.
I suggest we resolve this here and in design first. Once we're happy, we can then create a new PR with those tweaks.
I'll keep this description short. I still need to catch up with the latest (longer) comment and will do so in a reply. But feel free to take it away.

Quoting myself below, short-circuited with my view that current copy is not egregious in any way, and can be retained in the interest of time.

"Load snapshot" screen that gives more detail about how it works.

This screen can omit mention of transactions "The snapshot allows you to start using the application more quickly. Once loaded, it will be automatically verified in the background. Learn more" instead of "You can start using the application more quickly by loading a recent transaction snapshot. It will be automatically verified in the background."

"Snapshot loaded" screen state that informs people what was imported, what to keep in mind and what will happen next (this is the screen that we are talking about in this thread)
I'd suggest something like "The loaded snapshot contains data up to [some date]. The initial download will continue now. > The snapshot is verified in the background." instead of "It contains transactions up to September 10, 2023. Newer transactions still need to be downloaded. The data will be verified in the background."


TypeScript compiler failed with exit code 1

npm run start.android or npm run start.ios
TypeScript compiler failed with exit code 1
Sending exception report (press Ctrl+C to stop).........
npm ERR! Darwin 16.1.0
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "run" "start.android"
npm ERR! node v7.1.0
npm ERR! npm  v3.10.9
npm ERR! file sh
npm ERR! code ELIFECYCLE
npm ERR! errno ENOENT
npm ERR! syscall spawn
npm ERR<EMAIL_ADDRESS>start.android: cd nativescript && tns emulate android
npm ERR! spawn ENOENT
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>start.android script 'cd nativescript && tns emulate android'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the basic-web-mobile package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     cd nativescript && tns emulate android
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs basic-web-mobile
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls basic-web-mobile
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     /Users/chengzheng/czpro/angular-starter/npm-debug.log

I just updated the repo to the latest Angular. Please give it a try...took me a few times to run the app on Genymotion but it did eventually work.

After rebase your commit, all is ok, thanks!


Updating changelog, stealing Ben's change to get env variables from a…

… single kv var with a JSON value.

[ ] The purpose of this PR is explained in this or a referenced issue.
[ ] The PR does not update generated files.

These files are managed by the codegen framework at Azure/autorest.go.

[ ] Tests are included and/or updated for code changes.
[ ] Updates to module CHANGELOG.md are included.
[ ] MIT license headers are included in each file.

/azp run go - azopenai

/azp run go - azopenai

/azp run go - azopenai

/azp run go - azopenai

@RickWinter , adding in a contributors guide, similar to what we talked about the other day, to make it easier for people to develop with the package. It's a start - let me know what you think.


Minor tweaks to remove unused package

I'd like to try fly/example, but an error was displayed when I run npm i:
npm ERR! Darwin 14.4.0
npm ERR! argv "node" "/Users/watilde/.nodebrew/current/bin/npm" "i"
npm ERR! node v0.12.0
npm ERR! npm  v3.0.0

npm ERR! No compatible version found: 0.0.1
npm ERR! Valid install targets:
npm ERR! ["0.0.3"]
npm ERR!
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR!     <https://github.com/npm/npm/issues>

npm ERR! Please include the following file with any support request:

This patch for fixing this error. Thanks!

The latest commit on master includes this, @bucaran can we get a new version published ?

Done0.0.4

Wow! Thanks as always.

@bucaran Could you please exec npm version patch && npm publish this? Currently it seems to be still error and publishing version is v0.0.1 on the npm registry: https://www.npmjs.com/package/fly-uglify

@watilde Done. The plugin will get simpler with a small tweak to the plugin API in 0.0.5, basically the Fly.prototype.filter function will let you add plugins by name (which let us check whether the plugin exists or not and throw an error if it does) and it's also 1 LOC less.

@bucaran Sounds so nice! Thanks amigo :smiley_cat:

write plugins 2~3 LOC less.


fix(bgmv): write shared_memory y_warpsize only when threadIdx.x == 0

should add threadIdx.x == 0, when you want to write y_warpsize. Otherwise it will lead the wrong answer.

thanks for replying and offer the other fix! i get it.


[feature] AzureResourceManagerTemplateDeployment@3 - need dry-run option (what-if)

Note
feature requests
For a list:

AzureResourceManagerTemplateDeployment@3

Required Information
need dry-run option (what-if) when deploy ARM template
Something like this:
if ${dryRun} ; then
  AZCLI="az deployment group what-if"
else
  AZCLI="az deployment group"
fi

Question, Bug, or Feature?
Type: Feature
Enter Task Name: here
list here (V# not needed):
https://github.com/microsoft/azure-pipelines-tasks/tree/master/Tasks/AzureResourceManagerTemplateDeploymentV3
Environment

Server - Azure Pipelines or TFS on-premises?

Azure Pipelines
Not bug or issue, new feature requests only

Agent - Hosted or Private:

devops.azure.com
Not bug or issue, new feature requests only
Issue Description
Not bug or issue, new feature requests only
I currently workaround it with AzureCLI@2

Seems there is an option called Validation only, looks like the what-if (dry-run) feature. Let me test it.

Another feature is missed in this task:

workingDirectory

With that, I can nominate the working directory, where not always put the templates under root directory.

This would be very useful

This would be quite helpful. Not sure if there's a plan to release this feature? Thanks.


DropdownButton hint

If the DropdownButton's value is null and a hint widget is provided, then the hint is displayed where the value would ordinarily appear.
The width of the button and the menu are defined by the widest item and the width of the hint.
Fixes #7095


Add feature show cores M1 Ultra

I just want to change its version and README file before you upgrade the pip package


MWPW-158389: aem client updates for content-navigation wc

This PR contains aem.js and related logic update to support
content-navigation web component in M@S studio.
Also, Milo spectrum build logic is updated to make all the transitive imports relative instead of absolute.
This change is needed in order to test better merch-card with sp-button for CCD use cases.
By this occasion, I also bumped the spectrum version to latest stable.
Resolves: MWPW-158389
Test URLs:

Before: https://main--milo--adobecom.hlx.page/drafts/ilyas/merch-card?martech=off
After: https://content-navigation--milo--adobecom.hlx.page/drafts/ilyas/merch-card?martech=off

CC Pages:

https://main--cc--adobecom.hlx.live/products/catalog?milolibs=content-navigation
https://main--cc--adobecom.hlx.live/creativecloud?milolibs=content-navigation

Performance on the catalog page seems to be slightly positively impacted:


Access to Development SAS servers

As discussed during a meeting, we would like to get access to a development instance of a SAS server from a SAS provider/s.
This process might take some time according to Joey.

@jpad-freedomfi
Could you please paste here the URL to the dev/prod SAS server for which we have the certs?

@xbend https://spectrum-connect.federatedwireless.com/v1.2/


VSI submission: redirect terminal input through socket (1.0.2)

Same as #1575, but for 1.0.2

I screwed up.  Redoing


changing descriptor of a recovered software wallet forgets the seed and changes to watching only wallet

Create a new wallet
generate seed phrase
choose a non-standard derivation path (m/844'/0'/0')
import the keystore
copy the descriptor
Create a new wallet to recover the descriptor into
New or imported software wallet
enter seed phrase
import the keystore using the default derivation path
Paste the correct descriptor that uses a non-standard derivation path of m/844'/0'/0'
wallet changes to a watching only wallet and forgets the seed

I would expect sparrow wallet to look at the derivation path and use the xpriv it has and see if it computes the same xpub. If it computes the same xpub, then it should stay a software wallet and not switch to a watching only wallet.
This issue coupled with https://github.com/sparrowwallet/sparrow/issues/1352 make it hard to recover a wallet with a custom derivation path because both approaches don't work the way I would expect.

This issue coupled with https://github.com/sparrowwallet/sparrow/issues/1352 make it hard to recover a wallet

I would argue that both #1352 and this issue violate the principle of doing what the user has asked, and instead try to be 'clever', which has both pros and cons. Does it really make it 'hard to recover a wallet'? There is no good reason for normal users to be using non-standard derivation paths in the first place.

If the derivation path in the descriptor is not used when importing a software wallet, but instead a different derivation path is substituted in place of it, what do we have the descriptor for at all? It seems to me that if a descriptor completely defines a wallet, the user should just need to copy paste (or scan) the descriptor and then type (or scan) the seed (or type (or scan) the seed and then copy paste (or scan) the descriptor) and then get the wallet. The way it is now, the user has to keep overriding the default derivation path to match their custom descriptor. If someone doesn't know anything about derivation paths, they aren't going to know they have to watch out for sparrow wallet ignoring the derivation path in the descriptor.

Also, if someone doesn't have a custom derivation path, they likely won't have a descriptor saved at all and they will try to use the defaults for everything and then they won't encounter this issue or https://github.com/sparrowwallet/sparrow/issues/1352.

Implemented in 10a79609. Sparrow will now keep any existing seeds with matching fingerprints when changing a wallet's output descriptor, rederiving the xpub if necessary.

Tested in version 1.8.5, this is working good as expected!


upgrade PostgreSQL kind, make cloud_name mutable

Upgrades PostgreSQL kind with generated user config
Upgrades PostgreSQL controller with generic service controller
CloudName set mutable

CloudName has been mistakenly set immutable in prev PR, not released yet, no changelog need.

Tests https://github.com/aiven/aiven-operator/actions/runs/4017576690


[FLOC-3823] Parametrize number of benchmark samples to take

Allow the number of benchmarking samples to be provided as a command line parameter, rather than fixed at 3.
A particular use case is to help with generating benchmarks that are specified as meeting a limit in X% of cases. Running 100 samples can generate results to easily check such benchmarks.

:question: The code all looks fine, but there aren't any tests that the parameter is threaded
through correctly. Would it be possible to test that at some level, even if it's not right
from the command line?
@jml: mentor review please.
Thanks,
James

:+1: on mentor review.

Also, thanks @jongiddy for so consistently updating the prose docs.


Add support for static non-conforming P4estMeshes (no AMR)

Fifth point of #584.
This is basically an intermediate PR while I am nearly done with AMR. This makes the big AMR PR easier to review (hopefully).
I don't have any tests for non-conforming meshes here, but I can assure you that it works.
Tests will be added with AMR.

I'd also recommend to have at least one test that exercises the new capabilities before proceeding, in order to be able to refactor the AMR without fear of destroying earlier verification/validation tests.

The only feature implemented is simulation on non-conforming meshes. If this breaks, AMR will break as well, so the AMR tests in the next PR will definitely fail.

If this breaks, AMR will break as well, so the AMR tests in the next PR will definitely fail.

Yes, but we definitely want at least some tests with refinement but without AMR, to be able to distinguish AMR errors from general Mortar errors.

You're right, good point!

Since you directly use P4est from the elixirs now, you also need a [deps] and [compat] entry in test/Project.toml. Please also add a comment to the p4est mortar data structures as discussed.

If you prefix all stuff related to p4est by Trixi., you can avoid using P4est and adding it to the list of dependencies.

Some p4est tests are failing, @efaulhaber


Additional storage backends

Opening this issue to keep track of other related issues.

[x] Badger KV (memory/disk) as build-in option https://github.com/jaegertracing/jaeger/pull/760
[x] ScyllaDB https://github.com/jaegertracing/jaeger/issues/197 (available)
[x] InfluxDB via grpc-plugin (for v1 and v2 and iOx) https://github.com/jaegertracing/jaeger/issues/272 (available)
[x] Couchbase via grpc-plugin https://github.com/jaegertracing/jaeger/issues/1575 (available)
[x] OpenSearch https://github.com/jaegertracing/jaeger/issues/3044
[x] ClickHouse https://github.com/jaegertracing/jaeger/issues/1438
[x] PostgreSQL https://github.com/jaegertracing/jaeger/issues/1895
[x] Alibaba Cloud Log Service https://github.com/jaegertracing/jaeger/issues/3172
[x] RediSearch https://github.com/nicolastakashi/jaeger-redisearch
[x] Amazon S3 Google Cloud Storage(GCS) and Microsoft Azure Blob Storage support  https://github.com/jaegertracing/jaeger/issues/2633
[x] ConsmosDB https://github.com/jaegertracing/jaeger/issues/1667
[ ] MySQL https://github.com/jaegertracing/jaeger/issues/1944
[x] Humio https://github.com/jaegertracing/jaeger/issues/3005
[x] Quickwit https://github.com/jaegertracing/jaeger/issues/4362
[x] YugabyteDB https://github.com/jaegertracing/jaeger/pull/4220
[ ] Azure Data Explorer (Kusto) https://github.com/jaegertracing/jaeger/issues/4640
[ ] MongoDB https://github.com/jaegertracing/jaeger/issues/4712
[ ] ❌ Amazon DynamoDB https://github.com/jaegertracing/jaeger/issues/421
[ ] ❌ BigTable https://github.com/jaegertracing/jaeger/issues/1208
[ ] ❌ Elasticsearch APM data format https://github.com/jaegertracing/jaeger/issues/1365
[ ] ❌ Netflix Dynomite https://github.com/jaegertracing/jaeger/issues/331
[x] deprecated PostgreSQL with Promscale

Relevant issue: plugin support #422 (done).

Since I work with PostgreSQL, I sure wouldn't complain. But honestly I'm not sure a SQL db is an optimal store for largely free-form metrics of this nature. PostgreSQL at least offers the jsonb type. If you're trying to do this in a vendor neutral way you'll land up with your own json blobs, or doing EAV, and both of those are terrible. ANSI SQL is a poor fit for variable-structured or key/value form data and you'll need some vendor extensions to get usable performance.
But you inevitably land up with someone putting an ORM on top to "abstract" the DB. Then the ORM performs terribly, gobbles memory and everyone says "the SQL backend is slow, use  instead".

Related issue to this one is https://github.com/jaegertracing/jaeger/issues/551. Upvote if you are interested in it.

New related issue-
Files - https://github.com/jaegertracing/jaeger/issues/894

We are looking at using BigQuery as a storage layer. Presumably this could work with a SQL storage option.  SQL can be a generic way to deal with columnar data stores in a generic way. I would complain about a BigQuery specific solution, but I think there is a place for generic SQL interface beyond RDBs.

Our model is sufficiently simple to warrant looking into using an ORM to support a large number of backends. I'll take a look at what's available.

Giving my two cents.. an ANSI SQL could work for small workloads, so may be useful for lower-throughput applications that still want to benefit from this tool.
I will also throw out there that Timescale (a Postgres extension) may be a good fit for the required high write throughput.

Clickhouse are SQL high performance storage very efficient for log and trace storage and whold be perfect storage alternative to cassandra original one...
they are near to the CQL (sql like query language)... they use an SQL like language to...
https://clickhouse.yandex/

I just thought that I'd drop something here to say that there is also support for using Couchbase as a storage backend (via the grpc plugin), currently at  https://github.com/chvck/couchbase-jaeger-storage-plugin. Will likely move to the couchbase-labs organisation in time.

Has someone started to work on Azure CosmosDB integration? It has support for Cassandra API, but I couldn't manage to make it work...

I just created an issue proposing Chronowave as storage backend. https://github.com/jaegertracing/jaeger/issues/2534

What about ClickHouse? Clickhouse is very cool

What about ClickHouse? Clickhouse is very cool

It's already linked in the issue's description, but here's the tracking issue for it: #1438

What about Apache Solr?

What about Apache Solr?

With the recent changes to ElasticSearch licensing, this just because SUPER important.

With the recent changes to ElasticSearch licensing, this just because SUPER important.

The ES changes do look worrying, but not sure this justifies supporting Solr. It does help the case of advancing with some other storage.

The ES changes do look worrying, but not sure this justifies supporting Solr. It does help the case of advancing with some other storage.

AWS announced an Apache-2 licensed fork of ES, logz.io also said something similar (could be the same effort). So I don't think there's reason to panic.
I don't think Elastic changed the terms for the Go driver which we started using in OTEL-based collector, but we'd need to watch for that.

AWS announced an Apache-2 licensed fork of ES, logz.io also said something similar (could be the same effort). So I don't think there's reason to panic.
I don't think Elastic changed the terms for the Go driver which we started using in OTEL-based collector, but we'd need to watch for that.

So I don't think there's reason to panic.

Absolutely, especially because they can't change the license for something that was released already. So, folks currently using ES don't have a reason to change immediately. If they need to update for some reason, like due to a security problem or general bug fix, then it might become problematic.
While I appreciate the work that logz.io is doing in this front, having multiple sources of ES doesn't help us in supporting our users. On day 1, they'll all be compatible among each other, but each fork will tend to follow its own path over time. Meaning: we'd need to decide which one we'll be "officially" supporting.

So I don't think there's reason to panic.

Absolutely, especially because they can't change the license for something that was released already. So, folks currently using ES don't have a reason to change immediately. If they need to update for some reason, like due to a security problem or general bug fix, then it might become problematic.
While I appreciate the work that logz.io is doing in this front, having multiple sources of ES doesn't help us in supporting our users. On day 1, they'll all be compatible among each other, but each fork will tend to follow its own path over time. Meaning: we'd need to decide which one we'll be "officially" supporting.

We are working with several organizations including AWS on an open source version of ES and Kibana which will be Apache licensed and hopefully part of the ASF. I will know more in the coming days.
I've had a hard time getting RedHat engaged (they have canceled twice now) so if you can help with that @jpkrohling then we'd love it :)
Anyone interested in contributing or taking part in the community is welcome. I am collecting info here to start: https://docs.google.com/forms/d/e/1FAIpQLSfykAk4Bhc-dhjR0AXFP7T2oFmsLUxONbD6NwmgMz4usXSGkw/viewform?usp=sf_link

We are working with several organizations including AWS on an open source version of ES and Kibana which will be Apache licensed and hopefully part of the ASF. I will know more in the coming days.
I've had a hard time getting RedHat engaged (they have canceled twice now) so if you can help with that @jpkrohling then we'd love it :)
Anyone interested in contributing or taking part in the community is welcome. I am collecting info here to start: https://docs.google.com/forms/d/e/1FAIpQLSfykAk4Bhc-dhjR0AXFP7T2oFmsLUxONbD6NwmgMz4usXSGkw/viewform?usp=sf_link

This is the only issue that is not closed. #2633 is closed so i am announcing my work to support s3 for jaeger as a plugin. We needed a cheap way to store data and elasticsearch is expensive for us (whether managed or self-managed)
I took the work done by the amazing team at Grafana for their loki code and use that to write an s3 plugin. It's still a WIP and it stores indexes locally and syncs chunks of data on s3. (I am seeing indexes being synced as well).
Data stored is in boltdb format and shipped to s3 via cortex. (i am leveraging on loki's codebase i am not repeating doing other people's work)
More info here: https://grafana.com/docs/loki/latest/operations/storage/boltdb-shipper/
jaeger-s3 code: https://github.com/muhammadn/jaeger-s3/tree/develop
Also you will need my fork of jaeger, which is a small change for the file flag at https://github.com/muhammadn/jaeger-s3/tree/develop
Contributions are welcomed.

Interesting idea, good luck with the work @muhammadn. Remember, you'll have to figure out how to support querying for the data. My understanding of loki is that you can't do a free text search easily since the data is not all indexed. How will you support the querying of data with this new storage support?

Thanks @jkowall ! Conversations like this is what motivates me. 🙌.
I've managed to pull out the data from s3 through cortex by querying it using promql (basically logql which is based on promql) - You're right that the data indexed only are the time and labels and i can make a search using the labels.

But i am thinking if it's better to go to Grafana's Tempo as i found out about it. But that's a discussion i would make in Tempo's project.

The creator of Tempo @joe-elliott is a maintainer here at Jaeger and is also an engineer with Grafana Labs. We had this discussion, but right now Tempo cannot support the types of queries the Jaeger UI does today. I know that may change, at which point Tempo would be a good Jaeger backend, but today it cannot do everything necessary.
This is the compromise with something that doesn't do full text indexing versus selective queries or allowing queries based on a specific trace or short timeframe. The cost benefit of using non-indexing technologies are there, but flexibility is not the same.

@jkowall I've stabilised the code without any crashes now and I can query/see the data from Jaeger UI. 🎉  So moving forward i will test it out on production (using k8s) and see how it goes from then on. Thanks @jkowall  for your answers! 🙌  Also thanks to @yurishkuro for adding plugin support as without it, it would not be possible for me to write the code for s3 support.
Discussions on jaeger-s3 plugin will be on my repo, thanks all!

Cool! Nice job @muhammadn I'm curious how the performance is with a search using S3 in that manner. Are you planning on deploying or using this setup?

@muhammadn I re-opened #2633 and linked your repo at the top. Suggest moving discussions/updates there.

@Xitric and I are working in on a storage backend for Humio using the grpc plugin. The repository can currently be found at https://github.com/em135/humio-jaeger-plugin. I have opened an issue for this: #3005

If S3 is supported, I would suggest to support GCS as well, which is also an objects-storage for all Google Cloud users. For our use-case that would be tremendous helpful!

@galan it does actually, despite the name is jaeger-s3, i had already added support for GCS (and Azure Storage) for quite some time but i have not tested it.
Maybe you can go to https://github.com/muhammadn/jaeger-s3 to try it out.
Related code to GCS:
https://github.com/muhammadn/jaeger-s3/blob/main/config/config.go#L26
https://github.com/muhammadn/jaeger-s3/blob/main/s3store/store.go#L50
All you need is to modify the configuration for jaeger-s3 to this:
https://grafana.com/docs/loki/latest/operations/storage/boltdb-shipper/
I will update the documentation to jaeger-s3 include GCS and Azure as well. (and probably change the project name entirely)
Do tell me if you need help. But i think we can move this discussion to  #2633

@jpkrohling  The Alibaba cloud log service has supported the jaeger, and here are the gifs of the plugin.  Link: https://github.com/qiansheng91/jaeger-sls#quick-start

Can i use other jaeger collector as backend for my jaeger collector?

Jaeger collector cannot send data (e.g. over gRPC) to other jaeger collector. However this capability is supported with OTEL collector.

@yurishkuro Would highly recommend to add Azure Table Storage as a backend storage option as well.

@yurishkuro Could you please add PostgreSQL with Promscale into the list.? Now Promscale is Jaeger storage complaint too :) Thanks.

@yurishkuro could you please add RediSearch to the list? I've worked on a GRPC Plugin to Store Traces on Redis Search and this is close to the first release, I'm just adding a few performance tests.
https://github.com/nicolastakashi/jaeger-redisearch

Zinc https://github.com/zinclabs/zinc

i use jaeger with timescaledb in kubernetes
{"level":"info","ts":1677823818.9793034,"caller":"querysvc/query_service.go:137","msg":"Archive storage not created","reason":"archive storage not supported"}
i use this configurations
spec:
containers:
- env:
- name: GRPC_STORAGE_SERVER
value: promscale:9202
- name: SPAN_STORAGE_TYPE
value: grpc-plugin
image: jaegertracing/jaeger-query:1.30
name: jaeger
ports:
- containerPort: 16685
- containerPort: 16686
restartPolicy: Always
the problem getting can anyone give solution for this

@vemula-anu please do not post support questions to this issue, create a new question in Discussions.

Could you please add Yugabyte to the list? https://github.com/jaegertracing/jaeger/issues/4354

Could you please add Yugabyte to the list? #4354

Added, sorry for the delay.

The creator of Tempo @joe-elliott is a maintainer here at Jaeger and is also an engineer with Grafana Labs. We had this discussion, but right now Tempo cannot support the types of queries the Jaeger UI does today. I know that may change, at which point Tempo would be a good Jaeger backend, but today it cannot do everything necessary.

I know Tempo today is a lot more capable in terms of its search compared to back in 2021. Is it now a potentially good Jaeger backend or are there still gaps?

@paulgrav
Just what @joe-elliott explained of the possibility. I had completely overhauled jaeger-objectstorage to use tempo as a backend to store traces to AWS S3/GCS/AzureBlob since i believe tempo is already mature to support multiple cloud storage providers. Back in the early days of tempo there wasn't support for GCS and AzureBlob so we used loki as the interface to store trace data.
I've posted in the forums on how it would look like so you can take a look.
The codes are already published (both the tempo fork and jaeger-objectstorage) but the documentation needs more polishing.

Is it possible to use loki as a back-end store, which can be a good correlation between logging and tracing?

Is it possible to use loki as a back-end store, which can be a good correlation between logging and tracing?

Is it possible to use loki as a back-end store, which can be a good correlation between logging and tracing?

Unfortunately, no @jiajiayang as loki is a logging system, however Tempo is the tracing backend and doesn't support full text search which is how Jaeger does the querying you see in the search dialog box.
Even in Grafana stack you still run multiple backends.

Hello community, I am going to implement a apache doris grpc storage.
I have done some work in open telemetry community. The open telemetry collector will be able to write traces data directly to apache doris.
So can I only implement the SpanReaderPlugin interface in the grpc service, or I still need to implement the SpanReaderPlugin interface?
Could you give me some advice? Thank you!

@joker-star-l it's up to you. You can maintain it in your own repository and explain the existing limitations. If people find it useful they may ask to support the writer API.

Any plans of supporting Pinot in future ?

No

Hello, I am using OpenGauss recently. How can I adapt the storage backend of OpenGauss?

Could you give me some ideas, please?

@qixia1998 You would have to build a GRPC plugin to adapt to the Jaeger storage format. You can find lots of examples in the list above of how to build this. If you have specific questions you can open an issue or come to #jaeger on the CNCF Slack which is free to sign up. Thanks!

OK，Thanks

Following up on my comment about PostgreSQL I'm very confident PostgreSQL is not a suitable storage backend, at least with its default storage access method.
PostgreSQL has very high per-row overheads, and it's not great at append-oriented data.
It is possible that one of the columnar-store extensions might help, but I find it difficult to see any benefit to using PostgeSQL as a backing store compared to the various alternatives that are better suited to such data.

Hello this is a GaussDB gRPC Storage plugin，@yurishkuro


Issue 2090: Links to connector source code are broken

Motivation
Fixes #2090.
Links to connector source code are broken
Changes

Change package name from connect to io
Fix the connector class name

retest this please

retest this please

retest this please


Why is there no self parameter in contract impls?

As a beginner in Rust, I'm wondering why there is no self parameter in soroban smart contract functions. Is it because a smart contract struct has no state apart from what is in storage and therefore there is no need to have a self reference?

We could support it so that the developer could choose. It would feel more natural in many cases, although functionally I'm not sure it would add anything. But the usability bonus would be nice.
I debated putting the env: Env parameter on the struct itself, and that's something we could still do.


Fix premature rule evaluation

This commit prevents rule evaluation from starting until after
the storage is ready.
Fixes #1297

+1

:+1:

\o/


[backend]making connect request api added

Description
created all required api endpoints for the brand collab open apply by influencer. and accept, reject apis. with accepting message will autmatically sent.
Issue
Issue Link resolve #218

@Kajol-Kumari  @RohitGupta1237  can you please check.


DRAFT: add data structure for expansion candidates

Pull Request doc
Purpose
Add a thin data structure enclosing expansion candidate information for generation, transmission, and storage.
What the code is doing
Basic column checking on branch, plant, storage parameters if they're passed, otherwise instantiating an empty dataframe with the appropriate columns.
Usage Example/Visuals
>>> from powersimdata.input.expansion_candidates import ExpansionCandidates
>>> import pandas as pd
>>> ec = ExpansionCandidates()
>>> ec.branch
Empty DataFrame
Columns: [from_bus, to_bus, inv_cost, max_capacity]
Index: []
>>> ec.plant
Empty DataFrame
Columns: [bus_id, type, marginal_cost, inv_cost, max_capacity]
Index: []
>>> ec.storage
Empty DataFrame
Columns: [bus_id, inv_cost_power, inv_cost_energy, max_capacity_energy, max_capacity_power]
Index: []
>>> plant = pd.DataFrame({"bus_id": [1, 10, 10, 100], "type": ["ng", "ng", "wind", "solar"], "marginal_cost": [40, 40, 0, 0]})
>>> ec = ExpansionCandidates(plant=plant)
>>> ec.branch
Empty DataFrame
Columns: [from_bus, to_bus, inv_cost, max_capacity]
Index: []
>>> ec.plant
   bus_id   type  marginal_cost  inv_cost  max_capacity
0       1     ng             40       NaN           NaN
1      10     ng             40       NaN           NaN
2      10   wind              0       NaN           NaN
3     100  solar              0       NaN           NaN
>>> ec.storage
Empty DataFrame
Columns: [bus_id, inv_cost_power, inv_cost_energy, max_capacity_energy, max_capacity_power]
Index: []

Time estimate
?

We may want a table for investment costs (indexed by candidate, columns are years, or vice versa), since they may vary by year.

We'll probably also want to contain profiles for the expansion candidates.


does not work with immutable.js object as state

Due to object destructuring in createStore immutable.js objects are losing some of their methods, e.g. Map loses getIn, setIn etc.

Thanks for the warning @Yevs
Do you have something in mind for the possible solution?

if you are ok with breaking the current API, we might not merge updated state into current state but just update current state with updated state, e.g.:
setState(update) {
      state =
        typeof update === "function"
          ? update(state)
          : update

      listeners.forEach(f => f(state))
    }

Right now, this is what we get:
const state = { one: { two: { three: "four" } }, five: "six" }
store.setState(state)
expect(store.getState()).toEqual({
  one: { two: { three: "four" } },
  five: "six"
})

store.setState({ five: "seven" })
expect(store.getState()).toEqual({
  one: { two: { three: "four" } },
  five: "seven"
})

With this new approach that you're suggesting, this is what is going to happen:
const state = { one: { two: { three: "four" } }, five: "six" }
store.setState(state)
expect(store.getState()).toEqual({
  one: { two: { three: "four" } },
  five: "six"
})

store.setState({ five: "seven" })
expect(store.getState()).toEqual({
  five: "seven"
})

This means that we're pretty much losing the state history. Are you aware of that?

Yeah, I understand, that's why I said that this will break current API. If you want to save this behavior we can just add something like import { createStore } from 'redux-zero/replace-store-state-or-whatever' for immutablejs users

@Yevs that's an interesting approach. What you think about this @malbernaz ?

I think we can support immutablejs specifically. Not sure about other libraries.

Maybe the same API of regular createStore, but you can import it like this:
import createStore from 'redux-zero/immutable'

Wanna go for it @Yevs?

Thinking about it more in depth I think this is out of scope : /.
We should think of how trivial would it be to implement this in the code we already have. For instance, how would store.setState work?
In redux is fine to use immutable because the state is not manipulated directly.
And more: if we want to use immutable in the store today we can do it as we do in a react component state, like:
this.setState(({ data }) => ({
  data: data.update('password', password =>  event.target.value)
}));

I'm almost sure this works. It would be nice if we had tests for this use case.
What do you think @matheusml ?

Good point @malbernaz
@Yevs let's say that we add another function to the Store, immutableSetState. And this function will be exactly like you proposed:
immutableSetState(update) {
  state =
    typeof update === "function"
      ? update(state)
      : update

  listeners.forEach(f => f(state))
}

How is the application going to work if you're not saving the state history? Could please guide me here, because I'm not very familiar with Immutable.js?

@matheusml  I am not actually sure about what you mean by "saving the state history" but I will explain how I see it functioning. It would work in a similar way to how regular redux works, e.g. current state goes through some business logic and then new state is returned: onClick() -> store.getState() -> state -> update(state) -> newState -> store.immutableSetState(newStore) -> rerender react. In such way redux-zero can hold anything as its state (regular js object, immutablejs object, string etc.)

@Yevs thanks a lot for the time, but I think that this is out of scope for now.
We have some other priorities right now, and maybe in the future we can talk more in depth about this again, ok?

No problem, thank you guys for such a great library! :+1:

Thank you @Yevs
And we get back to this, I'll make sure you're involved.
:100:


Hide chargeback container image reports

Hides the 'chargeback for container images' feature from the user.
This is just in case we want to hide this feature in euwe branch until we merge all the fixes\enhancements
@bazulay @simon3z

The reason we are considering hiding it is because we are not sure when the fix in openshift will arrive

The reason we are considering hiding it is because we are not sure when the fix in openshift will arrive

Right. I meant that after they make the fix we would need the changes.

The reason we are considering hiding it is because we are not sure when the fix in openshift will arrive

Corrected

This is just in case we want to hide this feature in euwe branch until the openshift fix arrives

I assume this means euwe/yes label?

I assume this means euwe/yes label?

@chessbyte Yes
@miq-bot add_label euwe/yes

ping @bazulay @chessbyte we should get this merged

Need to merge this PR to hide the following RFE as it will not work due to and outstanding OpenShift issue.
https://bugzilla.redhat.com/show_bug.cgi?id=1357515
@miq-bot add_label bloker

Euwe Backport details:
$ git log -1
commit 3f840ef85eb45c7e6b7381f350de4b2259129199
Author: Oleg Barenboim<EMAIL_ADDRESS>Date:   Tue Nov 8 16:42:59 2016 -0500

    Merge pull request #12327 from zeari/hide_chargeback_container_project

    Hide chargeback container image reports
    (cherry picked from commit 73a2aebb3c9c6876f76c06246e77ddcf3012156e)

    https://bugzilla.redhat.com/show_bug.cgi?id=1357515

Need to merge this PR to hide the following RFE as it will not work due to and outstanding OpenShift issue.
https://bugzilla.redhat.com/show_bug.cgi?id=1357515

@chrispy1 @zeari @bazulay that doesn't seem the relevant BZ. Does anyone know the correct one?

@chrispy1 @zeari @bazulay that doesn't seem the relevant BZ. Does anyone know the correct one?

Ah I think I understood; it was the best fitting BZ we already had related to container images (even though not specific to chargeback). Or I suppose that's the idea (it's not clear).


Add narrow and wide

This PR fixes the narrow and wide port connection. It also shows that it can build correctly in this test.
Major TODOs:

[x] Add narrow wide switches
[x] Add configurations
[x] Check if it builds correctly

For documentation purposes, the SW test will be made in a separate PR to reduce PR size. Moreover, we need to attach the narrow-wide switches too.


Modify to not upgrade to same version of kit already installed

@Microsoft/ostc-devs

Looks nice!  Sign-off.

Signed off


Add tests for unicode inputs for ngram matrix

Now the unicode input is not tested by ngram matrix. It would be good to have this covered. Look e.g. at the tests in https://github.com/JuliaLogging/LoggingFormats.jl/blob/master/test/runtests.jl#L8-L12

Some tests added in 6b49b39b6a057f662ba078c5bb6a55febb9a804d


Install and configure avahi

Connects to #317
Avahi daemon on the device advertise the following services:
+ wlp4s0 IPv4 raspberrypi3 [b8:27:eb:a5:7d:b0]              Workstation          local
+ wlp4s0 IPv4 raspberrypi3                                  SSH Remote Terminal  local
= wlp4s0 IPv4 raspberrypi3 [b8:27:eb:a5:7d:b0]              Workstation          local
   hostname = [raspberrypi3.local]
   address = [<IP_ADDRESS>]
   port = [9]
   txt = []
= wlp4s0 IPv4 raspberrypi3                                  SSH Remote Terminal  local
   hostname = [raspberrypi3.local]
   address = [<IP_ADDRESS>]
   port = [22222]
   txt = []

Example of ssh-ing on a device:
andrei@resin ~ $ ssh -p 22222<EMAIL_ADDRESS>The authenticity of host '[raspberrypi3.local]:22222 ([<IP_ADDRESS>]:22222)' can't be established.
RSA key fingerprint is SHA256:cSP2z7aCpR1XHNgKqgHTG71cOX9hj4rPZKfIn1jCupg.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[raspberrypi3.local]:22222,[<IP_ADDRESS>]:22222' (RSA) to the list of known hosts.
root@raspberrypi3:~#

LGTM

Please rebase so we can merge this today. Thanks


[Enhancment] SSL Security Notifier (Like the previous feature)

Will come back soon.

Too complicated to develop for the time being.
Closed


⚠ Bofrost.lu has degraded performance

In c28a87c, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1167 ms

Resolved: Bofrost.lu performance has improved in ef7ad72.


casting larg duration produces irronius results

The returned string does not represent the same time stamp as the one in the query. It is off by an hour and change.
edgedb> SELECT <str><duration><str>'-854015929h20m18.258432s';
{'-854015928:39:41.741568'}

EdgeDB Version: 1.0a8.dev5287+g53ed2609-2020122100~focal.nightly

OS Version: Linux 5.8.0-40-generic #45~20.04.1-Ubuntu SMP Fri Jan 15 11:35:04 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

According to @elprans this is intended behavior, reflecting Postgres behavior and having to do with interval arithmetic.
A simpler, easier to grasp example of what's going on there:
edgedb> SELECT <duration><str>'-1h1m';
{<duration>'-0:59:00'}


README for new bootstrapped projects contains bad travis URL

Due to the bionitio-team in our original URLs, these are not correctly patched by the bootstrap script, so newly bootstrapped projects contain bad URLs.
We should update the bootstrap script to fix this.

We also need to fix the link to the license, making sure we use the correct license if the user chooses something other than the default.