Strategy for original rustfmt crate on crates.io

There's an ancient rustfmt crate on crates.io in addition to the current/maintained rustfmt-nightly crate, and the former's latest version is v0.10.0 which was published over 2.5 years ago.
This has been a source of confusion for users, particularly those new to the Rust ecosystem who go to crates.io looking for rustfmt, so I'm wondering if we should try to deprecate it/yank versions or if there's some valid usage patterns for that crate I'm just not aware of.
Thoughts?

I prefer to keep rustfmt over rustfmt-nightly as a valid name as the latter naming is for historical reasons.
I would like to publish to both rustfmt-nightly and rustfmt, advocate for using rustfmt over rustfmt-nightly and yank rustfmt-nightly at some point the future.
cc @nrc @steveklabnik who own https://crates.io/crates/rustfmt.

Ahh okay, SGTM (and sorry for the duplicate :smile:)

I would like to publish to both rustfmt-nightly and rustfmt, advocate for using rustfmt over rustfmt-nightly and yank rustfmt-nightly at some point the future.

This would be my personal preferred strategy as well, but in a policy sense, I am not sure who is in charge of doing this. My guess is @rust-lang/devtools ?

Is there not a concern that users try to install rustfmt and break their installation?  I've seen that happen, where the user runs cargo install rustfmt, and now they are using a 3 year old version, and don't understand why it sometimes doesn't work.  If the rustfmt crate was yanked (or replaced with one that generates a compile error explaining the situation), that wouldn't happen.   If the rustfmt crate is a new version, you kinda have a different problem where "my rustfmt works different from this other person's and I don't know why".
It's probably not too important, but something to be careful of.

Is there not a concern that users try to install rustfmt and break their installation?

That was the concern for me in opening this issue, as this definitely happens (as recently as yesterday). I think in the short term even something as simple as publishing a 0.10.1 with a deprecation notice in the readme that says "Don't use this, use rustup" would be helpful while we figure out what we should do longer term.

I'm okay with renaming rustfmt-nightly to rustfmt. I would slightly caution against shipping a binary here.
I would like to eventually start a discussion about https://github.com/rust-lang/rust/issues/70651 for rustfmt, because the current situation with updating over rustc-ap crates is not great. If that's implemented then it's going to be really tricky to publish rustfmt to crates, and it's worth looking at how people use the crate and if something that uses the tool can instead be used.

Sorry if this is the wrong place to ask, but: I just found the rustfmt-nightly crate on crates.io and wanted to use it to see how different versions of rustfmt might format some code differently.  I see that the last version published was 1.4.21, but the latest rustfmt is 1.4.30, and Rust stable 1.48 and 1.49 both shipped with rustfmt newer than the one on crates.io.  Was it intentional that this crate stopped being updated?  (I know that I can use rust toolchain to add the versions I want, but that will download and store a lot more than I need just to test different rustfmt versions.)  Thanks!

Sorry if this is the wrong place to ask, but: I just found the rustfmt-nightly crate on crates.io and wanted to use it to see how different versions of rustfmt might format some code differently.  I see that the last version published was 1.4.21, but the latest rustfmt is 1.4.30, and Rust stable 1.48 and 1.49 both shipped with rustfmt newer than the one on crates.io.  Was it intentional that this crate stopped being updated?  (I know that I can use rust toolchain to add the versions I want, but that will download and store a lot more than I need just to test different rustfmt versions.)  Thanks!

Was it intentional that this crate stopped being updated? (I know that I can use rust toolchain to add the versions I want, but that will download and store a lot more than I need just to test different rustfmt versions.) Thanks!

Not intentional, I just don't have access to push to crates :smile: Have started enumerating the install options in the Changelog and you'll note that the crates.io option is still listed as pending for all the recent releases.
If/when I get access to update the crate I'm happy to go back and publish these pending versions and any new ones that come along.
If you just want to grab a rustfmt binary though for some testing, you might find the GH releases (which contain pre-built binaries for several platforms) easier than trying to get a corresponding nightly needed to grab a specific version from crates.io

Was it intentional that this crate stopped being updated? (I know that I can use rust toolchain to add the versions I want, but that will download and store a lot more than I need just to test different rustfmt versions.) Thanks!

Not intentional, I just don't have access to push to crates :smile: Have started enumerating the install options in the Changelog and you'll note that the crates.io option is still listed as pending for all the recent releases.
If/when I get access to update the crate I'm happy to go back and publish these pending versions and any new ones that come along.
If you just want to grab a rustfmt binary though for some testing, you might find the GH releases (which contain pre-built binaries for several platforms) easier than trying to get a corresponding nightly needed to grab a specific version from crates.io

Not intentional, I just don't have access to push to crates smile Have started enumerating the install options in the Changelog and you'll note that the crates.io option is still listed as pending for all the recent releases.
If/when I get access to update the crate I'm happy to go back and publish these pending versions and any new ones that come along.

Is there any plan on this happening?
I would really like to use the new imports_granularity feature through the rustfmt dprint plugin which depends on rustfmt as a lib and pulls it from crates.io.

Not intentional, I just don't have access to push to crates smile Have started enumerating the install options in the Changelog and you'll note that the crates.io option is still listed as pending for all the recent releases.
If/when I get access to update the crate I'm happy to go back and publish these pending versions and any new ones that come along.

Is there any plan on this happening?
I would really like to use the new imports_granularity feature through the rustfmt dprint plugin which depends on rustfmt as a lib and pulls it from crates.io.

Is there any plan on this happening?

Not really. The folks that have access to the crate have not been involved with the project for a while, and I didn't have much luck the last time I inquired about getting added. Will give it another go at some point, but this has not been a particularly high priority item

I would really like to use the new imports_granularity feature through the rustfmt dprint plugin which depends on rustfmt as a lib and pulls it from crates.io.

While I understand the desire and benefits to have formatting capabilities available as a library, I want to reiterate caution given the current state of things.
rustfmt itself is coupled to the auto publish crates for access to the rustc internals, so by depending on the rustfmt crate all of those challenges associated with the auto publish crates will cascade down to you (and anything else that depends on your project). Notably that means nightly only, fairly frequent compilation failures on nightly, as well as some rustc internal requirements that trickle through like having to set CFG_RELESE and CFG_RELEASE_CHANNEL.
If you really want to go ahead and use the latest version of rustfmt as a lib then I suppose you could always specify the dependency as a git reference using one of the corresponding tags, but I'm rather skeptical about the viability of the rustfmt-as-a-lib use case given the current context and constraints.

Is there any plan on this happening?

Not really. The folks that have access to the crate have not been involved with the project for a while, and I didn't have much luck the last time I inquired about getting added. Will give it another go at some point, but this has not been a particularly high priority item

I would really like to use the new imports_granularity feature through the rustfmt dprint plugin which depends on rustfmt as a lib and pulls it from crates.io.

While I understand the desire and benefits to have formatting capabilities available as a library, I want to reiterate caution given the current state of things.
rustfmt itself is coupled to the auto publish crates for access to the rustc internals, so by depending on the rustfmt crate all of those challenges associated with the auto publish crates will cascade down to you (and anything else that depends on your project). Notably that means nightly only, fairly frequent compilation failures on nightly, as well as some rustc internal requirements that trickle through like having to set CFG_RELESE and CFG_RELEASE_CHANNEL.
If you really want to go ahead and use the latest version of rustfmt as a lib then I suppose you could always specify the dependency as a git reference using one of the corresponding tags, but I'm rather skeptical about the viability of the rustfmt-as-a-lib use case given the current context and constraints.

Yeah I think we should be trying to deprecate rustfmt-as-a-crate

Yeah I think we should be trying to deprecate rustfmt-as-a-crate

rustfmt itself is coupled to the auto publish crates for access to the rustc internals, so by depending on the rustfmt crate all of those challenges associated with the auto publish crates will cascade down to you (and anything else that depends on your project). Notably that means nightly only, fairly frequent compilation failures on nightly, as well as some rustc internal requirements that trickle through like having to set CFG_RELESE and CFG_RELEASE_CHANNEL.
If you really want to go ahead and use the latest version of rustfmt as a lib then I suppose you could always specify the dependency as a git reference using one of the corresponding tags, but I'm rather skeptical about the viability of the rustfmt-as-a-lib use case given the current context and constraints.

I haven't been involved in the initial development of the dprint plugin crate but at least the current state of things doesn't look very complicated: https://github.com/dprint/dprint-plugin-rustfmt

Yeah I think we should be trying to deprecate rustfmt-as-a-crate

Please don't deprecate rustfmt-as-a-crate. Being able to use rustfmt as a library provides a lot of value to us because it means we can use dprint as a single formatting tool across our codebases that often times mix several languages with each other.
Additionally, it is very nice to not being able to be restricted by what rustfmt considers stable and nightly. For example, the currently published version of rustfmt (v1) makes it impossible to use unstable formatting features on a stable toolchain (I know that this might change with v2 but that is not available yet).
As a result and before we discovered dprint, we had to always install two toolchains (1 nightly and stable) to be able to use features like merge_imports while at the same time compiling our code on stable. Ever since we use dprint, the amount of tooling configuration that we need to deal with in our codebases went down quite a bit.
I am not sure how many other people have similar requirements. I am just pointing out that not having rustfmt as a crate makes usecases like @dsherret's dprint harder to realize. (He has some plugins that invoke native binaries instead of being pure wasm plugins but wasm plugins are arguably the much nicer solution but they do require rustfmt to be available as a library.)

rustfmt itself is coupled to the auto publish crates for access to the rustc internals, so by depending on the rustfmt crate all of those challenges associated with the auto publish crates will cascade down to you (and anything else that depends on your project). Notably that means nightly only, fairly frequent compilation failures on nightly, as well as some rustc internal requirements that trickle through like having to set CFG_RELESE and CFG_RELEASE_CHANNEL.
If you really want to go ahead and use the latest version of rustfmt as a lib then I suppose you could always specify the dependency as a git reference using one of the corresponding tags, but I'm rather skeptical about the viability of the rustfmt-as-a-lib use case given the current context and constraints.

I haven't been involved in the initial development of the dprint plugin crate but at least the current state of things doesn't look very complicated: https://github.com/dprint/dprint-plugin-rustfmt

