text:
Our API suggests that panicking should be the default

In spirit of https://github.com/bevyengine/bevy/issues/12660
Adapted from https://github.com/bevyengine/bevy/pull/14268
What problem does this solve or what need does it fill?
I believe it is not controversial to say that when an API offers two similar functions with similar names, the shorter will seem like the default. As such, I believe many people will instinctively gravitate to single and single_mut over get_single and get_single_mut. This means we are subtly pushing users to prefer the implicitly panicking version over the fallible one. This is bad, as it leads to games that may run well on the developers machine but then panic in an edge case.
It is currently understood in the wider Rust community that panics should be an exceptional case, a nuclear option for when recovery is impossible.
We should do our best to make it as easy to do the right thing by default (See Falling Into The Pit of Success). This means that it should be easier to handle an error by propagating it with ? to a logger or similar than to panic. Our current API does the opposite.
This is an issue for the following APIs:

Query::single
Query::get
World::resource
World::non_send_resource (although eventually this will likely be on App)
All of the other non-deferred entity-component-manipulating APIs listed in https://github.com/bevyengine/bevy/issues/14231

What solution would you like?
Deprecate and remove panicking variants. Improve ergonomics by adding macros for early returns. Using a macro for get_single as an example:
fn do_stuff(primary_window: Query<&Window, With<PrimaryWindow>>) {
    let window = get_single!(primary_window);
    // Do stuff with the window. If there's not exactly one, we have already returned.
}

Which expands to:
fn do_stuff(primary_window: Query<&Window, With<PrimaryWindow>>) {
    match primary_window.get_single() {
        Ok(item) => item,
        Err => return default(),
    };
    // Do stuff with the window. If there's not exactly one, we have already returned.
}

Note that returning default() will allow the macro to work with systems that return an Option and get piped into error handling methods.
Similar macros are already being used by some users, as indicated by https://github.com/tbillington/bevy_best_practices?tab=readme-ov-file#getter-macros
Paraphrasing @alice-i-cecile:

I'm also coming around on the macro approach: I'd rather this be a Rust feature where we can just ? in function that return (), but failing that this is better than the endless let else return pattern.
As the engine matures, I'm increasingly against panicking APIs, especially in seemingly innocuous cases like this. While it's nice  for prototyping, it's a serious hazard for refactors and production-grade apps.
We should decide on what to do for all of these areas at the same time and make a consistent decision across the board, pulling in both SME-ECS and @cart. I think they're better implemented as separate PRs to avoid extreme size, but they should be shipped in the same cycle if we make the change.

What alternative(s) have you considered?

Do nothing
Leave the API as-is and heavily recommend the get_ variants in documentation
Print a warning when calling panicking variants
Keep the panicking variants and rename them to something clunky like _unchecked
Make the panicking API opt-in via a feature
Leave the API as-is and let the schedule handle panics
Use a #[system] macro that modifies the code to allow us to use ? in it, like in bevy_mod_sysfail

Open Questions
Naming
There is a sentiment that get_ is used by the standard library in general when returning an Option.
Quoting @benfrankel:

This isn't true for the standard library: Vec::first, Iterator::next, Path::parent, Error::source, etc.
The get_ prefix is only used to differentiate from a panicking version. If there's no panicking version, there's no need for the get_ prefix. For some reason Bevy has latched onto foo vs get_foo as the only API choice when foo may fail, but it doesn't have to be this way.

In a world where Bevy is not panicking by default and always hands out Options and Results, I believe there is little reason to stick to a get_ prefix. It is unnecessary noise on otherwise very concise functions. As such, I would advise to change Bevy's naming convention and drop it as part of this initiative. This may sound like something for another issue, but I'll argue that it should be discussed at least in the same release cycle. Users will already have to go and touch every instance of mut, single, etc. so I don't want to further annoy them by having to change them yet a second time when we drop the get_ prefix.
I realize that this is more controversial however and I'm fine with leaving it. I just want to point out that this is probably the best chance we will get to change it.
Macro parameters
It would be nice to have some influence over what should be done in the unhappy path. For example, we could have a parameter that controls an error! log:
get_single!(foo, "Oh heck");

which expands to:
match foo.get_single() {
    Ok(item) => item,
    Err => {
        error!("Oh heck");
        return default();
    }
};

Of course, the use of error! is arbitrary here and the user may want to use warn! instead or something else altogether. To accommodate for this, we could pass a closure:
get_single!(foo, || error!("Oh heck"));

Which expands to the same as above. Note that this closure could even dictate what we return. Since error! returns (), this works out for the common case, and a user is free to build their own Error variant. However at that point, I don't know if a macro call is saving much typing work anymore.
One could also combine these variants by using labeled parameters:
get_single!(foo, warn: "Oh heck");
get_single!(bar, error: "Oh heck");
get_single!(baz, returns: || error!("Oh heck"));

This would allow the user to have a terse version for the common case usage and a more verbose one for custom error handling.
continue
This discussion has focused on the case where we want an early return. I think that is the common case, at least in my experience. What about continue however? Do we want a _continue variant for all macros? An extra parameter? Is there some kind of Rust hack that turns into either continue or return depending on context? Would that even be what the user expects to happen?

Pinging SME-ECS: @JoJoJet @maniwani

I agree with this I think, however it would be unfortunate for singleton-style components to become more verbose. single is one of those panicking methods that kind of makes sense, since if you use it with a component type that you only spawn one of it's always correct.
Maybe we could remove panicking-by-default and still avoid the verbosity by having a marker trait for singleton components, which would unlock the infallible accessor for that type

@JoJoJet You could also do the following, assuming we remove the get_ suffix and allow passing a function to the macro as a second param:
let singleton = single!(singleton); // early return
let singleton = single!(singleton, panic); // panic if there's not exactly one

Although there's a caveat here: panic! returns the never type ! which in the Rust 2024 edition will no longer implicitly become (), turning this into the supremely ugly
let singleton = single!(singleton, || -> () { panic!() }); // panic if there's not exactly one

The RFC for postfix macros would make this pattern so much nicer. Waiting for a language feature isn't practical, though.

At work we started using a slightly different pattern. We use the early return, but we use a debug_assert so it still panics in debug to help us catch those issues. That way it doesn't panic for our users if something unexpected happens.

My take is generally still what I discussed here: https://github.com/bevyengine/bevy/issues/12660#issuecomment-2111371565
Specifically, I think we should investigate the viability of the following plan:

Make Result systems feel more automatic / first class  (id like to stress that result systems are already possible, they just currently require an addition function call at registration). Ideally it is just as simple as returning Result in an existing system. If this isn't possible (while retaining support for non-result systems) for type-system reasons, investigate further.app.add_systems(Update, window_thing)

fn window_thing(windows: Query<&Window>) -> Result {
  let window = windows.get_single()?;
  OK // this is a const export of Ok(())
}

Replace the majority of Option-returning functions with Results, which then enables ? to work seamlessly for pretty much everything:fn world_thing(world: &mut World) -> Result {
  let entity = world.get_entity(SOME_ENTITY)?;
  OK
}

Replace panicking nice-name api names (ex: entity()) with the Result-returning variant (and remove the old get_entity() function):fn world_thing(world: &mut World) -> Result {
  let entity = world.entity(SOME_ENTITY)?;
  OK
}

Imo it is critical to prove steps (2) and (3) out first and do it "as a single transaction" from a user perspective. Skipping straight to step (3) (while easy) puts the cart before the horse and imo makes Bevy UX worse for a period of time (at best) and at worst, commits us to a path that may not be viable or ideal (due to unknowns not yet discovered). Skipping (2) would mean that ? isn't the "ergonomic one size fits all" solution it needs to be.
I do think the macro approach is an interesting "middle ground", but it feels like we're just re-implementing the ? behavior in a clunkier / less idiomatic / less flexible way. Rather than create a zoo of ways to solve this problem (and encourage people to migrate once to a middle ground solution, then again to the "final" solution), I think I'd prefer to just invest in a single canonical ideal solution.
That being said, if it doesn't already exist, I think it makes a lot of sense to build the macro approach as a 3rd party crate. That seems like an appropriate "quick no bureaucracy" middle ground solution while we sort out the details.

As a supplement, I think it would also be interesting to investigate an Option extension trait that lets you do this:
fn system() -> Result {
  let list = vec![1, 2];
  let x = list.get(0).unpack()?;
  let y = list.get(1).assume("index 1 should exist")?;
  OK
}

Where unpack() (non panicking unwrap variant) maps Option<T> to Result<T, ContextlessError>. And assume()  (non panicking expect variant) maps to Result<T, MessageError>.

unpack and assume seem very similar to Option::ok_or.

ok_or is different in that it forces you to select and provide an error type. ok_or() is not a replacement for the "screw it I just want a value" mindset of unwrap()

Ditto for y = list.ok_or("index 1 should exist")?;. If you omit the ? it will compile, but because &str does not directly implement Error, adding ? would cause a failure to compile in the context of an anyhow-style catch-all error. It would need to be something like list.ok_or(MessageError("index 1 should exist"))?, which defeats the "screw it" mindset.

IMO better error handling shouldn't block a rename from e.g. single, get_single to single.unwrap, single. It's a footgun today, and it won't require any design work to solve.

Copying my sentiment from Discord here. The proposed additions to Option are great, but there is already anyhow::Context for exactly this.
anyhow is supremely mature and one of the most widely crates in Rust in general, so I think we should take advantage of this and just re-export it. We can also not re-export it and just tell users to use it.
But reinventing the wheel here seems rather pointless imo

(Also just mirroring discord) I do suspect that we may want our own top level general-purpose (anyhow-style catch-all) Bevy error type to allow us to better encapsulate Bevy context (such as system context). However should should definitely consider using anyhow given its maturity and featureset. Worth weighing both options. I agree that Context::context fills the same role as assume() (but not unpack()).

Replace the majority of Option-returning functions with Results

IMO we can and should start on this today: I've been frustrated by this in the past.

IMO we can and should start on this today: I've been frustrated by this in the past.

I still think we might want to land this all as a whole, as some people might be relying on the proliferation of Option to use ? in the context of code like fn something(world: &World) -> Option<Something> {  world.get_entity(SOME_ENTITY)?; } . We risk breaking people multiple times / forcing them to stop using ? if we do this piecemeal.

(if you're saying we should start merging these changes now as they come in)
If you're just saying "lets break ground now", I'm fully on board :)

Make Result systems feel more automatic / first class ... Ideally it is just as simple as returning Result in an existing system

Just noting that I previously explored this approach in https://github.com/bevyengine/bevy/pull/8705, but I decided to abandon it becuase it made the stack traces for errors useless, which was worse than just calling unwrap() where the error originates IMO

Yep, fine to wait on merging. We should at least get a list for now.

@JoJoJet its worth calling out that the anyhow impl supports this reasonably (using built in rust features), provided you enable the backtrace cargo feature (and run with the RUST_BACKTRACE=1 environment variable):
use anyhow::Result;
use thiserror::Error;

fn main() {
    let result = foo();
    println!("{:?}", result);
}

fn foo() -> Result<()> {
    bar()?;
    Ok(())
}

fn bar() -> Result<()> {
    let x = vec![1, 2];
    let y = x.get(2).ok_or(E1)?; // backtrace correctly points here
    Ok(())
}

