Target tier policy

Rust developers regularly implement new targets in the Rust compiler,
and reviewers of pull requests for such new targets would like a clear,
consistent policy to cite for accepting or rejecting such targets.
Currently, individual reviewers do not know what overall policy to
apply, and whether to apply solely their own judgment or defer to a Rust
governance team.
Rust developers regularly ask how they can raise an existing target to
tier 2 (and in particular how they can make it available via rustup),
and occasionally ask what it would take to add a new tier 1 target. The
Rust project has no clear official policy for target tiers. People not
only don't know, they don't know who to ask or where to start.
This proposal documents an official policy for adding new (tier 3)
targets, and for raising targets to tier 2 (with rustup builds) or to
tier 1.
Based on discussions with the compiler team and representatives from
other teams.
Note: when merging this RFC, please don't squash-merge.
This policy has gone through substantial revisions, and the history of those revisions would be useful.
Rendered

cc @rust-lang/compiler @rust-lang/infra @rust-lang/release

Thanks for writing this Josh! :tada:
Left a few comments and added T-infra and T-release.

Something we might want to clarify is the distinction between being tier 1/2/3 as a cross-compilation target and being tier 1/2/3 as a host platform, possibly including even tools in the last definition. I think formalizing that (and adding the categorization to the forge) will reduce the confusion about what's actually supported.

This may be off-topic: but I think it would be nice to be clearer about the definition of a tier and a platform.
For example, tier 1 says "pass tests", but can I just add #[cfg(not(my_platform))] in front of a test to make it pass?  Can I do that to a few tests?  A lot of tests?  There is also some amount of graduated support.  For example, some features may be disabled or degraded on older versions of a platform.  Usually that's because the platform doesn't fundamentally support it, but what if it is because I'm not in the mood to load a Windows 7 VM to fix it, so I just disable something because it is "too hard" to support?
Also, which version of a platform is supported.  The forge page currently lists macos 10.7+ and Windows 7+ as "tier 1" status, but I would be surprised if macos 10.7 still works.  And very few tier 2 platforms mention which version is built.  Should targets list their version?  Should that version be kept up-to-date with reality?  For tier 1, that would be macos 10.13, Windows Server 2016, linux is still kernel 2.6.18.  And only those versions are tested, not newer ones.  Should it be documented which version is tested, and which versions are intended to be supported?
Is there any expectation about when newer versions of a platform will be supported?  If 1.39 was released without supporting macos 10.15, is that OK?  What about 1.40?  How soon should newer versions be supported?
Platforms also have a suite of tooling that may be required, such as linkers.  Are there any guarantees about which versions of those are required?  Can I decide to stop supporting an old version of xcode?  Can I say "you must use clang, gcc is not supported"?
Feel free to ignore if this is too out of scope.  Most of these are judgement calls, but some guidance might help making those decisions and communicating what is actually supported and tested.

@shepmaster I made PR changing the style from a list of bullet points to using IETF verbs, "MUST", "MUST NOT", etc. Is this along the lines you were thinking?
https://github.com/XAMPPRocky/rfcs/blob/target-tier-policy/text/0000-target-tier-policy.md

to using IETF verbs

I'm personally fine with either style.
I won't claim to be an IETF-style expert. There's something nice about the certainty of those established words, but I'm not sure how well the current content fits within that framework.
I don't object to Rust's looser styling either, so long as we are clear about which pieces we expect to be (mostly) objective and which to be (mostly) subjective.
I think the key piece I'd like to see is the clearly differentiated transitions. Using some silly made-up requirements for example:
# Tier 1
## Requirements
### Objective

- Code comments for this target must be written in Pig Latin
- Compiling this code speeds up the compiler build process by 10 minutes
- All Tier 2 objective requirements

### Subjective

- The target is used by Really Big and Awesome companies that we like.
- We like the primary terminal emulator on this platform
- All Tier 2 subjective requirements

# Tier 2
## Requirements
### Objective

- Code must use a maximum width of 5 characters
- Compiling this code introduces at least 10 new compiler warnings

### Subjective

- Code must make us feel warm and fuzzy

# Transitioning
## Tier 1 to Tier 2

If the target fails to adhere to the Tier 1 requirements for 1 day, then the X
team(s) may downgrade this target to tier 2.

## Tier 2 to Tier 3

If the target fails to adhere to the Tier 2 requirements for 1 year, then the X
team(s) may downgrade this target to tier 3.

## Tier 2 to Tier 1

If the target adheres to the Tier 1 requirements for 1 month and @shepmaster receives
a payout of $1000USD,  then the X team(s) may upgrade this target to tier 1.

Another aspect that occurs to me is that it's likely worth expressing why we have a given requirement (or even a lack of requirement). While it might seem self-evident why having CI is important, including the rationale for that will give us more context when we apply subjective criteria or attempt to update the rules in the future.

I'd like to see more focus on target tier vs host tier. Many embedded devices will never, ever, be hosts to the rust compiler, but they should be able to be above tier 3 a targets for a build.

The draft states that Tier 1 targets may be "demoted or removed", but in #2837, there's some discussion (starting here) about how surprising it is for a Tier 1 target to jump all the way to Tier 3 in a single release. I think it's reasonable to permit this sort of "jump", but the document should probably explicitly state that it's allowed.
I do think it would be quite surprising to entirely remove a Tier 1 target. Perhaps a better policy would be that Tier 1 targets must be demoted to Tier 3 for at least one release cycle before being removed.

@BatmanAoD That PR doesn't propose removal of the code. It only proposes stopping to build the artifacts and run tests on those platforms. It will be one release before dropping to tier 3 support.

Might we have a maximum of 1 level of demotion per release? So tier-1 would drop to tier-2 for a release before becoming tier-3 the next release. Helps ease the process a little bit for end users, though I'm not sure how much burden that puts on the infra team.

@XAMPPRocky I don't understand the objection; stopping building the artifacts is demoting to tier 3, isn't it?
In any case, my point is not about that specific demotion; it's just that this document should be more explicit about how demotions work in general.

Might we have a maximum of 1 level of demotion per release? So tier-1 would drop to tier-2 for a release before becoming tier-3 the next release. Helps ease the process a little bit for end users, though I'm not sure how much burden that puts on the infra team.

The burden on the infra team is negligible (demoting a target basically means removing CI builders, so for Tier 1 => Tier 2 we remove the test builder and for Tier 2 => Tier 3 we remove the dist builder), but I'd argue demoting step by step is worse for end users.
When a platform is Tier 1 it's guaranteed to work (as we run test), when it's Tier 2 it's available through rustup but not tested anymore, and when it's Tier 3 it's not available through rustup at all.
If we go directly from Tier 1 to Tier 3 users will go from having a build that's guaranteed to work to no build at all. Instead, if we demote step by step they'll rustup update to a possibly broken build, and they'll be stuck with that as the last available compiler.

I just noticed this
https://github.com/rust-lang/rust/blob/451d4925f7bf98f069c553e6af8f549f57ab6efa/src/tools/tidy/src/deps.rs#L57-L58
So now I'm wondering: should we add some kind of "new targets must not introduce libraries with so-and-so licenses" requirement too?

Wow. Yes, I think we definitely need that to be explicit, because otherwise
it seems inevitable that it will be violated inadvertently.
On Sat, Feb 29, 2020, 12:27 PM Ixrec<EMAIL_ADDRESS>wrote:

I just noticed this
https://github.com/rust-lang/rust/blob/451d4925f7bf98f069c553e6af8f549f57ab6efa/src/tools/tidy/src/deps.rs#L57-L58
So now I'm wondering: should we add some kind of "new targets must not
introduce libraries with so-and-so licenses" requirement too?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rfcs/pull/2803?email_source=notifications&email_token=AARU4T72KMEVLZRLSZCVWODRFFQSTA5CNFSM4JIN3GBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENMD3SA#issuecomment-592985544,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AARU4TZAPEBVRY5QSEC36WTRFFQSTANCNFSM4JIN3GBA
.

@pietroalbini Would it be feasible to teach rustbot to have some labels associated with marker teams, so that adding certain labels will automatically cause rustbot to ping specific teams?

With some of these pushes, it's suddenly a little less clear what an "OS = none" environment should do.

The core crate will (hopefully) "just work" on its own, since it doesn't rely on much at all.
The alloc crate will require a Global Allocator to be defined somewhere, but a user can obtain that via a crate on crates.io or provide it themselves.
The std crate, that is the things that are unique to std and not just re-exports from other crates, almost entirely is just code to perform "operating system" sorts of actions  (file system, clock, network, etc) in a cross platform way.

Perhaps a note that os=none environments are largely expected to not support std itself? Given Rust's wide range of embedded usage, that seems like an important case to have be clear.
Separate from the OS concern, I think that what's most likely to be an issue for new tier3 targets is possibly needing a specific linker script to perform a correct build. This doesn't need to be written into the RFC, but how do custom linker scripts interact with the standardized rust targets? That is, compared to just using the "std aware cargo" feature and building core/alloc using your own custom target json.

@ehuss wrote:

This may be off-topic: but I think it would be nice to be clearer about the definition of a tier and a platform.
For example, tier 1 says "pass tests", but can I just add #[cfg(not(my_platform))] in front of a test to make it pass? Can I do that to a few tests? A lot of tests? There is also some amount of graduated support. For example, some features may be disabled or degraded on older versions of a platform. Usually that's because the platform doesn't fundamentally support it, but what if it is because I'm not in the mood to load a Windows 7 VM to fix it, so I just disable something because it is "too hard" to support?

I've added a requirement about this.

Also, which version of a platform is supported. The forge page currently lists macos 10.7+ and Windows 7+ as "tier 1" status, but I would be surprised if macos 10.7 still works. And very few tier 2 platforms mention which version is built. Should targets list their version? Should that version be kept up-to-date with reality? For tier 1, that would be macos 10.13, Windows Server 2016, linux is still kernel 2.6.18. And only those versions are tested, not newer ones. Should it be documented which version is tested, and which versions are intended to be supported?

I've added some explanations and requirements about this, as well as about CPU features and similar baseline expectations.

Is there any expectation about when newer versions of a platform will be supported? If 1.39 was released without supporting macos 10.15, is that OK? What about 1.40? How soon should newer versions be supported?

I don't think we need (or can specify) a hard requirement about this; rather, this is one of many ways in which we expect ongoing maintenance of a target. The reasonable length of time for such updates may depend on the magnitude of changes in the new version, the level of backward incompatibility in the new version, and similar factors.

