RFC: Minimum Supported Rust Version

This RFC adds an ability to specify Minimum Supported Rust Version (MSRV) in Cargo.toml using  rust field:
[package]
name = "foo"
version = "0.1.0"
edition = "2018"
rust = "1.35"

Rendered
Tracking issue
Internals discussion
Edit: FCP proposal https://github.com/rust-lang/rfcs/pull/2495#issuecomment-532853518

pull request

I think i like the key name be rustc better (or it will become problematic for alternative compilers like mrustc or something like that.)
I actually think the channels should not be mixed in. Since it's using semver, cargo init can just write "1" to represent all available rustc versions, right?
I also think that if a crate is nightly only. It can mark itself in an permanently unstable attribute, maybe something like nightly-rustc = ">=20180707" . And only nightly cargo can recognize and publish those crates, which is ok i think.

Personally I don't have a strong preference regarding the name, so it could be changed on implementation. But if we consider other compilers, then in my opinion rust fields makes more sense, which can be interpreted as aversion number of "rust specification", which currently provided in the form of the reference implementation. We could extend rust field to support experimental features of other compilers, e.g. in this form rust = "mrustc: ...".
Channels are mostly for convenience and providing sensible default option. Using "1.0" as a default value will result in too relaxed constraints on crate versions, thus making the feature significantly less useful in a long run. While the proposed channel handling will result in a too conservative constraint, at least we'll know for certain that crate can be built with a specified version.
As for nightly-rustc I don't see much benefit in introducing additional field, except making rust field pure-semver, which has arguable merit. Stable/nightly requirements are mutually exclusive, so there shouldn't be any problems in keeping them in one field. Also it will simplify explanation of this feature.

@aturon
Can this feature be implemented and introduced as part of the Rust 2018 release? (even in the form of "dumb fields") The proposed rust field is required, so it will be nice to make it optional only for 2015 edition.

It might be nice if there were an env|cli|profile option to have cargo emit an error or warning if the used toolchain is newer than specified for cargo check and test. So you have the chance of catching it early if you want.

This should also help with crates.io have a badge for it too :hooray:

Shall it support usual version syntax syntax like =1.35, ^1.35, 1.35.0?

Shall it support usual version syntax syntax like =1.35, ^1.35, 1.35.0?
@vi

Even if it was supported, I don't think it would something that would be useful, as it is only marking the absolute minimum version of Rust needed. The support for that syntax makes more sense for crates.

If you accept the fact that rust has in the past and will in the future make non-backward compatible changes, then a maximum supported version (or in other words a complete dependency range with minimum and maximum) is useful for crate lib authors.   See also rust-lang/rust#52320 for implications regarding how this is a two way street of effects.

@dekellum Take a look at the inline review comments about nightly versioning above. Specifying a maximum supported version in the Cargo.toml of a crate generally isn't helpful: you typically don't know when the next relevant breaking change will happen. And once you've published a crate, if there is later a breaking change, you can't go back and change it to say what the maximum supported version is.

@fintelia, I respectively still think a maximum supported version is useful and applicable.  I/you can publish a patch release (e.g. 1.2.1 for a 1.2.0 crate) once you determine that a stable or nighly rust has a breaking change that effects the lib.

I/you can publish a patch release (e.g. 1.2.1 for a 1.2.0 crate) with a new maximum version bound

The problem is that on "broken" newer stable Rust cargo will select 1.2.0 crate, because your 1.2.1 will be excluded from versions resolution due to the maximum bound, thus in your example version 1.2.1 becomes useless.
Either way maximum bounds can be introduced in a separate RFC, after baseline version of this proposal will be implemented.

Thanks @newpavlov.  I agree that maximum bound could be introduced later/incrementally.
We know that cargo could be made a lot smarter in version resolution. At the very least my 1.2.1 offers cargo readable documentation on late found maximum rust bound, which must be better than no information, even if we are not yet certain how to use it!

I propose updating this RFC to just be about minimum versions and not discuss maximums, ranges, etc.
The possible values for the rust field would thus become: stable, nightly, X.Y, X.Y.Z, and nightly-YYYY-MM-DD

@newpavlov, while I missed the inline debate on maximum rust bounds, beyond my reply above, I think a maximum bounds has practical utility because we are often developing with the nightly while targeting stable for production. So in many real cases, it will be possible to know with adequate certainty that a lib (at time of publish) will not be compatible with a future stable.  A specification like:
rust = ">1.30, <=1.40"

...is otherwise compatible with your current RFC syntax and I think you should add it in this RFC.  Yes, this kind of "exotic" version bounds is currently out favor, but I think that will prove naïve eventually and cargo will need to support and resolve these bounds!  Thanks for this RFC!

So in many real cases, it will be possible to know with adequate certainty that a lib (at time of publish) will not be compatible with a future stable.