#[derive(Error, Debug)]
#[error("hello")]
struct E1;

Prints:
Err(hello

Stack backtrace:
   0: anyhow::error::<impl core::convert::From<E> for anyhow::Error>::from
             at /home/cart/.cargo/registry/src/index.crates.io-6f17d22bba15001f/anyhow-1.0.86/src/backtrace.rs:27:14
   1: <core::result::Result<T,F> as core::ops::try_trait::FromResidual<core::result::Result<core::convert::Infallible,E>>>::from_residual
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/core/src/result.rs:1964:27
   2: rust_playground::x
             at ./src/main.rs:11:13
   3: rust_playground::main
             at ./src/main.rs:5:18
   4: core::ops::function::FnOnce::call_once
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/core/src/ops/function.rs:250:5
   5: std::sys_common::backtrace::__rust_begin_short_backtrace
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/sys_common/backtrace.rs:155:18
   6: std::rt::lang_start::{{closure}}
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/rt.rs:159:18
   7: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/core/src/ops/function.rs:284:13
   8: std::panicking::try::do_call
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panicking.rs:559:40
   9: std::panicking::try
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panicking.rs:523:19
  10: std::panic::catch_unwind
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panic.rs:149:14
  11: std::rt::lang_start_internal::{{closure}}
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/rt.rs:141:48
  12: std::panicking::try::do_call
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panicking.rs:559:40
  13: std::panicking::try
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panicking.rs:523:19
  14: std::panic::catch_unwind
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panic.rs:149:14
  15: std::rt::lang_start_internal
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/rt.rs:141:20
  16: std::rt::lang_start
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/rt.rs:158:17
  17: main
  18: <unknown>
  19: __libc_start_main
  20: _start)

We could also consider adding a bevy feature that sets the environment variable for people:
#[cfg(feature = "backtrace")]
std::env::set_var("RUST_BACKTRACE", "1")

Just verified that this works. Then if/when we add a "dev" meta-cargo-feature, we could add "backtrace" to it. Then when people do cargo run --features bevy/dev  during development (which I think we'll want to recommend ultimately), it will "just work".

Ah good point. We could provide a dedicated SystemError type that captures a backtrace when you convert to it via ?. If this type is used for nothing other than system return types, it wouldn't need to implement std::error::Error, so we could provide a blanket From impl for all error types without breaking coherence

@JoJoJet I want to point out that that would again increase the amount of code we duplicate from anyhow.
Is there something Bevy-specific we need in our error type that would justify creating it over using anyhow::Error? I suppose Bevy functions could populate some kind of metadata field on the error, but I'm struggling to think of something useful to put there that would not already be handled by the log call printing the underlying error.

I think it would be kind of weird for us to use anyhow::Error in our public APIs, and I don't think we should allow error types without a backtrace as I know from experience that it is a massive footgun to refactor all of your unwraps into a custom error type, only to later realize that all of your error messages are worthless. I think we should guard users against this trap by forcing them to use an error type with a backtrace. It could just be anyhow::Error, but that would seem weird to me as opposed to using a bevy-specific error type tailor-made for this purpose

Yeah, whatever the solution, usable backtraces are definitely a must-have.

I published a crate for the macro approach: https://github.com/benfrankel/tiny_bail.
I used (an earlier version of) these macros during the game jam and they were exceptionally convenient.

I feel like this issue drifted from the original purpose and either needs a rename or split to more issues.
My few cents are that we can't take the ergonomic hit from unwrapping everything by hand.
Either we slightly tweak the existing API to make non-panicking methods easier to access, but still keep the panicking ones.
Or we go with the ? approach you guys are discussing, but there seems to be no progress on actually providing that.
The reason I have to write this is, this is causing problems just by existing.
Each new API now has to decide whether it should expose panicking methods or not.
At the bare minimum this issue needs to resolve how new features should expose their APIs, old or new convention.
@alice-i-cecile

@MiniaczQ I think Cart's point here is that changing it now is really disruptive to users, and will be really disruptive again once we have better error handling.
I personally think this is enough of a footgun / API issue to warrant these consequences, but I see the point.

My suggestion is that issues need to stop being marked as X-Controversial because they are in any way involved with this issue.
The controversy is solely here.
The problem is that it's unclear whether new features should expose panicking APIs or not, and that should be decided right now, because not knowing that is halting progress.

I've only seen this issue now. My take is Results are the wrong way to go about this. The original problem of "do we panic or not" comes about from error types already (Option). Adding a more granular error type Result with more ways to handle them doesn't remedy that it makes it worse.
The solution to this I would prefer is to lean into the ECS paradigm more & treat more things as if they were querying the world. If a Res<Foo> doesn't exist the system just doesn't run. Similar to how iterating over a Query<Bar> that matches nothing loops over nothing. If users want a more explicit panicky behavior they can use Option<Res<Foo>> & unwrap.
This also makes for nicer breaking changes because users already have it set up so that systems with Res<Foo> don't panic cause they can't really do anything else with them? The diagnostics from those panics are unreliable at best to begin with.
Additionally this kind of default just makes for better graceful behavior for released apps.

The solution to this I would prefer is to lean into the ECS paradigm more & treat more things as if they were querying the world. If a Res<Foo> doesn't exist the system just doesn't run. Similar to how iterating over a Query<Bar> that matches nothing loops over nothing. If users want a more explicit panicky behavior they can use Option<Res<Foo>> & unwrap.

This only resolves errors during resource acquisition, systems can have other types of errors that need to be resolved and it'd be good to have a solution for that too.

The solution to this I would prefer is to lean into the ECS paradigm more & treat more things as if they were querying the world. If a Res doesn't exist the system just doesn't run. Similar to how iterating over a Query that matches nothing loops over nothing. If users want a more explicit panicky behavior they can use Option<Res> & unwrap.

I do think we should do this, and if we can get this behavior in place I'd prefer to encourage the use of the Single system param from #15264. This would go a long way to addressing the problem and ensuring non-panicking behavior by default without an ergonomics hit.
That said, I agree with @MiniaczQ above that Bevy needs better error-handling from within systems in general, and generally feel like we should be using more descriptive Result types over Option in most places.

This only resolves errors during resource acquisition, systems can have other types of errors that need to be resolved and it'd be good to have a solution for that too.

Which I think should be a different mechanism. Anything that can be treated as querying the world should be treated as querying the world.

@iiYese the reason Results are being discussed over Options is for error propagation without requiring anyhow-style .context, IIRC

The problem is that it's unclear whether new features should expose panicking APIs or not, and that should be decided right now, because not knowing that is halting progress.

Im thinking we should be building new APIs consistent with the current Bevy API pattern (panicking shortname with get_X for errors/results). Until we have solved the UX issues around error handling, I don't think we're ready to be hard-liners about Results-only apis.
Those interested in changing that paradigm should invest in resolving the technical questions outlined here, then start mapping out what a holistic port looks like so we can do this all in one fell swoop.

#15302 and #15264 should help a bit, any other system params we could use?

NonEmptyEventReader is the other system param in this family :)

@hymm suggested that the scheduler should treat systems as fallible by default, and convert systems that return () into Ok(()). I like this plan, and I'm hoping to take a crack at a design in 0.16 if no one beats me to it.

Note that systems can fail externally (missing parameters) or internally (return None/Err), I believe we should keep those 2 separate, so they don't get mixed when casting to Box<dyn Error> for default error handling

I've had a crack at implementing the basic suggestions here: https://github.com/bevyengine/bevy/pull/16589.

authors: IceSentry JoJoJet MiniaczQ NthTensor alice-i-cecile benfrankel cart iiYese janhohenheim


text:
screenshot example crashes on Linux, Wayland with Nvidia GPU

Bevy version
Bevy 0.11-dev: https://github.com/bevyengine/bevy/commit/a35ed552fafaffce8a28c7d47b3e294d755ff096
System information
rustc 1.71.0-nightly (2a8221dbd 2023-05-11), Arch Linux with kernel 6.3, Gnome 44 with Wayland
Adapter Vulkan AdapterInfo { name: "NVIDIA GeForce RTX 3060 Laptop GPU", vendor: 4318, device: 9568, device_type: DiscreteGpu, driver: "NVIDIA", driver_info: "530.41.03", backend: Vulkan }

What you did
Run Bevy's screenshot example on Wayland:
RUST_BACKTRACE=1 RUST_LOG=debug WGPU_BACKEND=vulkan cargo run --features wayland --example screenshot

What went wrong
After I pressed SPC, the app crashed.
Additional information
Full log: https://gist.github.com/VitalyAnkh/df177b789fac6b4b676864772c173a60
Line 13551 in the log shows:
    Incompatible color attachments at indices [0]: the RenderPass uses textures with formats [Some(Bgra8Unorm)] but the RenderPipeline uses attachments with formats [Some(Bgra8UnormSrgb)]

For precision: it works on Linux X11/AMD.

Not sure if this is related, or a separate issue, but all of the examples crash for me on Linux + Nvidia + Wayland, with error:
2023-05-28T04:49:21.824018Z  WARN wgpu_hal::vulkan: Unrecognized device error ERROR_INITIALIZATION_FAILED
thread 'main' panicked at 'Error in Surface::configure: Validation Error

Caused by:
    Parent device is lost

If I don't enable the Wayland feature everything works as normal.
(tested on commit a9ca40506e3dbc5048dc38601d1e3baed6f4a172)

@A-Walrus Hi! I can run bevy's many examples on Linux + Nvidia + Wayland, like many_foxes:
RUST_BACKTRACE=1 RUST_LOG=info WGPU_BACKEND=vulkan cargo run --features wayland --example many_foxes
    Finished dev [unoptimized + debuginfo] target(s) in 0.29s
     Running `target/debug/examples/many_foxes`
2023-05-28T06:21:45.391962Z  INFO bevy_winit::system: Creating new window "🦊🦊🦊 Many Foxes! 🦊🦊🦊" (0v0)
2023-05-28T06:21:45.679341Z  INFO wgpu_hal::vulkan::instance: Unable to find extension: VK_EXT_swapchain_colorspace
2023-05-28T06:21:45.720853Z  INFO wgpu_hal::vulkan::instance: Instance version: 0x4030f6
2023-05-28T06:21:45.720884Z  INFO wgpu_hal::vulkan::instance: Enabling debug utils
2023-05-28T06:21:45.720945Z  INFO wgpu_hal::vulkan::instance: Enabling device properties2
2023-05-28T06:21:45.721143Z  INFO wgpu_hal::vulkan::instance: GENERAL [Loader Message (0x0)]
	linux_read_sorted_physical_devices:
2023-05-28T06:21:45.721175Z  INFO wgpu_hal::vulkan::instance: 	objects: (type: INSTANCE, hndl: 0x559f1998abb0, name: ?)
2023-05-28T06:21:45.721191Z  INFO wgpu_hal::vulkan::instance: GENERAL [Loader Message (0x0)]
	     Original order:
2023-05-28T06:21:45.721196Z  INFO wgpu_hal::vulkan::instance: 	objects: (type: INSTANCE, hndl: 0x559f1998abb0, name: ?)
2023-05-28T06:21:45.721207Z  INFO wgpu_hal::vulkan::instance: GENERAL [Loader Message (0x0)]
	           [0] NVIDIA GeForce RTX 3060 Laptop GPU