Platforms also have a suite of tooling that may be required, such as linkers. Are there any guarantees about which versions of those are required? Can I decide to stop supporting an old version of xcode? Can I say "you must use clang, gcc is not supported"?

I've added discussions about specifying the baseline expectations of a target, and about modifications to those baseline expectations.

Feel free to ignore if this is too out of scope. Most of these are judgement calls, but some guidance might help making those decisions and communicating what is actually supported and tested.

I don't think this is out of scope at all; thank you for the feedback!

@pietroalbini wrote:

Something we might want to clarify is the distinction between being tier 1/2/3 as a cross-compilation target and being tier 1/2/3 as a host platform, possibly including even tools in the last definition. I think formalizing that (and adding the categorization to the forge) will reduce the confusion about what's actually supported.

I've added some notes about supplying host tools. Broadly speaking, these requirements are primarily about targets rather than about the availability of host tools, though typically I think we'd want a platform to be at least tier 2 before attempting to provide host tools. There are likely additional requirements for supplying host tools beyond what this policy documents, and we can elaborate on such requirements as they come up.

@Lokathor wrote:

I'd like to see more focus on target tier vs host tier. Many embedded devices will never, ever, be hosts to the rust compiler, but they should be able to be above tier 3 a targets for a build.

I've tried to ensure that every tier requirement can be met by a target that does not support host tools. If there's any requirement that seems like it prohibits a target which does not support host tools, please point that requirement out specifically, and I'll fix it.

Quick note (thanks to @pietroalbini for pointing it out): I've been hiding resolved comments to make it easier to figure out what's been addressed, but it turns out that GitHub's interface doesn't allow showing resolved top-level comments unless logged in, even though it always allows showing resolved line comments. So, when I'm done incorporating all the changes, I'll un-hide all top-level comments.

@XAMPPRocky wrote:

I made a PR changing the style from a flat list of bullet points to using IETF verbs, "MUST", "MUST NOT", etc. Is this along the lines you were thinking? I only did tier 3 as I wanted to get feedback before writing the rest.

As of the latest commit, I have now refactored all the requirements in the RFC. All of the bulleted lists are now exclusively requirements on the target (pulling out things like lists of approvers and discussions of demotion/removal). And with that change made, I then ensured that the requirements consistently use "must", "should", and "may". (I didn't change them to all-caps, but I did ensure that every single requirement carefully uses must/should/may as appropriate, and I defined those terms accordingly.)
I appreciate the suggestion!

@shepmaster I've massively overhauled the requirements at this point, and separated out requirements from transitions; the requirements lists are more of a checklist at this point. I've also highlighted some of the subjective requirements; I don't think we should separate them into separate lists, because all of the requirements are subject to good judgment, but I think that it's much clearer now how teams evaluate the requirements.

@Ixrec

I just noticed this https://github.com/rust-lang/rust/blob/451d4925f7bf98f069c553e6af8f549f57ab6efa/src/tools/tidy/src/deps.rs#L57-L58
/// These are exceptions to Rust's permissive licensing policy, and
/// should be considered bugs. Exceptions are only allowed in Rust
/// tooling. It is _crucial_ that no exception crates be dependencies
/// of the Rust runtime (std/test).
const EXCEPTIONS: &[&str] = &[
...
    // FIXME: this dependency violates the documentation comment above:
    "fortanix-sgx-abi",   // MPL-2.0+, libstd but only for `sgx` target
...

So now I'm wondering: should we add some kind of "new targets must not introduce libraries with so-and-so licenses" requirement too?

I'm working on a requirement for this, to clearly explain the target-specific aspects of Rust licensing policy. I'm currently coordinating this with the other members of the core licensing team, to address subtleties of the requirement.

@jethrogb

I support bringing clarity to the tier system. Has there been any effort of notifying existing tier 2 & 3 target owners of this ongoing RFC?

One of the problems this policy will hopefully solve is that we don't currently have any clear index of "target owners".
In lieu of that, I am hoping that a combination of TWiR and perhaps an Inside Rust blog post will draw attention to this proposed policy.

All feedback from above this point has been incorporated
I've gone through every comment in this thread above this comment, and made corresponding changes to the PR to address all of the feedback. Thank you to everyone for providing detailed suggestions, concerns, questions, and ideas.
In the absence of further feedback, I think this is ready for review by the compiler, infra, and release teams.

@pietroalbini I've also been thinking about "target tier 2" and "host tier 2" distinction as well, and I've been wondering if it would make these discussions a lot clearer if it was its own tier instead of using the "target" and "host" qualifiers?

Tier 1 — Same as today.
Tier 2 — Can build Rustc & Tools.
Tier 3 — Can build Rust programs.
Tier 4 — In the rustc codebase.

That would be an extremely useful distinction.

I've also been thinking about "target tier 2" and "host tier 2" distinction as well, and I've been wondering if it would make these discussions a lot clearer if it was its own tier instead of using the "target" and "host" qualifiers?

@XAMPPRocky that's an interesting proposal, but I think that would prevent some targets from eventually reaching Tier 1.
There are targets that can't be used as a host platform due to limitations in the underlying platform (for example, you can't ship a compiler on iOS in most cases), and some that will never be used as a host platform because it doesn't make much sense to do so anyway (for example, UEFI or SGX). I believe we want to have a path to promote all the targets to Tier 1 support (aka running tests) if there is enough interest and development efforts behind a target.
As an example, I could see us wanting to eventually support aarch64-apple-ios as a Tier 1 cross-compilation platform, even though Apple's App Store policy makes it really hard to justify promoting it to a Tier 1 host platform.

@pietroalbini That makes sense to me though I still think the "host" and "cross-compilation" qualifiers is not really clear. I would maybe even say it makes sense to organise that as five tiers, though you should chime in if this makes sense on the CI side, because a cross-compilation target could become host target. To use your example of Apple's App Store policy, Apple has over time loosened their policy over time of what kind of apps can run and Apple already ships the Swift Playground iPad app which uses the swift compiler under the hood so it is not unreasonable to believe that the iPad could become a platform where you can compile and run any code like a mac.
Summary

Can build and test as host
Can build as host
Can build and test as target
Can build as target
Exists

I'm a little unclear on 5. Would we keep around targets you can't even cross-compile to?

@Lokathor Well the proposed tier 5 is the current tier 3, so I'll defer to the RFC on keeping around targets. Sorry if that wasn't clear.

Ah, so you're saying that 5 is "we have it and it might not build at the moment" and then 4 is "we confirm that you can at least build core to that target"?
I mean really it feels like the problem is that we're trying to grapple with is using a J tier policy for a JxK situation.
along one direction is:

we hope it works, but don't maintain it as a project
we hope it works and do maintain it as a project
it must work, breaks are considered blocking

and then another direction is:

you can cross-build to this target from another target
you can run the toolchain on this target

So maybe using a 1-dimensional chart for a 2-dimensional situation will just never be satisfactory. But also I do understand in saying this that it implicitly means "moderate rewrite of the RFC".

@lokathor That makes sense, but are you sure those are really separate dimensions? Will we ever have a target that works as a host ("tier 2" in the above 5-tier scheme) but doesn't work as a cross-compile target ("tier 4" )? And will we ever have a target where cross-compile tests are guaranteed to pass ("tier 3"), and it's a valid host target ("tier 2"), but the host tests don't pass ("tier 1")?
If not, perhaps "is a valid host" should be a binary attribute of each platform in the tier policy:
Tier 3 - exists; is a "valid host" if we expect that Rust should compile on the target "some day"
Tier 2 - guaranteed to cross-compile; if valid host, rustc and tools are also guaranteed to compile on the host
Tier 1 - guaranteed to cross-compile & pass tests; if valid host, same as tier 1 in the above 5-tier scheme

Yeah, it's less like a rectangle and more like a V or something.
It's certainly easy enough to imagine a cross-compile target that's so important it's tier 1, even if it can't host the toolchain. Some sort of embedded thing, or the iPad example, or whatever you want to imagine there.
I guess just saying "is this a valid host?" is fine as a bool that imposes extra tier advancement requirements if it's set to true.

@XAMPPRocky my worry about your tiering proposal is that you're turning "cross-compilation Tier 1" into "Tier 3". Naming matters, as many companies are scared of relying on something which is not at the best support tier possible (in our case, tier 1).
Regarding naming, I have another proposal that might be easier to understand:

"Tier 1 development platform"
"Tier 1 compilation target"

New targets should not require proprietary (non-FOSS) components to link a functional binary or library.
Does this include, for example, a proprietary shared C runtime?

For instance, rustc built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library.

(emphasis mine) It seems not.

One question I have is of shipping core/alloc/std via rustup.
Essentially, tier 3 might not build, and tier 2 we strive to make sure it builds, and tier 1 blocks merges entirely if it makes the build stop.
However, is it reasonable to have some tier3 targets ship their build of core in rustup, if a build of the core lib was successful? Or could a select list of reliable tier3 targets that build regularly but aren't ready for tier2 have their standard library stored to be in rustup? Call it "tier 2.5" perhaps.
I primarily ask because the cargo "build std" ability isn't stable, and that's all that keeps a portion of the population on Nightly. If they had rustc recognize their target and have libcore available via rustup they'd be able to build programs on Stable.

@Lokathor Could you give an example where a target would be capable of reliably building support for the target such that rustup could support it, but where the target would not meet the tier 2 requirements, and could not be made to meet the tier 2 requirements?
Given that you're suggesting a motivation for this would be to avoid nightly, that suggests that the target would be available via rustup for stable, at which point it'd be unfortunate if it were no longer available in a future stable. That's more of a commitment than I think we'd want to make for a tier 3 target.
I'm hoping that this official policy pushes a lot more targets to strive for tier 2.

The GBA has almost never failed to build core via cargo-xbuild for as long as I can recall (at least a year say). The one time that the core crate couldn't build it was because of a problem with stdarch not using the correct cfg bounds on one of their functions. It was an ARMv5 thing and they assumed no one ever built Rust on a target earlier than v5 (not unreasonable, that's from 2001), so they missed the cfg and then it crashed the GBA build (which is a v4 chip). I filed a report and they had it fixed within a week (thanks again gnzlbg!).
It is of course possible to occasionally do some operation which ends up leading to needing a compiler-builtin that's not currently provided by Rust's compiler_builtins crate. Then you get a linking error if you try to make a binary. This actually happened with just integer division in debug mode when I was first starting on GBA, but we put in a PR and now you can do software divisions to your heart's content (thanks for that work goes to scottmcm and ketsuban).
However, despite the very solid stability in the building of the core lib and also in the building of binaries, I don't really expect that the GBA target will ever met the very first criteria listed for Tier2: "must have value to people other than its maintainers". Even if it could quite probably complete every single other requirement on that list, the usual number of people doing homebrew development with Rust for any particular video game console is like 1-3 people. And beyond just GBA I've seen quite a number of video game consoles that can have Rust put on them: N64, GameCube, DS, Wii, 3ds, Wii U, Switch, and PSP.
Each individual group is generally quite small in terms of users, but also it's like less than 5 seconds to build the core and alloc for a no_std target, and it's less than 50mb of space to store the build artifacts. And some of those newer targets might also pull in a C lib or something, but as long as you're not actually building the rust toolchain and its helper programs then any sort of stdlib build is doing to be lightning fast comparatively.
Of course, not every tier 3 target should instantly get a Stable release in rustup, but it should be possible to move towards being in Rustup and on Stable, even for narrowly used targets, particularly if they're not building a toolchain.
Prior Art: GHC ships all the time, but not all targets actually see all releases of GHC. Some of the non-x86_64 targets just get skipped some times. It's unfortunate, but it happens. Rust could do the same for lower-tiered targets. If you were on Stable 1.x and some horrible problem prevented 1.(x+1) from shipping out, then that release just doesn't exist for your platform and rustup update doesn't change anything for you. Once the problem is fixed and the next Stable is released (only in sync with the normal Stable release schedule) rustup would just jump you directly to 1.(x+n).