Yeah I think we should be trying to deprecate rustfmt-as-a-crate

Please don't deprecate rustfmt-as-a-crate. Being able to use rustfmt as a library provides a lot of value to us because it means we can use dprint as a single formatting tool across our codebases that often times mix several languages with each other.
Additionally, it is very nice to not being able to be restricted by what rustfmt considers stable and nightly. For example, the currently published version of rustfmt (v1) makes it impossible to use unstable formatting features on a stable toolchain (I know that this might change with v2 but that is not available yet).
As a result and before we discovered dprint, we had to always install two toolchains (1 nightly and stable) to be able to use features like merge_imports while at the same time compiling our code on stable. Ever since we use dprint, the amount of tooling configuration that we need to deal with in our codebases went down quite a bit.
I am not sure how many other people have similar requirements. I am just pointing out that not having rustfmt as a crate makes usecases like @dsherret's dprint harder to realize. (He has some plugins that invoke native binaries instead of being pure wasm plugins but wasm plugins are arguably the much nicer solution but they do require rustfmt to be available as a library.)

@thomaseizinger in the case of dprint-plugin-rustfmt, luckily I believe it could probably get away with building from the git tag because the plugin is published to a WASM file on github releases instead of to crates.io. That said, not having this crate published on crates.io might not be so nice for others.

@thomaseizinger in the case of dprint-plugin-rustfmt, luckily I believe it could probably get away with building from the git tag because the plugin is published to a WASM file on github releases instead of to crates.io. That said, not having this crate published on crates.io might not be so nice for others.

at least the current state of things doesn't look very complicated: https://github.com/dprint/dprint-plugin-rustfmt

That project is using a fairly old version, which predates some of the rustc updates, like the CFG_RELEASE vars. I suspect you'll run into this quickly if/when you update.

Being able to use rustfmt as a library provides a lot of value to us because it means we can use dprint as a single formatting tool across our codebases that often times mix several languages with each other.

Could you elaborate on how this specific use case is enabled by the rustfmt lib as a crate, that wouldn't be available by running the bin or using the lib from our git? Editors/IDEs support running rustfmt (as well as various other formatters for different languages), and the vast majority of them, including RA IIRC, invoke the rustfmt binary.

Additionally, it is very nice to not being able to be restricted by what rustfmt considers stable and nightly. For example, the currently published version of rustfmt (v1) makes it impossible to use unstable formatting features on a stable toolchain (I know that this might change with v2 but that is not available yet)

Sorry, but it's a bug not a feature that unstable options can be used on stable, and it could very well be removed in a future release. Additionally, the stability of configuration options/the cadence at which option are stabilized feels like an orthogonal topic.
The same bug that allows this in the library exists in the CLI too:
rustfmt foo.rs --config merge_imports=true

When and if the bug gets fixed, it is fixed everywhere, including any versions published to crates.io.

I am just pointing out that not having rustfmt as a crate makes usecases like @dsherret's dprint harder to realize. (He has some plugins that invoke native binaries instead of being pure wasm plugins but wasm plugins are arguably the much nicer solution but they do require rustfmt to be available as a library.)

That seems a bit like an implementation choice, with viable alternatives.
I've shared this previously in a few threads, but will reiterate again here that this is ultimately a matter of weighing tradeoffs.
Making rustfmt available for lib consumption from crates.io is not easy and has significant drawbacks for all rustfmt userss on nightly, not just the handful of scenarios where folks would like a lib from crates. Doing this is what results in rustfmt being broken and unavailable on nightly at a regular cadence (again, not available for anyone, not just someone trying to build the crate). It also eats up a ton of the rustfmt team's bandwidth because changes in rustc land all the time that in turn cause downstream breakage in rustfmt. We then have to retroactively figure out what changed in rustc and the associated impacts and changes we need to make. These updates then have to be coordinated across 4 (sometimes 5) separate projects, just to get rustfmt available again. We've also had been plenty of cases where this complicates the ability to backport fixes onto beta/stable.
We'd love to be able to support the types of use cases you've shared, and if there were zero drawbacks to continuing to make rustfmt available on crates.io then we wouldn't even be having the conversation. The challenge, however, is that it is the cause of a lot of very real problems both for users and maintainers, and we have to consider whether continuing to support these types of edge cases is worth the negative side effects.

at least the current state of things doesn't look very complicated: https://github.com/dprint/dprint-plugin-rustfmt

That project is using a fairly old version, which predates some of the rustc updates, like the CFG_RELEASE vars. I suspect you'll run into this quickly if/when you update.

Being able to use rustfmt as a library provides a lot of value to us because it means we can use dprint as a single formatting tool across our codebases that often times mix several languages with each other.

Could you elaborate on how this specific use case is enabled by the rustfmt lib as a crate, that wouldn't be available by running the bin or using the lib from our git? Editors/IDEs support running rustfmt (as well as various other formatters for different languages), and the vast majority of them, including RA IIRC, invoke the rustfmt binary.

Additionally, it is very nice to not being able to be restricted by what rustfmt considers stable and nightly. For example, the currently published version of rustfmt (v1) makes it impossible to use unstable formatting features on a stable toolchain (I know that this might change with v2 but that is not available yet)

Sorry, but it's a bug not a feature that unstable options can be used on stable, and it could very well be removed in a future release. Additionally, the stability of configuration options/the cadence at which option are stabilized feels like an orthogonal topic.
The same bug that allows this in the library exists in the CLI too:
rustfmt foo.rs --config merge_imports=true

When and if the bug gets fixed, it is fixed everywhere, including any versions published to crates.io.

I am just pointing out that not having rustfmt as a crate makes usecases like @dsherret's dprint harder to realize. (He has some plugins that invoke native binaries instead of being pure wasm plugins but wasm plugins are arguably the much nicer solution but they do require rustfmt to be available as a library.)

That seems a bit like an implementation choice, with viable alternatives.
I've shared this previously in a few threads, but will reiterate again here that this is ultimately a matter of weighing tradeoffs.
Making rustfmt available for lib consumption from crates.io is not easy and has significant drawbacks for all rustfmt userss on nightly, not just the handful of scenarios where folks would like a lib from crates. Doing this is what results in rustfmt being broken and unavailable on nightly at a regular cadence (again, not available for anyone, not just someone trying to build the crate). It also eats up a ton of the rustfmt team's bandwidth because changes in rustc land all the time that in turn cause downstream breakage in rustfmt. We then have to retroactively figure out what changed in rustc and the associated impacts and changes we need to make. These updates then have to be coordinated across 4 (sometimes 5) separate projects, just to get rustfmt available again. We've also had been plenty of cases where this complicates the ability to backport fixes onto beta/stable.
We'd love to be able to support the types of use cases you've shared, and if there were zero drawbacks to continuing to make rustfmt available on crates.io then we wouldn't even be having the conversation. The challenge, however, is that it is the cause of a lot of very real problems both for users and maintainers, and we have to consider whether continuing to support these types of edge cases is worth the negative side effects.

Being able to use rustfmt as a library provides a lot of value to us because it means we can use dprint as a single formatting tool across our codebases that often times mix several languages with each other.

Could you elaborate on how this specific use case is enabled by the rustfmt lib as a crate, that wouldn't be available by running the bin or using the lib from git? Editors/IDEs support running rustfmt (as well as various other formatters for different languages), and the vast majority of them, including RA IIRC, invoke the rustfmt binary.

As @dsherret pointed out, the dprint plugin is published as a wasm binary anyway and as such can actually use git dependencies.
This means at least for this usecase, a release on crates.io is not critical.

Additionally, it is very nice to not being able to be restricted by what rustfmt considers stable and nightly. For example, the currently published version of rustfmt (v1) makes it impossible to use unstable formatting features on a stable toolchain (I know that this might change with v2 but that is not available yet)

Sorry, but it's a bug not a feature that unstable options can be used on stable, and it could very well be removed in a future release. Additionally, the stability of configuration options/the cadence at which option are stabilized feels like an orthogonal topic.
The same bug that allows this in the library exists in the CLI too:
rustfmt foo.rs --config merge_imports=true

When and if the bug gets fixed, it is fixed everywhere, including any versions published to crates.io.

Well, at least through cargo fmt, it is precisely not possible to use unstable formatting features on a stable channel which is why we had to install two toolchains in the past.
FWIW, it never made sense to me that stable/unstable formatting features are coupled to the rustc release channels. I would like to build software against the stable compiler release because it receives a lot more testing. On the other hand, I have no issues using unstable formatting features if they provide sufficient value. In this particular case, merge_imports served us very well for 2+ years.
Unfortunately, precisely this is not possible with cargo as the primary interface. I've never actually dealt with the rustfmt binary itself.

I am just pointing out that not having rustfmt as a crate makes usecases like @dsherret's dprint harder to realize. (He has some plugins that invoke native binaries instead of being pure wasm plugins but wasm plugins are arguably the much nicer solution but they do require rustfmt to be available as a library.)

That seems a bit like an implementation choice, with viable alternatives.

As noted above, I didn't see that git dependencies are an option here.

I've shared this previously in a few threads, but will reiterate again here that this is ultimately a matter of weighing tradeoffs.
Making rustfmt available for lib consumption from crates.io is not easy and has significant drawbacks for all rustfmt users on nightly, not just the handful of scenarios where folks would like a lib from crates. Doing this is what results in rustfmt being broken and unavailable on nightly at a regular cadence (again, not available for anyone, not just someone trying to build the crate). It also eats up a ton of the rustfmt team's bandwidth because changes in rustc land all the time that in turn cause downstream breakage in rustfmt. We then have to retroactively figure out what changed in rustc and the associated impacts and changes we need to make. These updates then have to be coordinated across 4 (sometimes 5) separate projects, just to get rustfmt available again. We've also had cases where this complicates the ability to backport fixes onto beta/stable.
We'd love to be able to support the types of use cases you've shared, and if there were zero drawbacks to continuing to make rustfmt available on crates.io then we wouldn't even be having the conversation. The challenge, however, is that it is the cause of a lot of very real problems both for users and maintainers, and we have to consider whether continuing to support these types of edge cases is worth the negative side effects.

