Allow "artifact dependencies" on bin, cdylib, and staticlib crates

Rendered
This RFC was co-authored by @jyn514 and @joshtriplett.
See https://github.com/rust-lang/cargo/issues/4316 and https://github.com/rust-lang/cargo/pull/7804 for previous discussions of this. Also discussed on Zulip.
Some motivating use cases (taken from the RFC):

Testing the behavior of a binary.
Running a binary that depends on another.
Building tools needed at build time.
Building and embedding binaries for another target, such as firmware or WebAssembly.
Building and embedding a shared library for use at runtime.

Awesome! Additional usecase: building wasm32-wasi executable that is then loaded by an example binary that is a simple demo webserver, like is used in power-cpu-sim (hosted version, in case you like cpu design).

@alexcrichton, I responded inline to several of your comments, but I also wanted to respond to your top-level comment:

Thanks for writing this up! I feel like a feature along these lines is good to add to Cargo, but I do have some concerns about the motivation and some of the specifics below.
One concern I have is related to depending on binaries. I'm personally not convinced that what's proposed in this RFC is necessary or necessarily something that Cargo needs. One of the major drawback I see of "simply depend on a binary" is that running binaries is often quite involved and nontrivial. Fiddling with Command, having good error reporting, and dealing with subprocess I/O is not always trivial and if a widely-used package simply provides a binary it means that all consumers are duplicating all this logic for handling the subprocess management. The alternative, however, having a library, provides an author an opportunity to make a much easier to use Rust API, document it, provide examples, etc. An author providing the binary would still be able to build the binary itself in the build script and reference it from the crate that runs the binary.

Some crates may want to wrap the usage of the binary in an API, but that isn't always the case. That assumes your primary use case is to invoke the binary in some standardized way from Rust code via Command or similar. You may, instead, want to:

Invoke a different binary (such as make or ./configure or ./do-build.sh) that expects to find the binary you depend on via the $PATH.
Embed the binary, rather than running it: firmware, plugins, etc.
Run the binary in some non-standard way, for which wrapping it in an API would be non-trivial.
Have multiple different crates providing different APIs on top of the same binary, but only one crate with the knowledge of how to build and supply that binary.

An additional concern I would have about binaries is that it sort of feels like we're pushing Cargo towards an entire package manager. The example given in the RFC is related to cmake, but as the maintainer of the cmake crate I would not want to be responsible for shipping cmake's source code and building it if it's not already in the environment (or somehow handling "the environment is too old a version from what you requested). In general I can't ever really see myself managing build tools like that, especially for ubiquitous ones like make, cmake, clang, etc.