On Fri, Jul 17, 2020 at 04:14:35PM -0700, Lokathor wrote:

However, despite the very solid stability in the building of the core lib and also in the building of binaries, I don't really expect that the GBA target will ever met the very first criteria listed for Tier2: "must have value to people other than its maintainers". Even if it could quite probably complete every single other requirement on that list, the usual number of people doing homebrew development with Rust for any particular video game console is like 1-3 people. And beyond just GBA I've seen quite a number of video game consoles that can have Rust put on them: N64, GameCube, DS, Wii, 3ds, Wii U, Switch, and PSP.

That requirement was not at all intended to exclude niche targets. You
might not be able to meet the corresponding requirement for tier 1, but
to meet this tier 2 requirement, you just need to show that literally
"people other than you (or the company you work for) can use it, and
have some interest in doing so".
This requirement excludes, for instance, a target for hardware that will
never be available for use by anyone other than a small group of friends
(e.g. homebrew hardware) or employees of a specific company (e.g.
custom internal targets).
I don't think it'd be unreasonable for the GBA target to apply for tier
2.
I'm going to rephrase the requirement to make that more clear.

@Lokathor Thoughts on the clarification I just added to that requirement?

Excellent

Tier 3 targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge.

Should there be any mention of how stable a particular target name is? That is, is it allowed to rename aarch64-shep-amaz_os to aarch-jake-amaz_os if the target is tier 1/2/3? If it's allowed, any thoughts on what a process would be?
My gut feeling is that if something is tier3, we can rename the target with little ceremony, but tier2 and tier1 should require a lot more coordination.

(A quick update so that people are aware: I'm still planning to update this RFC to incorporate the last outstanding feedback, but it's taking a second priority to some of the Rust foundation work. I haven't forgotten about this, and it's still going to get done.)

I have a proposal for splitting up Tier-2 into two or more tiers. I considered presenting it as feedback on this RFC, but I think it is worth considering on its own, regardless of the status of this RFC, so I wrote-up a pre-RFC. Mentioning it here because I think it is worth thinking about in the context of this RFC, as I think they would go well together.

I've left a comment on @lambda's pre-RFC, but I'd like to bring attention to it here.
It would be very useful to be able to differentiate between cross compilation targets and hosted targets. There are many targets (e.g., embedded targets) that are very unlikely to ever be able to build an entire rustc compiler. Additionally there are hosts like AArch64 Windows where a full CI run (including bootstrapping the compiler) is currently difficult due to a lack of server hardware that can do this in a reasonable amount of time. While AArch64 Windows will eventually want to become a tier 1 host target, having a designation where we have high guarantees that the target is a viable cross compilation target would be very helpful.

I think if any targets are renamed/removed, even if they are tier 3, they should be mentioned in the release notes.
This came up in https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Dropping.20sys.2Fcloudabi/near/214732707

I've just landed substantial revisions, including an expansion to cover requirements for host tools separately (cc @pietroalbini).
I believe I've now incorporated all feedback up to this point, and I think this RFC is ready for review.

Thanks for updating the RFC Josh! :heart:
The changes on the text looks great, and while we could go down the bikeshedding path (I still prefer "tier N development platform" / "tier N compilation target") I'd be fine merging this as-is.

@rylev Thanks for the additional feedback; I've updated the RFC accordingly.
@pietroalbini I've incorporated your additional feedback as well. I also added notes mentioning "development platform" and "compilation target" for clarity. I feel like "host tools" is clearer for a tier title at a glance, but I think "development platform" and "compilation target" are useful in tier descriptions.

First, I think this RFC should be merged as is.
Second, an additional complication that this RFC does not address is "target API" version: which target symbols are required to be defined for a binary to run on the system.
For example, x86_64-pc-windows-msvc binaries compiled with the standard library implicitly rely on the InitializeCriticalSection symbol for implementing Mutexes1. However, this symbol was first available in Windows XP meaning that if the user tries to run the binary on an older system, the dynamic loader will complain that the symbol is undefined. This puts an implicit dependency for all x86_64-pc-windows-msvc binaries with the standard library on versions of Windows with AcquireSRWLockExclusive defined: Windows XP and above.
While this dependency is mentioned in the target support notes, testing does not specifically happen on older versions of those systems (e.g., testing for x86_64-pc-windows-msvc only happens on Windows 10). It is possible for use of symbols only available on newer versions of the target API to be introduced into the standard library breaking these implicit contracts without the tests failing.
Minimum target API versions are a good thing to have as we don't want to only have a standard library that is capable of support all historical versions of Windows. However, it should be noted that support for Rust on targets with older target API versions is in practice less guaranteed than the latest versions as CI testing only happens on those latest versions.
1 Soon the minimum target API version for *-windows-msvc targets will be higher as support for older versions of Windows is dropped.

First, I think this RFC should be merged as is.
Second, an additional complication that this RFC does not address is "target API" version: which target symbols are required to be defined for a binary to run on the system.
For example, x86_64-pc-windows-msvc binaries compiled with the standard library implicitly rely on the InitializeCriticalSection symbol for implementing Mutexes1. However, this symbol was first available in Windows XP meaning that if the user tries to run the binary on an older system, the dynamic loader will complain that the symbol is undefined. This puts an implicit dependency for all x86_64-pc-windows-msvc binaries with the standard library on versions of Windows with AcquireSRWLockExclusive defined: Windows XP and above.
While this dependency is mentioned in the target support notes, testing does not specifically happen on older versions of those systems (e.g., testing for x86_64-pc-windows-msvc only happens on Windows 10). It is possible for use of symbols only available on newer versions of the target API to be introduced into the standard library breaking these implicit contracts without the tests failing.
Minimum target API versions are a good thing to have as we don't want to only have a standard library that is capable of support all historical versions of Windows. However, it should be noted that support for Rust on targets with older target API versions is in practice less guaranteed than the latest versions as CI testing only happens on those latest versions.
1 Soon the minimum target API version for *-windows-msvc targets will be higher as support for older versions of Windows is dropped.

I received some questions about the current status of this RFC. This RFC needs signoffs from @rust-lang/compiler, @rust-lang/infra, and @rust-lang/release, and is waiting for a member of any of those three teams to invoke rfcbot.

Minor nits aside, this looks ready to go now, so:
@rfcbot fcp merge

@jonas-schievink I've resolved all of the nits you mentioned. Thanks!

