For windows, the package doesn't seems to be working

The npm package is not working on windows environment.
Can you please see what is causing this ?

Fixed in 1.0.4


foreach doesn't give you a filled in key value

Hi there, I'm trying to get at some values that are in keys which I may or may not know the full path of. When using forEach I need to know the key's value but it comes back as blank every time, for example in this goplayground - https://play.golang.org/p/YEVfzdSPatX
This doesn't happen if you use Parse(json).ForEach() with no query. Any idea why this is happening?

Hi.
The reason that it's not working is becuase, for this json
{"name.last":"Prichard","age":47}

the operation
gjson.Get(json, `name\.*`)

returns
"Prichard"

which is equivlent to
gjson.Parse("Prichard").ForEach(key, value gjson.Result)

Thus the original key is lost on the initial gjson.Get

Right...so...if I wanted to get the key, how would I go about it?

I don't really understand why that should result in the foreach not having a filled in key.

A gjson.Get() call finds the value belonging to the path. In your case it finds "Prichard". The "name.last" key is not a part of the result.
When you call ForEach on the result, you are effectively calling ForEach on the simple JSON string "Prichard".

how would I go about it?

Use the ForEach around the json member that is the parent to the target children's keys.
json := `{"name.last":"Prichard","age":47}`

gjson.Parse(json).ForEach(func(key, value gjson.Result) bool {
	if strings.HasPrefix(key.String(), "name.") {
		println(key.String())
		println(value.String())
	}
	return true
})

// Output:
// name.last
// Prichard

https://play.golang.org/p/1nkw9wzY4SR

Hi @Godley,
I'm closing this issue because it's been a few weeks without an update, but feel free to reopen if needed. Thanks :)


Qt ban4

last final fixes

i cherry picked https://github.com/Diapolo/bitcoin/commit/550c8047bc40831c5f7717a2d83864556b423c29. The other commit is controversial (i don't see the benefit of row coloring). It looks like that something is selected.
And we came to an agreement to not add new features into this PR. :)

@jonasschnelli You are right, well this pull has my ACK (and it can be improved later)!
ACK

closing, i think this is solved out


'ConnectionRefusedError' when GPU activated in the notebook

It works fine if the GPU in colab is turned off. However, after I activate the GPU, 'ConnectionRefusedError'  occurs to me.

Hello @AndyLizd, Welcome to the colab-ssh community !
Thank you for putting the time to submit the issue. :)
At first glance, I believe you have a similar issue to an old one, could you please check this issue #42 and tell me if it helps.
Have a nice day :)

Thank you, the problem is solved.


Edition Based Method Disambiguation: Preventing inference ambiguity breakages with extension trait methods

Rendered

This RFC proposes introducing an edition field to stability attributes on APIs in the standard libraries and using these edition fields to prevent breakage when newly introduced standard library methods share the same name with pre-existing methods on extension traits defined in downstream libraries.
cc @rust-lang/libs-api and @rust-lang/compiler since this RFC will likely need signoff from both teams. Libs API from the perspective of whether or not this is an acceptable solution to these breakages and Compiler from the perspective of whether this can be reasonably implemented in the compiler.

similar idea, but goes further with separate per-edition symbols that are user accessible from all editions (allowing edition migrated code to use the old function still): https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Effect.20of.20fma.20disabled/near/274199236

This proposes adding an edition field to rustc_stable, so I'll mention the spiritual opposite RFC https://github.com/rust-lang/rfcs/pull/3088 , which proposed to add an edition field to rustc_deprecated.

So, the alternatives section mentions that supertrait method shadowing wouldn't solve all cases, but is there actually any data suggesting how regular those cases are in the wild? The specific case of intersperse, for example, would be fixed by that.
If there's data suggesting that these cases aren't very prevalent, I would personally feel like edition-based method resolution is pretty much a nuclear approach, and should be avoided whenever possible. There is already precedent of this occurring with array IntoIterator, but that feels more like a one-off case that shouldn't happen very often.

So, the alternatives section mentions that supertrait method shadowing wouldn't solve all cases, but is there actually any data suggesting how regular those cases are in the wild? The specific case of intersperse, for example, would be fixed by that.
If there's data suggesting that these cases aren't very prevalent, I would personally feel like edition-based method resolution is pretty much a nuclear approach, and should be avoided whenever possible. There is already precedent of this occurring with array IntoIterator, but that feels more like a one-off case that shouldn't happen very often.

I don't have any specific data but I know that the second example I gave in the RFC, the one for adding a Display impl to ErrorKind^1 would not be fixed by the supertrait item shadowing approach, so we've already seen examples of the shortcomings of that approach.
This does raise the point that I don't think these should be seen as alternatives, but rather as complements. We can fix a lot of these with super trait item shadowing and absolutely should, but I don't want to leave holes in the system where we can't prevent breakage, so we shouldn't use super trait item shadowing as a reason for not accepting this PR.

I'm not sure if it makes sense to tie this to editions. A period of three years is reasonable for language changes, but I don't think that's acceptable for library changes.

This doesn't tie library changes to editions. With this it just resolves the rare cases of breakages of APIs we're already introducing. If there are no conflicts the new API will be available like normal.

Oh, I think I accidentally missed this part in the RFC:

when we detect an ambiguity

Without that, it seemed to suggest that APIs would not be available through method resolution until the next edition.
Thanks for clarifying.

Oh, I should've mentioned this before I pressed submit on my review: but this feature seems really cool, and I'm excited for what this might enable. For async Rust we've been wondering how to add methods to the traits provided by the stdlib without breaking the whole ecosystem, and this seems like a step in providing an answer to that!

Building on @cuviper's third comment above about how this could relate to into_iter for arrays. If we are able to make this behave nicely around deref coersions I think this may also help with introducing new methods to smart pointer types like https://doc.rust-lang.org/stable/std/sync/struct.Arc.html#method.try_unwrap where we might be able to introduce them with a self parameter and gate the deref behavior behind that edition.

@nikomatsakis I feel like we shouldn't tie any kind of "you have to change your code" changes to updating rust-version; that would give people the (correct) impression of breakage when upgrading Rust version. Editions specifically do advertise "you might have to change your code when upgrading to a new edition".
You can still use methods from a later edition, you just have to remove the ambiguity in name resolution in order to use the std method, or you need to explicitly reference the std name with a path.

I'm concerned that this is tying methods to editions. I'm also concerned that resolving the ambiguities still requires manual intervention. This means that breakage in a dependency requires patching that dependency to make your code compile.
An alternative is tying method resolution to the MSRV. Let's assume a crate specifies a MSRV of 1.59. If Rust runs into a name conflict (say, the library calls Foo::bar, but this method exists both in the standard library and in a third-party crate), then Rust should check if it already existed in the standard library version 1.59. If it did, it's an error as usual. If not, the method from the third-party crate is used and a "future incompatibility" warning is shown.
This could even be generalized to always compare the since field with the MSRV when calling a method, so you get an error when a method isn't supported by the MSRV.

I feel like we shouldn't tie any kind of "you have to change your code" changes to updating rust-version; that would give people the (correct) impression of breakage when upgrading Rust version.

I'm not sure how impactful that is, though, since it's exactly the same kind of breakage that you can get by upgrading any of your dependencies, when they add methods.  And if we do let crates use #[stable(since = "...")] one day, that parallel would be even better, as you'd get warned (or more) about using anything not in your specified version, and wouldn't get broken any more for method ambiguity just from upgrading the version of the crate in your lock file.
To me, the critical thing is that people can upgrade their toolchain without breakage.  (Or, analogously, that a binary can compile your crate with a newer version of the library than the one in your cargo.toml without failing due to method call ambiguity.)  And basing the disambiguation on MSRV would work just as well for that, with the advantage that it rolls so much more often than editions do.

I'm concerned that this is tying methods to editions.

I clearly need to find a way to be more clear about this because this is a confusion that keeps popping up, but this does not tie methods to editions. It only turns currently allowed breakages between editions into a breakage at an edition boundary, if the breakage wouldn't have occured the method is still callable. This only changes behavior when there is an ambiguity.

An alternative is tying method resolution to the MSRV. Let's assume a crate specifies a MSRV of 1.59. If Rust runs into a name conflict (say, the library calls Foo::bar, but this method exists both in the standard library and in a third-party crate), then Rust should check if it already existed in the standard library version 1.59. If it did, it's an error as usual. If not, the method from the third-party crate is used and a "future incompatibility" warning is shown.
This could even be generalized to always compare the since field with the MSRV when calling a method, so you get an error when a method isn't supported by the MSRV.

This is the idea that @m-ou-se suggested as well and I think it is a good idea, and something we should do along side this RFC, but it is not a sufficient fix on its own. If we only resolve this by tying these breakages to MSRV we turn bumping MSRV into a breaking change. This would be counter to our stability policy. We have a mechanism for introducing breaking changes, Editions, and they should be used where possible to introduce breaking changes in an opt in manner.

If we only resolve this by tying these breakages to MSRV we turn bumping MSRV into a breaking change.

It can only break your code if you have "future incompatibility" warnings and ignored them:

Rust should check if it already existed in the standard library version 1.59. If it did, it's an error as usual. If not, the method from the third-party crate is used and a "future incompatibility" warning is shown.

So the situation is actually very similar to editions: When migrating to a newer MSRV, you first need to fix the "future incompatibility" warnings (and this could in theory be automated with cargo fix --msrv). If you don't fix the warnings, they become errors after changing the MSRV.

If we only resolve this by tying these breakages to MSRV we turn bumping MSRV into a breaking change.

It can only break your code if you have "future incompatibility" warnings and ignored them:

That does not contradict my statement and I do not think this is an acceptable situation to put our users in. Bumping your compiler version and by extension your MSRV within the same edition without fixing warnings should never break your code.

