Activating features for tests/benchmarks

Given a library crate, I want to have optional features which are available to integration-level tests and examples so that 'cargo test' tests them.
Here's what I have:
[package]
name = "rustls"
version = "0.1.0"
(etc)

[features]
default = []
clientauth = []

[dependencies]
untrusted = "0.2.0"
(etc)

[dev-dependencies]
env_logger = "0.3.3"
(etc)

Here's what I've tried so far. Attempt one: add the crate into dev-dependencies with the feature, ie:
[dev-dependencies.rustls]
path = "."
version = "0.1.0"
features = ["clientauth"]

I kind of expected that to work, but it panics:
jbp@debian:~/rustls$ RUST_BACKTRACE=1 cargo test
thread '<main>' panicked at 'assertion failed: my_dependencies.insert(dep.clone())', src/cargo/util/dependency_queue.rs:86
stack backtrace:
   1:     0x558d17c3a2a0 - std::sys::backtrace::tracing::imp::write::h9fb600083204ae7f
   2:     0x558d17c4383b - std::panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::hca543c34f11229ac
   3:     0x558d17c434c3 - std::panicking::default_hook::hc2c969e7453d080c
   4:     0x558d17c28048 - std::panicking::rust_panic_with_hook::hfe203e3083c2b544
   5:     0x558d17701fef - std::panicking::begin_panic::h4ebf9fe884b2415f
   6:     0x558d17802d27 - cargo::ops::cargo_rustc::job_queue::JobQueue::enqueue::h98b20a33b8744ebe
   7:     0x558d177f4faf - cargo::ops::cargo_rustc::compile::h93336dd21aba29d0
   8:     0x558d1777a513 - cargo::ops::cargo_rustc::compile_targets::h7223dffae01d6b9d
   9:     0x558d1776eec9 - cargo::ops::cargo_compile::compile_pkg::h48656ffa9b1541f3
  10:     0x558d1776bd09 - cargo::ops::cargo_compile::compile::h1b43b20047c53d10
  11:     0x558d1785fb0d - cargo::ops::cargo_test::compile_tests::h028a22d3131e0d65
  12:     0x558d1785f379 - cargo::ops::cargo_test::run_tests::h0ad98c54a6f40c9d
  13:     0x558d176de256 - cargo::call_main_without_stdin::hd484f08b17c419d1
  14:     0x558d1768afe7 - cargo::execute::hab7accd6bf9b5c64
  15:     0x558d17683f8b - cargo::call_main_without_stdin::hf099bd36acb849a3
  16:     0x558d17680da1 - cargo::main::h2b219a79f378c1ef
  17:     0x558d17c430d8 - std::panicking::try::call::hc5e1f5b484ec7f0e
  18:     0x558d17c4e0eb - __rust_try
  19:     0x558d17c4e08e - __rust_maybe_catch_panic
  20:     0x558d17c42b03 - std::rt::lang_start::h61f4934e780b4dfc
  21:     0x7f79ea9bf86f - __libc_start_main
  22:     0x558d17680728 - <unknown>

(version: "cargo 0.11.0-nightly (259324c 2016-05-20)")
Attempt two: see if features.* works like profile.*:
[features.test]
default = ["clientauth"]

alas
$ cargo test
error: failed to parse manifest at `/home/jbp/rustls/Cargo.toml`

Caused by:
  expected a value of type `array`, but found a value of type `table` for the key `features.test`

Is this possible?
See also #4663

Unfortunately, no, it's not possible for cargo test to automatically enable features currently. The panic though definitely seems bad!

I just ran into this issue because I'm currently using a feature to decide whether or not to do some rather verbose tracing. I'd like to be able to set this during testing so that when tests fail I can look at the trace.
The reason I made it a feature is that the code itself is in a library, but at the same time it seems more appropriate to have the consuming crate decide whether or not to perform the trace.
To be clear, an actual consuming crate has no problem setting the feature and getting corresponding results. It is just for testing the library crate itself that it doesn't seem possible at the moment.

@alexcrichton:
As of yet, the Cargo panic is gone.
  cargo --version
cargo 0.19.0-nightly (fa7584c14 2017-04-26)

The output is now as follows:
Excerpt from Cargo.toml
[features]
default = [] # "clippy"

[profile.test]
default = ["clippy"]

cargo test --color=always --package my_app --bin my_app test_1 -- --nocapture
warning: unused manifest key: profile.test.default
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running target/debug/deps/structure_web_server-3dc5f86e9b4fb259

running 1 test
test tests::test_1 ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured

You wrote this isn't possible. It appears there are no immediate objections to adding such a feature. Could you explain how fundamental the limitation is? And, if possible, sketch a solution? Just so a PR becomes more likely to happen.

Ah I believe this was fixed in https://github.com/rust-lang/cargo/pull/3921 as https://github.com/rust-lang/cargo/issues/3902 was a dupe of this issue. I guess I was wrong before!

@alexcrichton: the crashes have been resolved yes, but the original feature request still stands AFAIK. Reopen?

Oh sorry, missed that aspect.

Is there any way to add features per profile now? That is, if I want to enable certain features during tests, can I do that yet?

@sunjay unfortunately no, you'll still need to pass --features on the command line

Is this change something that would require an RFC or could it just be implemented? It sounds like being able to specify features in the profile configuration is something that could benefit a lot of people.

@sunjay I think due to the subtle possible ramifications of auto-enabling features I'd personally want to see an RFC, but it may be worth canvassing others from @rust-lang/cargo first as well

I would love to work on an RFC for this. Very interested to hear what the cargo team thinks.
Right now, I'm having to constantly remember to pass features in when I run cargo test. I would really prefer to not have to do that. It's an extra point of friction for anyone who uses my code.
Though it would be great to even just be able to configure features in tests, I would really like to see cargo support a features/default features option in each of the [profile.*] sections. My RFC would be proposing something like that.

I think we have an RFC by @withoutboats for this already: https://github.com/rust-lang/rfcs/pull/1956, which is postponed because of profiles.

@matklad Ah yup that's exactly what I would have proposed. Thanks for looking that up! I read the discussion and it seems like that's pending on some work with how multiple profiles are applied together (e.g. test --release). It seems that the current behavior is more complicated than what it looks like at first glance.
Is there any way to do this in a backwards compatible way? It would be great if there was some way to just add another configuration option that is in effect the same as the command line argument while keeping everything the same as it is now. Would that make it too hard to change to something better (like profiles) later?
The main issue I'd like to solve is that right now, introducing features into your codebase makes it so that you have to pass features in as command line arguments every time you run a certain commands. If these aren't default features that you need for all builds, it's not possible to simply configure the ones you want in Cargo.toml. This makes it harder for people new to your codebase or to cargo set things up. It is very repetitive and easy to forget. Is there an easier way to just address that issue?

I've also run into the need to have features automatically enabled in test builds. In my case I want the python bindings "extension-module" feature on for production builds, but off for test builds so that I can link directly to python during testing.

Also it's very useful for #![no_std] ergonomics. Since you need to test with libstd linked, otherwise you get
error: no #[default_lib_allocator] found but one is required; is libstd not linked?. So you constantly running cargo test --features std

Note that you can do this with required-features if you specify your test targets explicitly, aka:
[[test]]
name = "whatever"
path = "tests/whatever.rs"
required-features = ["mycoolfeature"]

@ebfull That only skips building/running tests if feature is not enabled instead of force-enabling the feature during build.

Some ugly workaround, at least for some cases, is to extend all your #[cfg(feature = ...)] with test (e.g. #[cfg(any(test, feature = "..."))] and copy all optional dependencies in [dev-dependencies] and remove optional = true.
It works nice for me but for sure there are cases where it is not enough.

Yea I feel like an RFC here would make sense if one doesn't already exist. I'm using rust again, and finding myself really wanting something like cargo test --feature-matrix for example.

Some ugly workaround, at least for some cases, is to extend all your #[cfg(feature = ...)] with test (e.g. #[cfg(any(test, feature = "..."))] and copy all optional dependencies in [dev-dependencies] and remove optional = true.
It works nice for me but for sure there are cases where it is not enough.

I like your trick, but unfortunately, it does not work for the documentation tests (not sure why, though).

Having something akin to #[features("chrono", "alloc")] and so on to set a specific feature set for a test module (with #[features()] to use no features) would be awesome! Of course, having this functionality available elsewhere is probably not a great idea.
Of course, this might not even be feasible without rewriting the core of the testing framework, but perhaps it could be a nice quality of life feature to look at down the line.

If you have a workspace going, a better workaround is to create a test_utils crate. You can make the feature activate automatically for an integration test.
# test_utils crate
[dependencies]
main = { path = "../main", features = ["test"] }

pub use main as main_test;
// or, may as well use this crate to compile the integration testing infrastructure
pub fn exported(file: &str) { main::whatever(); assert_eq!(1, 1); }

// main crate
[features]
test = []

[dev-dependencies]
datatest = "..."
test_utils = { path = "../test_utils" }

// lib.rs
cfg_if::cfg_if! {
    if #[cfg(feature = "test")] {
        fn whatever() { do_something_else(); }
    } else {
        fn whatever() {}
    }
}

# tests/integration.rs
use test_utils::main_test as main;
use test_utils::exported;

#[datatest::files( ... )]
fn integration(file: &str) {
   exported(file);
}

Lotta moving parts but I think I wrote it all right.

What's the current state on this, has there been another RFC?

@cormacrelf unfortunately that doesn't work for my case, where I have multiple features I'd like to test. My current workaround is to use a makefile to keep track of different test crates, and each of those depends on the main crate with specific features turned on. With workspaces, you can't mix features. Would really love to see some  progress here, and I'd be willing to help with the RFC if help is needed.

We are working on a really big project and use a lot of protobuf structs. Now we want enable Serialize and Deserialize on those struct only under test situations, but found control through features may be our only choice:
First we have a lot of structs define like this
// crate a, which dependens on crate b
#[cfg_attr(feature = "with-serde", Serialize, Deserialize)]
struct Foo {
    bar: Bar
}

// crate b
#[cfg_attr(feature = "with-serde", Serialize, Deserialize)]
struct Bar {
    b: i32
}

Then we want write tests for crate a
#[cfg(test)]
mod tests {
    #[test]
    fn my_test() {
         let foo: Foo = serde_json::from_str("xxxxx");
         balabala.....
    }
}

We have to add #[cfg(feature = "with-serde")] for my_test or for mod tests, or the clippy will complain about not implement Serialize/Deserialize for Foo.
We alse have tried with using #[cfg_attr(test, Serialize, Deserialize)] instead of #[cfg_attr(feature = "with-serde", Serialize, Deserialize)], but found that when we run test for crate a, crate b won't have cfg_attr(test) to be true, which will lead Serialize/Deserialize not implement for Bar.
Another choice is use other config attribute instead of test, such as #[cfg_attr(with_serde, Serialize, Deserialize)], but this needs additional effort for both writing tests and running tests.
If we can have default features for test, it seems is the simplest way to solve this problem😋

Hi :wave:,
I have a bit of a simpler case, where I only want to activate one feature (testing), which serves the test infrastructure for all tests.
The simplest workaround I could figure out is to add the library itself with the desired feature to the dev-dependencies in Cargo.toml:
[dev-dependencies]
my_lib = { path = ".", features = ["testing"] }

[features]
testing = []

This is obviously not as fine-grained as per-profile-features, but maybe helps some folks 😁
Cheers

