text:
STATUS_STACK_BUFFER_OVERRUN return code when running with dynamic linking using rust-lld on Windows 11

Bevy version
0.5 and main ( 07ed1d053e7946a116ce3eef273fc93dd246f49d )
Operating system & version
Win 11 (day1 release - 21H2)
What you did
Running cargo run a minimal hello.world bevy app with dynamic linking using rust-lld on Win11.
use bevy::prelude::*;

fn main() {
    App::build()
        .add_system(hello_world.system())
        .run();
}

fn hello_world() {
    println!("hello world!");
}

config.toml
[target.x86_64-pc-windows-msvc]
linker = "rust-lld.exe"
# rustflags = ["-Zshare-generics=n", "-Ccontrol-flow-guard=nochecks"]
rustflags = ["-Zshare-generics=n"]

What you expected to happen
The app runs with dynamic linking
What actually happened
The process ends immediately with
PS C:\Projects\GameDev\bevy\dynamic_test> cargo run
   Compiling dynamic_test v0.1.0 (C:\Projects\GameDev\bevy\dynamic_test)
    Finished dev [optimized + debuginfo] target(s) in 1.32s
     Running `target\debug\dynamic_test.exe`
error: process didn't exit successfully: `target\debug\dynamic_test.exe` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)

Additional information
Either not using or rust-lld works.
This compiler flag seems that it could be related, but adding -Ccontrol-flow-guard=nochecks to config.toml did not help.
Also possibly relevant:
MS Docs on the MSVC flag /GS
MS Docs on Control Flow Guard

When compiling with features = ["dynamic"] on Windows 11 and running the debugger on the application revealed these errors:
The code execution cannot proceed because bevy_dylib-d25f65632eac054f.dll was not found.
Reinstalling the program may fix this problem.

The code execution cannot proceed because std-0f7e1853181d29c2.dll was not found.
Reinstalling the program may fix this problem.

You will either need to add target/debug/deps and the output of rustc --print target-libdir to your PATH variable or copy bevy_dylib-d25f65632eac054f.dll and std-0f7e1853181d29c2.dll from the aformentioned directories to target/debug next to the executable. Otherwise Windows doesn't know where to find them. When you use cargo run adds then to the PATH for you, but this doesn't work if you run it without going through cargon

@bjorn3 now, I don't get errors of missing dependencies anymore. But my executable still crashes with an exception in the middle of some disassembled code.
Thanks for your efforts, though.

If anyone comes across this later, I am running on the nightly toolchain and am able to build and run with the dynamic feature enabled by only dropping the following into my .cargo\config.toml:
[target.x86_64-pc-windows-msvc]
rustflags = ["-Zshare-generics=n"]

It still persists with 0.7. Everything runs perfectly without dynamic flag and if you add it immediately throws STATUS_STACK_BUFFER_OVERRUN.

I made a clean Windows 10 install and everything worked fine following the official bevy tutorial, but after upgrading to Windows 11, I got the STATUS_STACK_BUFFER_OVERRUN error. It only works now if I don't use dynamic flag.

I just