...

Bevy works well with Nvidia + Wayland on most scenarios now so your "Parent device is lost" should be another bug of Bevy or a desktop environment configuration error. Did run this example from an X11 session?

I'm definently on Wayland, will check if this is an issue with wgpu in general or bevy specifically and report. Thanks!

source: gharchive/issue

authors: A-Walrus VitalyAnkh nicopap

repo: bevyengine/bevy

license_type: permissive

license_source: github-api


text:
[Example] compute_shader_game_of_life crashes.

Bevy version
0.11.2
[Optional] Relevant system information
Rust: 1.70.0
OS: Arch Linux
AdapterInfo { name: "Mesa Intel(R) UHD Graphics 630 (CML GT2)", vendor: 32902, device: 0, device_type: IntegratedGpu, driver: "", driver_info: "", backend: Gl }

What you did
cargo run --features wayland --features dynamic_linking --example compute_shader_game_of_life

What went wrong
It crashed:
2023-09-02T13:14:00.305416Z ERROR wgpu_hal::gles::egl: GLES: [ShaderCompiler/Error] ID 1 : 0:9(1): error: image variables of format other than r32f, r32i or r32ui must be qualified `readonly' or `writeonly'
2023-09-02T13:14:00.306334Z ERROR wgpu::backend::direct: Handling wgpu errors as fatal by default
thread 'Compute Task Pool (5)' panicked at 'wgpu error: Validation Error

Caused by:
    In Device::create_compute_pipeline
    Internal error: 0:9(1): error: image variables of format other than r32f, r32i or r32ui must be qualified `readonly' or `writeonly'

', /home/so1aric/.cargo/registry/src/mirrors.tuna.tsinghua.edu.cn-2eab394af869c8a2/wgpu-0.16.3/src/backend/direct.rs:3019:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Encountered a panic in system `bevy_render::render_resource::pipeline_cache::PipelineCache::process_pipeline_queue_system`!
thread 'Compute Task Pool (5)' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', crates/bevy_render/src/pipelined_rendering.rs:143:45
warning: queue 0x55e43da78ed0 destroyed while proxies still attached:
  xdg_wm_base@23 still attached
  wl_output@15 still attached
  wp_fractional_scale_manager_v1@14 still attached
  xdg_activation_v1@13 still attached
  zwp_text_input_manager_v3@12 still attached
  zwp_relative_pointer_manager_v1@11 still attached
  zwp_pointer_constraints_v1@10 still attached
  zxdg_decoration_manager_v1@9 still attached
  wl_seat@8 still attached
  wp_viewporter@7 still attached
  wl_subcompositor@6 still attached
  wl_compositor@5 still attached
  wl_shm@4 still attached
  wl_registry@2 still attached

2023-09-02T13:22:43.389053Z  WARN bevy_pbr::ssao: ScreenSpaceAmbientOcclusionPlugin not loaded. GPU lacks support: TextureFormat::R16Float does not support TextureUsages::STORAGE_BINDING.
2023-09-02T13:22:44.395480Z ERROR wgpu_hal::gles::egl: GLES: [API/Error] ID 1 : GL_INVALID_ENUM in glTexStorage2DMultisample(target=GL_TEXTURE_2D)
2023-09-02T13:22:44.395642Z ERROR wgpu_hal::gles::egl: GLES: [API/Error] ID 1 : GL_INVALID_ENUM in glTexStorage2DMultisample(target=GL_TEXTURE_2D)
2023-09-02T13:22:44.623244Z ERROR wgpu::backend::direct: Shader translation error for stage ShaderStages(FRAGMENT): gsamplerCubeArrayShadow isn't supported in textureGrad, textureLod or texture with bias
2023-09-02T13:22:44.623279Z ERROR wgpu::backend::direct: Please report it to https://github.com/gfx-rs/naga
2023-09-02T13:22:44.623307Z ERROR wgpu::backend::direct: Handling wgpu errors as fatal by default
thread 'Compute Task Pool (3)' panicked at 'wgpu error: Validation Error

Caused by:
    In Device::create_render_pipeline
      note: label = `pbr_opaque_mesh_pipeline`
    Internal error in ShaderStages(FRAGMENT) shader: gsamplerCubeArrayShadow isn't supported in textureGrad, textureLod or texture with bias

', /home/so1aric/.cargo/registry/src/mirrors.tuna.tsinghua.edu.cn-2eab394af869c8a2/wgpu-0.16.3/src/backend/direct.rs:3019:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Encountered a panic in system `bevy_render::render_resource::pipeline_cache::PipelineCache::process_pipeline_queue_system`!
thread 'Compute Task Pool (3)' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', crates/bevy_render/src/pipelined_rendering.rs:143:45
warning: queue 0x55730ad944d0 destroyed while proxies still attached:
  xdg_wm_base@23 still attached
  wl_output@15 still attached
  wp_fractional_scale_manager_v1@14 still attached
  xdg_activation_v1@13 still attached
  zwp_text_input_manager_v3@12 still attached
  zwp_relative_pointer_manager_v1@11 still attached
  zwp_pointer_constraints_v1@10 still attached
  zxdg_decoration_manager_v1@9 still attached
  wl_seat@8 still attached
  wp_viewporter@7 still attached
  wl_subcompositor@6 still attached
  wl_compositor@5 still attached
  wl_shm@4 still attached
  wl_registry@2 still attached

Another example also crashes. I suspect it's my computer's fault😂