There is currently a work-around for this. (Source)
[dev-dependencies]
self-package-name= { path = ".", features = ["desired_feature"] }

where self-package-name is the name of the package in the Cargo.toml file.

There is currently a work-around for this. (Source)

@DesmondWillowbrook This seems to activate desired_feature even during non-dev build, for some reason.

 This is weird.

There is currently a work-around for this. (Source)
[dev-dependencies]
self-package-name= { path = ".", features = ["desired_feature"] }

where self-package-name is the name of the package in the Cargo.toml file.
Sample repo for the same

Unfortunately this doesn't seem to work on an edge case in a no_std environment where your crate allows no_std and has a feature which enables std. Here's an example of where the issue can occur:
error[E0152]: found duplicate lang item `panic_impl`
  --> package/src/main.rs:15:1
   |
15 | fn panic(_info: &PanicInfo) -> ! {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: the lang item is first defined in crate `std` (which `sprawl_format` depends on)
   = note: first definition in `std` loaded from /home/owen/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-3d933644112ba794.so, /home/owen/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-3d933644112ba794.rlib
   = note: second definition in the local crate (`sprawl_package`)

error: aborting due to previous error

For more information about this error, try `rustc --explain E0152`.
error: could not compile `sprawl-package`

To learn more, run the command again with --verbose.

I assume this is because its importing std for the developer dependencies section, and this function is trying to overwrite a now-included package.

The workaround for this workaround seems to be
#[cfg(not(test))]
// std overriding code here

In cases where std is acceptable if you still want to test :smile:

This seems to activate desired_feature even during non-dev build, for some reason.

Unfortunately this doesn't seem to work on an edge case in a no_std environment where your crate allows no_std and has a feature which enables std.

I assume this is because its importing std for the developer dependencies section, and this function is trying to overwrite a now-included stdlib function.

EDIT: This may actually be a bug with workspacing? if I delete my workspace file and use them separately this works fine. The other option is that I'm doing something wrong :smile:

Indeed the issue is simply because of the old bug of features from dependencies and dev-dependencies being unified, see #4866. This is fixed by using the new resolver.

God

There is currently a work-around for this. (Source)
[dev-dependencies]
self-package-name= { path = ".", features = ["desired_feature"] }

where self-package-name is the name of the package in the Cargo.toml file.
Sample repo for the same

This may be another thing worth pointing out with this approach: cargo seems to strip this specific reference to self-package-name from dev-dependencies when packageing and publishing. Meaning if you require desired_feature for, say, testing the package, tests may not work as expected on the published package unless you manually enable this feature. Typically that's not a problem, but it was unexpected to me and one can certainly construct cases where it matters.

[dev-dependencies]
self-package-name= { path = ".", features = ["desired_feature"] }

I tried this, and it worked like a charm except that when I run cargo test --no-default-features, the default features of my package are still enabled.  My theory is that since the explicit development dependency on self-package-name does not specify default-features = false, it activates the default features of the target package just like any other dependency would, but in this case, the target package happens to be the current package.  So even if I tell Cargo not to activate the default features, they still get activated by Cargo's feature unification rules.  If I change the workaround to:
[dev-dependencies]
self-package-name = { path = ".", default-features = false, features = ["desired_feature"] }

then I get the behavior I want: plain cargo test activates the default features and cargo test --no-default-features doesn't.  So I posit that the above is a superior version of the workaround in general, but if you don't use cargo test --no-default-features, it's fine to stick with the simpler version.

Allowing build-targets to force features to be on was proposed in rust-lang/rfcs#3374 but that was closed due to the challenges with feature unification and the ability to ensure a code base works with all combinations of publicly available features

I'm going to propose to the cargo team that we close this
We have the following workarounds

According to the comments, having a dev-dependency on yourself (so long as package.resolver="2" is set) will work
test.required-features exists
#[cfg()] on the relevant tests/mods

We also have #1982 tracking build-target-specific dependencies.   rust-lang/rfcs#3374  was an offshoot of that which was closed due to challenges with feature unification.

test.required-features exists

As far as I'm understanding that only enables the tests if the features are all available, not the other way around. The dev-dependencies thing also seems like a hack.

As far as I'm understanding that only enables the tests if the features are all available, not the other way around.

What would help is to say what use case is not well served by required-features.
Something to also keep in mind is that this feature was in a way covered by  rust-lang/rfcs#3374 but it was abandoned.  Feature unification is already a really difficult problem for users and it made it even worse.

Because running all tests is important, and not all tests need every feature (or even work with every feature). The unfortunate reality is that "features should be additive" isn't possible in every single case, so the assumption that --all-features work in all cases isn't sound. Thus, in order to run every single test possible in a crate, in cases where some features are incompatible with others, then there must be different feature sets enabled in different cases in order to run 100% of the tests.
As it stands, that means multiple invocations, and even then, there's a high chance you miss a test suite because a feature config was changed somewhere but whatever script you use to run each cargo test invocation wasn't also updated, and there's no way to error or fail the CI/CD process when that occurs because there's no way to detect such a case.

I think i'm missing something because it sounds like you are saying that enabling all features is a problem, meaning you need to enable different sets of features.  To me, that sounds like a test shouldn't be enabling features automatically but should instead be left up to the caller.  On top of this, having tests enable some features means that you can't test without them and it is easy to break feature interactions that you don't test.
Some ways of dealing with testing

When its not too much, cargo hack can automatically enumerate combinations of features
Having a build orchestrator capture specific sets of features used and test them (in clap I use make for this)

#10882 would allow encoding these feature sets as features

In case of jj, the tests use a couple of binaries for a "fake editor" (for example). We need some way to not have these binaries installed when the user runs cargo install jj-cli. The lack of fake editor in the binary releases also caused cargo binstall to refuse to install jj-cli.
In https://github.com/martinvonz/jj/pull/2277, I used the dev-dependencies hack to acheive this. Unfortunately, that doesn't work well with rust-analyzer, see e.g. https://github.com/rust-lang/rust-analyzer/issues/14167 . Other than that, it'd work.
For my purpose, I don't need any conditional compilation within a crate, only a way to prevent generating some binaries outside of tests.

Thanks @ilyagr for the clear use case!
Access to test binaries is a sore point right now I can see how this helps in that case.  Another feature that could help is artifact dependencies

Here's another use case from our GUI application Packetry.
Although our codebase does include some unit tests written in the usual way with #[cfg(test)] and #[test], the vast majority of testing is carried out by a specific test called test_replay. This test replays a large amount of input data and user actions into the UI code, and checks the results.
That test has to be declared in Cargo.toml with harness = false, because it calls into GTK, and on macOS, GTK can only be called from a program's original main thread. The standard cargo test harness does not run tests in the main thread, even if you run cargo test with -j 1. So we have to write the test as a standalone binary without the standard harness, or it won't work on macOS.
To achieve the testing we want, we have to add a bunch of logging output to our normal UI code. We don't ever want that logging code at normal runtime. It's only there for testing. But we can't gate it behind #[cfg(test)], because that isn't enabled when building our separate test binary: it only applies for tests specified in the standard way. So we have to gate the logging code behind a feature instead, which we call test-ui-replay.
Most of the above details aren't relevant: what matters is just that we have a custom test, not using the standard harness, which requires some feature, and which we want to always be run.
In Cargo.toml, we use required-features to specify that the test_replay test requires the test-ui-replay feature. But we still have to specifically request that feature, every time we test: cargo test --features=test-ui-replay
What we want is to be able to just run cargo test, and have this test always be run. It's absolutely fine that we won't be able to test without that 'feature'. That's exactly what we want. In our case it's not even a feature in the normal sense - it's only there because we can't use #[cfg(test)], which in turn is because we're not using the standard test harness for that test.
I've just tried, and the dev-dependency hack works for us. But that's not documented anywhere other than this thread, and the discussion in #9518 says that this isn't really something that should be allowed, and the only reason it's not being made an error yet is that it allows working round this issue. That doesn't sound like something we should be relying on.
I am opposed to closing this issue without either a proper solution, or another issue left open tracking what's needed.
The proposal to close suggests:

the self-dev-dependency hack: as above, this seems to only work by accident, and is not documented as supported.
test.required-features: we're already using this, it doesn't solve our problem.
#[cfg()] on the relevant tests/mods: we're already using this, it doesn't solve our problem.
#1982: this only covers build-target-specific dependencies, not features required in the current package.
#3374: this RFC is closed, and there's no other current proposal.

Most of the above details aren't relevant: what matters is just that we have a custom test, not using the standard harness, which requires some feature, and which we want to always be run.

Actually it is relevant, particularly the combination of (1) tests that need access to private APIs or behaviors and (2) not being able to write these as unit tests.
This kind of information is the core of whats needed to decide how important a use case is and how to handle it.
Is the logged information access through a feature-gated API or is it exposed through stdio / GUI?

@ilyagr another potential workaround is to have the test bins auto-discovered b
but to ensure they aren't included in the published artifact (.crate) via package.include or package.exclude.

@epage

another potential workaround is to have the test bins auto-discovered b but to ensure they aren't included in the published artifact (.crate) via package.include or package.exclude.

Could you elaborate? I'm far from an expert on Cargo.toml. I'm not sure what "auto-discovered" means.
Naively, I was wondering whether there could be a dev-dependency on a separate crate for the fake binaries, but I'm not sure whether the tests will be able to find the binaries from another crate.

Actually it is relevant, particularly the combination of (1) tests that need access to private APIs or behaviors and (2) not being able to write these as unit tests (with enough context to understand the "why")

I take your point; I was just trying to pre-emptively avoid the discussion getting dragged into the weeds of why GTK/macOS has that particular annoying limitation, when there are any number of other reasons why someone might want to have tests that don't use the standard test harness.

Is the logged information access through a feature-gated API or is it exposed through stdio / GUI?

The test creates a UI in the same way the normal program would, but the feature causes the UI to be created off-screen, with logging code. The test then uses feature-gated APIs on the UI to set where to direct the logging, and also to inject a sequence of pre-recorded user actions into the UI. The log output is then compared against a reference file, and if the two match, the test passes.
As I understand it, the reason that #[cfg(test)] doesn't work for us is that the UI code is in a library target, and that library target is built without cfg(test) set, because a standalone test is presumed to be an integration test that only uses public APIs. In fact, we don't have any truly public API at all - we don't publish a library crate. The library target only exists so that we can share UI code between the main program and the replay test.

For our particular use case, if there were a way to tag a unit test as "must be run in the main thread of a process", and have Cargo honour that somehow (either by executing from its main thread or spawning a new process), then that would be a better solution for us. Originally test_replay was just a unit test in main.rs; it's only because that wouldn't work on macOS that I had to break up main.rs into lib.rs, ui.rs, and test_replay.rs so that it could run as a standalone test.

Put most of your code in a lib and have another package depend on it, activating the feature that is needed, and have the tests live there.

I have just verified that yes, it is possible to make cargo test work as desired by further splitting what was originally a simple, single-binary project into three different packages, with four Cargo.toml files. But what was the point of this suggestion?
Yes, it is possible to work around the lack of the feature that people are asking for in this issue. That doesn't make the feature request invalid. The complexity of the workarounds you're suggesting illustrate exactly why it would be helpful.

Adding accessibility support (which would likely be a lot of work) as that tends to have enough overlap for testing

Even with a lot of work, I do not believe that it would be either practical or performant for us to implement the same test through the GTK accessibility APIs. We're not just clicking on some buttons and looking for dialog messages. We're dealing with a list model with what may be millions of rows that the UI loads from on demand. And the test also needs to control the inflow of packets into the decoder engine so that it can verify how descriptions of items are updated by new packets. There's no way to do all that through the normal application UI, we have to hook into it specially, and that requires gating some code.
But even if we could, the fact that this may a suitable solution for some GUI applications doesn't invalidate the use cases where it isn't.
Why is there so much desire to close this? I don't really see anyone asking for anything complicated here. A solution could be as simple as a Cargo.toml key that makes cargo test behave as if you'd typed cargo test --features=foo,bar. As far as I can see, it doesn't need to affect how feature unification works, or any other Cargo internals. It's just about setting some defaults per-profile on the frontend side.

I have just verified that yes, it is possible to make cargo test work as desired by further splitting what was originally a simple, single-binary project into three different packages, with four Cargo.toml files. But what was the point of this suggestion?
Yes, it is possible to work around the lack of the feature that people are asking for in this issue. That doesn't make the feature request invalid. The complexity of the workarounds you're suggesting illustrate exactly why it would be helpful.

I would assume you could get away with just two packages and two Cargo.toml files (workspace + lib + main bin, test bin)
As for the point, it was to offer another alternative solution for people running into it.  It might work for some people; it might not work for others.  It does offer the benefit of having the minimal affect on feature activations which is likely needed in some other cases.
I do feel it important to call out that what is important in an issue is the use cases.  We shouldn't get attached to any given solution.

Why is there so much desire to close this? I don't really see anyone asking for anything complicated here. A solution could be as simple as a Cargo.toml key that makes cargo test behave as if you'd typed cargo test --features=foo,bar. As far as I can see, it doesn't need to affect how feature unification works, or any other Cargo internals. It's just about setting some defaults per-profile on the frontend side.

I think there might be a misunderstanding.  None of this is "arguing back to force through a closure".  I am trying to understand use cases and explore the problem space.    The question is whether this is still the right solution.  That, I'm still not sure on.
And yes, we can add a lot of little features like this but

I've found the more features you have, the less value you get out of them because you overwhelm users and they can't find what they need to solve problems.  Its best to look for patterns in case you can find wider ways of solving problems.  There might even be times when its appropriate to say "this is too narrow of case for built-in support so long as there are valid workarounds"
We need to consider the whole workflow and how the feature is used to ensure we are helping drive the right behavior, while still allowing the exception cases.  Otherwise, a "simple" issue like this could turn into 10 more issues that want to extend whatever solution we come up with in 100 different ways because it doesn't quite work for them.

I think there might be a misunderstanding. None of this is "arguing back to force through a closure". I am trying to understand use cases and explore the problem space.

That intent would have been clearer had you not first entered the discussion with a proposal to close, and then proceeded to respond to use cases by listing workarounds.
But anyway. In our specific case, as I already said, I don't think this feature is actually the best solution to our problem. What we have is really a unit test, we're just lacking a way to specify that this unit test must be executed on the main thread of a program. I guess I should go raise that as a feature request for libtest.

A solution could be as simple as a Cargo.toml key that makes cargo test behave as if you'd typed cargo test --features=foo,bar. As far as I can see, it doesn't need to affect how feature unification works, or any other Cargo internals.

Are you proposing something like #4942? It doesn't seem too hard in terms of supporting that. However but I've outlined some unresolved questions around that needing to be addressed.
If we look into RFC 3374 a bit deeper, there is a paragraph calling out some difficulties and open questions on the implementation side. I know it looks not too hard but things are under the surface 😞.
Anyway, thank you for bringing more info on the table.


dark mode - signature pad area too dark

In dark mode, the signature pad is too dark -> dark stroke -> dark area
features User -> Mobile components screen

Changed the backgroud color and also the pen color in dark mode

please remove the border or set a "not so black" color
The rest is perfect


Printer redirect

Version: 2.2-feature
CUPS.org User: jarichar
Requesting the ability to redirect a print queue to another.  For example if a printer breaks provide the ability to send its entire print queue to another queue or maybe multiple queues. Similar to the redirect command functionality that exists in LPRNG.

After review we have decided not to address this issue.


⚠ Bofrost.lu has degraded performance

In a9fe340, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1324 ms

Resolved: Bofrost.lu performance has improved in 874dba9 after 41 minutes.


New Black Eeprom DS28 for Stratasys, any solution ?

Hello Everyone,
Well, I'm writing this post because we recently bought a Stratasys Fortus 450 and what a surprise, the cartridge have a new black eeprom with the slot on the side instead of on the middle with green ones....
We tried to read them, but impossible to communicate with, it seems to be a DS28E01 Eeprom. Did you already see this kind of eeprom and were you able to read it ?
If you have any information, please do not hesitate to contact me.
Thank you all.
Ciboulete

News??

Thank you so much

Hello, I also searching for solution of this problem. I think that it is possible to buy DS28E01-100, write on it and and place it on the chip, what do you think?

Hi
Good idea!! 💡
Saluti
Michele Rossetti
Inviato da iPhone

Il giorno 12 mar 2018, alle ore 14:52, SKLM2771<EMAIL_ADDRESS>ha scritto:
Hello, I also searching for solution of this problem. I think that it is possible to buy DS28E01-100, write on it and and place it on the chip, what do you think?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Hello bvanheu,
I ask you for information for cartridgewriter for uprint, i can not read internal eprom the cartridge, what can it be?
Thanks.
Saluti
Michele Rossetti
Inviato da iPhone

Il giorno 12 mar 2018, alle ore 14:52, SKLM2771<EMAIL_ADDRESS>ha scritto:
Hello, I also searching for solution of this problem. I think that it is possible to buy DS28E01-100, write on it and and place it on the chip, what do you think?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

hi, any updates on this? I cannot decode/write new black tiny eeproms for F900. I can see the crypted eeprom content but all machine types gives me "invalid crypted content checksum" error when I try to decode.


Events cards should be more dinamic and provide more information

Intended behaviour of cards components at event tab is to:
Once click
Expand and provide more information
I would prefer to be able to redirect to a full-fledge landing page for that event. The event landing page, or expanded card component, should be generated from a JSON.

Hi Brayen,
It's a great idea. I'd like to share with you two prototypes for this:

Event landing page: with register button (main CTA), tags, event info, organizers and speakers
Community landing page:  with register button (main CTA), about info, tags, gallery, team and social media

You can click here for full experience (from home page to event/community landing page): https://www.figma.com/proto/x7GTNPvqJwtyzjfKX5NqH9/ECinTech?node-id=88-148&node-type=frame&t=YVhIU8QGS8Od4zIZ-0&scaling=min-zoom&content-scaling=fixed&page-id=0%3A1
(If you'd like to skip the full experience) Here's the link for community landing page (you can access the event landing page from here): https://www.figma.com/proto/x7GTNPvqJwtyzjfKX5NqH9/ECinTech?node-id=269-2110&node-type=frame&t=YVhIU8QGS8Od4zIZ-0&scaling=min-zoom&content-scaling=fixed&page-id=0%3A1


Issue: 606. Make assets theme-independent.

Regarding to changes in PromotedOffers.vue I added background-color classes in order to tiles shows correctly without images. Images are now theme-specific and some components like MainSlider or PromotedOffers use global JSON resource to read URLs to images. Now if there are no images in theme, component looks quiet good with background-color only.
I think we should create another task to make some resources theme-specific (this requires also rebuilding core components that use global resources)

@qiqqq can you create this task?

@filrak There is no need to change URLs to images. I added middleware so each image is serve from path /assets/. . Images can be placed both in global /asstes/ directory as in theme /assets/ directory and path stays these same. I don't see also any broken images on my local instance so I don't understand your request.

Oh ok i wrongly ubderstood what you wrote, sorry :) merging


Add gender determination (based on VCF)

Martin = male
Rest = unknown
To be used software= unknown.

See: #6bdf7a64d4dfb498edb9e7674417a0067f9dacaf


Unexpected exception: 1-th lambda argument should be type of SlotRef

Steps to reproduce the behavior (Required)
CREATE DATABASE PROCESS;

CREATE TABLE `PROCESS`.`ACTIVITY` (`case` BIGINT, `timestamp` DATETIME, `sorting` BIGINT, `ID_ACTIVITY` BIGINT, `CG_SHARD_ID_mygroup` BIGINT, `activity` BIGINT, `activityname` STRING, `nonnullcount` BIGINT, `FK_8_ACTIVITY_CASE` BIGINT, `FK_13_ACTIVITY_INFO_ACTIVITY` BIGINT) PRIMARY KEY(`case`,`timestamp`,`sorting`,`ID_ACTIVITY`) DISTRIBUTED BY HASH (`case`) PROPERTIES("replication_num" = "1");
CREATE TABLE `PROCESS`.`ACTIVITY_INFO` (`ID_ACTIVITY_INFO` BIGINT, `CG_SHARD_ID_mygroup` BIGINT, `activity_info` BIGINT, `activity` BIGINT, `extra_info` STRING, `FK_13_ACTIVITY_INFO_ACTIVITY` BIGINT) PRIMARY KEY(`ID_ACTIVITY_INFO`) DISTRIBUTED BY HASH (`ID_ACTIVITY_INFO`) PROPERTIES("replication_num" = "1");
CREATE TABLE `PROCESS`.`CASE` (`ID_CASE` BIGINT, `CG_SHARD_ID_mygroup` BIGINT, `case` BIGINT, `caseinfo` STRING, `caseextrainfo` BIGINT, `FK_8_ACTIVITY_CASE` BIGINT, `FK_4_CASE_CASEEXTRAINFO` BIGINT, `PU_9_ARRAY_AGG_8_activity_case` ARRAY<BIGINT>, `PU_9_ARRAY_AGG_8_activity_timestamp` ARRAY<DATETIME>, `PU_9_ARRAY_AGG_8_activity_sorting` ARRAY<BIGINT>, `PU_9_ARRAY_AGG_8_activity_ID_ACTIVITY` ARRAY<BIGINT>, `PU_9_ARRAY_AGG_8_activity_CG_SHARD_ID_mygroup` ARRAY<BIGINT>, `PU_9_ARRAY_AGG_8_activity_activity` ARRAY<BIGINT>, `PU_9_ARRAY_AGG_8_activity_activityname` ARRAY<STRING>, `PU_9_ARRAY_AGG_8_activity_nonnullcount` ARRAY<BIGINT>, `PU_9_ARRAY_AGG_8_activity_FK_8_ACTIVITY_CASE` ARRAY<BIGINT>, `PU_9_ARRAY_AGG_8_activity_FK_13_ACTIVITY_INFO_ACTIVITY` ARRAY<BIGINT>) PRIMARY KEY(`ID_CASE`) DISTRIBUTED BY HASH (`ID_CASE`) PROPERTIES("replication_num" = "1");
CREATE TABLE `PROCESS`.`CASEEXTRAINFO` (`ID_CASEEXTRAINFO` BIGINT, `CG_SHARD_ID_mygroup` BIGINT, `caseextrainfo` BIGINT, `extra` STRING, `activitysuffix` STRING, `FK_4_CASE_CASEEXTRAINFO` BIGINT) PRIMARY KEY(`ID_CASEEXTRAINFO`) DISTRIBUTED BY HASH (`ID_CASEEXTRAINFO`) PROPERTIES("replication_num" = "1");

WITH `ACTIVITY` AS (
  SELECT
    `TableScan_Alias_ACTIVITY_000`.`CG_SHARD_ID_mygroup` AS `CG_SHARD_ID_mygroup_1`,
    `TableScan_Alias_ACTIVITY_000`.`FK_8_ACTIVITY_CASE` AS `FK_8_ACTIVITY_CASE`,
    TRUE AS `NodeOperatorNodeHandler_TRUE_000`,
    `TableScan_Alias_ACTIVITY_000`.`NONNULLCOUNT` AS `NONNULLCOUNT`,
    `TableScan_Alias_ACTIVITY_000`.`SORTING` AS `SORTING`,
    `TableScan_Alias_ACTIVITY_000`.`TIMESTAMP` AS `TIMESTAMP`
  FROM
    `PROCESS`.`ACTIVITY` AS `TableScan_Alias_ACTIVITY_000`
),
`ParserContext_SharedAggregation_000` AS (
  SELECT
    `TableScan_Alias_ACTIVITY_001`.`CG_SHARD_ID_mygroup_1` AS `CG_SHARD_ID_mygroup_3`,
    `TableScan_Alias_ACTIVITY_001`.`FK_8_ACTIVITY_CASE` AS `FK_8_ACTIVITY_CASE`,
    ARRAY_AGG(
      `TableScan_Alias_ACTIVITY_001`.`NONNULLCOUNT`
      ORDER BY
        `TableScan_Alias_ACTIVITY_001`.`TIMESTAMP` ASC,
        `TableScan_Alias_ACTIVITY_001`.`SORTING` ASC
    ) AS `NodeOperatorNodeHandler_activity_list_000`,
    ARRAY_AGG(
      `TableScan_Alias_ACTIVITY_001`.`NodeOperatorNodeHandler_TRUE_000`
      ORDER BY
        `TableScan_Alias_ACTIVITY_001`.`TIMESTAMP` ASC,
        `TableScan_Alias_ACTIVITY_001`.`SORTING` ASC
    ) AS `NodeOperatorNodeHandler_filter_list_000`
  FROM
    `ACTIVITY` AS `TableScan_Alias_ACTIVITY_001`
  GROUP BY
    `TableScan_Alias_ACTIVITY_001`.`CG_SHARD_ID_mygroup_1`,
    `TableScan_Alias_ACTIVITY_001`.`FK_8_ACTIVITY_CASE`
),
`TableScanSequence_CASE_000` AS (
  SELECT
    `TableScan_Alias_CASE_001`.`CASE` AS `JoinColumnResolver_Column_CASE_000`,
    `ParserContext_Alias_SharedAggregation_000`.`NodeOperatorNodeHandler_activity_list_000` AS `JoinColumnResolver_Column_activity_list_001`,
    `ParserContext_Alias_SharedAggregation_000`.`NodeOperatorNodeHandler_filter_list_000` AS `JoinColumnResolver_Column_filter_list_001`
  FROM
    `PROCESS`.`CASE` AS `TableScan_Alias_CASE_001`
    LEFT JOIN `ParserContext_SharedAggregation_000` AS `ParserContext_Alias_SharedAggregation_000` ON (
      `TableScan_Alias_CASE_001`.`FK_8_ACTIVITY_CASE` = `ParserContext_Alias_SharedAggregation_000`.`FK_8_ACTIVITY_CASE`
      AND `TableScan_Alias_CASE_001`.`CG_SHARD_ID_mygroup` = `ParserContext_Alias_SharedAggregation_000`.`CG_SHARD_ID_mygroup_3`
    )
),
`TableScanSequence_CASE_001` AS (
  SELECT
    `TableScan_Alias_CASE_002`.`JoinColumnResolver_Column_CASE_000` AS `JoinColumnResolver_Column_CASE_000`,
    ARRAY_FILTER(
      (NodeOperatorNodeHandler_arg_002) -> (
        (
          (
            `NodeOperatorNodeHandler_arg_002`
          ) IS NOT NULL
        )
      ),
      [  ARRAY_FILTER((NodeOperatorNodeHandler_arg_000, NodeOperatorNodeHandler_arg_001)->(((( `NodeOperatorNodeHandler_arg_000` ) IS NOT NULL) AND  `NodeOperatorNodeHandler_arg_001` )), `TableScan_Alias_CASE_002`.`JoinColumnResolver_Column_activity_list_001`, `TableScan_Alias_CASE_002`.`JoinColumnResolver_Column_filter_list_001`) [ 1 ] ]
    ) AS `NodeOperatorNodeHandler_nodify_000`
  FROM
    `TableScanSequence_CASE_000` AS `TableScan_Alias_CASE_002`
),
`UNNEST_LHS_3` AS (
  SELECT
    `TOSQL_UNNEST`.`NodeOperatorNodeHandler_nodify_000` AS `NodeOperatorNodeHandler_nodify_000`,
    `TableScan_Alias_CASE_003`.`JoinColumnResolver_Column_CASE_000` AS `RENAME_2`
  FROM
    `TableScanSequence_CASE_001` AS `TableScan_Alias_CASE_003`,
    UNNEST(
      `TableScan_Alias_CASE_003`.`NodeOperatorNodeHandler_nodify_000`
    ) AS TOSQL_UNNEST(
      `NodeOperatorNodeHandler_nodify_000`
    )
),
`ParserContext_SharedAggregation_001` AS (
  SELECT
    COUNT(*) AS `FilterAndSortHandler_OVERALLCOUNT_000`
  FROM
    `UNNEST_LHS_3` AS `TableScan_Alias_Flattener_000`
),
`FilterAndSortHandler_FilterAndSort_000` AS (
  SELECT
    `TableScan_Alias_Flattener_001`.`RENAME_2` AS `JoinColumnResolver_Column_CASE_001`,
    `TableScan_Alias_Flattener_001`.`NodeOperatorNodeHandler_nodify_000` AS `JoinColumnResolver_Column_nodify_000`
  FROM
    `UNNEST_LHS_3` AS `TableScan_Alias_Flattener_001`
  LIMIT
    50
), `TableOutputHandler_MAIN_000` AS (
  SELECT
    `TableScan_Alias_FilterAndSort_000`.`JoinColumnResolver_Column_CASE_001` AS `JoinColumnResolver_Column_CASE_001`,
    `TableScan_Alias_FilterAndSort_000`.`JoinColumnResolver_Column_nodify_000` AS `JoinColumnResolver_Column_nodify_000`
  FROM
    `FilterAndSortHandler_FilterAndSort_000` AS `TableScan_Alias_FilterAndSort_000`
  LIMIT
    50
), `ParserContext_UNION_000` AS (
  (
    SELECT
      `TableScan_Alias_MAIN_000`.`JoinColumnResolver_Column_CASE_001` AS `ParserContext_OUTCOLUMN_000`,
      `TableScan_Alias_MAIN_000`.`JoinColumnResolver_Column_nodify_000` AS `ParserContext_OUTCOLUMN_001`,
      CAST(1 AS BIGINT) AS `ParserContext_TAG_000`
    FROM
      `TableOutputHandler_MAIN_000` AS `TableScan_Alias_MAIN_000`
  )
  UNION ALL
  (
    SELECT
      NULL AS `ParserContext_OUTCOLUMN_000`,
      `TableScan_Alias_METADATA_000`.`FilterAndSortHandler_OVERALLCOUNT_000` AS `ParserContext_OUTCOLUMN_001`,
      CAST(2 AS BIGINT) AS `ParserContext_TAG_000`
    FROM
      `ParserContext_SharedAggregation_001` AS `TableScan_Alias_METADATA_000`
  )
)
SELECT
  `TableScan_Alias_UNION_000`.`ParserContext_OUTCOLUMN_000` AS `ParserContext_OUTCOLUMN_000`,
  `TableScan_Alias_UNION_000`.`ParserContext_OUTCOLUMN_001` AS `ParserContext_OUTCOLUMN_001`,
  `TableScan_Alias_UNION_000`.`ParserContext_TAG_000` AS `ParserContext_TAG_000`
FROM
  `ParserContext_UNION_000` AS `TableScan_Alias_UNION_000`

Expected behavior (Required)
Should succeed
Real behavior (Required)
ERROR 1064 (HY000) at line 1: Unexpected exception: 1-th lambda argument should be type of SlotRef, but actually NodeOperatorNodeHandler_arg_000
StarRocks version (Required)
branch 3.1. It was working at commit 17eaeded. Failing at commit 4c0a013c and at d5732a3b
Possibly related to this change: https://github.com/StarRocks/starrocks/pull/33036

Caused by https://github.com/StarRocks/starrocks/pull/33036


Can't generate TF Records

When I try to generate the TF record files, i get the following:
Traceback (most recent call last):
  File "generate_tfrecord.py", line 99, in <module>
    tf.app.run()
  File "/home/rafael/.virtualenvs/py3cv3/lib/python3.5/site-packages/tensorflow/python/platform/app.py", line 48, in run
    _sys.exit(main(_sys.argv[:1] + flags_passthrough))
  File "generate_tfrecord.py", line 90, in main
    tf_example = create_tf_example(group, path)
  File "generate_tfrecord.py", line 45, in create_tf_example
    encoded_jpg = fid.read()
  File "/home/rafael/.virtualenvs/py3cv3/lib/python3.5/site-packages/tensorflow/python/lib/io/file_io.py", line 118, in read
    self._preread_check()
  File "/home/rafael/.virtualenvs/py3cv3/lib/python3.5/site-packages/tensorflow/python/lib/io/file_io.py", line 78, in _preread_check
    compat.as_bytes(self.__name), 1024 * 512, status)
  File "/usr/lib/python3.5/contextlib.py", line 66, in __exit__
    next(self.gen)
  File "/home/rafael/.virtualenvs/py3cv3/lib/python3.5/site-packages/tensorflow/python/framework/errors_impl.py", line 466, in raise_exception_on_not_ok_status
    pywrap_tensorflow.TF_GetCode(status))