created a new binary crate
added bevy 0.7.0 with features=['dynamic]'
copied over .cargo/config from Bevy main .cargo/config_fast_builds
copied over a rust-toolchain.toml to select nightly
cargo run and cargo run --release

This with
> rustup show
Default host: x86_64-pc-windows-msvc
rustup home:  C:\Users\....\.rustup

installed toolchains
--------------------

stable-x86_64-pc-windows-msvc (default)
nightly-x86_64-pc-windows-msvc

installed targets for active toolchain
--------------------------------------

aarch64-linux-android
wasm32-unknown-unknown
x86_64-pc-windows-msvc

active toolchain
----------------

nightly-x86_64-pc-windows-msvc (overridden by 'C:\Users\...\rust-toolchain.toml')
rustc 1.64.0-nightly (9a7b7d5e5 2022-07-19)

I am also able to successfully run cargo run --example game_menu --features=dynamic with both v0.7.0 and main.
A "complex" example (a simple tech demo that follows game_menu but adds some 3d objects moved with leafwing-input-manager gets the usual 0xc0000409, STATUS_STACK_BUFFER_OVERRUN... 🤔

I tried to do what @aka-bash0r did and copied the required DLLs around (I copied the debug version of bevy_dylib-.dll from my directory and the Rust std library DLL from ~/.rustup/toolchains/nightly-x86_64-pc-windows-msvc/lib/rustlib/x86_64-pc-windows-msvc/lib/std-8a6b5a658b168ce9.dll (nightly from6dbae3ad1 2022-07-25).
After copying the 2 DLLs to C:\Windows\System32, running the exe from the command line doesn't crash but  it exits without doing anything.
Opening it in Visual Studio 2022 CE, it stops in some C/C++ glue (?) that, from what I've understood (... but I might be wrong) loads the instance of bevy_dylib.dll, as possibly described by the stack call window entry:
bevy_dylib-b4a908a5e3f80433.dll!dllmain_dispatch(HINSTANCE__ * const instance, const unsigned long reason, void * const reserved) Line 281
	at d:\a01\_work\43\s\src\vctools\crt\vcstartup\src\startup\dll_dllmain.cpp(281)

After that (point 0) there are 2 other calls on the stack, without symbols: it calls into XInput.dll (that should be DirectX's DirectInput implementation) for 2 stack frames, then crashes:

call to bevy_dylib-b4a908a5e3f80433.dll!dllmain_dispatch
call to XInput1_4.dll!DllMain()
call to XInput1_4.dll!RegisterUtcEventProvider(void)  that then crashes.

Checking the assembly code since there aren't debug symbol available from Microsoft's sources, the crash happens after a je (jump equal) to another point in this RegisterUtcEventProvider function: since it fails, load a 5 in ecx then executes an int 29h, that is our friend __fastfail that, called with 5, means FAST_FAIL_INVALID_ARG (from winnt.h from what I was able to find online).
The tests before the je are, if anybody can understand this better than me:
00007FF87E7F7A3C  push        rbx
00007FF87E7F7A3E  sub         rsp,40h
00007FF87E7F7A42  mov         rax,qword ptr [__security_cookie (07FF87E7FC068h)]
00007FF87E7F7A49  xor         rax,rsp
00007FF87E7F7A4C  mov         qword ptr [rsp+30h],rax
00007FF87E7F7A51  xor         edx,edx
00007FF87E7F7A53  lea         rcx,[g_VidPids (07FF87E7FC650h)]
00007FF87E7F7A5A  lea         r8d,[rdx+40h]
00007FF87E7F7A5E  call        memset (07FF87E7F82A9h)
00007FF87E7F7A63  cmp         qword ptr [WPP_GLOBAL_Control+28h (07FF87E7FC038h)],0
00007FF87E7F7A6B  mov         rax,qword ptr [WPP_GLOBAL_Control+10h (07FF87E7FC020h)]
00007FF87E7F7A72  movups      xmm0,xmmword ptr [rax-10h]
00007FF87E7F7A76  movdqu      xmmword ptr [rsp+20h],xmm0
00007FF87E7F7A7C  je          RegisterUtcEventProvider+49h (07FF87E7F7A85h)
00007FF87E7F7A7E  mov         ecx,5
00007FF87E7F7A83  int         29h

The debugger's output windows shows (as could be expected, given the int 29h call with 5): Unhandled exception at 0x00007FF87E7F7A83 (XInput1_4.dll) in fftf.exe: An invalid parameter was passed to a function that considers invalid parameters fatal.
HOWEVER: this is at least a bit different than what happens when run with cargo, since without debugger I don't get the exception printed out, so the reason might be different (some other configuration I'd need to perform manually).
QUESTION: where can I read how a cargo run sets up the execution environment for a Windows executable? I wasn't able to find it with a quick search.
IDEAS: can we try to disable XInput somehow? Check if there are newer crates/bugs filed in... gilrs? gilrs-core? It might also be in other types of input however (touch?) or unrelated functions inside the DLL (from https://docs.rs/rusty-xinput/1.2.0/src/rusty_xinput/lib.rs.html we can see it has functions like XInputGetBatteryInformationFunc or XInputGetAudioDeviceIdsFunc ...)

Knowing more details about what was the problem, I tried to search for people with similar issues on Google and...
I first found a post on the official Visual Studio support forum from somebody that had the exact same problem, crash in XInput1_4.dll when compiling an old project using clang-cl under Windows 11. See "Clang-cl tool chain results in dll loading issues for Xinput.lib".
The interesting part of that post is that apparently defining a function called DllMain somewhere in your own library will avoid the crash (probably by overshadowing the DllMain function inside XInput1_4.dll?). Microsoft recognized the problem but blamed it on "not Visual Studio".
Then I continued searching for people having trouble with XInput1_4.dll and I didn't find much other than people recommending to download it from fishy websites and copy it in Windows\System32... HOWEVER, one of the posts, about Chivalry 2, was a bit different: it recommended renaming XInput1_3.dll to XInput1_4.dll and that, if you did have an XInput1_4.dll and the game still didn't work, you could simply delete/rename the file and copy the 1_3 version with the same name as the 1_4 version. I tried and guess what?
Program using the dynamic feature are now working! 🥳
The XInput1_4.dll file was NOT locked on my system, meaning that none of the programs normally running in my system was using it (so all the bunch of crap from Asus to manage the strange hardware is ok). Steam and Epic clients are ok. After renaming the files, everything is still Ok, including Unreal 5 and Blender and a few of the games I was able to try. Unfortunately they're a bit old so they might use older versions of XInput anyway.
The 2 only modern games I have installed (Elite Dangerous and Genshin Impact) want me to download multiple gigabytes of updates so I'm not able to test them before probably a week or more :-P
In case you find programs or games that crash after you replace the file, it should be possible to simply restore the real XInput1_4.dll when you need to run it (and copying the XInput1_3.dll over it when you need to develop with Bevy using dynamic).
Now I'm finally able to compile a small change in < 4 seconds instead of 90+ and this will definitely help me in learning Bevy and experimenting with my game learning project 😄

What a great find!
I can confirm the problem is indeed with gilrs since it links to Xinput1_4.dll and for some unknown reason, when linking XInput1_4.dll using rust-lld the program crashes when calling DllMain of XInput1_4.dll.

XINPUT1_4.DLL is listed as dependency of BEVY_DYLIB.DLL
So if one can also disable bevy/gilrs (if GamePads isn't being used) and bevy_dylib.dll won't load XInput1_4.dll anymore:

No more XINPUT1_4.DLL
Sadly I wasn't to find which crate is requiring XInput1_4.dll to be loaded, since rusty-xinput loads it dynamically. so it must be somewhere else.

The winapi crate depends on XInput1_4.dll if the xinput feature is enabled. According to cargo tree --target x86_64-pc-windows-msvc -e features | grep -C5 xinput only gilrs-core and it's dependency rusty-xinput enable this feature.
https://github.com/retep998/winapi-rs/blob/2f76bdea3a79817ccfab496fbd1786d5a697387b/x86_64/def/xinput.def
    │               ├── gilrs-core feature "default"
    │               │   └── gilrs-core v0.4.1
    │               │       ├── uuid feature "default" (*)
    │               │       ├── log feature "default" (*)
    │               │       ├── winapi feature "default" (*)
    │               │       ├── winapi feature "xinput"
    │               │       │   └── winapi v0.3.9
    │               │       └── rusty-xinput feature "default"
    │               │           └── rusty-xinput v1.2.0
    │               │               ├── log v0.4.16 (*)
    │               │               ├── lazy_static feature "default" (*)
    │               │               ├── winapi feature "default" (*)
    │               │               ├── winapi feature "libloaderapi" (*)
    │               │               ├── winapi feature "winerror" (*)
    │               │               └── winapi feature "xinput" (*)
    │               └── vec_map feature "default"
    │                   └── vec_map v0.8.2
    ├── bevy_gltf feature "default"
    │   └── bevy_gltf v0.9.0-dev (/home/bjorn/Projects/bevy/crates/bevy_gltf)
    │       ├── anyhow feature "default" (*)

If anyone comes across this later, I am running on the nightly toolchain and am able to build and run with the dynamic feature enabled by only dropping the following into my .cargo\config.toml:
[target.x86_64-pc-windows-msvc]
rustflags = ["-Zshare-generics=n"]

Dynamic by itself was never an issue for me, only coupled with the lld linker.

Same, first works:
[target.x86_64-pc-windows-msvc]
rustflags = ["-Zshare-generics=n"]

second, fails:
[target.x86_64-pc-windows-msvc]
linker = "rust-lld.exe"
rustflags = ["-Zshare-generics=n"]

What are the benefits of lld though❓

Lld is much faster than most linkers.

Also clang-lld doesn't choke if you have more than 65535 symbols (something that happens easily with Rust, apparently) like Microsoft's linker does, see #1110

I was able to test disabling gilrs and it works for me too (best part is that gilrs at least in this W11 system is unable to detect a controller that works with both Steam Big Screen and the Web Controller APIs in Chrome).
Excluding a default feature could be a bit less annoying to configure, but well, you do it only once.
The "funny Windows thing of today" is that both Steam and the Nvidia share assistant decided they now need to use XInput1_4.dll so I had to kill a few things to copy back the real DLL file in its place. Thanks SysInternals for Process Explorer.

@alice-i-cecile do you think it's worth adding a warning on Bevy Book - Setup about using bevy_gilrs and rust-lld on Windows 11?
It seems disabling bevy_gilrs really enable fast compile times on Windows 11 (at least, as fast as it can go), so either disable bevy_gilrs feature or if it's needed, disable rust-lld.

I'm reluctant to encourage that, especially for beginner users. However this investigation is incredibly valuable; we should continue reducing the problem and attempt to fix it upstream in gilrs.

I made a test project, but I don't know where to open issue. Since this is related to rust-lld, should I open on rust-lang/rust?

Yes please, upstream for the compiler team is the place for this. Make sure to link this thread.
That's a great minimal example, thanks a ton.

Based on @RobertoMaurizzi's findings that xInput1_3.dll can be successfuly used in place of 1.4 version, I've managed to work around this issue without having to edit your system files, or otherwise influece any other program:

copy your system xinput 1.3 (from e.g. C:\Windows\system32\xinput1_3.dll)
go to your build directory (your_game/target/debug or release) that contain your built game exe file
paste the dll (1.3 version) there and RENAME it to Xinput1_4.dll

The drawback of this is you will need to repeat this process any time you run cargo clean or remove your target directory. If this is an issue to you, feel free to automate it in build.rs.
This works, because windows DLL loader searches for DLLs in the executable directory first by default. That way you can effectively replace any system DLL that a program tries to load.
Fun fact: this is often used various game mod loaders in order to hook into the game at startup without having to patch any executable file. One way of doing it is to place fake system DLL in your game directory (often xinput, thanks to it having small api surface), that passes all real function calls to the real system DLL, but additionally injects actual mod loader DLL to the game process by calling LoadLibrary inside DLLMain.

According to
https://learn.microsoft.com/en-us/gaming/gdk/_content/gc/input/porting/input-porting-xinput#differences-between-xinput-and-xinputongameinput Xinput is considered legacy, maybe we just need to get upstream gilrs to use the newer "windows gaming input" by default? Would enable broader gamepad support our of the box with windows too. (Currently only Xbox controllers work out of the box with bevy on windows)

Opened an issue on gilrs https://gitlab.com/gilrs-project/gilrs/-/issues/127 assuming they are open to it, and no one beats me to it, I should have time to work on it Friday.

That would be massively appreciated; better gamepad support on Windows + dynamic linking on Windows would both be incredible.

Poking around on the GitLab repo, it looks like that PR has been merged and released as of 0.10.0 or 0.10.1 - might be worth another look?

yup: https://github.com/bevyengine/bevy/pull/6558

I just tried this on bevy/main since that just got merged and this is now working for me while using the rust-lld linker on Windows 🎉
Note that you do still have to make sure to add this to your cargo.toml
# Enable a small amount of optimization in debug mode
[profile.dev]
opt-level = 1

# Enable high optimizations for dependencies (incl. Bevy), but not for our code:
[profile.dev.package."*"]
opt-level = 3

Without that I was getting rust-lld: error: too many exported symbols (got 243525, max 65535) which is reported here: https://github.com/bevyengine/bevy/issues/1110#issuecomment-1312926923

Hey, just wanted to let you know that it's now working for me with bevy 9.1 an d rust-lld.

Closing this out! Feel free to reopen if y'all can reproduce.

So I was chasing the same issue for a while, and I managed to get to the bottom of it. Please see: https://github.com/llvm/llvm-project/issues/82050

authors: 7flash Frizi Paulo-21 RobertoMaurizzi SamJBarney SecretPocketCat afonsolage aganea aka-bash0r alice-i-cecile bjorn3 dallonf mockersf paul-hansen ysaskia

repo: bevyengine/bevy


text:
SpriteBundle background color randomly not rendererd

Bevy version
v0.10.1
Relevant system information
`AdapterInfo { name: "NVIDIA GeForce 920M", vendor: 4318, device: 4761, device_type: DiscreteGpu, driver: "NVIDIA", driver_info: "470.182.03", backend: Vulkan }`

What you did
Simply run the breakout example.
What went wrong
Expected behavior:
The background color of the bricks and walls are visible on every execution of the application.
Actual behavior:
The background color of the bricks and walls are not visible on some executions of the application.
Additional information
My system is a laptop with hybrid graphics Intel + NVIDIA, configured for PRIME offloading.
I am running the application under SwayWM XWayland.
I have already tested this under the Intel GPU too but the issue is not there.
Diving deeper with RenderDoc, it seems to be a problem with rendering consecutive frames after the first one.
I can confirm that the vertices are still there, its just the colors are not being rendered.
Frame 0

Frame 1

Side note: This also happens for the NodeBundle background color when I ran the other examples.

I have setup a dynamic scene to test colors when I encounter the issue.
Sometimes the background becomes like below.

Closing as it was a GPU specific issue that is not worth creating a workaround for.

source: gharchive/issue

license_type: permissive

license_source: github-api


text:
Use -D warnings in all relevant CI

Objective
Fixes #17009
See: https://doc.rust-lang.org/stable/clippy/continuous_integration/index.html
Solution
Add the env
Testing
CI should start to fail, then I'll fix it.
Showcase

I broadly agree with this: deny warnings is the standard practice for Rust + Bevy, and blocking CI is the best way to ensure that these are fixed and stay fixed.

An alternative direction that we could take is to deny warnings in CI except for unused imports, variables, and muts. This might help keep verbosity down while still catching important lints. If we do that though, I would expect all the cfg stuff to be removed in all existing places we already do do that.

I don't like this though because I don't want irrelevant warnings when developing locally and there isn't enough granularity with allowing warnings in unchanged code.

Agreed. Half of the reason why these lints exist are to provide a better local development experience.

OK to add -D warnings to CI, but I would prefer the warnings in task pool creating to be solved in a way that keep their builder for wasm and not wasm common

I can do that

source: gharchive/pull-request

authors: BenjaminBrienen alice-i-cecile mockersf


text:
Fix instance rate vertex buffers

Implemented missing parts to support instance rate vertex buffers.
Instance count is calculated from instance rate buffer size and stride. This is not ideal if you want to render less instances than allocated buffer, but I think this is a good solution for the time being.
I also improved debug output in render, but can revert the last commit if it's too verbose.

Converting this to draft as it still does not fit my particle system use case. Calculating instance count from instanced vertex buffer is quite limiting in terms of performance. You are either wasting resources rendering unused instances or have to reallocate buffer.
I'm not sure what would be the best way to implement this. Instance count could be specified in Draw component, but could as well be a property of vertex buffer (like size vs capacity for vector).


text:
Use get_unchecked on release builds for image_texture_conversion

Just fixes does a quick fix while I was hunting for TODO's
Objective
Fixes a TODO that requests to use get_unchecked during release builds, rather than indexing normally (which includes bounds checking).
Solution
Used some conditional compilation that uses the regular indexing method on debug builds, and uses the get_unchecked method on release builds.

Oh okay, I'll just snip this PR then.

Oh okay, I'll just snip this PR then.

Could you swap over the TODO comment and then we can merge this? :)

Yeah, exactly that please.

@mockersf, how would I target the pipleined-rendering branch? Sorry to ask, I'm not crazy familiar with advanced PR stuff

So I changed the base, and now all of those commits are there...
Do I just make a new PR that removes the comment, but make it initially target the pipelined-rendering branch?

@billyb2 sounds good.

authors: DJMcNab alice-i-cecile billyb2


text:
Documented and tested Axis

Objective
Fixes #3247
Solution

Added docs to Axis<T>. This one can be extended @alice-i-cecile
Added unit tests
Added min and max values to the struct. @alice-i-cecile Do we need to these variables?
Limited set method usage with min and max values

Added min and max values to the struct. @alice-i-cecile Do we need to these variables?

Upon reflection, I think we should just hard-code these in as -1.0 and 1.0. Exotic controllers (e.g. guitars, XR, tablets, theremins, hamster wheels) would want to use fully un-normalized values where neither min or max exist. Simply hard-coding and documenting the values makes the code simpler to maintain and work with: we can make it configurable if there's a compelling use case.

@alice-i-cecile @MinerSebas  I applied your suggestion about docs. Let me know your opinions about the set method and configuration of min and max. Currently, I don't know exactly how it should be configurable and the proper behavior for the method.

Let me know your opinions about the set method and configuration of min and max. Currently, I don't know exactly how it should be configurable and the proper behavior for the method.

Talked this over a bit more on Discord (and looked at what other engines do): Unity, Unreal and Godot all use the fixed range. Let's hard-code this to [-1.0, 1.0], simplify the code and update the docs to match :)

Talked this over a bit more on Discord (and looked at what other engines do): Unity, Unreal and Godot all use the fixed range. Let's hard-code this to [-1.0, 1.0], simplify the code and update the docs to match :)

Updated the code to match your suggestion. Now it's documented, intervals are hardcoded and set method is updated

bors r+

authors: CrazyRoka alice-i-cecile cart


text:
Remove restrictions on Label types

Redo of #5377
Background
Originally, label traits were essentially like Any, but with extra capabilities.

This was unnecessarily slow, as it required boxing every label even though the vast majority are simply unit structs or C-style enums.
Ignited months-long unresolved debates as to whether Box<dyn *Label> should implement the trait.
Required a long list of derives for every implementer.
O(?) comparisons due to dynamic dispatch.

In #4957, labels were simplified: they are represented as just a TypeId and a string literal.

This sped up label comparisons and dependency resolution considerably, as allocations and dynamic dispatch are no longer necessary.
Makes the use of labels more ergonomic, as their type-erased form is Copy. Additionally, none of the extra derives are required.
It introduced major restrictions on what types can be labels: labels can only have names, not data.
In most cases, this change was completely invisible to users.

Objective

Remove the restrictions: allow labels to store any data that they want.
Make complex labels faster than before #4957.
Don't pessimize simple label types -- they should be just as fast as before this PR.
Make comparisons O(1).
Optimize the stack size of type-erased labels.
Keep the user-facing API as simple as possible.

Solution

Allow arbitrary debug formatting by writing to an &mut Formatter.
For comparisons, use a u64.

Types that are 8 bytes or smaller can be encoded and stored inline.
For larger types, intern them and store their index. This also avoids duplicate allocations for identical labels.
Both of these cases are supported in the derive macro.

Keep the stack size low by storing type-related data behind a pointer to an associated const.

Examples
Basic labels get converted to an integer and stored on the stack.
#[derive(SystemLabel)]
enum MyLabel {
    One,
    Two,
}

//
// Derive expands to...

impl IntoSystemLabel for MyLabel {
    fn data(&self) -> u64 {
        match self {
            Self::One => 0,
            Self::Two => 1,
        }
    }
    fn fmt(data: u64, f: &mut fmt::Formatter) -> fmt::Result {
        match data {
            0 => write!(f, "MyLabel::One"),
            1 => write!(f, "MyLabel::Two"),
            _ => Err(fmt::Error),
        }
    }
}

Complex labels get interned, with their index stored on the stack.
#[derive(Debug, Clone, PartialEq, Eq, Hash, SystemLabel)]
#[system_label(intern)]
pub struct MyLabel<T>(Vec<T>);

//
// Derive expands to...

use bevy_utils::{AnyInterner, InternGuard};

// Global label interner for `MyLabel<T>`, for any `T`.
static MAP: AnyInterner = AnyInterner::new();

impl<T: Debug + Clone + Hash + Eq + Send + Sync + 'static> IntoSystemLabel for MyLabel<T> {
    fn data(&self) -> u64 {
        MAP.intern(self)
    }
    fn fmt(idx: u64, f: &mut Formatter) -> fmt::Result {
        let val = MAP.get::<Self>(idx).ok_or(fmt::Error)?;
        write!(f, "{val:?}")
    }
}

Benchmarks
Relative to before this PR.

Using stack-allocated labels.

# of Systems
No deps
% Change
W/ deps
% Change

100
235.51 us
-0.9142%
1.8465 ms
-9.2033%

500
782.39 us
+0.1074%
61.109 ms
-15.269%

1000
1.4279 ms
+1.0771%
310.41 ms
-13.131%

Heap-allocating everything.

# of Systems
No deps
% Change
W/ deps
% Change

100
233.20 us
+1.0003%
2.0064 ms
+1.5735%

500
789.80 us
-0.9972%
64.846 ms
-6.1881%

1000
1.4699 ms
-2.0041%
318.41 ms
-5.2037%

Notes

This PR adds parking_lot and indexmap as dependencies for bevy_utils.

indexmap only has one dependency (hashbrown), which is already a dependency of bevy_utils.

Future Work

We can clean up unused memory by emptying out the global interners after dependency resolution is complete. This would break debug formatting, but comparisons would still work perfectly.
Downcasting can easily be implemented, but the API decisions are left for a future PR.

Changelog

Made the internal representation of labels more flexible.
Added support for complex label types by interning them.

Migration Guide
The Label family of traits (SystemLabel, StageLabel, etc) is no longer object safe.

Any use of Box<dyn *Label> should be replaced with *LabelId - this family of types serves the same purpose but is Copy and does not usually require allocations.
Any use of &dyn *Label should be replaced with impl *Label if possible, or *LabelId if you cannot use generics.

For manual implementers of this family of traits, you should now implement the corresponding Into*Label trait.
enum GameLabel {
    Input,
    Physics,
}

// Before:

impl SystemLabel for GameLabel {
    fn as_str(&self) -> &'static str {
        match self {
            Self::Input => "GameLabel::Input",
            Self::Physics => "GameLabel::Physics",
        }
    }
}

// After:

impl IntoSystemLabel for GameLabel {
    fn data(&self) -> u64 {
        match self {
            Self::Input => 0,
            Self::Physics => 1,
        }
    }
    fn fmt(data: u64, f: &mut Formatter) -> fmt::Result {
        match data {
            0 => write!(f, "GameLabel::Input"),
            1 => write!(f, "GameLabel::Physics"),
            _ => Err(fmt::Error),
        }
    }
}

This is an exceptional writeup, and I agree with the motivations here. A bit annoying to increase the complexity of this niche area further, but I think the expressiveness and performance will be worth it.

@JoJoJet is this still relevant?

Nah, I have no intention to update this.

authors: JoJoJet alice-i-cecile


text:
Rustdoc: Scrape example

Objective
Provide more usage examples in API docs so that people can see methods being used in context.
Solution
Enable experimental rustdoc feature "scrape examples". See https://doc.rust-lang.org/nightly/rustdoc/scraped-examples.html for official docs.
Example screenshots of examples :)

Limitations

Only methods seem to show examples so far
It may be confusing to have curated examples from doc comments followed by snippets from examples/

If this is approved, consider including it in 0.11.1!

re ci: check-bans fail seems unrelated

I also agree that its worth including in 0.11.1

I'm on board in principle with enabling this! Haven't reviewed the diff yet though.

I've played with this in bevy-ui-navigation. In my experience it's tricky to get the config right so that docs.rs properly scraps examples.

@mockersf Would this work with https://dev-docs.bevyengine.org/bevy/index.html?

Just so you know, new examples will need these flags in Cargo.toml. Maybe a good idea to check this in CI.

I think this doesn't work. It was part of 0.11.1 so docs on docs.rs should be built with it but I can't find any scraped example

I think this doesn't work. It was part of 0.11.1 so docs on docs.rs should be built with it but I can't find any scraped example

looks the same to me

@mockersf FYI if we can make the CI for dev-docs run on nightly, it will pick up https://github.com/rust-lang/cargo/issues/13074 and include examples :)

authors: alice-i-cecile cart dennisorlando killercup mockersf nicopap


text:
Timeout on deploy

Hi! This tool looks awesome!
I just installed it and are now testing on our stage server on Digital Ocean.
After installing the cli tool globally with composer I did the following:
▶ forge login

▶ forge init

Chose the correct server and site in forge init.
Then manually edit forge.yml to change env from "production" to "stage".
▶ forge info stage
+-----------+-------------------------+
| Key       | Value                   |
+-----------+-------------------------+
| Server    | example-stage           |
| IP        | x.x.x.x                 |
| Site      | example.com             |
| Directory | /public                 |
+-----------+-------------------------+

▶ forge deploy stage
Deploying site on stage...

In TimeoutException.php line 22:

  Argument 1 passed to Laravel\Forge\Exceptions\TimeoutException::__construct() must be of the type array, bool given, called in phar:
  ///example.com/.composer/vendor/beyondcode/forge-cli/builds/forge/vendor/laravel/forge-sdk/src/MakesHttpRequests.php on line 138

Things to note:

I logged in with a user that have been added to an circle and for that reason only have access to this server.
I manually edited the key in forge.yml from "production" to "stage" as I want this to be our stage server.
The deploymentscript itself that we have created on forge (and was copied to deployment inside forge.yml on init) seems to work. The site did actually do a successful deployment, but without the deployment output in the CLI. We do not use quick-deploy. That beeing said we have modifed the standard deploymentscript pretty heavily to get a no downtime deployment with forge.

Not sure why I got the timeout exception. Any suggestions or logs I can check? For the record the timeout seemed to come pretty quickly (like after 10-15 seconds, not 30s or 60s).
System:
▶ php -v && forge --version && lsb_release -a
PHP 7.4.10 (cli) (built: Sep  9 2020 06:36:14) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.10, Copyright (c), by Zend Technologies
Forge 1.0.5
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.5 LTS
Release:	18.04
Codename:	bionic

Thanks!

I just fixed this in version 1.1.0
The timeout was increased, but you can also use the new --no-wait option on the deploy command, in case you do not need to wait for the deployment log/result.

Thanks! Just tested and it's working smoothly now :+1:

authors: mpociot nettum

repo: beyondcode/forge-cli

license: MIT


text:
Koa

Is it possible to use this with Koa instead of Express?

Using the options, I was able to get this plugin at least partially running with:
createPrometheusExporterPlugin({ metricsEndpoint: false, defaultMetrics: false })

What I'm seeing on my endpoint now contains this:
# HELP apollo_server_starting The last timestamp when Apollo Server was starting.
# TYPE apollo_server_starting gauge
apollo_server_starting{version="v2.21.0",hostname="RROSS-XPS15"} 1614355537.831

# HELP apollo_server_closing The amount timestamp when Apollo Server was closing.
# TYPE apollo_server_closing gauge

# HELP apollo_query_started The amount of received queries.
# TYPE apollo_query_started counter

# HELP apollo_query_parse_started The amount of queries for which parsing has started.
# TYPE apollo_query_parse_started counter

# HELP apollo_query_parse_failed The amount of queries for which parsing has failed.
# TYPE apollo_query_parse_failed counter

# HELP apollo_query_validation_started The amount of queries for which validation has started.
# TYPE apollo_query_validation_started counter

# HELP apollo_query_validation_failed The amount of queries for which validation has failed.
# TYPE apollo_query_validation_failed counter

# HELP apollo_query_resolved The amount of queries which could be resolved.
# TYPE apollo_query_resolved counter

# HELP apollo_query_execution_started The amount of queries for which execution has started.
# TYPE apollo_query_execution_started counter

# HELP apollo_query_execution_failed The amount of queries for which execution has failed.
# TYPE apollo_query_execution_failed counter

# HELP apollo_query_failed The amount of queries that failed.
# TYPE apollo_query_failed counter

# HELP apollo_query_duration The total duration of a query.
# TYPE apollo_query_duration histogram

# HELP apollo_query_field_resolution_duration The total duration for resolving fields.
# TYPE apollo_query_field_resolution_duration histogram

However, I'm not seeing any actual statistics being gathered when I make Apollo queries.

Hello!
Yep, express is used only for exposing the metrics. What you can do:
import { register } from 'prom-client';

const app = new koa();
const router = new koaRouter();

const prometheusExporterPlugin = createPrometheusExporterPlugin({
  register, // this may not be needed but it ensures that the correct prom-client register is used
  metricsEndpoint: false // this will disable the integration between the plugin and express
});

// ... continue with the usual implementation of Apollo

router.get('/metrics', async (ctx) => {
  ctx.type = register.contentType; // set the correct content type from the prom-client register
  ctx.body = await actualRegister.metrics(); // set the body of the response to the data exposed by prom-client
});

Also, can you please post an example using StackBlitz or a GitHub repo to look over? It would help a lot.
Thanks!

I'm going to close this for no activity. Please feel free to reopen it if needed.

Finally had a chance to circle back on this.  I does look like it is working now:
# HELP apollo_server_starting The last timestamp when Apollo Server was starting.
# TYPE apollo_server_starting gauge
apollo_server_starting{version="v2.22.2",hostname="RROSS-XPS15"} 1617279638.125

# HELP apollo_server_closing The amount timestamp when Apollo Server was closing.
# TYPE apollo_server_closing gauge

# HELP apollo_query_started The amount of received queries.
# TYPE apollo_query_started counter
apollo_query_started{operationName="IntrospectionQuery",hostname="RROSS-XPS15"} 2
apollo_query_started{hostname="RROSS-XPS15"} 9

# HELP apollo_query_parse_started The amount of queries for which parsing has started.
# TYPE apollo_query_parse_started counter
apollo_query_parse_started{operationName="IntrospectionQuery",hostname="RROSS-XPS15"} 1
apollo_query_parse_started{hostname="RROSS-XPS15"} 2

# HELP apollo_query_parse_failed The amount of queries for which parsing has failed.
# TYPE apollo_query_parse_failed counter

# HELP apollo_query_validation_started The amount of queries for which validation has started.
# TYPE apollo_query_validation_started counter
apollo_query_validation_started{operationName="IntrospectionQuery",hostname="RROSS-XPS15"} 1
apollo_query_validation_started{hostname="RROSS-XPS15"} 2

# HELP apollo_query_validation_failed The amount of queries for which validation has failed.
# TYPE apollo_query_validation_failed counter

# HELP apollo_query_resolved The amount of queries which could be resolved.
# TYPE apollo_query_resolved counter
apollo_query_resolved{operationName="IntrospectionQuery",operation="query",hostname="RROSS-XPS15"} 2
apollo_query_resolved{operation="query",hostname="RROSS-XPS15"} 9

# HELP apollo_query_execution_started The amount of queries for which execution has started.
# TYPE apollo_query_execution_started counter
apollo_query_execution_started{operationName="IntrospectionQuery",operation="query",hostname="RROSS-XPS15"} 2
apollo_query_execution_started{operation="query",hostname="RROSS-XPS15"} 9

# HELP apollo_query_execution_failed The amount of queries for which execution has failed.
# TYPE apollo_query_execution_failed counter

# HELP apollo_query_failed The amount of queries that failed.
# TYPE apollo_query_failed counter

# HELP apollo_query_duration The total duration of a query.
# TYPE apollo_query_duration histogram
apollo_query_duration_bucket{le="0.001",operationName="IntrospectionQuery",operation="query",success="true",hostname="RROSS-XPS15"} 0
apollo_query_duration_bucket{le="0.005",operationName="IntrospectionQuery",operation="query",success="true",hostname="RROSS-XPS15"} 0
apollo_query_duration_bucket{le="0.015",operationName="IntrospectionQuery",operation="query",success="true",hostname="RROSS-XPS15"} 0
apollo_query_duration_bucket{le="0.05",operationName="IntrospectionQuery",operation="query",success="true",hostname="RROSS-XPS15"} 3
apollo_query_duration_bucket{le="0.1",operationName="IntrospectionQuery",operation="query",success="true",hostname="RROSS-XPS15"} 3
apollo_query_duration_bucket{le="0.2",operationName="IntrospectionQuery",operation="query",success="true",hostname="RROSS-XPS15"} 3
apollo_query_duration_bucket{le="0.3",operationName="IntrospectionQuery",operation="query",success="true",hostname="RROSS-XPS15"} 3
apollo_query_duration_bucket{le="0.4",operationName="IntrospectionQuery",operation="query",success="true",hostname="RROSS-XPS15"} 3
apollo_query_duration_bucket{le="0.5",operationName="IntrospectionQuery",operation="query",success="true",hostname="RROSS-XPS15"} 3
apollo_query_duration_bucket{le="1",operationName="IntrospectionQuery",operation="query",success="true",hostname="RROSS-XPS15"} 3
apollo_query_duration_bucket{le="5",operationName="IntrospectionQuery",operation="query",success="true",hostname="RROSS-XPS15"} 3
apollo_query_duration_bucket{le="10",operationName="IntrospectionQuery",operation="query",success="true",hostname="RROSS-XPS15"} 3
apollo_query_duration_bucket{le="+Inf",operationName="IntrospectionQuery",operation="query",success="true",hostname="RROSS-XPS15"} 3
apollo_query_duration_sum{operationName="IntrospectionQuery",operation="query",success="true",hostname="RROSS-XPS15"} 0.082
apollo_query_duration_count{operationName="IntrospectionQuery",operation="query",success="true",hostname="RROSS-XPS15"} 3
apollo_query_duration_bucket{le="0.001",operation="query",success="true",hostname="RROSS-XPS15"} 8
apollo_query_duration_bucket{le="0.005",operation="query",success="true",hostname="RROSS-XPS15"} 10
apollo_query_duration_bucket{le="0.015",operation="query",success="true",hostname="RROSS-XPS15"} 10
apollo_query_duration_bucket{le="0.05",operation="query",success="true",hostname="RROSS-XPS15"} 10
apollo_query_duration_bucket{le="0.1",operation="query",success="true",hostname="RROSS-XPS15"} 10
apollo_query_duration_bucket{le="0.2",operation="query",success="true",hostname="RROSS-XPS15"} 10
apollo_query_duration_bucket{le="0.3",operation="query",success="true",hostname="RROSS-XPS15"} 10
apollo_query_duration_bucket{le="0.4",operation="query",success="true",hostname="RROSS-XPS15"} 10
apollo_query_duration_bucket{le="0.5",operation="query",success="true",hostname="RROSS-XPS15"} 10
apollo_query_duration_bucket{le="1",operation="query",success="true",hostname="RROSS-XPS15"} 10
apollo_query_duration_bucket{le="5",operation="query",success="true",hostname="RROSS-XPS15"} 10
apollo_query_duration_bucket{le="10",operation="query",success="true",hostname="RROSS-XPS15"} 10
apollo_query_duration_bucket{le="+Inf",operation="query",success="true",hostname="RROSS-XPS15"} 10
apollo_query_duration_sum{operation="query",success="true",hostname="RROSS-XPS15"} 0.008
apollo_query_duration_count{operation="query",success="true",hostname="RROSS-XPS15"} 10

# HELP apollo_query_field_resolution_duration The total duration for resolving fields.
# TYPE apollo_query_field_resolution_duration histogram
apollo_query_field_resolution_duration_bucket{le="0.001",operation="query",fieldName="pingStudyDesignService",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 8
apollo_query_field_resolution_duration_bucket{le="0.005",operation="query",fieldName="pingStudyDesignService",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 8
apollo_query_field_resolution_duration_bucket{le="0.015",operation="query",fieldName="pingStudyDesignService",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 8
apollo_query_field_resolution_duration_bucket{le="0.05",operation="query",fieldName="pingStudyDesignService",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 8
apollo_query_field_resolution_duration_bucket{le="0.1",operation="query",fieldName="pingStudyDesignService",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 8
apollo_query_field_resolution_duration_bucket{le="0.2",operation="query",fieldName="pingStudyDesignService",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 8
apollo_query_field_resolution_duration_bucket{le="0.3",operation="query",fieldName="pingStudyDesignService",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 8
apollo_query_field_resolution_duration_bucket{le="0.4",operation="query",fieldName="pingStudyDesignService",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 8
apollo_query_field_resolution_duration_bucket{le="0.5",operation="query",fieldName="pingStudyDesignService",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 8
apollo_query_field_resolution_duration_bucket{le="1",operation="query",fieldName="pingStudyDesignService",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 8
apollo_query_field_resolution_duration_bucket{le="5",operation="query",fieldName="pingStudyDesignService",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 8
apollo_query_field_resolution_duration_bucket{le="10",operation="query",fieldName="pingStudyDesignService",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 8
apollo_query_field_resolution_duration_bucket{le="+Inf",operation="query",fieldName="pingStudyDesignService",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 8
apollo_query_field_resolution_duration_sum{operation="query",fieldName="pingStudyDesignService",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 0
apollo_query_field_resolution_duration_count{operation="query",fieldName="pingStudyDesignService",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 8
apollo_query_field_resolution_duration_bucket{le="0.001",operation="query",fieldName="features",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_bucket{le="0.005",operation="query",fieldName="features",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_bucket{le="0.015",operation="query",fieldName="features",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_bucket{le="0.05",operation="query",fieldName="features",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_bucket{le="0.1",operation="query",fieldName="features",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_bucket{le="0.2",operation="query",fieldName="features",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_bucket{le="0.3",operation="query",fieldName="features",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_bucket{le="0.4",operation="query",fieldName="features",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_bucket{le="0.5",operation="query",fieldName="features",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_bucket{le="1",operation="query",fieldName="features",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_bucket{le="5",operation="query",fieldName="features",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_bucket{le="10",operation="query",fieldName="features",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_bucket{le="+Inf",operation="query",fieldName="features",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_sum{operation="query",fieldName="features",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 0
apollo_query_field_resolution_duration_count{operation="query",fieldName="features",parentType="Query",pathLength="1",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_bucket{le="0.001",operation="query",fieldName="studyActivityReorderingAllowed",parentType="FeatureResponse",pathLength="2",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_bucket{le="0.005",operation="query",fieldName="studyActivityReorderingAllowed",parentType="FeatureResponse",pathLength="2",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_bucket{le="0.015",operation="query",fieldName="studyActivityReorderingAllowed",parentType="FeatureResponse",pathLength="2",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_bucket{le="0.05",operation="query",fieldName="studyActivityReorderingAllowed",parentType="FeatureResponse",pathLength="2",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_bucket{le="0.1",operation="query",fieldName="studyActivityReorderingAllowed",parentType="FeatureResponse",pathLength="2",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_bucket{le="0.2",operation="query",fieldName="studyActivityReorderingAllowed",parentType="FeatureResponse",pathLength="2",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_bucket{le="0.3",operation="query",fieldName="studyActivityReorderingAllowed",parentType="FeatureResponse",pathLength="2",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_bucket{le="0.4",operation="query",fieldName="studyActivityReorderingAllowed",parentType="FeatureResponse",pathLength="2",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_bucket{le="0.5",operation="query",fieldName="studyActivityReorderingAllowed",parentType="FeatureResponse",pathLength="2",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_bucket{le="1",operation="query",fieldName="studyActivityReorderingAllowed",parentType="FeatureResponse",pathLength="2",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_bucket{le="5",operation="query",fieldName="studyActivityReorderingAllowed",parentType="FeatureResponse",pathLength="2",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_bucket{le="10",operation="query",fieldName="studyActivityReorderingAllowed",parentType="FeatureResponse",pathLength="2",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_bucket{le="+Inf",operation="query",fieldName="studyActivityReorderingAllowed",parentType="FeatureResponse",pathLength="2",hostname="RROSS-XPS15"} 2
apollo_query_field_resolution_duration_sum{operation="query",fieldName="studyActivityReorderingAllowed",parentType="FeatureResponse",pathLength="2",hostname="RROSS-XPS15"} 0
apollo_query_field_resolution_duration_count{operation="query",fieldName="studyActivityReorderingAllowed",parentType="FeatureResponse",pathLength="2",hostname="RROSS-XPS15"} 2

repo: bfmatei/apollo-prometheus-exporter


text:
Dont't fix image with empty src

I have faced with extra reqeust in IE and after investigation I noticed that ofi generates them.
I use tag image without src attribute at all (or it can be image with empty src) for lazy loading. In that case ofi process this image and create backgroun-image style with empty source which make new request to current page.
Could you suggest the desicion for this case?

+1

Hi @fregante, I saw that this bug is still open and that there is a brach with the fix in it. I and my team are using your awesome polyfill, but in order to make it work properly, we are currently applying a patch like the one you merged here.
We were wondering why this is not been merged in master and released with a new version.
Can I do something to help with it? Thanks 😁

I haven't merged it because I don't have time to test it properly on IE and don't want to break it for anyone who has been using it unchanged for the past 3 years.
If you'd like to help, you can test it on IE9, IE11 and let me know if it works on both:

does the demo still work correctly in both browsers?
does it work if you add the src after?

authors: Hirbod bpahan fregante matteobad

repo: bfred-it/object-fit-images

license: mit

license_source: bigquery


text:
Fastboot support

After the latest release I hopped, that this addon now has a fastboot support, but i get the following error: Error: Network error: XMLHttpRequest is not defined
I tried to set up a new ember app(2.16.0) with just ember-cli-fastboot(1.1.0) and ember-apollo-client(0.5.2) installed, but i still get the same error.

Do you have a sample app we can reference to help debug this?
On Sat, Oct 21, 2017 at 1:19 AM Christoph Wiedenmann <
notifications@github.com> wrote:

After the latest release I hopped, that this addon now has a fastboot
support, but i get the following error: Error: Network error:
XMLHttpRequest is not defined
I tried to set up a new ember app(2.16.0) with just
ember-cli-fastboot(1.1.0) and ember-apollo-client(0.5.2) installed, but i
still get the same error.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/bgentry/ember-apollo-client/issues/65, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AAG9cb-3xJS82gbqDk7ZcWYE0L9k-KV0ks5suakpgaJpZM4QBe3R
.

I created a new repo with my small sample app. https://github.com/kennstenicht/ember-apollo-fastboot-test

@bgentry i have this error too. I tried use Apollo Fetch and integrate with ember-apollo, but I was not very successful. Do you have any idea how I am substituting XMLHttpRequest for fetch API in apollo-client?

@bgentry you have any suggestion for this problem with SSR?

I think this issue will be easier to address with Apollo Link after we update the addon to Apollo Client 2.0 - #54

I do not think so @viniciussbs, because the problem is the fastboot don't support XMLHttpRequest and Apollo Client 2.0  continues using XMLHttpRequest

@villander Apollo Client 2.0 relies on Apollo Link, that relies on Fetch. It deals better with global Fetch and let's you pass your on Fetch implementation.

Nice, we go start migration 🏎

Maybe something like this but inside the service should solve the fetch problem:
https://github.com/bgentry/ember-apollo-client/blob/master/tests/helpers/module-for-acceptance.js#L16-L20

@viniciussbs it's don't works, because SSR don't support browser API as window. What makes sense is to overwrite apollo's networkInterface or migrate to version 2.0
https://ember-fastboot.com/docs/addon-author-guide#common-causes

This was merged in #79. @villander created a sample fastboot app here: https://github.com/villander/ember-mvp
Check the readme for more info. Cheers 🍻

authors: bgentry kennstenicht villander viniciussbs

repo: bgentry/ember-apollo-client


text:
ModuleNotFoundError: No module named 'cydist.sspd' with Python 3

Hi! I'm trying to run the examples using python 3, and I'm getting the following error:
[silencer@myhostname traj_dist]$ python example.py
Traceback (most recent call last):
  File "example.py", line 2, in <module>
    import traj_dist.distance as tdist
  File "/usr/lib/python3.6/site-packages/traj_dist/distance.py", line 3, in <module>
    from cydist.sspd import c_e_sspd, c_g_sspd
ModuleNotFoundError: No module named 'cydist.sspd'

I have installed it as per the readme file. It is working in python 2, however.
Do you have any idea about what could be happening? I'd like to use this library with python 3.
Thank you for your hard work!
Rodrigo

Hi! I'm trying to run the examples using python 3, and I'm getting the following error:
[silencer@myhostname traj_dist]$ python example.py
Traceback (most recent call last):
  File "example.py", line 2, in <module>
    import traj_dist.distance as tdist
  File "/usr/lib/python3.6/site-packages/traj_dist/distance.py", line 3, in <module>
    from cydist.sspd import c_e_sspd, c_g_sspd
ModuleNotFoundError: No module named 'cydist.sspd'

I have installed it as per the readme file. It is working in python 2, however.
Do you have any idea about what could be happening? I'd like to use this library with python 3.
Thank you for your hard work!
Rodrigo

Hi Rodrigo, if you are still interested in using this, I have it working on Python 3.6. Either check out the pull request, or my fork of this repository.

authors: djjavo rpelorosso

repo: bguillouet/traj-dist


text:
Update deps.

Get the latest version of JS and CSS compression deps. Ensure no regressions.

Done.


text:
Bugs in settings.dart

Description
You need to create the constructor for settingspagestate class and there are some other bugs as well.
Screenshots

Additional information
No response

Hey @bhattabhi013, please assign this to me.

Hi assigning it to you, but before working on it, please list down all the bugs that you are facing.
It might help others in the community.

Resolved in the new commit🚀


text:
Add files via upload

added a cp problem which i solved in java

ok sure

i have added a new file with same code with .java as extension check that and plz merge that


text:
🛑 RefineAIR MQTT is down

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

HTTP code: 0
Response time: 0 ms

Resolved: RefineAIR MQTT is back up in 6d3e6d2.

repo: biapar/uptime


text:
only text, but no buy/sell!?

For Example..
This message..
Going to buy in now! No open orders, ready to set a buy order! I have 0.00104743 BTC to spend I can buy 0.0010120008019629 SC for this
But... no function! no buying, no selling?

Hey there, probably something has changed in the API... I'll try to look into this in the next few days..


text:
[FIX] Fixing template string on electrodes for eeg and ieeg.

Summary
Closes: #649
Fixes the template strings in the modality-specific spec to match that of https://bids-specification.readthedocs.io/en/stable/99-appendices/04-entity-table.html#encephalography-eeg-ieeg-and-meg

This is in accordance with the entity table: https://bids-specification.readthedocs.io/en/latest/99-appendices/04-entity-table.html#encephalography-eeg-ieeg-and-meg ... so this is truly a fix.
unfortunately, as discussed in this issue comment, the validator is not precise enough to validate this. So the validator will still accept files like: *_task-Nonsense_electrodes.tsv. There is a similar issue here: https://github.com/bids-standard/bids-validator/issues/848
Still +1 to merge, then adjust mne-bids (https://github.com/mne-tools/mne-bids/pull/604), and then eventually improve the validator (better sooner than later)

Thanks @adam2392

repo: bids-standard/bids-specification


text:
Problem: Unsure if Tendermint wants BigchainDB to Create a "Genesis block"

Back when BigchainDB Server was responsible for building the blocks, it would start out by creating a "Genesis block": bigchaindb init would call create_genesis_block() which would call prepare_genesis_block() which would make a simple "Genesis block" containing one special "Genesis transaction".
Does bigchaindb init still do that? If so, is that necessary, i.e. does Tendermint want BigchainDB Server to create a "Genesis block" or is this just old code that can be removed? Actually, how is it possible that BigchainDB Server can create a block? I thought that was Tendermint's job.
Issues Related to the Genesis Block & Genesis Transaction
#444
#712
#1375

This issue has been resolved. Tendermint does want a GENESIS block.
There is still some old "GENESIS transaction" code that can be removed, but that's a separate issue.

repo: bigchaindb/bigchaindb


text:
Ambiguity in the volume mounted to mongoDB docker

https://github.com/bigchaindb/bigchaindb/blob/7781f5aae8fd6a578175370d4f2775c3bfe2e9ce/pkg/configuration/roles/mongodb/defaults/main.yml#L26
Description
MongoDB's default database storage path is /data/db. In the code referenced, why are we mounting the host's /data/db to the containers' /data/db/main path.
Problem

This keeps on increasing the Mongodb containers' size with increasing number of transactions.
Also, the data gets lost when we purge the container.

@ttmc Could you look at this issue?

I assume just changing the path to /data/db would work as well. Have to tried changing it?

@muawiakh Yes it works, I was just curious why they did that.


text:
Added the possibility to configure the mouse button that triggers the action

As having the middle mouse being the default under Linux really messes up my workflow :smile:.
Thank you for this plug-in!

Oh, i just saw there is an issue open for this... this PR could close #26

@plafue Thanks for this.
It doesn't seem to work for me I'm afraid. Maybe its just a dev mode thing to do with the 'Sublime-Style-Column-Selection.mouseButtonTrigger' line.
Also, I'm not a fan of reading the config every mouse move. Can this value be cached with an observer?

authors: bigfive plafue

repo: bigfive/atom-sublime-select


text:
🛑 International booking - Quotation is down

In 0a7df0f, International booking - Quotation (https://agoyu.com/api/booking/market-place/123) was down:

HTTP code: 0
Response time: 0 ms

International booking - Quotation is restart service.

International booking - Quotation is restart service.

Resolved: International booking - Quotation is back up in 2fc82f4.

repo: biginvn/upptime


text:
add action to send special chars.

this is a reference page for this feature.
When implement this action, think about how to implement a multi keys action

could I use java robot class to implement these actions?
Furthermore, how can I write XML file to record these  actions?

What is java robot class?
On 05/27/2015 10:41 PM, ericlu312 wrote:

could I use java robot class to implement these actions?
Furthermore, how can I write XML file to record these actions?
—
Reply to this email directly or view it on GitHub
https://github.com/bigtester/automation-test-engine/issues/149#issuecomment-106152439.

Java.awt.Robot class is used to take the control of mouse and keyboard. Once you get the control, you can do any type of operation related to mouse and keyboard through your java code. This class is used generally for test automation.
I found a link which describe the actions in selenium webdriver
http://www.ibm.com/developerworks/cn/java/j-lo-keyboard/

oops, I thought that I have put this link here when I created the issue, this link does tell how to implement this feature. let me know if you still have question.
http://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/Keys.html

Design of fix for this issue,

ATE will add a new action named 'typeSpecialKeysAction' with parameter firstKey (mandatory), secondKey (optional), thirdKey (optional), fourthKey(optional)
each parameter has limited value to select in xml script
parameters could be combined sent to the web page if multiple keys given by the user
implementation will invoke webdriver sendkeys api to send above special keys, either single one special key or combined ones.

authors: bigtester-prot ericlu312 peidong-hu

repo: bigtester/automation-test-engine


text:
使用视频剪辑Demo时，视频无法显示画面，合成出来的视频页面没有画面

提示警告：hook.js:608 First sample not idr frame
第一帧确认是关键帧

视频文件：
https://fly-cut.oss-cn-hangzhou.aliyuncs.com/下载 (6).mp4

少写了一个类型，近期修复
参考 ffmpeg  IS_IDR(s)   ((s)->nal_unit_type == NAL_IDR_W_RADL \|\| (s)->nal_unit_type == NAL_IDR_N_LP)
https://ffmpeg.org/doxygen/2.6/libavcodec_2hevc_8h.html#a0149bdce65c87e9ccee137eb54502019a5115fdfc109c53df56954e6c77ea2630

repo: bilibili/WebAV


text:
ImgClip是否能返回所有的videoFrame

v1.0.4  decodeImg 现在不能使用了，目前场景是 当类型是gif时,需要使用gif所有的videoFrame, 请问ImgClip是否能返回所有的videoFrame

用 ImgClip 循环 tick 一遍获取 VideoFrame，或者直接使用 浏览器的 ImageDecoder Api。
let ts = 0
while(true) {
  const { video, state }  = imgClip.tick(ts)
  // video 就是你要的 videoFrame
  if (state === 'done') break
  ts += 10e3 // 10ms
}

建议不要持有太多活动中的 VideoFrame（用完立即 close），因为会占用比较大的显存。

好的大佬，最终是用ImageDecoder  解决的

authors: gubeils hughfenghen


text:
How to integrage measure data?

Hi..
I have some other tools with data that I'd like to use to feed KPIs data in bamboobsc. I could both enable some kind of API, so bamboobsc could call them go pull the data, or I could create some scripts to push them into bamboobsc using its API.
I couldn't find anything that could give me a clue of what path to take. It looks like creating a new WebService could be the answer, although I'm not sure which classes I'd have to use to write measure data.
Could you give me some guidelines ? :)

In fact, publishing service become as a webService not problem.
But I  not understand that you only need  measure-data or both need KPI data need.
But bambooBSC KPI data structure not equals you tools KPI data structure. Very different.
it need Vision, Strategy-Object, formula, employee, organization, aggregation method data, ... etc
Even publishing KPI as a webService, The problem is you must do the information to be converted into bambooBSC can accept data, need you self do it.
Enable measure-data create webService step:

use Eclipse fetch bambooBSC project code on this repo.

remove remark code line for KpiWebService.java and KpiWebServiceImpl.java , to enable the two method: createKpi & measureDataSaveOrUpdate

run gsbsc-web project with Eclipse.

browser open webService info page
http://127.0.0.1:8080/gsbsc-web/services/

Test create measure data example

Bye.


text:
Send message to car & send POI from OSM

Fixes #139 and replaces #115.
Due to some merge conflicts I had to refactor @gps1539's SendPOI OSM code and while doing so implemented a abstract Message class that can be used for both standard messages (subject, 255-char message) or POIs.

Thanks!

Thanks for merging and approving :-)


text:
java.io.EOFException: null when using Aggregate Trade Streams

I'm using the BinanceApiWebSocketClient to create a local cache for the AggTrade Stream like in this example:
https://github.com/binance-exchange/binance-java-api/blob/master/src/test/java/com/binance/api/examples/AggTradesCacheExample.java
Since yesterday I'm running into a "java.io.EOFException: null". My initial thought was that I was getting disconnected by the server because I was connected for too long, but it also happened shortly after a complete server restart.
What might be the problem here?
Stacktrace:
java.io.EOFException: null 	at okio.RealBufferedSource.require(RealBufferedSource.java:60) 	at okio.RealBufferedSource.readByte(RealBufferedSource.java:73) 	at okhttp3.internal.ws.WebSocketReader.readHeader(WebSocketReader.java:113) 	at okhttp3.internal.ws.WebSocketReader.processNextFrame(WebSocketReader.java:97) 	at okhttp3.internal.ws.RealWebSocket.loopReader(RealWebSocket.java:265) 	at okhttp3.internal.ws.RealWebSocket$2.onResponse(RealWebSocket.java:204) 	at okhttp3.RealCall$AsyncCall.execute(RealCall.java:153) 	at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 	at java.lang.Thread.run(Thread.java:748)

I'm facing exactly the same issue with candlestick streams. It seems to me that it appears totally random.

Did anyone solve this? For me its sam with kline stream...

Getting this exact same stacktrace when using BinanceApiWebSocketClient. (Java 8, Debian 8)

I ended up ignoring the error and implementing a routine which periodically checks if my streams are still open and reconnects if necessary.
I'm still getting the error but it doesn't really affect my trading anymore.

I just looked through my logs and this occurred exactly 24 hours after the web sockets were initiated. Closing and reopening the connection every 23ish hours might solve this problem.

Ok, my problem was, that my client was pinging binance api and this is obviously not supported. After I disabled ping, its working fine for me.

Closing this one, the library has since been improved, to automatically deal with the client being disconnected. In any case, you should your own fail-safe methods to restart the connection whenever it fails.

authors: GabBurnett brintal joaopsilva okieven skergetd

repo: binance-exchange/binance-java-api


text:
Modify an Existing Configuration

I am currently working on a project that allows values to be written in either little or big endian form. The form of encoding is indicating by a value set inside the binary.
So basically, a simplified workflow is as follows:
parse the header -> obtain endianness information -> parse the remaining binary
I was wondering, if it would be possible to modify an existing configuration and potentially even propagate it back to the initial configuration.
So far I am obtaining the current configuration like this:

impl bincode::Decode for HeaderItem {
    fn decode<D: Decoder>(decoder: &mut D) -> Result<Self, DecodeError> {

        let config = decoder.config().to_owned();
        ...

and I am a bit lost on how to progress.

You are not able to change the config. For performance reason this should be a compile time constant.
However what you can do is split encoding/decoding in 2 steps:
let (header, len) = bincode::decode_from_slice(&slice, config::standard())?;
let slice = &slice[len..];

let data = if header.is_little_endian {
    bincode::decode_from_slice(&slice, config::standard().with_little_endian())?
} else {
    bincode::decode_from_slice(&slice, config::standard().with_big_endian())?
};

Hope this helps

Seems like I cannot prevent this then. I would have liked to avoid the extra handling coming with these functions.
One last question in this context:

You are not able to change the config. For performance reason this should be a compile time constant.

Is there any way (planned) to modify the standard configuration globally? Once I parsed the header I would know everything needed, allowing to use one global configuration that can be used in all further decodings.

Is there any way (planned) to modify the standard configuration globally
There is not, no. With our current implementation that would require duplicating everything

authors: VictorKoenders thekief

repo: bincode-org/bincode


text:
Strange Response Codes

Have been reading the code and realized response codes are kind of rare many times, returning Redirection 3xx error codes when they are actually Client Error 4xx or Server Error 5xx.
¿May I create a PR with some changes proposals?

I think it would be better to keep the error codes, also you may testing on old Ps versions..
anyway let us discuss it with you internally in channel.
Thanks David.

repo: binshops/prestashop-rest


text:
Make base images multiarch

Add support for Linux ARM64 to base-glibc-busybox-bash and base-glibc-debian-bash images.
Update the Github runners to 20.04 because the 18.04 ones never start (they stay in Queued state for days). See https://github.blog/changelog/2022-08-09-github-actions-the-ubuntu-18-04-actions-runner-image-is-being-deprecated-and-will-be-removed-by-12-1-22/
Fix warnings:

update actions/checkout to v4, so that it does not use the deprecated Nodejs v12
use >> $GITHUB_OUTPUT instead of the deprecated set-output

Multi-arch images built by my fork could be seen here:

https://github.com/martin-g/bioconda-containers/pkgs/container/base-glibc-busybox-bash
https://github.com/martin-g/bioconda-containers/pkgs/container/base-glibc-debian-bash

We are ready with the next PR for bioconda-containers - https://github.com/martin-g/bioconda-containers/pull/2/files
It depends on this PR to be merged and the new container images to be available at Quay.io. And also depends on the new bioconda-utils-build-env-cos7-aarch64 which will be provided by https://github.com/bioconda/bioconda-utils/pull/866
The new/next PR will provide images create-env-x86_64 and create-env-aarch64 (https://github.com/martin-g?tab=packages&tab=packages&q=create-)

Friendly ping!

+1 for this PR!
Looking forward for it to be merged soon!

I have never touched this repo so far, so any help with fixing the remaining issues would be greatly appreciated.

@johanneskoester Do you have an idea what is needed for https://github.com/bioconda/bioconda-containers/pull/55#issuecomment-1584422904 ?
https://quay.io/repository/bioconda/bioconda-utils-build-env-cos7-aarch64 gives 404.
The CI job for https://github.com/bioconda/bioconda-utils/pull/866 failed to publish it due to authentication issues.

@johanneskoester Do you have an idea what is needed for #55 (comment) ? https://quay.io/repository/bioconda/bioconda-utils-build-env-cos7-aarch64 gives 404. The CI job for bioconda/bioconda-utils#866 failed to publish it due to authentication issues.

Thanks for the reminder. Looking into that now. I think the bot did not have the permissions to push, but that should be solved now. Let's see whether the next release (today) succeeds.

@johanneskoester Do you have an idea what is needed for #55 (comment) ? https://quay.io/repository/bioconda/bioconda-utils-build-env-cos7-aarch64 gives 404. The CI job for bioconda/bioconda-utils#866 failed to publish it due to authentication issues.

Thanks for the reminder. Solved now and 2.5.0 has been properly pushed!

Great!
I will update this PR to use it!

I am going to merge https://github.com/martin-g/bioconda-containers/pull/2 into this PR.

Is it OK to use Debian 10 instead ?
Or should I removed the problematic entries in /etc/apt/sources.list before executing apt-get update ?

With https://github.com/bioconda/bioconda-containers/pull/55/commits/c1e64e218db6e9ae7ed238bdc09a63b671659dbd I updated sources.list to use http://archive.debian.org for the debian:9 Docker image.

Now I remember why create-env needs to be in a second step:
https://github.com/bioconda/bioconda-containers/blob/0fc3512b38661fe72575d825b919484d4324f715/images/create-env/Dockerfile#L11
here it depends on quay.io/bioconda/base-glibc-debian-bash - the ARM64 flavor of this image is created by this PR.
But this PR CI checks cannot pass because https://github.com/bioconda/bioconda-containers/blob/0fc3512b38661fe72575d825b919484d4324f715/.github/workflows/base-glibc-debian-bash.yaml#L96-L98 makes a REST API call to Quay.io that fails with error 403 (authentication) in PRs because Github secrets are not exported to PRs.

@johanneskoester Could you please allow the execution of the checks one more time? Thanks!

Hi @martin-g,
thank you (and also everyone else above!) for working on this, much appreciated.
I'm currently reviewing this (looking good thus far!) and will help to get these changes published during the next few days.
(Incidentally, Debian 12.2 is also scheduled to be released today, so we might combine updating the base images with that version. I'm doing some sanity checks for that currently.)
I'll get back to you tomorrow or Monday at the latest.
Cheers,
Marcel

Quick update:
I'm still checking and debugging some bits and bobs here.
Currently, I'm digging into why busybox wget does not work under QEMU (haven't checked on native ARM64 yet).
It's not just our build of BusyBox but also the one from docker-library (both glibc and musl) and Debian.
Alpine's one work fine (they dyn. link to musl and have a bunch of patches and custom config).
Native x86_64 work fine, too, of course.
# podman run --arch=arm64 --rm docker://arm64v8/busybox:1.36.1-glibc busybox wget -q -S --no-check-certificate https://www.busybox.net/news.html
wget: error getting response: Connection reset by peer
# podman run --arch=arm64 --rm docker://arm64v8/busybox:1.36.1-musl busybox wget -q -S --no-check-certificate https://www.busybox.net/news.html
wget: error getting response: Connection reset by peer
# podman run --arch=arm64 --rm docker://arm64v8/debian:12.1-slim sh -c 'apt-get update -qq && DEBIAN_FRONTEND=noninteractive apt-get install -qy busybox > /dev/null && busybox wget -q -S --no-check-certificate https://www.busybox.net/news.html'
debconf: delaying package configuration, since apt-utils is not installed
wget: error getting response: Connection reset by peer
# podman run --arch=arm64 --rm docker://arm64v8/alpine:3.18.4 busybox wget -q -S --no-check-certificate https://www.busybox.net/news.html
  HTTP/1.1 200 OK
  Date: Mon, 09 Oct 2023 20:46:02 GMT
  Server: Apache
  Strict-Transport-Security: max-age=63072000
  Accept-Ranges: bytes
  X-Content-Type-Options: nosniff
  X-Frame-Options: DENY
  X-XSS-Protection: 1
  Connection: close
  Transfer-Encoding: chunked
  Content-Type: text/html

# podman run --arch=amd64 --rm docker://amd64/busybox:1.36.1-glibc busybox wget -q -S --no-check-certificate https://www.busybox.net/news.html
  HTTP/1.1 200 OK
  Date: Mon, 09 Oct 2023 20:46:53 GMT
  Server: Apache
  Strict-Transport-Security: max-age=63072000
  Accept-Ranges: bytes
  X-Content-Type-Options: nosniff
  X-Frame-Options: DENY
  X-XSS-Protection: 1
  Connection: close
  Transfer-Encoding: chunked
  Content-Type: text/html

# podman run --arch=amd64 --rm docker://amd64/debian:12.1-slim sh -c 'apt-get update -qq && DEBIAN_FRONTEND=noninteractive apt-get install -qy busybox > /dev/null && busybox wget -q -S --no-check-certificate https://www.busybox.net/news.html'
debconf: delaying package configuration, since apt-utils is not installed
  HTTP/1.1 200 OK
  Date: Mon, 09 Oct 2023 20:47:25 GMT
  Server: Apache
  Strict-Transport-Security: max-age=63072000
  Accept-Ranges: bytes
  X-Content-Type-Options: nosniff
  X-Frame-Options: DENY
  X-XSS-Protection: 1
  Connection: close
  Transfer-Encoding: chunked
  Content-Type: text/html

Once that one's figured out, I'll cherry-pick your changes into multiple PRs to update the base images and then the other images.
(docker://debian:12.2 is also not out yet but likely happening in the next days; though we don't have to wait for that.)

There are many reports for busybox + wget + TLS: https://github.com/docker-library/busybox/issues?q=Connection+reset+by+peer and https://github.com/mirror/busybox/issues?q=Connection+reset+by+peer
The recommendation is to use alpine: https://github.com/docker-library/busybox/issues/64#issuecomment-510194111 and https://github.com/docker-library/busybox/issues/134#issuecomment-1122717673
$ docker run --platform=arm64 -it --rm alpine wget -S -c https://www.busybox.net/news.html

works fine!
I tried many older versions of busybox but all of them fail here.

There are many reports for busybox + wget + TLS [...]

Yes, you'd normally not want to use BusyBox's wget with TLS etc. without backing it with a well-tested TLS library (it supports using openssl s_client).

The recommendation is to use alpine [...]

For some use cases that makes sense, yes.
For us not so much. If we were to use Alpine we'd essentially have images with the size of Alpine plus our current image's size (minus the ~800 kB for BusyBox) because we want an image with glibc and Bash (which comprise most of the image's size). It's also not bad to have the two base images somewhat similar.

I just wanted to make sure that we don't introduce (avoidable) differences between the amd64 and aarch64 images.
I checked on native ARM everything works as expected too -- so all good!
(Turns out the problem is just that BusyBox expects some (not standard-mandated) behavior of vfork which QEMU doesn't meet. So, only a problem if someone runs our images via QEMU. We can easily patch that the wget applet -- no idea if other (more important) applet are affected too...)

I'm currently working on incorporating the version updates and hope we can finish the images tomorrow.

After more unfortunate delays, we are nearly there with the container builds.
gh-59 is still building bioconda/create-env currently (I need to trim down the tests for that; 10 minutes or so previous run time is north of an hour under the emulator... not very economically...).
In gh-58 I cherry-picked your commits for the base images and those are available on quay.io/bioconda (well, after fixing a little hiccup with gh-60).
There were quite some unexpected hurdles with differences under QEMU and/or aarch64, Buildah versions, bumpy manifest handling, directory layout changes in Debian 12, etc. pp.
The build scripts are, admittedly, a lengthy, under-documented, redundancy-laden mess (I'll try to rectify this in the near-ish future) -- but the image contents seem fine as far as my local inspections/tests and the CI tests show thus far.
I'll wait for one test run of gh-59 to finish and then trim down/skip some tests (at least when run via QEMU), so that we can have those built and pushed today.
We now have x86_64 and aarch64 base images updated to the current Debian/BusyBox versions (also prepared for minimal work needed for future Debian >=13 updates) available at quay.io/bioconda/base-glibc-busybox-bash:3.0and quay.io/bioconda/base-glibc-debian-bash:3.0.
Thanks very much for keeping to push this -- half a year on this PR, finally coming to fruition!

w00t!
#59 is green and (I think) fast enough!
I am going to close this PR since it is done with #58 (and #60).

authors: emiliofernandes johanneskoester martin-g mbargull

repo: bioconda/bioconda-containers


text:
Artifact can be submitted to EBI/VAMPS changes

This PR updates the DB so the columns can_be_submitted_to_(EBI/VAMPS) are in the artifact_type table instead of the artifact table.
This also fixes the plugins and the API to reflect these changes.
@squirrelo @mortonjt @ElDeveloper can any of you do a review here? This is needed by @squirrelo to keep working.

First pass through :+1:

Looks good, just a few comments.

Comments addressed - artifact-study-pages was updated but I did not pull from there here, so that's probably the cause of the issue, although is a bit weird IMO.

Hmmm I think you have to pull from the upstream artifact-study-pages,
because you branched-off from master ...
On (Jan-26-16| 9:24), Jose Navas wrote:

Comments addressed - artifact-study-pages was updated but I did not pull from there here, so that's probably the cause of the issue, although is a bit weird IMO.

Reply to this email directly or view it on GitHub:
https://github.com/biocore/qiita/pull/1617#issuecomment-175128278

Forgot to mention: the tests are expected to fail because they fail in in the artifact-study-pages branch. If there are no more comments ( @ElDeveloper , @mortonjt ) this should be ready to merge.

Sounds good!

Thanks @josenavas

authors: ElDeveloper josenavas mortonjt

repo: biocore/qiita


text:
Add details about biolink-api in demo page

In the page https://api.monarchinitiative.org/api/ we should include more details about the BioLink API. Perhaps using text from this ReadMe file https://github.com/biolink/biolink-api/blob/master/README.md
@pnrobinson suggested adding the following (see the request in the monarch-ui repo):

What is the BioLink API?
What are the things it can do?
Who is it intended for?

@deepakunni3

repo: biolink/biolink-api


text:
Check for ORCID vs wikidata duplicates and resolve

query wikidata for ORCID entries that are present in Bionomia
run merge

Found some examples:
orcid: 0000-0003-3432-2924, wikidata: Q56807897
orcid: 0000-0002-6297-7939, wikidata: Q21514374
orcid: 0000-0001-9528-287X, wikidata: Q88776149
orcid: 0000-0002-0964-0819, wikidata: Q55092351
orcid: 0000-0002-6376-4855, wikidata: Q26713308
orcid: 0000-0002-1959-6938, wikidata: Q21391567
orcid: 0000-0002-0221-9650, wikidata: Q36643042
orcid: 0000-0002-0141-4999, wikidata: Q21502980
orcid: 0000-0001-9675-1498, wikidata: Q112057278
Some of these require careful handling so as not to be recreated from their sources. For example, this one https://www.gbif.org/occurrence/3802236862 has both an ORCID and a wikidata entity URI in dwc:recordedByID used for a single agent string in dwc:recordedBy and dwc:identifiedBy.

repo: bionomia/bionomia


text:
feat(simulators-api): add a query argument to include the results of …

…the validation
BREAKING CHANGE: validation data is no longer returned by default. A Query argument is needed to include the validation information
closes #2668

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

repo: biosimulations/Biosimulations


text:
Document new REST API schemas

https://api.biosimulations.dev
Examples

/files/{simId}
/specifications/{simId}

Added documentation in #3241. Created issues for remaining minor gaps in documentation.

repo: biosimulations/biosimulations


text:
move 're-run' outside of the box

Right now, the 'customize and re-run' button is inside the box in the right frame, which puts a tab menu below it, which I think is weird:

Instead, I would put that button above and to the right of that column of information, and then the tabs for the box would be at the top, where people expect them to be.

I temporarily removed this button as it simply displays an 'under dev' message currently. I am currently developing this functionality and will re-implement this button at full-functionality.

authors: AlexPatrie luciansmith


text:
Submit OpenCOR 2021-09-14

id: opencor
version: "2021-09-14"
specificationsUrl: https://raw.githubusercontent.com/biosimulators/Biosimulators_OpenCOR/d70d6149d278b3a451bf75ede7390a5262ec42e5/biosimulators.json
specificationsPatch:
version: "2021-09-14"
image:
url: ghcr.io/biosimulators/biosimulators_opencor/opencor:2021-09-14
validateImage: true
commitSimulator: true

Thank you @biosimulators-daemon for your submission to the BioSimulators simulator validation/submission system!
The BioSimulators validator bot is validating the specifications of your simulator, validating your Docker image, and committing your simulator to the BioSimulators registry.
We will discuss any concerns with your submission in this issue.
A complete log of your simulator submission job will be available for 90 days here. The results of the validation of your tool will also be saved as a JSON file. A link to this file will be available for 90 days from the "Artifacts" section at the bottom of this page.

The validation/submission of your simulator failed.
- The simulator specifications from `https://raw.githubusercontent.com/biosimulators/Biosimulators_OpenCOR/d70d6149d278b3a451bf75ede7390a5262ec42e5/biosimulators.json` are invalid. The specifications of simulation tools must adhere to BioSimulators' schema. BioSimulators' schema is available in both JSON Schema and Open API Specifications formats. Documentation is available at https://api.biosimulators.org/.
-
-   - Database ValidatorError (500): `/pythonApi/installationInstructions` is invalid
-
-       'installationInstructions' attribute must be defined

The complete log of your validation/submission job, including further information about the failure, is available for 90 days here.
If you chose to validate your Docker image, the results of the validation of your image will be available shortly as a JSON file. A link to this file will be available for 90 days from the "Artifacts" section at the bottom of this page.
Once you have fixed the problem, edit the first block of this issue to re-initiate this validation.
The BioSimulators Team is happy to help. Questions and feedback can be directed to the BioSimulators Team by posting comments to this issues that reference the GitHub team @biosimulators/biosimulators (without the backticks).

OpenCOR hasn't yet be updated for enhanced simulator specifications.
This will be fixed in the next submission.

authors: biosimulators-daemon jonrkarr

repo: biosimulators/Biosimulators


text:
json parse error fix + heap summary response

This PR just fixes some small bugs like

[x] expired spark profile + bad spark link
[x] if a user gives a heap summary report link it lets them know its not supported
[x] bot thinking spark download/doc link is a profiler report

Looks good, thanks for the pull

repo: birdflop/botflop


text:
Upgrade to V2.0

fix #81
TODO V2 migration:

[x] crypto update
[ ] sealed tokens
[x] scoped rules
[x] removing the Symbol type
[x] use the block signature as revocation id
[x] rename ID to Term
[x] add an enum indicating the key's type
[x] rename verifier to authorizer
[ ] update the parser to the latest grammar

TODO things to fix:

[x] checking that pointer issue in protobuf for all other fields
[x] checking that the deserialized keys are 32 byte arrays
[ ] reintroduce the sig module: we'll need an abstraction over the key when we start supporting multiple algorithms
[ ] verify signatures in Unmarshal: v1 was verifying the signatures while deserializing, and the Verify method was only checking that the root key is the expected one. Now Unmarshal only parses, while Verify checks the signature. In other implementations like rust, we parse and check the signature in the same step, an creating the authorizer does not need to check anything (the rust lib also has  UnverifiedBiscuit type, to be able to print or attenuate a token without checking the signature, it's a specific type that does not allow creating a verifier without checking the signature)
[ ] check that intersection and union are implemented

signatures verify properly :partying_face:
I'm encountering issues in c0cad49 due to the way optional fields are serialized by protobuf. It uses pointers to represent them:
https://github.com/biscuit-auth/biscuit-go/pull/82/files#diff-c7507070ba25194410b4afae59dde5ab3743a0b1a23a33f87c4f5551cfa8756bR460
I tried using the methods provided by the proto package:
https://github.com/biscuit-auth/biscuit-go/pull/82/files#diff-75f279e5e9b923a88737f5ed1726cc2ef4f36e574c2d5a1ebf711df86c77e441R16
but it still serializes a pointer, not the value

now all tests pass. Next step: scoped rules

scoped rules are implemented, and I updated a bit the checks and rules printing. The last big chunk of the migration is removing the symbol type. The rest comes easily

the parser should be working now, but I still need to reactivate and convert all the parser tests from the old constraints to the new stack base expressions

I'm encountering an issue with the .matches() operation, where the parser apparently only sees match as a token, then es as a separate one

repo: biscuit-auth/biscuit-go


text:
head_mover sometimes dies randomly

The head mover sometimes dies randomly with a segmentation fault. There is no helpful error message, so we will have to investigate some more.
I think it said "Looking at point" very often, then "Received goal request" once, then "Looking at point" a few times, then it died.
When the head mover is dead, the behavior is not doing anything because it is waiting for the head mover service.

Will close this now, as we did not reproduce this behavior since and the code has been refactored, which might have resolved this issue.

authors: jaagut timonegk


text:
Trezor: it should be possible to use an empty passphrase

In case a user enters empty passphrase on Trezor, it should work and a passphrase-less wallet should be open (the same as on a Trezor with passphrase protection off).
It seems that HWI disallows empty passphrases leading to confusions such as:

https://github.com/cryptoadvance/specter-desktop/issues/1946
https://github.com/sparrowwallet/sparrow/issues/240

@achow101 - any update / input on this from your side?

It's not clear to me what the actual issue is, can you provide a reproduction for HWI?
I don't see anything in HWI that prevents using the empty passphrase. It's not explicitly disallowed; it should just be passing the empty passphrase straight through to the device.

@moneymanolis Can you test #644

Will do asap. Thanks for responding so quickly with a PR.

Initial testing results @achow101:
On hwi master this does NOT work:
./hwi.py -t "trezor" -d "webusb:020:2:4" --password "" enumerate
Result is:
[{"type": "trezor", "path": "webusb:020:2:4", "label": "temp", "model": "trezor_1", "needs_pin_sent": false, "needs_passphrase_sent": true, "error": "Could not open client or get fingerprint information: Passphrase needs to be specified before the fingerprint information can be retrieved", "code": -12}]
On https://github.com/bitcoin-core/HWI/pull/644 it works, result is sth. like:
[{"type": "trezor", "path": "webusb:020:2:4", "label": "temp", "model": "trezor_1", "needs_pin_sent": false, "needs_passphrase_sent": false, "fingerprint": "59967cfd"}]
Just as a sidenote if you send the pin and then go straight to signtx: master and #644 work. My expectation was, that I'd had to provide the (empty) passphrase. But okay.
I am working now on testing #644 in conjunction with Specter.

But if I run ./hwi.py -t "trezor" -d "webusb:020:2:4" enumerate
I get [{"type": "trezor", "path": "webusb:020:2:4", "label": "temp", "model": "trezor_1", "needs_pin_sent": false, "needs_passphrase_sent": true, "error": "Could not open client or get fingerprint information: Passphrase needs to be specified before the fingerprint information can be retrieved", "code": -12}] on #644
Shouldn't that work?

Not necessarily. I think that's just an issue of what users expect. Do they expect it to work if passphrase protection is enabled but no passphrase is provided? Or should they expect to always need to provide a passphrase, even if it's the empty string?
I guess either way the behavior should be unified as it currently is not as you point out.

@matejcik Can you weigh in and tell us what is the behaviour that makes most sense (so it is aligned with how we do stuff in python-trezor/trezorctl/Suite)?

Using those changes in Specter https://github.com/cryptoadvance/specter-desktop/pull/1977 and the PR from hwi (https://github.com/bitcoin-core/HWI/pull/644) works for me!

We have a bunch of Specter Desktop users who at some point had the passphrase feature enabled but didn't use it in the sense that they used an empty string only. Technically, and the Trezor teams knows this much better, the part of  the PBKDF2 function (the salt part) from BIP39 where the passphrase goes is never really empty. It is always filled with the string "mnemonic" and if there is a passphrase this string is concatenated with the passphrase. So, I'd say the passphrase can only be an empty string or a non-empty string.

what is the behaviour that makes most sense (so it is aligned with how we do stuff in python-trezor/trezorctl/Suite)?

Right now there's actually a split between trezorctl and Suite.
trezorctl does the easy thing and if passphrase is enabled, always asks for it.
Suite enables passphrase by default even for people who never use the hidden wallet feature. By selecting the "default wallet", you auto-open the "" passphrase.
The Suite behavior is the more correct one UX-wise. So I believe that if the passphrase is not explicitly specified, HWI should default to the "" passphrase.

authors: achow101 matejcik moneymanolis prusnak

repo: bitcoin-core/HWI


text:
Make RPC console welcome message translation-friendly

The best practice is do not split a translatable multi-line message into single lines. This helps translators to follow the context.

Updated b00aaf6134daefd16a1ff5804a8cb45f6f223392 -> a596381c7244157d15063a1c590a993045ab5179 (pr331.01 -> pr331.02, diff):

addressed @jarolrod's comments

Updated a596381c7244157d15063a1c590a993045ab5179 -> 67bef11e57f12ceacd3810008914c33b37c3c5bf (pr331.02 -> pr331.03, diff):

addressed @jarolrod's comment

Seeing no reason to use QString optimization tricks as the welcome_message is static now.

re-ACK 67bef11e57f12ceacd3810008914c33b37c3c5bf

re-ack 0f3d955a38fe59a4e8cc4bf9f4442e6e1fd8bcbb

@goums @Talkless Do you mind reviewing this PR?

authors: hebasto jarolrod

repo: bitcoin-core/gui


text:
Add coinshuffle-plusplus-part-2 review to wasabi/research-club

This PR adds coinshuffle-plusplus-part-2 transcript review to the wasabi/research-club directory.

Hey @Musab1258,
Thank you for your contribution! I really appreciate your attention to detail.
I’ve made a few adjustments that you can review to help avoid similar issues in the future. Apologies for the delay in getting back to you—we're working on providing faster feedback going forward.
Keep up the great work, and thanks again for your effort!

repo: bitcointranscripts/bitcointranscripts


text:
Format for direct publication

When thinking about the use case for gotestdox as something that can do part of the documentation, have there been any thought about changing the output format to be something  like markdown? That would enable easy publication of the results for stakeholders etc. to keep track of what a software suite supports.

Well, that sounds like a good idea, but I'm not sure we need to do anything special for gotestdox output to be usable in Markdown documents. This comment is formatted in Markdown, and I've pasted some output in directly:
github.com/bitfield/shift:
✔ BlockSize returns block size (0.00s)
✔ Decrypt (0.00s)
✔ Decrypt 010203040506 - 0101010101010101010101010101010101010101010101010101010101010101 = 000102030405 (0.00s)
✔ Decrypter crypt blocks (0.00s)
✔ Encrypt (0.00s)
✔ Encrypt 000102030405 + 0101010101010101010101010101010101010101010101010101010101010101 = 010203040506 (0.00s)
✔ Encrypter enciphers block aligned message (0.00s)
✔ NewCipher gives err key size for invalid key (0.00s)
✔ NewCipher gives no error for valid key (0.00s)
✔ Pad (0.00s)
✔ Pad 1 short of full block (0.00s)
✔ Pad 2 short of full block (0.00s)
✔ Pad 3 short of full block (0.00s)
✔ Pad empty block (0.00s)
✔ Pad full block (0.00s)
✔ Unpad (0.00s)
✔ Unpad 1 short of full block (0.00s)
✔ Unpad 2 short of full block (0.00s)
✔ Unpad 3 short of full block (0.00s)
✔ Unpad empty block (0.00s)
✔ Unpad full block (0.00s)
It looks fine! What other formatting would you suggest?

Looks pretty good, especially in a terminal. And I must agree I was a bit unclear :see_no_evil:. Lets put the text you pasted into dillinger (online markdown editor) and it looks like this:

What I was thinking was to use some more of the refinement you can use with a doc format such as markdown (not married to markdown though) to make it closer whats described for agiledox. A simple example could be to simply add each package as a sub header and perhaps some collective information as the last output in package like
## github.com/bitfield/shift:
 ✔ BlockSize returns block size (0.00s)
 ✔ Crack (0.01s)
 ✔ Decrypt (0.00s)
 ✔ Decrypt 010203040506 - 0101010101010101010101010101010101010101010101010101010101010101 = 000102030405 (0.00s)
 ✔ Decrypter crypt blocks (0.00s)
 ✔ Encrypt (0.00s)
 ✔ Encrypt 000102030405 + 0101010101010101010101010101010101010101010101010101010101010101 = 010203040506 (0.00s)
 ✔ Encrypter enciphers block aligned message (0.00s)
 ✔ NewCipher gives err key size for invalid key (0.00s)
 ✔ NewCipher gives no error for valid key (0.00s)
 ✔ Pad (0.00s)
 ✔ Pad 1 short of full block (0.00s)
 ✔ Pad 2 short of full block (0.00s)
 ✔ Pad 3 short of full block (0.00s)
 ✔ Pad empty block (0.00s)
 ✔ Pad full block (0.00s)
 ✔ Unpad (0.00s)
 ✔ Unpad 1 short of full block (0.00s)
 ✔ Unpad 2 short of full block (0.00s)
 ✔ Unpad 3 short of full block (0.00s)
 ✔ Unpad empty block (0.00s)
 ✔ Unpad full block (0.00s)
 **Test coverage xx%**

That would be parsed in Dillinger like

Should also note that I'm just using Dillinger to make it easy to test for anyone checking this out, but the general formatting is pretty similar across tools.

It is possible to use go-test-report, to generate HTML documens and to generate markdown (with a PR)

authors: Jumziey afbjorklund bitfield

repo: bitfield/gotestdox