Example works fine on my system. Got 1 error but program didn`t crash.
 ERROR sctk_adwaita::config: XDG Settings Portal did not return response in time: timeout: 100ms, key: color-scheme
2023-09-08T10:51:07.750294Z  INFO bevy_render::renderer: AdapterInfo { name: "Intel(R) UHD Graphics 770 (ADL-S GT1)", vendor: 32902, device: 18048, device_type: IntegratedGpu, driver: "Intel open-source Mesa driver", driver_info: "Mesa 23.0.4-0ubuntu1~22.04.1", backend: Vulkan }


text:
Decouple BackgroundColor from UiImage and UiTextureAtlasImage

Objective
Fixes https://github.com/bevyengine/bevy/issues/11157.
Solution
Stop using BackgroundColor as a color tint for UiImage and UiTextureAtlasImage. Add UiImage::color and UiTextureAtlasImage::color fields for color tint instead. Allow a UI node to simultaneously include a solid-color background and an image, with the image rendered on top of the background (this is already how it works for e.g. text).

Changelog

BackgroundColor no longer applies color tint to UI images, but adds a solid-color background behind the image instead.
Added UiImage::color and UiTextureAtlasImage::color.
Removed ButtonBundle::image.
Updated RenderUiSystem variants.
Renamed bevy_ui::extract_xyz functions for consistency.

Migration Guide

BackgroundColor no longer applies color tint to UI images. Instead, use UiImage::color or UiTextureAtlasImage::color.
ButtonBundle::image has been removed. You can still include a UiImage component with your button entity outside of the bundle.
bevy_ui::extract_atlas_uinodes has been renamed to extract_uinode_atlas_image.
bevy_ui::extract_uinode_borders has been renamed to extract_uinode_border.
bevy_ui::extract_uinode_outlines has been renamed to extract_uinode_outline.
bevy_ui::extract_text_uinodes has been renamed to extract_uinode_text.
bevy_ui::extract_uinodes has been split into bevy_ui::extract_uinode_background and bevy_ui::extract_uinode_image.

I'm not sure the changelog / migration guides are written the way they should be / covering what they should.
Also, I removed Without<ContentSize> from the UI node query in extract_uinode_border so that I could add a border to the ui_texture_atlas example, but there may be a good reason for it that I'm not aware of (@ickshonpe ?).

I'm not sure the changelog / migration guides are written the way they should be / covering what they should.
Also, I removed Without<ContentSize> from the UI node query in extract_uinode_border so that I could add a border to the ui_texture_atlas example, but there may be a good reason for it that I'm not aware of (@ickshonpe ?).

Also I'm curious if there's a reason that ExtractedUiNodes::uinodes is a hash map with Entity key instead of just a Vec. The code isn't straightforward so I couldn't tell how the Entity gets used. Most of the extract_uinode_xyz systems just create a new entity with commands.spawn_empty().id() anyways, and now only extract_uinode_background uses the actual original UI node entity as a key.

Also I'm curious if there's a reason that ExtractedUiNodes::uinodes is a hash map with Entity key instead of just a Vec. The code isn't straightforward so I couldn't tell how the Entity gets used. Most of the extract_uinode_xyz systems just create a new entity with commands.spawn_empty().id() anyways, and now only extract_uinode_background uses the actual original UI node entity as a key.

isn't the Entity used in bevy_ui\src\render\mod.rs by the Render phase?
Btw, good changes, the examples probably will change too.

I put in a similar PR a year ago https://github.com/bevyengine/bevy/pull/7451 but it got no reviews.
I'm happy to close that though in favour of this one, as this one targets the latest bevy.

I think as well in my PR the colour was a field on the UiImage type, which isn't as flexible as a separate component and makes change detection awkward.
We can probably solve that if we go with the ColorTint idea in the future

I think as well in my PR the colour was a field on the UiImage type, which isn't as flexible as a separate component and makes change detection awkward.

We can probably solve that if we go with the ColorTint idea in the future

Ah yeah I wrote that before I looked at the source, I assumed you were going with a separate component for the color.

I'm not sure the changelog / migration guides are written the way they should be / covering what they should.
Also, I removed Without<ContentSize> from the UI node query in extract_uinode_border so that I could add a border to the ui_texture_atlas example, but there may be a good reason for it that I'm not aware of (@ickshonpe ?).

ContentSize uses different layout rules and may not work correctly with borders, I can't remember though it's been a while since I tested it. I think the filter should remain for now.
You should be able to display atlas images with a border with a construction like this I think
 commands.spawn((
        NodeBundle {
            style: Style {
                border: UiRect::all(Val::Px(20.)),
                ..Default::default()
            },
            border_color: Color::RED.into(),
            ..Default::default()
        },
        UiTextureAtlasImage { index, ..Default::default() },
        texture_atlas_handle
    ));

Or you could use an Outline instead of a border.

Also I'm curious if there's a reason that ExtractedUiNodes::uinodes is a hash map with Entity key instead of just a Vec. The code isn't straightforward so I couldn't tell how the Entity gets used. Most of the extract_uinode_xyz systems just create a new entity with commands.spawn_empty().id() anyways, and now only extract_uinode_background uses the actual original UI node entity as a key.

I made a couple of PRs improving UI extraction performance, but there were a lot of changes to rendering for Bevy 0.12, and not all of them have been merged yet. Some of them were: #9212 #9668 #9889 #9853 #9877

@benfrankel I'd like to review this and get it merged: can you resolve merge conflicts?

@alice-i-cecile done. Note that I half-reverted https://github.com/bevyengine/bevy/pull/11205 because with background color and images being extracted separately, skipping loading images won't also skip their background color.

@alice-i-cecile done. Note that I effectively reverted https://github.com/bevyengine/bevy/pull/11205 because with background color and images being extracted separately, skipping loading images won't also skip their background color. I might have misunderstood the issue there though, in which case I can remove the skip again.

Thanks! That's a question for @JMS55 and/or @mockersf.

UiImage is starting to become very similar to Sprite

UiImage is starting to become very similar to Sprite

It's out of scope for this PR of course, but in my opinion Sprite should also have UiImage's texture: Handle<Image> field instead of reading a separate Handle<Image> that's awkwardly floating around as a non-newtyped component on the same entity. And then... maybe they should just be the same component.

Helping migration by removing BackgroundColor from the image bundles as part of this change makes sense. My only concern is that that leaves the image bundles inconsistent with TextBundle (and NodeBundle).
I guess that's territory for a later PR, though, for other inconsistencies as well:

NodeBundle includes a BorderColor that defaults to transparent
ButtonBundle includes a BorderColor that defaults to white
TextBundle and image bundles don't include a BorderColor at all (because of taffy support, relevant: https://github.com/bevyengine/bevy/pull/10690)

^\_(``/)_/^

You are absolutely right, we need to schedule a cleanup to fix inconsistent components in bundles, for this PR I think we can focus on iso-functionality

source: gharchive/pull-request

authors: ManevilleF alice-i-cecile benfrankel ickshonpe pablo-lua


text:
Fix TextureCache memory leak and add is_empty() method

Objective
Fix a memory leak in TextureCache caused by the internal HashMap never having unused entries cleared.
This isn't a giant memory leak, given the unused entries are simply empty vectors. Though, if someone goes and resizes a window a bunch, it can lead to hundreds/thousands of TextureDescriptor keys adding up in the hashmap – which isn't ideal.
Solution

Only retain hashmap entries that still have textures.
I also added an is_empty() method to TextureCache, which is useful for 3rd-party higher-level caches that might have individual caches by view entity or texture type, for example.

Testing

Verified the examples still work (this is a trivial change)

@re0312 does this fix https://github.com/bevyengine/bevy/issues/14463 for you?

@re0312 does this fix #14463 for you?

It doesn't seem to resolve the problem, as memory leaks are still occurring on my machine.

authors: alice-i-cecile brianreavis re0312


text:
bevy_reflect: Add #[reflect(readonly)] attribute

Objective
There are times when you want a type to be Reflect, but don't want to allow the modification of certain fields. There a many reasons you might want to do this. One of those reasons is that your type might need to maintain certain invariants in its fields.
For example, we have defined a History type for an editor below.
struct History {
    /// New/redone actions are pushed here.
    undo_stack: Vec<Op>,
    /// Undone actions are pushed here.
    redo_stack: Vec<Op>,
}

It's important that the undo and redo actions are performed through the History::undo and History::redo methods so that the Op gets moved to the proper stack.
However, if we derive Reflect, then someone could very easily break this flow through reflection.
We could derive it as a #[reflect_value], but then our reflection-based editor pane can no longer display the undo and redo stacks.
Ideally, we'd be able to allow those fields to be visible without sacrificing our desired level of mutability privileges.
Solution
This PR adds a #[reflect(readonly)] field attribute that prevents that field from being mutably accessed via reflection.
Deriving Reflect on a type result in one of three subtraits being implemented: Struct, TupleStruct, or Enum. Because these are the only user-configurable traits (at least via the derive macro), these are the main trait affected by this PR.
All field, field_mut, field_at, and field_at_mut methods across these three traits have been modified to return a Result instead of an Option. The error type, ReflectFieldError, then has two variants:

NotFound - This takes the place of None, where the given field identifier does not exist on the type or the field is marked with #[reflect(ignore)].
Readonly - This is returned when attempting to mutably access a field marked with #[reflect(readonly)].

Additionally, the PartialReflect::try_apply method implementations—which rely on these field methods under the hood—will now skip readonly fields.
We also expose the readonly status of the field via type info:

NamedField::readonly
UnnamedField::readonly

This PR also adds the FieldId enum to help with error messaging. This will be super useful for error messaging in the future. And as an added benefit, it can even be used to consolidate named-vs-unnamed APIs:
// BEFORE
fn print_field(value: &dyn PartialReflect, name: &str) {/* ... */}
fn print_field_at(value: &dyn PartialReflect, index: usize) {/* ... */}

// AFTER
fn print_field(value: &dyn PartialReflect, id: impl Into<FieldId>) {/* ... */}

Again, not the point of this PR and not much use to us right now, but pretty cool nonetheless haha.
Open Questions

Should we split ReflectFieldError into mutable and immutable versions? I think I prefer having one error enum for these methods, but it does mean that the immutable methods will always have an "unreachable" pattern: the Readonly variant. It could make sense to split them up so the immutable methods don't have to deal with the variant, but I'm pretty sure many error types behave this way (io::Error, for example). So I don't think we should change it, but I'm open to opinions!

Testing
This PR adds a good handful of tests for this feature. To test locally, run the following command:
cargo test --package bevy_reflect

Showcase
Fields can now be marked as readonly when deriving Reflect, allowing them to be visible via reflection, but not mutable.
#[derive(Reflect)]
struct PlayerScore {
    #[reflect(readonly)]
    total: u32
}

let mut score: Box<dyn Struct> = Box::new(PlayerScore { total: 100 });

// We can still immutably access the field:
let total = score.field("total").unwrap();
assert_eq!(total.try_downcast_ref::<u32>(), Some(&100));

// But we cannot access the field mutably:
score.field_mut("total").unwrap(); // PANIC!

Migration Guide
The return types on the following methods have been changed from Option<...> to Result<..., ReflectFieldError>:

Struct::field
Struct::field_mut
Struct::field_at
Struct::field_at_mut
TupleStruct::field
TupleStruct::field_mut
Enum::field
Enum::field_mut
Enum::field_at
Enum::field_at_mut

While it's recommended to handle errors explicitly, an easy way to migrate existing code with minimal changes is to simply convert the Result back to an Option:
// BEFORE
fn extract_value(container: &dyn Struct) -> Option<&dyn PartialReflect> {
    container.field("value")
}

// AFTER
fn extract_value(container: &dyn Struct) -> Option<&dyn PartialReflect> {
    container.field("value").ok()
}

Also note that only the _mut methods return the ReflectFieldError::Readonly variant. For the immutable methods, only the ReflectFieldError::NotFound should be expected.

i'm not convinced we should have a readonly attribute. i don't think "readonly for the purposes of of reflection" is really a useful category.
however, i do think we should be able to mitigate usages of the described pattern.
instead, i think it would be better to make bevy_reflect delegate to Rust's field publicity rules, so only pub fields can be read/written to. this would be a major breaking change but it's unlikely this will cause significant breakage in practice.

i'm not convinced we should have a readonly attribute. i don't think "readonly for the purposes of of reflection" is really a useful category.
however, i do think we should be able to mitigate usages of the described pattern. instead, i think it would be better to make bevy_reflect delegate to Rust's field publicity rules, so only pub fields can be read/written to. this would be a major breaking change but it's unlikely this will cause significant breakage in practice.

I don't think we should tie mutability to pub. Doing so means that users can't have a field that they want to mutate through something like an editor or even their own workspace-local reflection logic without making it public to everyone.
I think if we're going to have a readonly custom attribute for the editor (we don't currently, but we almost certainly will), then it makes sense to allow users to embed that behavior into their reflected types.
So by having a readonly attribute, we provide a way for users to explicitly opt into this reflection-only behavior without affecting their "real" code. And they can have greater confidence that their invariants will be upheld, even if reflected (it's not 100% effective, of course, due to trickier tactics like FromReflect + Reflect::set).

I think if we're going to have a readonly custom attribute for the editor (we don't currently, but we almost certainly will), then it makes sense to allow users to embed that behavior into their reflected types.

what are the use cases where a field being modified by reflection becomes problematic, but being modified through downstream Rust code is ok?
if the only answer is "the editor", that's far enough downstream where that's what custom attributes are for!
i think it's best if our data model is a best-effort approximation of Rust's, and as long as Rust doesn't support readonly fields (although some progress is being made), not having readonly fields for reflection is, IMO, better than fragmenting our data model.

I don't think we should tie mutability to pub. Doing so means that users can't have a field that they want to mutate through something like an editor or even their own workspace-local reflection logic without making it public to everyone.

a user being able to mutate something through an editor
but not in their own code feels like a very error prone idea.
i strongly feel like reflection should generally be as conservative as Rust with what it exposes. i don't think non-pub fields (not a problem for enums) should be completely absent from reflection, e.g. they should be required when doing FromReflect and (de)serialisation. but they should not be directly accessible or modifiable.
i guess the clutch of my point is that annotating a type with Reflect does make all the fields public to everyone. it's easy to get a mutable reference to a field through, say Struct, downcast it, and do whatever you could if you'd just got that from the field directly. making a field pub isn't "dangerous" if it's already exposed via reflection.

what are the use cases where a field being modified by reflection becomes problematic, but being modified through downstream Rust code is ok?
if the only answer is "the editor", that's far enough downstream where that's what custom attributes are for!
i think it's best if our data model is a best-effort approximation of Rust's, and as long as Rust doesn't support readonly fields (although some progress is being made), not having readonly fields for reflection is, IMO, better than fragmenting our data model.

One of the issues with tying mutability to pub is that, unlike the Rust compiler, we don't know how public that pub really is. For example:
pub(crate) struct PrivateType {
    pub value: i32,
}

In this code, the value field is marked pub but it is definitely not accessible outside of the current crate. If we tie mutability to pub then value would still be mutable by downstream users via reflection, despite PrivateType not being directly accessible to them (e.g. using ReflectComponent, the editor, etc.).
If you did want value to be immutable during reflection, you'd need to remove the pub, which may affect your existing usages of PrivateType.
Of course, this is just an arbitrary example. We could find similar issues with readonly as well.

i guess the clutch of my point is that annotating a type with Reflect does make all the fields public to everyone. it's easy to get a mutable reference to a field through, say Struct, downcast it, and do whatever you could if you'd just got that from the field directly. making a field pub isn't "dangerous" if it's already exposed via reflection.

I think my main problem with it is that it forces the user to design their code around reflection rather than the other way around.
For example, if I prefer to only expose getter/setter methods for my types, then reflection is going to get in my way. I can't reflect my types without changing how I write my code (by making my fields pub). This is unfortunate, because I don't really have invariants to uphold—I just prefer my Rust code to look and feel a certain way.
Another example is that library authors have to choose between semver compatibility and reflection. As an author, I might keep my fields private so I can change them around without it being a breaking change, but still allow users to side-step this and modify them via reflection (and just warn them that doing so may break at any release). If my fields have to be pub, then I don't really have the option of doing this.
In both cases, reflection is more of an added bonus than it is a primary means of working with a type. Often, it can be used intentionally as a backdoor for users that really need it. So the fact that you can modify data through it doesn't necessarily mean you should. What you should will be determined by the Rust-based API itself.
So while I do think a dedicated readonly attribute could be useful, even if it isn't added, I (currently) don't believe we should tie reflection mutability to pub.

Should we split ReflectFieldError into mutable and immutable versions? I think I prefer having one error enum for these methods, but it does mean that the immutable methods will always have an "unreachable" pattern: the Readonly variant. It could make sense to split them up so the immutable methods don't have to deal with the variant, but I'm pretty sure many error types behave this way (io::Error, for example). So I don't think we should change it, but I'm open to opinions!

I prefer one error enum here: this doesn't seem so painful that adding another layer of nesting is worth it.

I agree with @soqb here. If I have a lib for example, and want to make something more easy to the end user to control, I wouldn't want to make possible footguns on fields that for example Shouldn't be changed manually. In that aspect, I would make this field not public. only pub(crate) maybe. But at the same time, we don't yet have a feature like this, so this problem exists in every way within Reflect now. But I think the problem here is the ergonomics: If none of the fields of a Struct is pub, I would have to set all of them to #[reflect(readonly)], when we can probably skip this step by making this field automatically readonly.
IMO, we should allow the user to bypass this pub thing if they want by setting #[reflect(readonly = false]], something like this maybe?
#[derive(Reflect)]
struct ImportantStruct {
    // This field will not be available
    should_not_change: i32,

    // This field will
    pub something_else: u32

    // What to do with this field though?
    pub(crate) what_to_do: bool
}

#[derive(Reflect)]
struct AnotherOne {
    // Even though this field is public, I don't want it to change via reflection for some reason
    #[reflect(readonly = true)]
    pub something: bool

    // I'm allowing this field to change, that's okay
    #[reflect(readonly = false)]
    another_something: bool

    // Even though this is pub to me, shouldn't be public via reflection, let's disable it
    #[reflect(readonly = false)]
    pub(crate) important_to_me: i32
}

So, we add this attribute, but let the users choose the behavior. And instead, we can just follow with rust convention for pub and field privacy.

There was some more recent debate on this over on Discord. There are those arguing for private-by-default (i.e. mutability matching Rust visibility) and those arguing for public-by-default (i.e. the current behavior).
I really like @pablo-lua's compromise where we can use the readonly attribute for configuration even in a private-by-default solution (though I'm still #TeamPublicByDefault). This might be something worth exploring.
However, I think overall this debate is mostly tangential to the changes made in this PR. It simply adds functionality on top of our current mutability behavior (public-by-default). If we want to change to private-by-default, that probably belongs in its own dedicated PR—both to focus the discussion and to separate out the massive breaking change.
So for now, I think we should continue evaluating this PR apart from that particular problem.

authors: MrGVSV alice-i-cecile pablo-lua soqb


text:
[DOC] Mention FPS in log_diagnostics example

Closes #2076

FPS, frame time, and frame count
Do you think FPS is enough to be found by all interested users, or should it be something like frames per second (FPS) as mentioned in #2076 ?

Do you think FPS is enough to be found by all interested users, or should it be something like frames per second (FPS) as mentioned in #2076 ?

Um now that I think of it, while most game devs (I assume) would know what FPS stands for, that doesn't mean everyone will.
I would agree that we should change FPS to frames per second (FPS)

CI seems to have found an unrelated issue

CI seems to have found an unrelated issue

should be fixed now, notify released a new version that fix their dependency

bors r+

authors: FlyingRatBull NathanSWard cart mockersf


text:
Separate gamepad state code from gamepad event code and other customizations

Earlier implementation of bevy_gilrs controls both the state and event part of gamepad input. In this PR the gamepad state part is moved to bevy_input. Now bevy_gilrs generates raw events in form of GamepadEvent in FIRST stage and then bevy_input reads those events in EVENT_UPDATE stage and update the gamepad states stored as Input<GamepadButton>, Axis<GamepadButton> and Axis<GamepadAxis>.

Gilrs uses same events(the events exposed in the API) to maintain gamepad state, so there is no way to query the state of connected gamepad during the connection event. This makes querying for default states of buttons and axis on connection event redundant. So this PR simplifies the connection event code.

Internally, gilrs' buttons can be classified into 2 types:

which takes continuous values between 0.0 and 1.0 (both inclusive) from platform code.
which takes discrete pressed/released event from platform code.

Both buttons can generate ButtonPressed, ButtonReleased and ButtonChange event in gilrs.
For buttons of first type, values from this function is used to generate ButtonPressed and ButtonRelease event internally in gilrs.
For buttons of second type, (pressed, released) is mapped to (1.0, 0.0) which generates ButtonChange event internally in gilrs.
So this PR emulates the button press/release from only ButtonChange event in bevy_input crate (ButtonPressed and ButtonReleased becomes redundant)

Resource GamepadProperty holds the data required for this button press/release emulation. The data is stored as ButtonProperty struct and can be changed anytime, which was not possible in earlier implementation as GilrsBuilder::set_axis_to_btn can be called only during initialization. Moreover, user can set default struct as well as specific struct for each GamepadButton as required. Default value of gilrs is used as default.

AxisProperty is used to store the deadzones and threshold for GamepadAxis in the same way as ButtonProperty. Arbitrary default value is used for deadzone and default value of gilrs is used for threshold.

ButtonAxisProperty is used to store the deadzones and threshold for GamepadButton that behave as axis in the same way as ButtonProperty. Arbitrary default value is used for deadzone and default value of gilrs is used for threshold.

gamepad_input example is updated to print axis values only on change.

gamepad_input_event example is added which uses the raw events (ButtonChange and AxisChange)

Parameter of Axis<T>::get and Axis<T>::remove is changed from &T to T to make is more analogous to Input<T> (separate commit, can be reverted)

I shall merge all to a single commit before merge

Looks good to me! I prefer XSettings over XSetting because in each case, its a "collection of configurable things", but I think I'll just merge this now and then follow up with a pr.

authors: cart simpuid


text:
only really notice effects on long press

only on the first time I tap do I notice effects on a short press. Every other time needs to be a long press to observe effects. any reason why?

Hi @hsavit1!
I'm having a hard time seeing this effect. Which version are you using and on which device?
I'm testing with v2.0.18 on an iPad 4th gen running iOS 8.3 and I cannot see this effect.

I'm testing with the same version, and on iOS 8.3. My button is constrained
to edges with auto layout and has a mapview as a sub view, if that helps.
On Thursday, May 21, 2015, Bence Feher notifications@github.com wrote:

Hi @hsavit1 https://github.com/hsavit1!
I'm having a hard time seeing this effect. Which version are you using and
on which device?
I'm testing with v2.0.18 on an iPad 4th gen running iOS 8.3 and I cannot
see this effect.
—
Reply to this email directly or view it on GitHub
https://github.com/bfeher/BFPaperButton/issues/16#issuecomment-104472272
.

--
Sent from Gmail Mobile

The circles fade in until either the animation duration is reached or the tap has ended. At which point they burst and fade out. The animation values continue where they left off, so if you tap lightly the circle doesn't fade in very much and begins to fade out from its current alpha value.
I am not yet able to reproduce a more noticeable circle on the first tap. Perhaps the mapview is delaying the touch or interacting with it in some way? Autolayout should have no effect on the circle animations.
You may want to try using BFPaperView instead if you plan on adding complex subviews. Though I'm not sure if that will solve your issue.

If you could upload a gif that would be helpful.

Hi @bfeher & @hsavit1 - Me too facing same problem...it requires long press to see the ripple effect...any solution found??

Hi @hardikamal  - Have you read my previous comments? This may be the expected behavior. If you are using a mapview or some kind of complex subview in the button, I suggest using BFPaperView.
If you still believe this to be a bug I would really like some more information as well as some kind of evidence so I can better understand what's going on.
Thanks :)

Hi @bfeher & @hsavit1....by disabling delay content touches on scrollview/uitableview/uicollectionview we get click effect on without long longpress...Thanks solved

Glad to hear that :)

authors: bfeher hardikamal hsavit1

repo: bfeher/BFPaperButton

license: mit

license_source: bigquery


text:
gitlab-ce: upgrade from 15.6.2 to 15.7.5

Changelog:
https://gitlab.com/gitlab-org/gitlab-foss/-/blob/v15.7.5/CHANGELOG.md

bors r+

repo: bfritz/homelab-apps

license: MIT


text:
input's value doesn't get updated?

Hi!
Does this line "Spectrum will handle setting the value as it changes, so you don't need to add a single extra line of JavaScript." mean that value of spectrum type input gets updated automatically?
I'm on Mac, Chrome 14 and this part doesn't work for me in your example — value still is "lightblue", no matter what color I choose.
Did I misunderstood something?

I'm seeing it change - it might be confusing because the markup is pretty printed above it?  That part won't change.  If you open up a console and uncheck the 'display:none;' on the original input type="spectrum", it should be changing.  Let me know if it isn't working!

authors: bgrins ql

repo: bgrins/spectrum


text:
Make example run on Exponent

Also fix the issue mentioned in https://github.com/bgryszko/react-native-circular-slider/pull/1
Soften dependency on react-native-svg as this lib doesn't explicitly depend on features in 4.4.1

If you'd rather not do this, no problem. Just submitting PR because I did this anyways.

That's great, thanks @brentvatne !

authors: bgryszko brentvatne

repo: bgryszko/react-native-circular-slider


text:
W = tanh(Wˆ ) * σ(Mˆ )

https://github.com/bharathgs/NALU/blob/16a4c9965ad371b48d086bfd780f0479ce311d98/nalu/core/nalu_cell.py#L22
Shouldn't W be implemented as below according to the paper ?:
W = tanh(Wˆ )  * σ(Mˆ )

@pushkarparanjpe thanks for pointing that, fixed it :slightly_smiling_face:

Sure :)

authors: bharathgs pushkarparanjpe

repo: bharathgs/NALU


text:
Add Bithumb Spot exchange

Pull request checklist

[x] Did you bump the project version?
[x] Did you add a description to the Pull Request?
[ ] Did you add new tests?
[x] Did you add reviewers?

Codecov Report
Attention: Patch coverage is 3.47826% with 111 lines in your changes are missing coverage. Please review.

Project coverage is 2.83%. Comparing base (7952cb0) to head (4515cf6).

Files
Patch %
Lines

src/Bithumb/Bithumb.jl
10.71%
25 Missing :warning:

src/Bithumb/Spot/API/Candle.jl
0.00%
18 Missing :warning:

src/Bithumb/Spot/API/OrderBook.jl
0.00%
16 Missing :warning:

src/Bithumb/Spot/API/Ticker.jl
0.00%
14 Missing :warning:

src/Bithumb/Utils.jl
0.00%
14 Missing :warning:

src/Bithumb/Errors.jl
0.00%
11 Missing :warning:

src/Bithumb/Spot/API/UserTransactionsLog.jl
0.00%
8 Missing :warning:

src/Bithumb/Spot/API/AssetStatus.jl
0.00%
5 Missing :warning:

Additional details and impacted files
@@            Coverage Diff            @@
##           master     #35      +/-   ##
=========================================
+ Coverage    2.77%   2.83%   +0.05%
=========================================
  Files          99     108       +9
  Lines        1296    1411     +115
=========================================
+ Hits           36      40       +4
- Misses       1260    1371     +111

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:blue_book: A preview of the documentation will be here soon

authors: artememelin codecov-commenter


text:
Problem with installation for antigen

I followed the instruction on wiki:
antigen theme bhilburn/powerlevel9k powerlevel9k
antigen apply

but antigen throws an error:
Script location could not be found! Maybe your POWERLEVEL9K_INSTALLATION_PATH is not correct?

I set an environment variable at the top of my .zshrc:
export POWERLEVEL9K_INSTALLATION_PATH=$HOME/.antigen/repos/https-COLON--SLASH--SLASH-github.com-SLASH-bhilburn-SLASH-powerlevel9k.git

then this error disappeared. However, the theme won't load automatically. I must load it by executing antigen theme bhilburn/powerlevel9k powerlevel9k manually.
my .zshrc configuration is
source $HOME/Playground/antigen/antigen.zsh

export POWERLEVEL9K_INSTALLATION_PATH=$HOME/.antigen/repos/https-COLON--SLASH--SLASH-github.com-SLASH-bhilburn-SLASH-powerlevel9k.git

# Load the oh-my-zsh's library.
antigen use oh-my-zsh

# Bundles from the default repo (robbyrussell's oh-my-zsh).
antigen bundle git
antigen bundle heroku
antigen bundle pip
antigen bundle lein
antigen bundle command-not-found

# Syntax highlighting bundle.
antigen bundle zsh-users/zsh-syntax-highlighting

# Load the theme.
export POWERLEVEL9K_INSTALLATION_PATH=$HOME/.antigen/repos/https-COLON--SLASH--SLASH-github.com-SLASH-bhilburn-SLASH-powerlevel9k.git
antigen theme bhilburn/powerlevel9k powerlevel9k

# Tell Antigen that you're done.
antigen apply

That's weird...I deleted .antigen dir and re-open zsh and everything goes well...I don't know why :(

Hah, well, not sure how to explain that, but glad you're all set, now :)

running into the same original error - this was after an antigen selfupdate / antigen update on all modules.
Deleted .antigen as noted above, and upon opening a new shell, I get this error:
Script location could not be found! Maybe your POWERLEVEL9K_INSTALLATION_PATH is not correct? (pwd now: ~/.antigen/bundles/bhilburn/powerlevel9k) Antigen: Failed to load theme.
My  .zshrc config reads:
`ZSH=$HOME/.oh-my-zsh
source $HOME/source/dot.hoagie/antigen/antigen.zsh
antigen use oh-my-zsh
antigen bundles <<EOBUNDLES
git
heroku
pip
python
command-not-found
tmux
unixorn/tumult.plugin.zsh
zsh-users/zsh-syntax-highlighting
trapd00r/zsh-syntax-highlighting-filetypes
zsh-users/zsh-history-substring-search
peterhurford/up.zsh
common-aliases
git-extras
git-flow
EOBUNDLES
antigen theme bhilburn/powerlevel9k powerlevel9k
#antigen theme tonyseek/oh-my-zsh-seeker-theme seeker
#antigen bundle nojhan/liquidprompt
antigen apply
`
Super odd, as until the most recent antigen selfupdate am at Antigen v1.2.1, had been using powerlevel9k for months without error.

What helped me.

In your .zshrc put

POWERLEVEL9K_INSTALLATION_PATH=$ANTIGEN_BUNDLES/bhilburn/powerlevel9k

Delete your antigen directory that is ~/.antigen (I used antigen from HomeBrew)
Restart your terminal (I'm using iTerm)

Your terminal should now reinstall all of antigen's packages again and powerline should be backup again.

@casoetan yeah it really works, but what makes me confused is that the wiki doesn't tell users to put this line in .zshrc...

Updated the wiki with this information.

Thanks for the help @casoetan ! I hope it will be unnecessary to manually set the installation path (see https://github.com/bhilburn/powerlevel9k/pull/482#issuecomment-295357081 ). That hopefully brings relief.
@mrtanuky yes, sorry about that. We can't follow every ZSH framework.. :/

TL;DR

Me shells are no longer perty!
Documentation as written failed to solve my issue
Solved by using the path $ANTIGEN_BUNDLES/bhilburn/powerlevel9k/powerlevel9k.zsh-theme, instead of the suggested $ANTIGEN_BUNDLES/bhilburn/powerlevel9k.zsh-theme, as the value of POWERLEVEL9K_INSTALLATION_PATH

Long Version
So, I figure some scheduled update happened and my shells are no longer ||D || ||\/|| ||D and I came here looking for a solution. Looks like antigen made some foundational updates that are causing some ripples.
Following the instructions with a "grain of salt", I delete .antigen contents, re-clone the repo back into .antigen, re-start iTerm, let antigen re-install all my bundles and ... this env var ANTIGEN_BUNDLES is never defined. Ever. No matter how times I restart iTerm.
Fail
antigen version === Antigen v2.0.2 (16f3fc2)
So, I decided to create the missing var in  ~/.zshenv: ANTIGEN_BUNDLES=$HOME/.antigen/bundles
Documentation states, set the var POWERLEVEL9K_INSTALLATION_PATH=$ANTIGEN_BUNDLES/bhilburn/powerlevel9k.zsh-theme
Fail
Set to the actual path of the antigen installed theme:
POWERLEVEL9K_INSTALLATION_PATH=$ANTIGEN_BUNDLES/bhilburn/powerlevel9k/powerlevel9k.zsh-theme
Success

Just the sunoterra's solution solved my problem. Thank you.

After the antigen init/.antigenrc introduction I factored out the configuration of powerlevel9k anyway:
In .zshrc:
# ...
source /opt/antigen/antigen.zsh

source $HOME/.antigen-theme-conf

antigen init .antigenrc
# ...

With this, this file .antigen-theme-conf becomes a good point as where to add the newly required variable:
# Theme config
# antigen theme bhilburn/powerlevel9k powerlevel9k

POWERLEVEL9K_INSTALLATION_PATH=$ANTIGEN_BUNDLES/bhilburn/powerlevel9k/powerlevel9k.zsh-theme

POWERLEVEL9K_MODE='nerdfont-fontconfig'
# POWERLEVEL9K_PROMPT_ON_NEWLINE=true

POWERLEVEL9K_TIME_FORMAT="%D{%H:%M:%S %d.%m.%y}"

# Std has become an ugly M or such
# POWERLEVEL9K_OK_ICON=$'\UF00C'
# POWERLEVEL9K_FAIL_ICON=$'\UF00D'

POWERLEVEL9K_VCS_GIT_ICON=$'\UF296'
# POWERLEVEL9K_VCS_TAG_ICON=$'\UF121'
# F1D3 is the general git icon

POWERLEVEL9K_MULTILINE_FIRST_PROMPT_PREFIX=""
POWERLEVEL9K_MULTILINE_SECOND_PROMPT_PREFIX="\UF120 "

POWERLEVEL9K_LEFT_PROMPT_ELEMENTS=(dir vcs)
POWERLEVEL9K_RIGHT_PROMPT_ELEMENTS=(status time)

Thanks for finding out @sunoterra

authors: bhilburn casoetan dritter hamhoagie hugotacito mrtanuky onaforeignshore sunoterra xasx


text:
[Bugfix] Ad hoc fix for no matches found

This ignores no matches found error for handling decomposed UTF-8 encoding for non-ASCII character handling in macOS, by applying nullglob when matching directories.
Although this is does not completely resolve the issue, it gracefully fails and simply show the full path for the directory with encoding problem—thus an ad hoc fix.
Fixes #1067

Thx for the fix. Before I merge this, could you try out #1082 ?
Your fix is only for the dir segment when truncating unique path, but not for the vcs segment. So both fixes are valid.

Merged. Thx @Zeta611 .
The PR I mentioned in my previous comment did not work. So I merged this one.

@dritter Great! b

Nice work, @Zeta611!

authors: Zeta611 bhilburn dritter


text:
Windows battery support

This ports over the changes by @ratijas from #887 onto a current next. Additionally I removed calling externals as much as possible and wrote tests for it.
@ratijas can you confirm this works for you as expected?

LGTM!
However my battery is dead now, so sadly I have no way to verify this on my own.

authors: dritter ratijas


text:
🛑 RefineAIR MQTT is down

In 3dd4464, RefineAIR MQTT (mqtt.refineair.it) was down:

HTTP code: 0
Response time: 0 ms

Resolved: RefineAIR MQTT is back up in c134524 after 9 minutes.

repo: biapar/uptime


text:
Consolidate docker and docker-compose

Description
Cleaning up the repo to consolidate docker packaging and docker-compose dev setup workflows and remove docker files un related to this repo
Issues This PR Fixes
Fixes #1960
Fixes partially #1895
How to QA
Follow the updated Contributing.md in this PR

Codecov Report

Merging #1965 into master will decrease coverage by 50.2%.
The diff coverage is 79.5%.

@@             Coverage Diff             @@
##           master    #1965       +/-   ##
===========================================
- Coverage   98.05%   47.85%   -50.21%
===========================================
  Files          60       70       +10
  Lines        3040     3354      +314
===========================================
- Hits         2981     1605     -1376
- Misses         59     1749     +1690

In CONTRIBUTING.md the "Step 2" section needs to be revised as well, since it's currently aimed at getting users set up to run everything as processes, rather than using Docker and Docker Compose, i.e.

Step 2 - Install some Dependencies
Install MongoDB, Tendermint, and all of BigchainDB Server's dependencies. The Quickstart page has some pointers. In fact, you could do everything in the Quickstart page short of installing BigchainDB with pip (since you will install from the source on GitHub), and you shouldn't run MongoDB or Tendermint yet.

The only dependencies they'll have now will be Docker and Docker Compose, unless I'm mistaken. You could move the links about how to install Docker and Docker Compose up into the "Step 2" section (out of "Step 6").

For people who really want to run everything as processes, maybe you could point them to the pkg/scripts/ directory?

@sbellem

Role of Dockerfile versus Dockerfile-dev
Added doc strings
Removal of rdb
Are we still supporting rethinkdb?
Purpose of bdb-base
Added doc string

@ttmc Addressed most of your comments and for multinode setup with docker-compose.network.yml and deployment as process using pkg/scripts I can create seperate PRs for that keep things incremental and manageable?

@shahbazn and I discussed, and we agreed to put this put PR on hold for now and we'll revisit it after the holidays.

I can create seperate PRs for that keep things incremental and manageable?

Sounds good.

I wrote this in an email thread, but it should really be shared here as well:
Shahbaz wanted to make using Docker Compose the standard way of doing development on BigchainDB Server. I figured that was fine so long as there are clear instructions for how to do that (including for new developers, i.e. in CONTRIBUTING.md).
Maybe we could document how to do development in a few different ways? Maybe:

by installing stuff with apt and pip, using virtualenvs, etc. (i.e. like the current CONTRIBUTING.md)
using Docker Compose
using Vagrant?

Maybe even other ways. I like the idea of making Docker Compose the default since it works cross-platform.

(I just approved this PR since I don't want my review to be a blocker while I'm away on holidays.)

Will be handled in separate PR.

authors: codecov-io sbellem shahbazn ttmc

repo: bigchaindb/bigchaindb


text:
Fix non deterministic test

@vrde fixed a small bug in one of my tests, thanks!

[Current coverage][cc-pull] is 89.87%

Merging [#441][cc-pull] into [master][cc-base-branch] will not change coverage

@@             master       #441   diff @@
==========================================
  Files            18         18
  Lines          1274       1274
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           1145       1145
  Misses          129        129
  Partials          0          0

[][cc-pull]

Powered by Codecov. Last updated by [fe136be...c7ed37e][cc-compare]
[cc-base-branch]: https://codecov.io/gh/bigchaindb/bigchaindb/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/bigchaindb/bigchaindb/compare/fe136bea9c6e1e3b2952d7e3e59a0e3963e2dd15...c7ed37e0a2b6af5e6aa31d233bc83ace3a19542d?src=pr
[cc-pull]: https://codecov.io/gh/bigchaindb/bigchaindb/pull/441?src=pr

authors: codecov-io rhsimplex


text:
Fix Max New Tokens in HF's Generation Config

HuggingFace's max_length configuration corresponds to the total length of the prompt and the generated output, while max_new_tokens corresponds to the length of generated output only.
Using args.max_length_generation to set max_new_tokens fixed runtime errors for me.  Using args.max_length_generation to set max_length lead to runtime errors because the total length of prompt+generation would exceed the intended value.

Thanks for fixing it > This is the message i am seeing as well in the logs when ran humaneval against llama2-7b-chat-hf model:
bigcode-evaluation-harness/bigcode_eval/utils.py:361: UserWarning: An error with the following message was thrown: Input length of input_ids is 1000, but max_length is set to 1000. This can lead to unexpected behavior. You should consider increasing max_length or, better yet, setting max_new_tokens.. Returning the input as the generation, for higher scores consider using a larger max_length
2024-07-23 11:50:32 EDT code_eval line: 74: [INFO] warnings.warn(f"An error with the following message was thrown: {e}. Returning the input as the generation, for higher scores consider using a larger max_length")

Thanks @kbmlcoding for approving. Still unable to merge the PR. Do we need another approval?
Cc @loubnabnl

authors: kbmlcoding mostafaelhoushi


text:
Clean up RDD method names

We've got a lot of methods in the *RDDFunctions classes whose names are adamSomething (e.g., adamSortReads or adamSAMSave. I'd like to eliminate the use of ADAM as a prefix, since it's somewhat redundant.

+1

Closed by https://github.com/bigdatagenomics/adam/commit/70eaa70835c11fb81445a22a7b1752d831c66bd3.

authors: fnothaft heuermh

repo: bigdatagenomics/adam


text:
Add approximate LSH approach for MinHash

Currently, our MinHashing scheme falls back to a LSH scheme for approximate MinHashing. This provides a reduction in data replication from n to b (where n is the number of elements and b is the number of buckets). However, more efficient approximate LSH schemes can achieve a further reduction. We should add a method like multiprobing:
Lv, Qin, et al. "Multi-probe LSH: efficient indexing for high-dimensional similarity search." Proceedings of the 33rd international conference on Very large data bases. VLDB Endowment, 2007.

Closing as WontFix, please feel free to reopen

repo: bigdatagenomics/utils


text:
Update README.md

Added information from contents of homology modelling slides to main readme file.

Can't seem to indent the bullet points more, @RMeli maybe one to fix if you can work it out.
Otherwise lgtm!

Not sure it's possible...

authors: IAlibay Maxim-93 RMeli

repo: bigginlab/WTcourse


text:
Adds OS X Support

Summary of Changes
This PR creates an OS X framework and testing target. Passing in a store URL to the constructSQLiteStack is preferable in most cases as passing nil will create the store at the root of ~/Documents on OS X.
Addresses
Resolves #64

:eyes: @jeremy-w

In a sandboxed OS X app, it'll just end up in the sandboxed Documents folder, won't it?

@jeremy-w looks like in a sandboxed app it landed at:
file:///Users/redwards/Library/Containers/com.bignerdranch.Mac-Example/Data/Documents/Sample.sqlite

:eyes: @

authors: jeremy-w rcedwards wolfbrain

repo: bignerdranch/CoreDataStack


text:
Footer not consistently unfixing

Hello,
First of thank you for such an exceptional plugin, I rate it very highly!
I am having an issue at the moment in regards to the unfixing, the site in question is http://www.hypemarketing.co.uk/
Upon scrolling it will trigger the footer at the bottom of the screen, then when you get to the bottom it snaps in correctly, but on any other page on the site this isn't occurring e.g. http://hypemarketing.co.uk/seo/ ?
Also on other pages (I am still working on) it snaps to the footer too early i.e. http://hypemarketing.co.uk/project/beacon-finance/ ?
For a bit more information this is a WordPress Site, and built on-top of the DIVI Framework from Elegant themes.
If you could please help me troubleshoot/ solve this issue it would be greatly appreciated. :)

My quick guess there is dynamic content on the other pages. Change the limit attribute to a function:
jQuery('#Sticky-Footer').scrollToFixed( {
    bottom: 0,
    limit: function() { return jQuery('#Sticky-Footer').offset().top; }
});

Hi bigspotteddog, thank you for your quick response, I have added the snippet and although now it seems to snap correctly it is flickering as you scroll up/ or down. URL: http://hypemarketing.co.uk/
Below is my js

Also sorry I have moved it over to a dev site: http://dev.hypemarketing.uk/

Looks like you solved it? I do not see a flicker on http://hypemarketing.co.uk/seo or http://dev.hypemarketing.uk/seo.

Hi,
Sorry no, I was trying to troubleshoot when you must have looked, check
now.
Kind regards,
On 20 June 2016 at 13:51, bigspotteddog notifications@github.com wrote:

Looks like you solved it? I do not see a flicker on
http://hypemarketing.co.uk/seo or http://dev.hypemarketing.uk/seo.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/bigspotteddog/ScrollToFixed/issues/215#issuecomment-227133059,
or mute the thread
https://github.com/notifications/unsubscribe/ATB5Ts1HLR9vybqjE-oP9clWIz9A3pFgks5qNoy4gaJpZM4I2ZWa
.

check the dev site.

Comment out the .scroll listeners to rule them out as a possible cause. If it does not flicker when they are no longer involved, they are the culprit; otherwise, there is something going on with the layout and possibly other events on the page.

Hi, thank you for your support so far, sadly I tried commenting them out and still occurring. Do you think there is anyway of resolving this?

Yes, it is solvable. It is a matter of finding what is doing it. There is something dynamic going on with the page that is causing the flicker. Eliminating all events to get to a properly functioning footer, then bringing them back one-by-one will tell you which event is causing the issue.

I have to say you have lost me there, I am not to clear on what are the events etc.
Could I perhaps give you temp access?

The basic gist is, the footer works on the typical web page and even on the index page on your site. There is something on the subsequent pages that is causing the footer to flicker. I am assuming some dynamic event, but it could be something else in the layout.
Unfortunately, I do not have the time to debug what is going on with the pages that is causing the flicker. I can support you by answering questions you might have.
I think the approach should be to trim down the page to get to back to basics, get the footer working as desired, then build back up. Along the way you will discover what on the page is causing the flicker. You can even start with the index page if it is working as you want it to.

repo: bigspotteddog/ScrollToFixed


text:
Added arriba to somatic_gene_fusion_calling step

Addressing issue #210

STAR is indeed part of the ngs_mapping step. However, it is used with quite different settings in the two steps: once with ENCODE settings and ideally generating gene counts and mapping on transcriptome, and the other with different value of parameters for mapping reads spanning introns, for example, and an output of chimeric reads.
When STAR is run during the somatic_gene_fusion_calling step, no bam file is created, the mapped reads are passed to arriba using a pipe.

Comment
It looks a little bit convoluted to be honest. Possible downside:

Hard to debug and to rerun as you're not saving the intermediate results from star.
Hard to maintain as the tools are logically different (mapping vs. gene fusion) but they are in the same place.
Inefficient way of allocating resource as you need to set it for the higher consuming portion (star).
...

Suggestion
Logically split this into two different parts: 'mapping' and 'gene fusion'.
Mapping Steps:

Create new step/class Star<SOMETHING>FusionStepPart (inherits from StarStepPart) in the ngs_mapping workflow. Include a new entry in the DEFAULT_CONFIG.
Move current star wrapper code to snappy_wrappers/wrappers/star/<run_default_?> (long standing TODO).
Adjust snappy_pipeline/workflows/ngs_mapping/Snakefile to star new path - only place it is used.
Move star part of your wrapper to snappy_wrappers/wrappers/star/<something_else>.

Gene Fusion Steps:

Change ArribaStepPart.get_input_files() to extract results from parent.sub_workflows["ngs_mapping"]

...great opportunity to try our end2end test ;)

I am concerned that moving the star part to ngs_mapping would conflict with the current alignment with star: how to differentiate the star run that is used in gene_expression_quantification, and the star run which is used in somatic_gene_fusion_calling? But perhaps I misunderstood your plan...
If you think that piping the output of star into arriba is not a good idea, then I would rather split run into mapping and calling.
If you want to enforce the fact that each step produces the same output, regardless of the tool, then I would remove star from the ngs_mapping step, and include it into the gene_expression_quantification step. This is because I would like to have star to eventually produce gene-based expression counts & mapping on the transcriptome, besides the mapping on the genome.
Also, some steps might not be suited for the unification of output. For example, QC steps could have several tools producing quite different output, all valid.

repo: bihealth/snappy-pipeline


text:
[Not a Bug] Just wanted to share how to register all commands & subcommands as 'singleton'

Hello!
I was not sure where to share this code snippet, I figured it was to small for a pull request, however, i do think that it would be helpful to add to the GREAT library CommandDotNet, or at least have in the wiki.
This command below uses Microsoft.Extensions.DependencyInjection and registers all commands (and subcommands) as singletons.
This will not work if you would like to use interfaces.  If you want to use interfaces, I advise you to check out Scrutor which is a great library for scanning assemblies for dependency injection
Docs for Microsoft.Extensions.DependencyInjection

// Register all commands and sub commands here, then inject the ServiceProvider in the AppRunner as seen Docs for Microsoft.Extensions.DependencyInjectio above

private static void RegisterAllCommands(this IServiceCollection services)
    {
        var commandClasses = from assembly in AppDomain.CurrentDomain.GetAssemblies() from type in assembly.GetTypes() where type.IsDefined(typeof(CommandAttribute)) select type;

        foreach (var commandClass in commandClasses)
        {
            services.AddSingleton(commandClass);

          // This code registers NESTED subcommands. This can be removed if you do not have nested subcommands within your parent command classes
            foreach (var pi in commandClass.GetProperties()
                         .Where(pi => Attribute.IsDefined(pi, typeof(SubcommandAttribute))))
            {
                var subCommandClass = pi.PropertyType;
                services.AddSingleton(subCommandClass);
            }
        }

I hope someone will find this helpful!
Thanks for the very advanced and helpful library CommandDotNet! I hope to contribute some Pull Requests in the future as I build more tools

Edit:
This will only work if for nested subcommands.
If you do not use nested subcommands, remove the code that registers subcommands

Hi @jeffward01,
Thanks for the compliments and for contributing to the community.  Glad you're finding the library helpful.
We have an example documented here at https://commanddotnet.bilal-fazlani.com/otherfeatures/dependency-injection/#registering-all-command-classes.
private static void RegisterSimpleInjector(AppRunner appRunner)
{
    var container = new SimpleInjector.Container();
    foreach(Type type in appRunner.GetCommandClassTypes())
    {
        container.Register(type);
    }
    appRunner.UseSimpleInjector(container);
}

This approach has the benefit of only registering all and only the commands that can be surfaced by the app.  So, it won't matter what assemblies to scan and it won't include commands that are not yet linked as subcommands, etc.
In an effort to improve discoverability of this example, is there something we could have done to make it easier to find?
Cheers,
Drew

repo: bilal-fazlani/commanddotnet


text:
Signature error on margin query

Getting error on some margin order queries.
{
    "code": -1022,
    "msg": "Signature for this request is not valid."
}

Please make sure you have checked with this:
https://github.com/binance-exchange/binance-api-postman#error-signature-for-this-request-is-not-valid
Otherwise please paste your request raw, hide the signature for your saftely.

repo: binance-exchange/binance-api-postman


text:
Removed from NPM because of malicious code

From https://www.npmjs.com/package/@binance/connector :

Security holding package
This package contained malicious code and was removed from the registry by the npm security team. A placeholder was published to ensure users are not affected in the future.
Please refer to www.npmjs.com/advisories?search=%40binance%2Fconnector for more information.

Reading "malicious code" about the company's official package isn't a great vote of confidence about any code/sdk in Binance org

I am wondering what malicious code? 🤔  I can not find and further explains at http://www.npmjs.com/advisories?search=%40binance%2Fconnector

I am wondering what malicious code? 🤔 I can not find and further explains at http://www.npmjs.com/advisories?search=%40binance%2Fconnector.
Until is resolved, qfix is to put in package json reference to this repo "@binance/connector": "git+https://github.com/binance/binance-connector-node.git",

Wondering what the malicious code is too. Quite concerned. I rely on this library heavily.

Wondering what the malicious code is too. Quite concerned. I rely on this library heavily.

We are investigating this issue.
This library is open-sourced from the first version, everyone can review and see the whole source code.
The library only has 2 dependencies:

"axios": "^0.21.4",
"ws": "^7.5.0"

and a few for development.
Any updates we have will be provided.

While waiting for feedback from NPM, we are not able to find anywhere that can give evidence of "malicious code" in this library.

No vulnerability advisory from https://github.com/advisories?query=binance related to this library.
We did some research, not able to target this library in the malicious npm package list from recent reports e.g:

https://jfrog.com/blog/large-scale-npm-attack-targets-azure-developers-with-malicious-packages/
https://jfrog.com/blog/malware-civil-war-malicious-npm-packages-targeting-malware-authors/

Please review the code and install by
"@binance/connector": "git+https://github.com/binance/binance-connector-node.git"

or
npm install "@binance/connector" git+https://github.com/binance/binance-connector-node.git

receiving this error when trying to install:
npm ERR! code EINTEGRITY
npm ERR! sha512-gI5Sl30tmhXsqkNvopFydP7ASc4c2cLfGNQrVKN3X90ADFWFsPEsotm/8JHSUJQKUSDTwowAHtcJPeyVhtKv0TQ== integrity checksum failed when using sha512: wanted sha512-gI5Sl30tmhXsqkNvopFydP7ASc4c2cLfGNQrVKN3X90ADFWFsPEsotm/8JHSUJQKUSDTwowAHtcJPeyVhtKv0TQ== but got sha512-gI5Sl30tmhXsqkNvopFydP7ASc4c2cLfGNQrVKN3X90ADFWFsPEsotm/8JHSUJQKTHbwowAHtcJPeyVhtKv0TQ==. (110735 bytes)

what's your node, npm version?
and which OS are you in?

maybe you can try to remove the package-lock.json file and install again.

Close this ticket, please open a new one if seeing any issue.
Thanks for your support.

repo: binance/binance-connector-node


text:
can't dump counter to file: ./data\scheduler.1h

Windows system:
"pyspider" is ok, but "pyspider -c config.json" has error.

C:\Users\hongyaoli\Desktop\pyspider>pyspider -c config.json
[I 150206 09:48:46 processor:156] processor starting...
[I 150206 09:48:46 result_worker:49] result_worker starting...
[I 150206 09:48:47 tornado_fetcher:387] fetcher starting...
[I 150206 09:48:47 scheduler:395] loading projects
[I 150206 09:48:47 app:64] webui running on http://0.0.0.0:5000/
[E 150206 09:48:47 counter:330] can't dump counter to file: ./data\scheduler.1h
[E 150206 09:48:47 counter:330] can't dump counter to file: ./data\scheduler.1d
[E 150206 09:48:47 counter:330] can't dump counter to file: ./data\scheduler.all

C:\Users\hongyaoli\Desktop\pyspider>pyspider
[I 150206 09:47:46 result_worker:49] result_worker starting...
[I 150206 09:47:46 processor:156] processor starting...
[I 150206 09:47:47 scheduler:395] loading projects
[I 150206 09:47:47 tornado_fetcher:387] fetcher starting...
[I 150206 09:47:47 app:64] webui running on http://0.0.0.0:5000/

There is the problem after I change system to centos6.5.
[root@lhy mypyspider]# pyspider -c config.json
[I 150206 10:18:58 result_worker:49] result_worker starting...
[I 150206 10:18:58 scheduler:395] loading projects
[I 150206 10:18:59 tornado_fetcher:387] fetcher starting...
[D 150206 10:18:59 scheduler:83] project: 11 updated.
[E 150206 10:18:59 counter:330] can't dump counter to file: ./data/scheduler.1h
[E 150206 10:18:59 counter:330] can't dump counter to file: ./data/scheduler.1d
[E 150206 10:18:59 counter:330] can't dump counter to file: ./data/scheduler.all

create a folder named data

There is the same problem.
How to config the directory ? @binux

authors: binux eaglewu lhyfree

repo: binux/pyspider


text:
Feature Request: Message formatting (Markdown, or otherwise)

The ability to format messages. Like bold, italics and so on. Here for example is the discord formatting guide.

Bravo for being the first 🥇 to actually open a ticket for this. About 50 people have asked, but nobody created a ticket. ;-)

Correct

What would be the realistic steps to implement such an idea? I don't have any experience with Go, but am proficient in C#. I could try to set something up to help with the development of this feature.

This would be 90% Android, 10% server; probably just pulling in a markdown library in Android, and then somehow carrying the "content-type" through the message to the client; could potentially even use the "encoding" field for that.

I'm working on this now. I will be using the markwon library even though it has not been updated in 2 years :grimacing:

Design proposal
Right now, I'm thinking:

Add a content_type field to the message, which is text/plain by default, and can now also be text/markdown.
The content type can be passed via the Content-Type: text/markdown header, or via X-Markdown: yes or Markdown: yes or md: yes
The Android app by default will allow parsing markdown, but will have an option to disable embedding of external images:

[ ] Allow embedding markdown images
[x] Do not allow embedding markdown images

Thoughts? @wunter8 maybe. :grimacing:

Looks good to me!
I am surprised this is being added to Android before the web app, but it'll be very nice to have!

The Android app by default will allow parsing markdown, but will have an option to disable embedding of external images:

Will you be able to disable parsing markdown entirely? Or just disable automatic download of images in markdown? Will this be per subscription?

Will you be able to disable parsing markdown entirely? Or just disable automatic download of images in markdown? Will this be per subscription?

Might as well also allow disabling it entirely. And yes, probably global and per-subscription, just like the other options.

@nimbleghost I know you're looking for your next challenge: Wanna do this one, the web app side? :grimacing: I have started the Android side a while back, before you came along and side-tracked me hard hehe.
There is a markdown branch (with minimal changes so far), but no changes in the web app, or any persistence in the message cache.

Thanks to @nihalgonsalves's work the server and web app side of Markdown support is now merged to main. The ticket will remain open for the Android portion of it.

Hey,
love the project and its progress!
But for me the markdown does not work on any instance (public / selfhosted).
Should it already be available?
curl -d "Look ma, **bold text**, *italics*, ..." -H "Markdown: yes" ntfy.sh/rAU8FLX2R9NiXZRf

In case it matters: I use Brave, a chromium based browser.
Version 1.56.11 Chromium: 115.0.5790.102 (Official Build) (64-bit)

It's not released yet.

Thank you for confirming.
I was not sure because its documented but the issue is still open.
Love what you have created!
Its impressive.

Markdown is now obviously live!
Looks and works great! 😍
(and also does the embedded picture!)
LOVE IT!

Are there any plans to implement this in the Android app as well?
I spent 2 hours figuring out why markdown formatting did not work for me, until I found this issue :(

Plans? Yes. I believe there is a work-on-progress branch that was started even. Timeline for estimated completion? Not yet

there any plans to implement this in the Android app as well?
I spent 2 hours figuring out why markdown formatting did not work for me, until I found this issue :(

seems the Android app does not yet support Markdown...

I have recently stumbled upon the Markdown functionality, and I already started using it for viewing in the webapp.
However I noticed that it does not support tables. The syntax doc page you refer to in your docs does not mention the common table syntax either.
Could we please also have table support?
I wanted to use it to display key-value pairs which are coming from a structured logging system of a tool I have been making.

is there any plan to support markdown in the ios app by any chance?

is there any plan to support markdown in the ios app by any chance?

We'd like to add it to iOS, but I wouldn't expect it anytime soon. We don't have any iOS devs right now, so progress is extremely slow.
However, the PWA on iOS already supports Markdown, so that's probably your best option in the meantime.

repo: binwiederhier/ntfy


text:
WIP: Attachments

This is for #25

Codecov Report

Merging #82 (eb5b86f) into main (09515f2) will decrease coverage by 0.98%.
The diff coverage is 45.66%.

@@            Coverage Diff             @@
##             main      #82      +/-   ##
==========================================
- Coverage   61.43%   60.44%   -0.99%
==========================================
  Files          20       22       +2
  Lines        1636     1757     +121
==========================================
+ Hits         1005     1062      +57
- Misses        486      544      +58
- Partials      145      151       +6

Impacted Files
Coverage Δ

cmd/serve.go
0.00% <0.00%> (ø)

server/message.go
100.00% <ø> (ø)

server/server.go
51.72% <14.51%> (-4.79%)
:arrow_down:

util/peak.go
60.71% <60.71%> (ø)

util/limit.go
85.36% <88.23%> (+18.69%)
:arrow_up:

server/config.go
100.00% <100.00%> (ø)

util/content_type_writer.go
100.00% <100.00%> (ø)

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 09515f2...eb5b86f. Read the comment docs.

authors: binwiederhier codecov-commenter


text:
CI: checklist.py verifies future imports in .py files

@ebolyen and I pair-programmed this.

@wasade I addressed your comment, thanks for reviewing! This is ready for merge.

:+1:

authors: jairideout wasade

repo: biocore/scikit-bio


text:
Format for spike-in sequences

Hi
I am trying to include spike-in sequences for small RNA analysis. The libraries were made using the Qiaseq UMI method. I included the spike-in sequences as a fasta file or as a csv but both ended with errors. The same fastq files run fine with out the spike-in option enables. What is the format in which the spike-in sequences should be specified?
thanks

please provide a jobID of your failed attempt, example input files and example spike-in files.

authors: bioinfoUGR kartikshankarcu

repo: bioinfoUGR/sRNAtoolbox