We can certainly change the example to a more hypothetical build tool, if you'd prefer. I'd like to talk to you at more length about the idea of building cmake from source, though. (I'd expect to put that in something like a cmake-sys or cmake-bin crate, rather than directly in the cmake crate; cmake could just have a vendored feature or similar, to optionally make use of that.) This would help many Windows users, for which it'd be substantially easier than installing cmake on the host system.
For something like clang, I'd love to provide a sysroot crate that supplies clang and related binaries from precisely the version of LLVM used to build Rust, which would make things like cross-language LTO trivial.
This would be even more helpful for less ubiquitous build tools that not everyone already has, particularly in environments where installing tools is not trivial.

Overall I feel that the most useful part of this RFC is being able to build multiple artifacts for possibly different targets, but I'm not sure that it's best served with a depencency-level directive rather than a package-level directive (commented more below). Otherwise I can't personally think of a concrete use case where this would be an improvement to a build that's otherwise quite complicated to do today (e.g. would presumably be multiple cargo invocations driven by some sort of other build system)

Several of the use cases proposed in the RFC are specifically cases where today someone would have to drive Cargo with some other build system, and this RFC would allow just using cargo build instead.

For something like clang, I'd love to provide a sysroot crate that supplies clang and related binaries from precisely the version of LLVM used to build Rust, which would make things like cross-language LTO trivial.

That's exactly what I need for power-cpu-sim, and I have to take up half the readme with instructions for how to install clang-11 using LLVM's APT repos. Replacing that all with just cargo build or maybe rustup component add would be awesome!

I submitted a PR at https://github.com/jyn514/rfcs/pull/3 to expand the alternatives section. (I don't think the alternative is something we should consider, but it's worth documenting.)

I think that's a really good point about a binary-calling-a-binary as well as something like *-bin crates (ala cmake-bin). That makes a lot of sense to me, thanks for clarifying! I agree that it'd make sense for the cmake crate (and other build-system-like crates) to have an optional off-by-default dependency on "vendor the build support".
One question I would have though is how is it expected to hook up a foreign binary into Cargo? For example it looks like the env vars specified to downstream crates are based on Cargo-based-[[bin]] targets, so how would binaries produced  by the build script (e.g. cmake) get specified?
(also FWIW I don't mind cmake as an example, I just didn't know what was expected of the literal cmake crate if this RFC were to get merged)
I do feel like this is a bit pie-in-the-sky for tools like cmake/clang/gcc though given that their build times is so long and ubiquity is so high. For smaller binaries and/or less-widely-known ones, however, I could imagine this being quite useful.

Several of the use cases proposed in the RFC are specifically cases where today someone would have to drive Cargo with some other build system, and this RFC would allow just using cargo build instead.

I think this makes sense as motivation, but after reading the RFC I was left with the impression that this is just a small feature in Cargo which may not be able to supplant other wrapper build systems. That being said this seems like a necessary step in any case. I'm sure this will unlock some use cases but it seems like it will only make progress on others (which is of course fine!).

One concern about this RFC with targets I'm realizing now is that "it's just cargo build" isn't quite right. If a crate has a variety of targets specified it's actually "run this set of rustup target add commands" (which is project-specific and perhaps not easily discoverable) and then "run cargo build". In terms of ease-of-use that may be a relatively high-priority item to tackle around this RFC as well?

If a crate has a variety of targets specified it's actually "run this set of rustup target add commands" (which is project-specific and perhaps not easily discoverable) and then "run cargo build".

Those are targets that would already be built anyway, right? Like if cargo is building from host to target, it needs both standard libraries anyway (one for build scripts and one for the library being cross-compiler). In that case I don't think that needs to be addressed in the RFC - the only time this would break is when cargo build would already break.

My point is that one of the major motivations it seems for this RFC is "let's get more projects simply doing cargo build". Having to rustup target add a bunch of targets makes me feel that it's not quite achieving that goal, especially if it's encouraged to add target-specific builds to dependencies.

With the new rust-toolchain format it is possible to specify which targets should be installed automatically.

I would like to add my use-case that makes this desirable, in case it helps folks working in it:
Overview
I have a workspace project with multiple packages. The two important ones are:

flowc - which is a lib and a binary
flowstdlib - which is a library of routines, to be built using flowc

flowc is a kind of compiler that I build as part of the project.
flowstdlib has a build script, that uses the flowc built binary to build that package, so I need the flowc compiler binary to be built when flowstdlib is to be built.
Current Situation
In cargo.toml of flowstdlib I define flowc as a build dependency:
[build-dependencies]
flowc = {path = "../flowc", version = "0.31.0" }`

The build compiles multiple packages at the same time in parallel:
   Compiling flowstdlib v0.31.0 (/Users/andrew/workspace/flow/flowstdlib)
   Compiling flowsamples v0.31.1 (/Users/andrew/workspace/flow/samples)
warning: Could not find `flowc` in $PATH or `target/debug`, so cannot build flowstdlib
error: failed to run custom build command for `flowsamples v0.31.1 (/Users/andrew/workspace/flow/samples)`

and the flowstdlib build fails as the flowc binary is not built yet.
Since the build continues and eventually finishes building flowc, if I re-run the build, it will work the second time around (as flowc binary is now found).
Desired State
Have the flowstdlib package build depend on the build of the  the flowc binary having completed.
(without forcing a non-parallel build)

Hi,
I've read the RFC and am very interested in it. I have two use cases for this, both are variants of the use-case "Installing a local command-line tool that is scoped to the project.".

When building WASM modules, I use the lib wasm-bindgen and the binary wasm-bindgen-cli. I want to ensure that both the library and corresponding CLI have the same version for a given project. Without project-local binaries, I need to reinstall my global wasm-bindgen-cli when switching between projects using a different lib version. With this proposal, I could define a dependency in each project and invoke it through build.rs.

Similarly, I want to use the cargo sqlx command provided by sqlx-cli without having to install it globally but having it bound to a project. I hope that a future RFC would enable cargo to load subcommands from the local project, but until then I will be able to use it from the build.rs script.

My point is that one of the major motivations it seems for this RFC is "let's get more projects simply doing cargo build". Having to rustup target add a bunch of targets makes me feel that it's not quite achieving that goal, especially if it's encouraged to add target-specific builds to dependencies.

FWIW I would be ok with removing the target-specific parts of the RFC, or limiting it only to the host or --target. @joshtriplett what do you think?

My point is that one of the major motivations it seems for this RFC is "let's get more projects simply doing cargo build". Having to rustup target add a bunch of targets makes me feel that it's not quite achieving that goal, especially if it's encouraged to add target-specific builds to dependencies.

FWIW I would be ok with removing the target-specific parts of the RFC, or limiting it only to the host or --target.

I think keeping target-specific parts is a major benefit of this rfc.
I'd anticipate cargo and rustup growing to be able to have cargo automatically install missing targets, though, even if that doesn't happen right away, having cargo build work after initial installation of required targets is itself still a major benefit.

@demurgos that's actually an example I'm worried about with this RFC, actually. It seems like it should work for wasm-bindgen but this would not be usable for wasm-bindgen. This RFC isn't intended for postprocessing artifacts, but only processing preexisting artifacts with external tools into the rest of the build. Nothing here would help wasm-bindgen's experience, I  believe.
@jyn514 I'm not saying that the target-specific bits should be removed, what I'm trying to do is point out that this is sort of a half-design in a lot of ways. I think it's solving real problems but it's leaving a lot of other closely related problems unsolved. That's possible and reasonable to do since you don't want to solve anything at once, but at the same time I think it's important to acknowledge what's explicitly not being solved and what pain points will continue to be.

Hey, just wanted to add a use case for artifact dependencies. In rust-gpu we want to be able to build and include SPIR-V shader crates in the main binary which is actually responsible for running them. Currently this implemented in a very hacky way with having a spirv-builder crate which runs cargo inside a build script to build the SPIR-V crate and expose the path to the binary in an environment variable.
This isn't really ideal since there have been a number of issues with calling cargo inside of cargo (from it easily creating directories that are beyond MAX_PATH in Windows and failing to build, to environment variables from the top level cargo build affecting the shader build). It would be so much nicer and simpler if you could say shader = { path = "...", target = "spirv-unknown-unknown" } in your Cargo.toml.

@alexcrichton wrote:

One question I would have though is how is it expected to hook up a foreign binary into Cargo? For example it looks like the env vars specified to downstream crates are based on Cargo-based-[[bin]] targets, so how would binaries produced by the build script (e.g. cmake) get specified?

With the RFC as specified, if you want to produce and depend on a bin artifact, it needs to be a Cargo [[bin]] target. I can think of many use cases for other possibilities, such as passing through a binary produced by one of your dependencies, or building a binary in your build script. If you're open to the possibility, I'd love to have a way to declare a [[bin]] target that's produced by build.rs.
Perhaps something like this?
[[bin]]
name = "foo"
manual = true

A [[bin]] target with manual=true will not have any logic emitted by Cargo; Cargo will just give build.rs an environment variable specifying a directory to put it in, and then error if it doesn't get built by build.rs.
Thoughts?

I do feel like this is a bit pie-in-the-sky for tools like cmake/clang/gcc though given that their build times is so long and ubiquity is so high. For smaller binaries and/or less-widely-known ones, however, I could imagine this being quite useful.

It's a tradeoff, just like any vendoring is a tradeoff. Many -sys crates offer the option of building a vendored copy, with the same tradeoff in build time.
Also, if we have the above mechanism for supplying binaries via build.rs, we could consider supplying a sysroot crate (installable via rustup) containing the LLVM we built rustc with.

One concern about this RFC with targets I'm realizing now is that "it's just cargo build" isn't quite right. If a crate has a variety of targets specified it's actually "run this set of rustup target add commands" (which is project-specific and perhaps not easily discoverable) and then "run cargo build". In terms of ease-of-use that may be a relatively high-priority item to tackle around this RFC as well?

As @bjorn3 observed, that's supported in rustup today, by specifying a rust-toolchain toml file that requires the targets you want. I don't think we need to do anything more than that in this RFC. Any further support for that in Cargo would be a different RFC.

@demurgos that's actually an example I'm worried about with this RFC, actually. It seems like it should work for wasm-bindgen but this would not be usable for wasm-bindgen. This RFC isn't intended for postprocessing artifacts, but only processing preexisting artifacts with external tools into the rest of the build. Nothing here would help wasm-bindgen's experience, I believe.

One day I hope we have a way to run Rust code post-build to generate or post-process artifacts. I want to avoid rolling too much into this RFC, though, and I'd expect post-build code to invite more controversy.
In the meantime, though, if we add a mechanism for supplying binaries, people could technically handle this by building a workspace with two crates, one building the un-preprocessed binary, and the other depending on that and wasm-bindgen and emitting a processed binary. That's not ideal, but it works.
@jyn514 wrote:

FWIW I would be ok with removing the target-specific parts of the RFC, or limiting it only to the host or --target. @joshtriplett what do you think?

Given the ability to enable those targets via a rust-toolchain file, and the value of this for cases like wasm, I'd like to keep this in the RFC.
@XAMPPRocky wrote:

Hey, just wanted to add a use case for artifact dependencies. In rust-gpu we want to be able to build and include SPIR-V shader crates in the main binary which is actually responsible for running them. Currently this implemented in a very hacky way with having a spirv-builder crate which runs cargo inside a build script to build the SPIR-V crate and expose the path to the binary in an environment variable.
This isn't really ideal since there have been a number of issues with calling cargo inside of cargo (from it easily creating directories that are beyond MAX_PATH in Windows and failing to build, to environment variables from the top level cargo build affecting the shader build). It would be so much nicer and simpler if you could say shader = { path = "...", target = "spirv-unknown-unknown" } in your Cargo.toml.

That's an awesome example! I've added it to the examples in the RFC.

@joshtriplett wrote:

@alexcrichton wrote:

One question I would have though is how is it expected to hook up a foreign binary into Cargo? For example it looks like the env vars specified to downstream crates are based on Cargo-based-[[bin]] targets, so how would binaries produced by the build script (e.g. cmake) get specified?

With the RFC as specified, if you want to produce and depend on a bin artifact, it needs to be a Cargo [[bin]] target. I can think of many use cases for other possibilities, such as passing through a binary produced by one of your dependencies, or building a binary in your build script. If you're open to the possibility, I'd love to have a way to declare a [[bin]] target that's produced by build.rs.
Perhaps something like this?
[[bin]]
name = "foo"
manual = true

A [[bin]] target with manual=true will not have any logic emitted by Cargo; Cargo will just give build.rs an environment variable specifying a directory to put it in, and then error if it doesn't get built by build.rs.

I've now written this up as a new RFC: https://github.com/rust-lang/rfcs/pull/3035
I think it makes sense to have this as a separate RFC depending on this one, because it seems like a logically separate step, and I don't want to complicate this RFC by substantially expanding its surface area, when this RFC is useful for many of its motivating use cases without that additional feature.

To be clear, I agree that we don't want to pile a whole bunch into one RFC and dilute the discussion, but at the same time I want to make sure that shortcomings are acknowledged and we're not led to believe this is the end-all-be-all RFC for making cargo build the one command you run. Discussion here I believe is helpful to figure out what else is needed and we can figure out what pieces of separable design are, and by considering multiple angles we can see if this feature as-is still makes sense in the grand scheme of things.
I personally think that this feature makes a lot of sense in the grand scheme of things. I do not believe that implementing it in Cargo will result in solving everything in the motivation section as cleanly as desired, but I do believe that it will be very useful to have this implemented.
I'd like to continue to reiterate my concern about targets, however, and how I think it may wish to be solved. I do not agree that rust-toolchain simply solves this issue, primarily because the targets necessary for compilation could come from your dependencies and shouldn't be the responsibility of everyone depending on a crate to create a rust-toolchain file with the same contents. For example of @XAMPPRocky publishes a crate with a shader, every single user of that crate needs to install spirv-unknown-unknown and/or write it in a rust-toolchain file. This isn't really in-line with the spirit of Cargo where the purpose is making dependencies easy. To give this sort of target-specific dependency the "cargo treatment" I believe there needs to be some protocol where Cargo can either invoke rustup to add a target or Cargo learns that the target isn't installed and it can't be installed, leading to a first-class error.

@alexcrichton I absolutely agree that the new rust-toolchain target support isn't a complete solution to that issue. Ideally, I'd like Cargo to be able to install targets and/or build those targets from source (using build-std).
However, I do believe that the new rust-toolchain target support is a sufficiently viable solution that we can separate the idea of first-class Cargo support for installing/building cross-compilation toolchains into a separate RFC. And that separability will keep both this RFC and that separate RFC (which I'd love to see) simpler and easier to evaluate.

The first motivation ("Testing the behavior of a binary"), isn't explained. If we don't know what it means, maybe it should be removed?

Ok, I removed it until we hear a response from @twey.

The second motivation ("Running a binary that depends on another"), uses rustc-perf as an example, but I don't see how this RFC would work for that package. The binaries (collector and rustc-fake?) are in the same package, so you still can't use cargo run.

Oh ... this is really unfortunate, I just realized there's no way to specify dependencies for only a single binary :( there's dev-dependencies and features, but no way to say 'only this binary depends on this library' (or now artifact). I guess adding that would need a further RFC? FWIW I think it would be useful independent of binary artifacts.

The third motivation ("Building tools needed at build time") isn't entirely clear to me (I can't tell how the linked PR is relevant).

That PR was edited significantly since being opened, sorry. The original use case was to use compiletest from an integration test, which broke down because the in-tree version of compiletest is only a binary and not a library. That means either you have to call cargo build from within the integration test, which has overhead if you have many tests, or to split compiletest into a library and a binary even though it only has one user. Docker doesn't help much here - it's more of a pain to use docker than to run cargo build in the compiletest project beforehand.

@ehuss I've updated the RFC to address all of your feedback. Responses to your top-level comment:

* The first motivation ("Testing the behavior of a binary"), isn't explained. If we don't know what it means, maybe it should be removed?

We've now dropped this use case. I added a variant of it, "Building tools needed for testing", with a more detailed explanation.

* The second motivation ("Running a binary that depends on another"), uses rustc-perf as an example, but I don't see how this RFC would work for that package. The binaries (`collector` and `rustc-fake`?) are in the same package, so you still can't use `cargo run`.

I've expanded that item for clarity. It now adds "This RFC would allow splitting the shim into a separate crate, building that crate as an artifact dependency, and invoking it as part of the top-level crate."

* The third motivation ("Building tools needed at build time") isn't entirely clear to me (I can't tell how the linked PR is relevant).

As @jyn514 mentioned, that PR changed in a way to make the citation less useful. I've dropped the link in favor of the explanation directly in the RFC.

There are some rough examples given of things like cmake, but I'm not really convinced that's something I'd want build scripts to try to build. If you really want an appropriate build environment, there are other ways to go about that (vagrant, docker, etc.).

Other examples would include many of the useful WebAssembly tools that have been written in Rust, and many other helper tools that people would otherwise need to pre-install before running cargo build.
The goal of this RFC isn't to suggest that people should always build such tools from source (though there are use cases for sometimes doing so). There's value in being able to build tools from source, and ensure the versions and dependencies and features of those tools are the same as those in the rest of your crate's dependency tree. There are also many less common tools, which the vast majority of people will not already have installed.
This RFC would make it so that most of the time, cargo build or cargo install should Just Work, without having to wrap it in some other build script, or provide a raft of instructions in the README to run before you can invoke cargo.

* I feel like the concern about the `type` field conflating artifacts and linked libraries hasn't been really addressed.

I've now addressed this. Depending on artifacts and a Rust library from the same crate now uses a separate lib = true, rather than putting "lib" and "bin"/"cdylib" into the same list.

  * And, speaking of `type`, I'm not sure if it's necessary to have two fields (type/bin), perhaps those could be combined?  Maybe something like `"bin:foo"` to specifying the `foo` binary.

This seems like a great idea. My initial reaction to it was somewhat negative, based on experiences with feature flags and symbol availability, and the fact that binaries can have nearly arbitrary names with various characters. But that doesn't prevent a fixed prefix bin:, followed by a binary name. I've switched the RFC over to use this syntax, and documented the previous syntax and another possible syntax in the alternatives section.

  * And a side note, I find `type` to be a pretty vague word, and doesn't intuitively tie with "cargo target". I'm not sure what else to call it. Swift calls it a "product". "Artifact" is also an option.

Now that I've split out "lib", I agree. I've renamed this to artifact.

* This doesn't mention where in the target directory these files will go. That may be an implementation concern, but I assume it is buried somewhere using hashed directory names?

I've added a proposal for this at the end of the reference-level explanation.

* This is not a requirement at all, but it usually gives me a much greater sense of ease to see the Prior Art section talk about how other tools similar to Cargo handle this (for example, Swift's "product" dependencies I mentioned above).

Thanks for the pointer; I added a reference to Swift's product dependencies.

* Some of the discussion above mentioned clang, but isn't that something that would better be served as a rustup component?

I absolutely expect it to be a separate rustup component, especially given its likely size. However, I hope that component will provide not just the binaries and libraries, but also a sysroot crate suitable for use in dependencies that supplies those binaries and libraries. That will make it easier not just to build software with clang, but to build things atop libclang and libLLVM (e.g. a code generator or binding generator).

@ehuss @alexcrichton Has this addressed all of your outstanding concerns?

I posted a question yesterday at https://github.com/rust-lang/rfcs/pull/3028#discussion_r546934140.

@ehuss I missed that, thank you. I've now addressed that, and added some corresponding language to the RFC.

I would just like to ask for a small clarification. Does "Building and embedding a shared library for use at runtime" include uses such as https://github.com/rust-lang/cargo/issues/9016, where the library isn't embedded in the final executable, but linked to at runtime?

@LunarLambda You could use this to produce a shared library and link to it. This RFC doesn't cover making that library available at runtime, so you'd still need to handle that yourself (or have your users do so).

@LunarLambda You could use this to produce a shared library and link to it. This RFC doesn't cover making that library available at runtime, so you'd still need to handle that yourself (or have your users do so).

I see. The linking part isn't the issue for me, it's finding the library at
runtime. Thank you for clarifying
On Sat, 2 Jan 2021, 23:11 Josh Triplett<EMAIL_ADDRESS>wrote:

@LunarLambda https://github.com/LunarLambda You could use this to
produce a shared library and link to it, though that isn't the primary use
case. This RFC doesn't cover making that library available at runtime, so
you'd still need to handle that yourself (or have your users do so).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rfcs/pull/3028#issuecomment-753536272, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AJI55IQNTX53O4UWVBGYX3LSX6KXJANCNFSM4UIHGRJA
.

I see. The linking part isn't the issue for me, it's finding the library at
runtime. Thank you for clarifying
On Sat, 2 Jan 2021, 23:11 Josh Triplett<EMAIL_ADDRESS>wrote:

@LunarLambda https://github.com/LunarLambda You could use this to
produce a shared library and link to it, though that isn't the primary use
case. This RFC doesn't cover making that library available at runtime, so
you'd still need to handle that yourself (or have your users do so).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rfcs/pull/3028#issuecomment-753536272, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AJI55IQNTX53O4UWVBGYX3LSX6KXJANCNFSM4UIHGRJA
.

I don't personally have any lingering concerns!

I don't personally have any lingering concerns!

One question I had, is that this RFC only mentions bin, cdylib, and static lib, but in rust-gpu we're actually using dylib so that code be used in both Rust host code and in shaders. I don't see any mention of dylib, is there potential issues with extending this to also support dylib dependencies?

One question I had, is that this RFC only mentions bin, cdylib, and static lib, but in rust-gpu we're actually using dylib so that code be used in both Rust host code and in shaders. I don't see any mention of dylib, is there potential issues with extending this to also support dylib dependencies?

Why are you using dylib as crate type actually? That is only for when you want to use it as a rust dependency. It includes the full crate metadata and dynamically links against libstd.

Why are you using dylib as crate type actually? That is only for when you want to use it as a rust dependency. It includes the full crate metadata and dynamically links against libstd.

That is only for when you want to use it as a rust dependency.

I believe this is the main reason, so that you could have a single crate be used as Rust crate, and as a shader when compiled with spirv-unknown-unknown. This was already in place when I joined the project however, so I’m not aware if there’s further reasoning beyond that. Feel free to file an issue on the repo to discuss it more.

That is only for when you want to use it as a rust dependency.

I believe this is the main reason, so that you could have a single crate be used as Rust crate, and as a shader when compiled with spirv-unknown-unknown. This was already in place when I joined the project however, so I’m not aware if there’s further reasoning beyond that. Feel free to file an issue on the repo to discuss it more.

@rfcbot fcp merge

@rfcbot fcp merge

Huzzah! The @rust-lang/cargo team has decided to accept this RFC.
To track further discussion, subscribe to the tracking issue here:
https://github.com/rust-lang/cargo/issues/9096

Huzzah! The @rust-lang/cargo team has decided to accept this RFC.
To track further discussion, subscribe to the tracking issue here:
https://github.com/rust-lang/cargo/issues/9096


security for authoring api

#487
Authoring api will support external clients.
External clients will be defined in git repo under /external_apps/{app_id}.json with a json with the
following settings:
{
     version: 1,
     appName:"",
     hash:"", //for secret
     salt:"",  //for secret
     permissions: {
          "keys": {
                "*": ["read", "write"...]
            },
            "schema": {
                 "*": ["read", "write"]
             }
     }
}

Current permissions will allow reading, writing keys, in the future we can limit the scope to certain paths.
External Application will use app-id and app-secret to interact with Authoring api.
Requests signed by tweek-editor will have all permissions and an additional actions to add/remove external clients.
@asafkotzer, @nataly87s, @michaelkruglos, @omerlh.

You can take a look on icinga authentication for a reference, it is pretty straight forward.


Give install instrcutions

Currently there are no instructions on how to install the app. There is no mention of it in either the website or the README. I'd love to start using Friends with friends, but I can't even see how to install Friends myself.

Done! Thanks for reporting this. File another issue if you get stuck. :)

@noffle thanks!


Fix Boolean NPE

Fix NPE of Boolean when user didn't specify correspond value in pom.xml

Please also fix dogfood boolean variable

will done in later pr


Anonymous Telemetry logging

anonymous logs for metrics. pair this with privacy page. we should be the gold standard in transparency and good intentions as a company, and not steal data

amazin


Self-destructing notes.

Add ability to create self-destructing notes.

This feature will be built directly into the  DropNote API.


Clean up session_event and inputs on tests

Non-urgent but will improve readability in future

Required for:

[ ] clinic
[ ] chw
[ ] personal


cocoapods install realm,the RLMArray_Private.hpp, RLMAccessor.h, Realm / RLMConstants.h file is not found

OX S：10.10.3
Xcode：6.3
CocoaPods： 0.37.1
I created a project swift clearance CocoaPods mounted the Realm, open .xcworkspace, prompted me RLMArray_Private.hpp, RLMAccessor.h, Realm / RLMConstants.h file is not found, how do I fix it?
https://github.com/VNSKing/RealmSample

@VNSKing it's very strange that the Pods directory doesn't contain a Headers subdir -- that's almost certainly a CocoaPods bug if it's happening, and the CocoaPods team would definitely appreciate a reproducible bug report! In the meantime, I'd recommend
rm -rf ~/Library/Caches/CocoaPods
rm -rf Pods
pod install

@segiddins Thanks！！ The problem is resolved.


Animated armor?

The question
I have a very simple question, is it possible to animate armor textures with cit, and if so, how?
Checklist

[X] I checked the issues(both open and closed) and could not find a duplicate of my question

Not with CIT Resewn on it's own currently. You can however utilize Animatica to animate the texture file iirc.


Allow 7D Morton codes

Motivation: running 7D Household dataset (9D with date-time removed).

Few builds failed due to unrelated issues (out of space).


[FEATURE REQUEST] Filtering the status for each client.

I did not find any mention in the documentation of how to filter the state so that other players could not see other players' enemy cards. I'm making a card game. A workaround is to send a message every move, which is not convenient in the plan.
For example, I suggest adding a hook function to the match
local nk = require("nakama")

local M = {}

function M.match_init(context, setupstate)
  local gamestate = {
    presences = {},
    cards = {}
  }

  local tickrate = 1 -- per sec
  local label = ""

  return gamestate, tickrate, label
end

function M.math_filter_state(context, state)
  return state // new clone state send client state
end

return M

Where the math_filter_state function is the final result for each client state to send the state. So that the player can only see the state of his cards and hide the information of others

State is not sent to clients automatically at all.
You choose and encode whatever data must be sent to each client, then broadcast it using dispatcher.broadcast_message(...) so the message only reaches the specified client(s).


python310Packages.spyder: 5.3.3 -> 5.4.0

Description of changes
https://github.com/spyder-ide/spyder/releases/tag/v5.4.0
Fixes the failure from #199661

Things done

Built on platform(s)

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

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

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

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

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

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 199884 run on x86_64-linux 1

10 packages failed to build:

python310Packages.arviz
python310Packages.dalle-mini
python310Packages.elegy
python310Packages.pymc
python310Packages.treex
python39Packages.arviz
python39Packages.dalle-mini
python39Packages.elegy
python39Packages.pymc
python39Packages.treex

35 packages built:

ihaskell
inkcut
inkscape-extensions.inkcut
napari (python310Packages.napari)
python310Packages.ansible-kernel
python310Packages.augmax
python310Packages.einops
python310Packages.jupyter
python310Packages.napari-console
python310Packages.phik
python310Packages.pylint-venv
python310Packages.qstylizer
python310Packages.qtawesome
python310Packages.qtconsole
spyder (python310Packages.spyder)
python310Packages.spyder-kernels
python310Packages.vega
python310Packages.xarray-einstats
python39Packages.ansible-kernel
python39Packages.augmax
python39Packages.einops
python39Packages.jupyter
python39Packages.napari
python39Packages.napari-console
python39Packages.phik
python39Packages.pylint-venv
python39Packages.qstylizer
python39Packages.qtawesome
python39Packages.qtconsole
python39Packages.spyder
python39Packages.spyder-kernels
python39Packages.vega
python39Packages.xarray-einstats
quarto
rare


[TECHDEBT] [Persistence] Fix Persistence Module TODOs - Golang Test Cleanup & Teardown

Objective
A general cleanup issue is needed to tackle TODO's and ensure the persistence module is usable/readable by refactoring golang-specific Golang test cleanup & teardown as part of https://github.com/pokt-network/pocket/issues/172 and https://github.com/pokt-network/pocket/issues/149.
Origin Document
Should follow issue-#128, issue-#105, issue-#147 and issue-#148 the persistence module is messier and more difficult to understand than the developers would want for organic external contribution.
Goals / Deliverables

[ ] Implement golang-specific Golang test cleanup & teardown.
For example, the usage of:

func CleanupTest() {
	PostgresDB.Tx.Rollback(context.TODO())
	PersistenceModule.Stop()
}

Can be refactored to something like this:
func NewTestingUtilityContext(t *testing.T, height int64) utility.UtilityContext {
   ...
   t.Cleanup(func() {
        ctx.Context.Release() // TODO (team) need a golang specific solution for teardown
        PostgresDB.Tx.Rollback(context.TODO())
        PersistenceModule.Stop()
   })
  ...
  return &UtilityContext{...

General issue checklist

[ ] Update the appropriate CHANGELOG
[ ] Update the README
[ ] If applicable, update the source code tree explanation
[ ] If applicable, add or update a state, sequence or flowchart diagram using mermaid
[ ] Update any relevant global documentation & references
[ ] Document small issues / TODOs along the way

Creator: @andrewnguyen22
Co-creator: @Olshansk

@Jasonyou1995 I assigned this task to you since you've been digging into the persistence module. No need to tackle it right away (we can figure that part out) but the main goal here is to move our proprietary testing setup & teardown to the standard libraries use in Go.
This is a good article as a starting point to learn more: https://medium.com/nerd-for-tech/setup-and-teardown-unit-test-in-go-bd6fa1b785cd
The tl;dr is to remove all instance of test_artifacts.CleanupTest(ctx) which are spread across the utility, persistence and runtime modules in favor of using Go's t.Cleanup

Resolved as part of #550.


WebHook Sample

Hi, i have created a githook. Maybe someone want to use this Bash Script.
When a commit pushed or created new repository using gogs interface, this bash script will be run and makes these changes:
1- For web server, create new a new folder with  owner/repositoryname at defined www folder.
2- When commit pushed, it will make "git checkout" to above www folder
3- Create for download directory that has latest.zip file all www folder.
4- It will create virtual host config file with reponame at defined Nginx vhost folder (you must include *.conf at nginx.conf file within http property)
5- It will add reponame to windows host file if you want to see at browser latest version of file.
I hope, it will help someone
http://serkankonakci.com/webhook/ it could be download from here

Hmm... thanks your script. But I don't think it's a good place to put it...
Maybe I should really setup a discourse...


Google Pixel 4 XL w/ v2 Goggles

Google Pixel 4 XL w/ v2 Goggles seem to work but is necessary to go to the USB setting and change it to controlled by device.
Also am only getting 2-3 frames per minute.

I'm having the same issue - although I can't seem to switch anymore, has stopped working altogether.
Android is saying "Issue with Linux USB Drive" and requesting to format it. Will this mess up the goggles if I do so?

I'm having the same issue - although I can't seem to switch anymore, has stopped working altogether.
Android is saying "Issue with Linux USB Drive" and requesting to format it. Will this mess up the goggles if I do so?

Try this, works a charm for me https://github.com/d4rken/fpv-dvca

@terry-dactle thanks! That did the trick


Rename Symbol deletes extra characters when replacing a symbol found after an elif

Type: Bug

Behaviour
Expected vs. Actual
When using "Rename Symbol" to rename a variable found on the same line as an elif statement, the preceding whitespace and surrounding parenthesis (if present) are erronously deleted. They should remain untouched.
Steps to reproduce:

Create an elif statement that uses a variable as its only argument.
Highlight the variable (from somewhere other than the line with the elif.
Run the command "Rename Symbol" and rename the variable to anything else.
All characters except whitespace before "elif", "elif", the new variable name, and the trailing colon will be deleted. This includes the whitespace between "elif" and the new variable name, as well as any parenthesis that may be present on the line.

Diagnostic data

Python version (& distribution if applicable, e.g. Anaconda): 3.11.5
Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Global
Value of the python.languageServer setting: Default

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

XXX

User Settings

languageServer: "Pylance"

Extension version: 2023.18.0
VS Code version: Code 1.83.1 (f1b07bd25dfad64b0167beb15359ae573aecd2cc, 2023-10-10T23:48:05.904Z)
OS version: Windows_NT x64 10.0.22621
Modes:

System Info

Item
Value

CPUs
13th Gen Intel(R) Core(TM) i7-13700H (20 x 2918)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: enabled_ondirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: enabled

Load (avg)
undefined

Memory (System)
15.70GB (2.78GB free)

Process Argv
--crash-reporter-id 0b9ddb31-2fef-4557-bf98-877efdbe1c71

Screen Reader
no

VM
0%

A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492cf:30256860
vslsvsres303:30308271
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscod805:30301674
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593:30376534
pythonvs932:30410667
py29gd2263:30856252
vscaac:30438847
vsclangdf:30486550
c4g48928:30535728
dsvsc012:30540252
pynewext54:30695312
azure-dev_surveyone:30548225
2e4cg342:30602488
89544117:30613380
showlangstatbar:30737416
962ge761:30841074
03d35959:30757346
pythonfmttext:30731395
f8hc8238:30694864
fixshowwlkth:30771522
showindicator:30805244
pythongtdpath:30769146
i26e3531:30792625
pythonnosmt12:30797651
pythonidxpt:30805730
pythonnoceb:30805159
copilotsettingt:30859503
dsvsc013:30795093
dsvsc014:30804076
diffeditorv2:30821572
dsvsc015:30845448
pythonregdiag:30859691

I'm unable to repro this. Can you provide more details?

What version of Pylance do you have installed?
What variable names (old / new) are you using?
A code sample and/or video might be helpful.

I am using Pylance v2023.10.20.
Here's a few screenshots of the process.

The original code

Select "old_name" on line 1, then run the Rename Symbol command, using "new_name" as the new name.

After executing the command, the parentheses on line 4 are deleted.

I see. Your repro steps above stated that the whitespace between elif and the new variable name was removed, which would result in invalid code. In your screenshots above however, and in my testing, that whitespace is unchanged. The parentheses that are removed are superfluous, so the resulting code is valid, although stylistically different. I noticed that any leading/trailing whitespace within the parentheses is also removed, but this again is superfluous.
While I agree that the parenthesis removal is unexpected for a rename operation, this seems like a low priority issue. We can handle it as an enhancement and see if other users up-vote it, indicating that they would also like to see it fixed.
Fair?
If you can provide repro steps where the resulting code is invalid, we would prioritize this more highly.

Sure. I'll try to find the code I was originally working on that prompted me to post the issue.

I can't share the original code I was working on for security purposes, but I've made an example that resembles my original issue. It seems that the problem only happens when the elif statement was immediately followed by a variable wrapped in parentheses (no spaces). I know it isn't pretty code, which is why I was going back to reformat it. Here are some screenshots.

Highlight the name of the variable on a line other than the elif.

Change the variable name to something else. Note that the extension is about to change the variable name and surrounding parenthesis on the line with the elif.

The resulting change deletes the surrounding parentheses on the line with the elif, resulting in invalid code.

Great, thanks for the repro! Since this results in invalid code, it's clearly much worse. We'll take a look.

This will be fixed next time we pull Pyright.

This issue has been fixed in prerelease version 2023.12.104, which we've just released. You can find the changelog here: CHANGELOG.md


Update buildenv to reflect latests zopen build changes

I will use this to test stderr getting garbled in the CI


Split window uses default keyboard shortcuts instead of custom

From<EMAIL_ADDRESS>on 2012-05-22T10:12:20Z
Spyder Version:  2.2.0dev
Python Version:  2.7.2
Qt Version:      4.7.4, PyQt4 (API v1) 4.8.6 on Windows
What steps will reproduce the problem?

Set delete line shortcut to Alt+Ctrl+Shift+D
Set duplicate line shortcut to Ctrl+D
Split a tab vertically
Pressing Ctrl+D correctly duplicates lines on the left hand side
Pressing Ctrl+D incorrectly deletes lines on the right hand side What is the expected output? What do you see instead? Bound keyboard shortcuts should always perform the expected action.

Original issue: http://code.google.com/p/spyderlib/issues/detail?id=1038

From pierre.raybaut on 2012-05-25T12:54:58Z
This issue was closed by revision f5761c3e0805 .
Status: Fixed


ci: Add dependabot go-storage auto build support

Signed-off-by: Xuanwo<EMAIL_ADDRESS>

ping @xxchan for a look.
There are the following problems:

The action won't work until we set go-storage to semver: Dependabot ignore git versions
I don't know how to test this workflow.

I think we can test by removing dependency-names first?

Wait, but we have to merge this into master first to test?

Wait, but we have to merge this into master first to test?

Yep, it's a problem. Maybe we can merge this to another branch?

Here is an open PR from dependabot: https://github.com/beyondstorage/go-service-s3/pull/138
Maybe we can test via them instead.

Wait, but we have to merge this into master first to test?

Yep, it's a problem. Maybe we can merge this to another branch?

I think this is an affordable price: one or two useless commit

Maybe we can merge this to another branch?

Can it be triggered? I'm OK.

Ooops, it looks like we have to merge this PR into master first.


demo data illustrating the effect of saline vehicle, caffeine and amphetamine on the mouse behaviours

May I please ask whether we could get your demo experiment data which was used to illustrate the effect of saline vehicle, caffeine and amphetamine on the mouse behaviours in the long-time scale? Thank you very much for your attention. I'm looking forward to your reply.

We didn't do any drug experiments on mice in the DANNCE paper. I assume you are thinking about the (rat) experiments in @jessedmarshall's CAPTURE paper. You should contact him directly for those data.


mariadb: updates

Motivation for this change
upstream releases, security fixes, the usual
should be backported, but automatic backport will definitely not work
I'm not sure if we want to change the default to 10.7, now or… ever. mainly because it's not an LTS release.
iirc the next one isn't known yet, so no idea when and how all of that wil happen.
Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

Something weird happened. Looks like the version updates were unpublished by upstream. :fearful:

Ah yes, there is a tweet mentioning the updates were unpublished:

The release was pulled due a problem that was picked up when manually running mariadb-upgrade. A new release will be out soon. https://twitter.com/mariadb_org/status/1491727266577010690

The re-revert + new batch of releases is in #160053


Add blend function and tests

Fixes https://github.com/ramda/ramda/issues/777

:+1:

I like this function. I take issue with its name (though I was greatly amused by the baking analogy). I've never liked the name R.mixin, either. The word "mixin" is a noun; the verb is "mix in". R.mixIn looks ugly, though. Also, when I hear "mixin" I think OOP.
I suggest the following changes:

R.mixin → R.merge; and
R.blend → R.mergeAll.

do we have a standard suffix for lifting a function to list context?

do we have a standard suffix for lifting a function to list context?

We do have R.insert and R.insertAll.

:cow2:

@davidchambers You've mentioned before not liking the name "mixin".  I don't care much.  I've seen a lot of names for this, and none of them seems to be particularly dominant.  If you've a strong feeling about it, let's do it now, before we hit 1.0.

@benperez, please rename the function R.mergeAll.

Updated

:deciduous_tree:

Just checking back in on this method. Have folks been happy with the signature R.mergeAll(array)?
I'm wondering if there's something to R.mergeAll(destObj, srcArr).

I'm wondering if there's something to a signature like R.mergeAll(destObj, srcArr).

R.reduce(R.merge, destObj, srcArr) should achieve this, shouldn't it? If you're asking whether there's a function which mutates one of its arguments, the answer is no.

Not about mutating. Just similar to other All methods which are like their non-All forms except applying an array of values instead of a single value. The mergeAll is a bit different than the other All-forms.

It doesn't seem too bad to me to write R.mergeAll(R.prepend(destObj, srcArr)) if one happens to have a single object and an array of objects. I don't think this warrants a dedicated function. Others may disagree, of course.

Yep, I know there are other ways to accomplish things. I was checking in to see if you all had gotten feedback on the signature and thoughts about it related to the other All-forms.

@jdalton:
Just returning from two-weeks away.  I don't recall any such feedback.
I also don't really think we have any standard behavior for the All suffix.  The three functions I can think of with that suffix, insertAll, mergeAll, and pickAll have three different sorts of semantics.


zephyr_library_compile_options() lost support for duplicates

Describe the bug
PR #14776 / commit 915a35325562 changed function zephyr_library_compile_options() to use MD5 instead of RANDOM for build reproduction reasons. As later predicted by @SebastianBoe  in the PR (thx), the names generated for these pseudo-libraries won't be unique anymore if the exact same flag gets added more than once.
To Reproduce
Simply add the following two lines in some CMakeLists.txt file like samples/hello_world/CMakeLists.txt:
zephyr_library_compile_options("-Dfubar=barfu")
zephyr_library_compile_options("-Dfubar=barfu")

cmake will then fail like this:
 CMake Error at zephyr/cmake/extensions.cmake:403 (add_library):
  add_library cannot create target
  "options_interface_lib_e689fdb7eb15d801c2f95dd61301fc5e" because
  another target with the same name already exists.  The existing
  target is an interface library created in source directory
  "zephyr/samples/hello_world".  See documentation for
  policy CMP0002 for more details.
 Call Stack (most recent call first):
  CMakeLists.txt:9 (zephyr_library_compile_options)

Expected behavior
zephyr_library_compile_options() supports duplicates
Impact
Depends how users use zephyr_library_compile_options() in their particular projects, suspected to be low. Apparently no impact in the core zephyr codebase.

@SebastianBoe could you please help assess the impact? Not sure whether this should make v1.14.0 or not.


Update the danger version reference #trivial

Fixes the version number for Danger.

Fails

:no_entry_sign:

Please assign someone to merge this PR, and optionally include people who should review.

  Generated by :no_entry_sign: dangerJS


No card when asl mismatch

When an user as no asl setted, clicking on his nick in the userlist opens an empty usercard.
It works well when user asl is "correct"

I think this is by design, a new feature request as #22 seems clear.

Well, it not by design, an error occures when trying to see the infos about an user with bad formated asl:

TypeError: y is not a function
at a.formattedRealname (plugin-asl.js:1)
at Ao.get (vue.common.prod.js:6)
at Ao.evaluate (vue.common.prod.js:6)
at a.formattedRealname (vue.common.prod.js:6)
at a.m (plugin-asl.js:1)
at a.t._render (vue.common.prod.js:6)
at a.r (vue.common.prod.js:6)
at Ao.get (vue.common.prod.js:6)
at new Ao (vue.common.prod.js:6)
at vue.common.prod.js:6


Shooter right-side wheel sometimes doesn't spin up without a poke.

It happened twice yesterday. It may be an electrical/hardware issue, but we should investigate if the speed controller is complaining about something like a missing encoder signal.
Interestingly, the code shows the left follows the right.  How does that work if the right doesn't move?  My understanding is that the left would get the same command as the right (the command appropriate for a 0 rpm motor).
Perhaps the follower feature is inappropriate here.  Makes sense for the shoulder (they are mechanically coupled), but perhaps not for things in speed or position control modes like the shooter and indexers.  In this case, the left side going to max is an appropriate fallback (compensates for no umph right side).  However, if the left were to go down, the right side would be unaware and not know to go to max.

Known issue. Other things I remember about this:

It occurs with and without the follower feature active
The speed controller is getting the correct signal immediately
No faults were directly shown on the speed controller (we could check Rev hardware client still)
Occurred after reimaging the spark

My guess would be the motor. Maybe one of the phases has degraded, if that is possible.
The follower features works as a logical link to apply the same voltage level as its leader based on CAN status frames, the leader doesn't necessarily need to move. If we can still shoot with just one side (I assumed the note would just get stuck), we can decouple these.

A new motor needed v1.1 for the tapped shaft, but that doesn't preclude a bad motor or bad wiring.  Will investigate and/or swap.
My point re: the follower is that the right (stuck) motor will have max P roportional and a growing I ntegral term applied to it, which the follower will follow, even though it is moving.  OK for a continuous rotation (will get high speed) but would be very bad for something like the shoulder if it didn't have an independent feedback sensor.

The speed controller has been replaced after confirming it was not able invoke one of the motors phases. Verified that it was able to spin up consistently during PID tuning #37.
Follow logic was also removed due to lack of overall control over the follower when the leader is dead in PID loop situations.
https://github.com/FRC-1250/Team-1250-Crescendo2024/commit/f9973f4e789bf5ddf345d5c4f2372166d077a9ff


padlock: generate assembler source for static libraries too

The GENERATE lines for generating the padlock assembler source were
wrongly placed in such a way that they only applied to the shared
library build.

The current builds of master fail because of the error that this PR hopefully fixes.
I've enabled extended tests to make sure

Merged.
7120f1e7c74c8220f43fd28ac7303c0cab29dabe padlock: generate assembler source for static libraries too


Support LDAP autoprovisioning in helm chart

added proxy environment variable PROXY_AUTOPROVISION_ACCOUNTS to proxy/deployments.yaml which defaults to "false"
added features.externalUserManagement.autoprovisionAccounts boolean flag to values.yaml and descriptions table

Description
Support LDAP autoprovisioning in helm chart
All that is missing is an environment variable for "proxy" in https://github.com/owncloud/ocis-charts/blob/main/charts/ocis/templates/proxy/deployment.yaml like this:
            - name: PROXY_AUTOPROVISION_ACCOUNTS               value: {{ .Values.features.externalUserManagement.autoprovisionAccounts | default "false" | quote }}
and a boolean flag autoprovisionAccounts in externalUserManagement section of values files.
Related Issue

Fixes #522

Motivation and Context
This can be useful in scenarios where you have an OIDC Idp which is not backed by LDAP but some other user store.
In this case we want OCIS to autoprovision users in its external LDAP (which is used for OCIS exclusively).
How Has This Been Tested?

test environment:
local test installation with external ldap and oidc enabled
test case1:
user authenticates via idp, then user is created in ldap store by proxy-service

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Technical debt
[ ] Tests only (no source changes)

Checklist:

[x] Code changes
[ ] Unit tests added
[ ] Acceptance tests added
[ ] Documentation generated (make docs) and committed
[ ] Documentation ticket raised:
[ ] Documentation PR created:

Hi @wkloucek, @d7oc,
thank you so much for picking up my pull request so quickly.
Best Regards
Ewald


[OpenXR] Fixes crashes when no device is present

PR Details
The essential part here is that OpenXRHmd.CanInitialize will now return false if no device is present. This ensures that the VRDeviceSystem sets up a dummy device which in turn prevents many parts from crashing.
Description
To truly know whether or not an actual device is connected we first need to establish contact with the OpenXR runtime. Therefor code has been moved around a bit to be able to call various parts individually. Tested on two machines, one without any VR related things installed and another one with an actual device.
This commit also contains a bunch of code cleanups:

Enables C# nullable feature on OpenXR files
Adds null checks to various places
Disposes XR API after shutting down the device
Makes various fields and methods private
Moves initialization code to a OpenXRUtils class to make dependencies more visible
Turns OpenXRInput into a normal class holding a reference to the device
Turns CheckResult into an extension method and simplifies its usage by letting C# infer the called method
Introduces OpenXRException exception class carrying the inferred method and XR error code

Related Issue
Probably causes conflicts with #2119 which we would offer to fix.
Motivation and Context
The system shouldn't crash when no VR device is present.
Types of changes

[ ] Docs change / refactoring / dependency upgrade
[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

[ ] My change requires a change to the documentation.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.
[x] I have built and run the editor to try this change out.
[x] I did run a VR patch in vvvv with two machines, one having a device, and the other which doesn't

Looks good @azeno - thanks again :)
We'll continue over in #2119


Output format JSON

Hi Till
Thanks for the great tool! Would it be possible to add an option to retrieve the output in JSON format? Especially for status information this would be really great.
BR
Markus

I was already thinking of this. Would you prefer the raw json as coming from the VW servers (with the risk that the structure changes more often) or would you prefer the (a bit more stable) output of the CLI but in json format?

As stable as possible would be nice! I'm especially interested in the batteryStatus and readinessStatus data.

Will put it on the Todo list without a particular promise when it will be available, but as it should be limited effort I think it can be ready in reasonable time.

Update: Does already work on my test branch. Will come in two flavours: --format json added to get command will switch the output to json. save command will also write a json file if the file ending is .json.

Now available in 0.24.0 release


[FEAT] react native

Apparently there is interopability with react DOM and react native so would be cool to have some react native components in the future too..
https://necolas.github.io/react-native-web/

The core team probably won't add this in the near future, but if a community. member wants to take this on we would support that.

Yea leave issue open I'll prob do it eventually just mostly raising awareness here. Can put it on my roadmap for future def


Update styles.css

You can use the   *  instead of  html,body

well i guess  i was taking about default css . like- margin :0px; padding:0px; box-sizing:border-box; and font family .Not  about  other  syntax .


Unable to create AssetBundle

Hello! I love your mod btw and want to eventually be able to make a map. I was testing the SDK through Unity and have been trying to create a new scrap item. I believe I did everything correct but also I do not have much Unity experience. When I try to export the assetbundle I am met with an error. I've tried manually installing bepinex and lethalexpansion to see if that would fix the issue as opposed to using Thunderstore but no matter where I try to import the bundle to I still receive this error. If you could help guide me whatsoever it would be greatly appreciated!

Hello! I love your mod btw and want to eventually be able to make a map. I was testing the SDK through Unity and have been trying to create a new scrap item. I believe I did everything correct but also I do not have much Unity experience. When I try to export the assetbundle I am met with an error. I've tried manually installing bepinex and lethalexpansion to see if that would fix the issue as opposed to using Thunderstore but no matter where I try to import the bundle to I still receive this error. If you could help guide me whatsoever it would be greatly appreciated!

This issue happen because you have several assets of the same name, check every file and rename them if two of them have the same name

Thank you so much! It worked! I will be uploading my mod adding 1 new scrap item into the game later today after configuring some more option. You're the best for replying so fast.


YouTube app doesn't Sign in and doesn't play videos (an error occured, please try again latter).

Hello Guys,
Steps to reproduce the issue:

Open Nuvola Player YouTube app.
On the top right, click on "Sign in"
Type your e-mail and password.

After realizing Sign On, it starts on a Loop. When you close the app, you can read the following message on screen:
)]}'
[["er",null,null,null,null,405,null,null,null,9]
]
I had to remove manually the dir ~/.config/nuvolaplayer3/apps_data/youtube to restore the YouTube app.
When you try to play any video (without sign in), it shows the following message:
An error occurred, please try again latter.
I'm using Deepin 15.4 x86_64 (based on Debian Sid "Unstable") and installed it from official Tiliato repo (deb https://tiliado.eu/nuvolaplayer/repository/deb/ sid stable)
$ lsb_release -a No LSB modules are available. Distributor ID:	Deepin Description:	Deepin 15.4.1 Release:	15.4.1 Codename:	unstable
$ uname -m x86_64
$nuvolaplayer3 --version Nuvola Player 3 3.0.8 Revision 683fc7254443f13a35e4ba33d948ca6e382e690f WebKitGTK 2.14.5 libsoup 2.56.0
Debugging Output
Video tried to open (without sign in): https://www.youtube.com/watch?v=JGwWNGJdvx8&list=TLGG3DnPUKZUodwxNjA3MjAxNw&index=1 (Ed Sheeran - Shape of You)
$ nuvolaplayer3 --debug Master: [DEBUG    DioriteGtk] DesktopShell.vala:96: Shell: mutter(deepingala) (null), CSD 0, appmenu 0, menubar 0 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app 8tracks at /usr/share/nuvolaplayer3/web_apps/8tracks, version 5.2 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Deezer at /usr/share/nuvolaplayer3/web_apps/deezer, version 2.5 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Groove at /usr/share/nuvolaplayer3/web_apps/groove, version 1.3 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Jango at /usr/share/nuvolaplayer3/web_apps/jango, version 2.3 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app KEXP Live Stream at /usr/share/nuvolaplayer3/web_apps/kexp, version 1.2 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Plex Music at /usr/share/nuvolaplayer3/web_apps/plex, version 1.3 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app SiriusXM at /usr/share/nuvolaplayer3/web_apps/siriusxm, version 1.3 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app SoundCloud at /usr/share/nuvolaplayer3/web_apps/soundcloud, version 1.3 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app TuneIn at /usr/share/nuvolaplayer3/web_apps/tunein, version 1.3 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Yandex Music at /usr/share/nuvolaplayer3/web_apps/yandex_music, version 1.4 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app YouTube at /usr/share/nuvolaplayer3/web_apps/youtube, version 1.3 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Amazon Cloud Player at /usr/share/nuvolaplayer3/web_apps/amazon_cloud_player, version 5.4 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Bandcamp at /usr/share/nuvolaplayer3/web_apps/bandcamp, version 2.2 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Google Play Music at /usr/share/nuvolaplayer3/web_apps/google_play_music, version 5.18 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Logitech Media Server at /usr/share/nuvolaplayer3/web_apps/logitech_media_server, version 2.2 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Mixcloud at /usr/share/nuvolaplayer3/web_apps/mixcloud, version 3.2 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Spotify at /usr/share/nuvolaplayer3/web_apps/spotify, version 2.3 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Test at /usr/share/nuvolaplayer3/web_apps/test, version 1.0 Master: [DEBUG    Nuvola] WebApp.vala:210: Theme icon nuvolaplayer3_test 48 not found. Master: [DEBUG    DioriteGtk] application.vala:219: XFCE session vanished: org.xfce.SessionManager Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app 8tracks at /usr/share/nuvolaplayer3/web_apps/8tracks, version 5.2 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Deezer at /usr/share/nuvolaplayer3/web_apps/deezer, version 2.5 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Groove at /usr/share/nuvolaplayer3/web_apps/groove, version 1.3 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Jango at /usr/share/nuvolaplayer3/web_apps/jango, version 2.3 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app KEXP Live Stream at /usr/share/nuvolaplayer3/web_apps/kexp, version 1.2 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Plex Music at /usr/share/nuvolaplayer3/web_apps/plex, version 1.3 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app SiriusXM at /usr/share/nuvolaplayer3/web_apps/siriusxm, version 1.3 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app SoundCloud at /usr/share/nuvolaplayer3/web_apps/soundcloud, version 1.3 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app TuneIn at /usr/share/nuvolaplayer3/web_apps/tunein, version 1.3 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Yandex Music at /usr/share/nuvolaplayer3/web_apps/yandex_music, version 1.4 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app YouTube at /usr/share/nuvolaplayer3/web_apps/youtube, version 1.3 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Amazon Cloud Player at /usr/share/nuvolaplayer3/web_apps/amazon_cloud_player, version 5.4 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Bandcamp at /usr/share/nuvolaplayer3/web_apps/bandcamp, version 2.2 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Google Play Music at /usr/share/nuvolaplayer3/web_apps/google_play_music, version 5.18 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Logitech Media Server at /usr/share/nuvolaplayer3/web_apps/logitech_media_server, version 2.2 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Mixcloud at /usr/share/nuvolaplayer3/web_apps/mixcloud, version 3.2 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Spotify at /usr/share/nuvolaplayer3/web_apps/spotify, version 2.3 Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Test at /usr/share/nuvolaplayer3/web_apps/test, version 1.0 Master: [INFO     Nuvola] WebAppRegistry.vala:89: Using web app YouTube, version 1.3, data dir /usr/share/nuvolaplayer3/web_apps/youtube Master: [DEBUG    Nuvola] MasterController.vala:378: Launch app runner for 'youtube': /usr/lib/nuvolaplayer3/apprunner -D -a /usr/share/nuvolaplayer3/web_apps/youtube  Runner: [DEBUG    DioriteGtk] DesktopShell.vala:96: Shell: mutter(deepingala) (null), CSD 0, appmenu 0, menubar 0 Runner: [DEBUG    DioriteGtk] application.vala:219: XFCE session vanished: org.xfce.SessionManager Master: [DEBUG    Nuvola] MasterController.vala:284: Connected to runner server for 'youtube'. Runner: [DEBUG    Nuvola] config.vala:174: Json Error: Falha ao abrir arquivo "/home/eduardo/.config/nuvolaplayer3/apps_data/youtube/config.json": Arquivo ou diretório não encontrado Runner: [DEBUG    Nuvola] Connection.vala:132: Network Proxy: system settings Runner: [DEBUG    Nuvola] WebEngine.vala:73: Nuvola WebKit Extension directory: /usr/lib/nuvolaplayer3 Runner: [WARNING  DioriteGtk] actionsregistry.vala:170: Action 'donate' not found in registry. Runner: [DEBUG    Nuvola] Notifications.vala:175: Notifications: persistence false, actions false, icons false Master: [DEBUG    Nuvola] MediaKeys.vala:134: GNOME settings daemon vanished: org.gnome.SettingsDaemon Runner: [DEBUG    Nuvola] AppRunnerController.vala:416: Component tray_icon (Tray Icon) not enabled Runner: [DEBUG    Nuvola] AppRunnerController.vala:416: Component notifications (Notifications) enabled Runner: [DEBUG    Nuvola] AppRunnerController.vala:416: Component mediakeys (Media keys) enabled Runner: [DEBUG    Nuvola] AppRunnerController.vala:416: Component scrobbler (Audio Scrobbler Services) enabled Runner: [DEBUG    Nuvola] AppRunnerController.vala:416: Component mpris (MPRIS 2) enabled Runner: [DEBUG    Nuvola] AppRunnerController.vala:416: Component lyrics (Lyrics) enabled Runner: [DEBUG    Nuvola] AppRunnerController.vala:416: Component developer (Developer's tools) enabled Runner: [DEBUG    Nuvola] MPRISProvider.vala:73: Bus acquired: org.mpris.MediaPlayer2.NuvolaAppYoutube, registering objects Runner: [DEBUG    Nuvola] MPRISProvider.vala:90: Bus name acquired: org.mpris.MediaPlayer2.NuvolaAppYoutube Worker: [DEBUG    Nuvola] WebExtension.vala:203: Page 1 created for (null) Worker: [DEBUG    Nuvola] WebExtension.vala:212: Document loaded about:loading Runner: [DEBUG    Nuvola] WebEngine.vala:496: Navigation, current window: uri = https://www.youtube.com/feed/music, result = true, frame = (null), type = WEBKIT_NAVIGATION_TYPE_OTHER Runner: [DEBUG    Nuvola] WebAppWindow.vala:170: Sidebar position: 955 Runner: [INFO     Nuvola] config.vala:260: Config saved to /home/eduardo/.config/nuvolaplayer3/apps_data/youtube/config.json Worker: [DEBUG    Nuvola] WebExtension.vala:113: Window object cleared for 'https://www.youtube.com/feed/music' Worker: [DEBUG    Nuvola] WebExtension.vala:123: Init frame: https://www.youtube.com/feed/music, 0x56045d1f9a50, 0x56045ce0e720, 0x7f2a35bd40e0 Runner: https://www.youtube.com/feed/music:34:107: CONSOLE ERROR Failed to set referrer policy: The value 'origin-when-cross-origin' is not one of 'no-referrer', 'origin', 'no-referrer-when-downgrade', or 'unsafe-url'. Defaulting to 'no-referrer'. Runner: [DEBUG    Nuvola] FormatSupport.vala:110: Trying to play /usr/share/nuvolaplayer3/audio/audiotest.mp3. Runner: [DEBUG    Nuvola] FormatSupport.vala:110: Pipeline state changed from NULL to READY. Runner: [DEBUG    Nuvola] FormatSupport.vala:110: Pipeline state changed from READY to PAUSED. Runner: [DEBUG    Nuvola] FormatSupport.vala:110: Pipeline state changed from PAUSED to PLAYING. Worker: [DEBUG    Nuvola] WebExtension.vala:212: Document loaded https://www.youtube.com/feed/music Runner: [DEBUG    Nuvola] FormatSupport.vala:110: End of stream for file /usr/share/nuvolaplayer3/audio/audiotest.mp3. Runner: [DEBUG    Nuvola] FormatSupportCheck.vala:145: Nuvola.WebPlugin: Shockwave Flash (enabled, flash) at /usr/lib/mozilla/plugins/flashplugin-alternative.so: Shockwave Flash 26.0 r0 Runner: [DEBUG    Nuvola] FormatSupportCheck.vala:145: Nuvola.WebPlugin: IcedTea-Web Plugin (using IcedTea-Web 1.6.2 (1.6.2-3.1)) (enabled, not flash) at /usr/lib/mozilla/plugins/libjavaplugin.so: The IcedTea-Web Plugin executes Java applets. Runner: file:///usr/share/nuvolaplayer3/web_apps/youtube/integrate.js:122:24: CONSOLE LOG YouTube API connection error: TypeError: window.yt.player.getPlayerByElement is not a function. (In 'window.yt.player.getPlayerByElement('player-api')', 'window.yt.player.getPlayerByElement' is undefined) Runner: [DEBUG    Nuvola] DeveloperSidebar.vala:158: Media player notify: artwork-location Runner: [INFO     Nuvola] config.vala:260: Config saved to /home/eduardo/.config/nuvolaplayer3/apps_data/youtube/config.json Runner: libva info: VA-API version 0.39.4 Runner: libva info: va_getDriverName() returns 0 Runner: libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so Runner: libva info: Found init function __vaDriverInit_0_39 Runner: libva info: va_openDriver() returns 0 Runner: libva info: VA-API version 0.39.4 Runner: libva info: va_getDriverName() returns 0 Runner: libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so Runner: libva info: Found init function __vaDriverInit_0_39 Runner: libva info: va_openDriver() returns 0 Runner: [INFO     Nuvola] config.vala:260: Config saved to /home/eduardo/.config/nuvolaplayer3/apps_data/youtube/config.json Runner: [DEBUG    Nuvola] WebEngine.vala:496: Navigation, current window: uri = https://googleads.g.doubleclick.net/pagead/ads?ad_block=2&client=ca-pub-6219811747049371&format=300x250_as&output=html&h=250&w=300&loeid=9419451%2C9422596%2C9431012%2C9434289%2C9441391%2C9451823%2C9457019%2C9460350%2C9462695%2C9465813%2C9474356%2C9475698%2C9477113%2C9477535%2C9478418%2C9478738%2C9478839%2C9480539%2C9480648%2C9480776%2C9481951%2C9482289%2C9482503%2C9482851%2C9483014&pucrd=CgYIABAAGAA&channel=0854550287%2BVertical_1021%2BVertical_1027%2BVertical_1408%2BVertical_211%2BVertical_36%2BVertical_613%2BVertical_617%2Bafc_on_page%2Bafv_user_edsheeran%2Bafv_user_id_0C-w0YjGpqDXGB8IHb662A%2Byt_cid_1%2Byt_gp%2Byt_mpvid_TkBdF52EBj86wZSB%2Byt_no_ap%2Byt_no_cp%2Byt_no_wa%2Bytdevice_1%2Bytdevicever_1.20170712%2Bytel_detailpage%2Bytps_default&host=ca-host-pub-9338557111912616&ht_id=4326035&ad_type=image&alternate_ad_url=https%3A%2F%2Fwww.youtube.com%2Fad_frame%3Fid%3Dwatch-channel-brand-div&flash=26.0.0&hl=pt&url=http%3A%2F%2Fwww.youtube.com%2Fvideo%2FJGwWNGJdvx8&video_doc_id=yt_JGwWNGJdvx8&wgl=1&dbp=ChZYbld4ZC0yRDJMSU81RmszdTZrcU1REAEgASgA&lact=-1&yt_pt=APb3F2_axkakcC4gwB9_x2Ez7CffTjHiVLVpzEDz_shIjti-MG4Pei_QZGHtcT6gMVasEX57kgPaTQkcq2IdZf0uW5aS7JB0DP670BHJKmRTG56P1BcwatXeG5jo5EHiB9YkQKb2ZHkDG9HzVUHo&dt=1500242575657&bdt=9585&idt=0&shv=r20100101&cbv=r20100101&correlator=4824247308847&frm=20&ga_vid=81929664.1500242576&ga_sid=1500242576&ga_hid=453543529&ga_fc=0&pv=2&iag=0&icsg=200293519&dssz=24&mdo=0&mso=0&u_tz=-180&u_his=2&u_java=0&u_h=768&u_w=1366&u_ah=768&u_aw=1366&u_cd=24&u_nplug=2&u_nmime=148&biw=1100&bih=559&loc=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DJGwWNGJdvx8%26list%3DTLGG3DnPUKZUodwxNjA3MjAxNw&rx=0&brdim=50%2C50%2C50%2C50%2C1366%2C0%2C1100%2C600%2C1100%2C559&vis=1&ppjl=u&pfx=0&fu=4096&bc=1&js=uds&eid=37464000, result = true, frame = (null), type = WEBKIT_NAVIGATION_TYPE_OTHER Runner: libva info: VA-API version 0.39.4 Runner: libva info: va_getDriverName() returns 0 Runner: libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so Runner: libva info: Found init function __vaDriverInit_0_39 Runner: libva info: va_openDriver() returns 0

From https://groups.google.com/d/msg/nuvola-player-users/_28EEAQNGA0/5zklBvW9BwAJ

$nuvolaplayer3 --version Nuvola Player 3 3.0.8 Revision 683fc7254443f13a35e4ba33d948ca6e382e690f WebKitGTK 2.14.5 libsoup 2.56.0

You need to update WebKitGTK to >= 2.14.7. I recommend 2.16.5.
If it is not possible on your system, you can use Nuvola 4.x Rolling releases, which always bundle the latest stable WebKitGTK to avoid web compatibility issues.

@jrosco You can close this ticket unless it is reproducible with WebKitGTK 2.16.5.

Helo jrosco and fenryxo,
This week, I found out that Debian Sid repo updated WebKitGTK to version 2.16.5 and Nuvola had released a new version and realized the upgrade of both.
It still shows the message "An error occurred, please try again latter" in any video that I try to play, but logon is fine now. Some debug info (the other info are the same from original post):
$ nuvolaplayer3 --version
Nuvola Player 3 3.0.9
Revision f79856a684ab9fbce31d814059a4fc20a51489c1
WebKitGTK 2.16.5
libsoup 2.56.0
Opened Nuvola Player 3, selected YouTube, open video: https://www.youtube.com/watch?v=y3KEhWTnWvE&list=TLGGP10gZ43XsJ8yNTA3MjAxNw&index=2
$ nuvolaplayer3 --debug
Master: [DEBUG    DioriteGtk] DesktopShell.vala:96: Shell: mutter(deepingala) (null), CSD 0, appmenu 0, menubar 0
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app 8tracks at /usr/share/nuvolaplayer3/web_apps/8tracks-link, version 5.2
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Amazon Cloud Player at /usr/share/nuvolaplayer3/web_apps/amazon_cloud_player-link, version 5.4
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Bandcamp at /usr/share/nuvolaplayer3/web_apps/bandcamp-link, version 2.2
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Deezer at /usr/share/nuvolaplayer3/web_apps/deezer-link, version 2.7
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Google Play Music at /usr/share/nuvolaplayer3/web_apps/google_play_music-link, version 5.19
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Groove at /usr/share/nuvolaplayer3/web_apps/groove-link, version 1.3
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Jango at /usr/share/nuvolaplayer3/web_apps/jango-link, version 2.3
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app KEXP Live Stream at /usr/share/nuvolaplayer3/web_apps/kexp-link, version 1.2
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Logitech Media Server at /usr/share/nuvolaplayer3/web_apps/logitech_media_server-link, version 2.2
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Mixcloud at /usr/share/nuvolaplayer3/web_apps/mixcloud-link, version 3.2
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Plex Music at /usr/share/nuvolaplayer3/web_apps/plex-link, version 1.3
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app SiriusXM at /usr/share/nuvolaplayer3/web_apps/siriusxm-link, version 1.3
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app SoundCloud at /usr/share/nuvolaplayer3/web_apps/soundcloud-link, version 1.3
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Spotify at /usr/share/nuvolaplayer3/web_apps/spotify-link, version 2.3
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app TuneIn at /usr/share/nuvolaplayer3/web_apps/tunein-link, version 1.3
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Yandex Music at /usr/share/nuvolaplayer3/web_apps/yandex_music-link, version 1.4
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app YouTube at /usr/share/nuvolaplayer3/web_apps/youtube-link, version 1.3
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Test at /usr/share/nuvolaplayer3/web_apps/test, version 1.0
Master: [DEBUG    Nuvola] WebApp.vala:210: Theme icon nuvolaplayer3_8tracks 48 not found.
Master: [DEBUG    Nuvola] WebApp.vala:210: Theme icon nuvolaplayer3_amazon_cloud_player 48 not found.
Master: [DEBUG    Nuvola] WebApp.vala:210: Theme icon nuvolaplayer3_bandcamp 48 not found.
Master: [DEBUG    Nuvola] WebApp.vala:210: Theme icon nuvolaplayer3_deezer 48 not found.
Master: [DEBUG    Nuvola] WebApp.vala:210: Theme icon nuvolaplayer3_google_play_music 48 not found.
Master: [DEBUG    Nuvola] WebApp.vala:210: Theme icon nuvolaplayer3_groove 48 not found.
Master: [DEBUG    Nuvola] WebApp.vala:210: Theme icon nuvolaplayer3_jango 48 not found.
Master: [DEBUG    Nuvola] WebApp.vala:210: Theme icon nuvolaplayer3_kexp 48 not found.
Master: [DEBUG    Nuvola] WebApp.vala:210: Theme icon nuvolaplayer3_logitech_media_server 48 not found.
Master: [DEBUG    Nuvola] WebApp.vala:210: Theme icon nuvolaplayer3_mixcloud 48 not found.
Master: [DEBUG    Nuvola] WebApp.vala:210: Theme icon nuvolaplayer3_plex 48 not found.
Master: [DEBUG    Nuvola] WebApp.vala:210: Theme icon nuvolaplayer3_siriusxm 48 not found.
Master: [DEBUG    Nuvola] WebApp.vala:210: Theme icon nuvolaplayer3_soundcloud 48 not found.
Master: [DEBUG    Nuvola] WebApp.vala:210: Theme icon nuvolaplayer3_spotify 48 not found.
Master: [DEBUG    Nuvola] WebApp.vala:210: Theme icon nuvolaplayer3_test 48 not found.
Master: [DEBUG    Nuvola] WebApp.vala:210: Theme icon nuvolaplayer3_tunein 48 not found.
Master: [DEBUG    Nuvola] WebApp.vala:210: Theme icon nuvolaplayer3_yandex_music 48 not found.
Master: [DEBUG    Nuvola] WebApp.vala:210: Theme icon nuvolaplayer3_youtube 48 not found.
Master: [DEBUG    DioriteGtk] application.vala:219: XFCE session vanished: org.xfce.SessionManager
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app 8tracks at /usr/share/nuvolaplayer3/web_apps/8tracks-link, version 5.2
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Amazon Cloud Player at /usr/share/nuvolaplayer3/web_apps/amazon_cloud_player-link, version 5.4
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Bandcamp at /usr/share/nuvolaplayer3/web_apps/bandcamp-link, version 2.2
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Deezer at /usr/share/nuvolaplayer3/web_apps/deezer-link, version 2.7
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Google Play Music at /usr/share/nuvolaplayer3/web_apps/google_play_music-link, version 5.19
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Groove at /usr/share/nuvolaplayer3/web_apps/groove-link, version 1.3
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Jango at /usr/share/nuvolaplayer3/web_apps/jango-link, version 2.3
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app KEXP Live Stream at /usr/share/nuvolaplayer3/web_apps/kexp-link, version 1.2
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Logitech Media Server at /usr/share/nuvolaplayer3/web_apps/logitech_media_server-link, version 2.2
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Mixcloud at /usr/share/nuvolaplayer3/web_apps/mixcloud-link, version 3.2
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Plex Music at /usr/share/nuvolaplayer3/web_apps/plex-link, version 1.3
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app SiriusXM at /usr/share/nuvolaplayer3/web_apps/siriusxm-link, version 1.3
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app SoundCloud at /usr/share/nuvolaplayer3/web_apps/soundcloud-link, version 1.3
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Spotify at /usr/share/nuvolaplayer3/web_apps/spotify-link, version 2.3
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app TuneIn at /usr/share/nuvolaplayer3/web_apps/tunein-link, version 1.3
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Yandex Music at /usr/share/nuvolaplayer3/web_apps/yandex_music-link, version 1.4
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app YouTube at /usr/share/nuvolaplayer3/web_apps/youtube-link, version 1.3
Master: [DEBUG    Nuvola] WebAppRegistry.vala:169: Found web app Test at /usr/share/nuvolaplayer3/web_apps/test, version 1.0
Master: [INFO     Nuvola] WebAppRegistry.vala:89: Using web app YouTube, version 1.3, data dir /usr/share/nuvolaplayer3/web_apps/youtube-link
Master: [DEBUG    Nuvola] MasterController.vala:378: Launch app runner for 'youtube': /usr/lib/nuvolaplayer3/apprunner -D -a /usr/share/nuvolaplayer3/web_apps/youtube-link
Runner: [DEBUG    DioriteGtk] DesktopShell.vala:96: Shell: mutter(deepingala) (null), CSD 0, appmenu 0, menubar 0
Runner: [DEBUG    DioriteGtk] application.vala:219: XFCE session vanished: org.xfce.SessionManager
Master: [DEBUG    Nuvola] MasterController.vala:284: Connected to runner server for 'youtube'.
Runner: [DEBUG    Nuvola] Connection.vala:132: Network Proxy: system settings
Runner: [DEBUG    Nuvola] WebEngine.vala:73: Nuvola WebKit Extension directory: /usr/lib/nuvolaplayer3
Runner: [WARNING  DioriteGtk] actionsregistry.vala:170: Action 'donate' not found in registry.
Runner: [DEBUG    Nuvola] Notifications.vala:175: Notifications: persistence false, actions false, icons false
Master: [DEBUG    Nuvola] MediaKeys.vala:134: GNOME settings daemon vanished: org.gnome.SettingsDaemon
Runner: [DEBUG    Nuvola] AppRunnerController.vala:416: Component tray_icon (Tray Icon) not enabled
Runner: [DEBUG    Nuvola] AppRunnerController.vala:416: Component notifications (Notifications) enabled
Runner: [DEBUG    Nuvola] AppRunnerController.vala:416: Component mediakeys (Media keys) enabled
Runner: [DEBUG    Nuvola] AppRunnerController.vala:416: Component scrobbler (Audio Scrobbler Services) enabled
Runner: [DEBUG    Nuvola] AppRunnerController.vala:416: Component mpris (MPRIS 2) enabled
Runner: [DEBUG    Nuvola] AppRunnerController.vala:416: Component lyrics (Lyrics) enabled
Runner: [DEBUG    Nuvola] AppRunnerController.vala:416: Component developer (Developer's tools) enabled
Runner: [DEBUG    Nuvola] MPRISProvider.vala:73: Bus acquired: org.mpris.MediaPlayer2.NuvolaAppYoutube, registering objects
Runner: [DEBUG    Nuvola] MPRISProvider.vala:90: Bus name acquired: org.mpris.MediaPlayer2.NuvolaAppYoutube
Worker: [DEBUG    Nuvola] WebExtension.vala:203: Page 1 created for (null)
Worker: [DEBUG    Nuvola] WebExtension.vala:212: Document loaded about:loading
Runner: [DEBUG    Nuvola] WebEngine.vala:496: Navigation, current window: uri = https://www.youtube.com/watch?v=y3KEhWTnWvE&list=TLGGP10gZ43XsJ8yNTA3MjAxNw&index=2, result = true, frame = (null), type = WEBKIT_NAVIGATION_TYPE_OTHER
Runner: [DEBUG    Nuvola] FormatSupport.vala:110: Trying to play /usr/share/nuvolaplayer3/audio/audiotest.mp3.
Runner: [DEBUG    Nuvola] FormatSupport.vala:110: Pipeline state changed from NULL to READY.
Runner: [DEBUG    Nuvola] FormatSupport.vala:110: Pipeline state changed from READY to PAUSED.
Runner: [DEBUG    Nuvola] FormatSupport.vala:110: Pipeline state changed from PAUSED to PLAYING.
Runner: [DEBUG    Nuvola] FormatSupport.vala:110: End of stream for file /usr/share/nuvolaplayer3/audio/audiotest.mp3.
Runner: [DEBUG    Nuvola] FormatSupportCheck.vala:145: Nuvola.WebPlugin: Shockwave Flash (enabled, flash) at /usr/lib/adobe-flashplugin/libflashplayer.so: Shockwave Flash 26.0 r0
Runner: [DEBUG    Nuvola] FormatSupportCheck.vala:145: Nuvola.WebPlugin: IcedTea-Web Plugin (using IcedTea-Web 1.6.2 (1.6.2-3.1)) (enabled, not flash) at /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so: The IcedTea-Web Plugin executes Java applets.
Runner: [DEBUG    Nuvola] WebAppWindow.vala:170: Sidebar position: 955
Worker: [DEBUG    Nuvola] WebExtension.vala:113: Window object cleared for 'https://www.youtube.com/watch?v=y3KEhWTnWvE&list=TLGGP10gZ43XsJ8yNTA3MjAxNw&index=2'
Worker: [DEBUG    Nuvola] WebExtension.vala:123: Init frame: https://www.youtube.com/watch?v=y3KEhWTnWvE&list=TLGGP10gZ43XsJ8yNTA3MjAxNw&index=2, 0x55e097d9d840, 0x55e09799b320, 0x7f4aa0dd00e8
Runner: [DEBUG    Nuvola] WebEngine.vala:496: Navigation, current window: uri = https://p2-llin5jo464rrw-cy2p3ukkp7ve7j2r-if-v6exp3-v4.metric.gstatic.com/v6exp3/iframe.html, result = true, frame = (null), type = WEBKIT_NAVIGATION_TYPE_OTHER
Worker: [DEBUG    Nuvola] WebExtension.vala:212: Document loaded https://www.youtube.com/watch?v=y3KEhWTnWvE&list=TLGGP10gZ43XsJ8yNTA3MjAxNw&index=2
Runner: file:///usr/share/nuvolaplayer3/web_apps/youtube-link/integrate.js:122:24: CONSOLE LOG YouTube API connection error: TypeError: window.yt.player.getPlayerByElement is not a function. (In 'window.yt.player.getPlayerByElement('player-api')', 'window.yt.player.getPlayerByElement' is undefined)
Runner: [DEBUG    Nuvola] DeveloperSidebar.vala:158: Media player notify: artwork-location
Runner: libva info: VA-API version 0.39.4
Runner: libva info: va_getDriverName() returns 0
Runner: libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
Runner: libva info: Found init function __vaDriverInit_0_39
Runner: libva info: va_openDriver() returns 0
Runner: libva info: VA-API version 0.39.4
Runner: libva info: va_getDriverName() returns 0
Runner: libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
Runner: libva info: Found init function __vaDriverInit_0_39
Runner: libva info: va_openDriver() returns 0
Runner: libva info: VA-API version 0.39.4
Runner: libva info: va_getDriverName() returns 0
Runner: libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
Runner: libva info: Found init function __vaDriverInit_0_39
Runner: libva info: va_openDriver() returns 0
Analyzing the log, there is a message window.yt.player.getPlayerByElement is not a function. Maybe that is the cause of this issue? Or it happens because the player was not loaded? (Error message in https://00683182289321774129.googlegroups.com/attach/3cf2ad7546a1/DeepinScreenshot_eu.tiliado.NuvolaAppYoutube_20170725211332.png?part=0.1&view=1&vt=ANaJVrGuda7c89MIoWmm1WwSAPRGId2aThJ5E3A2WfwxzEtoMBiJxrnr8b61NLC4qgKmOIpKNg1zxx2WCOZLa7IG0bkyx20hpPKj10v0T706U1JDYXQOLZo)

The error comes from https://github.com/tiliado/nuvola-app-youtube/blob/master/integrate.js#L105
this.vPlayer = window.yt.player.getPlayerByElement('player-api');

I'll check the player-api is still valid, maybe youtube updated this.

See also #11

Hello @jrosco. Any progress on this issue?

no progress yet, I'll find some time this week to work on this.

Fixed in the latest YouTube flatpak.


[Fix #11758] Fix a false positive for Style/RedundantLineContinuation

Fixes #11758.
This PR fixes a false positive for Style/RedundantLineContinuation when line continuations for string.

Before submitting the PR make sure the following are checked:

[x] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
[x] Wrote good commit messages.
[x] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[x] Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
[x] Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

Hm, especially #ends_with_backslash_without_comment? may have some problem. Any other method would be preferable to the regexp. I think the issue can be clarified and dealt with separately.


add "Compass Compiled!" notification

I took this out for a couple of reasons:

it seems like more and more elixir plugins were removing the "success" message
this message is slightly annoying if you save a lot.  I found myself constantly looking at the corner of my screen...eventually I went "blind" to the messages showing up and then I'd miss the one error message that I do need to see.

Thoughts?  What if turning on the success message happened via a parameter that you passed in?

I added this, because, when I didn't receive that success message, I thought I was doing something wrong and the compilation wasn't successful.
After adding it, it was more clear that, everything was working well.
I agree with you, that when saving frequently, those messages can be pretty disturbing. I like the idea of passing parameter, but what about setting it in configurations?
Something like this:
elixir.config.notifications = {boolean};

Yea, I think a config value would be great.

Say your word here: https://github.com/laravel/elixir/issues/63


Update how-to-authenticate-an-ews-application-by-using-oauth.md

await missing...

thanks @iwhp harry!


Install sass-loader, refactor .vue components to use scss #167

Will install sass-loader and update all components to use scss. #167
Motivation
The current vue.js setup allows only to write styles in pure css. This can be quite time consuming, error-prone and leads to redundant code. In order to use variables, mixins and all other handy tools I would suggest using a preprocessor. In vuejs this can be easily achieved by installing the preferred webpack loader. My suggestions would be to use SCSS because it has the same syntax as CSS and can therefore easily be adapted by people new to preprocessores.
Expected Behavior
I can write component styles with scss/sass/less/stylus and it gets compiled to css
Current Behavior
using <style lang="scss"> leads to compile time error
Possible Solution
install missing webpack loaders

Thanks!