tensorflow.python.framework.errors_impl.NotFoundError: /home/rafael/PersonalProjects/git/RetrainedObjectDetector/images/raccoon-76.png

This is the command I use to call the function:
python generate_tfrecord.py --csv_input=data/train_labels.csv --output_path=data/train.record

From the error my best guess is that the file is not there?

It seems like the labels.csv files where generated with the .png extension, while the images are .jpeg. I just saw your folders and the labels.csv all contain .jpeg labels. It must be some problem with my xml_to_csv.py, since I changed it and created the labels through it.
Will take a look and come back with answers.

It doesn't matter if it is .png or .jpeg in the xml files. The only thing that matters is if the filename is correct in the csv file. Other than that I didn't experience any problem with this.

i get the same error. i have checked all file extensions, they are matched. jpg file in directory jpg in cvs files.

Even am facing the same issue!! Anyone with solution???????????

Like @rafaellehmkuhl said my .xml files had .png extensions in them (while the actual images had .jpg) and this got automatically transferred to the .csv files (probably while batch processing them). A quick fix was to change the extensions in the .csv files.

I'm facing the same problem
i cannot generate the tf.recored file
Microsoft Windows [Version 10.0.18262.1000]
(c) 2018 Microsoft Corporation. All rights reserved.
C:\Users\admin\Desktop\object-detection>python generate_tfrecord.py
Traceback (most recent call last):
File "generate_tfrecord.py", line 99, in
tf.app.run()
File "C:\Users\admin\AppData\Local\Programs\Python\Python36\lib\site-packages\tensorflow\python\platform\app.py", line 125, in run
_sys.exit(main(argv))
File "generate_tfrecord.py", line 85, in main
writer = tf.python_io.TFRecordWriter(FLAGS.output_path)
File "C:\Users\admin\AppData\Local\Programs\Python\Python36\lib\site-packages\tensorflow\python\lib\io\tf_record.py", line 112, in init
compat.as_bytes(path), compat.as_bytes(compression_type), status)
File "C:\Users\admin\AppData\Local\Programs\Python\Python36\lib\site-packages\tensorflow\python\framework\errors_impl.py", line 526, in exit
c_api.TF_GetCode(self.status.status))
tensorflow.python.framework.errors_impl.NotFoundError: Failed to create a NewWriteableFile:  : The system cannot find the path specified.
; No such process
C:\Users\admin\Desktop\object-detection>python generate_tfrecord.py