Thank you for sharing your perspective! I didn't fully see the complexity that is involved in creating / maintaining these releases and I totally get that you want to free yourself from as much of this complexity as possible :)
At least for the particular topic at hand, a library interface and git tags should be sufficient. Is the rustfmt binary + lib split something you consider keeping (even if the lib is not published anywhere) or are you thinking of moving everything into a binary crate?

Being able to use rustfmt as a library provides a lot of value to us because it means we can use dprint as a single formatting tool across our codebases that often times mix several languages with each other.

Could you elaborate on how this specific use case is enabled by the rustfmt lib as a crate, that wouldn't be available by running the bin or using the lib from git? Editors/IDEs support running rustfmt (as well as various other formatters for different languages), and the vast majority of them, including RA IIRC, invoke the rustfmt binary.

As @dsherret pointed out, the dprint plugin is published as a wasm binary anyway and as such can actually use git dependencies.
This means at least for this usecase, a release on crates.io is not critical.

Additionally, it is very nice to not being able to be restricted by what rustfmt considers stable and nightly. For example, the currently published version of rustfmt (v1) makes it impossible to use unstable formatting features on a stable toolchain (I know that this might change with v2 but that is not available yet)

Sorry, but it's a bug not a feature that unstable options can be used on stable, and it could very well be removed in a future release. Additionally, the stability of configuration options/the cadence at which option are stabilized feels like an orthogonal topic.
The same bug that allows this in the library exists in the CLI too:
rustfmt foo.rs --config merge_imports=true

When and if the bug gets fixed, it is fixed everywhere, including any versions published to crates.io.

Well, at least through cargo fmt, it is precisely not possible to use unstable formatting features on a stable channel which is why we had to install two toolchains in the past.
FWIW, it never made sense to me that stable/unstable formatting features are coupled to the rustc release channels. I would like to build software against the stable compiler release because it receives a lot more testing. On the other hand, I have no issues using unstable formatting features if they provide sufficient value. In this particular case, merge_imports served us very well for 2+ years.
Unfortunately, precisely this is not possible with cargo as the primary interface. I've never actually dealt with the rustfmt binary itself.

I am just pointing out that not having rustfmt as a crate makes usecases like @dsherret's dprint harder to realize. (He has some plugins that invoke native binaries instead of being pure wasm plugins but wasm plugins are arguably the much nicer solution but they do require rustfmt to be available as a library.)

That seems a bit like an implementation choice, with viable alternatives.

As noted above, I didn't see that git dependencies are an option here.

I've shared this previously in a few threads, but will reiterate again here that this is ultimately a matter of weighing tradeoffs.
Making rustfmt available for lib consumption from crates.io is not easy and has significant drawbacks for all rustfmt users on nightly, not just the handful of scenarios where folks would like a lib from crates. Doing this is what results in rustfmt being broken and unavailable on nightly at a regular cadence (again, not available for anyone, not just someone trying to build the crate). It also eats up a ton of the rustfmt team's bandwidth because changes in rustc land all the time that in turn cause downstream breakage in rustfmt. We then have to retroactively figure out what changed in rustc and the associated impacts and changes we need to make. These updates then have to be coordinated across 4 (sometimes 5) separate projects, just to get rustfmt available again. We've also had cases where this complicates the ability to backport fixes onto beta/stable.
We'd love to be able to support the types of use cases you've shared, and if there were zero drawbacks to continuing to make rustfmt available on crates.io then we wouldn't even be having the conversation. The challenge, however, is that it is the cause of a lot of very real problems both for users and maintainers, and we have to consider whether continuing to support these types of edge cases is worth the negative side effects.

Thank you for sharing your perspective! I didn't fully see the complexity that is involved in creating / maintaining these releases and I totally get that you want to free yourself from as much of this complexity as possible :)
At least for the particular topic at hand, a library interface and git tags should be sufficient. Is the rustfmt binary + lib split something you consider keeping (even if the lib is not published anywhere) or are you thinking of moving everything into a binary crate?

Thank you for sharing your perspective! I didn't fully see the complexity that is involved in creating / maintaining these releases and I totally get that you want to free yourself from as much of this complexity as possible :)

I want to stress that the focus of these discussions is users and the community, not the maintainers.
The current approach prioritizes having the ability to also distribute rustfmt via crates.io, but has drawbacks for everyone in the community that utilizes rustfmt.
The status quo is what results in broken toolstates on nightly and rustfmt being unavailable through the main channel (rustup), often for extended periods of time. This is a common point of confusion, particularly for folks that are new to Rust.
Yes it's true that there's a lot of overhead with the current approach that eats up bandwidth, and that means the rustfmt team has less capacity to implement new features, fix bugs, and work on stabilizing configuration options. However, that's entirely secondary.
Again I appreciate the benefits of having rustfmt available as a crate and understand that it's useful in certain cases. We're just considering whether the status quo is tenable, and whether the use cases that benefit from being able to consume rustfmt from crates.io outweigh all of the drawbacks shared on this issue thread.

Is the rustfmt binary + lib split something you consider keeping (even if the lib is not published anywhere) or are you thinking of moving everything into a binary crate?

Correct, we have no intention of changing that regardless of what may or may not be done around crates.io.

The rest of these items are quite far off the focus of this issue, so this will be my last response to these particular topics on this thread. I'm happy to continue the discussion if you'd like, but would ask that you move it to a different issue and/or Discord.

additional responses

Well, at least through cargo fmt, it is precisely not possible to use unstable formatting features on a stable channel which is why we had to install two toolchains in the past.