(Apologies for the long comment.)
It might help to include some concrete hypothetical scenarios (intersperse is a good one) with specific edition numbers, focused on what the user's experience is in different ways. For example, it's not immediately clear to me how intersperse would be stabilized today. Would it be marked as 2021 or 2024? What would happen for a user using a previous edition, current edition, or future edition?
Can you clarify what happens when my edition is less than the edition where the new method is added? For example, let's say std's intersperse is marked 2021, and I'm using 2018 and using itertools. In that situation, is there a warning? The text seems to imply that the warning only happens if the edition is equal.
Similar to above, let's say I'm happily using 2018. I start using std's intersperse. Sometime later, I import itertools::Iterator. Does that silently switch to itertools' implementation, or is there a warning?
Just a heads up that changing the fix behavior based on whether or not it is doing an edition migration may be difficult to implement. I don't believe the current system can support that, and I don't know how that could be hooked up.
I think it would be good to include some clarity on what happens when the function signature is different. The current text seems to assume they are always the same.
Will the edition field be required for the #[stable] attribute? If not, what happens if it is not specified? Any particular reason this couldn't be inferred from the since version? If it isn't required, why would one not want to set it?
A vague observation: IIUC, this mostly addresses the scenario where std introduces something that conflicts with a pre-existing crate, but doesn't seem to address the reverse, correct? It'll still be a breaking change for a crate to introduce something the conflicts with an already stable std version. For example, I depend on foo 1.0.0, which depends on itertools 0.12.0. foo is edition 2024. I update itertools to 0.12.1 which introduces a new method that conflicts with std, and is a hard error. This means that it is still a semver hazard to add methods to a user's trait? Imagine that 0.12.1 was published long before the std method was introduced, so they couldn't have anticipated this.
I feel like this seems heavily focused on std, but doesn't help with conflicts between user crates. I've never felt like the story for allowing breakage due to method resolution is a fair interpretation of upgrades being painless, or that being a semver "compatible" change (with "compatible" not being well defined). I understand that is a very difficult problem, and I don't expect this RFC to solve it (and I'm very thankful for you to be working on this). I just feel like that is a big hole in Rust's compatibility story (along with every "possibly-breaking" change listed at https://doc.rust-lang.org/nightly/cargo/reference/semver.html), and it would be nice to have more general solutions. Unfortunately I don't have any constructive ideas here.

It might help to include some concrete hypothetical scenarios (intersperse is a good one) with specific edition numbers, focused on what the user's experience is in different ways. For example, it's not immediately clear to me how intersperse would be stabilized today. Would it be marked as 2021 or 2024? What would happen for a user using a previous edition, current edition, or future edition?

Today, if we were to try to stabilize Iterator::intersperse again it would cause inference breakages for any crate that already calls Itertools::intersperse via method call syntax. If we had this RFC intersperse would be marked with edition = "2021". Users in the 2021 edition and earlier editions would instead see a warning when the inference occurs indicating that there was an ambiguity, but the compiler defaulted to Itertools::intersperse because Iterator::intersperse was introduced during the current / a later edition. In future editions this would be a hard error as it is today.

Similar to above, let's say I'm happily using 2018. I start using std's intersperse. Sometime later, I import itertools::Iterator. Does that silently switch to itertools' implementation, or is there a warning?

There is a warning.

Just a heads up that changing the fix behavior based on whether or not it is doing an edition migration may be difficult to implement. I don't believe the current system can support that, and I don't know how that could be hooked up.

Unfortunate, but good to know, thank you.

I think it would be good to include some clarity on what happens when the function signature is different. The current text seems to assume they are always the same.

I'm not sure how different function signatures interact with method resolution atm. I was working with the assumption that it only considers the self type and the method name, and that any other differences in the signature are essentially ignored, but if this isn't the case I will figure out if any of the suggestions here need to change as a result.
edit: some basic testing on the playground seems to confirm this, so I think my answer to this question is that this doesn't change method resolution rules beyond adding a tiebreak in situations where there are exactly two answers and one of them is considered a recent breaking change.

Will the edition field be required for the #[stable] attribute? If not, what happens if it is not specified? Any particular reason this couldn't be inferred from the since version? If it isn't required, why would one not want to set it?

I believe all of these questions are answered in https://github.com/rust-lang/rfcs/pull/3240#discussion_r822695917 but let me know any answers are missing.

A vague observation: IIUC, this mostly addresses the scenario where std introduces something that conflicts with a pre-existing crate, but doesn't seem to address the reverse, correct? It'll still be a breaking change for a crate to introduce something the conflicts with an already stable std version. For example, I depend on foo 1.0.0, which depends on itertools 0.12.0. foo is edition 2024. I update itertools to 0.12.1 which introduces a new method that conflicts with std, and is a hard error. This means that it is still a semver hazard to add methods to a user's trait? Imagine that 0.12.1 was published long before the std method was introduced, so they couldn't have anticipated this.

I'm having trouble processing this one. Is the idea that foo pinned their itertools version to 0.12.0 as part of their upgrade to the 2024 edition? If 0.12.1 was available before the 2024 edition I don't see how foo could have avoided depending on it during their edition upgrade in a way that allows the a user of foo to cause a breakage later.

I feel like this seems heavily focused on std, but doesn't help with conflicts between user crates. I've never felt like the story for allowing breakage due to method resolution is a fair interpretation of upgrades being painless, or that being a semver "compatible" change (with "compatible" not being well defined). I understand that is a very difficult problem, and I don't expect this RFC to solve it (and I'm very thankful for you to be working on this). I just feel like that is a big hole in Rust's compatibility story (along with every "possibly-breaking" change listed at https://doc.rust-lang.org/nightly/cargo/reference/semver.html), and it would be nice to have more general solutions. Unfortunately I don't have any constructive ideas here.

There's a bit of commentary on this in a thread between scottmcm and I earlier in the discussion which has been persisted a bit to the future possibilities. I agree tho that our current policy of allowing method inference breakages is definitely a hole in our stability story that needs to be patched up. I'm hoping that this can go most of the way towards solving the issue for std, but yea, extending it to all libraries in the ecosystem is definitely a much bigger lift, though hopefully not as necessary since they don't have the same stability story we do.

Thanks for the response, that is indeed helpful.
Regarding the function signature differences, I think it would be nice to acknowledgment its consequences in the RFC. The diagnostic suggestion probably can't be applied, so cargo fix won't work. I don't know how often that will be the case. I think the suggestion could prefer the pre-edition method if the signature is different.
Another option for the diagnostic suggestion is to provide both suggestions, and let the user decide which one to use (when the signatures match).
Regarding the semver compatibility issue, imagine the following series of events:

itertools 0.12.0 is published
foo 1.0.0 is published, using edition 2021 and also importing Itertools from 0.12.0.
itertools 0.12.1 is published adding cool_new_method to its iterator trait
std introduces cool_new_method on Iterator with edition=2021
Edition 2024 is stabilized
foo 2.0.0 is published, using edition 2024, using cool_new_method from std, and still has Itertools imported from 0.12.0.
foo developer hasn't updated Cargo.lock in a while.
There's no warning for foo because this older version of itertools doesn't have the conflict.
foo developer runs cargo update -p itertools and picks up 0.12.1
foo no longer builds because it now has a conflict on the cool_new_method

This is the kind of scenario where a supposedly semver-compatible release causes the build to fail, even with this RFC's mitigation.
FWIW, I'm not advocating this RFC needs to be a perfect solution to the compatibility problem, but I think it would be good to acknowledge there are still some scenarios that cause semver-breakage when adding methods.

6. foo 2.0.0 is published, using edition 2024, using cool_new_method from std, and still has Itertools imported from 0.12.0.
foo developer hasn't updated Cargo.lock in a while.
There's no warning for foo because this older version of itertools doesn't have the conflict.

Does publish respect lock files? I would have expected this to fail because when you publish a new version it does a full build which I hope and assume ignores lock files because lock files are not published with crates.

Lock files are published if you have a binary in the project.

Lock files are published if you have a binary in the project.

Aaah, I had assumed we were talking about library crates, I see the problem now. I'm happy to add a note about this, and part of me wants to avoid dealing with this problem as part of this RFC to keep it as simple as possible, but another part of me wants to solve it immediately. The first solution that comes to mind is require to updating a lock file whenever the edition field is updated in the toml file.

The lockfile is also packaged for libraries which have an example. cargo publish also supports both --locked and --frozen as well as of course --no-verify. Plus you also have -Zminimal-versions, which may be required in order to build on the MSRV.
I also want to directly offer an argument against

The rust-version approach would prevent many breakages by not ever resolving ambiguous method calls to new methods when those new methods are introduced in later versions than your MSRV, but it would not be a complete solution by itself since otherwise it would turn bumping MSRV into a breaking change. This is counter to our stability policy which promises to only introduce breaking changes at edition boundaries.

I agree with scottmcm that

the critical thing is that people can upgrade their toolchain without breakage.

The key important part to the stability guarantee is that if you have a crate today, a new version of rustc N years later will still be able to compile it.
It is desirable but not core that you can use new features without fixing new warnings. Until we added k#word, it was the case that edition2015 just couldn't use async.await.
So I think that this concern

Bumping your compiler version and by extension your MSRV within the same edition without fixing warnings should never break your code.

is not just about upgrading which compiler you are using (this does not imply bumping MSRV), but also utilizing new language features, which is updating your MSRV. So it should instead read

Upgrading your MSRV (e.g. to take advantage of new language features) without fixing warnings should never break your code.