Ehhm... Rust stability promise does not work like that. If you know that code will break in some future stable version (because you've tested it on beta or stable), then you need to report this issue, it will get "regression-from-stable-to-*" an hopefully it'll get fixed ASAP. The common need for maximum stable bound will be a very grave sign for Rust.

I accept that what you say is the goal and philosophy of the rust maintainers, but I think I'm being more pragmatic! For an example, at some point in the future dyn Trait will become required syntax in a stable release.  Lets say I have a 1.1.3 version of my lib that is dyn Trait converted, but I have new work and a 1.2.0 release that isn't yet 100% dyn Trait converted. I want 1.2.0 or (if necessary) 1.2.1 to express rust <= 1.m or m is the stable that makes dyn Trait required.

at some point in the future dyn Trait will become required syntax in a stable release

In my understanding dyn Trait will never become required in 2015 edition, which must be supported by all future Rust 1.x compilers. This is the whole point of editions design.

OK, well then may same point applies to the 2018 editions, doens't it?

Or how can I specify, with this RFC, a maximum edition?

Editions are specified using edition field and on Rust 1.100 you should be able to use edition="2015" (or simlpy omit this field, which will mean the same) without any problems. Edition and MSRV features are mostly orthogonal to each other.

I'm behind on the "edition" design, obviously, so any links are appreated, but If I say edition="2015" in my lib crate release, does that mean it can only be used in an edition="2015" project as a dependency?

IIUC correctly 2018 and later edition crates should be able to use 2015 crates mostly without issues.
See #2052 for additional info regarding editions.

Well, that is super hand wavy, isn't it?  Logically my argument then still holds: this RFC should include either a maximum edition bounds and/or a maximum rust version bounds.

It's not hand-wavy at all. Literally the primary motivation of the "editions" proposal is that crates on different editions can interoperate, thereby removing the biggest problem with making superficial breaking changes to syntax and eliminating the need to ever have a "Rust 2.0". There's even a specific commitment to making macros from one edition expand correctly in crates from some other edition.
The point for this thread is that there's simply no motivation for a minimum edition, maximum edition or range of editions. There is only the current edition, and no need for anything else, because every crate can be on a different edition and that won't cause any problems.
Whereas with minimum Rust versions, if one of your dependencies requires a newer Rust compiler, that actually does break your build (unless we do something really crazy like potentially use different versions of rustc for every crate in your dependency tree... which I assume nobody wants), therefore it makes sense to talk about minimum versions and possibly ranges of versions. I'm still neutral on most of the details.

Let me summarize what I think is a logic fallacy (either mine or yours, lets find out), by way of a scenario:

A rust 2019 edition is defined that including making dyn Trait required syntax (or even a warning, where my project's deny(warnings) affectively makes its required.)

Next say in some lib crate called libfoo that I maintain, I'm still haven't converted to dyn Trait at least in my 1.3.x release series, lets say for reasons beyond just pure laziness on my part. How do I indicate that I can not be compiled up to the standards of rust 2019 edition? Is this enough, in libfoo's Cargo.toml?

edition="2018"

(a) If that is enough, does it mean that a 2019 edition downstream project will not use that version of libfoo (e.g. cargo won't resolve this version)?
(b) Or are you saying that even in a 2019 edition, downstream project, that libfoo will be compiled with a flag that continues to use edition="2018", and thus dyn Trait won't be required?
If its the former (a), then I what I was missing in this RFC that there is an implied maximum edition bounds.  That should be spelled out better at least.
If its the latter (b), than I'm a bit skeptical that this is going to work seamlessly in practice and more hopeful and inclined to see a maximum rust version bounds supported by this RFC.
Thanks for your time!

There's a very tiny section of the (admittedly huge) RFC you might want to look at: https://github.com/rust-lang/rfcs/blob/master/text/2052-epochs.md#the-full-mechanics My answer here are basically restating what it says.

Next say in some lib crate called libfoo that I maintain, I still haven't converted to dyn Trait at least in my 1.3.x release series, lets say for reasons beyond just pure laziness on my part. How do I indicate that I can not be compiled up to the standards of rust 2019 edition? Is this enough, in libfoo's Cargo.toml?

If you don't specify an edition in your Cargo.toml, then your edition is 2015. So all crates have a "known" edition, no matter what.
So when Rust 2019 comes into existence your crate is already clearly marked as not being a Rust 2019 crate, either because you never gave it an edition or because you gave it some other edition.

(a) If that is enough, does it mean that a 2019 edition downstream project will not use that version of libfoo (e.g. cargo won't resolve this version if there is some better choice)?

(b) Or are you saying that even in a 2019 edition, downstream project, that libfoo will be compiled with a flag that continues to use edition="2018", and thus dyn Trait won't be required?

Pretty much (b). There is an --epoch flag (or maybe it's --edition by now, whatever), which also defaults to 2015. So if dyn Trait becomes mandatory in edition 2019, that mandatory-ness will only apply to whichever crates are compiled with --edition 2019.
I assume your skepticism comes from lack of familiarity with the rest of the RFC. To oversimplify a bit, editions are only allowed to be used for changes where this obviously can work seamlessly, which mostly means surface syntax changes. This section might help: https://github.com/rust-lang/rfcs/blob/master/text/2052-epochs.md#negative-examples-what-epoch-opt-ins-cant-do

I've now read #2052 in full and I think understood most of it, thanks!  Yes, I remain skeptical given the complexity of the negative/positive examples, that this is going to avoid breakage in all or even most cases in combination with rapidly changing crate libs. I suspect this will work as intended for dyn Trait though, so my example isn't so well serving of my cause in retrospect. :)
I still think not including a maximum rustc version here in this RFC is a real missed opportunity. As a lib maintainer in several other languages for several years I have been able to fix major dependency breakage events by some combination of version constraints (incl. compiler/runtime max version), repo yanking, and making new releases that fix the problem for new compiler/runtime combinations. Without such a feature I won't be able to do that so easily for rust.
If on the other hand you have the wisdom to include an (opt in) maximum version bound in this RFC, then I would be willing to bet good money that the features gets used for the great betterment of the ecosystem, may times, shortly after the 2nd edition is defined and published!
But in any case, thank you for your patience with hearing me out and for your work in general.

As a lib maintainer in several other languages for several years I have been able to fix major dependency breakage events by some combination of version constraints (incl. compiler/runtime max version), repo yanking, and making new releases that fix the problem for new compiler/runtime combinations. Without such a feature I won't be able to do that so easily for rust.

Could you describe some of these use cases in detail for us?
I don't think anyone has claimed that supporting a max version would be actively harmful, only that we have yet to be presented with a convincing reason for supporting that feature, so at the moment it just seems unnecessary to people like me that can't imagine how one ends up in a situation like you describe without relying on a bunch of unstable stuff (and I assume this entire discussion is ruling out crates that somehow rely on unstable things on the stable channel), or being in an ecosystem that offers much weaker stability guarantees than Rust.

I mostly view maximum version as a part of pinned version (maximum == minimum).
If some arcane binary hacks (e.g. relianse on Rust ABI and it's symbol mangling) are going in the crate, it may work with only one particular version of rust (maybe nightly) on one particular platform. This makes it reasonable to specify =1.28.0 or =nigthly-2018-06-28.

Use case for a maximum rust version bound
Lets say with a hypothetical myproj lib crate, last released as version 1.2.0, I find a breakage on CI when a new beta rust 1.36.0 is released. The breakage is some grey area between my project and rustc that is going to take some time to sort out. I file a github issue for the failure but its currently unclear if myproj was doing something unsafe or unsupported, or if its an actual rust regression.
Step 1: To try and fix this, I first release a 1.2.1 with Cargo.toml having:
version="1.2.1"
rust=">=1.26, <1.36"

...and then yank build '1.2.0' from crates.io.
In this state, for the time being, consumers using nightly (1.37) or beta will resolve to a prior myproj 1.1.4, which will either exhibit the same problem or not, depending on the details of the issue involved. Both those scenarios are interesting, but won't be covered here.
Step 2, later on, I find some sketchy, experimental, workaround for the issue with 1.36, so I CI test a new branch, and release a '1.3.0' with:
version="1.3.0"
rust="1.36"

The experimental workaround actually has a dependency on some new feature of rust 1.36. That's OK because, with users of the last several stable rust releases (including possible future 'LTS' releases) it is not desirable to these experimental changes. They will be able to continue to use the myproj 1.2 branch unaffected, and I carved out set of versions to support those users.
With this recipe, I'm effectively asserting that I need the control to have one set of myproj versions with rust < 1.36 and another set of myproj versions for rust >= 1.36.  Its not necessarily ideal, but it is a useful hacksaw to have in the toolbox when its needed and makes sense.  When users rustup to a latest nightly or beta >= 1.36, they will see a clear error from cargo saying that their existing lock file, containing myproj 1.2.0 is now yanked and a cargo update -p myproj is needed. If there Cargo.toml has a dependency bounds not allowing myproj 1.3.0, cargo will be unable to resolve a version and will return a descriptive error to that effect, which they can fix with a bounds change.
Without being able to set a maximum rust bounds on the 1.2.x series of myproj, all is not lost, but I have to just keep breaking and confusing users with rust >= 1.36 and myproj < 1.3.0, and letting the rustc failures and github issues or README documentation try and guide users to apply their own "exotic" version bounds on myproj in there own projects.
Note, there are numerous variants on this theme, for exampling involving secondary or further away dependencies.

Hi - thanks for this RFC!
Given that Cargo.lock for binary crates is supposed to be committed to version control I think the version resolution should use the MSRV given by the Cargo.toml from the current main build target instead of the version of the compiler itself.
For testing whether a target builds with more recent versions I'd prefer some clean process to do so; maybe for non-standard --target-dir directories the MSRV could be overwritten in some way, which also would require a separate Cargo.lock to be generated in such target directory.

@stbuehler That would only work if we prohibited specifying maximum versions. Otherwise if any of your dependencies used @dekellum's trick, you'd risk resolving to a set of crates that while completely valid, your own compiler would be unable to build.

@fintelia Hm.  I think a consistent Cargo.lock is more important than getting maximum versions working in the scenario you described; but I guess theoretically it might be possible to determine a finite set of ranges (including single versions) to run version resolution for, and store them all in Cargo.lock.

@newpavlov I apologize for the late response. I've written a blog post laying out a bunch of thinking about version selection in general, which also talks about toolchain constraints. I'm hopeful that can inform some of the exploration of tradeoffs between this RFC and the LTS RFC.

@aturon That blog post is not considering an important kind of maintenance policy for a crate, which is the one I use for all my crates: I only support the latest released toolchain. The day toochain 1.99 is released, I stop caring if my crates build with toolchain 1.98. Typically what happens is that users try to build with an older version of the toolchain and the build fails with some cryptic error message and they waste their time and my time filing a bug report about the cryptic error message. If I had a way of stating that "I only support toolchain 1.99 and up" in Cargo.toml, much of this wasted energy would be avoided.
In fact, I really want a mechanism to say in Cargo.toml "if the build fails, don't file a bug report unless you are using the latest Rust Stable release or you expect this is something that needs to be addressed in order to be compatible with the next Rust Stable release."

@aturon
See my reddit answer.

It looks like this RFC got paralysed over getting all the features in and perfect, while the current situation is dire.
I really need anything to give a clear, non-scary messages to users trying to compile my crates with too-old Rust.
e.g. this is user experience of using one of my crates:

error[E0658]: non-reference pattern used to match a reference (see issue #42640)
--> /home/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/lodepng-2.4.1/src/huffman.rs:157:18
|
157 |         .filter(|(_, f)| *f > 0)
|                  ^^^^^^ help: consider using a reference: &(_, f)

It is awful. It's scary-looking. It gives no hint of what the real problem is. I really wish I could turn it into something like (+/- bikeshedded wording):

error[XXX]: Rust 1.30 is required for this crate. Please upgrade Rust and try again.

Well, the core feature of this proposal is essentially the same as at was at the time of the publishing: add rust field to Cargo.toml and use it in dependencies version resolution as a ^-style constraint (and produce nice error(s) if dependency constraints can not be resolved for given Rust toolchain). So I believe that ball is on the Rust team side right now, to make a principal decision if we need this feature or not. (though this RFC could use some minor edits based on the discussion)

Here's a minimal-minimal-RFC:

Allow rustc-minimum-version field to Cargo.toml [package] section
Don't insert anything automatically anywhere.
Don't use it for dependency resolution.
Support only exactly 1.x.x format. Only one version. No semver ranges. Ignore nightlies (#[feature] has a good-enough error).
If a crate being compiled has this property, and it's higher than the current Rust version, print an error and abort.

There's a ton of features that are very good to have, but such minimum could be added as a starting point that authors could manually use to at least handle most basic cases. Everything else can be bikeshedded after.

If rust = would be put by cargo new automatically then it maybe better be warning instead?

You can disable checks with --no-msrv-check, so I think it's worth to keep stricter defaults (for new, publish and build sub-commands) as described right now.

Allow rustc-minimum-version field in Cargo.toml's [package] section.

I am personally strongly against such long names. I think your variant is overly verbose and does not make much difference, while Cargo.toml becomes more noisy.

Don't use it for dependency resolution.
Support only exactly 1.x.x format. Only one version. No semver ranges. Ignore nightlies

The blocker here not an implementation difficulty, but Rust team green light on this idea. One of the cargo developers mentioned that it will not be too hard to add such constraint, so it does not make sense to water down this feature like this. Plus I think that rust = "stable" variant is a must-have if we don't want >90% of newly published crates to omit specifying MSRV.

Fine, I don't feel strongly about the name, so rust/rustc + -min/-msrv or whatever is fine too.
The advantage of not using this property for dependency resolution is ability to remove it in the future without breaking anything. This reduces risk of introducing the feature. So if the libs team is not sure if they want this feature, I'm assuming a no-risk version is easier to try and release to stable ASAP, and parts of this feature that are less clear can be added later.
I'd totally like 90% of crates to have MSRV specified, but if details on how to do it are blocking this feature, this means 0% of crates having MSRV until all of it is worked out. So I'd like to get anything out of the door to get 1% of crates with MSRV while we work on getting it up to 90%.

What is the status of this RFC?

@fintelia
We are awaiting decision from Rust team. I guess they are too busy with 2018 edition to make decision on this RFC.
@aturon
Is my understanding correct?

I think this RFC is way too complicated.

We don't need to change how cargo publish works; that can be done in the future.
We don't need to automatically translate stable to the version that the crate was published with. We can just require it to be a valid version number literal. Future iterations can add more complexity, maybe.
We don't need the minimum supported rust version to affect dependency resolution. This would be an anti-feature. If I fix a critical security bug in my crate and publish a new version, and that new version requires a new version of Rust, then people shouldn't keep using the older version because of the Rust version dependency.

The ONLY thing we need here is this: When building the crate, check to see if the MSRV is higher than the current version of Rust. If it is, stop building and report a readable error message stating that "Rust version X is required to build this." (Wordsmith away.) That's it!

@briansmith You're not the first to describe a "minimal-minimal-rfc"

* We don't need the minimum supported rust version to affect dependency resolution. This would be an anti-feature. If I fix a critical security bug in my crate and publish a new version, and that new version requires a new version of Rust, then people shouldn't keep using the older version because of the Rust version dependency.

You might not need it, but I think it is sad when people using stable linux distributions can only develop rust code when they are using rustup with the latest compiler.  I tried using rust from debian testing for some time, and even that just wasn't doable.
If you have crate versions affected by critical (security) bugs, you should yank them imho.  I'd hope cargo update would tell you about those.
I really think it should affect dependency resolution in the future (a "minimal-minimal-rfc" obviously doesn't need it).

We don't need the minimum supported rust version to affect dependency resolution. This would be an anti-feature. If I fix a critical security bug in my crate and publish a new version, and that new version requires a new version of Rust, then people shouldn't keep using the older version because of the Rust version dependency.

I'd agree the default behavior should not be to select older packages based on the minimum required Rust version. That said, I'm somewhat curious under what circumstances a security fix would require a new version of Rust (short of a vulnerability in rustc/std). If you're only fixing the latest release and don't want to support older releases which contain a vulnerability, why not yank them?
Back to the question of dependency resolution, as an example from another language ecosystem, the minimum Ruby version has been part of RubyGem's "spec" files almost from the beginning, and is part of Bundler's version resolution mechanism (where Bundler is the dependency resolver tool. In Rust, cargo provides the features of both RubyGems and Bundler).
By default Bundler prefers the latest version of each gem, irrespective of the minimum required Ruby version, and will fail if it selects a package that needs a newer Ruby version. However, it also supports an option in a Gemfile (the equivalent of Cargo.toml) to only consider packages which are compatible with a specified Ruby version.
I personally liked this behavior as it allowed for rapidly adopting new language features in an unobtrusive way, in my particular case for internal company packages in a company where Ruby versions varied.
However, these projects were also audited by bundle audit (via Brakeman) to ensure none of their dependencies contained security vulnerabilities. GitHub now performs these same checks automatically and exposes them through the web UI. So there was a sort of "compensating control" to ensure that if people were using older Ruby versions, and were using this particular Bundler feature, they at least would be aware they had vulnerable dependencies.
I would like to think cargo-audit could act in a similar capacity, but as its author, I will admit I don't think it's there yet, particularly in terms of adoption.

. That said, I'm somewhat curious under what circumstances a security fix would require a new version of Rust (short of a vulnerability in rustc/std).

Let's say in one commit I introduce a dependency on a feature in the newest stable Rust. Then I fix a security bug in the next commit. Or, when coding the security fix, I make use of a feature of the newest stable Rust (because why not?).

If you're only fixing the latest release and don't want to support older releases which contain a vulnerability, why not yank them?

Literally nobody thinks about whether or not older releases contain a vulnerability or not (at least I don't). I suppose I could always yank every older version when I publish a new version so there's never ever one non-yanked version; I don't see any downsides of doing that.

I suppose I could always yank every older version when I publish a new version so there's never ever one non-yanked version; I don't see any downsides of doing that.

I am considering actually doing that in a particular case, as it were (although it's for a crate whose previous release builds were always broken).

@briansmith

We don't need to change how cargo publish works; that can be done in the future.

As was stated in the RFC, first stage will be to have a "dumb" optional field which can be used with third-party tools. In other words this RFC attempts to describe a future which I believe we should pursue.

We don't need to automatically translate stable to the version that the crate was published with. We can just require it to be a valid version number literal. Future iterations can add more complexity, maybe.

Again, translating "stable" to the version is a second stage. For the first stage we could accept only valid version numbers. I believe allowing "stable" field value is a must have if we want to make MSRV field mandatory (in future edition), so those who don't bother with tracking MSRV will have a lazy "just take my toolchain version" option. I believe that making the field optional will significantly reduce usefulness of the feature.

We don't need the minimum supported rust version to affect dependency resolution. This would be an anti-feature. If I fix a critical security bug <..>

As others have said if your crate has a security bug you should yank it. Those who care about supporting older version of Rust compiler need such feature. Otherwise we will have to bump major crate version when Rust gets a new feature which we would like to use, or keep codebase in a worser state than it could be.

When building the crate, check to see if the MSRV is higher than the version of Rust being used to build the crate.

This approach will make a lot of crates unusable for older toolchains. I think we should rely on tools like cargo outdated to check if upstream crates have updates which require newer MSRV compared to the current crate MSRV or toolchain version.

If MSRV was added without affecting dependency resolution, would it be a breaking change if it started affecting dependency resolution later?

It's not a bigger breaking change than publishing crate with a bigger MSRV today. Plus you can always disable MSRV constraints with --no-msrv-check flag.

This approach will make a lot of crates unusable for older toolchains.

Good.

Here's an even more conservative proposal, which could serve as a stepping stone:
If any (non-fatal) error is encountered, and the crate advertised a MSRV, and the version of rustc is older than that, DO NOT EMIT any message for that error. Instead, emit an error message that the MSRV requirement was not met. If no errors are encountered, then do nothing.
In particular, this will ensure that the initial implementations of the MSRV mechanism would not cause any crate to fail to build on its own; it would merely replace the confusing error messages with a clear error message.
To be clear, failing to meet the MSRV should eventually become an error on its own. This conservative suggestion is intended to show a very gradual way forward.

failing to meet the MSRV should eventually become an error on its own

It's the main difference between your approach and one described in this RFC. You consider that breaking builds for older toolchain versions on a new patch update of some upstream dependency which internally uses new shiny lang/std features is a "good" thing. IIUC supporting only the latest stable version is a policy which you have adopted in ring and nothing wrong with that, but others (including me) take supporting older toolchain versions quite seriously and do not want break other people's build without VERY good reason.
With the functionality proposed in this RFC you can simply use "stable" as your MSRV and yank older patch versions of your crates. This effectively will enforce latest stable as a requirement for using your crates. Yes, you will not use most of the functionality in this RFC, but others will.

@newpavlov Regardless of which way is better, the fact is that no progress is has been made on this feature for a very long time, despite lots of people willing to help with it. Thus, my idea is to greatly simplify the feature to the minimum thing that could possibly help and which has zero risk (since nothing will break unless it was already broken) so that things can move forward. With a specification as complex as what you described, it would take at least a year to get into Rust stable, in my estimate. I'm trying to shorten the time until we get something useful.

So the main blocker for MSRV is not implementation difficulty, but a principal decision from Rust team.

Right, so let's agree on the easiest stuff to agree on now, and defer the harder-to-agree-on stuff for later.
Anyway, I think we should collect some motivation for doing this. There are multiple motivations:

It is confusing for users of a crate to get compilation errors because the crate has a MSRV higher than what the user is currently using. This is important but not critical.

Rust sometimes has bugs or changes in semantics (either language semantics or library semantics). If my crate is used in an older version of Rust then, if it compiles, the user may get wrong or even dangerous results. For example, consider https://github.com/rust-lang/rust/issues/18086. If you use extern "fastcall" then you must use a particular version of Rust (which one? I'm not sure). Otherwise the code might compile but it will be dangerously wrong. Similarly, one must use Rust 1.22 or later to avoid CVE-2018-1000657, one must use Rust 1.29.1 or later to avoid CVE-2018-1000810, etc. This is a critical reason to implement at least the very minimal version of this feature.

In the meantime, edition = "2018" acts as msrv = "1.31".

+1.  There is also a want for a scanning tool to detect minimum rust version and even assist with identifying how much of a crate depends on newer versions.

I know you were joking @kornelski , but I was disappointed to see that, for example, rust 1.16 completely ignores the edition="2018" field and continues on to fail to build in the typically perplexing ways. Unfortunately, I guess this will likely also be true with the proposed rust field addition, if its accepted and implemented?  I added this to a project:
[package]
edition = "2018"
rust = "1.36"
blowup = "please don't ignore me!"

And sure enough both the rust and the blowup field is completely ignored by rustc 1.35.0-nightly (3eb4890df 2019-03-19), cargo 1.35.0-nightly (0e35bd8af 2019-03-13). Even a new section is completely ignored:
[msrv]
rust = "1.36"

So it seems the longer such a feature is delayed, the longer it will be before the ecosystem is really free of the problem this is trying to address.  Considering this, perhaps a better design would be an attribute which can't be ignored in src/lib.rs:
#![rust_minimum_version(1.36)]

Which is a fatal error for the current compiler:
error[E0658]: The attribute `rust_minimum_version` is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642)
  --> src/lib.rs:11:4
   |
11 | #![rust_minimum_version(1.36)]

I guess one downside is when we want to get smarter and use this for dependency resolution, cargo would need some way of extracting it from the build for package metadata?
If just the minimal version part of RFC #2523 were accepted and implemented, might that also be enough for the basic use case:
#[cfg(not(version(1.36)))].
// ... something causing a fatal and hopefully descriptive MSRV compile error? ...

I don't actually know what that last line, at src/lib.rs top level, would be though?

I guess one downside is when we want to get smarter and use this for dependency resolution, cargo would need some way of extracting it from the build for package metadata?

Using MSRV for dependency resolution would likely encourage crate authors to aggressively yank old unsupported (and potentially broken in security-critical ways) versions of their crates so that people don't accidentally use them with old versions of the toolchain.

@briansmith, presumably this is independent of my attribute vs cargo field suggestion, but:
Yanking older versions with security vulnerabilities seems to be the consensus approach.
Yanking old versions that are currently "unsupported" would seem strange, and I haven't noticed that happening with other language communities, like ruby, that have had these features for a long time now.

Crates that become Debian Packages will benefit from the Debian Security team that will in most cases backport patches.  Having a system where old Crates can be patched would be ideal.

Off topic, but, @cheako, the yank on crates.io is soft. Debian or anyone can still get the crate tarball, I believe, and would as likely just be patching against the original source repo.

This might be worth opening another bug about, what to do with important patches against /previos/ creaets.io versions.  I don't think pulling them is the correct answer.

I just ran into an issue where it would be useful to be able to specify a minimum rustc version for a feature.  I was building with rustc / cargo 1.33.0.  Our build server was only running 1.32.0.  I hit the following error:
`
Compiling historian v4.0.3
Compiling bincode v1.1.2
Compiling v_escape v0.7.2
error[E0658]: use of unstable library feature 'vec_resize_with' (see issue #41758)
--> C:\Users<omitted>.cargo\registry\src\github.com-1ecc6299db9ec823\historian-4.0.3\src\lib.rs:44:14
|
44 |         vals.resize_with(BUCKETS, Default::default);
|              ^^^^^^^^^^^
error: aborting due to previous error
For more information about this error, try rustc --explain E0658.
error: Could not compile historian.
warning: build failed, waiting for other jobs to finish...
error: build failed
Build Errors
`
Apparently that feature was stabilized in 1.33.0.
So I added the following feature to disable it for now:
[features] memory_db = [] default = []
What I would have liked to be able to do is something like the following:
[features] memory_db = ["rustc >= 1.33.0"] default = ["memory_db"]
Then it would only add the memory_db feature if the rustc version was satisfied.  Note that I don't care about the specifics of the syntax, just the ability to say that a feature depends on a particular version of rust.
If there is a more appropriate place to make this request, please let me know and I can move this request.
Thanks,
-Dave

Here is a blog post on Cargo build.rs recipes, including enforcing MSRV for a crate. In particular, see the edge cases observed for various rustc versions when edition="2018" is used, or when the MSRV of dependencies isn't satisfied. I suspect that any direct support for specifying MSRV is going to encounter the same edge cases, just given how cargo and rustc work in all existing releases. Still this offers an improved error message for many rust versions.

A few responses from the Cargo team meeting:

We'd be interested in taking a minimal first step here, which can have more functionality added later.
For that minimal first step, we're uncomfortable with things like rust="stable" or rust="nightly", and would prefer to have only version numbers.
The first step shouldn't affect resolution, it should just produce a friendly compilation-time error if you don't have a sufficient version.

@joshtriplett
What is the status of this RFC in the light of this summary? Should I re-write it to include "versions-only" first step, wait for the minimal version and update RFC accordingly after that, or should this RFC broken into smaller ones?

This was also brought up today in the rust-gamedev wg discussions on this topic: https://github.com/rust-gamedev/wg/issues/28
I think there's an opportunity to collaborate on this RFC.

@newpavlov Personally (not speaking for the Cargo team here), I would suggest continuing forward with this RFC, focusing on the minimum next step that we can build consensus on, and significantly expanding the "future work" section. :)

@joshtriplett Could you, or another person from the cargo team, outline a little more specifically what the format of the minimum next step would look like, that the cargo team would be comfortable with? It's a little vague what exactly the team is looking for.

The minimum next step looks approximately like the step-1 version, minus the remaining steps, minus anything other than version numbers (no "stable", no "nightly").

Quick updates from the Cargo team meeting: we're potentially willing to see the minimal implementation (single declarative field for a version, error message if you don't have that version, no impact on resolution), but we'd like to get some feedback from people who may actually use this feature.
@dtolnay (for serde)
@kbknapp (for clap)
@BurntSushi (who had comments about this on Reddit)
Please also @ in anyone else you think would actively use this.

I would absolutely use this feature, and I believe that a single specific version entry in the Cargo.toml would be sufficient for my needs if it grew to eventually affect dependency resolution.
A simple error to start is also quite good.

@SergioBenitez @jebrosen See above. I know Rocket requires a minimum Rust version.

@joshtriplett Thanks! I think it's probably safe to say that I'd use it in almost every single crate I maintain, just for the improved failure modes alone.

@joshtriplett I would use this if it existed, but I would note that it's not great for Serde (and some of my other crates) where different feature combinations require different minimum Rust versions. In Serde for example features = [] supports 1.13+, features = ["derive"] supports 1.31+, features = ["alloc"] supports 1.36+, etc.
I guess that means I put 1.13 as the minimum under this RFC, but in practice nobody uses anything older than 1.13 and the people that care about this are somewhere in between but with features enabled.

Quick updates from the Cargo team meeting: we're potentially willing to see the minimal implementation (single declarative field for a version, error message if you don't have that version, no impact on resolution)

I would absolutely use that and that's exactly what I want.

I've experimented with MSRV-based dependency resolution, and got promising results:
https://users.rust-lang.org/t/rust-lts-a-diy-solution/32114
Even if Cargo doesn't use msrv annotation itself, the data would still be useful for building a more reliable workaround for Cargo.

Personally I'd be happy with a purely informational version of this feature that just warned users if they're using below the MSRV at the initial time they generate their Cargo.lock and displayed the MSRV on crates.io

warned ... generate their Cargo.lock

What about building executable crates with pre-existing Cargo.lock? Shall Cargo.lock also have msrv field?

I hope rls uses it!  Its horrible that rls won't work on Debian, but it's even worse that the only way you can find this out is by trying for hours.

I've updated RFC, now it centers around the minimum functionality and everything else got moved to the "future work" section. Please take a look.

we'd like to get some feedback from people who may actually use this feature

It may be obvious, but I would definitely use this feature. :) Although I think if we want to prevent accumulation of compatibility baggage in crates, it's quite important to add MSRV-dependent version resolution as early as possible. This issue may become significantly worse if #2523 will get merged and implemented (cc @Centril).

FWIW, I would love to use this for c2rust, as long as it supports specifying a nightly compiler version. We just need to pin a specific nightly and error on anything else. Right now we do a version check in build.rs, but that isn't ideal.

@newpavlov Thanks for updating the RFC!
@rfcbot merge

@rfcbot reviewed

@rfcbot reviewed
With the caveat that crates.io validation may not be possible (it may not know what "stable" is).  That's also up to the crates.io team whether they want to do that or not.

In future (probably in a next edition) we could make rust field mandatory for a newly uploaded crates.

Is there a wishlist issue somewhere tracking suggested changes for the next edition? Seems like this would be dropped on the floor otherwise.

@bstrie Perhaps you could open such an issue?

🎉 Huzzah! The RFC has been merged!
Tracking issue: https://github.com/rust-lang/rust/issues/65262

In future (probably in a next edition) we could make rust field mandatory for a newly uploaded crates.

I don't think this is compatible with older Cargo releases. Mandatory version number means not being able to support Rust versions older than 1.27. Although, I suppose there is probably no real reason to support old Rust releases like this.

Old cargo wouldn't be able to upload as the next edition value anyway, right?
Assuming they meant, "edition 2021 crates must specify a minimum version, other edition crates can do whatever.", then that seems fine.


Add missing migrations

I want to merge this change because...
I want to add missing migrations.
Pull Request Checklist

[x] Privileged views and APIs are guarded by proper permission checks.
[x] All visible strings are translated with proper context.
[x] All data-formatting is locale-aware (dates, numbers, and so on).
[x] Database queries are optimized and the number of queries is constant.
[x] The changes are tested.
[x] The code is documented (docstrings, project documentation).
[x] Python code quality checks pass: pycodestyle, pydocstyle, pylint.
[x] JavaScript code quality checks pass: eslint.

Codecov Report

Merging #1417 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1417   +/-   ##
=======================================
  Coverage   82.91%   82.91%
=======================================
  Files         128      128
  Lines        5777     5777
  Branches      663      663
=======================================
  Hits         4790     4790
  Misses        831      831
  Partials      156      156

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 aa33fa5...3e61412. Read the comment docs.


Design how the UP removes unwanted reportable conditions for a specific receiver

User Story:
As a receiver, I want to receive reports with only the reportable conditions I want, so I do not have to process unwanted data.
Description/Use Case
The COVID pipeline can only process one reportable condition per report. On top of that, conditions are reported to a specific pipeline from a specific sender, so there has been no need to filter out by condition.  For the UP, we can receive any condition and multiple conditions within a report, so we need a mechanism to remove conditions that are not wanted for a given receiver (e.g. a report contains COVID and Flu, but the receiver wants only COVID, so we remove the FLU information). in a report and allow a receiver to filter out what they do not want.
Risks/Impacts/Considerations

There could be a performance impact depending how this removal is done.

Dev Notes:

Need to first identify the mechanism(s) on how to remove reportable condition(s) (is it going to be by LOINC, equipment name, some text, etc.?).  Get with the OO team to figure this out.
May need the information from a lookup table (e.g. may need to check if ANY of ALL the LOINC codes in the LIVD table exists in the report).  You can see how this can be an expensive operation and we may want to think about caching.
Are we at risk of leaving some FHIR reference orphan if we remove something?

Acceptance Criteria

Document the ways we need to identify reports that are wanted by a receiver (e.g. via LOINC code?).  This needs to support the possible ways OO may want to filter these reports.
Document the proposed implementation of the removal, where it is configured, and what component in the UP diagram it belongs to (or maybe it is a new component)
Get buy-in from the team on the design.
Present the design to OO for buy-in
Generate the necessary tickets to implement the approved design.

Design is attached here:
202301 Condition filtering design.pdf
202301 Condition filtering design.docx


Testinfra test fails for package install on Ubuntu 18

SUMMARY
Testinfra test reports failure after installation of Java 11 deb package on Ubuntu 18
ISSUE TYPE

Bug Report

COMPONENT NAME
testinfra test
ANSIBLE VERSION
ansible 2.5.14
  config file = None
  configured module search path = [u'/home/gitlab-runner/.local/lib/python2.7/site-packages/epam_ansible']
  ansible python module location = /usr/lib/python2.7/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 2.7.15 (default, Aug 16 2018, 14:17:09) [GCC 6.4.0]

CONFIGURATION
$ ansible --version
ansible 2.5.14
config file = None
configured module search path = [u'/home/gitlab-runner/.local/lib/python2.7/site-packages/epam_ansible']
ansible python module location = /usr/lib/python2.7/site-packages/ansible
executable location = /usr/bin/ansible
python version = 2.7.15 (default, Aug 16 2018, 14:17:09) [GCC 6.4.0]
$ molecule --version
molecule, version 2.19.1.dev120
OS / ENVIRONMENT
Ubuntu 18.04
STEPS TO REPRODUCE
See the following job:
https://gitlab.com/lean-delivery/ansible-role-java/-/jobs/165557410

EXPECTED RESULTS
Like this one:
https://gitlab.com/lean-delivery/ansible-role-java/-/jobs/165557408
ACTUAL RESULTS
    =================================== FAILURES ===================================
    _ test_java_version[ansible://test-aws-ubuntu18-ansible-role-java-11-otn-deb] __

    host = <testinfra.host.Host object at 0x7f2a88853bd0>

        def test_java_version(host):
            command = host.run('java -version')
    >       assert command.rc == 0
    E       AssertionError: assert 127 == 0
    E        +  where 127 = CommandResult(command='java -version', exit_status=127, stdout=u'', stderr=u'/bin/sh: 1: java: not found').rc

    ../resources/tests/test_default.py:19: AssertionError
    ====================== 1 failed, 7 passed in 7.70 seconds ======================

@tgadiev This test is correct when python run "java -version" it should get 0 as exit code of the command (without errors), but it gets exit code 127, so this issue related to java setup.  Code 127 command not found in PATH and it is not a built-in shell command.

Fixed by https://github.com/lean-delivery/ansible-role-java/pull/55


adding two new Branch Rules for Harness Code: Block branch update and…

adding two new Branch Rules for Harness Code: Block branch update and block force push
Thanks for contributing to the Harness Developer Hub! Our code owners will review your submission.
Description

Please describe your changes: __________________________________
Jira/GitHub Issue numbers (if any): ______________________________
Preview links/images (Internal contributors only): __________________

PR lifecycle
We aim to merge PRs within one week or less, but delays happen sometimes.
If your PR is open longer than two weeks without any human activity, please tag a code owner in a comment.
PRs must meet these requirements to be merged:

[ ] Successful preview build.
[ ] Code owner review.
[ ] No merge conflicts.
[ ] Release notes/new features docs: Feature/version released to at least one prod environment.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://66eb25997ae65481f4cde6e1--harness-developer.netlify.app


Add tests desktop devices

Codecov Report

Merging #55 into master will increase coverage by 0.89%.
The diff coverage is 92.19%.

@@             Coverage Diff              @@
##             master      #55      +/-   ##
============================================
+ Coverage     83.42%   84.31%   +0.89%
+ Complexity     5460     5356     -104
============================================
  Files           325      328       +3
  Lines         11085    10873     -212
============================================
- Hits           9248     9168      -80
+ Misses         1837     1705     -132

Impacted Files
Coverage Δ
Complexity Δ

src/Helper/Desktop.php
93.1% <ø> (ø)
13 <0> (ø)
:arrow_down:

src/Helper/Windows.php
87.17% <100%> (ø)
19 <0> (ø)
:arrow_down:

src/Factory/Platform/DarwinFactory.php
81.14% <100%> (ø)
61 <60> (ø)
:arrow_down:

src/Factory/Device/Tv/SonyFactory.php
100% <100%> (ø)
4 <4> (?)

src/Factory/Platform/LinuxFactory.php
100% <100%> (+2.38%)
4 <3> (-16)
:arrow_down:

src/Factory/Device/Desktop/AppleFactory.php
100% <100%> (ø)
4 <4> (?)

src/Factory/Device/DarwinFactory.php
100% <100%> (+84.03%)
3 <0> (-56)
:arrow_down:

src/Helper/Macintosh.php
100% <100%> (ø)
4 <0> (ø)
:arrow_down:

src/Factory/EngineFactory.php
100% <100%> (ø)
24 <0> (+1)
:arrow_up:

src/Factory/Platform/WindowsFactory.php
76% <100%> (-0.48%)
25 <24> (ø)

... and 8 more

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 b617053...289c377. Read the comment docs.

Coverage increased (+0.9%) to 84.015% when pulling 289c3775bfda11e1a77211c6b4b2e354c0ca2bad on add-tests-desktop-devices into b61705371d96f29afb467bf5396985b76e92c879 on master.


Using springSecurityService.getCurrentUserId() to grab currentUser's primary identifier?

Issue description
Inside SpringSecurityService.groovy there is a getCurrentUserId() method that returns the id property from the principal. I see no reference to this method in the documentation.
Is this method the optimal way to fetch the currentUser's primary identifier of the applications User entity or should we always use the documented springSecurityService.getCurrentUser() and grab the identifier from this User instance?
The getCurrentUserId() has the benefit of not making an additional database call / transaction to fetch the entire user record (for cases where we just need the identifier).
My concern is that the getCurrentUserId() method is not referenced in any official documentation and therefore it may not be supported or included long term?
Thank you,
henryc-agr

if all you need is the user id, getCurrentUserId() would be the preferred way.


Update Fladle to support all the new Flank flags

https://github.com/runningcode/fladle

https://github.com/runningcode/fladle/pull/88
cc @bootstraponline

@bootstraponline
According to https://github.com/runningcode/fladle/pull/88#pullrequestreview-394115444 . PR will be merged once new stable version of flank is released. In the mean time, I will keep this PR updated.

Sounds great. We are targeting a May 15 release date for the new stable version.


R Show function missing

As reported by @zivy, the Show function in R is missing.  I've tracked it down to the following commits:
https://github.com/SimpleITK/SimpleITK/commit/6aa497d921ab97633c689b42f27771d50ab4b57e https://github.com/SimpleITK/SimpleITK/commit/7c0e9aae880d75f05129b225f05bc6e0691fb00f
I tried to figure out what was wrong but couldn't really understand what the file mkNamespace.R was doing.  I did notice that the lowercase function 'show' is mentioned in there, so I tried that, and yes, 'show' works as expected.
Also I tried the ignorant thing of changing 'show' to 'Show' in the script, but that didn't build.
I would guess and hope that this is a trivial bug for @richardbeare to fix.

Apologies for that - must be a side effect of attempts at making the package "CRAN compliant" leading to Show not being exported from the R namespace. The lowecase show is the standard generic operation that calls Show - it is the one invoked when an image variable name is typed at the console.
I'll look into it.

OK,
I'm ready with a patch that exports Show correctly. However there is another issue making it impossible to use another viewer if imagej isn't installed on the host. Filing an issue on that.

closed by #603


Simplify installation instructions

Hi Sebastian @sebi06 ,
here comes a small PR simplifying installation instructions. I tested it like this and it works like a charm. Congrats to the great plugin!
Best,
Robert

Hi @haesleinhuepf
thanks for the improvements.


Using oops concepts and dsa concepts(linkedlist, Trie)

Title and Issue number

Close #3190

Checklist:

[x] I have mentioned the issue number in my Pull Request.
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have created a helpful and easy to understand README.md

great project did and implements oops concepts with dsa knowledge , merge this pr @pranjay-poddar @MohitGupta121

@TusharKesarwani


feat(rx-dynamic-component): add the ability to preload modules

@Stonepaw just pushed an update that implements the loading priority and a method on the service to manually trigger priority manifest loads.


Timer not right

Hi, I have a countdown timer set for an event at 7:30pm or 19:30, and it is showing 02:35:18 at the current time of 3:54pm. I am in CST, and the clock on my RaspberryPi, and MagicMirror are both correct. Timer is an hour off.

I just tested the module with a 19:30 event (it can't be 7:30 for pm) and the module performs as expected accurately. I'm sorry you're have trouble with it. If you wouldn't mind creating a topic on the MM forum I can better help you there. I'd like to have a  look at your config entry which is better viewed there than here


Issue when reading remote CSV

Hello,
I found that computing series from a remote CSV takes so much time. I can read the file successfully with:
df = dd.read_csv("https://path/dataframe.csv")

but when computing, for example:
df.head(1)

it REALLY takes a long time.
Could be something about storage_options that I am missing? Could be something about the protocol or server where dataframe is storaged?
Thanks for your time.

@perezzini thanks for the report.  Would it be possible to share an a minimal example with public data ?  If you don't have a readily accessible public data set perhaps you can upload an example CSV to Gtihub and use that.

Hi @quasiben .
Apparently it's something concerning server side with a particular CSV. I tried with other public dataframes and computing time for common operations were just OK.
But now, what it's causing me troubles is that with some public CSV files, the following error appears when reading:
Backing filesystem couldn't determine file size, cannot do chunked reads. To read, set blocksize=None

But using blocksize=None in Dask it's like losing what Dask is all about: I cannot longer split datataframes into chunks.
I red somewhere that this problem was "fixed", but it seems not to me. Or maybe I am missing something with respect to fsspec lib, etc.
Thanks for quick reply.
Example:
df = dd.read_csv("https://data.lacity.org/resource/hpbr-2ant.csv")

@perezzini yes, in http "filesystems" often there is no file size listed in the header so dask has no ability to chunk an unknown sized file.  You can see this info easily with curl --head
❯ curl --head https://s3.amazonaws.com/nyc-tlc/trip+data/yellow_tripdata_2019-01.csv
HTTP/1.1 200 OK
x-amz-id-2: M6D3EVbnjVP4vZhNonbzbEBct0yv0Ek3rCC3w9MmaKMtA/XWELc+q6UvFA5B2SdO8xcK+60Kkwg=
x-amz-request-id: 5F530D47FC351F66
Date: Tue, 31 Mar 2020 15:04:33 GMT
Last-Modified: Wed, 14 Aug 2019 17:45:00 GMT
ETag: "1bfeb66e3a477c7ea21766ac97208340-40"
Accept-Ranges: bytes
Content-Type: text/csv
Content-Length: 687088084
Server: AmazonS3

Note: Content-Length: 687088084 As opposed to,
❯ curl --head https://data.lacity.org/resource/hpbr-2ant.csv
HTTP/1.1 400 Bad Request
Server: nginx
Date: Tue, 31 Mar 2020 15:04:57 GMT
Connection: keep-alive
Access-Control-Allow-Origin: *
X-Error-Code: invalid_request
X-Error-Message: HEAD is not supported
Cache-Control: private, no-cache, must-revalidate
Age: 0
X-Socrata-Region: aws-us-east-1-fedramp-prod
X-Socrata-RequestId: 4a0fd995390410323b84c2206de62f6a

Where no length is defined.

Thanks @quasiben for your quick and clear response.
Do you know if in the case I start to store (CSV) dataframes in Amazon S3 "filesystem", Content-Length is a MUST. I mean, does every request (through http(s):// or s3://) always retrieves its own Content-Length, so I can use Dask's read_csv() without any worries?
I'm kind of new using file systems, and my team created a very useful project using Dask but we didn't test reading from remote data (and this is now extremely required).
Again, thanks for your response. Would like to know more about work-arounds about this "issue".

I believe in the case of S3, Content-Length should be there and you should be able to use read_csv with blocksize. Is that right @martindurant  ?

Yes, S3 provides the length through it's own API, which is what you get with "s3://". I believe the https endpoints for AWS S3 do too via a HEAD call. People use s3 and gcs for blockwise loading of large files all the time.
(The only caveat is that you should not specify the content-encoding for compression, even if the file is indeed, because it makes the byte range you read ambiguous)

Thanks @martindurant for the response.  I think since there is no bug here we are good to close


Difference between c.sell_stop_pct and c.max_sell_loss_pct

I'm confused about these two parameters.  Using c.sell_stop_pct = 1, I can get the bot to sell when the price dips beyond a 1% loss on the trade. In this case, wouldn't c.max_sell_loss_pct = 1 be redundant? Or does it serve a different purpose?

Yeah i thought c.sell_stop_pct x would sell when the trade is down x pct but it doesnt seem to do that.

@brucetus It works for me, but I think it depends on the period value. If the period is set too high, you could miss the value by a lot.  For example, a --period=10m can leave you exposed for 10 minutes while the loss grows bigger than the c.sell_stop_pct.  I think it would only kick in at the next period. At least thats my assumptions from watching it trade.  Using c.max_sell_loss_pct does not behave as expected for my however.

@bbusche Ahh i think you're right. I was using 4h period and it eventually sold.

Dear issue reporter,
We have slightly changed our github issue policy and would now kindly request folks that have questions that they ask them in our zenbot subreddit.
You can find it here: https://reddit.com/r/zenbot
This issue will be closed, but if you disagree with your ticket being marked as a question feel free to leave a comment defending your case.
Thanks for contributing time and effort!
Greetings,
🤖


Fix bug in mmCIF parser

Loading cif files with spacegroup info failed due to typo

Hmm, the mmcif dict says it is a hyphen. I am ok with adding the underscore variant if there are files out there needing it.

I am ok with adding the underscore variant if there are files out there needing it.

It's better to force people to follow standard.

The cif file i'm using was generated by biojava, so if there are errors we should fix them in biojava not ngl


why did you prune ResNet-50, Instead of ResNet-18, ResNet-34?

As mentioned in the title.
I guess that the more is the number of layer, the more is better in speed after pruning.

Because many acceleration methods failed on very deep models like
ResNet-50, Xception-50.
18, 34 are not bottleneck architecture. They are similar with VGG-16.
On Thu, Oct 19, 2017 at 2:54 AM, eeric<EMAIL_ADDRESS>wrote:

As mentioned in the title.
I guess that the more is the number of layer, the more is better in speed
after pruning.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/yihui-he/channel-pruning/issues/40, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AJkBS8f7f_IH6ELjzz9419oBbgII3GDsks5stvIfgaJpZM4P-xcE
.

--
Best,
Yihui He
yihui-he.github.io

It's not like that.
2X in FLOPs that was impractical.

Nothing more than this.

To your knowledge, which work could practically accelerate ResNet-50 up to
2X without special implementation?
On Thu, Oct 19, 2017 at 3:04 AM, eeric<EMAIL_ADDRESS>wrote:

It's not like that.
2X in FLOPs that was impractical.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/yihui-he/channel-pruning/issues/40#issuecomment-337818109,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJkBSyOR0YiGDOX4PiD_-R6Nv9-Gfb4Mks5stvRjgaJpZM4P-xcE
.

--
Best,
Yihui He
yihui-he.github.io

Not yet.
It is not fit to ResNet model to prune.


Not Working

I tried out the library and it's not working.
Here's my code
class MainActivity : AppCompatActivity() {
// fetchListener code, removed, for the sake of brevity.

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        val url = "http://www.alexszepietowski.com/wp-content/uploads/downloads/2013/03/The%202%20Golden%20Rules%20of%20Property,%20Business%20and%20Life!.pdf"
        val fileName = "MyFile.pdf"
        val dirPath = "/FileDownloader/PDF/$fileName"

        val fetchConfiguration = FetchConfiguration.Builder(this)
                .setDownloadConcurrentLimit(3)
                .build()

        val fetch = Fetch.getInstance(fetchConfiguration)

        val request = Request(url, dirPath)
        request.priority = Priority.HIGH
        request.networkType =  NetworkType.ALL
        request.addHeader("clientKey", "SD78DF93_3947&MVNGHE1WONG")

        fetch.addListener(fetchListener)

        fetch.enqueue(request)
    }

    fun Log(msg: String) {
        android.util.Log.d("MainActivity", msg)
    }
}

AndroidManifest.xml
<manifest
  ... >

    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />

    <application
        ...>
        ...
    </application>

</manifest>

Log output
D: FetchListener. onError. Error = UNKNOWN_IO_ERROR, Download = DownloadInfo(id=-1721883501, namespace='LibGlobalFetchLib', url='http://www.alexszepietowski.com/wp-content/uploads/downloads/2013/03/The%202%20Golden%20Rules%20of%20Property,%20Business%20and%20Life!.pdf', file='/FileDownloader/PDF/MyFile.pdf', group=0, priority=HIGH, headers={clientKey=SD78DF93_3947&MVNGHE1WONG}, downloaded=0, total=-1, status=FAILED, error=UNKNOWN_IO_ERROR, networkType=ALL, created=1536016053913, tag=null, enqueueAction=REPLACE_EXISTING, identifier=0, downloadOnEnqueue=true, extras={})
you can check out my full code here -> https://github.com/Edge-Developer/FetchDownloadManagerIssue

val dirPath = "/FileDownloader/PDF/$fileName" looks incorrect.
Try something like context.getCacheDir() and append your dir path.

please type out a sample code

https://github.com/sethchhim/FetchDownloadManagerIssue/commit/6173636e45b4b9cc61756dd6a61835bd75ac87f3
D/LibGlobalFetchLib: DownloadManager starting download DownloadInfo(id=-94132710, namespace='LibGlobalFetchLib', url='http://www.alexszepietowski.com/wp-content/uploads/downloads/2013/03/The%202%20Golden%20Rules%20of%20Property,%20Business%20and%20Life!.pdf', file='/data/user/0/com.edgedevstudio.fetchdownloadmanagerissue/cache/FileDownloader/PDF/MyFile.pdf', group=0, priority=HIGH, headers={clientKey=SD78DF93_3947&MVNGHE1WONG}, downloaded=0, total=-1, status=QUEUED, error=NONE, networkType=ALL, created=1536090340704, tag=null, enqueueAction=REPLACE_EXISTING, identifier=0, downloadOnEnqueue=true, extras={})
D/LibGlobalFetchLib: FileDownloader starting Download DownloadInfo(id=-94132710, namespace='LibGlobalFetchLib', url='http://www.alexszepietowski.com/wp-content/uploads/downloads/2013/03/The%202%20Golden%20Rules%20of%20Property,%20Business%20and%20Life!.pdf', file='/data/user/0/com.edgedevstudio.fetchdownloadmanagerissue/cache/FileDownloader/PDF/MyFile.pdf', group=0, priority=HIGH, headers={clientKey=SD78DF93_3947&MVNGHE1WONG}, downloaded=0, total=-1, status=QUEUED, error=NONE, networkType=ALL, created=1536090340704, tag=null, enqueueAction=REPLACE_EXISTING, identifier=0, downloadOnEnqueue=true, extras={})
D/MainActivity: FetchListener. onStarted
D/MainActivity: FetchListener. onDownloadBlockUpdated
D/MainActivity: FetchListener. onDownloadBlockUpdated FetchListener. onProgress
D/MainActivity: FetchListener. onCompleted

i mean, actual code NOT log output

The commit is the code, I will paste here for you.
val dirPath = "$cacheDir/FileDownloader/PDF/$fileName"

thanks man, i'm about to try it out

Good fetch is working.
Cache directory is a sandboxed directory in your application folder. I used this example because sandboxed directories do not require PERMISSIONS to write to it. Just so you know cache directory can be found at /Android/data/.
I rewrote your sample app to request permissions and write to the root DOWNLOAD folder like you are expecting.
https://github.com/sethchhim/FetchDownloadManagerIssue/commit/c083874844ca9f6949f749b2b004eac7f8f7aedf

Thanks very much!
So helpful

It worked!


Ion-tab breaks the behavior of ion-segment. Old bug occurring again, now on 3.1.1 version

Ionic version:  (check one with "x")
[ ] 1.x (For Ionic 1.x issues, please use https://github.com/driftyco/ionic-v1)
[ ] 2.x
[X] 3.x
I'm submitting a ...  (check one with "x")
[X] bug report
[ ] feature request
[ ] support request => Please do not submit support requests here, use one of these channels: https://forum.ionicframework.com/ or http://ionicworldwide.herokuapp.com/
Current behavior:
In an ionic's tabs based app, if we click in a tab button it breaks the behavior of ion-segment.
Expected behavior:
Normal switches in the ion-segment elements of the screen after touch any tab.
Other information:
The solution for this error was released in (2017-01-11) by Ionic Team closing the follow issues: #9392 #9811.
All topics about it was closed after this release but seems the error is occurring again in the version 3.1.1.
I am using 3.1.1 and facing exaclty the same problems with ion-tabs breaking the behavior of ion-segment like the issues reported before.
Is this error returned from the ashes just for me?
Ionic info:
Cordova CLI: 7.0.0
Ionic Framework Version: 3.3.0
Ionic CLI Version: 2.2.1
Ionic App Lib Version: 2.2.0
Ionic App Scripts Version: 1.3.6
ios-deploy version: Not installed
ios-sim version: Not installed
OS: Linux 4.4
Node Version: v6.9.3
Xcode version: Not installed

Hey guys, here is a plunker related to the old issues. Im facing the same problem now.
(http://plnkr.co/edit/QB4vcaQuIhKLYXSgyGvl?p=preview)
Steps to replicate:
Load above Plunker.
Tap "Go to Tabs"
Observe the segment switches at the top (currently you can switch between "Camera" and "Bookmark").
Tap the log out tab (bottom-right).
Tap "No".
Repeat step (3) and observe no switch.

Thanks for opening an issue with us @lpsantana . Does this happen on the latest release of ionic ?

Unfortunately the same behavior occur in the latest released yesterday from you guys ;(
Anyone else?

@lpsantana I've ran into the same issue. I load some data in ionViewWillEnter() but it does not update when changing tabs by this.tabs.select(3).
Any idea of a fix @jgw96?


Spotify access token expiration

Home Assistant release (hass --version): 0.47.1
Python release (python3 --version): 3.6.1
Component/platform: Spotify
Description of problem:
Spotify is not refreshing access token (not sure what exact lifetime of token is). Components stops updating
2017-07-01 01:23:28 WARNING (MainThread) [homeassistant.components.media_player] Updating spotify media_player took longer than the scheduled update interval 0:00:30

Any interaction with component produces exception
Expected:
Refresh token used
Problem-relevant configuration.yaml entries and steps to reproduce:
- platform: spotify
  name: Spotify
  client_id: <id>
  client_secret: <secret>

Configure Spotify, launch single song
Wait for token expiration (need to clarify)

Traceback (if applicable):
2017-07-01 01:23:32 WARNING (SyncWorker_7) [requests.packages.urllib3.connectionpool] Failed to parse headers (url=http://<IP_ADDRESS>:2971/camera/stream): [StartBoundaryNotFoundDefect(), MultipartInvariantViolationDefect()], unparsed data: ''
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/requests/packages/urllib3/connectionpool.py", line 398, in _make_request
    assert_header_parsing(httplib_response.msg)
  File "/usr/lib/python3.6/site-packages/requests/packages/urllib3/util/response.py", line 66, in assert_header_parsing
    raise HeaderParsingError(defects=defects, unparsed_data=unparsed_data)
requests.packages.urllib3.exceptions.HeaderParsingError: [StartBoundaryNotFoundDefect(), MultipartInvariantViolationDefect()], unparsed data: ''
2017-07-01 01:23:32 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/spotipy/client.py", line 121, in _internal_call
    r.raise_for_status()
  File "/usr/lib/python3.6/site-packages/requests/models.py", line 928, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 401 Client Error: Unauthorized for url: https://api.spotify.com/v1/me/player/play

During handling of the above exception, another exception occurred:

...skip

  File "/usr/lib/python3.6/site-packages/spotipy/client.py", line 126, in _internal_call
    headers=r.headers)
spotipy.client.SpotifyException: http status: 401, code:-1 - https://api.spotify.com/v1/me/player/play:
 The access token expired

Additional info:
Restart helps

Just ran into this myself. Restarting helped. Is there anyone who works on the media player component who can take a look?

Home Assistant release (hass --version): 0.58.1
Python release (python3 --version): 3.5.3
Component/platform: Spotify
Spotify failed to update, token expired.
08:53 components/media_player/spotify.py (WARNING)
It's still a problem.


Some CORR coefficients in the output of plot_kl_surrogate_fit() function are not correct.

Here is an example output of plot_kl_surrogate_fit() function (from ensembleperturbation.plotting.surrogate)

The last four modes should have CORR of 0.0 instead of 1.0!
Looks like there is an issue with the get_validation_statistics()

@SorooshMani-NOAA @WPringle I found the bug. Please see line 30 in surrogate.py .
if numpy.isnan(corr.values):
    corr.values = 1.0  # 0/0: perfect correlation
return corr

Replacing 1.0 with 0.0 will resolve this error, but it might not be correct all the times (i.e. when both obs. and sim. are zero). How about returning NaN or Not Available instead of a number (1.0 or 0.0)?

Can't we just add another condition when it's nan to distinguish perfect vs no-relation?

@SorooshMani-NOAA good point. how about something like this to differentiate perfect vs non-relation:
if (PDOD==0) & (PD2==0) & (OD2==0):
    corr.values = 1.0  # 0/0: perfect correlation
elif (PD2==0) or (OD2==0):
    corr.values = 0.0  # No./0: no-correlation

I think it makes sense, but wait for @WPringle to confirm if you're not sure

I think it looks good, as long as result gives you what we think it should be.

@SorooshMani-NOAA I'm getting permission denied for pushing my changes to the remote (git push origin fix_cor_in_plot):
ERROR: Permission to noaa-ocs-modeling/EnsemblePerturbation.git denied to FariborzDaneshvar-NOAA.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists.
```
I pushed changes from the same directory on NHC_COLAB_2 to the remote before! .git/config file also has pushurl as you noted before. What's your take on this? thanks

I also could not push to remote. You need just push to your fork and the to get into the main repository you need to do a pull request.

@FariborzDaneshvar-NOAA I added you to the repo

PR: https://github.com/noaa-ocs-modeling/EnsemblePerturbation/pull/141


Update dds.py and preprocessing.py with MRN normalization

Context
This code introduces alternative normalization methods to the preprocessing.py step for generation of normalization factors. I am not an expert in this codebase but I'm trying to lay the groundwork for further expansion of normalization methods to expand use of this package to a variety of datasets and applications. I am hoping the major contributors of PyDESeq2 will make improvements to this code to help lay a clear path for others share their normalization own methods. I will try to implement feedback modifications as time permits.
The work of this PR serves to expand the available options for calculating normalization factors. The current methods of normalization used by DESeq2 and PyDESeq2 are called by different names across academic literature and reference documentation, but for practicality I will refer to this normalization method as "Relative Log Expression" (RLE) as described in In Papyro Comparison of TMM (edgeR), RLE (DESeq2), and MRN Normalization Methods for a Simple Two-Conditions-Without-Replicates RNA-Seq Experimental Design (Maza et al., 2016). The same paper also references an alternative normalization method called “Median Ratio Normalization” (MRN) described in Maza et al. (2013), which is initially provided as an R-script by the author, and which has been converted to python here-in by Zachary Friar with his permission. The current implementation allows the user to use fit_size_factors() to calculate normalization factors, but has modified these methods to include MRN normalization as a method for calculating normalization factors given the iterative normalization methods do not trigger. While it's best to refer to the paper, a benefit of MRN is a lower rate of false positives for DE analysis.

Reference Issue or PRs

To my knowledge there is not an applicable PR to reference.
What does your PR implement? Be specific.
This PR expands the normalization options provided by PyDESeq2 and sets the groundwork for future expansion of preprocessing.py to create a library of normalization methods.
Future Work
We could potentially also use the TMM normalization logic from the conorm package to perform TMM normalization that is comparable to the methods of EdgeR. I should mention though that certain parts of the conorm package such as the methods to calculate cpm should not be used because they are incomplete. Additionally, the TMM normalization method has poorer performance than RLE or MRN as shown in "FIGURE 1. NORMALIZATION FACTORS FOR THE FRUIT SET RNA-SEQ DATA DEPENDING ON CORRESPONDING LIBRARY SIZES" in Maza et al. 2016. I provide this because there are times where it may be beneficial to create results with methods that closely mirror the methodology of the EdgeR package.

import conorm
import pandas

def cpm_from_tmm(tmm_df):
    """
    Calculates counts per million (CPM) from TMM normalized data.

    tmm_df : pandas.DataFrame
        TMM normalized count data (rows are genes, columns are samples).
    """
    # Calculate the total count for each sample
    total_counts = tmm_df.sum(axis=0)
    # Divide each sample's count by the total count and multiply by 1 million
    cpm_data = (tmm_df / total_counts) * 1e6
    return cpm_data

def apply_tmm_normalization(counts_dataframe, cpm = False):
  """
  args:
  counts_dataframe - a pandas dataframe
  cpm - a boolean value determining whether the data is converted to parts per million
  """
  # here we clean up the index name to make sure it matches the conditions_df
  counts_dataframe.index.name = "sample_id" # can we delete?

  #perform TMM normalization
  tmm_df = conorm.tmm(counts_dataframe)

  if cpm == True:
    cpm_df = cpm_from_tmm(tmm_df)
    cpm_df = cpm_df.round().astype(int)
    output_path = "./output_files/tmm-cpm_normalized_counts.csv"
    cpm_df.to_csv(output_path, index=True)
    return cpm_df
  else:
    tmm_df = tmm_df.round().astype(int)
    output_path = "./output_files/tmm_normalized_counts.csv"
    tmm_df.to_csv(output_path, index=True)
    return tmm_df

I refactored the MRN normalization function, and I wanted to ask if you agree it accomplishes the same thing.
I also created some test cases, which you can check.
Something I wanted to bring up is that without some MRN normalization data generated in R, we have no point of reference of whether what we are doing is comparable to the author's original methods. I wanted to see if you might be able to generate some data so I can add this to my tests and we can confirm outcomes match.


expiration policies should work with matrix deployments

Codecov Report

Merging #24 into master will increase coverage by 0.5%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master      #24     +/-   ##
=========================================
+ Coverage   62.13%   62.64%   +0.5%
=========================================
  Files         126      126
  Lines        4424     4385     -39
  Branches      111      110      -1
=========================================
- Hits         2749     2747      -2
+ Misses       1675     1638     -37

Impacted Files
Coverage Δ

core/src/main/scala/cleanup/ExpirationPolicy.scala
88.33% <100%> (ø)
:arrow_up:

core/src/main/scala/Datacenter.scala
84.21% <0%> (-3.51%)
: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 32571f2...293781f. Read the comment docs.


h264qsv codec, results in error: Unrecognized option 'look_ahead'.

Hello!
Recently aquired a NUC, model: NUC5i5RYH
It has a 5th gen i5-5250u with intel hd graphics 6000.
Trying to get it to work with QSV, so i set h264qsv in the video-codec options. When i try to do a manual run on sommething thats not already h264, i get the following error:
Unrecognized option 'look_ahead'.
Error splitting the argument list: Option not found
Does the processor not support quick sync or am i missing some setting to get this to work?
OS: Ubuntu 16.04 LTS
FFMPEG version: 3.4.1
I have the following settings in autoProcess:
[MP4] tag-language = en download-artwork = false download-subs = True delete_original = True use-qsv-decoder-with-encoder = True audio-language = eng,swe output_format = mp4 ffprobe = /usr/bin/ffprobe move_to = output_directory = post-process = False threads = ios-first-track-only = False max-audio-channels = subtitle-codec = mov_text audio-codec = ac3 audio-copy-original = True pix-fmt = subtitle-default-language = eng tagfile = True video-bitrate = audio-filter = relocate_moov = True embed-subs = True ffmpeg = /usr/bin/ffmpeg h264-max-level = fullpathguess = False sub-providers = addic7ed, podnapisi, thesubdb, opensubtitles convert-mp4 = False subtitle-encoding = subtitle-language = eng,swe audio-default-language = eng output_extension = mp4 ios-audio = True video-max-width = audio-channel-bitrate = 256 permissions = 777 aac_adtstoasc = False ios-audio-filter = copy_to = video-codec = h264qsv, h264, x264 preopts = postopts = enable_dxva2_gpu_decode = False ios-move-last = False video-crf = embed-only-internal-subs = False use-hevc-qsv-decoder = False

What version/build of FFMPEG are you using? Did you compile yourself? What OS?
From: izeen
Sent: Thursday, December 28, 2017 3:54 PM
To: mdhiggins/sickbeard_mp4_automator
Cc: Subscribed
Subject: [mdhiggins/sickbeard_mp4_automator] h264qsv codec, results in error:Unrecognized option 'look_ahead'. (#840)
Hello!
Recently aquired a NUC, model: NUC5i5RYH
It has a 5th gen i5-5250u with intel hd graphics 6000.
Trying to get it to work with QSV, so i set h264qsv in the video-codec options. When i try to do a manual run on sommething thats not already h264, i get the following error:
Unrecognized option 'look_ahead'.
Error splitting the argument list: Option not found
Does the processor not support quick sync or am i missing some setting to get this to work?
OS: Ubuntu 16.04 LTS
FFMPEG version: 3.4.1
I have the following settings in autoProcess:
[MP4] tag-language = en download-artwork = false download-subs = True delete_original = True use-qsv-decoder-with-encoder = True audio-language = eng,swe output_format = mp4 ffprobe = /usr/bin/ffprobe move_to = output_directory = post-process = False threads = ios-first-track-only = False max-audio-channels = subtitle-codec = mov_text audio-codec = ac3 audio-copy-original = True pix-fmt = subtitle-default-language = eng tagfile = True video-bitrate = audio-filter = relocate_moov = True embed-subs = True ffmpeg = /usr/bin/ffmpeg h264-max-level = fullpathguess = False sub-providers = addic7ed, podnapisi, thesubdb, opensubtitles convert-mp4 = False subtitle-encoding = subtitle-language = eng,swe audio-default-language = eng output_extension = mp4 ios-audio = True video-max-width = audio-channel-bitrate = 256 permissions = 777 aac_adtstoasc = False ios-audio-filter = copy_to = video-codec = h264qsv, h264, x264 preopts = postopts = enable_dxva2_gpu_decode = False ios-move-last = False video-crf = embed-only-internal-subs = False use-hevc-qsv-decoder = False
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Did not compile my self,
Im on ubuntu server 16.04  LTS,
Tried with ffmpeg from the official ubuntu PPAs and now im using version: ffmpeg version 3.4.1
``

I would try downloading the binary from here instead of using the repo one and see if that fixes your error
https://www.ffmpeg.org/download.html
From: izeen
Sent: Thursday, December 28, 2017 4:20 PM
To: mdhiggins/sickbeard_mp4_automator
Cc: Michael Higgins; Comment
Subject: Re: [mdhiggins/sickbeard_mp4_automator] h264qsv codec, results inerror: Unrecognized option 'look_ahead'. (#840)
Did not compile my self,
Im on ubuntu server 16.04 LTS,
Tried with ffmpeg from the official ubuntu PPAs and now im using version: ffmpeg version 3.4.1
``
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

potentially related to this pull request - https://github.com/mdhiggins/sickbeard_mp4_automator/pull/822

Merged that

I removed ffmpeg and compiled from this guide: https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu followed all the steps.
Pulled the changes you commited yest, still same error:
Unrecognized option 'look_ahead'.
Error splitting the argument list: Option not found
If i look at #822  its regarding h265 and the changes to look_ahead in avcodecs.py was for that specific codec, i tried to remove the same block of code for h264_qsv but then i just get: Unknown encoder 'h264_qsv'

Ah, ok. I didn't realize this, but on linux you have to use VAAPI - https://trac.ffmpeg.org/wiki/Hardware/VAAPI
This pull request might be worth looking into: https://github.com/mdhiggins/sickbeard_mp4_automator/pull/690

Aaaaah, so i should use this then in the video-codec options: h264vaapi ?

It will not currently work without that pull request. I haven't tested the pull request as I don't have a qsv capable computer.

Did the changes manually mentioned in #690
Works nicely, watching with intel_gpu_top and can see it chugging along. Great stuff!

Pushed an updated with the improved VAAPI support
Level should be automatically multiplied by 10 when VAAPI is chosen
Give it a shot and let me know if its working

its working great! can see the CPU offloaded and GPU getting to work. Thanks alot for your quick commits :)


GraphML file importer

This plugin can import data coming from a GraphML file (http://graphml.graphdrawing.org/) generated by Python software using networkx graph.
It requires the properties with keys 'x', 'y', 'z' and 'frame' to be present and can handle supplemental properties that are imported as Mastodon features. The features values are saved and restored along with the data.
A simple dialog allows specifying from where the take pixel size; apparently the x, y, z position are saved in pixel coordinates. Right now the radius or covariance matrix for the ellipsoid are not imported. The user must specify a radius.

Tested with the new dev branch. Ready for beta 27.


Get it working on Gitpod

The prof wants us to use gitpod so we will have to find a way to get this whole project running on there somehow.

It seems to be working on Gitpod now. The Readme also already contains some minimal info on how to get it running on gitpod. Before I close this issue, I want to make sure that I'm not the only one who gets it running on gitpod and that the current configurations are enough.

It might also be beneficial for issue #12 to check if running child-processes works on gitpod

Works 👍


Prevent installing on systems that are not x86_64

We don't have any checks for x86_64. We should have our wheels restrict to only the platforms that we support. Ideally with names like this: numpy-1.13.3-cp35-cp35m-manylinux1_x86_64.whl

The pypi files for 4.0 permit more than we support. Even if we fix this for say 4.0.1, users on unsupported platforms would still get 4.0 if they simply did pip install turicreate. Of course, we never want to change 4.0, but we might be able to consider a name change of the files for 4.0 that simply will prevent users on unsupported platforms to get broken installs.

The work here is twofold:

Build a wheel, instead of an egg, for Linux.
Remove the 4.0 egg so that users on unsupported platforms don't get that one on pip install.

Open question: should we backport this fix to 4.0 and publish a 4.0 wheel for Linux? Not sure if this is even possible on PyPI.

I think you can remove old versions, but you can't re-upload them (maybe twine can circumvent, but I'm not sure). It looks we will probably need to pull version 4.0 from pypi at some point in the future, or issues where users try to install on an unsupported platform will never be fixed:

#121 Windows user outside WSL
#22 macOS 10.11
non-x86_64: I haven't seen a report of this yet, but theoretically this would not fail gracefully

@gustavla - twine does not allow you to circumvent that.

@TobyRoseman Good to know (I read some vague reference at https://github.com/pypa/packaging-problems/issues/74 to suggest otherwise, but reading it again I think you are right). We'll probably have to pull it at some point in time then.

@gustavla @TobyRoseman Another option would be to publish a newer version of a pure Python egg named turicreate, along with our future releases, but instead of containing a non-working version of Turi Create, it could error out on setup with a user-facing message re: platform/version support?

4.2 egg with error message on install has been published to https://pypi.python.org/pypi/turicreate/4.2


Update package.json

I have added a new condition to judge inline in inline-source, so I suggest that update inline-source to 4.4.0. Thank you.

@yedaodao thanks for the PR. I've upgraded to<EMAIL_ADDRESS>and made new release on NPM.


Added Norwegian (NO) holidays.

Ciao Mario!
After completing the Mastering DAX Video Course I was inspired to add the Norwegian holidays to the DAX Calendar template.
You can find these appended at the bottom of the datatable in the code.
All the best,
Marcus

Thanks for adding to the template Marco! 😊👍🏼


11/20 Homework M11209302/p477d343

Shodan : Check port 502 modbus, there are some ics over the internet in india and us
CloudStorageFinder: Find a media cloudspace, right page is the web content, in include some file name.
Firepit/Splint: Same as textbook.

Checks

[ ] Your YAML file has required fields as listed in Specs
[ ] All checks have passed yaml-lint passed
[ ] You agree to contribute your work under MIT license

firepit demo missing firepit, only splint


Fix a few misc typos

I'm perusing through the codebase trying to get an idea where I might be able to meaningfully contribute to this wonderful framework that you guys have made and that I've been using extensively. Noticed a few typos along the way.
@smahood @mike-thompson-day8 @danielcompton have you guys given spec integration any thoughts as of yet?

Hey, this didn't really apply very well when I tried to merge it, so I fixed the spelling mistakes manually. Thanks!
re: spec integration, I think we're waiting for spec itself to settle down, as both best practices and implementation seem to be in a bit of flux.


ajout quizz lsf page

page de quizzLSF

Codecov Report

Merging #6 (fe84c2f) into main (67de2ff) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #6   +/-   ##
=======================================
  Coverage   77.22%   77.22%
=======================================
  Files          12       12
  Lines         101      101
  Branches       10       10
=======================================
  Hits           78       78
  Misses         16       16
  Partials        7        7

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Chatto failing in Swift source compatibility suite due to obsolete API usage

https://bugs.swift.org/browse/SR-5500
For example:
/Users/buildnode/jenkins/workspace-private/swift-master-source-compat-suite/project_cache/Chatto/Chatto/Source/ChatController/Collaborators/AccessoryViewRevealer.swift:59:29: error: 'addGestureRecognizer' has been renamed to 'add(_:)'
self.collectionView.addGestureRecognizer(self.panRecognizer)
^~~~~~~~~~~~~~~~~~~~
add

Please do not act on this yet; we're pretty sure it's our bug.

@jrose-apple, ok. Please, ping me when it become clear

The failures were transient and are no longer occurring.


fix(volume) Disable the expand operation when the status of the rwx v…

https://github.com/longhorn/longhorn/issues/2389
Signed-off-by: Siye Wang<EMAIL_ADDRESS>

Seems that their is way to much state checking in there right now?
Can we just use disabled: selected.state != 'detached'


Fix inverted condition when unwrapping lightmap

Condition checking for the presence of normals was inverted, it now matches the same check in lightmap_gi.cpp

Fixes: #84373

Thanks!

Thank you!


feat: add option to configure width and border style

This PR adds 2 new options to set the max width of hover window and its border style.

LGTM:) Thanks.

LGTM:) Thanks.

Bug with max_hover_widht it will hung neovim.

Bug with max_hover_widht it will hung neovim.

Ah, my bad. I didn't test if it has 0 value.

Ah, my bad. I didn't test if it has 0 value.

Ok I have a fix for that, turns out it _make_floating_popup_size is using max_width that we provided. The solution is just renaming max_width in handler.lua to max_hover_width. Do you want me to make a PR for this?

Ok I have a fix for that, turns out it _make_floating_popup_size is using max_width that we provided. The solution is just renaming max_width in handler.lua to max_hover_width. Do you want me to make a PR for this?


ModuleNotFoundError: No module named 'outlines.text'

Describe the bug
ModuleNotFoundError when importing client:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/cecil/repos/anarchy/LLM-VM/src/llm_vm/client.py", line 6, in <module>
    from llm_vm.completion.optimize import LocalOptimizer
  File "/Users/cecil/repos/anarchy/LLM-VM/src/llm_vm/completion/optimize.py", line 14, in <module>
    from llm_vm.guided_completion import Completion
  File "/Users/cecil/repos/anarchy/LLM-VM/src/llm_vm/guided_completion.py", line 2, in <module>
    import outlines.text.generate as generate
ModuleNotFoundError: No module named 'outlines.text'

To Reproduce
Steps to reproduce the behavior:

Install LLM-VM
Open python3 in shell
Import client using from llm_vm.client import Client

Expected behavior
Client imports successfully.
Desktop (please complete the following information):

OS: macOS Monterey 12.7.1

I am facing the same issue while running the project for the first time. The linked PR is not the solution.
We need to change line 2 in guided_completions.py from: import outlines.text.generate as generate to import outlines.generate as generate

I am facing the same issue while running the project for the first time. The linked PR is not the solution.
We need to change line 2 in guided_completions.py from: import outlines.text.generate as generate to import outlines.generate as generate

Can I ask why the linked PR is not the solution?

The PR changes the import statement to import outlines.generate.text. That is not correct. It should be import outlines.generate.


Is there a way to delete a tenant?

Hi, i'm needing a functionality to delete a tenant, is there a way to do it or a new functionality is needed?

On whatever you've set your TENANT_MODEL (e.g. TENANT_MODEL = "tenant_app.Customer") to, add the following to your model:
class Customer(TenantMixin):
    name = models.CharField(max_length=100)
    created_on = models.DateTimeField('created on',default=timezone.now, blank=True)
    auto_drop_schema = True
    auto_create_schema = True

You can now delete tenants by just deleting the entry via the Django ORM.

@flxfxp Thank you dude!!!!

You're welcome, please close :)

A help page is required for this please don't close

I thought this was in the original tenant-schemas docu?


Modular decode: reduce tree size limit by a factor of 16

As discussed in and fixes #528
The reduction applies to both the per-pixel limit and the overall limit, which means the maximum memory consumption of a frame's decode tree will be ~0.3MB (previously ~5.2GB).

I was literally just making the exact same pull request :)
Note: currently in the amendment to 18181-1 that defines the (single) profile and levels, we have 1024 + width × height × nb_channels as the limit on tree size, so we'll need to adjust the limit there too.


docu(dev): add dev docu

Issue
As a developer i want to know how to work on this repo.
Description
This commit adds a DEV.md containing information for developers.

Hey @DaAnda97! We should make sure that the "how to use miranum" answer gets described at the very beginning of the readme. I would add it to the overall readme similar to how it is done in spring-zeebe for instance:
https://github.com/camunda-community-hub/spring-zeebe