Like @rafaellehmkuhl said my .xml files had .png extensions in them (while the actual images had .jpg) and this got automatically transferred to the .csv files (probably while batch processing them). A quick fix was to change the extensions in the .csv files.

i have all the extensions in the file csv file as .JPG could that be a problem, but my original image also has the same extension

Facing the same issue, anyone found a solution?


Feature Request: MSSQL Provider

I would like someone to help expand our official plugins to add support for Microsoft SQL databases. The Provider should of course be SGv2 compatible, as even those who are using klasa v0.4.0 will be able to use the up to date provider. (SGv2 Providers are backwards compatible with SGv1)

For multi-platform support, we use the Tedious wrapper, which is tedious.

The code needed to write the SGv2-compatible Tedious provider is very hard to achieve without the presence of my previously proposed GatewayORM. Why is that? Well, if you check the documentation, to pass parameters you need to use some middleware that is uncompatible with the current state of SGv2, check it here.
Wrapping it is very bloated and very hard, why is that? It uses both events and callbacks (Promise support is lacking) althought it comes with many features.

Current code (if somebody wants to continue this):
const { Provider } = require('klasa');
const { Connection } = require('tedious');

module.exports = class extends Provider {

	constructor(...args) {
		super(...args, {
			enabled: true,
			sql: true,
			description: 'Allows you to use MSSQL functionality throught Klasa'
		});
		this.db = null;
	}

	init() {
		return new Promise((resolve, reject) => {
			this.db = new Connection({
				userName: 'database-userName',
				password: 'database-password',
				server: '<IP_ADDRESS>',
				// If you're on Windows Azure, you will need this enabled:
				options: { encrypt: false }
			});

			this.db.on('connect', (error) => {
				if (error) reject(error);
				else resolve();
			});
		});
	}
}