This is a reasonable position to take, is potentially supported by the stability promise[^stability], and becomes even more desirable an axiom if the compiler were to start erroring on the use of features newer than rust-version.
[^stability]: The counterargument is that the stability guarantee applies solely to the new compiler compiling your code, and not access to new features.
For the rest of this post I am going to treat rust-version as a binding contract enforced by the compiler that you don't use newer features. This is the strictest possible interpretation and the effect in practice of actually conforming to the advertised MSRV.
But I argue that this isn't wanting for tying name resolution to editions, but instead for introducing a std-version key instead.
This makes std behave much more like any other library, and as a bonus makes how version-influenced name resolution would be extended to other libraries trivial, rather than requiring every library to introduce (and users to manage) their own edition train.
Reduced to absurdity, the argument that name resolution priority of the special std library should be tied to the language edition reduces to it should be possible to use new APIs in std without resolving name resolution conflicts introduced by new APIs.
The problem is that using lockfiles means that just because you don't currently have a name collision on new APIs doesn't mean that one isn't present in your updated dependency tree.
Assuming full due diligence from crate publishers — that is, never publishing a new version which adds a new name which could cause a new name resolution warning, or which could completely shadow a std name, and always testing with both current maximal and minimal version resolution — it seems possible[^but] that tying ambiguous name resolution fallback to edition instead of rust-version could both allow the use of new library APIs in and not require said libraries to do their due diligence in resolving name ambiguity warnings.
[^but]: However, I am not willing to bet that there isn't still a hole allowing for a new name ambiguity to sneak in.
But this seems really lopsided to me. In this scheme we're requiring a lot of open-ended due diligence on the part of the library authors to prove that they aren't introducing new potential for name resolution ambiguity[^stability]... just so that they can avoid doing the simple, machine-enumerated task of resolving existing ambiguity before using new language features.
[^stability]: A further problem is that the more due diligence expectation we put onto crate authors (e.g. when adding a new defaulted method to a trait, I must make sure that it doesn't have the same name as any std trait method, because a downstream crate could have both implemented on a type), the more this feels like pushing the responsibility for the stability guarantee onto library authors, rather than offering a solution.
And for all that work, we still aren't solving the issue for local crates! It doesn't help my proposal that local crates probably aren't using rust-version[^new], but it hurts all schemes that they can be using arbitrarily old dependencies. Unlike with published crates, there's no way to enforce[^publish] that they're using up-to-date dependencies, and ever requiring they do actively goes against stability goal of upgrading toolchains should require no further changes.
[^new]: Though we could tip the balance going forward by including rust-version in the cargo new template.
[^publish]: Enforcing it for published libraries is still not necessarily possible, either. And in the extreme there're libraries that just fail to do their full due diligence; are we just blaming them if name inference fails?
The failure case with a local crate is even more worrying if it doesn't cause a build error, and only causes a warning. The whole point of not requiring addressing warnings before using new toolchains / library features is that we don't want to require paying attention to warnings. But if a local crate updates their toolchain and takes advantage of a new std trait method, then gets around to updating a library dependency that also provides that trait method, their code now effectively silently — because we've told them they can upgrade without looking at warnings — has changed behavior.

To be tractable, any initiative for improving stability / decreasing the number of allowed breaking changes has to be explicit about goals and non-goals. For this RFC (and thus any competing proposal should meet the same goals or actively argue an unmet goal nondesirable), I believe we have
Goals
Given any compiling crate and resolved dependency tree,

Upgrading the toolchain should never result in different method lookup[^caveat]
Upgrading the rust-version key should never result in different method lookup
If all crates in the dependency tree are well-behaved[^well-behaved]

Upgrading private-to-root dependency versions should never result in different method lookup

[^caveat]: Caveat to the entire list: as currently defined, this only changes the behavior to meet the goals if the conflict is at the same autoderef level. This means only trait name conflicts on identical Self is covered. Inherent methods and new trait implementations are not covered.
[^well-behaved]: A dependency is considered well-behaved if it does not add any new methods to existing traits which clash with a stable-at-the-time method name on a non-mutually-exclusive std trait and was verified using the most up-to-date resolution of its dependency tree at time of publish.
Non-goals

Upgrading public-to-root dependency versions may result in different method lookup, even if all dependencies are well-behaved

e.g. a trait method got deprioritized in favor of a library version

Upgrading dependency versions where any dependency is not well-behaved may result in different method lookup
Additional caveat: even if all dependencies are well-behaved, upgrading private-to-root dependency versions can result in a method lookup conflict between crates, just not to std

I am actively re-counter-proposing tying method lookup deprioritization to rust-version, or a new std-version key if access to new language features separately is considered important, rather than edition. I argue that the provided limitation/downside does not apply

the burden of resolving machine-enumerated method lookup ambiguities is significantly smaller than the other due diligence required for a well-behaved crate

and in fact is not required the crate doesn't care about being well-behaved

the important part is that a new toolchain can compile existing code

not that old code can use new features without minor changes

and comes with measurable benefits

crates can switch to using std functionality idiomatically immediately
method deprioritization is trivially extendable to libraries annotating stabilization versions

significantly decreasing the effort required for a well-behaved library
using the std version as the resolution if the std version is included but the library version is not

Reduced to absurdity, the argument that name resolution priority of the special std library should be tied to the language edition reduces to it should be possible to use new APIs in std without resolving name resolution conflicts introduced by new APIs.
...
But if a local crate updates their toolchain and takes advantage of a new std trait method, then gets around to updating a library dependency that also provides that trait method, their code now effectively silently — because we've told them they can upgrade without looking at warnings — has changed behavior.
...
Upgrading the toolchain should never result in different method lookup

I'm still reading and trying to understand all of the points you made in your comment @CAD97 and am still somewhat confused, so this may be a case of me replying too soon, but these parts of your comment make me think that you may have misunderstood the proposal and that the reason I'm having trouble following the points you're making is because we're not working off of the same set of assumptions and facts. This proposal specifically aims to make it possible to not use new std apis without resolving name resolution conflicts and does not change behavior of code silently, ever. I think you got something backwards because your comments make it seems like the goal is to make it so you can use new std apis in the presence of conflicts, but the goal is the opposite, to make it so you can continue to use the old code in the presence of conflicts.

@rfcbot merge

Despite being a loud proponent for an alternative solution, I'd like to formally state I have no current concerns about the acceptance of this RFC.

Note: [...] This RFC only changes behavior when there is an ambiguity to make things that are currently errors into warnings until the next edition boundary.

I think this may be the contentious point which is difficult to ensure is communicated entirely. The edition-sensitive name resolution rule as added by this RFC exclusively impacts the narrow case of default methods added to preexisting traits, and only serves as a disambiguation rule when method name resolution would otherwise fail because it resolved multiple applicable candidates from multiple traits in scope.
There are no changes made to name resolution by this RFC; solely a new step of name selection when multiple resolution candidates are present is added. If a name has higher resolution priority (e.g. it's an inherent method or earlier in the autoref lookup order), it's still always chosen.

I do think it is fair to say this "ties methods to editions;" it does deliberately make the new method selection (not resolution) edition-dependent. But I no longer think this is problematic, due to the following observation:
Even in its most generalized form, edition-sensitive name resolution isn't actually about upgrading the used standard library version; it's about upgrading the toolchain version without upgrading the standard library API.
The stability promise of the Rust toolchain is that if your project compiles with the 1.N toolchain, then it will also compile and run without changes[^1] on toolchain 1.M for any M ≥ N, if you compile the exact same code the same way.
[^1]: Presuming no UB, of course.
This isn't fully true today, because there's no way to upgrade the toolchain/compiler version without also upgrading the standard library version, and library upgrades are allowed to cause inference breakage[^2].
[^2]: We say a library change is only a "major" breaking change if it breaks fully elaborated downstream code. We consider name inference breakage (here this includes name shadowing / higher priority resolution for the same name lookup) as allowed "minor" breaking changes because adding any new functionality can cause name inference breakage.
The real generalized form of this feature is std adaptively downgrading its API such that user code always gets the version of the API it was written against, even without the code being written in fully elaborated form. The edition-sensitive part of it just puts a cap on how far std will downgrade its API, such that std functionality can eventually actually be used without requiring the fully elaborated form.
To this interpretation: it could make sense to also consider rust-version as a lower bound for this name deprioritization. The goal imho isn't that my crate should be able to raise its manifest rust-version without encountering minor breaking changes; it's that the full package tree can raise its toolchain version without breaking packages unaware of the toolchain upgrade. This is not asking for strict rust-version enforcement; such would supersede adaptive downgrading if enabled, but is in fact a distinct problem.
Doing so may make the purpose of the name deprioritization more obvious, and would probably be necessary for more extensive application.
I am explicitly not proposing such a scheme. I merely present it as a potential generalization of the RFC's behavior and potential model of what the behavior is accomplishing.

I took a swing at trying to diagram what I think the intended workflow is: https://hackmd.io/TvFfyYbpQaK5L6kseXZheg

A thing I want to mention as a potential additional thing on this feature is that we could add a <Foo as Self>::method() syntax for unambiguously calling inherent methods: we haven't needed it yet, but this would allow people to call stdlib methods in cases where there is ambiguity.
(Though I suppose that can also be handled by being careful about how and where you import traits)

@rustbot label: +I-libs-api-nominated
I just wanted to double check with the libs team about whether they are happy with this proposal as an interface for solving this problem as stdlib developers.
(My motivation is that I don't want to put pressure on T-lang to invest time looking at this until after we have more concrete evidence that T-libs-api is happy with the proposal.)

This doesn't seem to be close to consensus (yet), so I'm cancelling the proposed FCP for now.
@rfcbot cancel

I think spelling out the an example timeline of how you expect new methods to be rolled out, and how various client crates will hit the cases described, could help clarify this for people reading the RFC on its own.

It's not just a clarification.  The expected rollout plan for new methods is part of the design underlying the behaviour.  Writing down these aspects of the design is important so that we can check that the design does in fact meet its goals.  It often happens that properly describing something reveals previously-overlooked lacunae.

I should mention that I'm not currently interested in continuing to push for this change. I still do believe it is worth doing, but I'm prioritizing other work I'm more interested in over this. If anyone wants to take the torch and complete this work, I'm happy to answer questions and provide clarifications about the RFC; just message me in Zulip.


Miner's Fervor calculation doesn't include sea level

In Enchantment Descriptions for Apotheosis, you said Miner's Fervor will effect 1 + level * level * ((sea level - y level) / sea level) for underwater and  1 + level * level * ((sea level - y level) / (sea level * 3)) for overwater.
But it just calculate base on the EnchantmentsLevel(depth) and OriginalSpeed.

That document is not a reliable piece of information anymore (and hasn't been for at least a year, at this point)


Discovery: GC committed for MinIO

Try out CGC with MinIO and estimate the effort of implementing it.

Trying it out manually, it seems like anything below our Hadoop 3 Spark
assemblies will not work with MinIO.  MinIO requires me to force path style,
S3A only supports that starting Hadoop 2.8.x, and we use 2.7.7.
Going for Hadoop 3 now.

Opened #4885 to document this.  It is somewhat tricky.


⚠ Bofrost.at has degraded performance

In dbc3e55, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1385 ms

Resolved: Bofrost.at performance has improved in 43160b7 after 8 minutes.


Correctly handle fragmented Handshake message when trying to detect SNI

Motivation:
At the moment our AbstractSniHandler makes the assemption that Handshake messages are not fragmented. This is incorrect as it is completely valid to split these across multiple TLSPlaintext records.
Thanks to @sskrobotov for bringing this to my attentation and to @Lukasa for the help.
Modifications:

Adjust logic in AbstractSniHandler to handle fragmentation
Add unit tests

Result:
Correctly handle fragmented Handshake message in AbstractSniHandler (and so SniHandler).

@Lukasa  @sskachkov PTAL if you have time...

@netty-bot test this please


Is It possible to call CGO?

Is it possible to call Golang CGO routines?

Hi @grafael,
Can you please provide more detail? Do you mean calling the shim CGO functions? or your own CGO functions?

I mean my own CGO functions. I am asking that because the Google app engine (Google cloud platform) does not support, and I was wondering to use aws lambda.

In theory I don't see any problem preventing you from doing such calls. I haven't tested such calls but it should be ok.
One thing to notice, in order to compile your CGO parts, you have to be in the same environment than AWS Lambda, so you should use https://hub.docker.com/_/amazonlinux/ image or our docker image which embed this one.
I'll be glad to hear back from you to know if this scenario is possible. And do not hesitate if you encounter any problem, create an ephemeral repo and I'll assist you.

Thanks. I'll try that soon, and  I let you know the results

:wink: I'll close the issue for now, but feel free to continue the thread if you have any other question.


Daemons with expiration all shut down at different times

Daemons that have an expiration set do not consistently shut down at the expiration. Observing a testnet which expired, there was as much as a 40 minute drift between the time that the individual nodes shut down. This is pretty low priority, but should be an easy fix.

Some metrics supporting this conclusion:

Odd -- All the fillet nodes stopped precisely at the same time.

What was your expiration time?
Based on the wide spread, I suspect those nodes died 'naturally' and just weren't restarted.
(monit is only deployed manually at the moment)

It's possible that happened instead, but at least on the nodes that I inspected (2 nodes, not all of them) there were no crashes and the last log messages were regarding expiration.

I have a utility in ansible to gather up all log dirs when you retire a testnet
we should be sure to do that for your next net.


Dependabot PRs fail due to permission restrictions on writing test results to PR

Re: https://github.blog/changelog/2021-02-19-github-actions-workflows-triggered-by-dependabot-prs-will-run-with-read-only-permissions/
Per https://github.com/EnricoMi/publish-unit-test-result-action#support-fork-repositories-and-dependabot-branches, Dependabot PRs will not publish test results to get around this issue.
Acceptance criteria:

Dependabot builds do not fail on publishing test results.

Resolved through several workflow optimizations and conditional testing.


Updated documentation for L2normSquared and LeastSquares functions

Describe your changes
Describe any testing you have performed
Please add any demo scripts to CIL-Demos/misc/
Link relevant issues
Closes #1554
Checklist when you are ready to request a review

[x] I have performed a self-review of my code
[x] I have added docstrings in line with the guidance in the developer guide
[x] I have implemented unit tests that cover any new or modified functionality
[x] CHANGELOG.md has been updated with any functionality change
[x] Request review from all relevant developers
[x] Change pull request label to 'Waiting for review'

Contribution Notes
Please read and adhere to the developer guide and local patterns and conventions.

[x] The content of this Pull Request (the Contribution) is intentionally submitted for inclusion in CIL (the Work) under the terms and conditions of the Apache-2.0 License.
[x] I confirm that the contribution does not violate any intellectual property rights of third parties

Thanks @gfardell - will wait on the github actions and put some screen shots up

Before

After

The maths is a big improvement, but you've opened a can of worms!
Functions
init shouldn't be included in the documentation or have a doc string (this is just the class doc string)
call I'm not sure if this should be included or not, I think it should be an example of usage in the main doc string with an explanation of the maths.
All other methods don't list their parameters
Weighted LS
as above
LS
Parameter input is formatted strangely, could you update that to the current standard.
It doesn't take L, it looks like it's on the parameter list, maybe it could be a note in the main docstring.
rmul definitely shouldn't be there.
In general we want the documentation to show
.. autoclass:: cil.optimisation.functions.Function
   :members:
   :inherited-members:

https://github.com/TomographicImaging/CIL/blob/master/docs/source/optimisation.rst
seems to be showing :special-members:
Which may be a future clean up job.

Updated documentation :)

I can see from the code changes you've updated things but the screenshots still look wrong. The LeastSquares parameter list is one example, did you post the latest version?

@gfardell - Hopefully this looks better:


codegen Angular services return wrong subscription listener observable types at runtime

Note: If your issue/bug is regarding the AWS Amplify Console service, please log it in the
Amplify Console GitHub Issue Tracker

Describe the bug
codegen generates Angular services that return graphql subscription listener observables at runtime that don't match their declared typescript types.
Amplify CLI Version
4.29.0
To Reproduce
Create any graphql API and have amplfiy codegen all types including subscriptions.
For example, the Amplify Angular getting started walkthrough here creates a simple Restaurant API with a single Restaurant type.
In the generated Angular APIService, there's an OnCreateRestaurantListener property implemented like this (other generated subscription properties are similar):
OnCreateRestaurantListener: Observable<
  OnCreateRestaurantSubscription
  > = API.graphql(
    graphqlOperation(
      `subscription OnCreateRestaurant {
        onCreateRestaurant {
          __typename
          id
          name
          description
          city
          createdAt
          updatedAt
        }
      }`
    )
  ) as Observable<OnCreateRestaurantSubscription>;

While that may look right at first glance, it's fundamentally broken. It compiles successfully, but it breaks at runtime.
Expected behavior
I expect the declared return types of generated code to match the actual runtime types.
Desktop (please complete the following information):

OS: Mac
Node v12.18.3
(these versions are irrelevant - the angular codegen code for subscriptions is broken)

Additional context
The problem in the generated code is (referencing the sample above), the OnCreateRestaurantSubscription instance (i.e. the newly-created Restaurant object) is not directly at the top level in the observable response returned by the API.graphql call.
If the intention is to only provide an observable for the newly-created objects, then something like this with a map call to pick out the new value is needed instead (modeled after the generated code for queries and mutations):
  OnCreateRestaurantListener: Observable<
    OnCreateRestaurantSubscription
  > = (API.graphql(
      graphqlOperation(
        `subscription OnCreateRestaurant {
          onCreateRestaurant {
            __typename
            id
            name
            description
            city
            createdAt
            updatedAt
          }
        }`
      )
    ) as Observable<any>)
  .map(x => x.value.data.onCreateRestaurant as OnCreateRestaurantSubscription);

This only fixes the return type. Other issues like robust error handling and such when provided as a property on a shared service instance vs a function that returns new cold observables is another matter to be addressed separately.

@rob3c Based on the amplify-js library the response is event.value.data (source). We also have this piece in our docs which you've linked. I've opened a PR to add an interface so it's more clear on the type coming from a subscription.

@SwaySway I appreciate your attempt at feedback for my issue, but based on the nature of your response, it appears that my writing was not as clear as I had hoped. I'm quite familiar with the runtime shapes that Amplify generates in the Angular services, the docs, the source code used for both generating the broken Angular service as well as passing the values to observable subscribers at runtime.
The problem is that the code generated by the codegen tool does not generate the correct typescript types for graphql subscriptions in Angular services, as I mentioned above. As also mentioned above, I provided the fix for the generated subscription if the intention is to match the generated type. Obviously, if the intention is to change the generated type to match what is actually being produced, then you'd address it by fixing the return type instead.
In any case, the result object needed to match the (broken) generated type for the restaurant getting started sample that I mentioned is not directly event.value.data, but is event.value.data.onCreateRestaurant, as indicated above. That's based on what it actually took to get a real project working with the (broken) generated code to match the generated return type.
This would've been easily caught before publishing the library if there were any tests that used a generated angular service with typescript, as either typescript would've caught it and given a compiler error that breaks the build, or the assertions would've broken when testing the runtime subscription values if it got that far.
Unfortunately, there are no Angular service subscription tests. There are only abstract CodeGenerator print statements using template literals, so none of the concrete object types or shapes that are actually generated get tested or are even obvious to readers of the source code (since I'm sure the code passed review by humans at some point and is still broken). There are some snapshot-based tests for queries and mutations - but not for subscriptions - and that may seem like a solution here. However, the saved snapshots would have to be correct, and that can be prone to error if you're not checking behavior of the generated code. (Snapshot tests are a religious war in itself lol).
The bottom line is, it seems very likely that nobody on the team has actually tried using the generated Angular service with subscriptions using typescript (the predominant Angular language), because they just don't work as generated (although they work fine after patching things up). I suspect this is due to the strong React bias the team seems to have (which is fine in itself - I like React too, and it's a nice framework with a solid ecosystem. However, this library is meant to support multiple platforms well.)
 None of the relatively fewer samples or walkthroughs are up-to-date to a modern Angular version or work exactly as described in the docs without alteration, including being outright broken like generated subscription typings are.
Another related issue is that Amplify uses zen-observable instead of rxjs for the subscription observables in a supposedly Angular service, which is more evidence the Amplify team doesn't seem too worried about providing a native Angular experience. And zen vs rxjs incompatibility issues aside, Amplify uses the outdated zen-observable-ts project for zen typings that don't even match the full zen observable interface completely! (For example, concat is available at runtime on a zen observable but is missing in the typescript typings for it.)
(There's also the matter I mentioned that we're only addressing the return type here rather than observable implementation details, but it's beyond the issue scope and this comment has turned out to be much longer than intended already lol - sorry about that.)
Amplify is certainly growing into a nice suite of tools that makes a lot of AWS interactions easier! I think it's important to understand the assumptions, biases and limitations of any tool to best leverage its capabilities. Please try to accept my comments here as the constructive feedback they were intended to be from someone working through those in a serious and detailed attempt to incorporate Amplify into multiple frontend and backend projects.

@rob3c Is correct on both major points...

Generated code is incorrect for listeners.
This is a nightmare when using strict Typescript.
Non RxJS Observables
In an Angular project seeing the type Observable and it not being RxJS is pretty jarring. At the very least the docs should highlight this inconsistency and at the most selecting your preferred implementation (ahem RxJS) should be allowed.


x/mobile/cmd/gomobile: INSTALL_FAILED_INVALID_APK when dashes in package

Hi,
It seems that it is not possible to build an Android application from Go source code if there is a dash (-) somewhere in the Go package name. Since my organization on GitHub has a dash inside, this means I cannot build any Android applications whatsoever.
You can easily test this with the currently available Go 1.5 release version.

Take the golang.org/x/mobile/example/basic example application and move it to the golang.org/x/mobile/example/basic-demo folder.
Run gomobile build -target=android golang.org/x/mobile/example/basic-demo command.
Run the adb install basic-demo command.

You will get the following error:
6927 KB/s (3293500 bytes in 0.464s)
	pkg: /data/local/tmp/basic-demo.apk
Failure [INSTALL_FAILED_INVALID_APK]

Now, you might ask me why didn't I use the gomobile install command instead. There seems to be another issue as well. If you run the gomobile install command, you will not receive any output to the terminal at all. Furthermore, you will even get an exit code of 0. It seems that the gomobile command hides any issues coming from the adb command.
My best guess is that somewhere in the manifest you place the package name. At least for Java based applications, I know that they don't allow dashes in the package names and you are advised to substitute those with underscores. (http://stackoverflow.com/questions/3179216/what-is-the-convention-for-word-separator-in-java-package-names) I guess a similar validation is performed even if the application is not Java based. This is just a hunch, I might be totally off base.

CC @crawshaw

I have the new project without dash on a Windows machine and I get exactly the same problem.
Compiling goes well but the APK produced is invalid.
C:\software\go\src\golang.org\x\mobile\example\basic
> gomobile install -target android golang.org\x\mobile\example\basic
3008 KB/s (3450146 bytes in 1.120s)
    pkg: /data/local/tmp/basic.apk
Failure [INSTALL_FAILED_INVALID_APK]

Confirmed this issue exists on OS X as well and I just lost an hour to it!

Please provide the output of
% go version
% gomobile version
and device model & android version.
Also,
@neoranga55 Can you send me the produced basic.apk?
@stmuk Does your app have dash in the package name? Or do you have a problem with the basic example as well?

% go version
go version go1.5.1 darwin/amd64
% gomobile version
gomobile version +a54776c Wed Nov 11 22:33:35 2015 +0000 (android,ios); androidSDK=
The issue I saw was installing from a directory with a dash in it "go-mobile" the app itself didn't contain a dash and neither did it use a package with one. The target platform was  HTC One M7 with Android 5.0.2
Renaming the directory fixed the problem and I was able to run on Android and IOS

To clarify I had no problems with any example apps.

go version
go version go1.5.1 windows/amd64

gomobile version
gomobile version +83be1bf Thu Oct 8 21:24:20 2015 +0000 (android); androidSDK=C:\Users\MyUser\AppData\Local\Android\sdk\platforms\android-23

On a Xperia Z3 with 5.1.1
APK is in the link and MD5 sum is 0ACE1CC04AB31127C43424E01D18EC51
http://s000.tinyupload.com/index.php?file_id=90941633308815548327

Is this still a problem?

@eliasnaur , no idea. I moved away from gomobile a few years ago due to many instabilities in the package at the time. It is good to see that effort is still ongoing and I expect things have changed now.
Maybe other people in the thread that have also experienced the issue can check.


Interpolating lead to poor quality and jamming

https://pan.baidu.com/s/1m72KUBkUApodDDyrGZPhqQ 提取码: kivu

The 2x and 8x video is jamming in the 0:01..It's hard to say that the video after inserting frames has better MOS, but the speed has really improved a lot.

use the windows app to interpolate

@BeiluobluesNing by windows app do you mean Flowframes?
Also define MOS.
I am having trouble downloading the files from that link for inspection.

年轻人不讲武德
I think it's a window app issue. I make a new 2X video for you using colab.
链接: https://pan.baidu.com/s/1-WDJMWCNyY_-pTGLEc-IeA 提取码: rp3b
耗子尾汁

@BeiluobluesNing by windows app do you mean Flowframes?
Also define MOS.
I am not sure what you mean by jamming yet and I am having trouble downloading the files from that link for inspection.

For you to test, https://drive.google.com/file/d/1rOF_Og2N21t5jX8AxiAYAm0T2AJYd-Zg/view?usp=sharing

I think it's a Flowframes issue. Please port this issue to https://github.com/n00mkrad/flowframes.


Ios

@BrunoBetancourt this is the second issue you've created without any context. Explain yourself.

Closing this issue. @BrunoBetancourt please stop wasting my time.


Common elements in the row of a matrix

I want to write the code for finding all the common elements of the matrix in a row in c++.

/assign


Update setup.py

fix LONG_DESCRIPTION NameError by putting LONG_DESCRIPTION in scope

This was merged in #33. Thanks for contributing.


[5.10] Legacy Driver: Make --ld-path option consistently use single dash

Cherry-pick of #68495.
The original --ld-path option hasn't been included in a released version yet, so it's ok to break.
The vast majority of other options on Swift Driver already use a single dash.

@swift-ci test

@swift-ci build toolchain

@swift-ci please build toolchain windows platform

@swift-ci please build toolchain windows platform

@swift-ci please build toolchain windows platform


Upgrade controller-runtime to 0.8.1

What would you like to be added:
Upgrade controller-runtime to 0.8.1
Required changes:

Upgrade admission webhook to v1
kubernetes/kube-openapi#220

Why is this needed: Allow clients to use newer controller-runtime

/kind feature

@sagikazarmark
The latest controller-runtime version is v0.8.3. Should we upgrade to this version? If so, I'm willing to open a pr for this issue.

Sure, why not. Not sure if the above linked PR is updated everywhere.

@yuswift Sure, please do it :).

I'm trying to take another stab at this as this will bite more and more clients are upgrading to controller-runtime v0.7.0+

/assign


Ok/gitlab fix

PR Type
Enhancement, Bug fix

Description

Refactored the gitlab_webhook function to improve async processing and logging.
Moved the app setup outside of the start function for better initialization.
Enhanced request validation and error handling to ensure secure processing.
Added detailed logging for request processing time to aid in debugging and monitoring.

Changes walkthrough 📝
Relevant filesEnhancement

gitlab_webhook.pyRefactor GitLab webhook handling and initialization

pr_agent/servers/gitlab_webhook.py
Refactored gitlab_webhook function to improve async processing and logging.  Moved app setup outside of the start function.  Enhanced request validation and error handling.  Added detailed logging for request processing time.

+67/-57

💡 PR-Agent usage:
Comment /help on the PR to get a list of all available PR-Agent tools and their descriptions

/improve
--pr_code_suggestions.persistent_comment=true

/improve

/improve

/improve
--pr_code_suggestions.persistent_comment=true

Generating PR code suggestions
Work in progress ...

Generating PR code suggestions
Work in progress ...

Generating PR code suggestions
Work in progress ...

Generating PR code suggestions
Work in progress ...


Bump version in sanitize.css to 8.0.0

Thanks, @alexblunck. I really need to make this part of the build process.


Using Visual Studio Code and kinda hating the IDE, the file menu disappears after every use. I just learned after a 4 hour search on google that the alt key will restore the view of file menu. I use File menu a lot. Wish I could keep it visible always.

VSCode Version:
OS Version:

Steps to Reproduce:

This issue report is awful. The least that you can do is to fill in the version information. That title is far too long and should be the description.

Press alt.. go to the "view" menu and press "toggle menu bar"
Or press ctrl+shift+p and type "toggle menu".
Maybe next time just put a normal bug report here without the "hating" in the title as this isn't really necessary ;)

Toggle Menu Bar in the command palette switches between a permanent and a auto-hidding menu bar on Windows.

thank you KieFerrm. this is answer I was hoping for. the shaming from the others is kind of touching that they care so much.


Add support for fetching list of spaces being used

This is a Feature Proposal
For feature proposals, please answer the following question:

What is the use case that should be solved? The more detail you describe this in the easier it is to understand for us.

Use cases
Possibly an admin would like to see what functions and subscriptions are present.
Currently we can fetch subscriptions and functions with the following API.
GET <Configuration API URL>/v1/spaces/<space>/subscriptions

GET <Configuration API URL>/v1/spaces/<space>/functions

But we need to know the <space> before hand. It'd be nice if there is an API like the following:
GET <Configuration API URL>/v1/spaces

which returns a list of spaces already in use. If we can retrieve this, it's possible to retrieve all the informations (spaces, functions, subscriptions) via the API.
Would like to know if this is by design or not or if I'm missing something.
Thanks!

Hey @kenfdev, that's a good idea and would make it easier to discover the full setup of your Event Gateway.
@mthenw What are your thoughts?

Totally +1 for that. That's natural step forward in Config API.

@alexdebrie @mthenw Thanks! Ping me if there's any way I can help.
Also, a bit off topic but should the user be able to create and delete a space via an API?
POST <Configuration API URL>/v1/spaces
DELETE <Configuration API URL>/v1/spaces/<space>

This will probably lead to checking the existence of a space when creating functions and subscriptions which is a breaking change in the workflow.
One thing I though of is that, currently one can easily have a typo in the  and accidentally create a space. Perhaps it'll be better to have a CREATE and DELETE workflow for spaces. WDYT?
(I think this should be a different issue but didn't want to pollute the tracker much)

@kenfdev IMHO until there is no properties/options that can be set on space level we shouldn't provide CRUD API for spaces and space should be created implicitly. Right now space without functions or subs doesn't provide any value.


Removed loopdevice feature from sys-mount

The loopdev crate currently failes to compile on some platforms, see https://github.com/mdaffin/loopdev/issues/65.
Because it failes to compile and the sys-mount crate lists it as a dependency, this crate failes to compile as well.
Since the loopdev feature of sys-mount is not necessary for this crate, this pull request disables the loop feature of sys-mount that is responsible for loopdev crate.

Available since 0.2.2 on crates.io.
Thanks a lot for your interest and contribution to cargo-ramdisk @tynberry 😄


Enable adding a PAT from settings

Part of #2376, #2165

I also think there should be guidance on what scopes you recommend for user ie public repo scope access. I know this is just a partial merge but just to keep in mind :)


Allow Client Side to define relationships not in DB side

About a year ago I was on a project whereby the developers of the application had no clue concerning DB fundamentals.  In fact not a single foreign key was defined anywhere.  They wanted the application side migrated to an MVC application but did not want the DB to be altered.   The solution to me was that "I should map the tables as they were using DB first, but then I would go further and add the relationships client side only."   I was unable to do that.
Please consider allowing the client side to define foreign key relationships that are not in the database.

@AcousticGuitar Neither EF6 or EF7 require FKs to be defined in the database. The only time we ever introspect into the DB is when reverse engineering.


Youtube Video

Would you please add a feature of inserting video like featuredImage?
Thank you very much.

@sugawara-system I'll look at its feasibility. If possible, I will add this feature in the future. Because there are many video platforms, perhaps some of them have their own limitations.
And if you just want to add a video in content instead of summary, you can just insert the html code in markdown file.

@sugawara-system This feature has been added in v0.3.0. You can upgrade to v0.3.0 and check eureka‘s document to use it.

It worked perfectly. Great work! Thank you so, so much.


Add future annotations

Summary
This pull request adds future annotations in places where it can be used in the current code base.
It also restructures the imports from lightbulb.
Note
The lightbulb dependency has been updated to the github development branch, for the typing changes in tandemdude/hikari-lightbulb#176, until it is released to pypi.

I mean this pr has the development branch targeted for lightbulb, it could technically be merged now and that dependency updated to 2.0.4 when it releases.

This is true, yeah. I'd rather not accidently introduce anything down the line between now and then, so may be best to lock to commit until it's released?

Fair. I'll be starting the feeds cog from this commit.

 I'll update it when I do #135.


Update Config Validator to use opa v0.17.2

The policy-library repo was recently updated to use opa v0.17.2 (from v0.16.0).
Config Validator will also need to be updated to use opa v0.17.2 to be synced, as it is currently on v0.16.2.

This is going to entail updating github.com/open-policy-agent/frameworks/constraint and github.com/open-policy-agent/gatekeeper to both use 0.17.2
Dependencies:
https://github.com/open-policy-agent/frameworks/issues/86
https://github.com/open-policy-agent/gatekeeper/issues/510

That sounds like a good idea- I've opened a PR here: https://github.com/forseti-security/policy-library/pull/284


courses?

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

sorry accidenaly pressed enter

how do I enter community made courses on beatrun.ru?

Please ask those questions on Discord, stop creating Issues here
https://courses.beatrun.ru
https://discord.com/channels/1113394230002454560/1113443771569418270


Not sure how to add package with same name

I'm trying to add the helm package but soon realize that there are more than one. How do I specify which one to install and apply?

you're experiencing a bug in the search that didn't display the correct package name. it was fixed in the 0.9.0 release. Here's the same search on the current release:
❯ fleek search helm
 [*]  Search the package repository
 [✓]  Reading package cache
 [i]  Exact Matches
Package                 | Version | Description
kubernetes-helm-wrapped | 3.11.3  | A package manager for kubernetes
helm                    | 0.9.0   | A free, cross-platform, polyphonic synthesizer

 [i]  Try `fleek add kubernetes-helm-wrapped` to install kubernetes-helm-wrapped
 [i]  Try `fleek add helm` to install helm
 [✓]  Operation completed successfully

Here are upgrade instructions: https://getfleek.dev/docs/upgrade

reference: https://github.com/ublue-os/fleek/issues/164

Oh, yeah. I guess was running an older version. It was still using a default nix profile for fleek. After removing that the upgrade went smoothly and I can see unique package names in there now.
Thank you!

thanks for reporting success, I appreciate it.


Make the running of code more secure

Prevent the handling of files, reading system information, e.t.c. while running the code submitted.

Use docker containers instead of running the code on your local machine

This will allow you to support multiple versions of python for example

The code runs in Docker containers.
https://github.com/paulonteri/remote-code-execution-environment/blob/master/.github/workflows/deploy_backend.yml

Do you spin up a container for every code submission?
That's what you should do to avoid executing malicious code.


[observability] add metrics for throughput of metrics and logs

Tasks

[ ] Add counter metric for # of metrics currently submitted (https://github.com/libra/libra/pull/6000)
[ ] Add counter metric for bytes of metrics currently submitted (https://github.com/libra/libra/pull/6000)
[x] Add counter metric for # of logs currently submitted
[ ] Add counter metric for bytes of logs currently submitted

This is a followup from @christinacelee 's post


404 when serve http

What version of the package or command are you using?
v4.0.0-alpha.7
What are you trying to do?
Serve archiveFS using http.FileServer
What steps did you take?
caddy.tar.gz
func TestServer(t *testing.T) {
	file := "caddy.tar.gz"
	fs, _ := archiver.FileSystem(file)
	server := http.FileServer(http.FS(fs))
	http.HandleFunc("/", func(writer http.ResponseWriter, request *http.Request) {
		// disable range support
		writer.Header().Set("Accept-Ranges", "none")
		request.Header.Del("Range")

		// disable content-type sniffing
		ctype := mime.TypeByExtension(filepath.Ext(request.URL.Path))
		writer.Header()["Content-Type"] = nil
		if ctype != "" {
			writer.Header().Set("Content-Type", ctype)
		}
		server.ServeHTTP(writer, request)
	})
	t.Fatal(http.ListenAndServe("localhost:1234", nil))
}

Open http://localhost:1234
What did you expect to happen, and what actually happened instead?
Browsing archive content on the fly. But every link when opened return 404.
How do you think this should be fixed?
When matching files, nomalize NameInArchive to be cross platform compatible.
Please link to any related issues, pull requests, and/or discussion
None

Quit breaking my code, @WeidiDeng :smile:
That is a bit odd. I've been able to reproduce this (thanks for the report), but what's the use case of having a directory named "." in the archive?

Anyway, I'm a bit torn what to do with this. When you say "normalize NameInArchive to be cross-platform compatible," what do you propose exactly? It technically already is "cross-platform compatible," it's just that Go's standard HTTP file server cleans paths to remove . elements (via path.Clean()).

Quit breaking my code, @WeidiDeng ! 😄
That is a bit odd. I've been able to reproduce this (thanks for the report), but what's the use case of having a directory named "." in the archive?

git clone https://git/caddy
cd caddy
tar -czvf ../caddy.tar.gz

That's how the file is created.

@WeidiDeng Right, so it creates a folder in the archive named literal . -- is that what you intended? Why?

@WeidiDeng Right, so it creates a folder in the archive named literal . -- is that what you intended? Why?

without ., I can't even create the archive, that's how tar is working. I could go up a directory and replace . with caddy but that's required for tar to know which directory to pack.

So, don't you want * instead of .?

It's a matter of habit, even if I change mine, there are others use . and archiveFS can't handle that.

Even if I use *, cmd directory below root returns a go file instead of directory listing, there are definitely corner cases to be considered.

ArchiveFS should handle those appropriately.

I think we do handle it appropriately... the "bug" (if it can be called that) is in the std lib http.FileServer.

Even if I use *, cmd directory below root returns a go file instead of directory listing,

What do you mean? * worked fine for me, can you be more specific? What is the actual command, dir structure, and result?

ArchiveFS should handle those appropriately.

I think we do handle it appropriately... the "bug" (if it can be called that) is in the std lib http.FileServer.

Even if I use *, cmd directory below root returns a go file instead of directory listing,

What do you mean? * worked fine for me, can you be more specific? What is the actual command, dir structure, and result?

The result archive from * command doesn't have top level . directory.
Also, in open, there exists a similar problem like 330, directory doesn't have entry in the archive file.

All in all, I think precomputing a path to FileInfo map is helpful, at least Extract interface is stable enough to do this. On the fly traversal simply has too many corner cases to consider.

The result archive from * command doesn't have top level . directory.

That sounds like the desired result then. I think that is probably the best/proper fix. That's just how tar works: if you give it a directory, it'll tar a directory. So I don't find the behavior surprising; maybe open an issue upstream with Go if you think the behavior of http.FileServer (or http.FS) should be changed. :+1:

Also, in open, there exists a similar problem like https://github.com/mholt/archiver/issues/330, directory doesn't have entry in the archive file.

Can you elaborate on that?

The result archive from * command doesn't have top level . directory.

That sounds like the desired result then. I think that is probably the best/proper fix. That's just how tar works: if you give it a directory, it'll tar a directory. So I don't find the behavior surprising; maybe open an issue upstream with Go if you think the behavior of http.FileServer (or http.FS) should be changed. 👍

Rar suffers from the same problem. Several of my rar files have top level . directory, others don't. If you don't like it, that's fine with me.
Can you at least document that even with the normal archive file, how to disable content-type sniffing and disable range request, that's actually helpful to know.
this file when used directly, you can't download rar inside it directly, because golang sniff content-type and it will cause seek to fail error.
When only disable content-sniffing, browser download it fine, but aria2c can't, because it uses range request.

Also, in open, there exists a similar problem like #330, directory doesn't have entry in the archive file.

Can you elaborate on that?

There is not internal directory in the tar directory listing. Like in the issue. Some folders just don't have entry in archivefs.


Support multiple paths from the command line.

I need the multiple-path functionality added in #31 to be available on the command line.
I am splitting the string on commas for simplicity, but if another approach is preferred that would be fine.

This looks pretty good to me. I'll run some tests on this and merge it in this week. Hopefully we can get a release out too. Thank you.

Any chance of getting this merged soon?

@andygrn soon. I just took a new day job and have a couple other PRs to include into a new release. Planning for this week yet (I hope!)

@andygrn @raineorshine Published to NPM as 0.5.0


Add a way to generate arbitrary gates using real parameter angles

Add generic unitary gates with arbitrary angles. This can be tested by doing gradient descent on a TFIM to find the ground state with a small quantum circuit.

Below is the result of running the examples/brickwork_unitary.jl script for the TFIM with parameters
nbits = 4;
nlayers = 3;
J = 1;
h = 0.5;
g = 0;

The Hamiltonian is used for gradient descent on the brickwork circuit with 3 layers (2 gates, 1 gate, 2 gates).


js-interop: Wrapping JS-objects into Dart-class

How to wrap js-object having dash in property name with @anonimous Dart-class? JS-object like this:
{
  . . .
  'some-property': 'value'
  . . .
}

You need to use
package:js/js_util.dart
to get and set that property.
You couldn't access that property with dot syntax in JS. The goal with JS interop is only to support properties that could be accessed with normally in JS.
To access this property fro dart you would write
import 'package:js/js_util.dart' as js_util;

Object getSomeProperty(Object someJsObject) {
  return js_util.getProperty(someJsObject, 'some-property');
}

Thanks. This works


Warm the Vendor API cache

Context
The ApplicationChoice#index is slow at the best of times.
We have a situation where there are 1000s of records being returned for a very small duration of 2 days.
In order to help speed up the response to API clients, we can warm the cache.
Changes proposed in this pull request

Add WarmCache service
Run WarmCache in the WarmCacheWorker
Schedule the Worker to run every 23 hours.

Guidance to review

Things to check

[ ] If the code removes any existing feature flags, a data migration has also been added to delete the entry from the database
[ ] This code does not rely on migrations in the same Pull Request
[ ] If this code includes a migration adding or changing columns, it also backfills existing records for consistency
[ ] If this code adds a column to the DB, decide whether it needs to be in analytics yml file or analytics blocklist
[ ] API release notes have been updated if necessary
[ ] If it adds a significant user-facing change, is it documented in the CHANGELOG?
[ ] Required environment variables have been updated added to the Azure KeyVault
[ ] Inform data insights team due to database changes
[ ] Make sure all information from the Trello card is in here
[ ] Rebased main
[ ] Cleaned commit history
[ ] Tested by running locally
[ ] Add PR link to Trello card

 Warm the Vendor API cache

Caching appears stable - we don't feel that this is required anymore.


deploy to Bluemx link - fixes issue #8

Added simple link for now - I need to test it when it reaches the master branch. I can add a fancier button that tracks the number of deployments if required. But this is MVP. I had to rework the way the environment variables work - I made it assume that a missing "MBAAS_DATABASE_NAME" meant a database name of "mbaas". This saves the Bluemix user from having to create a custom environment variable to get this to work - it finds the port number and the Cloudant config from pre-existing env variables.

👍

Fancier button notwithstanding, don't we want to know when this is deployed (by using the deployment tracker)?

We do @bradnoble. Just wanted to test whether deploy to bluemix link worked ok first. Then I'll swap out for  fancy tracking button.


Updates to cdk-integ-tools to support CDK v2

Issue #, if available: 401
Description of changes:
Add cdk-integ-assert-v2 for validating CFN templates ignoring the expected diffs due to CDK v2
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

AWS CodeBuild CI Report

CodeBuild project: codebuildgithubautobuildPro-fkVQbXRiQi6A
Commit ID: 122342f09c91752e26dbbadeeb168e2683414ad8
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: codebuildgithubautobuildPro-fkVQbXRiQi6A
Commit ID: f6182366e13242228487c172a1f976e09eec3ba9
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: codebuildgithubautobuildPro-fkVQbXRiQi6A
Commit ID: cbc6039c32ca3d06f302253b1650f8e2f4c27c0e
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository


Remove SENTRY_CSP_URL env var and references

Having some difficulty adding this env var, which has now blocked the pipeline. Removing all references to SENTRY_CSP_URL to unblock the editor deployment pipeline.

Closing as this has been resolved in https://github.com/ministryofjustice/fb-editor/pull/2272


Windows testing

@OClement had a Windows issue where paths are being built in of the following form:
"npm:react-router@0.12.4/C:\Users\O\.jspm\packages\npm\react-router/index".
I have no idea how the .jspm folder is getting in here.
It would be good to do some testing on Windows to see if we can replicate this build issue at all.
@OClement if you can provide a simple repo that replicates this on Windows that would help a lot too.

Will try to recreate one as soon as I can
Thanks

Le 2015-03-01 à 07:34, Guy Bedford<EMAIL_ADDRESS>a écrit :
@OClement had a Windows issue where paths are being built in of the following form:
"npm:react-router@0.12.4/C:\Users\O.jspm\packages\npm\react-router/index".
I have no idea how the .jspm folder is getting in here.
It would be good to do some testing on Windows to see if we can replicate this build issue at all.
@OClement if you can provide a simple repo that replicates this on Windows that would help a lot too.
—
Reply to this email directly or view it on GitHub.

Hello, coincidentally I stumbled upon this exact problem @OClement is having.
I've created a quick public repo that should hopefully explain, along with reproducible steps in the readme, it is pretty easy to recreate on windows from scratch.
https://github.com/richardhallett/systemjs-issue95

@guybedford I've moved my repo to Github and made it public
This is the actual code that fails on Win for me:
https://github.com/OClement/CKWEB_2015

Thanks. Ok sounds like this is more critical then - will do some windows testing asap.

This is fixed now in jspm-npm 0.20.3 (https://github.com/jspm/npm/commit/59cb342820ee41759b712c416ae71531d7e73274). If you run an npm update of jspm it should update to use this version of the endpoint. Do let me know if you spot any other windows issues at all!


OpenACC and/or OpenMP support

Given the ubiquity of these programming models, and some downstream desires, it might be worth looking into what it would take to add these programming models as well.
The basic programming model in both cases is #pragma based decoration.  I think there are now examples of at least one of these in Kokkos.
Given how this library is intended to be used, it might be easy to extend it to mark functions as needing to be compiled for device, and we might not need to worry about data locality issues.  We probably need to play with some examples in simple downstream codes in order to understand the issues more.
Relates to #12 because it opens the possibility of having Fortran decorators as well.

Agreed---I think OpenMP support has to be on the list to support Pagosa in the very near future.


[Drop down] Need a way to customize selected item highlight

Bug Report
Need a way to customize selection of drop down control, so, we may compose it from header and sub-header parts as shown on picture below.

Steps
A clear and concise description of steps to reproduce the problem.
Expected Result
The result that you expected.
Actual Result
The actual result that happened 💣
Version
0.21.0
Testcase

Please use a correct tracker when you're creating issues:

And fill descriptions fully, it will help us to provide solutions and fixes faster 👍

If you mean case with multiple selection, it's already possible: https://stardust-ui.github.io/react/dropdown#usage-render. I also prepared an example: https://codesandbox.io/s/xo6nk5y29w?module=/example.js
If you mean case with single selection, it's possible, too: https://codesandbox.io/s/wqpm1vp5kk
However, it's much more little tricky, but it's satisfies your needs, it's possible to customize it.

Closing for housekeeping, please let us know if you need additional help 👍


3.17.0-Preview: Adds new preview release and updates changelog

Pull Request Template
Description
This adds the changelog notes and updates the preview version to 3.17.0-preview
Changes between 3.15.0-preview and 3.17.0-preview

Hello, it looks like you're creating this PR without the necessary working being completed. This PR #1526 was promised via support ticket<PHONE_NUMBER>09048 to be included in this release. Please complete this PR before releasing this as promised.

@dpiessens that PR was closed based on inactivity, there was no activity since May 2020, you could contact the author to follow up but that work was not slated on this release.

@dpiessens that PR was closed based on inactivity, there was no activity since May 2020, you could contact the author to follow up but that work was not slated on this release.

OK but it's linked to issue #993 which was reopened and assigned to someone on your team. Additionally we've been working with MS support who told us the issue would be done for 3.16, then that it didn't make that release and was slated for 3.17? So, either they were being dishonest, or your team was giving them false information.
I can pick up this PR and make the remaining changes. Given the combination of how minor the change it, how it accounts for a significant gap in the C# API, and our willingness to contribute to something that was done, I'd ask you hold 3.17 until this can be incorporated so we don't need to wait another 8 weeks before consuming it.


Cloudfront distribution tweak for react router

Please describe which feature you have a question about?
Built-in Cloudfront distribution. Possibly related to https://github.com/aws-amplify/amplify-console/issues/40.
Provide additional details
I've got a tiny problem with my react app. The way react router dom is built - it requires a little Cloudfront hack to work with S3 hosting.
Otherwise links in the app will be hopelessly broken.
I love the way Amplify Console simplifies CD flow for react apps greatly, but unfortunately I can't edit Cloudfront distribution for the app? It doesn't appear neither in aws cloudfront list-distributions output nor in management console.
Is there any way to leverage Cloudfront functionality with amplify console for react apps?

@swaminator I need the Custom Error Page functionality from these aws docs.
This would allow me to customise an error path for 404 (and possibly 403 as well) code as described here.
Unfortunately I can't see any other way to fix react-router-dom with S3 hosting just now. See the link above for the router issue description.
Hope it helps. Happy to answer any more questions.
Y

@swaminator that worked! Thanks a lot!


Add constants for common HTTP header names, media types, and status codes

This resolves #88
This adds trait/object pairs for HTTP header names, media types, and status codes.
Header Names
A complete list of header names is here, though not sure it's worth adding all of them, so I started with the set defined by Play. I'm open to using a different source.
Media Types
A complete list of media types is here, though not sure it's worth adding all of them, so I started with the set defined by Play. I'm open to using a different source.
Status Codes
This was easy to use the complete list defined here. I did not include any non-standard ones like 418, 420, etc.
Note I had to change the imports to BasicTests.scala to avoid conflict with StatusCodes and MediaTypes.

I'm not sure what happened, but my fork is way behind, possibly because I already had the repo forked from previous commits. I think I'll just recreate this PR from scratch...


Customisation of dist-tag/branch mapping?

Shall we allow customisation of the dist-tag/branch mapping. If so, perhaps with a publish.config.json in the root of the package, something like:
{
  "distTagBranchMap": {
    "latest": "master",
    "beta|next": "develop"
  }
}

Closing this as we're not mapping, rather always releasing from master, unless an npm whom pre-release.


[WIP][Test only][DEMO][SPARK-6235]Address various 2G limits

What changes were proposed in this pull request?
The main changes.

Replace DiskStore method def getBytes (blockId: BlockId): ChunkedByteBuffer to def getBlockData(blockId: BlockId): ManagedBuffer .
ManagedBuffer's nioByteBuffer method return ChunkedByteBuffer.
Add class ChunkFetchInputStream, used for flow control
Move class ChunkedByteBuffer, ChunkedByteBufferInputStream and ChunkedByteBufferOutputStream to common/network-common/src/main/java/org/apache/spark/network/buffer/
Replace ByteBuffer with ChunkedByteBuffer

Test build #63783 has started for PR 14647 at commit dc9ffd6.

Test build #63783 has finished for PR 14647 at commit dc9ffd6.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
public class ChunkedByteBuffer implements Externalizable
public class ChunkedByteBufferInputStream extends InputStream
public class ChunkedByteBufferOutputStream extends OutputStream
public class ChunkFetchInputStream extends InputStream
public class ChunkFetchStreamCallback implements StreamCallback
  case class LaunchTask(data: ChunkedByteBuffer) extends CoarseGrainedClusterMessage

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/63783/
Test FAILed.

Test build #63784 has started for PR 14647 at commit a211c1a.

Test build #63784 has finished for PR 14647 at commit a211c1a.

This patch fails MiMa tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/63784/
Test FAILed.

@witgo Could you provide a more high level description of this PR? I am curious to see which problem you are trying to solve? Also see @srowen's comment on the JIRA.
The sheer size in lines of code and files modified make this a challenge to review. Is it an option to split this PR in number of smaller PRs? The other thing I am missing are tests.

@hvanhovell
I will submit some small PRs and provide a more high level description of them.

@hvanhovell  #14658 , #14662 and #14664


ITM: don't test reserved bits in is_fifo_ready

On ARMv7-M, bits 31:1 of the value read from STIMx are reserved, so
comparing them against zero is a bad idea.
On ARMv8-M, bit 1 has been repurposed to indicate DISABLED. This means
that the is_fifo_ready impl hangs forever when ITM is disabled on a
Cortex-M33 (for example).
Changed to test only the FIFOREADY bit.
@bcantrill

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @thejpster (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

Ugh. So, I have bad news.
On the one hand, this change makes v7-M more correct.
On the other hand, it turns out that this isn't sufficient to fix v8-M. Here's the deal.

Bit 1 has been repurposed to mean DISABLED on v8-M.
Bit 0 is still FIFOREADY
The reset state appears to be DISABLED and (importantly) not FIFOREADY.
On v7M the reset state is undefined, but on the STM32F407 at least it is FIFOREADY.

So, on reset, with no debugger attached, if one wants ITM writes to succeed, you've got two options:

Implement architecture-version-specific logic.
Read the reserved bits I just fixed. :-)

While ARM described the bits on ARMv7-M as reserved, if you look at their pseudocode, they're treating anything other than 0 as ready to write. This logic works on both v7-M and v8-M but is technically dealing in reserved bits.
I'm happy to fix this either way, but I wonder if anyone has a strong opinion on approach?

Ah, that's a nuisance! I think architecture-specific logic is the way to go then. Keep the current behaviour for thumbv7 and add the alternative check of DISABLED and FIFOREADY for thumbv8. We already do this sort of check extensively in this crate so I don't see any reason not to do it here.


collect-bmc-data

Collect out of band data at a low sample rate and interpolate
results. Find a way to get access to this data on the compute
cores, especially when CPU doesn't have access to out of band
network supporting BMC data.

Related to #2047
Related to #2048
Related to #2049
Related to #2050


Support for Rails 5

Tests for Rails 5 is failing.
Please include the same.
Getting the following error:
RSpec::Rails::SystemExampleGroup
  #method_name
LoadError: cannot load such file -- capybara System test integration requires Rails >= 5.1 and has a hard dependency on a webserver and `capybara`, please add capybara to your Gemfile and configure a webserver (e.g. `Capybara.server = :webrick`) before attempting to use system tests.

Pending: (Failures listed here are expected and do not affect your suite's status)

  1) RSpec::Rails::ControllerExampleGroup in a namespace sets up resourceful routes on the example
     # Not yet implemented
     # ./spec/rspec/rails/example/controller_example_group_spec.rb:222

Hello @utkarsh2102!
If you're running rails 5.1, you'll need to add capybara to your Gemfile to get system tests to work.
e.g.
gem "capybara",  "~> 3.12"
If you're running rails lower than 5.1, you will need to upgrade to be able to use system tests.
I hope that helps!


Consolidate logic related to extracting data from a BulkOperation

Description
With the addition of the create action, there is need to branch when extracting data from a BulkOperation. This adds helper methods to BulkOperationWrapper to consolidate this logic in a single place. It also resolves a bug with the create action and writing to a DLQ
Issues Resolved
#3040
Check List

[x] New functionality includes testing.
[x] New functionality has been documented.

[x] New functionality has javadoc added

[x] Commits are signed with a real name per the DCO

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Is there an ETA for this being included in a release?


Refactor the scanner

Rob Pike had a good talk on the subject.
https://www.youtube.com/watch?v=HxaD_trXwRE
https://go.dev/talks/2011/lex.slide
Some thoughts:

Use a more standard lexer/parser architecture. It has a similar CommentScanner/TODOScanner architecture but this could be cleaner.
Don't use regex to parse TODO comments. Instead generate lexemes from a lexer that can then be put together into full todos by a parser.
Rob Pike's idea to have states be functions was neat but I'm not sure I like that when a state has to hold data. Instead maybe make it a simple interface with a Run method. This would allow states to more easily hold data.type state interface {
  Run() state
}

Consider building a generic lexer/parser package using generics.

I can also perhaps just read from a byte reader and check the individual bytes match the starting characters for comments strings etc.  This is because pretty much all languages use ASCII characters for these which are represented as bytes. I can then just scan to the end of the line or to the end of a multi-line comment to get the comment bytes and convert them to utf8. That way I don't have to convert all bytes in every file.


Executing ExampleStartupBenchmark with or without baseline-prof.txt does not produce very different results

I went through all the steps to generate a baseline profile with the gradle virtual device.
Running ExampleStartupBenchmark using the generated  baseline_prof.txt, I had results similar to the codelab's. Results about 5% less than with the None compilation mode.
I wanted to do the same test, but without a baseline profile. So I deleted the baseline profile, deleted my app build folder, and ran the test again.  I got really similar results than with the baseline profile.
Do you have any idea on why this is happening?

We had some troubles in past with pre-installed code on the device on a non-rooted build.
Could you try with the latest versions of the profile installer and macrobenchmark?
Alternatively, would it be feasible to measure the results on a userdebug (rooted) device? On rooted devices, we can properly clear the app state between the benchmarks, which results in good measurements.
In any case, this only affects measuring the results, not the Baseline Profiles directly. Alternatively, you can upload the APK with generate Baseline Profiles to Google Play and you should see the benefits in Play Vitals or any other service you use for measuring app startup or jank

I'm going to close this due to no activity, but feel free to reopen if you still see no improvements when using Baseline Profiles. Thanks! 🤗