Mitigate Miri violation

While testing an embassy project on Windows using Miri, I encountered a hard-to-diagnose violation involving a conflict between writing to and dropping critical-section's GLOBAL_GUARD.
I believe the change proposed in this PR is low-risk and should work exactly the same as before while appeasing Miri and potentially mitigating a program bug.
Minimal project to produce Miri complaint:
Cargo.toml:
// ...
[dependencies]
embassy-executor = { version = "0.5.0", features = ["task-arena-size-131072", "arch-std", "executor-thread", "integrated-timers"] }
embassy-time = { version = "0.3.0", features = ["std"] }

main.rs:
#[embassy_executor::main]
async fn main(_spawner: embassy_executor::Spawner) {
    loop {
        embassy_time::Timer::after_millis(1000).await;
    }
}

Miri command (on Windows): cargo +nightly-2024-04-10 miri run
Sample output:
error: Undefined Behavior: not granting access to tag <39012> because that would remove [Unique for <38804>] which is strongly protected because it is an argument of call 8084
   --> C:\...\lib\rustlib\src\rust\library\core\src\mem\maybe_uninit.rs:493:24
    |
493 |     pub const fn write(&mut self, val: T) -> &mut T {
    |                        ^^^^^^^^^ not granting access to tag <39012> because that would remove [Unique for <38804>] which is strongly protected because it is an argument of call 8084

interesting.
do you have some understanding/explanation for why the original code causes a miri error and the change doesn't? Miri doesn't have false positives, so if the original code fails we definitely should fix it. However, it does have false negatives, so it's possible if we do this change without fully understanding why the original is bad and the new is good, we're just randomly changing the code to mask the issue (false negative) instead of actually fixing it.

Hi. I was looking at this with @Catamantaloedis earlier today, and had suggested that change on a hunch.
Without having a completely solid grasp of Rust's semantics in this area, my guess is that it comes down to assume_init_drop being an in-place drop, and the need for drop to hold exclusive mutable access to what is being dropped. In this case, dropping a MutexGuard unlocks the mutex during the drop, but the &mut bound to the MutexGuard lives on for the entirety of the drop operation. This means that there's a portion of execution (if not in practice, then at least semantically) where the mutex is unlocked but an &mut reference to the contents of GLOBAL_GUARD is still alive, which is "racy" insofar as that the mutex is itself being used to synchronize access to GLOBAL_GUARD.
The "fix" was based on the observation that there's no need to actually do the drop in-place; the drop is just for its side-effect of unlocking the mutex, and not for any mutation it may or may not perform to the guard object itself. The change to
let _ = GLOBAL_GUARD.assume_init_read();

means that the drop is instead performed on a temporary loaded out of GLOBAL_GUARD, so there's never a mutating reference bound to GLOBAL_GUARD in the first place.

I can't reproduce this, Miri is giving an ICE...

Can you post the full miri error?
Do you have a more reduced version to trigger this, that doesn't depend on embassy crates?

I'm hitting the same UB report on Linux too.

I can't reproduce this, Miri is giving an ICE...

Miri has a bug for clock for now. See https://github.com/rust-lang/miri/issues/3647 (with reproducible code in there but on top of embassy).
So miri should be run in host system environment instead of faked one via
MIRIFLAGS="-Zmiri-disable-isolation" cargo miri run

Full error with 1 sec tick
embassy-local ✗ MIRIFLAGS="-Zmiri-disable-isolation" cargo miri run
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.04s
     Running `/root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/cargo-miri runner target/miri/x86_64-unknown-linux-gnu/debug/embassy-local`
[2024-06-05T02:15:37Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:15:38Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:15:39Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:15:40Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:15:41Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:15:42Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:15:43Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:15:45Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:15:46Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:15:47Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:15:48Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:15:49Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:15:50Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:15:51Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:15:52Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:15:54Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:15:55Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:15:56Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:15:57Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:15:58Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:15:59Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:16:00Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:16:02Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:16:03Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:16:04Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:16:05Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:16:06Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:16:07Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:16:08Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:16:10Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:16:11Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:16:12Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:16:13Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:16:14Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:16:15Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:16:16Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:16:17Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:16:19Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:16:20Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:16:21Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:16:22Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:16:23Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:16:24Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:16:25Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:16:27Z INFO  embassy_local] tick for 1 sec
[2024-06-05T02:16:28Z INFO  embassy_local] tick for 1 sec
error: Undefined Behavior: not granting access to tag <1457496> because that would remove [Unique for <1457358>] which is strongly protected because it is an argument of call 310298
   --> /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/mem/maybe_uninit.rs:493:24
    |
493 |     pub const fn write(&mut self, val: T) -> &mut T {
    |                        ^^^^^^^^^ not granting access to tag <1457496> because that would remove [Unique for <1457358>] which is strongly protected because it is an argument of call 310298
    |
    = help: this indicates a potential bug in the program: it performed an invalid operation, but the Stacked Borrows rules it violated are still experimental
    = help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information
help: <1457496> was created by a SharedReadWrite retag at offsets [0x0..0x10]
   --> /root/.cargo/registry/src/rsproxy.cn-0dccff568467c15b/critical-section-1.1.2/src/std.rs:38:13
    |
38  |             GLOBAL_GUARD.write(guard);
    |             ^^^^^^^^^^^^
help: <1457358> is this argument
   --> src/main.rs:20:1
    |
20  | #[embassy_executor::main]
    | ^^^^^^^^^^^^^^^^^^^^^^^^^
    = note: BACKTRACE (of the first span) on thread `unnamed-1`:
    = note: inside `std::mem::MaybeUninit::<std::sync::MutexGuard<'_, ()>>::write` at /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/mem/maybe_uninit.rs:493:24: 493:33
    = note: inside closure at /root/.cargo/registry/src/rsproxy.cn-0dccff568467c15b/critical-section-1.1.2/src/std.rs:38:13: 38:38
    = note: inside `std::thread::LocalKey::<std::cell::Cell<bool>>::try_with::<{closure@<critical_section::std::StdCriticalSection as critical_section::Impl>::acquire::{closure#0}}, bool>` at /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:286:12: 286:27
    = note: inside `std::thread::LocalKey::<std::cell::Cell<bool>>::with::<{closure@<critical_section::std::StdCriticalSection as critical_section::Impl>::acquire::{closure#0}}, bool>` at /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:262:9: 262:25
    = note: inside `<critical_section::std::StdCriticalSection as critical_section::Impl>::acquire` at /root/.cargo/registry/src/rsproxy.cn-0dccff568467c15b/critical-section-1.1.2/src/std.rs:18:9: 41:11
    = note: inside `critical_section::std::_critical_section_1_0_acquire` at /root/.cargo/registry/src/rsproxy.cn-0dccff568467c15b/critical-section-1.1.2/src/lib.rs:282:13: 282:44
    = note: inside `critical_section::acquire` at /root/.cargo/registry/src/rsproxy.cn-0dccff568467c15b/critical-section-1.1.2/src/lib.rs:183:18: 183:49
    = note: inside `critical_section::with::<u64, {closure@embassy_time::driver_std::TimeDriver::alarm_thread::{closure#0}}>` at /root/.cargo/registry/src/rsproxy.cn-0dccff568467c15b/critical-section-1.1.2/src/lib.rs:226:26: 226:35
    = note: inside `embassy_time::driver_std::TimeDriver::alarm_thread` at /root/.cargo/registry/src/rsproxy.cn-0dccff568467c15b/embassy-time-0.3.0/src/driver_std.rs:72:30: 103:15
    = note: inside `<fn() {embassy_time::driver_std::TimeDriver::alarm_thread} as std::ops::FnOnce<()>>::call_once - shim(fn() {embassy_time::driver_std::TimeDriver::alarm_thread})` at /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5: 250:71
    = note: inside `std::sys_common::backtrace::__rust_begin_short_backtrace::<fn() {embassy_time::driver_std::TimeDriver::alarm_thread}, ()>` at /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:155:18: 155:21
    = note: inside closure at /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/mod.rs:542:17: 542:78
    = note: inside `<std::panic::AssertUnwindSafe<{closure@std::thread::Builder::spawn_unchecked_<'_, '_, fn() {embassy_time::driver_std::TimeDriver::alarm_thread}, ()>::{closure#2}::{closure#0}}> as std::ops::FnOnce<()>>::call_once` at /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/panic/unwind_safe.rs:272:9: 272:19
    = note: inside `std::panicking::r#try::do_call::<std::panic::AssertUnwindSafe<{closure@std::thread::Builder::spawn_unchecked_<'_, '_, fn() {embassy_time::driver_std::TimeDriver::alarm_thread}, ()>::{closure#2}::{closure#0}}>, ()>` at /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:559:40: 559:43
    = note: inside `std::panicking::r#try::<(), std::panic::AssertUnwindSafe<{closure@std::thread::Builder::spawn_unchecked_<'_, '_, fn() {embassy_time::driver_std::TimeDriver::alarm_thread}, ()>::{closure#2}::{closure#0}}>>` at /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:523:19: 523:88
    = note: inside `std::panic::catch_unwind::<std::panic::AssertUnwindSafe<{closure@std::thread::Builder::spawn_unchecked_<'_, '_, fn() {embassy_time::driver_std::TimeDriver::alarm_thread}, ()>::{closure#2}::{closure#0}}>, ()>` at /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:149:14: 149:33
    = note: inside closure at /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/mod.rs:541:30: 543:16
    = note: inside `<{closure@std::thread::Builder::spawn_unchecked_<'_, '_, fn() {embassy_time::driver_std::TimeDriver::alarm_thread}, ()>::{closure#2}} as std::ops::FnOnce<()>>::call_once - shim(vtable)` at /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5: 250:71
    = note: inside `<std::boxed::Box<dyn std::ops::FnOnce()> as std::ops::FnOnce<()>>::call_once` at /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:2063:9: 2063:52
    = note: inside `<std::boxed::Box<std::boxed::Box<dyn std::ops::FnOnce()>> as std::ops::FnOnce<()>>::call_once` at /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:2063:9: 2063:52
    = note: inside `std::sys::pal::unix::thread::Thread::new::thread_start` at /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/pal/unix/thread.rs:108:17: 108:64
    = note: this error originates in the attribute macro `embassy_executor::main` (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to 1 previous error

I tried to make backtrace readable as below
std::mem::MaybeUninit::<std::sync::MutexGuard<'_, ()>>::write
    /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/mem/maybe_uninit.rs:493:24: 493:33
closure
    /root/.cargo/registry/src/rsproxy.cn-0dccff568467c15b/critical-section-1.1.2/src/std.rs:38:13: 38:38
std::thread::LocalKey::<std::cell::Cell<bool>>::try_with::<{closure@<critical_section::std::StdCriticalSection as critical_section::Impl>::acquire::{closure#0}}, bool>
    /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:286:12: 286:27
std::thread::LocalKey::<std::cell::Cell<bool>>::with::<{closure@<critical_section::std::StdCriticalSection as critical_section::Impl>::acquire::{closure#0}}, bool>
    /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:262:9: 262:25
<critical_section::std::StdCriticalSection as critical_section::Impl>::acquire
    /root/.cargo/registry/src/rsproxy.cn-0dccff568467c15b/critical-section-1.1.2/src/std.rs:18:9: 41:11
critical_section::std::_critical_section_1_0_acquire
    /root/.cargo/registry/src/rsproxy.cn-0dccff568467c15b/critical-section-1.1.2/src/lib.rs:282:13: 282:44
critical_section::acquire
    /root/.cargo/registry/src/rsproxy.cn-0dccff568467c15b/critical-section-1.1.2/src/lib.rs:183:18: 183:49
critical_section::with::<u64, {closure@embassy_time::driver_std::TimeDriver::alarm_thread::{closure#0}}>
    /root/.cargo/registry/src/rsproxy.cn-0dccff568467c15b/critical-section-1.1.2/src/lib.rs:226:26: 226:35
embassy_time::driver_std::TimeDriver::alarm_thread
    /root/.cargo/registry/src/rsproxy.cn-0dccff568467c15b/embassy-time-0.3.0/src/driver_std.rs:72:30: 103:15
<fn() {embassy_time::driver_std::TimeDriver::alarm_thread} as std::ops::FnOnce<()>>::call_once - shim(fn() {embassy_time::driver_std::TimeDriver::alarm_thread})
    /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5: 250:71
std::sys_common::backtrace::__rust_begin_short_backtrace::<fn() {embassy_time::driver_std::TimeDriver::alarm_thread}, ()>
    /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:155:18: 155:21
closure
    /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/mod.rs:542:17: 542:78
<std::panic::AssertUnwindSafe<{closure@std::thread::Builder::spawn_unchecked_<'_, '_, fn() {embassy_time::driver_std::TimeDriver::alarm_thread}, ()>::{closure#2}::{closure#0}}> as std::ops::FnOnce<()>>::call_once
    /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/panic/unwind_safe.rs:272:9: 272:19
std::panicking::r#try::do_call::<std::panic::AssertUnwindSafe<{closure@std::thread::Builder::spawn_unchecked_<'_, '_, fn() {embassy_time::driver_std::TimeDriver::alarm_thread}, ()>::{closure#2}::{closure#0}}>, ()>
    /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:559:40: 559:43
std::panicking::r#try::<(), std::panic::AssertUnwindSafe<{closure@std::thread::Builder::spawn_unchecked_<'_, '_, fn() {embassy_time::driver_std::TimeDriver::alarm_thread}, ()>::{closure#2}::{closure#0}}>>
    /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:523:19: 523:88
std::panic::catch_unwind::<std::panic::AssertUnwindSafe<{closure@std::thread::Builder::spawn_unchecked_<'_, '_, fn() {embassy_time::driver_std::TimeDriver::alarm_thread}, ()>::{closure#2}::{closure#0}}>, ()>
    /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:149:14: 149:33
closure
    /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/mod.rs:541:30: 543:16
<{closure@std::thread::Builder::spawn_unchecked_<'_, '_, fn() {embassy_time::driver_std::TimeDriver::alarm_thread}, ()>::{closure#2}} as std::ops::FnOnce<()>>::call_once - shim(vtable)
    /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5: 250:71
<std::boxed::Box<dyn std::ops::FnOnce()> as std::ops::FnOnce<()>>::call_once
    /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:2063:9: 2063:52
<std::boxed::Box<std::boxed::Box<dyn std::ops::FnOnce()>> as std::ops::FnOnce<()>>::call_once
    /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:2063:9: 2063:52
std::sys::pal::unix::thread::Thread::new::thread_start
    /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/pal/unix/thread.rs:108:17: 108:64

It basically says aliasing rules are violated. I agree with @distractedlambda that there are two mutable/exclusive reference caused by dropping, because when I tuned the tick frequency to 10 ms, miri points out drop removes Unique tag.
embassy-local ✗ MIRIFLAGS="-Zmiri-disable-isolation" cargo miri run
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.43s
     Running `/root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/cargo-miri runner target/miri/x86_64-unknown-linux-gnu/debug/embassy-local`
[2024-06-05T03:46:58Z INFO  embassy_local] tick for 10 millis
[2024-06-05T03:46:58Z INFO  embassy_local] tick for 10 millis
[2024-06-05T03:46:59Z INFO  embassy_local] tick for 10 millis
[2024-06-05T03:46:59Z INFO  embassy_local] tick for 10 millis
[2024-06-05T03:46:59Z INFO  embassy_local] tick for 10 millis
[2024-06-05T03:46:59Z INFO  embassy_local] tick for 10 millis
[2024-06-05T03:46:59Z INFO  embassy_local] tick for 10 millis
[2024-06-05T03:46:59Z INFO  embassy_local] tick for 10 millis
[2024-06-05T03:47:00Z INFO  embassy_local] tick for 10 millis
[2024-06-05T03:47:00Z INFO  embassy_local] tick for 10 millis
[2024-06-05T03:47:00Z INFO  embassy_local] tick for 10 millis
[2024-06-05T03:47:00Z INFO  embassy_local] tick for 10 millis
[2024-06-05T03:47:00Z INFO  embassy_local] tick for 10 millis
[2024-06-05T03:47:00Z INFO  embassy_local] tick for 10 millis
[2024-06-05T03:47:00Z INFO  embassy_local] tick for 10 millis
[2024-06-05T03:47:01Z INFO  embassy_local] tick for 10 millis
[2024-06-05T03:47:01Z INFO  embassy_local] tick for 10 millis
error: Undefined Behavior: not granting access to tag <526578> because that would remove [Unique for <526360>] which is strongly protected because it is an argument of call 112396
   --> /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/mem/maybe_uninit.rs:493:24
    |
493 |     pub const fn write(&mut self, val: T) -> &mut T {
    |                        ^^^^^^^^^ not granting access to tag <526578> because that would remove [Unique for <526360>] which is strongly protected because it is an argument of call 112396
    |
    = help: this indicates a potential bug in the program: it performed an invalid operation, but the Stacked Borrows rules it violated are still experimental
    = help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information
help: <526578> was created by a SharedReadWrite retag at offsets [0x0..0x10]
   --> src/main.rs:20:1
    |
20  | #[embassy_executor::main]
    | ^^^^^^^^^^^^^^^^^^^^^^^^^
help: <526360> is this argument
   --> /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sync/mutex.rs:548:13
    |
548 |     fn drop(&mut self) {
    |             ^^^^^^^^^
    = note: BACKTRACE (of the first span):
    = note: inside `std::mem::MaybeUninit::<std::sync::MutexGuard<'_, ()>>::write` at /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/mem/maybe_uninit.rs:493:24: 493:33
    = note: inside closure at /root/.cargo/registry/src/rsproxy.cn-0dccff568467c15b/critical-section-1.1.2/src/std.rs:38:13: 38:38
    = note: inside `std::thread::LocalKey::<std::cell::Cell<bool>>::try_with::<{closure@<critical_section::std::StdCriticalSection as critical_section::Impl>::acquire::{closure#0}}, bool>` at /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:286:12: 286:27
...

With the code in this PR, miri doesn't complain any more.


Exchange edges

Follow-up to #477.
Here is a rework of internal node communication patterns. It should significantly reduce traffic and CPU consumption of the nodes in a steady state and make it scale better. Surely, the PR is huge, but unfortunately it turned out to be impractical to divide it into the smaller ones, as all the features play well just being implemented together.
Here is the outline:

Internal communication protocol for ThreadsDB nodes extended with a new call ExchangeEdges. New method enables efficient checks if thread information is in sync between any two nodes, using heads/address edges (digest), and is a replacement for continuous pulling with GetRecords. It also helps to reduce communication overhead with both synced and inactive peers.
Now all calls to GetLogs/GetRecords are grouped by peers and performed through the corresponding queues, thus deduplicating and distributing peer calls over the time.
Address edge computation implemented - deterministic digest of all peer addresses involved into the thread (similar to heads edge).
Multiple minor fixes and improvements.

New communication logic is fully compatible with an older nodes, as it fallbacks to the GetRecords-based pulling if peer is lacking support of ExchangeEdges.

Ok folks, I've given this a thrice-over, but to be honest, I didn't do a deep dive on all the updates here. I'm also happy to merge mostly as is, though I do really like @eightysteele's suggestion of some doc strings that outline the algorithm used in net/queue/ff.go, so I'd like to see that updated before we merge. Otherwise, I'm keen to just play around with this and see how it behaves.


Adding information about Kibana and dashboards.

Addressing issue #9 and #10.
@chuckbutler will notice I changed "grab" to "download"
@arosales Please let me know if this resolves your issues.

@mbruzek Thanks for these updates to help improve the user experience. My issues #9 and #10 look to be resolved in this pull request with other fixes.
Also thanks for taking the opportunity to clean up other bits in the Readme while you were in there.


Allow us to turn security on/off at will

And if turned on, choose a different user/group
Fixed the formatting of the preferred affinity to be indented to the correct level.

@k8s-ci-robot CLA signed.

@fhemberger Fixed all of the spacing issues, to match the desired format.

@mlaccetti Cool, thanks!

@mlaccetti @fhemberger not sure whats going on but way too many files have changed in this PR. Can you see if you can fix it?

@mlaccetti Oh, I only meant to fix the whitespace for your zookeeper changes, not for the entire repo (that change has already been merged).

@fhemberger Can you please fix this PR so only Zookeeper-related changes are in?

@unguiculus Oh, I would if it was my PR. 😀  I only suggested changes.
@mlaccetti Can you please check the PR again?

@fhemberger Of course, sorry, I was confused.

@fhemberger @unguiculus Let me figure out where all the extra changes came from and address that.

@unguiculus The changes were there since my branch was out of date.  Fixed, and we're back to just the two changes. :)

/ok-to-test

@unguiculus looks like the automated deployment isn't happy - might be due to PVCs not being provisioned, etc. How do you want to handle this?

Sorry for the delay, I was on vacation. Can you fix the conflicts, please?

  Let me try to fix.

Marking this as stale. Please update PR within one week. Also, note that there is a problem with the CLA.

I fixed the history for you.

/cc @lachie83 @kow3ns

Reset author.


Entry favorite count & more

Refactored the settings route by moving default cookie key/value pairs to DEFAULT_COOKIES.
Refactored the entries by unifying entry templates from both "topic.html," and "entry.html" to a macro at "entry_macro.html," thus reducing repetition.
Added an option to display favorite counts of entries obtained from "data-favorite-count."
Fixed a bug that causes şükela to deselect when using navigation.
Other minor stuff.

Wow this changes are awesome. I trying before merging. Also can you upgrade version to 0.7.0.

Done.

Thanks for contribute.


Better Color Scheme

Make a better color scheme
Currently the website could look a bit better as it's currently just green and stuff (which is quite goofy)

I don't think the color scheme is an issue, it's just that the design itself is basic. We could work on animations/cool effects or add actually content then change things up. I do think that we should modify the color scheme but not yet.

I agree with that partially so I'm going to rename the issue to be more general about the website's design and how we can improve it

https://github.com/Mr-Ben-Merch-Store/Website/commit/9c772abc9d1748b11416976b7531bb07bf224698
current commit

I might go work on some animations later.

Linked to https://github.com/Mr-Ben-Merch-Store/Website/pull/88

Linked to #99


finos/a11y-theme-builder#876: adding support for prettier

Took code that @ravjot07 originally put in to make prettier work, so he should get credit for this!  I'm just pushing it through.

Question - will a precommit hook be implemented to run prettier on changed files? Or should that be a separate issue?

Holding off on review until Aaron is back to answer the above question.

I'm fine with a precommit hook

@kburk1997 I was looking at pre-commit hooks in Git.  Particularly how to get them to work with a GitHub repo: https://stackoverflow.com/questions/427207/can-git-hook-scripts-be-managed-along-with-the-repository
What approaches did your other projects use w.r.t. pre-commit hooks?  I think putting our hooks into a folder in the repo and than asking developers to update their git config to point to them would be the best way.  Of course, can't force people to do that.

This works for me when put in a11y-theme-builder/.git/hooks/pre-commit and made executable.  It came from: https://prettier.io/docs/en/precommit.html#option-4-shell-script.
#!/bin/sh
# Gather the names of files that have been staged (by "git add") and were the result of
#  code being added, created, merged or renamed
FILES=$(git diff --cached --name-only --diff-filter=ACMR | sed 's| |\\ |g')
# if there are no files then exit
[ -z "$FILES" ] && exit 0

# Prettify all selected files
echo "$FILES" | xargs ./code/node_modules/.bin/prettier --ignore-unknown --write

# Add back the modified/prettified files to staging
echo "$FILES" | xargs git add

exit 0

Per discussion in yesterday's Theme Builder call, I opened a separate issue for creating a pre-commit hook for running prettier and linting -> https://github.com/finos/a11y-theme-builder/issues/960


record span and breadcrumb when Django opens db connection

Here's a screenshot of a trace where Django opens a new connection

fixes #1249

Will wait for tests match against the django matrix to see if it works with all versions, but LGTM from an initial glance. Thank you for your contribution!

The test failures are due to sanic, which we fixed. Mind rebasing on master?

@AbhiPrasad I updated the branch

@AbhiPrasad I think I finally fixed it. I was incorrectly using the test client like the Django Rest client.

Awesome, thanks for sticking with this!!


Minor website/docs tweaks

http://opencolorio.org/installation.html#environment-variables should mention OCIO_ACTIVE_VIEWS, OCIO_ACTIVE_DISPLAYS, OCIO_LOGGING_LEVEL
The "Color Transform Example" has text "spi-animation profile, available here" which doesn't link anywhere
http://opencolorio.org/installation.html#building-from-source should say "Nuke 6.x or newer" probably
As Marc Draco mentioned on nuke-user list, http://opencolorio.org/CompatibleSoftware.html should list Natron and probably remove Ramen as it is no longer being developed (http://est77.github.io/ramen.html "It was developed between 2008 and 2011")

Thank you for carrying that discussion over


Link to the fork for size 2

Hi!
I just made a fork for a size 2 tab: https://github.com/adriantoine/tab-size-on-github. I just changed the size 4 to size 2, I changed the name and the logo to avoid confusions on the Chrome/Opera store. Could you tell me if there's a license issue since I just tweaked your logo and plugin? And if everything's ok, would you consider adding a link in your readme to my fork?
Thanks!

All fine, but not interested in linking to it as I don't see the point of your fork.


Options to add additional imports for the output module

Options to generate additional imports for the output module:
--moduleImports               "List of additional imports for the output module "

An example is added to README.
Update 02/03/2017: Remove need of --moduleImportsDelimiter Thx @alexbiehl for the hint!

Thanks, the code looks great. But, why would you need to add additional imports? Isn't the default list complete?

In the following example import Bar would not be generated.
module Data.Tree where

import Bar

type Foo = {bar :: Bar}

Maybe there is a better approach reading imports from the original module (in this case Data.Tree) and add these to the output module (Data.Tree.Lenses) instead of adding these by using an extra option...  Does have Language.PureScript any functions to read all imports of a module?

It should be easy enough to list imports by parsing the module, but I understand the issue now, and I think this will work fine.
Thanks!


Calculix 2.22

Checklist

[x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

@looooo @adrianinsaval
@FEA-Eng has requested that CalculiX v2.22 be used in the v1.0 release of FreeCAD to address some bugs present in prior versions.  This update to the patches fixes the build issues present in #28 .

Thank you. I will test it in the RC to make sure this version works as expected and fixes the issues we had with the old one.


Longest prefix matching for pathMapping server paths?

In my docker container with XDebug I have two volumes mounted:

/var/www/html mounts a wordpress folder in my Code workspace. That folder is ignored by git, as it only contains a WordPress installation.
/var/www/html/wp-content/themes/my-theme mounts a  my-theme folder in my workspace, which is subject of my work and tracked by git.

I have added pathMappings to my launch.json like this:
"pathMappings": {
     "/var/www/html/wp-content/themes/my-theme": "${workspaceRoot}/my-theme",
     "/var/www/html": "${workspaceRoot}/wordpress"
}

Unfortunately, as soon as I include "/var/www/html" in the pathMappings, server files within /var/www/html/wp-content/themes/my-theme are mapped to the corresponding ${workspaceRoot}/wordpress subdirectory, instead of the ${workspaceRoot}/my-theme folder.
What I would like the extension to do in this scenario is performing a longest prefix matching for server paths.
Are there any plans for implementing this in the future? Or am I missing a point here maybe?
If this feature is welcome, I would certainly offer to implement it!

@felixfbecker @bjoluc Would also love this feature as well. When mounting volumes with vagrant/docker, the local file structure often doesn't match the remote file structure, and this makes the current pathMappings setup only work for one mount at a time.


.pdb files of objects are not cached

This issue was originally created at: 2009-05-07 07:56:42.
This issue was reported by: manni51.

manni51 said at 2009-05-07 07:56:43

The man page describes usage of CCPDBFLAGS:
An alternative would be to use the /Zi to put the debugging information in a separate .pdb file for each object file by overriding the $CCPDBFLAGS variable as follows:
env['CCPDBFLAGS'] = '/Zi /Fd${TARGET}.pdb'

CAUTION: If you have enabled a CacheDir, these .pdb file are not written to the cache.
After restoring object files from cache, the debug information of cached files is lost.
It would be useful to cache these files too!

gregnoel said at 2009-05-13 21:52:15

Bug party triage.  This will take some design work (retrieving multiple target files from CacheDir with the same "build signature" isn't supported right now), so we won't be able to get to it for a while.

I found a simple fix that seems to work:
You can just env["PDB"] = "thing.pdb" instead of passing the exact pdb argument via CCPDBFLAGS (or any other flags).
SCons seems to set the appropriate compiler flags for you, and it "tracks" the pdb aswell. Also, it seems to track the pdb when cleaning too!

Thanks for the note.  Hope someone with more MSVC expertise will look this over - maybe there's something to add to the docs.


Videos from Huawei Gallery won't play

Hello,
I'd like to report a possible bug. I'm trying to use this app as the default video player on my phone, but if i try to play a file from the Gallery, the player will open, but nothing would actually play. Oddly, if i open the same videos from file manager it works ok.  I'm running android 10, and my phone model is Huawei P20 Pro.

Hi. Could you try opening "App info" detail for Just Player (the screen from where you uninstall an app or clear its data) and grant it Storage permission? Does it work then?

This fixed my issue, thanks. However I don't believe it prompted me for this permission when I first installed it.

Yes, the player app currently doesn't ask for this storage permission. It shouldn't be needed when interacting with other modern and properly written apps (at least from Android 7 and up). System apps are excluded from the requirements to target higher Android versions. I planning on adding the prompt for the storage permission eventually (when opening from these "unsupported" apps).

I hope I will be able to maintain this app over time so I focus on the actually maintainable and "testable" feature set. Support for these kind of hacks - receiving apps need storage permission when it's actually the task for the sender app - is fortunately needed less and less and eventually going fully away with latest Android releases. I even removed the storage access permission from the latest versions. This player really tries to go to the extreme.
(Still, you can continue using the -online build from Github that can be manually given the storage permission.)


German Translation

After quite some time, another German translation.
cc @ingorichter

I only looked at some translations with Google translate and they seems fine.


Unable to Save Bulk Count CSV Mapping with Only Mandatory Fields

Note

If a saved mapping is used and bulk count file is uploaded successfully then for the next attempt, previously used mapping should not appear pre-selected.
User should not be able to save the mapping with no name and using space.
Mapping chip should appear selected if clicked.
User should not be able to save the new mapping without doing selection opposite to mandatory fields.

Current behavior
The system does not allow the mapping to be saved and prompts the user to create mappings for all fields, including the optional ones.
Expected behavior
The mapping should be saved successfully when the user completes the mandatory fields without requiring mappings for the optional fields.
Steps to reproduce the issue
Navigate to the 'Bulk Count' page and upload a CSV file.
Attempt to create a mapping using only the mandatory fields.
Try to save the mapping.
Environment details
App version : v2.1.0
App environment : UAT
Additional information
https://jam.dev/c/3c391a6a-4e6f-45cd-9674-f04f441ee2a6

Verified in release v2.1.1 and found that issue exists for the 4th point mentioned in the note section. Hence, reopening this ticket.

Issue verified and working fine in release v2.2.0. Hence, closing this issue.


Can this bot DM a specific role or user?

It woud be good if the bot could DM a certain role or user... Is this possible to make?

Absolutely possible, contributions are welcome.

how do you do it?

@husosh use discord.js and commando documentation. Good luck if you attempt it! It isn’t too hard :p

can someone give the code for DM members
by user and not role


b3sum: Invalid space ; b3sum unable to verify hash that it created? [Works fine with b2sum]

How to recreate:
b3sum -l 64 ~/.cargo/bin/b3sum > b3sum.b3h
b3sum -c b3sum.b3h

> b3sum: Invalid space

b2sum -l 64 ~/.cargo/bin/b3sum > b3sum.b2h
b2sum -c b3sum.b2h

> ~/.cargo/bin/b3sum: OK

If b3sum can create longer hashes, surely it can verify them?

See this comment: https://github.com/BLAKE3-team/BLAKE3/issues/208#issuecomment-963384710
In short: Checking shorter hashes has a clear downside in terms of reduced security, which sophisticated users understand but which the majority of users might not be able to reason about clearly. Meanwhile, checking longer hashes has no security benefit, which is surprising to the vast majority of users. So I think supporting nonstandard hash lengths in checkfiles probably does more harm than good.
As a special case of this, implicitly figuring out the hash length from the checkfile itself (as opposed to requiring an explicit --length flag together with --check) is especially risky. Obviously we don't want to let someone put 1-byte hashes in a checkfile and then silently make it seem like that's providing just as much security as the 32-byte default. We could say "longer hashes are fine by default, but shorter hashes aren't allowed," but then again longer hashes actually provide no security benefit, so it's not clear why we would want to do this.
One thing we could definitely improve, though, is the quality of the error messages here. If we're never going to allow anything other than default-length hashes in a checkfile, it would be good for the error message to make that clear.


Camera only moves to end Positions

Hey! Thank you for this awesome library.
I am currently looking into the possibility of adding C200 support to unifi-cam-proxy  however I am not able to move the camera into any in between position.
tapo.moveMotorClockWise() and tapo.moveMotorStep(180) moves all the way into the end stop.
tapo.moveMotor("0.0000", "0.0000") crashes the camera with
Traceback (most recent call last):   File "<stdin>", line 1, in <module>   File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/pytapo/__init__.py", line 1118, in moveMotor     return self.performRequest(   File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/pytapo/__init__.py", line 619, in performRequest     raise Exception( Exception: Error: -60102, Response: {"error_code": -60102}
tapo.moveMotorStep(1) also crashes, but with
Traceback (most recent call last):   File "<stdin>", line 1, in <module>   File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/pytapo/__init__.py", line 1127, in moveMotorStep     return self.performRequest(   File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/pytapo/__init__.py", line 619, in performRequest     raise Exception( Exception: Error: -64316, Response: {"error_code": -64316}
I am sure there must be a way to control the camera into an in between position, but I could not figure out how?

You can use moveMotor.
https://github.com/JurajNyiri/HomeAssistant-Tapo-Control/blob/main/custom_components/tapo_control/button.py#L156


⚠ TorrentLeech has degraded performance

In eed4268, TorrentLeech ($TL) experienced degraded performance:

HTTP code: 200
Response time: 4583 ms

Resolved: TorrentLeech performance has improved in 89ae682 after 26 minutes.


Book and Quill is unusable with controller

https://github.com/Wilyicaro/Legacy-Minecraft/assets/39068731/e8ae7428-cc9d-4c0b-b749-c8d71e4dba6f

@Wilyicaro oh mb, didn't know this issue like this already existed


Error: Debug Failure. False expression. in 'getNodes' during 'getCodeFixes'

This issue comes from crash dumps in telemetry. We've tried to de-duplicate issues on a best-effort basis, comparing the sequence of methods called and the command requested while ignoring line numbers.
TypeScript Version Prefix: 2.7.1
VSCode Version 1.19.3
command requested: getCodeFixes
hitting sessions: 519
proportion of all sessions: 0.0019374853008701884
stack
Error: Debug Failure. False expression.
    at getNodes (tsserver.js:77598:22)
    at Object.getCodeActions (tsserver.js:77570:29)
    at unknown (tsserver.js:77059:33)
    at Object.forEach (tsserver.js:1430:30)
    at Object.getFixes (tsserver.js:77058:16)
    at unknown (tsserver.js:83206:35)
    at Object.flatMap (tsserver.js:1697:25)
    at Object.getCodeFixesAtPosition (tsserver.js:83204:23)
    at IOSession.Session.getCodeFixes (tsserver.js:90228:64)
    at Session.handlers.ts.createMapFromTemplate._a.(anonymous function) (tsserver.js:89132:61)
    at unknown (tsserver.js:90393:88)
    at IOSession.Session.executeWithRequestId (tsserver.js:90384:28)
    at IOSession.Session.executeCommand (tsserver.js:90393:33)
    at IOSession.Session.onMessage (tsserver.js:90413:35)
    at Interface.<anonymous> (tsserver.js:91614:27)
    at emitOne (events.js:96:13)
    at Interface.emit (events.js:191:7)
    at Interface._onLine (readline.js:241:10)
    at Interface._normalWrite (readline.js:384:12)
    at Socket.ondata (readline.js:101:10)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:191:7)
    at readableAddChunk (_stream_readable.js:178:18)
    at Socket.Readable.push (_stream_readable.js:136:10)
    at Pipe.onread (net.js:560:20)

This issue reproduced in the following context:
TypeScript Version Prefix: 2.7.2
VSCode Version 1.19.2
command requested: getCodeFixes
hitting sessions: 112
proportion of all sessions: 0.01188076800678901
stack
Error: Debug Failure. False expression.
    at getNodes (tsserver.js:77758:22)
    at Object.getCodeActions (tsserver.js:77730:29)
    at unknown (tsserver.js:77219:33)
    at Object.forEach (tsserver.js:1431:30)
    at Object.getFixes (tsserver.js:77218:16)
    at unknown (tsserver.js:83366:35)
    at Object.flatMap (tsserver.js:1698:25)
    at Object.getCodeFixesAtPosition (tsserver.js:83364:23)
    at IOSession.Session.getCodeFixes (tsserver.js:90388:64)
    at Session.handlers.ts.createMapFromTemplate._a.(anonymous function) (tsserver.js:89292:61)
    at unknown (tsserver.js:90553:88)
    at IOSession.Session.executeWithRequestId (tsserver.js:90544:28)
    at IOSession.Session.executeCommand (tsserver.js:90553:33)
    at IOSession.Session.onMessage (tsserver.js:90573:35)
    at Interface.<anonymous> (tsserver.js:91774:27)
    at emitOne (events.js:96:13)
    at Interface.emit (events.js:191:7)
    at Interface._onLine (readline.js:241:10)
    at Interface._normalWrite (readline.js:384:12)
    at Socket.ondata (readline.js:101:10)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:191:7)
    at readableAddChunk (_stream_readable.js:178:18)
    at Socket.Readable.push (_stream_readable.js:136:10)
    at Pipe.onread (net.js:560:20)


Dataframe.to_csv does not work as expected with mode="x"

Case 1: Using mode="x"
def test_to_csv_with_exclusive_mode():
    df0 = pd.DataFrame(
        {"x": ["a", "b", "c", "d"], "y": [1, 2, 3, 4]}
    )
    df = dd.from_pandas(df0, npartitions=2)
    with tmpdir() as dir:
        df.to_csv(dir, index=False, mode="x")
        result = dd.read_csv(os.path.join(dir, "*")).compute()
    assert_eq(result, df0, check_index=False)

raises FileExistsError.

Case 2: Using mode="x" with a single_file=True
def test_to_csv_with_single_file_and_exclusive_mode():
    df0 = pd.DataFrame(
        {"x": ["a", "b", "c", "d"], "y": [1, 2, 3, 4]}
    )
    df = dd.from_pandas(df0, npartitions=2)
    with tmpdir() as dir:
        csv_path = os.path.join(dir, "test.csv")
        df.to_csv(csv_path, index=False, mode="", single_file=True)
        result = dd.read_csv(os.path.join(dir, "*")).compute()
    assert_eq(result, df0, check_index=False)

raises ValueError: must have exactly one of create/read/write/append mode.

 (See https://github.com/dask/dask/pull/10441#discussion_r1293437311 for a pointer to where the problem might be.) cc @benrutter

I had a look at this today.

Case 1: Using mode="x"

The problem here looks like it's happening in fsspec, specifically in the file expansion function. Opening an issue over in that repository is a good idea.
Dask calls fsspec file_open, which calls fsspec _expand_paths, which calls get_fs_token_paths and I think the fix needs to happen there.

Case 2: Using mode="x" with a single_file=True
... See https://github.com/dask/dask/pull/10441#discussion_r1293437311 for a pointer to where the problem might be.

The line you mention is definitely the culprit. I've made a PR with your suggested test case and fix here https://github.com/dask/dask/pull/10443 Maybe you or Ben could take a look at it.

Case 1: Using mode="x"

The problem here looks like it's happening in fsspec, specifically in the file expansion function. Opening an issue over in that repository is a good idea.

Following up:

issue https://github.com/fsspec/filesystem_spec/issues/1332
PR https://github.com/fsspec/filesystem_spec/pull/1333


Carriage return char not escaped in Internet Explorer

I had an issue where a carriage return character was finding its way into the parsed template and in Internet Explorer I'd get an error at line 545 complaining of an unterminated string which on inspection turned out to be a " followed by an unescaped \r.
My workaround was chnaging line 406 to the following:
content.push( markup.substr( loc, shift ).replace( rNewLine,"\n").replace("\r", "\n"));
Unfortunately I haven't had time to replicate this small-scale yet but I'm posting an issue in case it's something obvious that you can fix.

Was this the latest version of jsrender? Sounds like https://github.com/BorisMoore/jsrender/issues/17 - which should have been fixed in commit  https://github.com/BorisMoore/jsrender/commit/09e5f23eb089f067cc263b95dd1b06294796eec8. Can you verify whether your issue still happens with that latest bits?

Quite right, it seems the version we are using was from before those fixes...
Thanks!


dns.ParseZone() parsing error leading to nil pointer dereference

What did I do?
PoC.go
package main

import (
	"fmt"
	"strings"

	"github.com/miekg/dns"
)

func main() {
	r := strings.NewReader(` Ta 0 0 0`)
	for x := range dns.ParseZone(r, "", "") {
		if x.Error != nil {
			fmt.Println(x.Error)
		} else if x == nil {
			// This should never be reached
			fmt.Println("x == NIL")
		} else {
			// Do something with x.RR
			fmt.Println(x.RR.String())
		}
	}
	return
}

What happened?
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x65a762]

goroutine 1 [running]:
main.main()
	/path/to/gopath/src/fuzz/dns/worker/main.go:20 +0x122
exit status 2

@miekg
I will take a look this tomorrow or a few day : )

@miekg
A PR #745  has been sent, please review it

#745 didn't have the magic commit message that would have closed this issue.


AutoCommandBindings add support method overloanding

"public void Do() // Call when not passing CommandParameter
{
// do something
}
public void Do(decimal parameter)  // Call when passing CommandParameter
{
// do something
}"

This issue was moved to RadicalFx/Radical.Windows#10


Added null checks to Gson results; removed deprecated MatchHistory

Added null checks to the results of Gson
Removed deprecated MatchHistory (since it doesn't work anymore at all;
this API has been shut down permanently)

Technically, basically I simply added a check like this to every result of Gson:
if (teams == null) {
    throw new RiotApiException(RiotApiException.PARSE_FAILURE);
}

This way we shouldn't run into NullPointerExceptions anymore, as discussed in https://github.com/rithms/riot-api-java/issues/31

Better safe than sorry. Lemme check over it, run some tests, and I'll merge.


QdtTable: qMatrix shows only 1000 values

Using the qdt-components, I have created a grid in my React project. The issue is that source data has more then 25000 rows but my application is rendering only 1000 rows. Probably due to the hypercube limitation. But is there a way to increase its limit? Let me know what changes I should make to get all the rows in my table.

Would appreciate any suggestion or solution for this. This is slowly becoming a show stopper for my project at work. Thanks in advance.

there is not way of changing the limits in the hypercuve results.
What you can do is have a loop to get all data like this
https://community.qlik.com/t5/Qlik-Design-Blog/Getting-all-data-cells-from-app-createCube/bc-p/1470928#M4912

I have added 'getDataInterval' that gets all data based on the given seconds for looping, in QdtMapBox
https://github.com/qlik-demo-team/qdt-components/blob/master/docs/components/QdtMapBox.md
let me know where do you need it

I have added 'getDataInterval' that gets all data based on the given seconds for looping, in QdtMapBox
https://github.com/qlik-demo-team/qdt-components/blob/master/docs/components/QdtMapBox.md
let me know where do you need it

Thank you for responding. This looks promising. Can this be done for QdtTable component please?

It's bad for performance and user experience to render so many things rows of a table in the dom at one time. QdtTable includes pagination for this reason.


Feature: Support RTK and normal GPS blending

Change in EKF required:
Currently all gps have to run at the same rate. But RTK (trimble) runs at 20hz and ublox m8n runs at 5hz

Prototype here: https://github.com/priseborough/Firmware/tree/pr-gpsBlendRate
PR will be submitted when reversion testing complete. Will require test data for replay testing with RTK 20hz and ublox m8n 5Hz data.
We should also add user settable parameter to enable running UBlox m8n at 10Hz

➤ Wrike Bot commented:
@Paul Riseborough All subtasks have been completed or deferred, you might want to complete this task as well.

@hamishwillee could you reach out to @priseborough and make sure we have documentation for this new feature


pytest-api test: fix ping server step

This PR aims to fix this error on CI : https://github.com/mindee/doctr/runs/7517599231?check_suite_focus=true
curl command in CI is run but the API is not fully ready so the Ping server step often failed.
There is an option --retry-all-errors since curl 7.71.0 but there is only curl 7.68.0 on ubuntu-latest (which is ubuntu 20.04) and that's not that simple to update curl to this version.
I replaced curl by wget with option --spider.
From man page:
--spider
When invoked with this option, Wget will behave as a Web spider, which means that it will not download the pages, just check that they are there.

Work on Ping server step also done here: https://github.com/mindee/doctr/pull/985

@frgfm

Hi @odulcy-mindee I think both PR's will not solve the under issue mentioned by users it is only a fix for CI 😅

@felixdittrich92 Yeah, I just discovered that haha

A deprecated decorator from pytest_asyncio induced failures on this step: https://github.com/mindee/doctr/runs/7522290771?check_suite_focus=true.
There has been a new release on pytest_asyncio. It requires to update the decorators. See a similar problem here https://github.com/pytest-dev/pytest-asyncio/issues/390.

Hey everyone :wave:
Here are my humble thoughts about this:

for multi-OS testing, I think that would clutter the CI. This type of API is usually run on a Docker or similar isolated environment, so it makes sense that this is run a Linux-based docker
about the underlying steps, I've started checking the proper version specifier range for all our dependencies on the API, the underlying issue should be fixed soon :)
regarding the arg deprecation of pytest_asyncio, I've also experienced this on other projects, I'll fix this :+1:

No need to close this PR, there are a few things we'll need :ok_hand:

Ok, I was able to reproduce https://github.com/mindee/doctr/issues/847 on my Linux.
As @frgfm said, I think that it's still fine to test only on a Linux-based container. I'll continue to investigate the dependencies issues.

Nice 👍 @frgfm has also something dependency related open in #957

@felixdittrich92 @frgfm The problem is coming from Tuples on fastapi, see https://github.com/tiangolo/fastapi/issues/4168, https://github.com/tiangolo/fastapi/issues/3782 and https://github.com/tiangolo/fastapi/issues/3665#issuecomment-1019579214.
I tested fastapi>=0.73.0 and it worked :partying_face:

@felixdittrich92 Yes, you're right, I'll add a small note in requirements.txt


abcl: 1.6.1 -> 1.7.0

Semi-automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/abcl/versions.
meta.description for abcl is: "A JVM-based Common Lisp implementation"
meta.homepage for abcl is: "https://common-lisp.net/project/armedbear/"
meta.changelog for abcl is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 1.7.0 with grep in /nix/store/xyxl52ljgcza3hpv5y369sil5prqdr4z-abcl-1.7.0

directory tree listing: https://gist.github.com/f2a55ae9c81108d462ed7b52fcc3d8b9

du listing: https://gist.github.com/861976d2c6bf852a26f6e166aef80189

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
0 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
abcl

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/xyxl52ljgcza3hpv5y369sil5prqdr4z-abcl-1.7.0 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A abcl https://github.com/r-ryantm/nixpkgs/archive/313d79983c12bb4994121894e91212f59cd9377a.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/xyxl52ljgcza3hpv5y369sil5prqdr4z-abcl-1.7.0
ls -la /nix/store/xyxl52ljgcza3hpv5y369sil5prqdr4z-abcl-1.7.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review 1

1 package built:
- abcl

Maintainer pings
cc @7c6f434c for testing.

Applied


Improve/tighten eslint configuration

Intro
eslint is one of the most important tools for any complex, collaborative project and allows us to easily find and fix bugs. So this PR aims to improve the current configuration to ensure we are utilising it to its full capacity.
Problems
The existing configuration isn't very strict, allowing bugs to occur more easily while also being a detriment to the overall code quality of this repo.
Solutions
I've gone ahead and added some recommended defaults, as well as some opinionated ones too.

react-app and react-hooks/recommended are important with react stuff.
@typescript-eslint/recommended and @typescript-eslint/eslint-recommended as recommended defaults.
unused-imports to automatically remove unused imports.
simple-import-sort to automatically sort imports alphabetically. This is opinionated, but I believe useful because it helps avoid merge conflicts with imports (and who doesn't like neat alphabetically sorted imports anyway).
@typescript-eslint/explicit-function-return-type and @typescript-eslint/explicit-module-boundary-types are turned off to prioritise inferred return types over explicit return types. This is opinionated, but often times the inference Typescript makes is good enough, and sometimes help prevents type mismatches that are a pain to debug.
@typescript-eslint/ban-ts-comment and @typescript-eslint/ban-ts-ignore are also turned off. This could possibly be temporary, but the ability to use @ts-ignore-like directives is certainly handy as an escape hatch as we encounter errors during the migration to TS.

More possible solutions

Implement a pre-commit hook using something like husky to ensure all code is linted before being pushed to remote (this should probably be the last step of the PR).

Discussion
Would love to hear any other defaults or eslint rules that you think should be added to the configuration.

Quite a few conflicts here, @sam-potter

Fixed all conflicts. @valtumi
With effectively 107 files prettified and linted, conflicts will be common as new commits are pushed (but are easily resolved by accepting all incoming changes and running yarn lint:fix again).

Also added the eslint rule: no-undef.
Reason being, undefined variables (like forgetting to import { t } from @lingui for example) were causing the build to fail, however were not being picked up by eslint. By explicitly specifying this rule, it prevents that and creates better parity between the two.

Added a pre-commit hook to lint only the staged files (to prevent from running eslint on the entire codebase). This means when a user tries to commit something to their local repo, it runs the eslint config and will abort the commit if it encounters any errors it can't fix automatically.
Added dev dependencies: husky and lint-staged.

Nice work, I really like this rules and how they enforce the quality of the code automatically!

Rules moved to https://github.com/OlympusDAO/olympus-frontend/pull/1234


Add -XX:+PerfDisableSharedMem flag by default

This change improves performance by avoiding GC pauses when writing stats to
a memory-mapped file under /tmp: http://www.evanjones.ca/jvm-mmap-pause.html.
Note that this behaviour can be overridden by users via '-XX:-PerfDisableSharedMem'.

Coverage remained the same at 100.0% when pulling 7913d55e179bce18197ab61c3998e2f30492856e on rfink/PerfDisableSharedMem into e3f7d4080b40730dec9c653ff0bd465515d5617c on develop.

Rob, feel free to cut a release.
From: Coveralls<EMAIL_ADDRESS>Reply-To: palantir/gradle-java-distribution<EMAIL_ADDRESS>Date: Friday, July 15, 2016 at 2:57 PM
To: palantir/gradle-java-distribution<EMAIL_ADDRESS>Cc: Mark Elliot<EMAIL_ADDRESS>Assign<EMAIL_ADDRESS>Subject: Re: [palantir/gradle-java-distribution] Add -XX:+PerfDisableSharedMem flag by default (#93)
[overage Status]https://urldefense.proofpoint.com/v2/url?u=https-3A__coveralls.io_builds_7028609&d=DQMCaQ&c=izlc9mHr637UR4lpLEZLFFS3Vn2UXBrZ4tFb6oOnmz8&r=Vp81aOxWZvuVgVK_wp-VF3pIYG92B19LcCw6XKeYC0U&m=oMdCQ2_wBmDftpNXK1u3nby9J8_FwJDi2YdcHr5cxpc&s=kQ-7Hj6M1YMoc88kVeQyArzBX3vg36mtX06r6RE4LtY&e=
Coverage remained the same at 100.0% when pulling 7913d55https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_palantir_gradle-2Djava-2Ddistribution_commit_7913d55e179bce18197ab61c3998e2f30492856e&d=DQMCaQ&c=izlc9mHr637UR4lpLEZLFFS3Vn2UXBrZ4tFb6oOnmz8&r=Vp81aOxWZvuVgVK_wp-VF3pIYG92B19LcCw6XKeYC0U&m=oMdCQ2_wBmDftpNXK1u3nby9J8_FwJDi2YdcHr5cxpc&s=4mgB7PcHLUY9N8bOgAQSyQA3jr-Q3kxAGOTs80mVwQQ&e= on rfink/PerfDisableSharedMem into e3f7d40https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_palantir_gradle-2Djava-2Ddistribution_commit_e3f7d4080b40730dec9c653ff0bd465515d5617c&d=DQMCaQ&c=izlc9mHr637UR4lpLEZLFFS3Vn2UXBrZ4tFb6oOnmz8&r=Vp81aOxWZvuVgVK_wp-VF3pIYG92B19LcCw6XKeYC0U&m=oMdCQ2_wBmDftpNXK1u3nby9J8_FwJDi2YdcHr5cxpc&s=IA0L4AGryLRWga36pbYJGyhSydQiJO9WFjjxF4NoZH8&e= on develop.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_palantir_gradle-2Djava-2Ddistribution_pull_93-23issuecomment-2D233038180&d=DQMCaQ&c=izlc9mHr637UR4lpLEZLFFS3Vn2UXBrZ4tFb6oOnmz8&r=Vp81aOxWZvuVgVK_wp-VF3pIYG92B19LcCw6XKeYC0U&m=oMdCQ2_wBmDftpNXK1u3nby9J8_FwJDi2YdcHr5cxpc&s=YxWEUb31qnJ92pq2GE4BM1bZVNmu5duaTcsZfdp_TN4&e=, or mute the threadhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AAp3Q5St7KZdZLQ6Y298XhPWcxgV6Wdsks5qV9gfgaJpZM4JNqj2&d=DQMCaQ&c=izlc9mHr637UR4lpLEZLFFS3Vn2UXBrZ4tFb6oOnmz8&r=Vp81aOxWZvuVgVK_wp-VF3pIYG92B19LcCw6XKeYC0U&m=oMdCQ2_wBmDftpNXK1u3nby9J8_FwJDi2YdcHr5cxpc&s=CyiWsR9YPPJZNZySlKWpMAlvuuW_B-T55GpLO-KsHbU&e=.


Cluster requirements

Is it possible to apply all these to a local cluster installed via KinD? (Kubernetes version is 1.25
$ kubectl version --short
Flag --short has been deprecated, and will be removed in the future. The --short output will become the default.
Client Version: v1.24.1
Kustomize Version: v4.5.4
Server Version: v1.25.2
)
When I run below command it shows pending instead of bounded.
kubectl get pvc
I used the same scripts and yaml files, apply into an AKS cluster, then it had no issues - it shows bound.
The fileshare has no ACL or virtual network constraints.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: d634c63a-6194-86a6-b522-3310812c81e8
Version Independent ID: fa86da1e-9c86-88fe-170c-5e6aa9230b5f
Content: Manually create Azure Files share - Azure Kubernetes Service
Content Source: articles/aks/azure-files-volume.md
Service: container-service
GitHub Login: @MGoedtel
Microsoft Alias: magoedte

The fileshare is visible in azure storage explorer

@minnieshi
It would be great if you could add a link to the documentation you are following for these steps? This would help us redirect the issue to the appropriate team. Thanks!!

https://learn.microsoft.com/en-us/azure/aks/azure-files-volume
Please see above.
That is right, This is a bug when feedback about a page, links open in GitHub app, it does not quote the original page.
If I clicked on a desktop which did not have the GitHub app installed, above link would have automatically been added.

@minnieshi
Thank you for your feedback!
Since this issue isn't directly related to improving our docs, and to gain a better understanding of your issue, I'd recommend working closer with our support team via an [Azure support request] (https://docs.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request).
Thank you for your time and patience throughout this issue.

My point is that the article is not clear in terms of setting up a Kubernetes cluster and no link to an article either . So would be great to have it for people to follow the "learning page"

@minnieshi
Thanks for your suggestion. We would work together to add your points with product team.


Query and header documentation

Insomnia allows to include description for query parameters and headers. I think it would be great if those were documented too.

I can't believe I overlooked that 🤦♂ I'll make sure to include this in the next release! Thank you for the heads up <3

Nice, I look forward to it
Another thing I noticed is that the json that insomnia exports also includes an attribute "description" for each folder, with an empty string as its value. However, if you manually modify this with your description it is shown in the generated documentation. I have asked, just in case you are interested in this thing about folders description.
https://github.com/Kong/insomnia/issues/196#issuecomment-569657012

This has been implemented in v0.3.1!

Folder descriptions were always supported!

Thank you again for the contribution!


3-tier architecture ?

Hi everyone,
Following this repository, I'm wondering if the architecture in place is more a 3-tier than a Clean Architecture.
These thoughts come from the fact that the domain module is calling directly the external Framework & Device layer (data module), without the Gateways object from the Interface Adapter layer of the Clean Architecture.

Finally, someone with understanding of the clean architecture.


mount render issue

Hi,
I've experienced some issues with the mount property:
export default class App extends ux.App {
    static _template() {
        return {
            Header: {
                rect: true,
                w: 1920,
                h: 50,
                color: 0xff005500,
                Title: {
                    x: w => w - 50,
                    y: 30,
                    mountX: 1,
                    mountY: 0.5, text: { text: 'Header' }
                }
            }
        }
    }
}

If I have this code, it renders like this:

If I add the same code to the live demo (or in a component within a project), it renders as expected (please notice window.innerWidth, since the demo panel is smaller than 1920!):
class LiveDemo extends lng.Application {
    static _template() {
        return {
            Header: {
                rect: true,
                w: window.innerWidth,
                h: 50,
                color: 0xff005500,
                Title: {
                    x: w => w - 50,
                    y: 30,
                    mountX: 1,
                    mountY: 0.5, text: { text: 'Header' }
                }
            }
        }
    };
}

Thanks!

Btw, using Lightning in the SDK with the blueprint. Thanks!

Looks like it was fixed in recent Lightning (exact change: https://github.com/WebPlatformForEmbedded/Lightning/commit/97444951be90b1354d746e5cc553ccffbb94898b)
I'll leave it open until fully confirmed.

@v42 can you check if this is fixed as @g-zachar is mentioning?

@woutermeek not fixed on SDK yet, I've created an issue there:
https://github.com/WebPlatformForEmbedded/Lightning-SDK/issues/7


Document the return value of exported function as a separate entity

This is probably not an issue and would probably make a better fit at a place like StackOverflow, but there doesn't seem to be a lot of traction on there for ESDoc - what with the lack of a suitable tag and all.

I'm currently in the process of rewriting an Angular 1.x codebase into ES2015. We've identified two core concepts that fit the class bill incredibly well. We've also managed to identify a fairly decent way of hooking said class into the service layer intricacies that is Angular 1.x.
In essence, this is what the code (read: boilerplate) looks like:
// FooModel.es6

/**
 * angular service wrapper fn.
 * @ignore (wont work)
 */
export default function ($q, $x, $z, ...otherAngularDeps) {
  /**
   * Foo class.
   */
  class Foo {
    /**
     * Foo constructor fn
     * @param {object} props
     */
    constructor (props) {}
  }

  return Foo;
}

// importer.es6
import Foo from './FooModel.es6';
angular.service('Foo', Foo);

Now, in a perfect setting I would be able to ignore the outer wrapper function and only document the Foo class - this does not seem to work with @ignore, which makes total sense imho.
Barring @ignore - any documentation I have for the Foo class gets lost whenever the wrapping function is introduced. If I break out the class definition from the wrapping functions scope, ESDoc picks it up just fine 🚀.
Now, I could ditch the wrapper function and slap the Angular dependencies into the constructor function of Foo (this is the 'generally accepted' approach of using ES2015 classes in angular@1.x), but that would introduce a ton of boilerplate and exposed services through the instances of Foo. Yuck!

tl/dr: I'm looking for suggestions on how to document the return value of a function as a separate entity, yet keep said entity in the given function scope.
(Feel free to close this and send my sorry bum over to StackOverflow, this is borderline issue/non-issue as far as I'm concerned. Sorry bout that.)

A little nit here class Foo () { is invalid class Foo { is what it should be... I suppose this doesn't change the documentation situation though.
You just might be able to fudge the AST generated with a custom ESDoc plugin that modifies the AST in onHandleAST, but that is pretty funky in general.
IE dynamically move the AST for the Foo ClassDeclaration seen here: https://astexplorer.net/#/DnVgOekcoZ
to this:
https://astexplorer.net/#/DnVgOekcoZ/1
You can see the generated AST on the right. What I'm suggesting though again a bit freaky is moving the ClassDeclaration to the body of the Program node before ExportDefaultDeclaration.

A little nit here class Foo () { is invalid class Foo {

Sorry bout that one. Edited the main post. Thanks!
I'm absolutely fine with moving around the AST - the freakiness doesn't bother me that much as I'm not concerned with the intricacies of how angular injectables so the wrapping function goes in the bin as far as ESDoc goes.
I'll have a look, see if there isn't already a plugin written for this type of problem. Barring that, let's see how far I get with wiring up a plugin.
Cheers!

There won't be an existing ESDoc plugin to handle this situation to my knowledge.
Perhaps an edge tip... ESDoc might officially upgrade to Babylon I hope soon. I have a maintained fork of ESDoc that uses Babylon 6 for the parser.
To make the AST parsing easier and more reliable if using the Babylon fork for this particular case you could use a decorator:
https://astexplorer.net/#/DnVgOekcoZ/2
And that way you can parse the ClassDeclaration looking for the declarator tag.

Alrighty, I think this can be closed right about now. Made something incredible primitive but it appears to get the job done of lifting out the class declaration, generating some docs for it as well as ignoring the wrapper function. Happy days! 🚀
/**
 * @ignore
 * @ngClassLift
 */
export default function FooWrapper () {
  class Foo {
  }
  return Foo;
}

Thanks @typhonrt for nudging me in the right direction!
plugin as a gist

@kasperlewau Nice... Get 'er done! :8ball:

I'm having the same issue. I'll see if I can adapt @kasperlewau's plugin for now (thanks!), but I'm a bit confused about the basic problem.
Even if I don't use @ignore on the wrapper function, the class inside isn't documented. Doesn't ESDoc traverse inside of function bodies? Actually, I know it does, for some things. But I guess everything that's deemed 'local' is ignored.
Perhaps the JSDoc @global tag can be implemented?


Consistent intersection type with array and tuple

Suggestion

🔍 Search Terms

array, tuple, intersection, covariance, #32926, #33760
✅ Viability Checklist

My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

I think this is rather theoretical approach for the behavior of intersection types and covariance for the consistency.
If this doesn't meet the design policy, feel free to close this.
📃 Motivating Example

Comprehension check for the intersection type and covariance
With my understanding of TypeScript and set theory, intersection type seems to obey following:
A & B ⊆ A
A & B ⊆ B

Also covariance/contravariance can alter the direction of such relation.
A ⊆ B

If F needs to be covariant:
F<A> ⊆ F<B>

then F<A> & F<B> is equivalent to F<A>

If F needs to be contravariant:
F<A> ⊇ F<B>

then F<A> & F<B> is equivalent to F<B>

Current behavior of finite/infinite computed property
Now consider the following object types
type Small = {
  [k in 'a' | 'b']: number
}

type Big = {
  [k in 'a' | 'b' | 'c']: number
}

let small: Small = { a: 1, b: 1 }
let big: Big = { a: 1, b: 1, c: 1 }

// small = big    // (OK)
// big = small    // (Invalid)

This makes sense. Note that this somehow behaves contravariant, while with the following behaves covariant.
type Big = {
  [k in string]: number
}

Here is the #playground for a glimpse.
What should be T[] & [T]?

It's basically nonsensical to intersect a tuple type with a variable-length array type;

I already read this from https://github.com/microsoft/TypeScript/issues/33760#issuecomment-537584492 . But with the theoretical point of view, I just wonder whether this is helpful for the consistent implementation for future or not.
I don't know the implementation detail of this, but along the empirical tests, I think [T] is considered like:
[T] = {
  length: 1
  "0": T
  // and other array's properties
}

And T[] resembles:
T[] = {
  length: number
  [index in number]: T
  // and other array's properties
}

Currently, with TypeScript v4.7.4, the result is a little bit weird. #playground
type T = number[] & [number]
let t: T[1] // ??? no error
let len: T["length"] // 1

Is this because 0 is not computed property? How about [T, T] or [T, T, T]?
💻 Use Cases

Literal type 0 should be considered as finite subset of number, and by "Current behavior of finite/infinite computed property", the computed property of index, should be narrowed into 0. Note that length is already narrowed into 1.
// suggested behavior
type T = number[] & [number]
let t: T[1] // should be error or never
let len: T["length"] // 1

I understand that this might impractical, and nobody do number[] & [number]. But I'm not sure that, there is no guarantee for other complex composition never make such result. I hope this insight would be helpful for TypeScript team.

// suggested behavior
type T = number[] & [number]
let t: T[1] // should be error or never
let len: T["length"] // 1

I think this goes back to what ⊆ is understood to mean. One viewpoint -- not the only one you could have -- is that if an operation is valid on B, and A ⊆ B, then that same operation must be valid on A. T[1] is valid when T is number[], so it must be valid on number[] & [number]
The same subtyping/subsetting behavior might be observed on the indexing expression itself -- if T[number] is legal (which I think it absolutely must be in this case) then it can't be illegal to write T[1], since 1 is a subset of number.

if an operation is valid on B, and A ⊆ B, then that same operation must be valid on A.

I agree but I think T[1] should be never here, as (A & B)[C] should have the same type as A[C] & B[C].

if an operation is valid on B, and A ⊆ B, then that same operation must be valid on A

I agree but I think T[1] should be never here, as (A & B)[C] should have the same type as A[C] & B[C].

I understood! As such operation have to be applicable, error should not occur. But its result has to obey the covariance property- never might be the answer.

Chiming in here to leave an opinion.
I'm implementing a type system for an unrelated project, and I've been sanity checking it by seeing how TypeScript handles these cases. I consider the following to be inconsistent behavior:
type Error = [1] & [1, 2]; // never
type Valid = { a: 1 } & { a: 1, b: 2 }; // { a: 1, b: 2 }

If differing array.length values should produce a type error, then differing Object.keys(object).length values should too.
Given how useful { a: 1 } & { b: 2 } is, the decision to ignore key length for the purpose of object intersections seems perfectly justifiable, but I think that decision should be applied consistently to tuples as well, unless there's a reason for the discrepancy that I'm not seeing.


Update lifecycle Hooks

Using package hook instead of deprecated deploy hooks and added to invoke local hooks

Coverage decreased (-3.2%) to 96.825% when pulling eb2e583645fc6eeb52f64b5f0b8f7c3d82a592a8 on dschep:lifecycle-hooks into 4bfb0162ff99827f4ac7b9dad727b6aaa989aedf on marcy-terui:master.

Coverage remained the same at 100.0% when pulling 0074b2e387f3972f8132d914699c222a9599e4ed on dschep:lifecycle-hooks into 4bfb0162ff99827f4ac7b9dad727b6aaa989aedf on marcy-terui:master.

Nice work!! Thanks a lot 👍


[BUG] Fix BWC tests on 3.0

Currently BWC tests are failing on OS 3.0: https://github.com/opensearch-project/cross-cluster-replication/actions/runs/3359666773/jobs/5567932617
Basically the cluster went unresponsive after upgrading one of the nodes. Though It doesn't seem to be related to CCR, we still need to triage this once and identify the root cause.

I tried taking a look again. Rolling upgrade tests are failing. After the first node is upgraded to 3.0, node is unable to join master. I can also see that master node also freezes(process is up and but no logs). Here are the logs:
bwcLeader0-0 is the node that upgraded. Logs:
[2023-04-17T18:44:47,502][WARN ][o.o.c.c.ClusterFormationFailureHelper] [bwcLeader0-0] cluster-manager not discovered or elected yet, an election requires at least 2 nodes with ids from [f2Qc2CtRR52qi0lOxoNWLA, na_iUH4eS0G4YMXdXyUGNQ, Yl5_pcSoTtOB_HjAXH8pdA], have discovered [{bwcLeader0-0}{f2Qc2CtRR52qi0lOxoNWLA}{wuDkRrwZTqmkauQ9D7hw4Q}{<IP_ADDRESS>}{<IP_ADDRESS>:51544}{dimr}{upgraded=true, testattr=test, shard_indexing_pressure_enabled=true}] which is not a quorum; discovery will continue using [[::1]:51318, <IP_ADDRESS>:51319, [::1]:51323, <IP_ADDRESS>:51324] from hosts providers and [{bwcLeader0-0}{f2Qc2CtRR52qi0lOxoNWLA}{wuDkRrwZTqmkauQ9D7hw4Q}{<IP_ADDRESS>}{<IP_ADDRESS>:51544}{dimr}{upgraded=true, testattr=test, shard_indexing_pressure_enabled=true}] from last-known cluster state; node term 5, last-accepted version 12 in term 5
[2023-04-17T18:44:47,765][WARN ][r.suppressed             ] [bwcLeader0-0] path: /_cluster/health, params: {wait_for_status=yellow, wait_for_nodes=>=3}
org.opensearch.discovery.ClusterManagerNotDiscoveredException: null
	at org.opensearch.action.support.clustermanager.TransportClusterManagerNodeAction$AsyncSingleAction$2.onTimeout(TransportClusterManagerNodeAction.java:350) [opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
	at org.opensearch.cluster.ClusterStateObserver$ContextPreservingListener.onTimeout(ClusterStateObserver.java:394) [opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
	at org.opensearch.cluster.ClusterStateObserver$ObserverClusterStateListener.onTimeout(ClusterStateObserver.java:294) [opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
	at org.opensearch.cluster.service.ClusterApplierService$NotifyTimeout.run(ClusterApplierService.java:707) [opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
	at org.opensearch.common.util.concurrent.ThreadContext$ContextPreservingRunnable.run(ThreadContext.java:747) [opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
	at java.lang.Thread.run(Thread.java:833) [?:?]

bwcLeader0-1(Master node):
[2023-04-17T18:43:42,886][INFO ][o.o.c.c.FollowersChecker ] [bwcLeader0-1] FollowerChecker{discoveryNode={bwcLeader0-0}{f2Qc2CtRR52qi0lOxoNWLA}{D2WPoAw3RfuXZVIj8_qQ5Q}{<IP_ADDRESS>}{<IP_ADDRESS>:51219}{dimr}{testattr=test, shard_indexing_pressure_enabled=true}, failureCountSinceLastSuccess=0, [cluster.fault_detection.follower_check.retry_count]=3} marking node as faulty
[2023-04-17T18:43:42,894][INFO ][o.o.c.s.MasterService    ] [bwcLeader0-1] node-left[{bwcLeader0-0}{f2Qc2CtRR52qi0lOxoNWLA}{D2WPoAw3RfuXZVIj8_qQ5Q}{<IP_ADDRESS>}{<IP_ADDRESS>:51219}{dimr}{testattr=test, shard_indexing_pressure_enabled=true} reason: disconnected], term: 5, version: 13, delta: removed {{bwcLeader0-0}{f2Qc2CtRR52qi0lOxoNWLA}{D2WPoAw3RfuXZVIj8_qQ5Q}{<IP_ADDRESS>}{<IP_ADDRESS>:51219}{dimr}{testattr=test, shard_indexing_pressure_enabled=true}}
[2023-04-17T18:43:42,896][DEBUG][o.o.c.c.PublicationTransportHandler] [bwcLeader0-1] received diff cluster state version [13] with uuid [iYjVAg3jRhyWjpUuFituvg], diff size [656]
[2023-04-17T18:43:42,963][INFO ][o.o.c.s.ClusterApplierService] [bwcLeader0-1] removed {{bwcLeader0-0}{f2Qc2CtRR52qi0lOxoNWLA}{D2WPoAw3RfuXZVIj8_qQ5Q}{<IP_ADDRESS>}{<IP_ADDRESS>:51219}{dimr}{testattr=test, shard_indexing_pressure_enabled=true}}, term: 5, version: 13, reason: Publication{term=5, version=13}
[2023-04-17T18:43:42,984][INFO ][o.o.c.r.DelayedAllocationService] [bwcLeader0-1] scheduling reroute for delayed shards in [59.9s] (1 delayed shards)
[2023-04-17T18:43:42,984][DEBUG][o.o.c.c.C.CoordinatorPublication] [bwcLeader0-1] publication ended successfully: Publication{term=5, version=13}
[2023-04-17T18:43:43,024][INFO ][o.o.i.s.IndexShard       ] [bwcLeader0-1] [bwc_test_index][0] primary-replica resync completed with 0 operations
[2023-04-17T18:44:42,894][DEBUG][o.o.c.c.PublicationTransportHandler] [bwcLeader0-1] received diff cluster state version [14] with uuid [rbON9BKfQFuFu_IbQJds_A], diff size [318]
[2023-04-17T18:44:43,050][DEBUG][o.o.c.c.C.CoordinatorPublication] [bwcLeader0-1] publication ended successfully: Publication{term=5, version=14}
[2023-04-17T18:44:43,084][WARN ][o.o.c.r.a.AllocationService] [bwcLeader0-1] [bwc_test_index][0] marking unavailable shards as stale: [mVtF80e6QTSoqiazZMeFwA]
[2023-04-17T18:44:43,086][DEBUG][o.o.c.c.PublicationTransportHandler] [bwcLeader0-1] received diff cluster state version [15] with uuid [vtOX4DfxRdeKHdW7JWWJ7w], diff size [433]
[2023-04-17T18:44:43,149][DEBUG][o.o.c.c.C.CoordinatorPublication] [bwcLeader0-1] publication ended successfully: Publication{term=5, version=15}
[2023-04-17T18:44:43,404][INFO ][o.o.i.r.RecoverySourceHandler] [bwcLeader0-1] [bwc_test_index][0][recover to bwcLeader0-2] finalizing recovery took [120.8ms]
[2023-04-17T18:44:43,407][INFO ][o.o.c.r.a.AllocationService] [bwcLeader0-1] Cluster health status changed from [YELLOW] to [GREEN] (reason: [shards started [[bwc_test_index][0]]]).
[2023-04-17T18:44:43,408][DEBUG][o.o.c.c.PublicationTransportHandler] [bwcLeader0-1] received diff cluster state version [16] with uuid [IZpKNhjoSDGs8-2xSmIywQ], diff size [485]
[2023-04-17T18:44:43,455][DEBUG][o.o.c.c.C.CoordinatorPublication] [bwcLeader0-1] publication ended successfully: Publication{term=5, version=16}

Logs from 3rd node bwcLeader0-2
[2023-04-17T18:43:42,962][INFO ][o.o.c.s.ClusterApplierService] [bwcLeader0-2] removed {{bwcLeader0-0}{f2Qc2CtRR52qi0lOxoNWLA}{D2WPoAw3RfuXZVIj8_qQ5Q}{<IP_ADDRESS>}{<IP_ADDRESS>:51219}{dimr}{testattr=test, shard_indexing_pressure_enabled=true}}, term: 5, version: 13, reason: ApplyCommitRequest{term=5, version=13, sourceNode={bwcLeader0-1}{na_iUH4eS0G4YMXdXyUGNQ}{ieUCKHmrQnGBXRfMiOtXNQ}{<IP_ADDRESS>}{<IP_ADDRESS>:51319}{dimr}{testattr=test, shard_indexing_pressure_enabled=true}}
[2023-04-17T18:44:42,896][DEBUG][o.o.c.c.PublicationTransportHandler] [bwcLeader0-2] received diff cluster state version [14] with uuid [rbON9BKfQFuFu_IbQJds_A], diff size [318]
[2023-04-17T18:44:42,962][INFO ][o.o.p.PluginsService     ] [bwcLeader0-2] PluginService:onIndexModule index:[bwc_test_index/d9Mf4r26S92WNkr9jmINrA]
[2023-04-17T18:44:43,087][DEBUG][o.o.c.c.PublicationTransportHandler] [bwcLeader0-2] received diff cluster state version [15] with uuid [vtOX4DfxRdeKHdW7JWWJ7w], diff size [433]
[2023-04-17T18:44:43,409][DEBUG][o.o.c.c.PublicationTransportHandler] [bwcLeader0-2] received diff cluster state version [16] with uuid [IZpKNhjoSDGs8-2xSmIywQ], diff size [485]
[2023-04-17T18:44:47,885][DEBUG][o.o.c.c.LeaderChecker    ] [bwcLeader0-2] leader [{bwcLeader0-1}{na_iUH4eS0G4YMXdXyUGNQ}{ieUCKHmrQnGBXRfMiOtXNQ}{<IP_ADDRESS>}{<IP_ADDRESS>:51319}{dimr}{testattr=test, shard_indexing_pressure_enabled=true}] disconnected
[2023-04-17T18:44:47,885][INFO ][o.o.c.c.Coordinator      ] [bwcLeader0-2] cluster-manager node [{bwcLeader0-1}{na_iUH4eS0G4YMXdXyUGNQ}{ieUCKHmrQnGBXRfMiOtXNQ}{<IP_ADDRESS>}{<IP_ADDRESS>:51319}{dimr}{testattr=test, shard_indexing_pressure_enabled=true}] failed, restarting discovery
org.opensearch.transport.NodeDisconnectedException: [bwcLeader0-1][<IP_ADDRESS>:51319][disconnected] disconnected
[2023-04-17T18:44:47,886][DEBUG][o.o.c.c.Coordinator      ] [bwcLeader0-2] onLeaderFailure: coordinator becoming CANDIDATE in term 5 (was FOLLOWER, lastKnownLeader was [Optional[{bwcLeader0-1}{na_iUH4eS0G4YMXdXyUGNQ}{ieUCKHmrQnGBXRfMiOtXNQ}{<IP_ADDRESS>}{<IP_ADDRESS>:51319}{dimr}{testattr=test, shard_indexing_pressure_enabled=true}]])
[2023-04-17T18:44:47,886][INFO ][o.o.c.s.ClusterApplierService] [bwcLeader0-2] cluster-manager node changed {previous [{bwcLeader0-1}{na_iUH4eS0G4YMXdXyUGNQ}{ieUCKHmrQnGBXRfMiOtXNQ}{<IP_ADDRESS>}{<IP_ADDRESS>:51319}{dimr}{testattr=test, shard_indexing_pressure_enabled=true}], current []}, term: 5, version: 16, reason: becoming candidate: onLeaderFailure

Disabling the mixedClusterTask for 3.0 now:
https://github.com/opensearch-project/opensearch-plugins/issues/167
https://github.com/opensearch-project/job-scheduler/pull/242/files


release: prepare for v0.0.5

Description
Release for v0.0.5
Rationale
Change logs

#190
#215
#224
#226
#227
#228
#229
#232
#233

Example
NA
Changes
NA

Need change the crypto release to an official one, thanks.


Leak of memory mappings + memory leak.

We run a simple test:
https://github.com/yandex/ClickHouse/blob/master/dbms/src/Common/tests/mi_malloc_test.cpp
for the following scenario: allocate memory segments of a random medium to large size and keep the total allocated memory within some limit.
If we use jemalloc, the test is using constant number of memory mappings (32) and bounded amount of memory.
If we use mimalloc, the test works much slower but quickly creates huge amount of memory mappings:
$ while true; do cat /proc/$(pidof mi_malloc_test)/maps | wc -l; sleep 1; done
0
738
4894
8790
12608
16533
20428
24283
28041
31763
35642
39321
43014
46589
50222
53969
57612
61197
64718
65531
65531
65531
65531
65531
65531
65531
65531
65531
65531
65531
65531
65531
65531
65531
65531
65531

until it reaches the maximum. After that, it will start to leak memory untill all memory is exhausted.
It happens after about 5 million iterations:
$ dbms/src/Common/tests/mi_malloc_test
Total allocations: 1048576
Total allocations: 2097152
Total allocations: 3145728
Total allocations: 4194304
Total allocations: 5242880
Total allocations: 6291456
Total allocations: 7340032
^C

Ah thanks for finding this! I am looking into it ASAP (-- and amazing how simple the test is that leads to this behaviour).   (I just tried it on windows but it seems stable there)

Found it :-)  It was caused due to allocating many "huge" objects larger than 512kb (and not accessing them in the test). This lead mimalloc to use raw mmap for that which is very slow and becomes fragmented.
Now, the good news is that I was already working on better supporting huge allocations -- and if you pull the latest dev-exp branch it should be good again. This branch is more experimental but perhaps it is time to integrate parts of it back into dev and master (also since it just got WASM support thanks to @jedisct1 )

(ps. If you are ok, can I grab the test and modify it a bit and add it to the mimalloc-bench repository? If so, please add a MIT license on top of the test file so I can easily include  it.)

If you are ok, can I grab the test and modify it a bit and add it to the mimalloc-bench repository?

Sure!

please add a MIT license on top of the test file so I can easily include it.

Ok, I've added a license:
https://github.com/yandex/ClickHouse/blob/master/dbms/src/Common/tests/mi_malloc_test.cpp

Thanks Alexey! -- appreciate the test and improving mimalloc to work better!

The issue was closed but it's unclear of the memory leak was fixed and my tests seem to indicate it wasn't, could we get some clarification?

Ah, I thought this was fixed! I tried to access the test again but the links stopped working -- can you try with the latest dev branch if it still fails? If so, please send me the test source again; the plan was to add this to the mimalloc-bench but I didn't get around to it.

I don't have access tot he original test, sorry, I'll see if I can create a simplified case for where I'm seeing it - sadly it's part of a bigger application :(

Ah I see. Please try with the latest dev branch -- there should be no problems anymore. The dev branch is being tested on large internal services and there seem to be no memory leak bugs. But if you do find a problem please write me so we can fix it.

Hi daanx, thanks for the patients and sorry for getting back so late, had to find the time to run some tests. I can confirm that the memory leak is gone in the dev branch! :)

looks like stable too after getting dev working and backtracking the steps it turns out there was a issue with the rust crate for mimalloc bumping the crate number not nut the git submodule to the newest version :( sorry about the confusion


isLoading not returning Bool without destructing | Nuxt - Vue-Query

Describe the bug

As shown above, without destructing, and using useQuery in a direct const like below, the isLoading is not returning bool, i haven't tested for other types, but isFetching is working good.

Your minimal, reproducible example
https://codesandbox.io/s/new
Steps to reproduce
Output  .isLoading without destructing
Example
<template>
Loading..
////Its stuck in  Loading. only
Things are loaded</span<
</template>

Expected behavior
when used like below

@return type should be  : Boolean
How often does this bug happen?
Every time
Screenshots or Videos

Platform
Nuxt project info:                                                                    5:17:51 PM

Operating System: Windows_NT
Node Version:     v18.11.0
Nuxt Version:     3.6.1
Nitro Version:    2.5.2
Package Manager<EMAIL_ADDRESS>Builder:          vite
User Config:      vue, routeRules, nitro, css, vite, postcss, app, modules, content, googleSignIn, runtimeConfig, devtools, plugins
Runtime Modules<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Build Modules:    -

Tanstack Query adapter
vanilla
TanStack Query version
^4.29.19
TypeScript version
No response
Additional context
No response

All properties returned by vue-query are ref's. Otherwise if you try to destructure them, you will loose reactivity, which is a very common problem among new Vue devs.
Vue should unwrap refs that are passed to the template, but it seems that they are doing it only for direct accessed properly and dot notation access - query.isLoading is not unwrapped.
This is not strictly a problem with vue-query.
You could potentially open a feature-request in Vue repository to get it working.
We could potentially just return reactive object and count on users to properly handle destructuring with toRefs conversion, but i doubt that will be a good idea (more confused users than benefits).
There is an RFC in place to make reactive props destructurable, but until that lands and will be supported in custom composables, i doubt we could do anything about it.

Hello @DamianOsipiuk  This really makes sense, i used react-query previously, it worked. well in that case,
One point i would like to add here  is:
With destructing only few property like isLoading are not working here, isFetching  is all working good when tested with ve dev tool
Can you  please tell me how to use the isLoading then with below query now :
<template>
Loading..
////Its stuck in  Loading. only
Things are loaded</span<
</template>

Hello @DamianOsipiuk , Still unhappy with what they said tbh,
But still thinking why we have to use query.isLoading.value on the template and for some query.isFetching works just fine,
This looks so inconsistent.


regression in device cgroup

# rpm-ostree status -b
State: idle
AutomaticUpdates: ex-stage; rpm-ostreed-automatic.timer: last run 19h ago
Deployments:
● ostree://fedora-atomic:fedora/28/x86_64/workstation
                   Version: 28.20180818.0 (2018-08-19 00:37:14)
                BaseCommit: 779dfb76fbec73853917d4259ada8f9657a9cb8ab5642880cc7386e5ca4b0d87
           LayeredPackages: emacs ffmpeg-libs fuse-sshfs git-evtag keepassx krb5-workstation libvirt-client mozilla-openh264 oci-kvm-hook opensc origin-clients pcsc-lite-ccid strace stratisd tmux virt-manager
                            xsel ykclient ykpers
# rpm -q podman
podman-<IP_ADDRESS>-1.gitf38eb4f.fc28.x86_64
# podman run --rm -ti registry.fedoraproject.org/fedora:28 /bin/sh -c 'mknod mynull c 1 3; echo foo > mynull'
/bin/sh: mynull: Permission denied
# rpm -q docker
docker-1.13.1-61.git9cb56fd.fc28.x86_64
# docker run --rm -ti registry.fedoraproject.org/fedora:28 /bin/sh -c 'mknod mynull c 1 3; echo foo > mynull'
#

(In a quick test I failed to downgrade to https://koji.fedoraproject.org/koji/buildinfo?buildID=1133743 due to conmon, but trying the latest version in FAH28...)
# rpm -q podman
podman-0.7.2-2.git4ca4c5f.fc28.x86_64

The above works fine.
This specifically breaks running mock inside podman.

Can you add --cgroup-manager=cgroupfs to the <IP_ADDRESS> command line and see if it works with that?

This is probably a result of our swap to systemd cgroup management in <IP_ADDRESS>. Will need to look into why this is prohibiting this.

While attempting to reproduce, I caused conmon to dump core. So that's also not good.

conmon coredump is just on one VM, so that's probably just my environment. Can repro locally on my laptop.

It's not cgroupfs, it's not SELinux. Hm.

Has to be the devices cgroup. We don't deliberately set anything related to said CGroup, though.

Ah hah.
[root@localhost ~]# rpm -q podman
podman-0.7.4-4.git80612fb.fc28.x86_64
[root@localhost ~]# podman run --rm -ti registry.fedoraproject.org/fedora:28 findmnt -o OPTIONS /
OPTIONS
rw,relatime,context="system_u:object_r:container_file_t:s0:c588,c594",lowerdir=/var/lib/containers/storage/overlay/l/QLZYS6RMMTBNCA5MKINHFG5ZU2,upperdir=/var/lib/containers/storage/overlay/2534e74abbc639850f02b7
[root@localhost ~]#

...

[root@localhost ~]# rpm -q podman
podman-<IP_ADDRESS>-1.gitf38eb4f.fc28.x86_64
[root@localhost ~]# podman run --rm -ti registry.fedoraproject.org/fedora:28 findmnt -o OPTIONS /
OPTIONS
rw,nodev,relatime,context="system_u:object_r:container_file_t:s0:c120,c503",lowerdir=/var/lib/containers/storage/overlay/l/QLZYS6RMMTBNCA5MKINHFG5ZU2,upperdir=/var/lib/containers/storage/overlay/b873c28ab4a7d1e8

Note the nodev.

...But why are we allowed to mknod then? I would expect that mknod would be the command to break, not subsequent accesses to said node. I suppose that's a kernel semantics problem, though.

This looks like https://github.com/containers/storage/blob/956a1971694f18fd602b1203c0a2d192e2cc88a1/storage.conf#L35-L36 - added by @rhatdan a month ago.
@cgwalters Can you change storage.conf to remove the nodev and see if that fixes matters?
@rhatdan Can we make this toggle-able per-container?

I briefly tried to find out which git commit in podman started injecting nodev but I don't know the code well enough.
However, now that I know the root cause, since today practically speaking recursive containers need --privileged, it's a simple matter of mount -o remount,dev / in my dev container.

I think probably the storage conf shouldn't have default mount flags.  Rather, podman could inject nodev if the container isn't --privileged?

Somehow only hit this now myself and took me some time to figure it out. I would definitely expect podman --privileged to not have this restriction here.

Slowly working my way back to this.  We really need to be able to disable some options for containers/storage at container create time.  I have been distracted by other tasks though.

This should be fixed in latest podman.