v0.2.2

Codecov Report

Merging #4 (d337b71) into main (0136693) will decrease coverage by 0.03%.
The diff coverage is 33.33%.

@@            Coverage Diff             @@
##             main       #4      +/-   ##
==========================================
- Coverage   57.69%   57.65%   -0.04%
==========================================
  Files          16       17       +1
  Lines        1988     1991       +3
==========================================
+ Hits         1147     1148       +1
- Misses        841      843       +2

Impacted Files
Coverage Δ

src/keyboard.rs
5.69% <ø> (ø)

src/lib.rs
100.00% <ø> (ø)

better_swarm/src/main.rs
33.33% <33.33%> (ø)

Continue to review full report at Codecov.

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


Nested arrays with C++ 17.

The following snippet compiles fine in C++14 mode but fails in C++17:
#include <boost/pfr/precise/core.hpp>

int main()
{
  struct foo
  {
    int things[3];
  };

  boost::pfr::for_each_field(foo{{1, 2, 3}}, [&](auto& field) {});
}

Tested on GCC 7.2.0 and CLANG 5.0.0.
Errors from CLANG:

In file included from main.cpp:5:
In file included from include/boost/pfr/precise/core.hpp:21:
In file included from include/boost/pfr/detail/core17.hpp:10:
include/boost/pfr/detail/core17_generated.hpp:57:9: error: type 'foo' decomposes into 1 elements, but 3 names were provided
auto& [a,b,c] = val;
^
include/boost/pfr/detail/core17_generated.hpp:1032:30: note: in instantiation of function template specialization 'boost::pfr::detail::tie_as_tuple'
requested here
return boost::pfr::detail::tie_as_tuple(val, fields_count_tag{});
^
include/boost/pfr/detail/core17.hpp:52:17: note: in instantiation of function template specialization 'boost::pfr::detail::tie_as_tuple' requested here
detail::tie_as_tuple(t)
^
include/boost/pfr/precise/core.hpp:145:27: note: in instantiation of function template specialization 'boost::pfr::detail::for_each_field_dispatcher<foo,
(lambda at include/boost/pfr/precise/core.hpp:147:9), 0, 1, 2>' requested here
::boost::pfr::detail::for_each_field_dispatcher(
^
main.cpp:102:15: note: in instantiation of function template specialization 'boost::pfr::for_each_field<foo, (lambda at main.cpp:102:46)>' requested here
boost::pfr::for_each_field(foo{{1, 2, 3}}, [&](auto& field) {});
^
1 error generated.

Errors from GCC:

In file included from include/boost/pfr/detail/core17.hpp:10:0,
from include/boost/pfr/precise/core.hpp:21,
from main.cpp:5:
include/boost/pfr/detail/core17_generated.hpp: In instantiation of ‘constexpr auto boost::pfr::detail::tie_as_tuple(T&, boost::pfr::detail::size_t_<3>) [with T = main()::foo; boost::pfr::detail::size_t_<3> = std::integral_constant<long unsigned int, 3>]’:
include/boost/pfr/detail/core17_generated.hpp:1032:42:   required from ‘constexpr auto boost::pfr::detail::tie_as_tuple(T&) [with T = main()::foo]’
include/boost/pfr/detail/core17.hpp:52:29:   required from ‘void boost::pfr::detail::for_each_field_dispatcher(T&, F&&, std::index_sequence<_Idx ...>) [with T = main()::foo; F = boost::pfr::for_each_field(T&&, F&&) [with T = main()::foo; F = main()::<lambda(auto:6&)>]::<lambda(auto:1&&)>; long unsigned int ...I = {0, 1, 2}; std::index_sequence<_Idx ...> = std::integer_sequence<long unsigned int, 0, 1, 2>]’
include/boost/pfr/precise/core.hpp:145:52:   required from ‘void boost::pfr::for_each_field(T&&, F&&) [with T = main()::foo; F = main()::<lambda(auto:6&)>]’
main.cpp:102:65:   required from here
include/boost/pfr/detail/core17_generated.hpp:57:9: error: 3 names provided while ‘main()::foo’ decomposes into 1 elements
auto& [a,b,c] = val;
^~~~~~~
In file included from include/boost/pfr/precise/core.hpp:21:0,
from main.cpp:5:
include/boost/pfr/detail/core17.hpp: In instantiation of ‘void boost::pfr::detail::for_each_field_dispatcher(T&, F&&, std::index_sequence<_Idx ...>) [with T = main()::foo; F = boost::pfr::for_each_field(T&&, F&&) [with T = main()::foo; F = main()::<lambda(auto:6&)>]::<lambda(auto:1&&)>; long unsigned int ...I = {0, 1, 2}; std::index_sequence<_Idx ...> = std::integer_sequence<long unsigned int, 0, 1, 2>]’:
include/boost/pfr/precise/core.hpp:145:52:   required from ‘void boost::pfr::for_each_field(T&&, F&&) [with T = main()::foo; F = main()::<lambda(auto:6&)>]’
main.cpp:102:65:   required from here
include/boost/pfr/detail/core17.hpp:51:23: error: invalid use of void expression
std::forward(f)(
~~~~~~~~~~~~~~~~~~^
detail::tie_as_tuple(t)
~~~~~~~~~~~~~~~~~~~~~~~
);
~

That's a known issue and it is documented (for example here)
If you know some way to workaround that issue or to static_assert it, then please give me hint.

@apolukhin: You could test explicit initialization of every member instead one aggregate list.
Let's consider this example:
struct Foo
{
    int a;
    int b[3];
    int c;
};

You can construction it like so
Foo foo{1, 1, 1, 1, 1};

which will of course give you "flat" number, brace elision is coming into play. But if you instead do this:
Foo foo{{}, {}, {}};

you will get "precise" number of members. Because as you probably figured this will fail:
Foo foo{{}, {}, {}, {}};

I can make PR in new year with the changes to support precise mode with nested arrays. Unless you beat me to it :>


Sponsor info for marketing flow

get sponsor logos
get sponsor twitter handle
interview sponsor for blog post

Logos are stored in Sponsor folder on Google drive. The twitter handle and contact info are stored in sponsorship worksheet under 2016 sponsors. Please keep in sync.


Design and add new favicon

The site could use its own favicon.
If this is accepted, please assign it to emgrey02

I was hoping to give it to Emma Grey (emgrey02) for a Hacktoberfest win.
I was just typing out a comment saying I missed that bit of your original message. I'll assign it to them :)

@emgrey02  - it looks like the issue is yours if you want it.


[cinder-csi-plugin][doc] Update CSIMigration status

From release1.21 , CSIMigration is ON by default. This PR
is to reflect the same in doc.

What this PR does / why we need it:
Which issue this PR fixes(if applicable):
fixes #
Special notes for reviewers:

Release note:

NONE

Please also update https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/openstack-cloud-controller-manager/migrate-to-ccm-with-csimigration.md#enable-csimigration

Please also update https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/openstack-cloud-controller-manager/migrate-to-ccm-with-csimigration.md#enable-csimigration

@lingxiankong Thanks . Updated .I see that all the feature gates are now enabled by default. So removed the same.
PTAL

/lgtm

@jichenjc PTAL

/approve


Use new auth server domain

We are transitioning to a new domain for the auth server. This configures the new domain in the agent binary.
We are going to be backward compatible, so old agents can run with the old domain.

/lgtm
/hold

/unhold


Fix wrapping of child TextNodes in jQuery 1.1x.x [fixes #16]

This fixes hiding of non-wrapped TextNodes using jQuery 1.10+, which may be issue #16
.contents(':not("any-old-filter")') in jQuery > 1.9 happens to also filter out all non-wrapped TextNodes, while contents() and children() without filters specified leave all of them in. That caused the old $detailsNotSummaryContents to exclude the nodes that still needed <span> wrapping to hide properly.
jQ 1.9 (leaves in unwrapped nodes): http://codepen.io/anon/pen/MwQmVb
jQ 1.10 (filters out unwrapped nodes): http://codepen.io/anon/pen/YXeVLJ

Ah, shoot, I see PR#18 handles this as well in a slightly different way. That one is less obtrusive so I'd prefer that one be merged.


[FEAT]: Update _reusable-package-release.yml to allow creating prerelease versions

Description
It would be nice to be able to use this automation tool to create a prerelease version. It would need to create a prerelease version and upload it to pypi and testpypi as well as create a prerelease in GitHub. The testpypi upload workflow would also need to be updated to properly handle the postN versions that are uploaded (it may need to include the release candidate info in the custom version)
Additional Information
No response

See https://python-semantic-release.readthedocs.io/en/stable/automatic-releases/github-actions.html#prerelease

Will also require updating to use https://python-semantic-release.readthedocs.io/en/stable/automatic-releases/github-actions.html#python-semantic-release-publish-action

Relates to #141, #107, #91


fix bucket deallocation with incorrect layout

Fixes a bug introduced in #35 (not released yet).

Thanks! Do you need me to publish a new release?


Use strong name version of third party dependencies

I've created a strong name version of all dependencies that are not already strong named. These packages are on nuget-build. The same SNK was used for all of these packages and is stored in our KeyVault.
This is the same process taken over a year ago to enable strong naming on NuGetGallery.Core, with:

elmah.corelibrary.strongname
elmah.sqlserver.strongname
elmah.strongname

Progress on https://github.com/NuGet/Engineering/issues/1577.

Also addresses https://github.com/NuGet/NuGetGallery/issues/3849.


Form: key? predicate always raises NoMethodError

require 'bundler/setup'
require 'dry-validation'

form = Dry::Validation.Form do
  required(:foo) { key? }
end

result = form.call('foo' => 'bar')
puts result.success?
puts result.messages[:foo].inspect

__END__

Expected:
  true
  nil

Actual:
  /Users/luca/.gem/ruby/2.3.1/bundler/gems/dry-types-394fa8b62966/lib/dry/types/compiler.rb:15:in `visit': undefined method `[]' for nil:NilClass (NoMethodError)
        from /Users/luca/.gem/ruby/2.3.1/bundler/gems/dry-types-394fa8b62966/lib/dry/types/compiler.rb:75:in `visit_key'
        from /Users/luca/.gem/ruby/2.3.1/bundler/gems/dry-types-394fa8b62966/lib/dry/types/compiler.rb:15:in `visit'
        from /Users/luca/.gem/ruby/2.3.1/bundler/gems/dry-types-394fa8b62966/lib/dry/types/compiler.rb:80:in `block in merge_with'
        from /Users/luca/.gem/ruby/2.3.1/bundler/gems/dry-types-394fa8b62966/lib/dry/types/compiler.rb:80:in `map'
        from /Users/luca/.gem/ruby/2.3.1/bundler/gems/dry-types-394fa8b62966/lib/dry/types/compiler.rb:80:in `merge_with'
        from /Users/luca/.gem/ruby/2.3.1/bundler/gems/dry-types-394fa8b62966/lib/dry/types/compiler.rb:58:in `visit_form_hash'
        from /Users/luca/.gem/ruby/2.3.1/bundler/gems/dry-types-394fa8b62966/lib/dry/types/compiler.rb:28:in `visit_type'
        from /Users/luca/.gem/ruby/2.3.1/bundler/gems/dry-types-394fa8b62966/lib/dry/types/compiler.rb:15:in `visit'
        from /Users/luca/.gem/ruby/2.3.1/bundler/gems/dry-types-394fa8b62966/lib/dry/types/compiler.rb:11:in `call'
        from /Users/luca/.gem/ruby/2.3.1/bundler/gems/dry-validation-59fb0a09c499/lib/dry/validation/input_processor_compiler.rb:16:in `call'
        from /Users/luca/.gem/ruby/2.3.1/bundler/gems/dry-validation-59fb0a09c499/lib/dry/validation/schema.rb:122:in `input_processor'
        from /Users/luca/.gem/ruby/2.3.1/bundler/gems/dry-validation-59fb0a09c499/lib/dry/validation/schema.rb:145:in `default_options'
        from /Users/luca/.gem/ruby/2.3.1/bundler/gems/dry-validation-59fb0a09c499/lib/dry/validation/schema.rb:45:in `new'
        from /Users/luca/.gem/ruby/2.3.1/bundler/gems/dry-validation-59fb0a09c499/lib/dry/validation.rb:37:in `Schema'
        from /Users/luca/.gem/ruby/2.3.1/bundler/gems/dry-validation-59fb0a09c499/lib/dry/validation.rb:42:in `Form'
        from /Users/luca/Code/hanami/validations/test.rb:4:in `<main>'

This error is raised for all the combinations of required/optional with value/filled/maybe.
GIT
  remote: git://github.com/dry-rb/dry-logic.git
  revision: e649fad58546e8e53a048d310c554ad910466a93

GIT
  remote: git://github.com/dry-rb/dry-types.git
  revision: 394fa8b62966fd398f84b83cc712e5b1355f4af7

GIT
  remote: git://github.com/dry-rb/dry-validation.git
  revision: 59fb0a09c4997db95076b49082dc68445ead4630

I don't think key? is intended to be run on the value side of the data (i.e. the right side of the rule definitions). AFAIK it's only there for use by the required/optional methods for the left side of the rule definitions.
If you were to express the rule from your example in ordinary English (as opposed to Ruby), what sort of validation would you be expecting?

@timriley Hey thanks for the quick reply!
As mentioned on yesterday, I'm testing in dumb mode. 😉  I'm just trying all the possible combinations: if I ran into this error, maybe somebody else will ran into. And there will be bug reports, confusion and somebody will give the same exact explanation. Don't get me wrong, you explanation makes sense.
For this reason, shall we forbid combinations that don't make sense?

@timriley As a side note, key? predicate works fine with Schema. Maybe it's an accidental success, but it worth to be mentioned. 😄

No worries! And I'll try to respond to some others soon too.
Yeah, in this case, I reckon it's a combination that doesn't make any sense, and we shouldn't include it in your suite of checks.
(Though I still think there's a case for making the error message better, but I would say that's a different issue)

On 3 May 2016, at 6:17 PM, Luca Guidi<EMAIL_ADDRESS>wrote:
@timriley Hey thanks for the quick reply!
As mentioned on yesterday, I'm testing in dumb mode. 😉 I'm just trying all the possible combinations: if I ran into this error, maybe somebody else will ran into. And there will be bug reports, confusion and somebody will give the same exact explanation. Don't get me wrong, you explanation makes sense.
For this reason, shall we forbid combinations that don't make sense?
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

Oh, would you mind posting the code with it in .Schema? I suspect it's because required/optional are actually shortcuts for key? checks, which is why it actually works in .Schema - because that's the actual appropriate context.

On 3 May 2016, at 6:19 PM, Luca Guidi<EMAIL_ADDRESS>wrote:
@timriley As a side note, key? predicate works fine with Schema. Maybe it's an accidental success, but it worth to be mentioned. 😄
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

@timriley Here it is: https://github.com/hanami/validations/blob/predicates-with-new-backend/test/predicates/schema/key_test.rb

Hi Luca, thanks for the link to that file, but I'm not sure which is the particular case you meant, when you said that key? works find inside Schema. Would you mind letting me know which lines are working?

Would you mind letting me know which lines are working?

The tests for schema are running with success, failures and expected exceptions.
The tests for form are all failing with unexpected exceptions like the one reported by the description of this issue.

We should raise an arg error if key? is used. We set it implicitly when using required(:foo) and it shouldn't be available in the DSL. It's a very low level predicate.


Fixing issue with browse_catalog_bundles fails with HTTP 400

Fixing issue with browse_catalog_bundles fails with HTTP 400 when using bundle_relationship_type::bundles_with_product.
The catalog service now requires you to specify a sort order if asking for which bundles a product is part of.

@CameronGoodwin,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot


exercise and solution nb 16

fixes #49

arg I forgot to save the notebook after I cleared the output, wait a sec

great idea. Clear the cells?

should be fine now

hm maybe use accuracy score from metrics instead of reimplementing it in the solution? but no strong opinion. feel free to merge.

Yeah, I think people will do that automatically. Just thought it was useful to do it explicitely to be able to look at the difference between this accuracy computation and macro wrapper?


Update networking Prometheus dashboard

Close #7171
Updates the networking dashboard for the removal of sysinfo (https://github.com/paritytech/substrate/pull/6805), the changes in metrics in #6634, and the exposed k-buckets sizes in https://github.com/paritytech/substrate/pull/7104.
cc @wi1dcard

bot merge


cmstt.txt

add cmstt university to jetbrains

@letanhienth92 I have to close this request without merging, because you requested to add a non-existent domain to this repository: Host cmstt.edu.vn not found: 3(NXDOMAIN) Please ensure that you are familiar with this repository rules located at the bottom of this page and submit a new request with the correct information. Thank you for your understanding!


webpa messages and payloads

Hello.
My name is Vitor Paulino and I work at NOS Inovação and we at NOS Inovação are starting to explore this and others repositories regarding webpa protocol.
To understand the messages payload that are sent and received by parodus, it would be great if there was any documentation regarding the use cases and the messages that are exchanged. Can you provide something so we can start working on this?
Best regards
Vitor Paulino

Vitor,
We're in the process of moving the more cross cutting docs into https://github.com/comcast/xmidt and it's wiki.  Until then wrp-c wiki is the best description of the payloads.
Best,
Wes


Arduino Nano + RFID RC522 + Ethernet shield W5100

I have this Arduino Nano, Ethernet shield W5100 and RC522 as card reader. They are sharing pins D13, D12, D11, D10 is SS pin for W5100 D8 is SS pin for RC522. Problem is with pin D12, like it doesn't share it.
For example if I unplug D12 from W5100, RC522 reader works, if I wire it back it doesn't work anymore. W5100 works no matter if RC522 is wired or not, so problem would be somehow with pin D12.
Does anybody have some ideas, what I'm doing wrong right here?

Seems to be a SPI problem. See: https://github.com/arduino/Arduino/issues/6694#issuecomment-327145487


[Feature request] Search only by title - setup option

I think it will be useful because if I search item by word that is a part or my default email, I get a full bunch of records that I dont want to get

For now, you can bring up advanced search (click lens icon in search field) and uncheck everything except Other fields. Title option should be added there.

The fix deployed to beta https://beta.keeweb.info/


feat: bump gwapi to v0.6.0

Fixes: https://github.com/envoyproxy/gateway/issues/839
Fixes: https://github.com/envoyproxy/gateway/issues/716
Closes: https://github.com/envoyproxy/gateway/pull/828
Signed-off-by: bitliu<EMAIL_ADDRESS>

Codecov Report

Merging #853 (c50c1e1) into main (e2ba87a) will decrease coverage by 0.18%.
The diff coverage is 18.18%.

@@            Coverage Diff             @@
##             main     #853      +/-   ##
==========================================
- Coverage   64.14%   63.96%   -0.19%
==========================================
  Files          50       50
  Lines        6523     6543      +20
==========================================
+ Hits         4184     4185       +1
- Misses       2080     2098      +18
- Partials      259      260       +1

Impacted Files
Coverage Δ

internal/status/status.go
0.00% <0.00%> (ø)

internal/provider/kubernetes/controller.go
48.01% <15.00%> (-0.93%)
:arrow_down:

internal/status/conditions.go
96.00% <100.00%> (ø)

internal/provider/kubernetes/helpers.go
75.40% <0.00%> (-1.64%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

looks like the core issue is interpretation of mapping of Observed Generation to Status Conditions
The new GAPI tests assert that the new Observed Generation value be asserted on all Status Conditions (https://github.com/kubernetes-sigs/gateway-api/pull/1586) but Envoy Gateway does not update the status conditions for all older conditions if the core values have not changed https://github.com/envoyproxy/gateway/blob/085e6fa5a56066472a52e8c07bc1aefa3ffca5a2/internal/status/conditions.go#L127 . Imho the latter approach seems more logical. Is there any spec governing this mapping @youngnick

looks like the core issue is interpretation of mapping of Observed Generation to Status Conditions The new GAPI tests assert that the new Observed Generation value be asserted on all Status Conditions (kubernetes-sigs/gateway-api#1586) but Envoy Gateway does not update the status conditions for all older conditions if the core fields (such as Status, Reason and Message) have not changed
https://github.com/envoyproxy/gateway/blob/085e6fa5a56066472a52e8c07bc1aefa3ffca5a2/internal/status/conditions.go#L127
and
https://github.com/envoyproxy/gateway/blob/085e6fa5a56066472a52e8c07bc1aefa3ffca5a2/internal/gatewayapi/contexts.go#L484
. Imho the latter approach seems more logical. Is there any spec governing this mapping @youngnick @skriss

from the Condition spec: https://github.com/kubernetes/apimachinery/blob/6c409361e35e40e38c4056ba0b86647d4244c047/pkg/apis/meta/v1/types.go#L1480-L1485

thanks for sharing that @sunjayBhatia ! , the spec makes it clear that the condition is considered out of date if the observed generation is older
hey @Xunzhuo if you can enhance these snippets (https://github.com/envoyproxy/gateway/blob/085e6fa5a56066472a52e8c07bc1aefa3ffca5a2/internal/status/conditions.go#L127 and https://github.com/envoyproxy/gateway/blob/085e6fa5a56066472a52e8c07bc1aefa3ffca5a2/internal/gatewayapi/contexts.go#L484) with an extra check to consider a condition unchanged or changed if the observed generation is also unchanged or changed respectively, should fix the issue, thanks !

even if the type/reason/status haven't changed, the observed generation should be updated to make clear the status condition applies to the latest version of the resource
From this comment, do we still need to add an extra check to consider a condition unchanged or changed if the observed generation is also unchanged or changed respectively ?

thanks for sharing that @sunjayBhatia ! , the spec makes it clear that the condition is considered out of date if the observed generation is older hey @Xunzhuo if you can enhance these snippets (
https://github.com/envoyproxy/gateway/blob/085e6fa5a56066472a52e8c07bc1aefa3ffca5a2/internal/status/conditions.go#L127
and
https://github.com/envoyproxy/gateway/blob/085e6fa5a56066472a52e8c07bc1aefa3ffca5a2/internal/gatewayapi/contexts.go#L484
) with an extra check to consider a condition unchanged or changed if the observed generation is also unchanged or changed respectively, should fix the issue, thanks !

Done.

@Xunzhuo you will also need to edit this code to
func conditionChanged(a, b metav1.Condition) bool {
	return a.Status != b.Status || a.Reason != b.Reason || a.Message != b.Message || || a.ObservedGeneration != b.ObservedGeneration
}

@Xunzhuo you will also need to rm ObservedGeneration from here https://github.com/envoyproxy/gateway/blob/97032bee2db5ec73027b172e24b03d4dfe98ac3a/internal/status/status.go#L164 since it is now a comparable field

hey @Xunzhuo looks like there was an issue where the gateway API status updater code path would try and update Status.Listeners without updating the ObservedGeneraton with Status.Conditions  causing the test to fail. Ive updated the logic here https://github.com/envoyproxy/gateway/pull/874


variable styles

This PR wants to make all of the common styles (or most of them) "variable" (#175, #380)

[x] strokeDasharray (difficult case: we can't consider that an array is a columnar representation of a channel) 🌶
[x] strokeDashoffset (number)
[x] dx and dy

[ ] DX without X, DY without Y?

[ ] mixBlendMode
[ ] more?

for the text mark:

[x] textAnchor
[x] fontFamily
[x] fontSize (was already variable)
[x] fontStyle
[x] fontVariant
[x] fontWeight

I'm not sure how to make dx and dy variable when X or Y are not channels; I think I'll punt on this for now, because I don't want to overcomplicate the PR—my first prototype was making changes in each and every mark, depending on X, Y, and possibly cx, cy when X and Y were not defined… booo. The current approach which shifts X seems much better, but doesn't work when X is not a channel.

rebased

Fil, thanks for the work here. I would like to put this on hold to focus on animation and interaction. I am concerned that this generalization may make animation more difficult to implement. Let’s discuss this week.


Feature: Configure the reader/writer via API

Having the reader/writer options hard coded requires consumers of this library to build and deploy custom docker images if the files they work with don't match the defaults.
Request: Make the reader and writer options configurable in API requests

Link to code of hardcoded options:
https://github.com/moov-io/imagecashletter/blob/17a228ebf9adaece2221bd7dfcbaf7ff756efdad/cmd/server/files.go#L132
(Got from Daniel)


misc: Add Python v3.12 release candidate 3 to the testing

Blocked by #2869

Checklist

[x] npm install && npm test passes
[x] tests are included
[x] documentation is changed or added
[ ] commit message follows commit guidelines

Description of change

@Trott Any ideas on the Windows test failures (tests on Py3.8 and VS tests too)?
https://github.com/nodejs/node-gyp/actions

@Trott Any ideas on the Windows test failures (tests on Py3.8 and VS tests too)?
https://github.com/nodejs/node-gyp/actions

Those failures aren't on the main branch (as far as I can tell), so I'd guess they're related to the changes here. But I say that knowing very little about compiling thingson Windows, etc.....

Closing in favor of nodejs/gyp-next#201 and nodejs/gyp-next#214 as discussed at https://github.com/nodejs/node-gyp/pull/2888#issuecomment-1783233943


Error while trying to build the project

Hi. I've cloned the project and installed all the dependencies. When I run cargo build I got the following error:
$ cargo build
[...]
   Compiling nanos_sdk v0.2.0 (https://github.com/LedgerHQ/ledger-nanos-sdk.git#4e3a0138)
error: failed to run custom build command for `nanos_sdk v0.2.0 (https://github.com/LedgerHQ/ledger-nanos-sdk.git#4e3a0138)`

Caused by:
  process didn't exit successfully: `/tmp/rust-app/target/debug/build/nanos_sdk-64891551d00a4d76/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at 'invalid target `none`, expected one of `nanos`, `nanox`, `nanosplus`. Run with `-Z build-std=core --target=./<target name>.json`', /home/testuser/.cargo/git/checkouts/ledger-nanos-sdk-f77eb1a6021b7ee5/4e3a013/build.rs:268:24
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...

There seems to be a problem when trying to build the SDK. Any idea on how to solve it?

cargo build would try to build for you own desktop PC, but this is a Ledger app, so it builds for special targets like nanos, nanox, nanosplus.
A way to set your project to build for one of those is to use a .cargo/config.toml file and add these flags: https://github.com/LedgerHQ/ledger-nanos-sdk/blob/master/.cargo/config.toml#L10-L15
To install the necessary files to build for those special targets, use https://github.com/LedgerHQ/cargo-ledger with cargo ledger setup

Thanks for your reply.


Build is broken due to update of k8s.io/apimachinery/pkg/apis/meta/v1.ListOptions

Describe the bug
Build failing with following errors
Fetching https://k8s.io/client-go/tools/clientcmd?go-get=1
Parsing meta tags from https://k8s.io/client-go/tools/clientcmd?go-get=1 (status code 200)
get "k8s.io/client-go/tools/clientcmd": found meta tag get.metaImport{Prefix:"k8s.io/client-go", VCS:"git", RepoRoot:"https://github.com/kubernetes/client-go"} at https://k8s.io/client-go/tools/clientcmd?go-get=1
get "k8s.io/client-go/tools/clientcmd": verifying non-authoritative meta tag
github.com/integrii/flaggy (download)
k8s.io/api/vendor/github.com/gogo/protobuf/sortkeys
...
github.com/sirupsen/logrus
k8s.io/client-go/vendor/github.com/spf13/pflag
github.com/Comcast/kuberhealthy/pkg/checks/daemonSet
# github.com/Comcast/kuberhealthy/pkg/checks/daemonSet
../../pkg/checks/daemonSet/daemonSet.go:699:3: unknown field 'IncludeUninitialized' in struct literal of type "k8s.io/apimachinery/pkg/apis/meta/v1".ListOptions
../../pkg/checks/daemonSet/daemonSet.go:787:3: unknown field 'IncludeUninitialized' in struct literal of type "k8s.io/apimachinery/pkg/apis/meta/v1".ListOptions
../../pkg/checks/daemonSet/daemonSet.go:807:3: unknown field 'IncludeUninitialized' in struct literal of type "k8s.io/apimachinery/pkg/apis/meta/v1".ListOptions
../../pkg/checks/daemonSet/daemonSet.go:836:4: unknown field 'IncludeUninitialized' in struct literal of type "k8s.io/apimachinery/pkg/apis/meta/v1".ListOptions
../../pkg/checks/daemonSet/daemonSet.go:851:5: unknown field 'IncludeUninitialized' in struct literal of type "k8s.io/apimachinery/pkg/apis/meta/v1".ListOptions

Steps To Reproduce
docker build .

Additional context
Revision of Comcast/kuberhealthy 67fd71113deb20625f97772ccdbe6fb555d85886
Remove use of alpha initializers

Thanks for your contribution today to help with go report card!
I am on this one in issue #40.  I need to modify the modules to use a different version of kube-client.  I plan to fix this within a few days...

Builds online!


Save All Variable group as a json file

Hi,
I'm playing with Azure Pipelines, and i would like to save all variables from specific, linked variable group to json file. Is this is possible?

@Planche95 Thanks for your question. It looks like you're working through an issue with your scenario or implementation, rather than an issue with the documentation. Here are a few options where you might consider asking your question:

Azure DevOps on Stack Overflow
Azure DevOps Support Bot


Clarify that there is no en passant

Hello,
The documentation on LMS says that there is no en passant, but in the README it said that there was en passant. There's also no en passant implemented in the game so I assumed this was just a typo in the README.

Thanks. I'm beginning to worry you may be spending too much time on this : )

You're probably right... if only this weren't so much more enjoyable than all my other units


Who's thoughts are those?

I've got code with two agents, one can delegate to the other.
I'm getting results like

> Entering new AgentExecutor chain...

Thought: Do I need to use a tool? Yes
Action: Search the internet - Trends in AI
Action Input: NoneSearch the internet - Trends in AI is not a valid tool, try one of [Search the internet].Thought: Do I need to use a tool? Yes
Action: Search the internet - Trends in AI
Action Input: NoneSearch the internet - Trends in AI is not a valid tool, try one of [Search the internet].

It would be very useful to have the Role before the thought, so like
'Writer:Thought"
or
"Researcher:Thought"

good call, specially upon delegation it can get trick to tag along, I'll add it

Is my take on solving this issue valid?
It solves it but the disadvantage to this solution is that it added more text to the prompt and so it raises the token count.

Ideally no, as we have that information in the executor we can make sure to log them without having to update the prompts itself


Error: --input provided more than once....

I'm getting this error:
$ yacrd scrubb -i run1.all.report.yacrd -i run1.fastq -o run2.scrubbed.fastq
error: The argument '--input <input>' was provided more than once, but cannot be used multiple times

USAGE:
    yacrd --input <input> --output <output> scrubb --input <input> --output <output>

For more information try --help

Which seems odd that all the readme's show multiple inputs and outputs?  I don't recall seeing this behavior on centOS.  This is installed on Mac OS via bioconda.
$ yacrd --version
yacrd 0.6.0

Hi @nextgenusfs,
Thank you for using yacrd and creating this issue.
You have made a small error in the argument order. The -i run1.all.report.yacrd need to be before the subcommand scrubb.
The first part of the command line is for the general parameters, the part after subcommand is for this subcommand only.
The correct command line, to do what you want to do, is:
yacrd -i run1.all.report.yacrd -o /dev/null -i run1.fastq -o run2.scrubbed.fastq
Sorry for the -o /dev/null I need to found a way to fix this. I will try to clarify the parameter ordering in Readme.

Ok @natir thanks for clarification.  And thanks for yacrd its helping scrubb ONT reads prior to assembly!


Submit new tracks to last.fm

Sometimes a track cannot be recognized automatically. The extension's icon is gray then. Clicking the icon I can open a popup window where I can enter the Artist and Track names manually and try to Submit them. However, the extension still checks with the last.fm database and won't let me submit new tracks.
I actually would like to be able to submit new tracks to the last.fm database.
Technically, this is possible. The track.scrobble request should only add the "duration" key (in addition to the "artist" and "track" keys), and then last.fm will happily add the new track to its database.

@anthonypetrov Did you get any further with your patches? Willing to share?

@david-sabata any update on this? Any estimate as to when these changes could be incorporated into the mainline? The change is so simple - just pass the detected track length to last.fm, and it will allow you to add unrecognized tracks...
@inverse they still work for me. However, Chrome now enforces extensions content verification, so I'm no longer able to patch the extension in place. I had to remove it from Chrome (goodbye updates to last.fm scrobbler... :( ), make a copy of the patched extension folder on my local disk, enable the Developer Mode in Chrome, and then load the unpacked extension from the copy folder. It works just fine now.
As for sharing the patches, sure! But this bug tracking system won't let me attach patches. It only supports images. I could send them to you by email if I had one. Or I can paste them in a comment, but I'm afraid the formatting/spacing could suffer so that you'd have to apply them manually (currently they apply cleanly to version 1.43). Let me know what option works best for you.

@anthonypetrov  Are you able to put your changes to a branch and share that?

I could, but have no time. Here's the patches:
--- popup.js.orig	2014-11-09 16:23:57.761325200 -0800
+++ popup.js	2014-11-09 16:27:39.178123400 -0800
@@ -87,10 +87,20 @@

 			var validateCB = function (res) {
 				if (res === false) {
-					$(this).attr('disabled', false);
-					$(this).siblings().remove();
-					$(this).parent().append('Not valid');
-				} else {
+                    var ar = artist;
+                    var tr = track;
+                    var dr = 60;
+                    if (!song.duration) {
+                        dr = 60;
+                    } else {
+                        dr = song.duration;
+                    }
+                    song.submitDuration = true;
+                    res =  {artist : ar,
+                        track : tr,
+                        duration : dr
+                    };
+                }  {
 					// did the content script recognize at least the duration?
 					if (!song.duration) {
 						song.duration = res.duration;
@@ -107,7 +117,7 @@
 					// The minimum time is 240 seconds or half the track's total length
 					// minus the time that already past
 					var past = parseInt(new Date().getTime() / 1000.0) - song.startTime;
-					var min_time = Math.min(240, song.duration / 2) - past;
+					var min_time = Math.min(30, song.duration / 5) - past;

 					// Set up the timer to scrobble
 					popupApi.planSubmit(min_time * 1000);

--- scrobbler.js.orig	2014-12-08 22:47:46.000000000 -0800
+++ scrobbler.js	2014-12-23 20:25:25.944198600 -0800
@@ -303,7 +303,7 @@
 			if (typeof song.album !== 'undefined' && song.album !== null) {
 				params.album = song.album;
 			}
-			if (typeof song.duration !== 'undefined' && song.duration !== null) {
+			if (!(!song.submitDuration) || (typeof song.duration !== 'undefined' && song.duration !== null)) {
 				params.duration = song.duration;
 			}

@@ -389,6 +389,10 @@
 			if (typeof song.sourceId !== 'undefined' && song.sourceId !== null) {
 				params['sourceId[0]'] = song.sourceId;
 			}
+
+            if (!(!song.submitDuration)) {
+                params["duration[0]"] = song.duration;
+            }

 			var api_sig = LastFM.generateSign(params);
 			var url = config.apiURL + createQueryString(params) + '&api_sig=' + api_sig;
@@ -529,7 +533,7 @@
 					// The minimum time is 240 seconds or half the
 					// track's total length. Subtract the song's
 					// current time (for the case of unpausing).
-					var min_time = (Math.max(1, Math.min(240, song.duration / 2) - song.currentTime));
+					var min_time = (Math.max(1, Math.min(30, song.duration / 5) - song.currentTime));
 					// Set up the timer
 					scrobbleTimeout = setTimeout(submit, min_time * 1000);
 				}

Hope this helps.

Thanks for the share! so basically sets the duration to 60 for when it is not defined?
Perhaps a more elegant solution would be to:

Allow the popup to be populated with what the scrobbler believes to be a new track is.
Include a duration field that if the scrobbler supports duration handling to set that also, or allow the user to supply this with perhaps some sort formatting applied e.g. mm:ss

Opinions?

In 99.9% of cases it can detect the correct track length, so I didn't feel like it's necessary to implement any advanced logic/UI for that. But you and/or @david-sabata are free to improve this part.
The crux of the patch is 1) to avoid the "Not valid" state in the extension, AND 2) pass the duration of the track to last.fm when the scrobble is submitted.
(The changes to the minimum duration of the song before it gets submitted are unrelated, but they're a part of my patches, so I left them as they are. I've filed a separate feature request for that: #453 ).

@inverse the song object within scrobbler.js is much like singleton. It's created when the extension loads and then only its properties are changed. That's why popup.js directly writes to it and it works.
Also the popup should already be filled with values that were parsed from current page, if any.

@david-sabata I'm not seeing this working with any v1 scrobblers.
Example: https://soundcloud.com/eyesix/dyed-in-the-wool
Are you able the shed some light when you have some time?

@inverse it's possible that it really did stopp working some time ago. Also it cannot work if a connector doesn't send all the info it has. For example if there's a condition like if (artist==null || track==null) { /* dont send to background */ }, then the background script has nothing to prefill.
I probably said that somewhere else, but I'll repeat. I'm not a fan of adding new stuff for v1 connectors or legacy/scrobble.js. It works "good enough" and I'd like to keep it that way rather than broke it by adding new features :)
For v2 I'd like to have this as a part of a new popup window which will also contain song info, probably some buttons ("don't scrobble this",...) and such. But it's still in just an idea without some specific interface.

@david-sabata :+1:

@david-sabata I may be wrong, but isn't this already the behaviour of the old (current) manual_scrobble popup, in addition to the upcoming new popup? Think this can be closed.

@janbaykara we only submit the track if it is already on L.FM or has been corrected by user. But I suppose we can drop the second condition with the new popup. It was there because user couldn't edit the info once the track was (badly) recognized

Ah apologies, I misread the OP.

we only submit the track if it is already on L.FM or has been corrected by user. But I suppose we can drop the second condition with the new popup.

@david-sabata Any chance the first half of this is going to become optional in v2?
I listen to a lot of new music on Google Play Music and it's rather annoying that over half of the tracks aren't scrobbling because track.getInfo returns a 400 with error code 6 "Track not found". (Meanwhile, requesting track.getInfo?format=json at least returns an HTTP 200, with the same error & message; erm, thanks Last.fm?)
This means with v1.52 if I want the tracks to scobble I have to sit here baby-sitting the extension and clicking through the unrecognized track/manual scrobble popup on just about every song.

Closed as a duplicate of #185.


add fluxible logo and use new font

@annawchou @jedireza @mridgway @lingyan
I've changed from using Nobile custom font to Montserrat as suggested by @annawchou.
Check out the screen shots below:

CLA is valid!

Coverage remained the same at 90.82% when pulling 94f442e07af1dcf006817d4e924ac156b5e6be72 on logo into 7a4e420e66e622d2590805559dac42147c9609b4 on master.

Coverage remained the same at 90.82% when pulling e3004edf90dea6a2699ad7a31007144670ad90a1 on logo into 7a4e420e66e622d2590805559dac42147c9609b4 on master.

I think SVG files are vector and can be resized without loss. Do we need two (large/small)?

@jedireza you're right, no need for 2 versions. But why svg in the first place? png is better supported. On acss.io we are using a PNG and we re-use that same image (that we resize) inside the header on other pages.

@annawchou suggested the small one because when the larger logo was resized to the smaller one, it was too hard to read. I didn't actually try this myself, I just used the smaller one instead. Anna can comment.

@thierryk when the logo is resized the detail of the spacing gets lost

@redonkulus can you add a line-height to vertically align the logo in the top nav?

@redonkulus delete logo_big and just use the logo_small and resize that one for the splash page

@redonkulus yes, if you use SVG, it is better to use the small one, but with PNG you can start big and resize it. Better browser support

Coverage remained the same at 90.82% when pulling 4c6e81d41c4095867b052823af384fd49da82aee on logo into 7a4e420e66e622d2590805559dac42147c9609b4 on master.

@thierryk @jedireza using the small one now, removed the large one.


Anyway to change the presence type?

Instead of seeing Playing Plex, can it be set to Watching Plex instead?

Discord limitation, can't change that.


operator gitlab-runner-operator (1.18.1)

/merge possible

@ggeorgiev-gitlab again, as I said in https://github.com/redhat-openshift-ecosystem/community-operators-prod/pull/3386#issuecomment-1749146613, this won't merge until you fix all previous bundles.


Add command to generate a project skeleton for various project types

i.e. Web application, CLI tool, CLI application, Micro-site, REST API

:+1:


Amend link to point at VS 2017 page

Old link giving a 404, so point at new VS 2017 page

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

@steveculshaw : Thanks for your contribution to the Azure documentation! The author, @mlearned, has been notified to review your proposed change.

#sign-off


Ionic2 content init working, load image window scroll event not triggering

I'm trying to use your directive inside an ng2-ion2 project and it seems the scroll event is not being triggered. I've looked in your source code and it seems to me that the observable event is not being triggered. I think Observable.fromEvent(window, 'scroll') should be adjusted to an Ionic2 scroll event to make it work.
Reproduce

Install & import directive (Ionic2 project)
Template:
Class constructor:

this.defaultImage = 'https://www.placecage.com/1000/1000';
this.image = 'https://images.unsplash.com/photo-1443890923422-7819ed4101c0?fm=jpg';
this.offset = 100;

Result
Initial default images are being shown, the lazyload images are not loaded, so that's working.
But the scroll event is not being triggered so lazyloading new images is not working in Ionic2.
Thank you.

Hi,
You are right. window will not trigger any scroll-event in a ng2-ion2 project.
I have updated the code (d763b7c15031dea9852621be2b6b7ec1c45084ab) with the ability to change what element we want to listen on scroll-events, eg:

I created a demo project:
$ ionic start ionic-lazy-load-images --v2
$ npm install<EMAIL_ADDRESS>--save

and updated:
ionic-lazy-load-images/app/pages/page1/page1.js:
import { Page } from 'ionic-angular';
import { LazyLoadImageDirective } from 'ng2-lazyload-image';

@Page({
  templateUrl: 'build/pages/page1/page1.html',
  directives: [ LazyLoadImageDirective ]
})
export class Page1 {
  constructor() {
    this.defaultImage = 'https://www.placecage.com/1000/1000';
    this.image = 'https://images.unsplash.com/photo-1443890923422-7819ed4101c0?fm=jpg';
    this.offset = 100;
  }
}

ionic-lazy-load-images/app/pages/page1/page1.html:
<ion-navbar *navbar>
  <ion-title>Tab 1</ion-title>
</ion-navbar>

<ion-content padding class="page1" #container>

Welcome to Ionic!

    This starter project comes with simple tabs-based layout for apps
    that are going to primarily use a Tabbed UI.

</ion-content>

And it seems to work fine :)

Works! Awesome, thanks.
(Note #container has to be placed on an ion-content tag)

should use getter method for the scrollTarget