As I noted in my review comment, this overall looks excellent. However, I felt that it was missing some further discussion on the likelihood of a split between existing targets, and those newly introduced, and the extent to which we should expect to refer to this RFC (particularly once it is accepted) when reviewing changes to existing targets. We should evaluate the relative cost of an audit in comparison to the cost of the continued -- and likely to some extent increased -- uncertainty for existing targets. Expanding upon the existing text in the future work section seems necessary.
Additionally, I would like to see some more discussion of whether the target maintainers or the Rust project/teams are responsible for ensuring that targets work well, and to what extent this changes over the tiers. I personally think that currently, particularly for tier 1 targets, this is seen as an obligation on the Rust project, not on some set of third party maintainers. I do not think we want to fundamentally shift this for tier 1 targets, and it should be a requirement for the project itself to have the people and resources to maintain tier 1 targets, not a third party; this may mean that tier 1 targets need explicit representation in the governance structure, but I think this RFC currently at least implicitly suggests that it suffices for a set of third party maintainers to be available, which I'm not sure can be true -- we can't really shift our stability policies outside the project.
I also think that this RFC is missing an unresolved question - I think definitively outside the scope of this RFC - about how users are expected to know that a target is tier 1/2/3. For tier 1 or 2 targets, it is not really feasible to tell outside consulting the platform support page. If and when build-std support becomes stable, this will potentially also be true for tier 3 targets. As Rust grows, I think it will increasingly be true that we want to inform users as much as possible when they stray outside the fully supported set, especially as the set may change over time. While the RFC includes notifications to the Rust community, it seems likely that there will eventually be people who don't see those notifications and are surprised by the removal of a target. (I imagine this likely has already happened, in fact).
The tier 2 and tier 3 targets being available (to greater and lesser extent respectively) on stable also implies a level of commitment to their presence and stability that currently is not upheld by this RFC (in particular, that we may remove tier 3 targets at anytime, and tier 2 targets with some notification). I think we cannot uphold it to some extent, but we should be explicit about this gap in our stability policy. (It is also true for tier 1 targets; unlike - say - language features, targets are not something we've really stabilized in some senses, though for many purposes they do work).
Given the length and potentially pretty unbounded scope for this RFC, I would be happy to see some expectation of continued work to investigate these questions (e.g., as part of a future work section), coupled with an amendment that until they are explored, we should not treat the RFC as sufficient with respect to changing target tiers, though it may be seen as a minimum policy that is extended in an ad-hoc manner on a case-by-case basis (particularly for the questions asked in this comment).

@rfcbot concern clarifying-questions-and-edits
I would like to see the above resolved before moving into FCP (and given the large number of different teams, am unsure if and when rfcbot will decide to move ahead, so want to register an explicit concern). Registering a single concern to avoid creating too much traffic/notifications, but overall all of the above I'd like to see addressed in some way - either through clarifying comments on thread or updates to the RFC. Happy to discuss over Zulip or similar, too, if that seems helpful.

I've now addressed all the outstanding feedback up to this point, including both point-by-point feedback and general feedback.
Regarding a few points of the general feedback:

I would like to see some more discussion of whether the target maintainers or the Rust project/teams are responsible for ensuring that targets work well, and to what extent this changes over the tiers.

The intention as presented in these requirements is that the Rust project is committing to keeping the target building (for tier 2) or building and passing tests (for tier 1), but that the Rust project cannot and should not do that without active support from the target maintainers. A target that no longer has maintainers the Rust project can call on to answer questions or fix issues will not remain at its tier indefinitely. Others might step forward as new target maintainers, but no one is required to do so, and if no one is willing and able to do so, that's a sign that the target shouldn't qualify at that tier anymore.
It sounds like you're drawing a distinction between "the target maintainers" and "the Rust project". I don't think that distinction makes sense for accepted targets; if someone is one of the maintainers of an accepted target, they are by definition a contributor to the Rust project. So, in that sense, the Rust project is responsible for maintaining the targets at their specified tiers, but some people are more responsible for a given target than others, and there's always an upper bound to which others are expected to pick up all of the slack.
We always have the ability to make a judgment call about whether we should maintain a target or demote/remove it. We've done this for Windows XP support, for instance, when we deemed the burden of ongoing maintenance higher than the value provided by preserving such support. The target tier policy documents requirements and subjective evaluations that we can use to consider such tradeoffs; we can expand it in the future.

The tier 2 and tier 3 targets being available (to greater and lesser extent respectively) on stable also implies a level of commitment to their presence and stability that currently is not upheld by this RFC

I've added some discussion about the degree to which we provide stability guarantees about target availability and tier. I've also added a point under "future possibilities" about documenting more policies in that area in the future.

I would be happy to see some expectation of continued work to investigate these questions (e.g., as part of a future work section)

I've expanded the "future possibilities" section to cover many of these points.

coupled with an amendment that until they are explored, we should not treat the RFC as sufficient with respect to changing target tiers

The RFC already makes it very clear that there are many subjective requirements, and that the requirements as a whole cannot be taken as an entirely objective point-by-point checklist leading inevitably to acceptance. I wouldn't describe any present or future version of the target tier policy in terms of "sufficient conditions", precisely because it includes subjective evaluations; the "sufficient conditions" are the signoffs from the approving teams. The "must" requirements could be viewed as "necessary conditions", but many of those are subjective as well, and while the approving teams should not knowingly grant exceptions to "must" requirements, they may find nuance in those requirements that requires updating. If the approving team members find themselves making a subjective judgment call that isn't directly captured in the rules-as-written of the policy, the policy as written may need updating to some degree, to better capture and document the requirements we're aware of. If we find more nuance within those subjective judgments, we may be able to document them and provide precedent. The degree of specificity we should use when adding or updating requirements depends on whether we expect them to arise again, and how much nuance and precedent we will need to evaluate them.
With all that in mind, I'd suggest that any unspecified or as-yet-unstated requirements are things that the approving teams can apply their judgment about as they arise, and document accordingly to avoid leaving them as unwritten or unstated requirements. They don't prevent the application of the target tier policy as part of the evaluation and approval process for targets.

@rfcbot resolve clarifying-questions-and-edits
I've had a chance to review the latest draft and some of the feedback you gave in response to my broader comments, @joshtriplett -- I think this looks good to me. We may want to iterate further, but I think this gets us meaningful progress, and as it is definitely true we're continuing to see interest, I think it makes sense to aim to merge this. We can iron out problems as they arise with implementation in practice, and perhaps document patterns common to its application to existing and future targets.
Thanks so much for the hard work here!

@rfcbot reviewed

Hi, I was linked to this RFC from rust-lang/rust#84475 by @jyn514. I've read through the recommendations on moving a target from Tier 3 to Tier 2. My primary interest is in seeing builds published for a different (very well supported by LLVM) CPU architecture for an operating system that already has a Tier 2 target, which from my perspective as someone external to the Rust project isn't a major compiler change, but a testing and infrastructure change.
From looking at the major change proposal template, it seems to be intended for major code/languages changes, when the tier change is really based mostly around infrastructure. As a person external to the rust compiler project, it's unclear how I should format my proposal.

@niacat I would suggest taking the tier 3 and tier 2 sections of this policy, quoting them in full, and responding to each bullet point stating how the target meets that requirement. That should provide all the information needed to evaluate the MCP.

@joshtriplett IIUC aarch64-unknown-netbsd is already tier 3, so I think @niacat should only have to explain the tier 2 requirements, right?

@jyn514 Given that all of the tiers incorporate the requirements of each lower tier by reference, I think it's generally a good idea to confirm all the requirements on each proposed tier promotion.

I've submitted https://github.com/rust-lang/rust/pull/84583 to add this policy alongside the platform support page, in the rustc documentation.


New package: epi052.feroxbuster version 2.10.3

Pull request has been created with komac v2.2.1 :rocket:
Microsoft Reviewers: Open in CodeFlow

Verify:


Update main.yml - remove deprecated include

On newer ansible versions, there is a deprecation warning

ERROR! [DEPRECATED]: ansible.builtin.include has been removed. Use include_tasks or import_tasks instead. This feature was removed from ansible-core in a release after 2023-05-16. Please update your playbooks.

This PR fixes this

Can you take a look at this @rarrais ? This still fails in Ubuntu 22.04


fix(grid-list): update non-reactive properties

:tada: This PR is included in version 11.2.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Wrong types

I just realized some of the TypeScript types I implemented in the last PR are not accurate at all:

LanguageServerClientOptions requires a documentUri, which is not necessary for the client
And languageServerWithTransport doesn't actually always need a transport if client is passed

I will fix this asap

@marc2332 Thank you for revisiting this. Sure, a PR would be appreciated.


Fix the issue that the splits cannot be skipped for some special case

In some rare case, the tables created by other engines would put the
partition key columns in the data file too, and fail to write ColumnStats
for such columns. In such case, the split from a partition with NULL
partition keys failed to be skipped, causing wrong results. This is
because HiveConnectorUtils::testFilters() assumes the partition keys are
not in the data file, therefore is unable to apply the filter on the
partition key. This commit fixes this issue by also checking the partition
key list even when the partition columns are in the data file.

Having partition key in file is a wrong thing to starts with. Where and when is the error introduced and how easy is it to fix it on the write side?

@Yuhta Iceberg writes in this way in both Presto and Spark.

@yzhang1991 That's unfortunate.  We should have comment in code that we are doing this for unfixable bug in Iceberg

Having partition key in file is a wrong thing to starts with. Where and when is the error introduced and how easy is it to fix it on the write side?

@Yuhta For some table formats like Iceberg, the partition management is different than Hive tables. Iceberg uses "partition spec" in manifest files and does not exclude the column in the data file. It was a legitimate Iceberg table, just missing the stats. Since we only have one HiveDataSource class and didn't choose to subclass it to handle such cases when skipping partitions, we need to handle it here.

We should have comment in code that we are doing this for unfixable bug in Iceberg

This is not a bug of Iceberg but by design. I'll add some comments.

@Yuhta I checked my code and see comments were already added:
// The partition key columns are written in the data file for
      // IcebergTables, so we need to test both cases
      if (!rowType->containsChild(name) || iter != partitionKey.end()) {
        if (iter != partitionKey.end() && iter->second.has_value()) {
          // This is a non-null partition key
          return applyPartitionFilter(
              (*partitionKeysHandle)[name]->dataType()->kind(),
              iter->second.value(),
              child->filter());
        }
        // Column is missing, most likely due to schema evolution. Or it's a
        // partition key but the partition value is NULL.
        if (child->filter()->isDeterministic() &&
            !child->filter()->testNull()) {
          VLOG(1) << "Skipping " << filePath
                  << " because the filter testNull() failed for column "
                  << child->fieldName();
          return false;
        }

Do you think we need to add more comments?

Curious is there a use case in Iceberg that we read only the data file but not the manifest? If no such case then the partition column in data file is redundant and is a design bug

@Yuhta No there is no such case. The Iceberg tables write the partition keys in the data file and get the partition spec from the manifest file (or manifest file cache) in the scan planning phase. This way the Iceberg tables can change partition key easily over time, and support partition transform easily. E.g. A table can be partitioned by year(ds) at time 1, then changed to be partitioned by day(ds) at time 2, then changed to partitioned by another column e.g. supp_key at time 3.

@yingsu00 I see, thanks.  Can you update the comment to add that this is designed to implement partition column change in table format?

@yingsu00 I see, thanks. Can you update the comment to add that this is designed to implement partition column change in table format?

Sure. Updated the comment to be the following:
      // By design, the partition key columns for Iceberg tables are included in
      // the data files to facilitate partition transform and partition
      // evolution, so we need to test both cases.

@Yuhta Hi Jimmy, I addressed your other comments, can you please review again? Thank you!

@Yuhta Hi Jimmy, as you suggested, I created another PR https://github.com/facebookincubator/velox/pull/9707 that does not modify the ColumnStats writing, but with a test in ParquetTableScanTest.cpp using a Parquet file from a null partition in an Iceberg table. Please let me know which one you prefer and I'll close the other one. Thank you!

@yingsu00 https://github.com/facebookincubator/velox/pull/9707 looks good and I accepted it, it will be merged soon


Function not found

Starting from yesterday the 17th of June, some of my RPC functions are not working anymore and I receive the following error:
 {
   "message": "Could not find the public.get_user() function or the public.get_user function with a single unnamed json or jsonb parameter in the schema cache",
   "code": null,
   "details": null,
   "hint": "If a new function was created in the database with this name and parameters, try reloading the schema cache."
 }

I was wondering if there is any internal change happened from yesterday to today that could cause this?
P.S: other functions are working fine.
function:
create function get_user(user_id uuid)
    returns TABLE(id uuid, username text, full_name text, avatar text, followings bigint, followers bigint)
    language sql
as
$$
select u.id,
       u.username,
       u.full_name,
       u.avatar,
       (select count(*) from friends as f where f.follower = user_id),
       (select count(*) from friends as f where f.following = user_id)
from users as u
where u.id = user_id
  and is_not_blocked(user_id)
limit 1;
$$;

hmm, it works from console but not from flutter anymore.

Hi there-if this is related to a project hosted by Supabase, please create a support ticket via your dashboard.
Based on the fact that other functions are being executed fine, my first guess would be to verify if the permissions on the function in question have been updated recently.

Could you please retry your rpc requests? This was likely related to https://github.com/supabase/supabase/issues/7293, which was recently fixed.

Also, please retry your rpc requests. This could have been related to https://github.com/supabase/supabase/issues/7293, which was recently fixed.

@steve-chavez it most definitely was it. it works now 🤷🏼


✨🐛Add support for pasting and fix onFullfill call on backspace on last element

Description

✨Add support for pasting https://github.com/ttdung11t2/react-native-confirmation-code-input/issues/29
🐛Fix onFullfill call on backspace on last elem https://github.com/ttdung11t2/react-native-confirmation-code-input/issues/26
⚡ reduce bundle size significantly
🔧Added package-lock.json

Actions

added support for pasting by removing max length = 1 on input and spreading the characters to the next fields while taking care not to exceed the limit
fixed onFullfill being called when backspacing the last element by checking for the codeLength
reduce bundle size significantly by uninstalling lodash and using only the needed parts
added .vscode to .gitignore
added package-lock.json

Notes

VSCode auto prettifies my code according to prettier, if it's inconvenient let me know

Hello @A-Tokyo
:skull:  This repository is dead.
The author does not support it  :sob:.
I suggest using fork: react-native-confirmation-code-field, with :heavy_check_mark: long term support!
Your pr is already added to the fork!  :+1:

@retyui How was my PR added there? :D I don't remember issuing it...

@retyui Awesome job 🚀 , but how was my PR added there? :D I don't remember issuing it...

@retyui Awesome job 🚀 , but how was my PR added there? :D

Handled conflicts

@NiksCode  @lsabbagh @nishantWM Please let me know if there's anything else I need to do 👍

There is no onCodeChange function defined on line 286

@csokdara-thefoundry-app handled

this has not been implemented yet?

@DeniferSantiago It's been ready for a while, awaiting merge from contributors ✨

Too bad, don't you have a fork?

Thank you

@DeniferSantiago My pleasure


No files into test.pypi.org/simple

Describe the bug
I'm trying to create a package using testPyPI. Until version 0.0.4 the files were succesfully uploaded and installed into my machine. From version 0.0.5 when I try to install this version a error message returns "No matching distribution found for example-package-ribeiro-breno==version", even using the presented link for testPyPI. Looking for the files at https://test.pypi.org/simple/example-package-ribeiro-breno/ I only find files for versions until 0.0.4. The files for versions 0.0.5+ can be download from test.pypi.org, but they can't be installed.
Expected behavior
Expect to be able to install the latest version of my package
To Reproduce
link for my last version: https://test.pypi.org/project/example-package-ribeiro-breno/0.0.10/
link for test.pypi.org/simple: https://test.pypi.org/simple/example-package-ribeiro-breno/
My Platform
Windows 10
Chrome
VSCode
Additional context
No additional context

Hi @Ribeiro-Breno ! Looks like you're hitting up against some caching slowness in TestPyPI. I've kicked a few containers to restart the processing.
The project should be displaying correctly now.

Seems relate to #14572. It seems dd-trace is once again interfering with worker health.
We run fewer workers in test-pypi which probably led to them all being dropped sooner.

Thank you, guys, it worked now!


Bundle GPG key instead of downloading via insecure HTTP

Downloading the GPG key via HTTP defeats the point of having it in the first place. This patch bundles the key with the cookbook so the integrity of downloaded packages can be properly verified. This is especially important since the packages are not downloaded via HTTPS.
Note that the Ubuntu version of this is untested. Documentation for apt_repository suggests it will work. Feedback welcome.

Already fixed by #54


Impossible class rename

You can leave the name filed completely empty during renaming, which results in an invalid name that cannot be reverted back.
Steps to reproduce the behavior:

Open any jarfile.
Refactor -> Rename on any class.
Leave the name field empty.
Try renaming again.

Exception
Unhandled exception on thread 'mapping-applier-x'
Screenshots

Hi, I would Like to work on it

24d156f9db1af25ec85ddd445eaa33c9a29fdcd2


docs: update the auto-imports page

🔗 Linked issue

❓ Type of change

[ ] 📖 Documentation (updates to the documentation, readme, or JSdoc annotations)
[ ] 🐞 Bug fix (a non-breaking change that fixes an issue)
[ ] 👌 Enhancement (improving an existing functionality like performance)
[ ] ✨ New feature (a non-breaking change that adds functionality)
[ ] 🧹 Chore (updates to the build process or auxiliary tools and libraries)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

📝 Checklist

[ ] I have linked an issue or discussion.
[ ] I have updated the documentation accordingly.

Thanks for this but i prefer to update this section once h3 docs were ready so we know direction to go (maybe we can directly list h3 imports in nitro docs)


Update spark_submit_hook.py

We will need to add the spark dependencie (pyspark) into the image when building.
--build-arg ADDITIONAL_PYTHON_DEPS="pyspark==3.0.1"

This is not urgent, but simple enough that I went ahead and did it.


Is it possible to display highlighted word diff in github pages?

Hi,
I often use diff --color-words for smaller changes. For what I see github supports that, but I can't see how to enable that via pygments highlighter. Is it possible?

If I understand what you mean:
```diff
    --- funtion() {}
    +++ function() {}
```

Which output this:
--- funtion() {}
+++ function() {}

I rather meant something like this: http://ryrych.github.io/2015/12/13/using-word-diff-for-smaller-changes-in-git.html
or https://github.com/tiimgreen/github-cheat-sheet/pull/126/files

If I understand what you mean:
```diff
    --- funtion() {}
    +++ function() {}

Which output this:
--- funtion() {}
+++ function() {}

.github/workflows/blank.yml
ineed brif explanation


Need the currency toggle on Settings and More screen.

Need the currency toggle here. Fiat to BTC

Ignore this issue.We have this toggle button on Home screen.


chore: project addition by

Add a new project to the list
On hover can change the background of the button to text-primary or change the text of the button to text-primary it might look cool

Record

[X] I agree to follow this project's Code of Conduct
[X] I want to work on this issue

i think white is looking good.


Add Ruby as a possible language

Merge / deployment checklist

[x] Confirm this change is backwards compatible with existing workflows.
[ ] Confirm the readme has been updated if necessary.
[ ] Confirm the changelog has been updated if necessary.

We're populating the changelog now. Since this is a public-facing feature, could you add an entry. And then it's good to merge. Thanks!

There shouldn't be an entry. This is just for internal tests. CodeQL for Ruby is not available yet.


Build CoreML protobufs

This might keep in branch but since we merged coreml I'd prefer to merge it also.

sure :)


Syntactic sugar for "set if not empty"

It might be useful to have a variant of := for inside update ... set to mean "set if not empty". Elvis suggested ?:= on discord.
So set { foo ?:= expr } would be equivalent to set { foo := expr ?? .foo }.
 Or is ?? good enough?

insert can benefit from this too, ?:= would mean "if empty, us default".

So maybe this would subsume #4595. (Thought that is more flexible, but mostly not in a useful way?)

Yeah, this should cover enough of use cases to make #4595 unnecessary,


Incorrect bar data

While trying to implement my existing algorithm using this library, I ran into an issue with data.  It seems that the bar data is not correct.  I had not realized it originally, but it seems that the bars are being calculated from the incomplete subscribed tick stream.  While in theory this would be a nice thing, it represents incomplete data, and incorrect bars.
For example, I have adapted an example from the demo code (see below).
import sys

from qtpylib.algo import Algo

class CrossOver(Algo):

    def on_bar(self, instrument):
        numBars = 100
        bars = instrument.get_bars(lookback=numBars)
        print("on_bar called with %i bars for symbol %s"%(len(bars), instrument.symbol))

        if len(bars) < numBars:
            return

        t = (bars['high']-bars['low']).unique()
        if len(t)==1 and t[0]==0:
            print("No variation within each bar.")
            sys.exit()

        print("Hooray!  We finally have at least %i bars"%numBars)

        sys.exit()

if __name__ == "__main__":
    strategy = CrossOver(
        instruments = [("EUR", "CASH", "IDEALPRO", "USD", "")],
        resolution  = "1T",
        preload = "100T",
        ibport = 7497
    )

    strategy.run()

When I run this code, the result is:

Server Version: 76
TWS Time at connection:20190307 13:31:42 PST
2019-03-07 13:31:48,817 [WARNING] qtpylib.blotter: Backfilling historical data from IB...
....
.
on_bar called with 100 bars for symbol EURUSD_CASH
No variation within each bar.

During that period, the data being reported as having been computed from ticks shows all bars as flat, with the same high and low values.  During that same period, the TWS application running on the same computer showed the following plot:

As you can see there is a wide range in each 1 minute candle.  Trying to use the tick stream in TWS to compute candles represents an enormous loss of fidelity.  The problem is that there are many ticks/quotes/changes that are not reported to end user tools.  For active instruments, those changes just occur too fast.
Are there plans to fix this?

Interactive Brokers API has historical data for 1min/1day, etc, but they only provide API for real time streaming in either ticks or in 5-sec bars

You can use the historical bars keepUpToDate option to get bar updates as they occur, which is as realtime as it gets for those time periods Historical data docs.  In any case, the 5 second bars would be better to use for building larger time periods if that is needed.  The actual ticks will never be complete.

Thanks for pointing out this feature!

keepUpToDate, Whether a subscription is made to return updates of unfinished real time bars as they are available (True), or all data is returned on a one-time basis (False). Available starting with API v973.03+ and TWS v965+. If True, and endDateTime cannot be specified.

I found this note, worth keeping in mind:

The advantage of reqRealTimeBars is that it behaves more robust when the connection to the IB server farms is interrupted. After the connection is restored, the bars from during the network outage will be backfilled and the live bars will resume.
reqHistoricalData + keepUpToDate will, at the moment of writing, leave the whole API inoperable after a network interruption.

That is interesting.  I have experience with the API, and it does not behave that way.  The the connection to the server farm recovers, so does the data.  So, not sure where you found that, but my actual experience with the API does not match.  I get the interrupted message, and then it recovers.
Now, what does NOT work, is when I'm using TWS rather than the gateway, and TWS does its daily reboot, then the data does not come back.  It seems rational that the fresh start of TWS doesn't maintain the previous data requests.  I have it on my todo list... to detect an interruption in data and re-request data.

I'll test this out with the API too, see how it handles it


Fix ci test always failed

Codecov Report

Merging #255 into release-rc3 will increase coverage by 0.00%.
The diff coverage is n/a.

@@              Coverage Diff               @@
##             release-rc3     #255   +/-   ##
==============================================
  Coverage          25.01%   25.01%
  Complexity           330      330
==============================================
  Files                127      127
  Lines               4238     4237    -1
  Branches             311      310    -1
==============================================
  Hits                1060     1060
+ Misses              3099     3098    -1
  Partials              79       79

Impacted Files
Coverage Δ
Complexity Δ

...webank/wecross/network/rpc/netty/RPCBootstrap.java
0.00% <0.00%> (ø)
0.00% <0.00%> (ø%)


fix: cognito-idp: admin_create_user remove default attributes

Fix for #4069 - Creation of users should not include default attributes.
This fix removes the additional attributes.

Codecov Report

Merging #4070 (057847f) into master (eb6515c) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #4070      +/-   ##
==========================================
- Coverage   94.98%   94.98%   -0.01%
==========================================
  Files         465      465
  Lines       50488    50484       -4
==========================================
- Hits        47956    47952       -4
  Misses       2532     2532

Flag
Coverage Δ

servertests
55.85% <ø> (+<0.01%)
:arrow_up:

unittests
94.85% <ø> (-0.01%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

moto/cognitoidp/models.py
88.65% <ø> (-0.07%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update eb6515c...057847f. Read the comment docs.

@bblommers apologies - I even read CONTRIBUTING.md then clean forgot when I got round to submitting.
It looks like everything is working. Thanks for all your help and for your support for this awesome project.


Version 2.0.0

[x] Support Cowboy 2.0
[x] Improve error validation
[ ] Add FakeServer.run to improve standalone server support
[ ] Support global servers
[x] Move FakeServer.HTTP.Response to FakeServer.Response
[x] Add both {:ok, _} | {:error, _} and raise options to API
[x] Add %FakeServer.Route{} struct to manage routes and responses
[x] Split handlers into response types
[x] Remove FakeControllers

Coverage decreased (-2.6%) to 96.599% when pulling 4e71d4f20122bc28e48ad2781cbd12e557e1677a on 2.0.0 into 6610d73bdfbb02a2068687d4e40299d9b193b333 on master.

Hi, thanks for keeping up the good work, highly appreciated! I'm playing around with this branch, mainly because I need cowboy 2, but I can't seem to get it working. Is this broken?
defmodule MyFakeServerTest do
  @moduledoc false
  use ExUnit.Case, async: false

  import FakeServer
  alias FakeServer.HTTP.Response

  test_with_server "setting up a route works as expected" do
    route("/foo", do: Response.ok(~s<{"status":"ok"}>))
  end
end

When run with mix test this yields:
== Compilation error in file test/my_fake_server_test.exs ==
** (CompileError) test/my_fake_server_test.exs:9: FakeServer.Env.__struct__/0 is undefined, cannot expand struct FakeServer.Env
    (stdlib) lists.erl:1354: :lists.mapfoldl/3
    (stdlib) lists.erl:1355: :lists.mapfoldl/3
    (fake_server) expanding macro: FakeServer.route/2
    test/my_fake_server_test.exs:9: MyFakeServerTest."test setting up a route works as expected"/1
    (elixir) lib/code.ex:767: Code.require_file/2
    (elixir) lib/kernel/parallel_compiler.ex:209: anonymous fn/4 in Kernel.ParallelCompiler.spawn_workers/6

Hello @kevinbader, thanks for the feedback! I am taking the opportunity to improve the code and refactor some modules and the FakeServer.Env module was removed. I will fix this to ensure the code in this branch compiles while 2.0.0 version is not released. Just take care, because version 2.X will not be fully compatible with 1.X (For example, FakeControllers were removed).  Please, tell me if you have any trouble.

Hi @bernardolins, thanks a lot for the quick fix! Finally had the chance to try this and it works just fine :)
Here's my test code, for reference:
defmodule MyFakeServerTest do
  @moduledoc false
  use ExUnit.Case, async: false

  import FakeServer
  alias FakeServer.Response

  alias HTTPoison

  test_with_server "setting up a route works as expected" do
    %{port: port} = FakeServer.http_address() |> URI.parse()
    route("/foo", Response.ok!("Hello from port #{port}"))
    assert %HTTPoison.Response{status_code: 200} = HTTPoison.get!("http://localhost:#{port}/foo")
  end
end

btw, perhaps that's gonna be changed anyway, but just to document it here: the request object now keeps the parsed query map in query_string instead of query, e.g.:
%FakeServer.Request{
  body: nil,
  cookies: %{},
  headers: %{"host" => "localhost:4000", "user-agent" => "hackney/1.14.3"},
  method: "GET",
  path: "/my-endpoint",
  query: %{},
  query_string: %{"foo" => "bar"}
}

btw, perhaps that's gonna be changed anyway, but just to document it here: the request object now keeps the parsed query map in query_string instead of query, e.g.:
%FakeServer.Request{
  body: nil,
  cookies: %{},
  headers: %{"host" => "localhost:4000", "user-agent" => "hackney/1.14.3"},
  method: "GET",
  path: "/my-endpoint",
  query: %{},
  query_string: %{"foo" => "bar"}
}

Hum, nice catch. This is a mistake, the query_string field should be a string and not a map. The map should be available at the query field.


[Storage][DataMovement] Add ProviderId to resources and job plan file

This change adds the concept of ProviderId where each resource type now has a string id that represents which provider, they need for resuming. This information is stored in the job plan file for source and destination and used when choosing the provider to use for resume.

API change check
APIView has identified API level changes in this PR and created following API reviews.
Azure.Storage.DataMovement

/azp run net- storage - ci


OSSM-2082 CNI installer now creates the net.d directory if necessary

/test unit
Argh, that flaky StatusManager test.

/test all

/test istio-gencheck-2-3
/test istio-lint-2-3
/test istio-unit-2-3

This isn't needed in upstream, since they always install the plugin into the cluster's main net.d dir, which always exists.

Well, the MountedCNINetDir parameter is present on upstream and is configurable so that vendors like us can use it, and this PR makes it more robust, right? So, IMO we should do that as this will also benefit us in the future rebases. Upstream first policy :)

Earlier versions did create the directory, so this was actually removed in upstream.

/test lint

/test integration-pilot
/test integration-security
/test integration-servicemesh


nsc-events-nextjs_8_428_event-background-images

Resolves #428
This PR puts the event cover photo as the background image and blurs it/makes it transparent.

Looks good to me! This is a really nice feature.


deprecate no-reassign

Looks like ESLint proper has updated no-redeclare to include modules as of 1.0.0-rc1 (see eslint/eslint#2948).
Assuming no-reassign is now redundant, should remove it.

Upon further inspection, it's not clear whether all of no-reassign is duplicated by no-redeclare. The assignment bits might need to stay.
Alternative: rename/rebirth as no-assignment?


Webpage is not loading

I have little coding experience, but I followed all guidelines to launch the demo app from examples/react folder. I ran npm install, npm build and a few other commands to resolve errors for webpack 5. However, finally when I ran npm run start, the vosk-browser fails to launch, even though no errors are detected. The page is empty.
C:\Users\CNata\Downloads\vosk-browser-master\examples\react>npm run start

><EMAIL_ADDRESS>start
> react-scripts start

(node:17120) [DEP_WEBPACK_DEV_SERVER_ON_AFTER_SETUP_MIDDLEWARE] DeprecationWarning: 'onAfterSetupMiddleware' option is deprecated. Please use the 'setupMiddlewares' option.
(Use `node --trace-deprecation ...` to show where the warning was created)
(node:17120) [DEP_WEBPACK_DEV_SERVER_ON_BEFORE_SETUP_MIDDLEWARE] DeprecationWarning: 'onBeforeSetupMiddleware' option is deprecated. Please use the 'setupMiddlewares' option.
Starting the development server...
Compiled successfully!

You can now view vosk-browser-react-demo in the browser.

  Local:            http://localhost:3000/vosk-browser
  On Your Network:  http://<IP_ADDRESS>:3000/vosk-browser

Note that the development build is not optimized.
To create a production build, use npm run build.

webpack compiled successfully
Files successfully emitted, waiting for typecheck results...
Issues checking in progress...
No issues found.

Hello @ccoreilly ,
So I've started it all again from scratch, and when I run npm install, I get the warning that many of the packages are now deprecated. Here's the message:
C:\Users\CNata\vosk-browser-master\examples\react>npm install
npm WARN deprecated<EMAIL_ADDRESS>See https://github.com/lydell/source-map-url#deprecated
npm WARN deprecated<EMAIL_ADDRESS>flatten is deprecated in favor of utility frameworks such as lodash.
npm WARN deprecated<EMAIL_ADDRESS>request-promise-native has been deprecated because it extends the now deprecated request package, see https://github.com/request/request/issues/3142
npm WARN deprecated<EMAIL_ADDRESS>This version has been deprecated and is no longer supported or maintained
npm WARN deprecated<EMAIL_ADDRESS>This version has been deprecated and is no longer supported or maintained
npm WARN deprecated<EMAIL_ADDRESS>Please see https://github.com/lydell/urix#deprecated
npm WARN deprecated<EMAIL_ADDRESS>this library is no longer supported
npm WARN deprecated<EMAIL_ADDRESS>See https://github.com/lydell/source-map-resolve#deprecated
npm WARN deprecated<EMAIL_ADDRESS>Chokidar 2 does not receive security updates since 2019. Upgrade to chokidar 3 with 15x fewer dependencies
npm WARN deprecated<EMAIL_ADDRESS>Chokidar 2 does not receive security updates since 2019. Upgrade to chokidar 3 with 15x fewer dependencies
npm WARN deprecated<EMAIL_ADDRESS>https://github.com/lydell/resolve-url#deprecated
npm WARN deprecated<EMAIL_ADDRESS>The querystring API is considered Legacy. new code should use the URLSearchParams API instead.
npm WARN deprecated<EMAIL_ADDRESS>some dependency vulnerabilities fixed, support for node < 10 dropped, and newer ECMAScript syntax/features added
npm WARN deprecated<EMAIL_ADDRESS>Moved to 'npm install @sideway/address'
npm WARN deprecated<EMAIL_ADDRESS>This package has been deprecated and is no longer maintained. Please use @rollup/plugin-babel.
npm WARN deprecated<EMAIL_ADDRESS>The querystring API is considered Legacy. new code should use the URLSearchParams API instead.
npm WARN deprecated<EMAIL_ADDRESS>babel-eslint is now @babel/eslint-parser. This package will no longer receive updates.
npm WARN deprecated<EMAIL_ADDRESS>Please upgrade  to version 7 or higher.  Older versions may use Math.random() in certain circumstances, which is known to be problematic.  See https://v8.dev/blog/math-random for details.
npm WARN deprecated<EMAIL_ADDRESS>Please upgrade  to version 7 or higher.  Older versions may use Math.random() in certain circumstances, which is known to be problematic.  See https://v8.dev/blog/math-random for details.
npm WARN deprecated<EMAIL_ADDRESS>Please upgrade  to version 7 or higher.  Older versions may use Math.random() in certain circumstances, which is known to be problematic.  See https://v8.dev/blog/math-random for details.
npm WARN deprecated<EMAIL_ADDRESS>request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN deprecated<EMAIL_ADDRESS>This version has been deprecated and is no longer supported or maintained
npm WARN deprecated<EMAIL_ADDRESS>Switch to 'npm install joi'
npm WARN deprecated<EMAIL_ADDRESS>This SVGO version is no longer supported. Upgrade to v2.x.x.
npm WARN deprecated<EMAIL_ADDRESS><EMAIL_ADDRESS>is no longer maintained and not recommended for usage due to the number of issues. Because of the V8 engine whims, feature detection in old core-js versions could cause a slowdown up to 100x even if nothing is polyfilled. Please, upgrade your dependencies to the actual version of core-js.
[##################] | reify:@ant-design/icons: timing reifyNode:node_modules/@ant-de[##################] | reify:@ant-design/icons: timing reifyNode:node_modules/@an[##################] | reify:@ant-design/icons: timing reifyNode:node_modules/@a[##################] | reify:@ant-design/icons: timing reifyNode:node_[##################] | reify:@ant-design/icons: timing reifyNode:node_modu[##################] | reify:@ant-design/icons: timing reifyNode:node_mo[##################] | reify:@ant-design/icons: timing reifyNode:node_[######[######[######[######[######[##################] | reify:@ant-design/icons: timing reifyNode:node_mod[##################] | reify:@ant-design/ico[##################] | reify:@ant-design/icons: timing reifyNode:n[##################] | reify:@ant-design/icons: timing reifyNode[##################] | reify:@ant-desi[###########
added 2033 packages, and audited 2035 packages in 2m

what should I do? I would be very grateful for help or advice. Thank you.

Hi @Nata0801 !
being it just an example, I haven't really kept the dependencies up to date. I am surprised that it does not work even if there are warnings but I will not be able to try it out in about at least a week.
It should be safe to upgrade the dependencies to their latest versions. Maybe you can try that and if you succeed with it contribute the changes in a PR? :)

Hi @ccoreilly !
So, I have checked some dependencies with the following command npm la <package-name> to see the dependency depth and if the packages are crucial for the app or the warning can be discarded. After some analysis I decided to move on. It all worked out at the end, I managed to launch vosk-browser and webpage loaded all right.
However, I had one question for you left. Earlier I was testing AWS Transcribe and it seems to work faster. My colleagues advised to run Vosk models on GPU. So my question is if it is possible to change where the models run - on CPU/GPU. I would greatly appreciate your advice.

Sure, you should check vosk, the engine that powers this library. You can run it on GPU using node in the server as well.
Running vosk-browser using the GPU is not possible and I guess it wouldn't be easy to implement.

Thank you very much for your help!


NVIDIA GeForce GTX 1650

Hello,
is my NVIDIA GeForce GTX 1650 (~4GB) good for speech generation?
Can I convert large text to speech at a time?
Thank you.

should be fine if you offload the models between steps and maybe use the small models, see here: https://github.com/suno-ai/bark/blob/main/notebooks/memory_profiling_bark.ipynb


result upload validation

Current validation logic of result zipfile upload:

parse the primary key YY_MM_NN from zip filename assuming form YY_MM_NN_....zip

return error message if corresponding sample not found (this happened for your first zip upload)

store this zipfile as the zip results for this sample

a "zip" link is added to the results table allowing the user to download this file

try to extract the file YY_MM_NN_samplename.fasta from the zipfile

here samplename is the sample name the user entered when submitting the sample
if this file is found a "fasta" link will be added to the results table to download this file

do the same for YY_MM_NN_samplename.gbk
send user an email

attach the fasta and gbk files if present
(for your second zip upload the filenames inside the zipfile didn't match so these files didn't get extracted)

Is this what you would like? Two potentially more consistent options could be:

more strict validation

also return an error message if fasta/gbk files with these expected names are not found inside zip file

less strict validation

ignore the names of the files in zipfile and just assume they are correct and extract them / send them to the user

(copied from https://github.com/ssciwr/circuit_seq/issues/43#issuecomment-1347932932_)

looks like great progress since I last checked in!


Implementation NNCF support for face recognition models

Added configs for MobileNet and Landnet sparsification and quantization experiments (more about NNCF in https://github.com/opencv/openvino_training_extensions/tree/develop/pytorch_toolkit/nncf).
The compressed models results are shown in the table

Please rebase your develop branch to original develop
https://gist.github.com/ravibhure/a7e0918ff4937c9ea1c456698dcd58aa

@GalyaZalesskaya Which version of pytorch did you used?
Face_recognition have required 0.4.1, but nncf 1.0 or higher.

@GalyaZalesskaya
You forget add config files with new names

I used torch 1.2 (for CUDA 10.0), but I noticed now that after installation of FR and NNCF requirements there is still torch 0.4.1. Should I add the line into init_venv.sh by force
pip install torch==1.2?
But CUDA and Torch versions should be compatible.
Sorry for delaying. I found some issue which appeared after rebasing and I'm still trying to solve it.

@GalyaZalesskaya

Sorry for delaying. After you comment I found an issue which appeared after rebasing and I'm still trying to solve it.

No problem

I used torch 1.2 (for CUDA 10.0), but I noticed now that after installation of FR and NNCF requirements there is still torch 0.4.1. Should I add the line into init_venv.sh by force
pip install torch==1.2?

No, I'll try to check it by myself and merge pull request on this week.


don't report in abstract_call simulated in return_type_tfunc

Codecov Report

Merging #18 into master will increase coverage by 0.86%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #18      +/-   ##
==========================================
+ Coverage   68.09%   68.95%   +0.86%
==========================================
  Files          10       10
  Lines         608      612       +4
==========================================
+ Hits          414      422       +8
+ Misses        194      190       -4

Flag
Coverage Δ

#unittests
68.95% <100.00%> (+0.86%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

src/TypeProfiler.jl
100.00% <ø> (ø)

src/tfuncs.jl
92.85% <100.00%> (+2.85%)
:arrow_up:

src/reports.jl
87.76% <0.00%> (+0.71%)
:arrow_up:

src/abstractinterpretation.jl
95.94% <0.00%> (+4.05%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c510219...929b31d. Read the comment docs.


Model generator

We should add a model generator so that people can easily populate components with data from a database or API via GraphQL.
We should basically aim to abstract away GraphQL so that they user doesn't have to think too much about how the data gets into their components.
We might also want to think about explicit database support here.

Database support libraries:

https://github.com/typeorm/typeorm


Creating Delayed Queue

I wonder how to create delayed message queue. Please take a look on my test case and the result
it('should create send messagee', function (done) {
    rsmq.deleteQueue({'qname': "myqueue"}, function (res) {
      rsmq.createQueue({qname: "myqueue"}, function (err, resp) {
        if (resp === 1 || err.name === 'queueExists') {
          console.log("queue created");
          rsmq.sendMessage({qname: "myqueue", message: "Hello world", "delay": 1}, function (err, resp) {
            if (resp) {
              console.log("message sent");
              console.log("Message sent. ID:" + resp);
              done();
            }
          });
        }
      });
    });
  });

  it('should receive msg', function (done) {
    rsmq.receiveMessage({qname: "myqueue"}, function (err, resp) {
      if (resp.id) {
        console.log("Message received.")
        console.log(resp);
      }
      else {
        console.log(err);
        console.log("No messages for me...");
      }
    });
  });

Result:
queue created
message sent
Message sent. ID:e2mp1o4p90fNowqfWpNbxNdAj2huPIKN
.null
No messages for me...
I didn't put done inside receiveMessage function and wait until timeout but the receiveMessage never triggered again.

You are creating a queue with the default settings (vt: 30, delay: 0, maxsize: 65536).
Then your are sending a message "Hello world" with delay=1. The delay=1 means this particular message will only appear after 1 second to recipients. As you are trying to receive the message right afterwards it won't be received. Which is correct.

Send a message without the "delay" parameter to receive it immediately.
Try a receiveMessage after 1+ seconds to receive the message.

If you want to create a delayed queue where all messages are delayed by n seconds you should use the delay parameter with the createQueue method.
Your queue worker(s) typically poll the queue every second and will receive all messages after the delay has passed


Update Version of Chai

With the inclusion of dirty-chai to enable passing the linters (changed from calls like: expect(true).to.be.true to expect(true).to.be.true()) we had to revert to an earlier version of Chai due to a peer-dependency issue.
A PR has been created to address this issue with the dirty-chai plugin.

This will be handled by #10


Add Beta <IP_ADDRESS>3 support

Custom launchers such as Oxide or Remux don't seem to work however:
Dec 04 17:13:51 reMarkable systemd[1]: Started reMarkable 2 Framebuffer Server.
Dec 04 17:13:51 reMarkable xochitl[194]: STARTING RM2FB
Dec 04 17:13:51 reMarkable xochitl[194]: getInstance() at address: 0x3a9f80
Dec 04 17:13:51 reMarkable xochitl[194]: REPLACING THE IMAGE with shared memory
Dec 04 17:13:55 reMarkable xochitl[194]: Reading waveforms from /usr/share/remarkable/320_R382_AF5F11_ED103TC2M1_VB3300-KCD_TC.wbf
Dec 04 17:13:55 reMarkable xochitl[194]: Running INIT (135 phases)
Dec 04 17:13:55 reMarkable xochitl[194]: 1404 1872 16
Dec 04 17:16:59 reMarkable xochitl[194]: Pan failed: Invalid argument

what do you mean launchers don't work? with these addresses, the launchers aren't working?

xochitl works, rm2fb launches, oxide displays startup logo but that's it.

xochitl works, rm2fb launches, oxide displays startup logo but that's it.

Sounds like something is missing. Third party applications should not require any changes to continue to work. It could be that one of the addresses is slightly off, or something was changed under the covers that needs to be accounted for.

I think the problem might be the offsets.  I have different ones for wait and getInstance.
!20211202111519
version str <IP_ADDRESS>3
update addr 0x3a9ccc
updateType str QRect
create addr 0x3ac124
shutdown addr 0x3ac0c8
wait addr 0x3ab604
getInstance addr 0x3a041c

@rotech These do look better, thanks!  However, I still get:
$ journalctl -u rm2fb
Dec 05 10:39:37 reMarkable systemd[1]: Started reMarkable 2 Framebuffer Server.
Dec 05 10:39:37 reMarkable xochitl[197]: STARTING RM2FB
Dec 05 10:39:37 reMarkable xochitl[197]: getInstance() at address: 0x3a041c
Dec 05 10:39:37 reMarkable xochitl[197]: REPLACING THE IMAGE with shared memory
Dec 05 10:39:42 reMarkable xochitl[197]: Reading waveforms from /usr/share/remarkable/320_R382_AF5F11_ED103TC2M1_VB330
0-KCD_TC.wbf
Dec 05 10:39:42 reMarkable xochitl[197]: Running INIT (159 phases)
Dec 05 10:39:42 reMarkable xochitl[197]: 1404 1872 16
Dec 05 10:40:23 reMarkable xochitl[197]: Pan failed: Invalid argument
Dec 05 10:40:23 reMarkable xochitl[197]: Pan failed: Invalid argument
Dec 05 10:40:23 reMarkable xochitl[197]: Pan failed: Invalid argument
Dec 05 10:40:23 reMarkable xochitl[197]: Pan failed: Invalid argument
Dec 05 10:40:23 reMarkable xochitl[197]: Pan failed: Invalid argument
Dec 05 10:40:23 reMarkable xochitl[197]: Pan failed: Invalid argument
Dec 05 10:40:23 reMarkable xochitl[197]: Pan failed: Invalid argument
Dec 05 10:40:23 reMarkable xochitl[197]: Pan failed: Invalid argument
Dec 05 10:40:23 reMarkable xochitl[197]: Pan failed: Invalid argument
Dec 05 10:40:23 reMarkable xochitl[197]: Pan failed: Invalid argument
Dec 05 10:40:23 reMarkable xochitl[197]: Pan failed: Invalid argument
Dec 05 10:40:25 reMarkable xochitl[197]: Pan failed: Invalid argument
Dec 05 10:40:25 reMarkable xochitl[197]: Pan failed: Invalid argument

And this for tarnish.service: https://pastebin.com/903U7sG5, notably many instances of
ERROR: ld.so: object '/opt/lib/librm2fb_client.so.1' from LD_PRELOAD cannot be preloaded (internal error): ignored.

This is my config now:
$ cat /opt/etc/rm2fb.conf
!20211102143141
version str <IP_ADDRESS>9
update addr 0x398acc
updateType str QRect
create addr 0x39aee0
shutdown addr 0x39ae84
wait addr 0x39a404
getInstance addr 0x38f3b4

!20211202111519
version str <IP_ADDRESS>3
update addr 0x3a9ccc
updateType str QRect
create addr 0x3ac124
shutdown addr 0x3ac0c8
wait addr 0x3ab604
getInstance addr 0x3a041c

The LD_PRELOAD errors from the tarnish service are normal and can be ignored as they are actually only warnings.

Testing on <IP_ADDRESS>3 with the offsets proposed in this PR works fine. I can’t reproduce the Pan failed: Invalid argument errors on my side @ljrk0 (tested running Xochitl and Oxide and the calculator app from Oxide).

thanks for the updates offsets, @ljrk0  and @rotech


[docs] Unstyled menu can't be closed with the designated Button

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Current behavior 😯
The event onClose is called even when clicking the button that's designated to open/close the menu, this caused the close & open event to be called after eachother, making it impossible to close the menu when clicking the button.
Expected behavior 🤔
Clicking away from the menu should fire the close event, while clicking on the button should fire the click event from the button.
Steps to reproduce 🕹
Visit the official docs, clicking the basic usage button. You will see it's impossible to close the menu when clicking the button again after it is opened.
Context 🔦
I'm trying to implement the unstyled menu button from MUI. Not being able to close this when clicking the button seems like a bug as the basic menu from Material UI does support this behaviour.
Your environment 🌎
No response

Agree, the demo should be updated. cc @michaldudak can you check this out?

Hi, thanks for the workaround. Shouldn't that be the default behaviour? As I understand, that is just a hack the developer can apply while using it. I mean, opening a dropdown by clicking on the button and closing it by clicking again on the button is the expected behaviour of such a controll element.

When we have the MenuButton component, this logic will be built in. For now, we have to fall back to this fix.

One simpler fix is to use onMouseDown instead of onClick on the toggle button.


LUN-390: Remove plural article

This pull request belongs to an issue on our bugtracker.
You can find it there by looking for an issue with the key which is mentioned in the title of this pull request.
It starts with the keyword LUN.

@SteffiStuffel @charludo please review from scratch :)


Build number fallback when product-info.json is missing

Fixes #881
When configuring prepareSandbox we add some attributes to the jar
manifest, one of which being "Build-SDK" - when using localPath, the value of the attribute
is constructed from the contents of product-info.json (a metadata file located in the target IDE directory).
However, when the target IDE is Android Studio, this file does not exist (in recent versions at least), and the value thereby resolves to null; this causes the following error:
Could not determine the dependencies of task ':prepareSandbox'.

Failed to query the value of task ':prepareSandbox' property 'pluginJar'.
The value of a manifest attribute must not be null (Key=Build-SDK).

This commit makes it so that we fall back on the build number (also read
from the IDE directory) if product-info.json is missing.

Thanks once again!


add language selector

[x] Add language selector to header
[x] Link to correct page slug Redirect to correct page

Closes #119

I think these changes break page revalidation now that the fix branch has been merged, but it was broken before that as well so 🤷. We'll have to have a look at the revalidation logic and perhaps write some tests for it.


cannot read propeety getcell of undefined while writing in to the workbook

var workbook = new Excel.Workbook();
workbook.xlsx.readFile(filename)
.then(function() {
// edit worksheet
var worksheet = workbook.getWorksheet("My Sheet");
worksheet.getCell("A1") = new Date();
})
.then(function() {
return workbook.xlsx.writeFile(filename)
})
.then(function() {
console.log("Done");
});

Sorry it's taken me so long to reply, I've been v.focussed on other work lately.
looking at your code I can see a problem with the line
worksheet.getCell("A1") = new Date();

This line is trying to assign a value to the return result of a function call (not possible). You probably meant:
worksheet.getCell("A1").value = new Date();


HHH-13444 Remove ignored EntityMode field from CollectionKey

https://hibernate.atlassian.net/browse/HHH-13444

It look good to me, thanks @Sanne


NoSQL DB integration

Hi
Is there a way to integrate with a NoSql DB (like MongoDB)?

Sorry, but specifically for what?

It is a responsibility of testing framework (xUnit, NUnit). For example NUnit has TestCaseSource attribute for custom data sources. So for test you can implement custom method that will read the set of test parameters from any source you like (config file, DB, etc). And you need to specify this method as a test case source using an attribute.


fix: use absolute path for cln backup-cli

fix: #3858
running:
./config.scripts/cl-plugin.backup.sh on

works now and fixes CLN.
Will run a test with a new install.

Looks good on first test :) CL is running again- will test with a local sd card fatpack build.

New install with the change worked,  ready to merge.


Notifications: use fetched urls instead of resolving

Ticket
#218 If comments/notifications have thumbnail URLs, don't resolve, use them. Resolve rest
Approach
Augment FileThumbnail, ChannelThumbnail and UriIndicator to accept direct props for the necessary data ... when used in this mode, we skip resolving uri for the full claim info.
If the data passed in is null (for the case of old notifications), the default resolving behavior kicks in.
Notes
I'm skipping "Comments" for now because <CommentReaction> requires more info or needed to do a bunch of parseUri from the notification details.  device.target also isn't consistently in permanent form (sometimes canonical), so harder to determine if it matches the active channel (to determine Creator Like visibility and stuff).

@tzarebczan, I gave updating CommentReaction another shot https://github.com/lbryio/lbry-desktop/commit/f9255c7e3c99ccc7cf9563b2d94f7db6c773009f ... the proof of concept works (still need to touch up some bugs), but it's somewhat ugly code.
If the notification can provide the "commented content's channel ID" and "commented content's channel thumbnail", then we can skip the elaborate code.
Alternatively, we could just not allow Creator Like from the Notifications Page, but I think that's not ideal.


Using the bot (or the beaglebone in general) when hardware is disconnected.

related to issue  #137 , where the ctrl server would not start when the color sensor was disconnected, we have the same problem with most of the hardware.
We need to figure out a way to make the script handle errors like that more gracefully, where a warning is passed when something like that happens, especially for when we do things like working on a beaglebone without the rest of the bot.

This has been solved for a while actually,  the config file contains a new data-structure for each piece of hardware to determine if it's running real hardware or not.


🐛UI | PeoplePage | Carousel swipes trigger GC and cause delays

In Debug I can see that GC is triggered when the user swipes the carousel; that causes delays, and the carousel feels sluggish. Works ok in Release on a relatively old phone - Samsung Note 8.
It's required to investigate if we can avoid GC firing up on every swipe.

Not relevant anymore. There is no SSW People page in v2024.


Approver role to resubmit

Think about adding a approver role button to allow a rejected txn to be resubmitted without any editing.
This can happen if a PPM which was invalid gets fixed in AE so it is now valid.

Closed with #431