That's not correct. The bug exists in an override function that's exposed through the library, and thus to rustfmt, and accordingly to cargo fmt, via the cli --config option:
$ cargo +stable fmt --version
rustfmt 1.4.25-stable (0f29ff6 2020-11-11)
$ cargo +stable fmt -- --check --config merge_imports=true
Diff in ..../src/main.rs at line 1:
-use foo::bar;
-    use foo::baz;
+use foo::{bar, baz};

 fn main() {
     println!("Hello, world!");

FWIW, it never made sense to me that stable/unstable formatting features are coupled to the rustc release channels. I would like to build software against the stable compiler release because it receives a lot more testing. On the other hand, I have no issues using unstable formatting features if they provide sufficient value. In this particular case, merge_imports served us very well for 2+ years.

I can understand that point of view, and I'm glad you've had positive experiences with merge_imports!
For future reference, we have documentation that enumerates the requirements for stabilizing options. We won't call a new configuration stable/complete unless and until it can clear that threshold, regardless of whether it's 2 weeks old or 2 years old. It's pretty common within the Rust ecosystem for some features to only be available on nightly, and the rustfmt configuration options (which are how certain formatting features are surfaced) are following that same paradigm (aforementioned bug aside).
Specifically with merge_imports there are known bugs that still exist to this day, and it had also been clear for quite some time that the nature of the option did not fully meet the community need (#3362). This is why we now have imports_granularity, and that evolution is something we wouldn't have been able to do (or at least would've been signficantly more challenging to do) had merge_imports been stabilized prematurely.
Finally, the question/suggestion about whether or not stable rustfmt should support an explicit opt-in to permit using unstable config options on stable has surfaced a few times before, but it's typically been met with a lot of pushback.

Thank you for sharing your perspective! I didn't fully see the complexity that is involved in creating / maintaining these releases and I totally get that you want to free yourself from as much of this complexity as possible :)

I want to stress that the focus of these discussions is users and the community, not the maintainers.
The current approach prioritizes having the ability to also distribute rustfmt via crates.io, but has drawbacks for everyone in the community that utilizes rustfmt.
The status quo is what results in broken toolstates on nightly and rustfmt being unavailable through the main channel (rustup), often for extended periods of time. This is a common point of confusion, particularly for folks that are new to Rust.
Yes it's true that there's a lot of overhead with the current approach that eats up bandwidth, and that means the rustfmt team has less capacity to implement new features, fix bugs, and work on stabilizing configuration options. However, that's entirely secondary.
Again I appreciate the benefits of having rustfmt available as a crate and understand that it's useful in certain cases. We're just considering whether the status quo is tenable, and whether the use cases that benefit from being able to consume rustfmt from crates.io outweigh all of the drawbacks shared on this issue thread.

Is the rustfmt binary + lib split something you consider keeping (even if the lib is not published anywhere) or are you thinking of moving everything into a binary crate?

Correct, we have no intention of changing that regardless of what may or may not be done around crates.io.

The rest of these items are quite far off the focus of this issue, so this will be my last response to these particular topics on this thread. I'm happy to continue the discussion if you'd like, but would ask that you move it to a different issue and/or Discord.

additional responses

Well, at least through cargo fmt, it is precisely not possible to use unstable formatting features on a stable channel which is why we had to install two toolchains in the past.

That's not correct. The bug exists in an override function that's exposed through the library, and thus to rustfmt, and accordingly to cargo fmt, via the cli --config option:
$ cargo +stable fmt --version
rustfmt 1.4.25-stable (0f29ff6 2020-11-11)
$ cargo +stable fmt -- --check --config merge_imports=true
Diff in ..../src/main.rs at line 1:
-use foo::bar;
-    use foo::baz;
+use foo::{bar, baz};

 fn main() {
     println!("Hello, world!");

FWIW, it never made sense to me that stable/unstable formatting features are coupled to the rustc release channels. I would like to build software against the stable compiler release because it receives a lot more testing. On the other hand, I have no issues using unstable formatting features if they provide sufficient value. In this particular case, merge_imports served us very well for 2+ years.

I can understand that point of view, and I'm glad you've had positive experiences with merge_imports!
For future reference, we have documentation that enumerates the requirements for stabilizing options. We won't call a new configuration stable/complete unless and until it can clear that threshold, regardless of whether it's 2 weeks old or 2 years old. It's pretty common within the Rust ecosystem for some features to only be available on nightly, and the rustfmt configuration options (which are how certain formatting features are surfaced) are following that same paradigm (aforementioned bug aside).
Specifically with merge_imports there are known bugs that still exist to this day, and it had also been clear for quite some time that the nature of the option did not fully meet the community need (#3362). This is why we now have imports_granularity, and that evolution is something we wouldn't have been able to do (or at least would've been signficantly more challenging to do) had merge_imports been stabilized prematurely.
Finally, the question/suggestion about whether or not stable rustfmt should support an explicit opt-in to permit using unstable config options on stable has surfaced a few times before, but it's typically been met with a lot of pushback.


Date.create() doesn't support dd/mm/yyyy

Date.create('27/01/2016'); // => Thu Mar 01 2018 00:00:00 GMT+0530 (IST)

It's actually 27th January 2016. This kind of date format is very common in countries like India.

It seems that the date is being parsed using the en-us locale. That is mm/dd/yyyy . you can (and should) enforce the locale by passing the locale string as a second argument in the function. Date.create("27/1/2016", "en-UK") will work as you are expecting. Keep in mind that this is the cleanest solution to disambiguate between March first and January third.

Wow, that was so obvious. Thanks!

Note that you can also pass en-IN as well if you like to be more explicit. Although there is no defined locale, it will have the same effect as en-US is the special one here.


(maint) add codeowners

@tphoney  Travis is failing but not related to the changes in the PR.Merging.


go: Update groups based on current Vim built-in syntax

Description
Since v8.2.3117, Vim ships with the syntax file from fatih/vim-go, which has richer, more granular syntax highlight groups.
Because Polyglot was using this exact syntax file, the polyglot-specific section can now be merged with the regular Go syntax.
Go is my main programming language and I tried to make sensible choices in the additional highlight groups provided by the current Vim syntax (with corresponding Treesitter groups):

built-in function calls -> same as normal function calls, but italic (if enabled)
built-in types -> same as custom types, but italic (if enabled)
namespaces (Treesitter only) -> Fg instead of TSNamespace (YellowItalic) to avoid a dominance of yellow on screen. We refer to things by their explicit package name in Go (e.g. sync.Mutex, bytes.Buffer, ...), and the type already defaults to Yellow.

Screenshots
Before (Treesitter / Vim syntax)

After (Treesitter / Vim syntax)
https://github.com/sainnhe/everforest/pull/81#issuecomment-1216869326

initial screenshots (old)

I think the design of italics need to be adjusted.
When italics are enabled, some green words are italicized while some are not, IMO this is somewhat weird. Either all green words become italic, or become not italic.
Currently there are two widely accepted design for italics:

Italicize keywords and operators.
Italicize types and special variables (like self, this, none, etc.)

In this color scheme, I use the first design in classic vim syntax highlighting, and use the second design in tree-sitter based highlighting.
You've merged these two design which will make there too many italics that will be hard to read when users use fonts with cursive italics like Operator Mono.

I use the first design in classic vim syntax highlighting, and use the second design in tree-sitter based highlighting.

Ahhh, that alleviates some confusion I had about Treesitter and Vim following different conventions in base groups such as Keyword, Type, etc.
(Parenthesis: may I ask why not choosing one convention and apply it uniformly?)
I'll happily adjust my PR to stick to the convention.

@sainnhe I adjusted the highlight groups, taking your comment into account (I think) in e64e4599..75ce7c1c.
Current status:
Treesitter

Vim

Parenthesis: may I ask why not choosing one convention and apply it uniformly?

Check this: https://github.com/sainnhe/gruvbox-material/issues/109#issuecomment-964656653

LGTM. Do you need some more adjustments? If not, I'm going to merge it.

Thanks for the link explaining your rationale. I think parts of your comments from https://github.com/sainnhe/gruvbox-material/issues/119 would deserve to be mentioned in the docs because I'm

Thanks for the link explaining your rationale. I think parts of your comments from https://github.com/sainnhe/gruvbox-material/issues/119 would deserve to be mentioned in the docs, so people are aware that choices that look like mistakes are in fact intentional. With Treesitter starting to be widely adopted and people switching between Vim syntax and Treesitter, glitches like function calls with string arguments that result in green("green", "green") are pretty frequent with the removal of Aqua in Vim syntax.

I'm happy with the changes 👍  I don't have any further improvement for Go highlighting at this point. Thanks!

OK, I may add some to FAQ.
Thanks for your contribution! Your work is really great!


Azure Open AI multi tenancy support (Add your own data)

Hello,
We have a solution that is multi-tenant. Each tenant represents a customer with segregated data, and we are trying out "Add your own data" feature that is currently in Preview.
We are trying to have as little Azure resources as possible.

Is it possible to have multiple data sources in Azure AI Studio or created by API in the same Cognitive Search Azure resource, each one pointing to a specific container in an Azure Blob Storage account (each container having the data of different customer)?
From the Azure AI Studio interface, currently I can only create a data source. Hopefully, this is not a limitation.
Is it possible to call the Open AI API to return data from a specific data source and return data only for that customer? From what I saw, in the API call we can specificy an index name that is associated in a 1:1 relationship with a data source.

How can I make a data source to be persistent? Every time I close my browser, my data source disappears.

Thanks

Hi,
Is there anyone looking at this and give a reply?
Tks,
Miguel

Hi,
Is there anyone looking at this and give a reply?
Thanks

I've also tried to find an clear answer to this same topic and would be glad if this could be answered.

Hi @miguelisidoro, @VisualSeb -

You can create multiple indexes on the same Cognitive Search resource. Each index can then be used as the data source when calling the Azure OpenAI chat extensions API. Currently only one index can be used at a time.
It sounds like you're looking for document-level access control or filtering based on the user ID. The API supports this for a properly configured index using a "filter" parameter for the data source. See more info in the documentation: https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/use-your-data#document-level-access-control

You can see how the web app code constructs the filter string here: https://github.com/microsoft/sample-app-aoai-chatGPT/blob/17e3ab02c9d603906cf13fcb36bd13ab8396df4c/app.py#L133C1-L142C16

Hello @sarah-widder ,
Thanks for the reply.

What do you mean by "Currently only one index can be used at a time."? Does it mean that in each API call we can only specify an index in the indexName property when calling the Azure OpenAI chat extensions API?
It is not document-level access control. What I want is to return data from a specific index. In our case, an index represents a tenant in a multi tenant scenario.

Thanks


Could you share the visualization code to reproduce Figure 1?

Hi,
Could you share the visualization code to reproduce Figure 1 in the paper?

Thank you!
Best,
Wenting

Hi, the code I used to draw this figure is different from the current code base, but you can simply draw a same figure using seaborn's heatmap.

Hi. I have been working on reproducing the impact matrix plot from your paper, but I seem to be getting different results compared to the figure presented in your work. I would greatly appreciate your assistance in identifying any steps I might be missing or any potential issues with my approach.
To generate the impact matrices, I executed the following command:
python preprocess.py --cuda \
  --probe dependency \
  --data_split PUD \
  --dataset ./dependency/data/PUD.conllu

After obtaining the impact matrices, I used the code snippet below to create the plot:
matrix_path = Path("results/dependency/bert-dist-PUD-12.pkl")
with matrix_path.open("rb") as f:
    data = pickle.load(f)
    text, tokens, matrix = data[1]
    print(f"{tokens=}") # tokens=['[CLS]', 'for', 'those', 'who', 'follow', 'social', 'media', 'transitions', 'on', 'capitol', 'hill', ',', 'this', 'will', 'be', 'a', 'little', 'different', '.', '[SEP]']
    print(f"{matrix.shape=}") # matrix.shape=(20, 20)
    sns.heatmap(matrix, xticklabels=tokens, yticklabels=tokens, cmap="crest")

However, the resulting plot (attached below) differs from the one presented in your paper.

Could you provide any insights or suggestions on what I might be missing or if there are any additional steps or considerations I should take into account to accurately reproduce the impact matrix plot? Thanks!


Create example of passing ARNs in CDK apps around

Done: https://docs.aws.amazon.com/cdk/latest/guide/use_cfn_template.html


Do not create scheduler for channel & trigger (till we move to v2)

Signed-off-by: aavarghese<EMAIL_ADDRESS>Controller logs were getting filled with info logs for channel & trigger due to absence of v2 sts dispatchers (that will be added only when we move to HA v2 version). We currently only have source HA STS dispatchers that run the replica scheduler. So commenting this out temporarily.
{"level":"info","ts":"2022-06-09T07:52:03.927Z","logger":"kafka-broker-controller","caller":"state/state.go:178","msg":"failed to get statefulset","knative.dev/pod":"kafka-controller-7bcd565879-9lc6c","error":"statefulsets.apps \"kafka-channel-dispatcher\" not found"}
{"level":"info","ts":"2022-06-09T07:52:03.927Z","logger":"kafka-broker-controller","caller":"statefulset/autoscaler.go:122","msg":"error while refreshing scheduler state (will retry){error 26 0  statefulsets.apps \"kafka-channel-dispatcher\" not found}","knative.dev/pod":"kafka-controller-7bcd565879-9lc6c"}
{"level":"info","ts":"2022-06-09T07:52:03.927Z","logger":"kafka-broker-controller","caller":"state/state.go:178","msg":"failed to get statefulset","knative.dev/pod":"kafka-controller-7bcd565879-9lc6c","error":"statefulsets.apps \"kafka-broker-dispatcher\" not found"}
{"level":"info","ts":"2022-06-09T07:52:03.927Z","logger":"kafka-broker-controller","caller":"statefulset/autoscaler.go:122","msg":"error while refreshing scheduler state (will retry){error 26 0  statefulsets.apps \"kafka-broker-dispatcher\" not found}","knative.dev/pod":"kafka-controller-7bcd565879-9lc6c"}

/cc @matzew @pierDipi

/cc @matzew @pierDipi


Notification Feature Suggestion

Dear Anton & Team,.
I can see the email notification system being built, so was just thinking would the notification recipient email be set per device or per userid.
As per what I feel, per device would be a good idea, when we have groups/and possibility of a single device being under multiple accounts, thus users would be able to specify who to alert for a particular device.
-Sorry wasnt sure if I should post it here or in forum :) so did it here..

User can choose to receive notifications for a device or a group of devices.

Sorry, correction. Geofencing events are per device and groups. Other events are just for all user devices.
@Abyss777, please correct me if I'm wrong.

@tananaev you are rigth. Geofences are linked to devices and groups, and can be unlinked from user. Other events will be notified for all user devices.
@nefertiti007  Thanks for the useful idea, we will think about how to do that.

@Abyss777 & @tananaev Thanks for considering my feedback.. :)

@jaimzj, please explain the use case for this feature.

The reason why I suggested having the notifications recipients configurable on per device basis are as following.

If a single device is assigned to multiple user accounts in current scenario I believe only the useraccount holder will receive notifications,. however allowing per device setting, will allow admin/users to define each device who should get the notifications.

Configuring alerts recipients on per device also would allow traccar admins/business users with multiple vehicles to alert the right recipients based on the vehicle/device they are responsible.

In this case Group will work,. However only if a Single Device does not fall under Multiple Groups.

This feature is for business installations more I guess.

There is fleet of tracks. There are some operators who see all devices, but they should not get tones of notifications from every device. There are some responsible managers who have to watch their group of devices and get all notifications.
There is a boss who want to see everything, but do not want get notifications about everything except his own car. There is some special persons who responsible for every device and only them should get notifications.

May be It looks like crutch, and we should consider deep improvement of device linking and divide it on three types like watch/edit/notifiy and it is a big work.

@jaimzj

Every device can decide if he wants to receive notification. Device can be shared between number of people.

It's already possible through different user accounts. I don't see much value in adding another option to do the same thing. It would just complicate the server.

I don't understand this point.

@Abyss777

Makes some sense, but I think in most cases managers would be interested only in their devices.

It's possible to have a company account and a personal account with a single car.

I guess it makes sense to allow users to select from which devices they want to receive notifications, but I don't think #2436 is the best solution for this particular problem.

@tananaev
You are right #2436 looks like quick fix, we need some more base improvement to choose notification by device/group.
Some analog of linking device -> user and group -> user but which works for notifications.

Agree. One option would be to extend user_device table with a flag.

@jaimzj, please correct me if I am wrong.
What I understood from @jaimzj is he wants to assign multiple email recipients to each device.
The recipients may not be the only users registered with traccar but User/Admin can add new email ids as recipients for that device to send notification.

I want to know a use case where non-users would want to receive notifications.

Hello to all @tananaev @Abyss777  @jaimzj
Well, in bussines, when we have a clients, and this have another clients, we need to have different email, example
I´m the admin for a group, and i have 10 clients, this 10 clients need to received notification of they devices, but we can config this, because we dont have different place to put different email address.
is a power useful option in the platform and many person go to be happy with this, person like me... hehehhe

Hello, @djbo1982
There is better solution for your use case. I would call it User Manager/Management and it will be available in next release.

@tananaev
I´m reading that new solution…. look very good… and go to solved many problem for us…
I love your work Man… we are so happy for meet your work
El 05/01/2017, a las 23:10, Andrey Kunitsyn <notifications<EMAIL_ADDRESS>escribió:
Hello, @djbo1982https://github.com/djbo1982
There is better solution for your use case. I would call it User Manager/Management and it will be available in next release.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/tananaev/traccar/issues/2061#issuecomment-276270528, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AWl_k5QoDb6IqSQbGwVD_NgCKajzmJANks5rXrQ4gaJpZM4JAb_2.

@djbo1982, you should thank @Abyss777 for it. He worked on the implementation. I just reviewed it and gave some suggestions.

Sure… @Abyss777https://github.com/Abyss777
I´m Just changing my installation of Windows server to Ubuntu, i use windows for many years, but this night i decided to change all…
To many problem to install my server to used another system (NOT GPS) but, im ready to begin with UBUNTU…
And yes, this new version have a useful thing for managed float, because now, we don’t have to much to offers to others. and the stability and the develop of traccar let us to implement new thing to offer to the clients…
im learn to how used as well GitHub, because at today, i don’t know how i need to make and change to test your update develop.
Im use Azure from microsoft VPN and Amazon Web Services for all my project
if you need help to test the system, only ask me, i have all time for this
El 05/02/2017, a las 02:17, Anton Tananaev <notifications<EMAIL_ADDRESS>escribió:
@djbo1982https://github.com/djbo1982, you should thank @Abyss777https://github.com/Abyss777 for it. He worked on the implementation. I just reviewed it and gave some suggestions.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/tananaev/traccar/issues/2061#issuecomment-277180653, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AWl_kw0kJkH6yP39BL6vW2i54-Uycrmbks5rYtSCgaJpZM4JAb_2.


Compiles on Android

Android ndk toolchain is missing ifaddrs.h for some reason.
I've added implementation from here: https://github.com/morristech/android-ifaddrs
Not sure it is right to ship that header with yojimbo, because we don't have any build scripts or samples for Android. User must add android/ifaddrs to header search paths in the chosen build system.
There is also sockaddr_storage that is redefined as a macro and I had to change include order so that system libraries go before yojimbo_address.h.
Library works flawlessly on Android.

Thanks!


RVC not working

i keep getting this weird error despite having my mlodel in a folder in the v2v rvc folder
Traceback (most recent call last):
File "C:\aistuffsies\xttsgui\xtts-webui\venv\Lib\site-packages\gradio\queueing.py", line 489, in call_prediction
output = await route_utils.call_process_api(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\aistuffsies\xttsgui\xtts-webui\venv\Lib\site-packages\gradio\route_utils.py", line 232, in call_process_api
output = await app.get_blocks().process_api(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\aistuffsies\xttsgui\xtts-webui\venv\Lib\site-packages\gradio\blocks.py", line 1570, in process_api
data = self.postprocess_data(fn_index, result["prediction"], state)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\aistuffsies\xttsgui\xtts-webui\venv\Lib\site-packages\gradio\blocks.py", line 1456, in postprocess_data
outputs_cached = processing_utils.move_files_to_cache(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\aistuffsies\xttsgui\xtts-webui\venv\Lib\site-packages\gradio\processing_utils.py", line 265, in move_files_to_cache
return client_utils.traverse(data, _move_to_cache, client_utils.is_file_obj)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\aistuffsies\xttsgui\xtts-webui\venv\Lib\site-packages\gradio_client\utils.py", line 923, in traverse
new_obj[key] = traverse(value, func, is_root)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\aistuffsies\xttsgui\xtts-webui\venv\Lib\site-packages\gradio_client\utils.py", line 919, in traverse
return func(json_obj)
^^^^^^^^^^^^^^
File "C:\aistuffsies\xttsgui\xtts-webui\venv\Lib\site-packages\gradio\processing_utils.py", line 257, in _move_to_cache
temp_file_path = move_resource_to_block_cache(payload.path, block)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\aistuffsies\xttsgui\xtts-webui\venv\Lib\site-packages\gradio\processing_utils.py", line 234, in move_resource_to_block_cache
return block.move_resource_to_block_cache(url_or_file_path)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\aistuffsies\xttsgui\xtts-webui\venv\Lib\site-packages\gradio\blocks.py", line 258, in move_resource_to_block_cache
temp_file_path = processing_utils.save_file_to_cache(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\aistuffsies\xttsgui\xtts-webui\venv\Lib\site-packages\gradio\processing_utils.py", line 170, in save_file_to_cache
temp_dir = hash_file(file_path)
^^^^^^^^^^^^^^^^^^^^
File "C:\aistuffsies\xttsgui\xtts-webui\venv\Lib\site-packages\gradio\processing_utils.py", line 102, in hash_file
with open(file_path, "rb") as f:
^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: 'C:\aistuffsies\xttsgui\xtts-webui\output\rvc_mitest_20240213_183208.wav'

i reinstalled everything on a 3,10 env and now i get this error ...
: 31, 'attn_type': '', 'pos_enc_type': 'abs', 'fp16': False}
2024-02-13 20:53:55 | INFO | rvc_python.modules.vc.pipeline | Loading rmvpe model - base_models/rmvpe.pth
C:\aistuffsies\try\xtts-webui\venv\rvc_venv\lib\site-packages\rvc_python\modules\vc\pipeline.py:240: RuntimeWarning: invalid value encountered in divide
weight /= weight.sum(axis=1, keepdims=True)
2024-02-13 20:53:57 | WARNING | rvc_python.modules.vc.modules | Traceback (most recent call last):
File "C:\aistuffsies\try\xtts-webui\venv\rvc_venv\lib\site-packages\rvc_python\modules\vc\modules.py", line 184, in vc_single
audio_opt = self.pipeline.pipeline(
File "C:\aistuffsies\try\xtts-webui\venv\rvc_venv\lib\site-packages\rvc_python\modules\vc\pipeline.py", line 415, in pipeline
self.vc(
File "C:\aistuffsies\try\xtts-webui\venv\rvc_venv\lib\site-packages\rvc_python\modules\vc\pipeline.py", line 241, in vc
npy = np.sum(big_npy[ix] * np.expand_dims(weight, axis=2), axis=1)
IndexError: index -1 is out of bounds for axis 0 with size 0
Traceback (most recent call last):
File "C:\Users\shell\AppData\Local\Programs\Python\Python310\lib\runpy.py", line 196, in _run_module_as_main
return _run_code(code, main_globals, None,
File "C:\Users\shell\AppData\Local\Programs\Python\Python310\lib\runpy.py", line 86, in run_code
exec(code, run_globals)
File "C:\aistuffsies\try\xtts-webui\venv\rvc_venv\lib\site-packages\rvc_python_main.py", line 31, in
inferred_path = infer_file(
File "C:\aistuffsies\try\xtts-webui\venv\rvc_venv\lib\site-packages\rvc_python\infer.py", line 49, in infer_file
wavfile.write(opt_path, vc.tgt_sr, wav_opt)
File "C:\aistuffsies\try\xtts-webui\venv\rvc_venv\lib\site-packages\scipy\io\wavfile.py", line 771, in write
dkind = data.dtype.kind
AttributeError: 'tuple' object has no attribute 'dtype'

I cant event load RVC :D how did you make it ? where did you put the model i put in rvc but didnt worked

Guys now busy with work projects, no time to help you, as soon as I finish I will try to help you

I have a problem with RVC on Python 3.11. Running with 3.10 it goes away for me. Hope this helps.

Did you find a solution for this? Python 3.10 doesn't work either.

Since I'm using Python 3.10.6 and generating text2voice gives me a different error, figure I'd weigh in too. Cmd Log:
2024-03-11 23:44:07.284 | INFO     | scripts.tts_funcs:local_generation:355 - Processing time: 1.56 seconds.
2024-03-11 23:44:16 | INFO | fairseq.tasks.text_to_speech | Please install tensorboardX: pip install tensorboardX
File rmvpe.pt not found, start loading...
Traceback (most recent call last):
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\urllib3\connectionpool.py", line 793, in urlopen
    response = self._make_request(
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\urllib3\connectionpool.py", line 491, in _make_request
    raise new_e
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\urllib3\connectionpool.py", line 467, in _make_request
    self._validate_conn(conn)
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\urllib3\connectionpool.py", line 1099, in _validate_conn
    conn.connect()
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\urllib3\connection.py", line 653, in connect
    sock_and_verified = _ssl_wrap_socket_and_match_hostname(
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\urllib3\connection.py", line 806, in _ssl_wrap_socket_and_match_hostname
    ssl_sock = ssl_wrap_socket(
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\urllib3\util\ssl_.py", line 465, in ssl_wrap_socket
    ssl_sock = _ssl_wrap_socket_impl(sock, context, tls_in_tls, server_hostname)
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\urllib3\util\ssl_.py", line 509, in _ssl_wrap_socket_impl
    return ssl_context.wrap_socket(sock, server_hostname=server_hostname)
  File "C:\Users\admin\AppData\Local\Programs\Python\Python310\lib\ssl.py", line 513, in wrap_socket
    return self.sslsocket_class._create(
  File "C:\Users\admin\AppData\Local\Programs\Python\Python310\lib\ssl.py", line 1071, in _create
    self.do_handshake()
  File "C:\Users\admin\AppData\Local\Programs\Python\Python310\lib\ssl.py", line 1342, in do_handshake
    self._sslobj.do_handshake()
ConnectionResetError: [WinError 10054] An existing connection was forcibly closed by the remote host

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\requests\adapters.py", line 486, in send
    resp = conn.urlopen(
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\urllib3\connectionpool.py", line 847, in urlopen
    retries = retries.increment(
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\urllib3\util\retry.py", line 470, in increment
    raise reraise(type(error), error, _stacktrace)
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\urllib3\util\util.py", line 38, in reraise
    raise value.with_traceback(tb)
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\urllib3\connectionpool.py", line 793, in urlopen
    response = self._make_request(
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\urllib3\connectionpool.py", line 491, in _make_request
    raise new_e
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\urllib3\connectionpool.py", line 467, in _make_request
    self._validate_conn(conn)
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\urllib3\connectionpool.py", line 1099, in _validate_conn
    conn.connect()
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\urllib3\connection.py", line 653, in connect
    sock_and_verified = _ssl_wrap_socket_and_match_hostname(
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\urllib3\connection.py", line 806, in _ssl_wrap_socket_and_match_hostname
    ssl_sock = ssl_wrap_socket(
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\urllib3\util\ssl_.py", line 465, in ssl_wrap_socket
    ssl_sock = _ssl_wrap_socket_impl(sock, context, tls_in_tls, server_hostname)
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\urllib3\util\ssl_.py", line 509, in _ssl_wrap_socket_impl
    return ssl_context.wrap_socket(sock, server_hostname=server_hostname)
  File "C:\Users\admin\AppData\Local\Programs\Python\Python310\lib\ssl.py", line 513, in wrap_socket
    return self.sslsocket_class._create(
  File "C:\Users\admin\AppData\Local\Programs\Python\Python310\lib\ssl.py", line 1071, in _create
    self.do_handshake()
  File "C:\Users\admin\AppData\Local\Programs\Python\Python310\lib\ssl.py", line 1342, in do_handshake
    self._sslobj.do_handshake()
urllib3.exceptions.ProtocolError: ('Connection aborted.', ConnectionResetError(10054, 'An existing connection was forcibly closed by the remote host', None, 10054, None))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\admin\AppData\Local\Programs\Python\Python310\lib\runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "C:\Users\admin\AppData\Local\Programs\Python\Python310\lib\runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\rvc_python\__main__.py", line 31, in <module>
    inferred_path = infer_file(
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\rvc_python\infer.py", line 30, in infer_file
    download_rvc_models(lib_dir)
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\rvc_python\download_model.py", line 27, in download_rvc_models
    response = requests.get(url)
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\requests\api.py", line 73, in get
    return request("get", url, params=params, **kwargs)
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\requests\api.py", line 59, in request
    return session.request(method=method, url=url, **kwargs)
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\requests\sessions.py", line 589, in request
    resp = self.send(prep, **send_kwargs)
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\requests\sessions.py", line 725, in send
    history = [resp for resp in gen]
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\requests\sessions.py", line 725, in <listcomp>
    history = [resp for resp in gen]
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\requests\sessions.py", line 266, in resolve_redirects
    resp = self.send(
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\requests\sessions.py", line 703, in send
    r = adapter.send(request, **kwargs)
  File "C:\xtts-webui\venv\rvc_venv\lib\site-packages\requests\adapters.py", line 501, in send
    raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: ('Connection aborted.', ConnectionResetError(10054, 'An existing connection was forcibly closed by the remote host', None, 10054, None))
Traceback (most recent call last):
  File "C:\xtts-webui\venv\lib\site-packages\gradio\queueing.py", line 489, in call_prediction
    output = await route_utils.call_process_api(
  File "C:\xtts-webui\venv\lib\site-packages\gradio\route_utils.py", line 232, in call_process_api
    output = await app.get_blocks().process_api(
  File "C:\xtts-webui\venv\lib\site-packages\gradio\blocks.py", line 1570, in process_api
    data = self.postprocess_data(fn_index, result["prediction"], state)
  File "C:\xtts-webui\venv\lib\site-packages\gradio\blocks.py", line 1456, in postprocess_data
    outputs_cached = processing_utils.move_files_to_cache(
  File "C:\xtts-webui\venv\lib\site-packages\gradio\processing_utils.py", line 265, in move_files_to_cache
    return client_utils.traverse(data, _move_to_cache, client_utils.is_file_obj)
  File "C:\xtts-webui\venv\lib\site-packages\gradio_client\utils.py", line 919, in traverse
    return func(json_obj)
  File "C:\xtts-webui\venv\lib\site-packages\gradio\processing_utils.py", line 257, in _move_to_cache
    temp_file_path = move_resource_to_block_cache(payload.path, block)
  File "C:\xtts-webui\venv\lib\site-packages\gradio\processing_utils.py", line 234, in move_resource_to_block_cache
    return block.move_resource_to_block_cache(url_or_file_path)
  File "C:\xtts-webui\venv\lib\site-packages\gradio\blocks.py", line 258, in move_resource_to_block_cache
    temp_file_path = processing_utils.save_file_to_cache(
  File "C:\xtts-webui\venv\lib\site-packages\gradio\processing_utils.py", line 170, in save_file_to_cache
    temp_dir = hash_file(file_path)
  File "C:\xtts-webui\venv\lib\site-packages\gradio\processing_utils.py", line 102, in hash_file
    with open(file_path, "rb") as f:
FileNotFoundError: [Errno 2] No such file or directory: 'C:\\xtts-webui\\output\\reference_PatrickWarburton_12.wav'

Did you fix the RVC problem ?
For me when i select my RVC pth file and Run, no error but my CPU is 100% and my graphic card 0 , i stopped after 1 hour

Its been sat doing something but not doing anything for about 10 minutes here... i am sure its errored as rvc is usually fast

I have the same issue. it sits there with this 2024-05-13 11:09:40 | INFO | rvc_python.modules.vc.pipeline | Loading rmvpe model - base_models/rmvpe.pth
like its trying to load the basemodel but its failing to do so, it just pins the cpu at 100% and does nothing.
i tried the other modes like crepe and harvest but it does the same thing . i tried giving it the rmvpe.pth model and put it in xtts-webui\models but it didnt make a difference. https://github.com/Vali-98/XTTS-RVC-UI this works fine and its basicly doing the same thing but it doesn't have the same controll over the intial tts generation so I would like to get this xtts-webui to work with rvc

I have the same issue. it sits there with this 2024-05-13 11:09:40 | INFO | rvc_python.modules.vc.pipeline | Loading rmvpe model - base_models/rmvpe.pth like its trying to load the basemodel but its failing to do so, it just pins the cpu at 100% and does nothing. i tried the other modes like crepe and harvest but it does the same thing . i tried giving it the rmvpe.pth model and put it in xtts-webui\models but it didnt make a difference. https://github.com/Vali-98/XTTS-RVC-UI this works fine and its basicly doing the same thing but it doesn't have the same controll over the intial tts generation so I would like to get this xtts-webui to work with rvc

+1 on this - came here wondering if it was an issue at my end, I'm clearly not alone.

Same issue for me running on python 3.10.9, v2.0.2 on xtts.

Same for me. It doesn't throw an error, but just computes endlessly until manually stopped.

Did anyone ever figure this out? This seems like it should be a pretty simple fix...

If you are stucking at:
2024-05-13 11:09:40 | INFO | rvc_python.modules.vc.pipeline | Loading rmvpe model - base_models/rmvpe.pt
Please note readme.txt on root repo dir:

WARNING: for some reason some people have RVC hangs, the reason is that you are using the index file, try deleting it and restart the interface
Speaker models you can put in webui/speakers folder or add them through the interface

That works for me

If you are stucking at: 2024-05-13 11:09:40 | INFO | rvc_python.modules.vc.pipeline | Loading rmvpe model - base_models/rmvpe.pt Please note readme.txt on root repo dir:

WARNING: for some reason some people have RVC hangs, the reason is that you are using the index file, try deleting it and restart the interface
Speaker models you can put in webui/speakers folder or add them through the interface

That works for me

This worked for me thanks


scantailor: Add original and two forks

Fix #2368

This is use case for versions bucket I think.

It's a little difficult to choose one survivor between scantailor-advanced and scantailor-universal.
Scantailor Advanced is more actively developing last year while Scantailor Universal just releases new version after long periods of inactivity.
And I made the choice. 😄


esp_flash_api fixes (IDFGH-5592)

As found in https://github.com/espressif/esp-idf/issues/7272, calling esp_flash_erase_region with len=0 would erase the whole flash because it would get to the erase loop and the length would underflow.  Fix to return ESP_OK to match behavior of other flash api functions.  Returning ESP_OK immediately without checking other arguments will mask other problems like memory corruption.  Add sanity checks to write/erase loops.

Thanks for the fix @negativekelvin!

Thanks for your contribution, and sorry for late reply, we have put the changes into our internal review queue, and the PR will be updated once the changes are available on GitHub. Thanks.


depth sensing

hello, i have installed the SDK,  when i try to run the depth sensing  example, only the RESOLUTION_VGA could be used. If i init the camera with other resolution params ,such as RESOLUTION_HD2K, RESOLUTION_HD1080, RESOLUTION_HD720, the program occurs error: cannot initialize the camera. Try another  resolution.
My program init the params below:
initParameters.depth_mode = DEPTH_MODE_MEDIUM;
initParameters.coordinate_units = UNIT_MILLIMETER; measurements)
initParameters.camera_resolution = RESOLUTION_HD2K;
initParameters.sdk_verbose = true;

Hi,
Can you specify the camera model (ZED or ZED-M), the SDK version and the OS  you are using.
Try the resolution with ZED Explorer to check if they are availalble. Make sure the camera is connected on a USB3.0 port otherwise only VGA resolution is available.

i found that the camera is connected on a USB2.0 port, so i change to another computer with usb3.0 port, then the  high RESOLUTION can be used. Thanks for your help.


Add support for Windows Named Pipe

What does this PR do?
This PR adds support for the  Windows Named Pipe.
Motivation
The .NET tracer currently runs in environment (AAS) where traces are sent to the agent through windows named pipe. The customers that have their apps in that environment are waiting for the profiler to work there too.
Additional Notes
Not on top of my head
How to test the change?

I build a custom version of libdatadog, linked it to the compiler.
Implement support for named pipe in the profiler
Setup the datadog agent to listen on windows named pipe by setting the environment variable DD_APM_WINDOWS_PIPE_NAME to \\.\pipe\datadogpipe\mypipe
Run the application

I check the profiler log and I saw the agent url is the named pipe:
[2022-08-23 22:01:41.691 | info | PId: 421300 | TId: 411900] Using agent endpoint windows:\\.\pipe\datadogpipe\mypipe
And saw in the dashboard my profiles:

I know nothing about Windows, but if it works for you, this looks fine to me!

We will put some tests in our hand with named pipe to ensure that it works accordingly (once released)


i18n(ja): Add Japanese translation guide

What kind of changes does this PR include?

New or updated content

Description

Add Japanese translation guide

Thank you! What a wonderful Merry Christmerge present, @kyosuke! 🎄 🎁
I know this hasn't been reviewed, but let's just get it in live, and people can PR any changes, additions or corrections!  🥳


While reading from DB, skip the extra fields in JSON(TolerantReader)

Hi,
How to skip the extra fields(TolerantReader) in JSON while converting to Java object ?
In ObjectMapper, we pass FAIL_ON_UNKNOWN_PROPERTIES as false. is there a way to do this in this lib ?
https://martinfowler.com/bliki/TolerantReader.html

You can customize the ObjectMapper as explained in this article. That way, you can surely achieve your goal.


Feature/refactor estimators

IMPORTANT: Please search among the Pull requests before creating one.
Title

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] New feature (non-breaking change which adds functionality)

Description

TODO
How has this been tested?

TODO
Have release notes been modified?

N/A
Closes

closes #564

@michalk8, did you check that **kwargs has a type hint everywhere? Or should we open an issue for it s.t. we don't forget about it?

@michalk8, do you have a rule for when to define enums and when not?

@michalk8, for the argument backend you use the type hint
backend: Backend_t = _DEFAULT_BACKEND

but for others something along the lines of
argument: Literal["a", "b"] = CustomEnum.a

Any reason why we cannot go with the first option everywhere?

Thanks @WeilerP for this very thorough code review!

There appears to be a problem with color matching. I use the pancreas data (Fig. 1). I use a GPCCA estimator initialized from a PseudotimeKernel. I compute 5 macrostates and show their top 30 cells each (Fig. 2). Next, I use run g.predict(n_states=3, method='top_n') to get 3 terminal states. The colors are still wong, and, surprisingly, have even been changed again from how they have been assigned in the macrostates case (Fig. 3).
Fig. 1

Cluster colors
Fig. 2

5 macrostates. Names are right, colors are wrong.
Fig. 3

Names right, colors have been shuffled again.
I'm sending you a notebook to reproduce on MM (@michalk8)

Note that this does not happen when I plot macrostates or terminal states using a continuous color scale, i.e. discrete=False.

Can confirm that your commit fixed the coloring issue.

This can be merged from my side.


Bypass Fa3 autism :(

thanks use curl_cffi

Thanks for this PR, but there are a couple crucial issues with it.

I will not be using a blocking http method in an async environment. If i recall correctly, that curl lib does support async, and that support should be used here.
commenting old code out is not a good idea. Please remove the code that is no longer used, and test it.
You're changes don't just effect http.py, so other files would have to be modified as well.

@cibere I hope you enjoy the fact that I really like this repo.
Yes its really trashy , but it does work , I promise you
I tried, I am able to connect , I am able to get the Fa3 corrected
I am not a developer , and my english is too broken to become one too

I just can't put this in the main repo in the state its in. Though once I'm home from camping I can probably fix it.

@cibere I hope you enjoy the fact that I really like this repo.
Yes its really trashy , but it does work , I promise you
I tried, I am able to connect , I am able to get the Fa3 corrected
I am not a developer , and my english is too broken to become one too

I just can't put this in the main repo in the state its in. Though once I'm home from camping I can probably fix it.

Oh no this was not a request to pull , I just showed you can use curl_cffi
Yes you're right its a really put in thing , for me it works flawlessly , but I guess you can just to show
anyways if you can get this cffi thing into an aio libary it would be amazing ..
its a way that works, but it breaks anything else - but shout out for you for this kick.py thing
https://github.com/yifeikong/curl_cffi/blob/master/curl_cffi/aio.py
god knows what its all about , should be there
https://github.com/yifeikong/curl_cffi/blob/1f3285cef2ef0cb6597ef25285832e59325a014a/curl_cffi/requests/session.py#L294C1-L296
it is a library , but I have no idea what the hell they do
cffi is something that cross do C and python idk man
it does act like requests tho

@cibere im unsure if curl_cffi works too well on windows

@cibere im unsure if curl_cffi works too well on windows

Oh? What operating systems did you test it on?

@cibere im unsure if curl_cffi works too well on windows

Oh? What operating systems did you test it on?

arch linux because I am an hipster

bump


Improved tooltip: functions, tuples, etc

This is an attempt to fix #631.
I have implemented the behavior specified in the issue, allowing tooltip for f when Shift-Tab is pressed inside a function call f(x, y, ... |) or right outside the call f(x, y, ...)|. | is cursor. Detailed behavior is in docstring.
The current implementation has some string hacks which I consider ugly (explained thoroughly, I hope, in docstrings). If I can dig deeper, I prefer an implementation using a proper Julia language parser. Maybe one that comes from Julia itself.
In any case, I tested with quite a few of my Notebooks, and they all seem to work well.
I forgot to squash the commits, though.

Would be good to add a test/completion.jl with some tests for get_token.

I agree that it would be nice to use the Julia parser; the basic issue is that the user might be asking for help on code they haven't finished writing yet…

I will try quickly adding some test cases. It's the first time I develop Julia packages so I will need to check out some docs...

I have changed behavior slightly to make sure the basic x + y + z works, giving x, y, and z respectively. Further making the completion more robust might be out of scope for my goals, so I propose to merge this as an intermediate solution which provides a slight quality of life improvement. It should be good enough for many common cases.

As a note, the julia tokenizer might be helpful for a better solution:

Do you have any plan on merging? I think the current state is good enough for an intermediate improvement.

Any updates?

Any activities on this? @stevengj can this be merged, or are there some feedback?

Any more reviews?

Do you think this is mergable or is it too hacky to be put into mainline? I have been waiting for a decision for quite a while.


How is occlusion determined?

Hi, excellent work. In the paper you mention you are given occlusion O, but I am wondering how you obtain this.

Hi, bounding box and occlusion as input information B and O are based on the information obtained from existing a priori access. We recommend to automate the judgment of occlusion information in the image based on some existing image understanding work. Of course, you can specify the occlusion information by your own understanding of the image to facilitate the subsequent complementary processing.


MyLoveNovel shows "cannot read property "push" of undefined"

Source information
MyLoveNovel
Steps to reproduce
1.Go to library or updates tab and pull down to update.
2.Wait until the app fetches data for a novel sourced from MyLoveNovel
Expected behavior
Should updates novels and the only prompt should be "Library updated"
Actual behavior
Toast notification showing
"cannot read property "push" of undefined"
LNReader version
1.1.8
Android version
Android 8.1
Other details

Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.
[X] I have written a short but informative title.
[X] I have updated the app to version 1.1.8.
[X] I have updated all installed extensions.
[X] If this is an issue with the app itself, I should be opening an issue in the app repository.
[X] I will fill out all of the requested information in this form.

Browse works fine when searching novels but once a novel is picked a toast notification saying cannot read property 'push'of undefined also shows up when fetching metadata

They have updated their website's url to https://www.novelhold.com/, so the source is broken.

Oh. I understand. I guess migrating the novels will be the only workaround.


feat: add C ndarray interface and refactor implementation for stats/base/dnanmax

Resolves None
Description

What is the purpose of this pull request?

This pull request:

adds C ndarray interface for stats/base/dnanmax
refactors JavaScript implementation
refactors tests, docs, benchmarks and examples.

Related Issues

Does this pull request have any related issues?

This pull request:

resolves None.

Questions

Any questions for reviewers of this pull request?

No.
Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

No.
Checklist

Please ensure the following tasks are completed before submitting this pull request.

[x] Read, understood, and followed the contributing guidelines.

@stdlib-js/reviewers

Here, the JavaScript benchmarks and examples are not refactored yet as I need some advice on how to generate random arrays with NaN values. I've left them untouched for now.


Cannot read properties of undefined (reading 'length;)

Error occurred when opening Drop plan.

Hi @Alfadbhq,
I see on the logs this failure which relates to a task that spans beyond the sprint working days.
I added more logs to try to better understand the root cause.
Will keep you updated :-).

Hi @sgtwilko,
It's working now as expected.  Thanks for the immediate resolution.


Use npm dependency badge on david-dm.org

gemnasium.com didn't update, the dependency was updated for a long time

Wrong place.


Bump Dependencies #1692007558

Bumps dependencies for product-is. Link : https://github.com/wso2/product-is/actions/runs/1692007558

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.jenkins-is-staging seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Images from allowed registry

bash-4.2# kubescape version
Skipping version check
Your current version is: v1.0.137

I tried to set a local config file that looks like this:
bash-4.2# cat ~/.kubescape/config.json
{ "imageRepositoryAllowList": "ecr.*amazonaws.com,.*.gcr.io,*azurecr.io,.*my-artifact-repo.*" }

I also tried a file that looks like this:
{
  "imageRepositoryAllowList": [
    "ecr.*amazonaws.com",
    ".*.gcr.io,*azurecr.io",
    ".*my-artifact-repo.*"
  ]
}

neither one seemed to work the check is still failing:
any ideas?

Hi @clintmod and thank you for asking.
First, you will need to update your kubescape version.
Next, do as following:

Download the control configuration file
kubescape download controls-inputs

The configuration file will be downloaded and stored in the default cache directory -> ~/.kubescape/controls-inputs.json

Edit the ~/.kubescape/controls-inputs.json so it will suit your needs

Scan your cluster with the --controls-config ~/.kubescape/controls-inputs.json
e.g.:
kubescape scan --controls-config ~/.kubescape/controls-inputs.json  --enable-host-scan --submit

I don't have an account to download anything from… trying to set this up manually

Closing since I have not received a response. If you wish, feel free to contact me personally-<EMAIL_ADDRESS>


SDL2: 2.0.22 -> 2.24.0

Description of changes

Foremost, they changed the versioning, the patch in the version was promoted to minor. 2.0.22 == 2.22.0;

Full changelog in https://github.com/libsdl-org/SDL/releases/tag/release-2.24.0

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

Closes #188794.

Breaks the build of ffmpeg on aarch64-darwin:
ERROR: sdl2 requested but not found

Shouldn't break according to their changelog, could it be the building of pipewire's ffmpeg? If that's the case, we have an override in top-level/all-packages.nix, to pipewire.ffmpeg.SDL2.pipewireSupport = false to stop a cycle.

No, it's the regular ffmpeg derivation. SDL2 itself builds just fine.

No, it's the regular ffmpeg derivation. SDL2 itself builds just fine.

Seems like my patch will need a little more tweaking to produce the same pkg-config as the previous version.

Haven't tested it, but https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=e5163b1d34381a3319214a902ef1df923dd2eeba should fix the ffmpeg issue

Haven't tested it, but https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=e5163b1d34381a3319214a902ef1df923dd2eeba should fix the ffmpeg issue

Thanks, @vs49688, I was getting nuts thinking it was something wrong in the pkgconfig, didn't think of checking the version condition.

Tested with space-cadet-pinball (builds and plays), ffmpeg (builds, alias of ffmpeg_4), and ffmpeg_5 (builds).

@ofborg eval

@PedroHLC Can you check the eval errors?

@ofborg eval


Don’t add to history if action is a noop?

Quick feature request and curious of your thoughts—if the reducer returns the same state (via object reference equality) after a dispatch, then it appears that a new state is added to the history. Would it make sense to change it to not add to the history in this scenario? Alternatively, a custom grouping function could control this one way or the other, e.g., https://github.com/frontendphil/react-undo-redo/issues/331

@mrcoles, great idea! I've added the feature you've described. Since this is a breaking change to the behavior of this lib, I've published the changes in a new major version 3.0.0.

Awesome, thanks!


Wezterm strategy doesn't work again if test pane is closed

When using the wezterm strategy, after the initial test pane is split, if that pane is closed
To reproduce

Run :TestNearest (pane is successfully split)
Exit the pane (CTRL-D)
Run :TestNearest again (pane will not re-open)

Versions:
nvim: 0.9.5
vim-test: master
wezterm: 20230712-072601-f4abf8fd

Hey @jsilasbailey.
Hope you're doing well!
I came across this issue after running into this same behavior myself and looking for a solution. I haven't tested it much but clearing the test#wezterm#pane_id allows closing and re-opening a pane to work as expected. I was expecting it to break in other ways, but I haven't run into anything yet in my minimal testing. If you're still using this combo this may work for you as well as a temporary workaround.
  init = function()
    vim.g["test#custom_strategies"] = {
      wezterm_wrapped = function(cmd)
        vim.fn["test#strategy#wezterm"]("clear; " .. cmd .. "\n")
        vim.g["test#wezterm#pane_id"] = nil
      end,
    }

    vim.g["test#strategy"] = "wezterm_wrapped"
  end,

Using neovim_sticky as well and facing this error.


No symbols are extracted when generating documentation (w/ the CLI) while the package uses a local XCFramework reference

I ran into an odd situation where I when I attempted to use swift-docc-plugin to generate documentation archives (either converted for static HTML or the original DocC archives), the archives would end up with 0 symbols within them.
An example of this kind of project is OSS in github: automerge-swift and the relevant pieces that make the difference here is a local reference to an XCFramework. The relevant stanza of Package.swift to illustrate:
   .binaryTarget(
      name: "automergeFFI",
      path: "./automergeFFI.xcframework.zip"
    ),
    .target(
      name: "AutomergeUniffi",
      dependencies: ["automergeFFI"],
      path: "./AutomergeUniffi"
    ),
    .target(
      name: "Automerge",
      dependencies: ["AutomergeUniffi"]
    ),

I dug through this down into SwiftPM, where the symbols are extracted. The relevant process call to do the extraction isn't available using -v or -vv output from swift package, but is in the form of:
/Applications/Xcode-14.3_beta_2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift-symbolgraph-extract -module-name Automerge -target arm64-apple-macosx10.15 -I /Users/heckj/src/automerge-swifter/.build/arm64-apple-macosx/debug -sdk /Applications/Xcode-14.3_beta_2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk -F /Applications/Xcode-14.3_beta_2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks -I /Applications/Xcode-14.3_beta_2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/usr/lib -L /Applications/Xcode-14.3_beta_2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/usr/lib -module-cache-path /Users/heckj/src/automerge-swifter/.build/arm64-apple-macosx/debug/ModuleCache -v -minimum-access-level public -skip-inherited-docs -omit-extension-block-symbols -output-dir /Users/heckj/src/automerge-swifter/temp

This script doesn't reference the local XCFramework directories at all, resulting in the whole extraction process failing with out propagating up a failure (as opposed to a "no symbols" scenario, which seems like a correct, non-failure response for an empty swift file kind of setup).
Building the package with this structure works without issue - so it seems that the core issue under the covers is that the extraction of symbols uses different logic to build up the includes, or pre-loads a module cache, where the symbol extraction doesn't do that. Therefore a workaround exists to run a build to explicitly pull our the symbols, and then run docc directly with a reference to that manually generated symbol cache.
This issue only appears to happen when using a local XCFramework reference. When using a binaryTarget with a remote reference and hash, it "does the right thing" with preloading a module cache or including the relevant directories (not sure which).
Checklist

[x] If possible, I've reproduced the issue using the main branch of this package.
[X] This issue hasn't been addressed in an existing GitHub issue.

Expected behavior
documentation archive to contain symbols
Actual behavior
documentation archives generated with any internal content, but no symbols are included within them.
Steps to Reproduce
The branch debug-docc-plugin on the repository https://github.com/heckj/automerge-swifter/ illustrates the issue with a script:
git clone https://github.com/automerge/automerge-swift -b debug-docc-plugin
cd automerge-swift
./scripts/build-xcframework.sh # NOTE: requires Rust to be installed to build this!
./test-docc-script.bash

Example output of script:
Building for debugging...
[54/54] Linking snippet-extract
Build complete! (4.26s)
Generating documentation for 'Automerge'...
symbol graph options: 'SymbolGraphOptions(minimumAccessLevel: PackagePlugin.PackageManager.SymbolGraphOptions.AccessLevel.public, includeSynthesized: true, includeSPI: false, emitExtensionBlocks: false)'
Building for debugging...
[15/15] Compiling Automerge value.swift
Build complete! (2.35s)
target symbol graph directory path: '/Users/heckj/Desktop/foo/automerge-swifter/.build/arm64-apple-macosx/extracted-symbols/automerge-swifter/Automerge'
snippet extractor provided, attempting to generate snippet symbol graph
no snippet symbol graphs generated
docc archive output path: '/Users/heckj/Desktop/foo/automerge-swifter/.build/plugins/Swift-DocC/outputs/Automerge.doccarchive'
docc invocation: '/Applications/Xcode-14.3_beta_2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/docc convert /Users/heckj/Desktop/foo/automerge-swifter/Sources/Automerge/Automerge.docc --fallback-bundle-identifier com.github.automerge.automerge-swifter --output-path ./docs --emit-digest --transform-for-static-hosting --hosting-base-path automerge-swifter --fallback-display-name Automerge --additional-symbol-graph-dir /Users/heckj/Desktop/foo/automerge-swifter/.build/arm64-apple-macosx/extracted-symbols/automerge-swifter/Automerge'
Converting documentation...
Conversion complete! (0.26s)
Generated DocC archive at '/Users/heckj/Desktop/foo/automerge-swifter/docs'
Generated        0 identifiers/symbols

Swift-DocC Plugin Version Information
Swift-DocC plugin version: 1.1.0, and main (6a8f81a21df0aef44513f5ce25b58ae758347789)
Swift Compiler version: ```
swift-driver version: 1.75.1 Apple Swift version 5.8 (swiftlang-<IP_ADDRESS>.11 clang-14<IP_ADDRESS>.100)
Target: arm64-apple-macosx13.0

Encounter the same issue #80