impl new i2c driver interface of esp-idf 5.2

closes #388
Interface
Sync
let config = Config {
    pub pullup_enabled: bool,
    pub source_clock: SourceClock,
    pub glitch_ignore_cnt: u8,
};

let driver = I2cDriver::new(..., config);

let config = DeviceConfig {
    pub address: DeviceAddress,
    pub baudrate: Hertz,
}

let device_a = driver.device(config);
let device_b = driver.device(config);
// alternative
let device_a = I2cDeviceDriver::new(&driver, config);
let device_b = I2cDeviceDriver::new(&driver, config);

Async
let config = Config {
    pub pullup_enabled: bool,
    pub source_clock: SourceClock,
    pub glitch_ignore_cnt: u8,
};

let driver = AsyncI2cDriver::new(..., config);

let config = DeviceConfig {
    pub address: DeviceAddress,
    pub baudrate: Hertz,
}

let device_a = driver.device(config);
let device_b = driver.device(config);
// alternative
let device_a = AsyncI2cDeviceDriver::new(&driver, config);
let device_b = AsyncI2cDeviceDriver::new(&driver, config);

// owned device (async supports only one device at the time without adding
// and deleting the isr callback at every operation -> could optimice performance
// by adding the callback once for multiple operations)
let device = driver.owned_device(config);
let driver = device.release();

trait impls

I2cDriver: impls embedded_hal traits by creating a device driver internally by using default device config (transaction unimplemented!)
I2cDeviceDriver:  impls embedded_hal traits by ignoring the address args of the trait (transaction unimplemented!)
AsyncI2cDriver: impls embedded_hal_async traits by creating a device driver internally by using default device config (transaction unimplemented!)
I2cDeviceDriver:  impls embedded_hal_async traits by ignoring the address args of the trait (transaction unimplemented!)
OwnedAsyncI2cDeviceDriver: impls embedded_hal_async traits by ignoring the address args of the trait (transaction unimplemented!)

Open Questions:

[ ] Is it ok to split the drivers into sync and async drivers? Main difference when using async

add the isr callback (only one device can be async at a time)
increase the trans_queue_depth config (this must be done at driver creation time) (as it is implemented by now, the implementation takes care of it, but if we combine the drivers it could be done by the user in the driver config and by adding a comment to indicate to increase it when doing async operations)

[ ] How to support legacy driver (transactional interface)

call it LegacyI2cDriver?
How to deal with it if two i2c drivers can be used? (must be both legacy or new driver)

[ ] support sync and async on one bus? The current implementation allows only sync or async devices.
[ ] Use case for setting trans_queue_depth > 1?
[ ] How to impl read blocking for I2cSlaveDriver?
[ ] Allow 7/10 bit address (currently in dev config, but embedded_hal needs it within the type itself -> add a generic to the device driver whether it is 7 or 10 bit address)

sync and async driver combined + address len
// only sync operations available
let driver = I2cDriver::<'_, AsyncDisabled>::new(..., config);
// async operations + async devices available
let driver = I2cDriver::<'_, AsyncEnabled>::new(..., config); // sets `trans_queue_depth` = 1

let sync_device = driver.device::<TenBitAddress>(config);
drop(sync_device);
let owned_sync_device = driver.owned_device(config); // bus is owned by the device
let driver = owned_sync_device.release();
// if AsyncEnabled
let async_device = driver.async_device(config);
drop(async_device);
let owned_async_device = driver.owned_async_device(config); // bus is owned by the device
let driver = owned_async_device.release();

pros

more simple interface
sync and async combined and simultaneous usable
all device drivers can be Send (currently I2cDeviceDriver cannot be send because no locking mechanism of the bus internally)

cons

lock inner bus mutex for sync and async operations (if not using owned devices)
adds a generic to the driver struct

When I use the OwnedAsyncI2cDeviceDriver async driver (do some operations) as I implemented it, I get an error with the following backtrace. If I add some dbg!() in the read, write or write_read operations it works fine. So it is mainly because of the call to the fast HalIsrNotification::wait()? Some ideas why?

stacktrace
Guru Meditation Error: Core  0 panic'ed (Stack protection fault).

Detected in task "pthread" at 0x40387f16
0x40387f16 - multi_heap_internal_lock
    at /home/al9hu7/workspace/playground/i2c-test/.embuild/espressif/esp-idf/v5.2.1/components/heap/multi_heap.c:164
Stack pointer: 0x3fc99910
0x3fc99910 - _heap_start
    at ??:??
Stack bounds: 0x3fc9991c - 0x3fc9a510
0x3fc9991c - _heap_start
    at ??:??
0x3fc9a510 - _heap_start
    at ??:??

Core  0 register dump:
MEPC    : 0x40387f1e  RA      : 0x40387e7e  SP      : 0x3fc99910  GP      : 0x3fc8b600
0x40387f1e - multi_heap_internal_lock
    at /home/al9hu7/workspace/playground/i2c-test/.embuild/espressif/esp-idf/v5.2.1/components/heap/multi_heap.c:166
0x40387e7e - multi_heap_aligned_alloc_impl_offs
    at /home/al9hu7/workspace/playground/i2c-test/.embuild/espressif/esp-idf/v5.2.1/components/heap/multi_heap.c:286
0x3fc99910 - _heap_start
    at ??:??
0x3fc8b600 - __global_pointer$
    at ??:??
TP      : 0x3fc73940  T0      : 0x42031486  T1      : 0x40389c72  T2      : 0xa5a5a5a5
0x3fc73940 - _rodata_reserved_end
    at ??:??
0x42031486 - core::sync::atomic::atomic_compare_exchange
    at /home/al9hu7/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/sync/atomic.rs:3388
0x40389c72 - memspi_host_read_id_hs
    at /home/al9hu7/workspace/playground/i2c-test/.embuild/espressif/esp-idf/v5.2.1/components/spi_flash/memspi_host_driver.c:113
0xa5a5a5a5 - SYSTEM
    at ??:??
S0/FP   : 0x3fc8d590  S1      : 0x00000008  A0      : 0x00000000  A1      : 0x00000008
0x3fc8d590 - _heap_start
    at ??:??
0x00000008 - RV_STK_SP
    at ??:??
0x00000000 -
    at ??:??
0x00000008 - RV_STK_SP
    at ??:??
A2      : 0x00000008  A3      : 0x00000000  A4      : 0x00000000  A5      : 0x3fc8d000
0x00000008 - RV_STK_SP
    at ??:??
0x00000000 -
    at ??:??
0x00000000 -
    at ??:??
0x3fc8d000 - __lock___malloc_recursive_mutex
    at ??:??
A6      : 0x3fc9a77c  A7      : 0xa5a5a5a5  S2      : 0x00000008  S3      : 0x3fc8d940
0x3fc9a77c - _heap_start
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0x00000008 - RV_STK_SP
    at ??:??
0x3fc8d940 - _heap_start
    at ??:??
S4      : 0x00000000  S5      : 0x00000003  S6      : 0x3fc8d000  S7      : 0x00000000
0x00000000 -
    at ??:??
0x00000003 - EXC_ILLEGAL_INSTRUCTION
    at ??:??
0x3fc8d000 - __lock___malloc_recursive_mutex
    at ??:??
0x00000000 -
    at ??:??
S8      : 0x3fc8d590  S9      : 0x3b9aca00  S10     : 0x3c072db8  S11     : 0x3fc8ae10
0x3fc8d590 - _heap_start
    at ??:??
0x3b9aca00 -
    at ??:??
0x3c072db8 - str.0
    at ??:??
0x3fc8ae10 - _ZN12tracing_core8metadata9MAX_LEVEL17h4af3cbd1cee9ec55E
    at ??:??
T3      : 0xa5a5a5a5  T4      : 0xa5a5a5a5  T5      : 0xa5a5a5a5  T6      : 0xa5a5a5a5
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
MSTATUS : 0x00001881  MTVEC   : 0x40380001  MCAUSE  : 0x0000001b  MTVAL   : 0x00000141
0x00001881 -
    at ??:??
0x40380001 - _vector_table
    at ??:??
0x0000001b - _rtc_reserved_length
    at ??:??
0x00000141 -
    at ??:??
MHARTID : 0x00000000
0x00000000 -
    at ??:??

Stack memory:
3fc99910: 0x00000000 0x3fc998dc 0x00000c00 0x40387e7e 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0x00000000
0x00000000 -
    at ??:??
0x3fc998dc - _heap_start
    at ??:??
0x00000c00 -
    at ??:??
0x40387e7e - multi_heap_aligned_alloc_impl_offs
    at /home/al9hu7/workspace/playground/i2c-test/.embuild/espressif/esp-idf/v5.2.1/components/heap/multi_heap.c:286
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0x00000000 -
    at ??:??
3fc99930: 0x00000008 0x00001000 0x00000008 0x403817f8 0xa5a5a5a5 0xa5a5a5a5 0x00000001 0x3b9ad000
0x00000008 - RV_STK_SP
    at ??:??
0x00001000 -
    at ??:??
0x00000008 - RV_STK_SP
    at ??:??
0x403817f8 - heap_caps_aligned_alloc
    at /home/al9hu7/workspace/playground/i2c-test/.embuild/espressif/esp-idf/v5.2.1/components/heap/heap_caps.c:720
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0x00000001 -
    at ??:??
0x3b9ad000 -
    at ??:??
3fc99950: 0x3fc99b48 0x3fc9a79c 0x3b9aca00 0x3b9ad000 0x3fc8d000 0x00000008 0x00000008 0x4202946e
0x3fc99b48 - _heap_start
    at ??:??
0x3fc9a79c - _heap_start
    at ??:??
0x3b9aca00 -
    at ??:??
0x3b9ad000 -
    at ??:??
0x3fc8d000 - __lock___malloc_recursive_mutex
    at ??:??
0x00000008 - RV_STK_SP
    at ??:??
0x00000008 - RV_STK_SP
    at ??:??
0x4202946e - core::ptr::non_null::NonNull<T>::new
    at /home/al9hu7/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/non_null.rs:247
3fc99970: 0x00000000 0x00000008 0x00000008 0x4202936c 0x00000000 0x3fc9a79c 0x3fc9a79c 0x420298a4
0x00000000 -
    at ??:??
0x00000008 - RV_STK_SP
    at ??:??
0x00000008 - RV_STK_SP
    at ??:??
0x4202936c - alloc::alloc::exchange_malloc
    at /home/al9hu7/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/alloc.rs:330
0x00000000 -
    at ??:??
0x3fc9a79c - _heap_start
    at ??:??
0x3fc9a79c - _heap_start
    at ??:??
0x420298a4 - alloc::boxed::Box<T>::new
    at /home/al9hu7/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:218
3fc99990: 0x00000000 0x3fc8d000 0x00060000 0x00000000 0x00000000 0x3fc8d000 0x3fc9a774 0x3fc9a77c
0x00000000 -
    at ??:??
0x3fc8d000 - __lock___malloc_recursive_mutex
    at ??:??
0x00060000 -
    at ??:??
0x00000000 -
    at ??:??
0x00000000 -
    at ??:??
0x3fc8d000 - __lock___malloc_recursive_mutex
    at ??:??
0x3fc9a774 - _heap_start
    at ??:??
0x3fc9a77c - _heap_start
    at ??:??
3fc999b0: 0x3fc99b48 0x3fc9a79c 0x3fc9a79c 0x42031472 0x00000001 0x3fc99a10 0x3fc9a79c 0x4202fa3a
0x3fc99b48 - _heap_start
    at ??:??
0x3fc9a79c - _heap_start
    at ??:??
0x3fc9a79c - _heap_start
    at ??:??
0x42031472 - std::sys_common::lazy_box::LazyBox<T>::initialize
    at ??:??
0x00000001 -
    at ??:??
0x3fc99a10 - _heap_start
    at ??:??
0x3fc9a79c - _heap_start
    at ??:??
0x4202fa3a - std::sys_common::lazy_box::LazyBox<T>::get_pointer
    at /home/al9hu7/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/lazy_box.rs:50
3fc999d0: 0x3fc99b4c 0x3fc99a20 0x3fc9a79c 0x4202fa60 0x3fc99b4c 0x00000002 0x00000000 0x4202f63c
0x3fc99b4c - _heap_start
    at ??:??
0x3fc99a20 - _heap_start
    at ??:??
0x3fc9a79c - _heap_start
    at ??:??
0x4202fa60 - std::sys::pal::unix::locks::pthread_mutex::Mutex::lock
    at /home/al9hu7/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/pal/unix/locks/pthread_mutex.rs:114
0x3fc99b4c - _heap_start
    at ??:??
0x00000002 - EXC_ILLEGAL_INSTRUCTION
    at ??:??
0x00000000 -
    at ??:??
0x4202f63c - std::sync::mutex::Mutex<T>::lock
    at /home/al9hu7/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sync/mutex.rs:274
3fc999f0: 0x00000000 0x00000001 0x3fc9a7ac 0x42010136 0x00000003 0x00000000 0x00000001 0x4200f154
0x00000000 -
    at ??:??
0x00000001 -
    at ??:??
0x3fc9a7ac - _heap_start
    at ??:??
0x42010136 - core::result::Result<T,E>::unwrap
    at /home/al9hu7/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/result.rs:1075
0x00000003 - EXC_ILLEGAL_INSTRUCTION
    at ??:??
0x00000000 -
    at ??:??
0x00000001 -
    at ??:??
0x4200f154 - event_listener::sys::<impl event_listener::Inner<T>>::register
    at /home/al9hu7/.cargo/registry/src/index.crates.io-6f17d22bba15001f/event-listener-4.0.3/src/std.rs:169
3fc99a10: 0x3fc9a6b8 0x3fc9a6bc 0x000f4200 0xa5a5a500 0x00000000 0xa5a5a5a5 0x00001800 0x4038146a
0x3fc9a6b8 - _heap_start
    at ??:??
0x3fc9a6bc - _heap_start
    at ??:??
0x000f4200 -
    at ??:??
0xa5a5a500 - SYSTEM
    at ??:??
0x00000000 -
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0x00001800 -
    at ??:??
0x4038146a - heap_caps_malloc_base
    at /home/al9hu7/workspace/playground/i2c-test/.embuild/espressif/esp-idf/v5.2.1/components/heap/heap_caps.c:180
3fc99a30: 0x00001800 0x00000002 0x00000000 0x3fc9a794 0x00000000 0x3fc9a6b8 0x3fc9a774 0x00000001
0x00001800 -
    at ??:??
0x00000002 - EXC_ILLEGAL_INSTRUCTION
    at ??:??
0x00000000 -
    at ??:??
0x3fc9a794 - _heap_start
    at ??:??
0x00000000 -
    at ??:??
0x3fc9a6b8 - _heap_start
    at ??:??
0x3fc9a774 - _heap_start
    at ??:??
0x00000001 -
    at ??:??
3fc99a50: 0x3fc9a77c 0x3b9aca00 0x3fc99b48 0x4200ed1c 0x00001800 0x0000001c 0x0000001c 0x40381484
0x3fc9a77c - _heap_start
    at ??:??
0x3b9aca00 -
    at ??:??
0x3fc99b48 - _heap_start
    at ??:??
0x4200ed1c - event_listener::Listener<T,B>::wait_with_parker
    at /home/al9hu7/.cargo/registry/src/index.crates.io-6f17d22bba15001f/event-listener-4.0.3/src/lib.rs:1103
0x00001800 -
    at ??:??
0x0000001c - RV_STK_T2
    at ??:??
0x0000001c - RV_STK_T2
    at ??:??
0x40381484 - heap_caps_malloc
    at /home/al9hu7/workspace/playground/i2c-test/.embuild/espressif/esp-idf/v5.2.1/components/heap/heap_caps.c:202
3fc99a70: 0x3b9aca00 0x3fc8d000 0x0000001c 0x4200fe94 0x00000000 0x00000000 0x00000000 0x42010032
0x3b9aca00 -
    at ??:??
0x3fc8d000 - __lock___malloc_recursive_mutex
    at ??:??
0x0000001c - RV_STK_T2
    at ??:??
0x4200fe94 - core::ptr::non_null::NonNull<T>::new
    at /home/al9hu7/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/non_null.rs:247
0x00000000 -
    at ??:??
0x00000000 -
    at ??:??
0x00000000 -
    at ??:??
0x42010032 - alloc::boxed::Box<T>::new
    at /home/al9hu7/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:218
3fc99a90: 0x00000000 0x00000008 0x000f4240 0x3fc8d348 0x00000000 0x3fc99b48 0x3b9ad000 0x3fc99b48
0x00000000 -
    at ??:??
0x00000008 - RV_STK_SP
    at ??:??
0x000f4240 -
    at ??:??
0x3fc8d348 - _ZN8async_io6driver14BLOCK_ON_COUNT17h0162ff7491fbbacaE
    at ??:??
0x00000000 -
    at ??:??
0x3fc99b48 - _heap_start
    at ??:??
0x3b9ad000 -
    at ??:??
0x3fc99b48 - _heap_start
    at ??:??
3fc99ab0: 0x3b9aca00 0x3fc9a774 0x3fc9a770 0x4200ec30 0x3fc9a6bc 0x00000000 0x3c072e00 0x00000006
0x3b9aca00 -
    at ??:??
0x3fc9a774 - _heap_start
    at ??:??
0x3fc9a770 - _heap_start
    at ??:??
0x4200ec30 - core::cell::Cell<T>::get
    at /home/al9hu7/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/cell.rs:512
0x3fc9a6bc - _heap_start
    at ??:??
0x00000000 -
    at ??:??
0x3c072e00 - str.0
    at ??:??
0x00000006 - RV_STK_RA
    at ??:??
3fc99ad0: 0x3fc99b64 0x000003e8 0x3c072e00 0x00000006 0x3fc99b64 0x00000001 0x3fc9a100 0x4200ee1c
0x3fc99b64 - _heap_start
    at ??:??
0x000003e8 -
    at ??:??
0x3c072e00 - str.0
    at ??:??
0x00000006 - RV_STK_RA
    at ??:??
0x3fc99b64 - _heap_start
    at ??:??
0x00000001 -
    at ??:??
0x3fc9a100 - _heap_start
    at ??:??
0x4200ee1c - core::option::Option<T>::unwrap
    at /home/al9hu7/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/option.rs:930
3fc99af0: 0xa5a5a5a5 0x00000001 0x3fc9a100 0x42005856 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
0xa5a5a5a5 - SYSTEM
    at ??:??
0x00000001 -
    at ??:??
0x3fc9a100 - _heap_start
    at ??:??
0x42005856 - <event_listener_strategy::Blocking as event_listener_strategy::Strategy>::wait
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
3fc99b10: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
3fc99b30: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0x3fc8c340 0x3fc9a333 0x00000001 0x00000002
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0x3fc8c340 - _ZN8async_io7reactor7Reactor3get7REACTOR17h9e39ef048be84631E.llvm.5754974393764579329
    at ??:??
0x3fc9a333 - _heap_start
    at ??:??
0x00000001 -
    at ??:??
0x00000002 - EXC_ILLEGAL_INSTRUCTION
    at ??:??
3fc99b50: 0x00000000 0x3fc9a794 0x00000000 0x00000000 0x3fc9a6b0 0x3fc99b48 0x3fc8c340 0x3fc9a333
0x00000000 -
    at ??:??
0x3fc9a794 - _heap_start
    at ??:??
0x00000000 -
    at ??:??
0x00000000 -
    at ??:??
0x3fc9a6b0 - _heap_start
    at ??:??
0x3fc99b48 - _heap_start
    at ??:??
0x3fc8c340 - _ZN8async_io7reactor7Reactor3get7REACTOR17h9e39ef048be84631E.llvm.5754974393764579329
    at ??:??
0x3fc9a333 - _heap_start
    at ??:??
3fc99b70: 0xa5a50001 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
0xa5a50001 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
3fc99b90: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
3fc99bb0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
3fc99bd0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
3fc99bf0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
3fc99c10: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
3fc99c30: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
3fc99c50: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM
    at ??:??
0xa5a5a5a5 - SYSTEM

It looks like a stack overflow to me...

@ivmarkov any thoughts on the points in the init PR comment? I think the sync and async driver combined + address len is pretty neat, but it differs to other driver impls.

@ivmarkov any thoughts on the points in the init PR comment? I think the sync and async driver combined + address len is pretty neat, but it differs to other driver impls.

Limited access to internet right now. Will follow up when I have an opportunity

@teamplayer3 I finally have some time now, so I can start looking into this. My first question would be, why not implementing the new driver in a completely separate module from the old driver? As all "new" drivers were implemented so far (ADC comes to mind)?
The name of the new driver's module is not so important as long as it is separate from the old driver.
Otherwise, we'll lose the old driver completely, and until we have the new driver working properly, we probably don't want this?

Ahhhh, you did it except moving the existing driver to legacy.
Maybe (and in the name of backwards compatibility) keep the old driver under its existing i2c module. And then introduce the new driver in a new module? We can always later re-export all pub types from the new driver into the i2c module?

Some quick answers here (unfortunately I don't have answers for everything...):

Is it ok to split the drivers into sync and async drivers? Main difference when using async add the isr callback (only one device can be async at a time)

We do both (a single driver and multiple drivers). I'm leaning towards not splitting, as long as it results in readable code and real code reuse. If the async driver uses a completely different code path from the sync driver or it needs some expensive extra state (say, a hidden FreeRtos task to "simulate" async behavior), then it is probably better to keep those separate.

How to support legacy driver (transactional interface) call it LegacyI2cDriver?

As per above, I think we should keep the code base backwards compatible, i.e. the legacy driver for now should stay in place, under its existing name and module.

How to deal with it if two i2c drivers can be used? (must be both legacy or new driver)

No good answer, but we have to support this for other drivers besides i2c. Thinking loud: what if we detect this at runtime, using a global atomic or a mutex? I.e. if the new driver is instantiated on at least one i2c peripheral, the old driver would fail to construct (with a runtime error or a panic)? And the other way around?

support sync and async on one bus? The current implementation allows only sync or async devices.

I think that's good enough.

Use case for setting trans_queue_depth > 1?

No idea :)

How to impl read blocking for I2cSlaveDriver?

No idea, need to look at the C API I guess...

Allow 7/10 bit address (currently in dev config, but embedded_hal needs it within the type itself -> add a generic to the device driver whether it is 7 or 10 bit address)

Yes, a 0-sized type should do.

As per above, I think we should keep the code base backwards compatible, i.e. the legacy driver for now should stay in place, under its existing name and module.

As soon functions are linked in from both driver versions, an error is thrown at startup:
E (382) i2c: CONFLICT! driver_ng is not allowed to be used with this old driver

This because of a check in i2c.c:  check_i2c_driver_conflict
This means we cannot use both drivers simultaneous.

As per above, I think we should keep the code base backwards compatible, i.e. the legacy driver for now should stay in place, under its existing name and module.

As soon functions are linked in from both driver versions, an error is thrown at startup:
E (382) i2c: CONFLICT! driver_ng is not allowed to be used with this old driver

This because of a check in i2c.c: check_i2c_driver_conflict
This means we cannot use both drivers simultaneous.

I see.
Deleting the legacy driver is still not an option. At least not until (a) the new driver is proven reliable (b) the old ESP IDF 5 versions are no longer used. (Because the new driver was introduced after ESP IDF 5.0, right?)
Is the new driver (and the old driver) somehow covered by an ESP IDF component? Or is there a CONF_ setting whether to use one or the other? If any of these is true, then we can explore this path.
As much as I hate it, in the absence of one of the two options from above, we can introduce a feature for that then. Something like legacy_i2c. It will be on by default, and thus will only allow the legacy driver. If users want to use the new driver, they'll have to run with default-features=false. And once the new driver is stabilized, we can remove the legacy_i2c feature.
But let's first carefully check if we have a CONF_ or if one (or both) of the drivers are in fact in separate components?

Actually...
The above will happen ONLY if the code of the user is calling into BOTH drivers!
If the user is not using both drivers, there should be no problem? Right?
Hint: Rust only links code that you call into. The rest is pruned.

Problem with embedded_hal impl of transaction() interface (not implemented in new driver interface): This could be implemented with i2c_jobs but as stated this wouldn't come soon. issue comment

Actually...

The above will happen ONLY if the code of the user is calling into BOTH drivers!
If the user is not using both drivers, there should be no problem? Right?
Hint: Rust only links code that you call into. The rest is pruned.

If I remove the legacy mod from i2c, it works without a problem. If I only use the new driver in my main code, and don't have removed the legacy stuff in esp-idf-hal, the error mentioned occurs.

Actually...
The above will happen ONLY if the code of the user is calling into BOTH drivers! If the user is not using both drivers, there should be no problem? Right? Hint: Rust only links code that you call into. The rest is pruned.

That all sounds nice in theory but in practice we run over and over into the problem with all legacy drivers. The simple truth is that esp-idf forbid the usage of both at the same time while not providing a compile time solution do set a used driver.
The truth is that in our compiled libespidf.elf we always have both symbols for new and old drivers, something that would not so easily happen in a pure C project since you only use the header you need.
We discussed the point some time ago a bit, but my stance is that we still should try find a way ( for example with more exclusive imports of old and new drivers in the bindgen.h) to make a more clear cut at the root of the issue and not engineer around it by shifting the problem into manual labor - tipple check if anything aliens correctly with all our drivers so we don't accidental call into old or new api where we should not,

Actually...

The above will happen ONLY if the code of the user is calling into BOTH drivers!
If the user is not using both drivers, there should be no problem? Right?
Hint: Rust only links code that you call into. The rest is pruned.

If I remove the legacy mod from i2c, it works without a problem. If I only use the new driver in my main code, and don't have removed the legacy stuff in esp-idf-hal, the error mentioned occurs.

This does not sound right. This means something is calling into the legacy code. Or the linker is not pruning the legacy code, which would also be weird.

Tests:

mod legacy and new driver in esp-idf-hal

don't remove any driver in esp-idf-hal
use only one driver of them (either legacy or new) in main code
error is thrown at startup

remove the other impl in esp-idf-hal

use only one driver of them (either legacy or new) in main code
remove other impl
no error

This check is done in this function:
__attribute__((constructor))
static void check_i2c_driver_conflict(void)
{
    // This function was declared as weak here. The new I2C driver has the implementation.
    // So if the new I2C driver is not linked in, then `i2c_acquire_bus_handle()` should be NULL at runtime.
    extern __attribute__((weak)) esp_err_t i2c_acquire_bus_handle(int port_num, void *i2c_new_bus, int mode);
    if ((void *)i2c_acquire_bus_handle != NULL) {
        ESP_EARLY_LOGE(I2C_TAG, "CONFLICT! driver_ng is not allowed to be used with this old driver");
        abort();
    }
    ESP_EARLY_LOGW(I2C_TAG, "This driver is an old driver, please migrate your application code to adapt `driver/i2c_master.h`");
}

I think one solution could look like the following: us providing "user defined" kconfigs that define appropriate compiletime flags. That flags can be consumed in the binding.h and would also automatically generate them as to rust cfg(). A normal user than could set them in ther sdkconfig file selecting old or new, with one of them the default.
That would need some work on us providing the mechanism in the first place in the current embuild/esp-idf-sys dynamic but i think its not to far out. I can explore it if you think that would be a viable solution.

I think one solution could look like the following: us providing "user defined" kconfigs that define appropriate compiletime flags. That flags can be consumed in the binding.h and would also automatically generate them as to rust cfg(). A normal user than could set them in their sdkconfig file selecting old or new, with one of them as the default.

That would need some work on us providing the mechanism in the first place in the current embuild/esp-idf-sys dynamic but i think its not to far out. I can explore it if you think that would be a viable solution.

This would be a nice thing solution which will align to the esp-idf config.
I think a quick solution to switch to the legacy version would be to add a feature to esp-idf-hal, something like driver-i2c-legacy. If it isn't set, the new one is used and if it is set the legacy one is used. But of course, then all drivers are included in esp-idf-sys and it would not fix the root cause.

@teamplayer3 - thanks for you analysis, but this is not complete yet? It is unpleasant - I can imagine - but I would go inspect the .elf file and try to understand, why is a bunch of code ending up in there when it shouldn't. Or try to understand how exactly _attribute((constructor))__ works in GCC. Because it really shouldn't be as you describe - if you don't use the code from an .o file, it is not getting linked. There is something we don't understand still.
@Vollbrecht Not even sure where to start? Maybe these two comments:

The pain point is that in our compiled libespidf.elf we always have both symbols for new and old drivers,

It is not .elf but .a. The fact that we have both symbols for old and new drivers there is not a problem in my opinion. Please explain why this is a problem. Also if you can explain why the fact that we have both new and old i2c symbols in the libespidf.a file is not a problem even here, as long as @teamplayer3 comments out the Rust code (which is weird!).

something that would not so easily happen in a pure C project since you only use the header you need.

Headers have nothing to do with what symbols you end up with in your .o file. I can #include "internet.h" - yet - if I am not calling the internet, I'll not end up with any __internet symbols in my .o file.
==============
Please don't take the above as nit-picking. Really! The last thing I want is to demotivate folks by pointing at their (potential) mistakes.
BUT: I'm absolutely NOT OK with introducing grandiose new solutions (like the user-defined "conf" thing) or even new features to problems that we still do not understand completely.

mod legacy and new driver in esp-idf-hal

don't remove any driver in esp-idf-hal
use only one driver of them (either legacy or new) in main code
error is thrown at startup

remove the other impl in esp-idf-hal

use only one driver of them (either legacy or new) in main code
remove other impl
no error

@Vollbrecht @teamplayer3  I think I have a very good hypothesis for the above problem that needs a quick test:
What happens, if you put the legacy driver module, and the new driver module into two separate .rs files?
I'm betting and hoping that the problem will then disappear!
Background: https://rustc-dev-guide.rust-lang.org/backend/libs-and-metadata.html
Specifically the section which says:
"
Object code, which is the result of code generation. This is used during regular linking. There is a separate .o file for each codegen unit.
"
I.e. since we have just one .rs file for both legacy and new driver, we end up with a single .o file.
Further since I'm not sure that the linker properly uses "function-level lLTO" (though I swear I noticed this option in the linker cmd args!), the linker will link-in to the final ELF both the old and the new rmt driver wrappers (and thus both the old and the new  ESP IDF C rmt drivers), as long as we are calling even just one of them.

Unfortunately, it might not be as simple as I thought.
To translate the above ^^^ in simple terms, it seems there is just no .rs <-> .o file 1:1 mapping, as it is in the C world.

What that means - in the worst case - is that - whatever we do - the old and the new RMT driver might still end up in the same .o file and thus - in the absence of function-level LTO - we'll end up with the CONFLICT! issue again.

@teamplayer3 You are using xtensa or riscv MCU for your tests?

You are using xtensa or riscv MCU for your tests?

@ivmarkov for tests I used riscv

@teamplayer3 if you can do one more test whenever you have some time, sorry: can you compile in release and see if you are still reproducing the problem?

@ivmarkov here is a minimal repo that reproduces the error. It only has a lib.rs that has two function, one using the legacy driver and one using the new one. In the bin.rs only the new one is called but it fails at runtime with the usual error.

my example fails for me both with cargo r and cargo r --release

https://github.com/esp-rs/esp-idf-sys/issues/313

Whats the status on this?

Whats the status on this?

The root cause prohibiting the merge of the driver is solved, yet there is still feedback in the driver code itself that needs to be addressed. For one, I would appreciate if the old (4.4.X) driver is left untouched as much as possible (including in its current module as well as its location in the file), and the new 5.X driver is in its own sub-module. For one, that would make the review much easier as the current diff is very difficult to review.
There were other issues as far as I remember, but the bottom line is somebody needs to volunteer and pick it up. The esp-idf-* crates are a community effort so unless somebody puts some effort here, it would stay as-is.

I can pick it up again. And see if I can make it more diff friendly. @kaaax0815 maybe you can test it, because I'm missing the test infrastructure currently.

I can pick it up again. And see if I can make it more diff friendly. @kaaax0815 maybe you can test it, because I'm missing the test infrastructure currently.

@teamplayer3 Just to mention that when saying that the root cause is solved, this unfortunately does not mean it is solved at the ESP-IDF level.
We do need to introduce a feature toggle for switching between the legacy and the new driver similar to this one. But at least now we know why this is necessary in the first place (because of those pesky GCC C constructor functions that get pulled-in if we have any code compiled and referencing the legacy or the new driver - even if that code is pruned by the linker the GCC C constructors that were pulled by the pruned code would stay and be called).
So if that means the legacy code needs to be surrounded with a i2c_legacy module, than fine, be it, let's just leave it where it is physically, so that diff can do a better job at figuring out the actual differences. :-)

Currently, I have problems building the hal. These are the same problems why esp-idf-template not building in CI. How can I fix these? I want to build for riscv by using rust nightly.

Compile Error:
error[E0308]: mismatched types
    --> /home/al9hu7/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/pal/unix/fs.rs:1053:33
     |
1053 |         unsafe { CStr::from_ptr(self.entry.d_name.as_ptr()) }
     |                  -------------- ^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `*const u8`, found `*const i8`
     |                  |
     |                  arguments to this function are incorrect
     |
     = note: expected raw pointer `*const u8`
                found raw pointer `*const i8`
note: associated function defined here
    --> /home/al9hu7/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ffi/c_str.rs:276:25
     |
276  |     pub const unsafe fn from_ptr<'a>(ptr: *const c_char) -> &'a CStr {
     |                         ^^^^^^^^

error[E0308]: mismatched types
    --> /home/al9hu7/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/pal/unix/fs.rs:1185:43
     |
1185 |         let fd = cvt_r(|| unsafe { open64(path.as_ptr(), flags, opts.mode as c_int) })?;
     |                                    ------ ^^^^^^^^^^^^^ expected `*const i8`, found `*const u8`
     |                                    |
     |                                    arguments to this function are incorrect
     |
     = note: expected raw pointer `*const i8`
                found raw pointer `*const u8`
note: function defined here
    --> /home/al9hu7/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/libc-0.2.168/src/unix/mod.rs:851:12
     |
851  |     pub fn open(path: *const c_char, oflag: c_int, ...) -> c_int;
     |            ^^^^

error[E0308]: mismatched types
    --> /home/al9hu7/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/pal/unix/fs.rs:1555:61
     |
1555 |         run_path_with_cstr(p, &|p| cvt(unsafe { libc::mkdir(p.as_ptr(), self.mode) }).map(|_| ()))
     |                                                 ----------- ^^^^^^^^^^ expected `*const i8`, found `*const u8`
     |                                                 |
     |                                                 arguments to this function are incorrect
     |
     = note: expected raw pointer `*const i8`
                found raw pointer `*const u8`

Currently, I have problems building the hal. These are the same problems why esp-idf-template not building in CI. How can I fix these? I want to build for riscv by using rust nightly.

Upstream broke all nightly versions, because they changed c_char definition stuff. A patch to fix it for esp-idf should be already merged but we need to wait so it trickels down...

i fixed it temporarily by using esp channel

For now, I restricted the AsyncDeviceDriver to only one async device per bus, as documented in docs. If another one is constructed, a runtime error will be returned. (tried to determine the cause of this by the source code - couldn't find the reason. Maybe I overlooked something, but the callback is set per device.)
As I understand it, this applies to the callback function, which is called after completed transactions and must be set for a device which should support async operations. In other words, you could remove this restriction if the callback is reset for each transaction (read, write, writeRead) and the bus is blocked for asynchronous transactions by semaphore or mutex. But I'm not quite sure, it must be tested.
start async trans
- lock bus for async
- set callback
- write/read/write&read
- wait on done
- reset callback
- unlock bus for async
end async trans

This would lead to the next async transaction call gets blocked until the last is finished. I think this is completely fine as long the blocking mechanism is async.


call x-maps-google with ajax

Hello and thank you very much for the effort you put in this package.
I am trying to implement the map in the following scenario.
A specific user interaction makes an ajax call to a route. From there the controller handles the request by returning a small blade with some information. The controller is using the return view() to send back the blade. Inside this blade I have the .
When the ajax request returns, javascript handles it by applying the blade to a div element.
When doing this, the map is not rendered.
I notice that if the  is rendered onpageload , it pushes some scripts to html .
But if the  is being rendered afterwards through ajax, the snippets are not pushed to
Am I approaching this the wrong way? Do you have any suggestions on how to initialize the map asynchronously maybe?
Thank you for your time.

Hi, thx for the issue :)
Could you setup a repository with a basic example of what you want?
I kinda understand it but having a level playing ground would help.

Hi thank you for making the repository. as I understand it now this will never work. That is because the google and leaflet are listening for a document created event which is never fired when loading it via this.
What you could try is loading it via an iframe and using the js in the page to reload the iframe.

This is a very good solution actually. Thank you very much! You made my day :)

Alright, good luck :)


move test to a dev-dependency and move test apis to transformer_test package

other than the name suggestion, lgtm


Parameter encoding - linker error

I'm using "Moya/Moya" "10.0.2" and "Alamofire/Alamofire" "4.6.0"
Once I add parameter encoding to TargetType enum declaration I'm getting linker error
public var parameterEncoding: ParameterEncoding {
        return URLEncoding.httpBody
    }

Look's like problem is related with Alamofire, but I can't find any solutions.
I'm using Carthage 0.27.0

Hey @mkkroliks. Try to import Alamofire and see if it helps.

Yes! It works, thanks a lot @sunshinejr.

Thanks for letting us know this worked for you @mkkroliks 👍
Sent with GitHawk


fix(Utxo.get()): Properly handling addresses with no SLP utxos

:tada: This PR is included in version 5.2.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Add connection abstraction to devp2p networking

Extracted from #684
Builds on #887
What was wrong?
As a continuation of #684 we previously implemented the Multiplexer and new facilities to handle the P2P handshake under p2p.handshake.  Now we need something active (aka a Service) to manage the multiplexed connection and allow multiple consumers for each protocol or command.
How was it fixed?
The implements a Connection service (which is implemented but not yet used by the p2p.BasePeer.  This service houses a Multiplexer and exposes the following APIs.

Mirrors access to the base p2p protocol from the Multiplexer.
Mirrors access to the remote from the Multiplexer
Meta-data about the remote connection like their public key, client version string, listen port, etc.
Meta-data about the handshake via the handshake receipts.
APIs for registering handlers for individual Commands or full Protocols.  This can be thought of as similar to the existing peer subscription API.

To-Do

[x] Clean up commit history

[x] Add entry to the release notes

Cute Animal Picture

Blocked by #887

Requested review from both @lithp and @carver just to get both of you to look at it.  I think Jason has seen this code before when I was presenting it in a preliminary fashion, but Brian has reviewed some of the recent pull requests in this feature line.


Enable flag changes in exposed API functions

These public APIs were created back in this ticket: https://github.com/tensorflow/tfjs/issues/760
But the code assumes a person would never want to turn these off once triggered.  I don't want them turned on all the time, so exposing an optional boolean to set them back to false.

To see the logs from the Cloud Build CI, please join either
our discussion
or announcement mailing list.

This change is

Hi @GantMan thanks for the PR.
Just curious what your use case for disabling these are? We're really not trying to use these flags as mutable state, they're supposed just be set at module initialization time (and I'm going to enforce that soon).

Hi @nsthorat - It's a noise to signal thing.
I'd like to enable verbose logging for a set of operations (a single one could, of course, use profile), to assist in potential debugging.  It's hypothetical, but reasonable that we wouldn't want EVERY operation to be logged, only a subset of my choice.
For perspective:  I'm providing a UI for enabling this.  And philosophically... what UI element can be turned on and never off?  Just hoping ot use it as a way to dig deeper if needed, and then turned back off.

I don't think this completely solves the issue you want to be solved. If you only want a few ops to be logged I would definitely recommend using the programmatic tf.profile() and filtering the response (which should be a JSON object). This is our blessed way of doing what you want programatically. The global flags aren't meant to be switched in the middle of the program, only to setup TensorFlow.js at the beginning (in fact flags are cached aggressively so there's no guarantee this will even work).

That's fair.   I can deal with that.
Do you have a way for me to PR the docs (I didn't see it in a glance) where I could put this information for people after me?

Here are the API docs, is this what you meant? https://js.tensorflow.org/api/latest/#profile

@GantMan there are also some flag related docs here https://www.tensorflow.org/js/guide/platform_environment if you want to take a look and see if they need any improvement. The source for that is located here

Thanks!!!


Add support for stress tests to nextest

Add support to run a single test multiple times in parallel. This is a somewhat different mode of operation from nextest as usual (the runner should be fed the same test multiple times, and should maybe not run other tests at the same time), but is worth doing as a future improvement.

Have done quite a bit of this in the past with Go. Some notes that may help:
In Go, tests are fairly similar; there are a few test binaries that get compiled then you can execute them like ./test and optionally add some filters. So all of our stress testing we do is on these binaries.
We use a tool https://github.com/howardjohn/golang-tools/tree/master/cmd/stress - there is an official Go variant but the fork has a lot more features.
Running it will output something like 129909 runs so far, 48 failures (99.96% pass rate). 34.237162ms avg, 15.518448036s max, 18.07186ms min every second or so. Failure outputs get written to a tempfile for later review (the command just shows a few lines of it as a preview to avoid spam). It also does some (very unsophisticated) logic to detect if an execution is running behind (logging something like process still running after 13.527344113s); this is useful since often failures end up happening in some test logic that is like retry for 10min { check something }, which can mask errors as we won't see any failures until 10min in.
Typically this is used on a single test or test package, focusing on a specific area, but we also use a wrapper that allows running on ~all tests, with some fixed test count or duration. This allows doing something like "run every test for 1000 executions or 1 min (whichever is fastest)" to analyze the entire codebase for flaky tests.
So overall, I think nice features are:

Run all or a subset of tests many times in a row, as fast as possible, in parallel
Report current status (execution count, failures, and runtime) in realtime.
Report slow executions, dynamically detecting what 'slow' is
Report each failure to a unique log for later analysis

In the meantime, I also created a bash helper that does this. Its a bit overcomplex and poor UX, but usage is like rust-flaker test-binary optional-regex-filter:
function rust-flaker() {
  relpath () {
    python -c "import os.path; print(os.path.relpath('$1','${2:-$PWD}'))"
  }
  clr='\e[0m'
  blue='\e[0;34m'

  executables="$(cargo test --no-run --message-format json | jq -R 'fromjson? | select(type == "object") | select(.executable != null) | select(.profile.test == true) | select(.target.kind | contains(["bin"]) == false)| .executable' -r)"
  want_name="${1}"
  local bin=""
  while read -r line; do
    name="$(basename $line | cut -d- -f1)"
    if [[ "${want_name}" == "${name}" ]]; then
      echo "${blue}Found test binary: $(relpath $line)${clr}"
      bin=${line}
      break
    fi
  done <<< "${executables}"
  if [[ "${bin}" == "" ]]; then
    "Test binary '${want_name}' not found, have:"
    while read -r line; do
      echo "  $(basename $line | cut -d- -f1)"
    done <<< "${executables}"
    return 1
  fi

  echo "${blue}Running test once...${clr}"
  $bin "${2:-}" || return 1
  echo "${blue}Running test repeatedly...${clr}"
  filter="${2:-}"
  shift; shift
  stress "$@" $bin "${filter}"
}

Thanks for the detailed overview @howardjohn!

Hi, @sunshowers Is this feature supported now?

Hi @iamazy. No, the feature isn't yet supported. I don't expect to get to it any time soon either, I'm too busy with other work.
However, I'd be interested in both design and engineering contributions towards this. I think the list of concerns mentioned in @howardjohn's post is a good start. I know @bmwill expressed some interest in implementing it but I believe he's been super busy as well.

Would love to see this implemented

Adding my two cents on the proposed design. Would like to see parallelization and repeats as separate configs. Or ensure the { max-threads = 1 } config for certain tests plays nice with this feature.


Add course confirmation and cancellation mobile tweaks

Currently if you go to add a course to the roadmap and cancel it on mobile, it looks like this.

I think when the add course modal shows, it should confirm the name of the course with the user so they can make sure they select next one. i.e. instead of saying "Where do you want to add this course?" say "Where do you want to add AC ENG 20B?"
Also, I think the course search shouldn't close until the user clicks submit on the add course modal. That way if they click the wrong one, they can cancel and go right back to where they were in the search component.

To be honest I think the whole flow of adding courses on mobile isn't the best.
I think it would make a lot more sense for there to be a plus button next to the schedule of each quarter, then when you click it you can search for classes. Each class in that list would then have a plus button or a trash can depending on whether it's in the list already or not – simply click that to change whether it's in the schedule.
This would be better for both of these (opposite) use cases:

Planning quarter by quarter – it would save a lot more clicks if you want to add 4 classes to the same quarter. It would be tap the plus on the quarter "schedule, search, click plus, search, click plus, (2 more times)" rather than "add courses, search, click, open year picker, pick year, open quarter picker, pick quarter, click submit, click add courses, search, click, open year picker, pick year, open quarter picker, pick quarter, click submit, (2 more times)"
Planning on a per-subject basis, where you plan a series of classes in a row across different quarters. It would be the same idea of "scroll to quarter, tap plus on schedule, search, tap the plus, (3 more times)", which is about the same amount of interaction required as currently.

https://github.com/icssc/peterportal-client/assets/54484616/f4e5e897-869f-459a-b4f7-ae3a6b320228


Leetcode Question Number 1672

Leetcode Question Number 1672 solution needs to be added in the repo .
The link for the question is this.
Accepted Languages C++ / JAVA .
You Only need to add the  class Solution in the file.
Make Sure you have read the contributions guidelines before creating an PR.

assign


Button Click Animations/ Hover Color Change

Tried to do this on my own and failed.

hover: your style, then
transition

@JaydenDev read the docs, it's hover: and transition-all

meh

searchocean is pretty much a failure, just look at it.


code to calculate gradient of alpha

Hi, @MarcelSimon
Thanks for sharing this code!
I am trying to find the code that calculate the gradient w.r.t. alpha, and I check the file caffe_pp2/src/caffe/layers/signed_power_layer.cpp
but can not find it, would you please show me which lines compute this? I only find the gradient w.r.t. bottom data.
Thank you!

Hi @Eniac-Xie
The source only contains the GPU implementation, hence you can find the diff at https://github.com/cvjena/caffe_pp2/blob/0a7d6efea371a82117410b289a090132fbab6bbe/src/caffe/layers/signed_power_layer.cu#L126  The CPU implementation is from the power layer, which I used as a basis, and hence does not implement the layer correctly. Sorry for the confusion, I will add an error message to the CPU implementation until there is one.

OK, thanks for your response!


Integration Guide

I should write a guide for integrating Carbon into a Graphene (or not Graphene) workflow.

I'm not sure how important embedding is going to be in the future with Carbon as the submodule.

This is now live in some form over at http://carbon.lpghatguy.com


Beautify the Footer.

I want to add the copyright in the footer,change the twitter icon to X icon and beautify the footer with all the required information.

I would be grateful if you assign me this task under the label Gssoc-ext,Hacktoberfest .My github username is @Bhanuprakash842

@Bhanuprakash842 Thanks for creating the issue in BuddyTrail!!! The issue has been assigned to you.
Before you start working on your PR, please make sure to:

⭐ Star the repository if you haven't already.
Pull the latest changes to avoid any merge conflicts.
Attach before & after screenshots in your PR for clarity.
Include the issue number in your PR description for better tracking.

Contributors will start at Level 1, and their level will increase based on the quality and quantity of their contributions. The more effort and value you bring, the faster you'll progress. Put forth your best effort to unlock new levels and opportunities!
I'm excited to see your contribution as part of GSSOC EXTENDED 2024! 🎉
Don't forget to follow me on GitHub for more updates.
Happy open-source contributing! 🚀


Kubernetes install instructions are broken

My actions before raising this issue

[X] Read/searched the docs
[X] Searched past issues

Following the instructions for the helm deploy fail.

The container names have changed, so the instructions for creating a super yser are out of date: https://opencv.github.io/cvat/docs/administration/advanced/k8s_deployment_with_helm/#how-to-create-superuser
I don't know if it's related, but on a clean install, the vector container fails.

Steps to Reproduce (for bugs)

git clone
helm dependency update ./helm-chart
helm upgrade cvat -i ./helm-chart -f ./helm-chart/values.yaml
run command to set admin password

Expected Behaviour

Connect to the pod and set the admin password
The system starts

Current Behaviour

Cannot connect to the pod because the container doesn't exist
The initializer job finishes with complete and I can't connect, if I change the container

Context
I cannot start the container in GCP
Your Environment

Git hash commit: ee1d421
Other diagnostic information / logs:

2023-09-25T22:01:26.170971Z  INFO vector::app: Internal log rate limit configured. internal_log_rate_secs=10
2023-09-25T22:01:26.175205Z  INFO vector::app: Log level is enabled. level="vector=info,codec=info,vrl=info,file_source=info,tower_limit=trace,rdkafka=info,buffers=info,lapin=info,kube=info"
2023-09-25T22:01:26.182483Z  INFO vector::app: Loading configs. paths=["/etc/vector"]
2023-09-25T22:01:26.204872Z ERROR vector::cli: Configuration error. error=No sources defined in the config.
2023-09-25T22:01:26.204918Z ERROR vector::cli: Configuration error. error=No sinks defined in the config.

I've had the same issues with a clean install. I'm also unable to login to the fronted or create a user. Changing the vector config, doesn't affect the problem.

Exactly same error for me, did you find a workaround ?

It's pretty hacky, but I did manage to get the tool somewhat working by editing the nginx config on the frontend pod. Just proxypassed the /api route to the backend service. Was planning on looking at this again later and comparing with the docker deployment to see what's going wrong.

Fixed in #7631


Fix docker wait-and-run.sh when POSTGRES_USER is different from POSTGRES_DB

When the postgres_user and postgres_db are different this causes a bug:
For example:
POSTGRES_USER=igor
POSTGRES_DB=trader
result:
FATAL:  database "igor" does not exist
Explanation of solution:
<EMAIL_ADDRESS>
If you run psql without a database name as an option, it tries to
connect to a database with the same name as the $USER psql runs as.

Looks good.

Looks good to me.  We'll probally want to update the importer as well, as it uses the db as well.

:+1:


mixin() function

I think https://github.com/Im0rtality/Underscore/issues/41 could be solved with this by changing how __call and __callStatic works. This would require allowing to mixin initializers, mutators and accessors.


clusterrole admin/edit/view is null

we have created clusterrole admin/edit/view, but the rules is null. for example:
 get clusterrole edit -oyaml
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.authorization.k8s.io/aggregate-to-edit: "true"
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2023-02-07T14:36:46Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
  name: edit
  resourceVersion: "88"
  uid: 38dcc816-3e5e-4e7c-a9ba-a8ba824e25f5
rules: null

The expected behaviour is there are correct rules inside.

/close


Feature/forum UI development

Task: https://freedcamp.com/view/2956183/tasks/panel/task/40404049

Please fix the UI and missing key issues.

For this issue,  currently the sort icon show when click the head. but by default, it will be not shown, @ngvtuan.
Except for it, all UI issues are resolved.

Thanks  to all of you, @CrazyOptimist, @ngvtuan .


Support to SoapHeader

Hi, and thank you for this great library.
Unfortunately, I would need suppport to SoapHeader, to set an authentication header, but, I'm not able to manage it with this facade.
Is there any way to get it?
The final result on XML should be:
<soap:Header>
  <AuthHeader xmlns=".../">
    <Username>user</Username>
    <Password>password</Password>
  </AuthHeader>
</soap:Header>

Thank you in advance

Hi!
Thanks for getting in touch and raising an issue, it's much appreciated. We will look to have this implemented in the coming week, will drop a comment when we have done so.

I started to implement something working. I can open a PR so you will have a starting point for this feature, what do you think?

@giraz82 please do!

@lukeraymonddowning here we are

Need this feature ASAP!

We have opened #23 for this feature.

Really nice job, it works like a charm within my code.

Thos has now been merged and released in 1.3.0


Liquid syntax error: unknown tag 'google_map'

Hi, I was trying to put map in my site. I was following your steps. But it keeps saying Liquid Exception: Liquid syntax error (line 44): Unknown tag 'google_map'.
Does anyone encounter this before?

Hi! Have you checked #21 ? Did you install the plugin with bundler?

@ayastreb Hi, thank you for your superfast reply, Yes I have checked it. I installed plugin with bundler and I can see it with : gem list | grep jekyll, it gaves: jekyll-maps (2.0.4)
I also double checked my _config.yml:
plugins:

jekyll-paginate
jekyll-sitemap
jekyll-maps
jekyll-gist
jekyll-feed
jemoji
there is no other plugins session in the file.

Btw , Happy new year


Multus proxy keep crashing

Multus proxy service keeps restarting every minute. And the logs says
E0423 20:21:26.983615       1 pod.go:373] failed to get cri client: failed to connect: failed to connect to unix:///host/run/crio/crio.sock, make sure you are running as root and the runtime has been started: context deadline exceeded
F0423 20:21:26.984069       1 main.go:65] cannot create pod change tracker

It is now pretty early stage of development, hence everything may be changed without any notification. Please do NOT use it as production. We don't support any question about how-to-use/how-to-deploy until current development status is changed.

As of above (described in README.md), let me close this issue. From the error message, your multus proxy cannot connect to container runtime. Please check your container runtime configuration and change that (which is in muluus-proxy deployment in deploy.yml file).


Update oauth and data publisher versions

This will incorporate fixes  done in oauth and data publisher repos w.r.t OAEP encryption.
1.https://github.com/wso2-extensions/identity-inbound-auth-oauth/pull/807
2.https://github.com/wso2-extensions/identity-data-publisher-oauth/pull/14

Closing this as the version update is already done with 6cff759ee38c72b2a1fe6fa9909bba554018a265


Do enable and  disable modules

Hello,dear Mr Nicolas Widart
I have a problem that i cant resolve it and i was hoping you could help me.
I work with your package.
I created a module with name:Users  and i enabled that,this module contains of one Model with
name:User.i can Fetch my users information's with this modules and Model:User with below code :
$users=User::find(1)->first();
But when i disable Module:Users,i can Fetch my users information's again! .but I do not want to
have access to Model:User and Module:Users when this module is DISABLE .
I do not understand the concept of this case(disable/enable).
Thank you for reading this issue.
Best wishes .

I'll close this as there hasn't been a reply in a while, feel free to comment if needed.


Accessibility Plugin does not reload page before running tests.

I have encountered cases where running the chrome accessibility tests can cause Stale Element Reference. See: #2331
This can happen because browser clicks can create dom elements that get removed for some reason while the chrome accessibility tests are running. A good way to mitigate this problem would be to do a browser.refresh() before running the accessibility tests.
This could be added as an optional parameter in the protractor config.

Is this something the devs also think would be helpful to add?
If added should it default to be enabled or disabled?

Moved to https://github.com/angular/protractor-accessibility-plugin/issues/7


🧑💻: Add Hover effects on Enter button.

:red_circle: Title :Add Hover effects on Enter
:red_circle: Enhancement Aim :To give better user expererience.
:red_circle: Changes : Add Css related to that.
Screenshots 📷

I will add hover effects on this.

:white_check_mark: **To be Mentioned while taking the issue :**Zala Bhavy

Full name :
What is your participant role? Gssoc'24

Happy Contributing 🚀
All the best. Enjoy your open source journey ahead. 😎

kindly assign this issue to me i feel adding a couple of css classes would do the trick and it will be having a really good UI

@zalabhavy go ahead.


External downloader not working for 1dm

Steps to reproduce
1 Open download settings
2. Chose ' Always use external downloader for anime'
3. Chose 1dm
4. Nothing happens, downloading didn't start in 1dm
Expected behavior
When click on download button it should start in 1dm
Actual behavior
Nothing happens it shows exclamation mark on download button
Crash logs
No response
Aniyomi version
<IP_ADDRESS>
Android version
Android 12
Device
Redmi note 10 pro
Other details
I installed ADM but there is no option for ADM to choose
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] If this is an issue with an extension, I should be opening an issue in the extensions repository.
[X] I have tried the troubleshooting guide.
[X] I have updated the app to version <IP_ADDRESS>.
[X] I have updated all installed extensions.
[X] I will fill out all of the requested information in this form.

Have you tried downloading with the internal downloader first?
I use 1DM and it works well


feat(bindlings): add useStateManager()

WIP

Warnings

:warning:
There are no updates provided to CHANGELOG. Ensure there are no publicly visible changes introduced by this PR.

:warning:
New package.json added: packages/react-bindings/package.json. Make sure you have approval before merging!

:warning:
New package.json added: packages/state/package.json. Make sure you have approval before merging!

  Generated by :no_entry_sign: dangerJS


Duplicate Squeezelite MAC address if app is copied between devices

I recently got a new Android phone, and used its setup wizard to copy apps and settings from my old phone.  This exposed a couple of problems, one of which is:
Things go haywire if I try to use Squeezelite on both Android devices at once, because this app is giving them both the same fake MAC address.  I worked around this by clearing LMS Material’s storage on one of the devices and setting it up again.
It’s possible to exclude things from being backed up, but I’m not sure if that would prevent them from being copied like this.  A note in the wiki might be the simplest solution.

Next release will prevent backups, so will work-around this.


Feature Request: Force stop/remove-job

Stop-Job can take a long time or forever depending on what you have started. See for example this or this.
Adding -Force should bring it down imediatelly.
Remove-Job has force param but it still hangs.

@majkinetor Can you a standalone, easily reproducible example snippet here?

Hi @NoMoreFood,
I've come across this recently when using Jobs for Sockets/HttpListener. A simple example is:
Start-Job -Name Example -ScriptBlock {
    $listener = [System.Net.HttpListener]::new()
    $listener.Prefixes.Add('http://*:80/')
    $listener.Start()
    $listener.GetContext()
}

Calling Stop-Job -Name Example will just hang forever, or take 5mins+ to stop on some machines. Remove-Job -Name Example -Force exhibits the same issue as well.

Note that this must be executed in admin shell or it will just complete with 'Access denied'.
Note also that it doesn't only avoid stopping, but also completelly renders Powershell session unusable.


After Steam update RemotePlayWhatever doesn't work

Client Steam
Build from 16 November 2022
Steam API: v020
Version Steam package:<PHONE_NUMBER>
I think Steam change something in API

Client Steam Build from 16 November 2022 Steam API: v020 Version Steam package:<PHONE_NUMBER>
I think Steam change something in API

Yeah, I have the same issue the app won't launch since the steam update.

+1

+1

+2 Also not working here.

Working on it. Might take some to update OSW.

How much longer to wait?

How much longer to wait?

You can open a pull request if you have a fix to share.

Tag 0.2.1-pre-alpha works for me! Thank you very much!


Added support for - as a valid character in the LHS of rules

Hello,
I added support for highlighting hyphen (-) separated rule names. Seems to be working.

Hi Jean,
Thank you for taking the time to submit a pull request.
Can you give me example of the EBNF language feature you would like to have highlighted?
The current implementation is according the official ISO paper defining EBNF grammar (https://www.cl.cam.ac.uk/~mgk25/iso-14977.pdf).
To extend the syntax highlighting of EBNF you have to edit ebnf.YAML-tmLanguage and then generate ebnf.json based on it. Check the README file in syntaxes directory.


Fix v1.12 archive build

Add the v1.12 archive directory to keep_files to
prevent Jekyll from removing the directory when
building the main docs.
ping @mstanleyjones @johndmulhausen PTAL

OMG 💯 :1st_place_medal:

slaps forehead


"Instance got rescheduled" should not be treated as failure

Originally reported by Andrea Bolognani in libvir-list:

Since I have your attention, I'll also report the only issue we've
encountered so far that might be a genuine bug in cirrus-run. If you
look at this recent pipeline
https://gitlab.com/libvirt/libvirt/-/pipelines/170028119
you'll see that the x86-freebsd-12-build job has failed; however if
you look at the corresponding Cirrus CI job
https://cirrus-ci.com/build/6133607741784064
you'll notice that it has completed successfully. We've seen this
happen about once a week on average. It's as if cirrus-run somehow
lost track of the status of the Cirrus CI job...
Unfortunately I haven't had time to dig further, but if there's any
information that I could provide to help you figure out what's going
on please just ask.

In this case Cirrus CI instance was rescheduled (likely due to VM being preempted by GCP) and cirrus-run incorrectly reported build failure.
Timing of cirrus-run failure (24:19) roughly matches the timing of first run attempt at Cirrus CI (00:01 + 05:04 + 19:10). Rerun was scheduled 2 seconds after initial run ended. It is very likely that during those 2 seconds API returned some status value that indicates build failure (FAILED/ABORTED/ERRORED) - specifics would have been available if such failure was caught in verbose mode (cirrus-run -v)
I do not see any field in GraphQL schema that would indicate the build is being rerun. Possible workaround would be to add some timeout (5 seconds?) to check build status again before reporting build failure to the user (cirrus_run/queries.py:wait_for_build).

Workaround has been added to master.
Since the source of the problem was deduced almost on a hunch, without any hard evidence, there is a chance that this fix is not enough.
I'll leave the issue open for a few weeks to gather feedback.

@sio does running cirrus-run in verbose mode cause severe slow downs or anything like that? If not, we can temporarily switch libvirt's jobs to verbose mode and hope to catch another occurrence of rescheduling that way.

No, no slowdowns at all. Just a lot of noise in stdout :-) One '-v' is enough for this case.
After adding the workaround described above I've experienced an automatic rerun in Cirrus CI which was handled correctly by cirrus-run: GitLab, Cirrus. Cirrus-run waited until the second run was finished and fetched logs for both runs.
Nature of this rerun was somewhat different though (it was not caused by GCP preemption), but that still speaks in favor of existing fix. I've noticed that a rerun occurred only because it was a genuine build failure which I went to investigate.

All libvirt pipelines starting with https://gitlab.com/libvirt/libvirt/-/pipelines/174107420 are now using verbose mode. Hopefully a couple of weeks worth of data will be enough to confirm the issue has been solved for good :)

It seems that there were no more misreported build failures in libvirt/libvirt (by the way, do any other repos under libvirt org use cirrus-run?)
I think I'll go forward with 0.3 release chores in the next couple of days.

It seems that there were no more misreported build failures in libvirt/libvirt (by the way, do any other repos under libvirt org use cirrus-run?)

Not yet... I haven't had the time to crate jobs for the other repos, though it's definitely something that we want to do.

I think I'll go forward with 0.3 release chores in the next couple of days.

If you think you have enough data confirming that this and the other changes are good, then it sounds like a plan :)

I have encountered three automatic re-runs in Cirrus CI since the workaround has been implemented. All of them in my own project, none in libvirt:

GitLab / Cirrus
GitLab / Cirrus
GitLab / Cirrus

All of them were handled correctly by cirrus-run. I think it's safe to assume the workaround is sufficient. Thank you very much for your help!
I wrote a helper script to query Cirrus API for builds with more than one task (since there is no way to detect re-runs I'm just looking for unexpected number of tasks in a build): https://github.com/sio/cirrus-run/blob/inspect-issue-4/inspect.py I've run that script against both my repo and libvirt/libvirt, it just so happened that libvirt didn't encounter a re-run within the last 100 builds.
I've just released v0.3.0 and I'm closing this issue now. Feel free to reopen if some new information arrives.


Boundary corruption when loading ParMesh created by ParPrint

I am seeing the number of boundary elements being padded by non-boundary elements when loading a parallel mesh that was created by ParPrint from a ParSubMesh.
To demonstrate the problem, I have created a simple program in the attached tarball.  The program is compiled for Ubuntu Linux, and you may be able to run it as is.  If not, I have included a make file.
There are three examples called mesh19, mesh20, and mesh21 in the tests directory.  Each includes a mesh generated by ParPrint with differing numbers of slots: 19, 20, and 21.  The starting mesh is the same in each case, so the only difference is the number of slots.  If the program runs for you as-is, then you can execute each example by running ./run.sh in each test directory.
For each test, examining the mesh files shows a total of 8 boundary elements.  When I run example mesh19, I get an output showing 8 boundary elements, which is the expected result.  Running mesh20, I get 11 boundary elements, with the extra being internal to the problem, which then leads to an incorrect numerical solution in my application.  Running mesh21, the output is again the correct count of 8.
By the way, I am using MFEM 4.6.
meshtest.tar.gz

Thanks for the demonstration, will have a look at it more thoroughly. However, I am not sure if it is a bug, but a feature 😅 ParMesh is a distributed mesh, which means that every peer has a piece of it. The methods for printing the mesh then do not reconstruct a monolithic mesh again, but simply collect all pieces of the mesh to a single file. This way, you may see how the mesh was split, which is sometimes very useful for debugging etc., but other times it may cause troubles...

Check PrintAsSerial if it is not what you are looking for by chance 😉

Ok, I'll look forward to hearing how it goes.
I need ParPrint because I use ParSubMesh to extract a 2D port mesh and write it to a file.  Then the 3D program spawns a separate 2D simulator that imports the 2D mesh, solves, and writes out the computed port DOFs.  Finally, the 3D program imports the DOFs to keep working.  I need ParPrint to work consistently or I end up with re-ordered DOFs between the 2D and 3D programs that corrupts the 3D solution.

So the question is, do you want to follow the partitioning of the 3D mesh in 2D or not? If I understand it correctly, you do not want to respect that in the 2D solver if it is parallel as well and you probably want to redistribute the whole thing among the processors. You are only concerned about returning from this 2D system back to 3D, right? If this is the case, try to output that "serial" mesh and solve the 2D problem with that. We will need to figure out then how to invert the partitioning...

Yes, I want the 2D solver to follow the 3D partitioning.  I have to maintain the distribution of the mesh between the 2D and 3D solvers.  Otherwise, the DOFs get re-ordered, and I cannot import the 2D solution into the 3D solution.  If I use the serial mesh output, then the 2D solver will partition the mesh differently than the way the 3D solver did it, and the DOF orderings between the 2D and 3D solvers will be different.  When I use ParPrint, then the imported mesh in the 2D solver distributes the same as the 3D solver, the DOF orderings remain the same, and my solution exported from the 2D solver reads into the 3D solver with the correct DOF order.

I think you are making a bit too many deductions here, that DOF ordering is one thing and that is something we need to sort out, but more important is what you need for the code itself. As I read it, it does not make any sense for you to use the 3D partitioning in 2D, because the submesh will be distributed just among a small fraction of all processors (if you do not do some trickery with the partitioning). So again, please try to export the serial mesh from 3D and import it to 2D. If this works, and you get some reasonable result there, we may explore the ways how to get it back to 3D.

I already went down the serial output path, and it doesn't work for the reasons that I explained.  I exchanged emails with Mark Stowell on the issue, and he recommended that I switch over to ParPrint on Oct. 11, 2023.  This methods works great except for the occasional corruption that I documented.
This is a fairly mature project.  I presented my 3D work on OpenParEM3D at https://mfem.org/seminar/ on Jan. 9 about a month ago, and I presented my 2D work on OpenParEM2D at https://mfem.org/workshop22/ in Oct. 2022 after 1 year of work.  The 2D simulator has an automated regression suite with 27 cases with something like 40,000 individual tests.  The 3D simulator currently has an automated regression suite with 22 cases with about 750 individual tests.
I'm not looking to re-architect and re-write 30,000+ lines of code from a 2.5 year effort and about 5000 man-hours of labor to work around the ParPrint bug.  Can we just get ParPrint fixed?

It is not a bug of ParPrint, it saves the mesh as a parallel mesh, i.e. topologically discontinuous, which implies extra boundaries, nodes, faces etc. Maybe I am missing something here, but using the 3D partitioning in 2D is highly inefficient as I explained, so I am trying to help you here to improve it. Changing the way the mesh is loaded is not a big deal I believe, basically just swap the constructor of ParMesh. With that DOF reordering, I am willing to help and we may consider making some new methods for that.
Otherwise, if you insist to use principally incompatible partitioning in 2D then we need to find a way to identify the interior boundaries and you will have to filter them out in whatever procedures you do with them, which is not exactly a smooth solution.
One more thing to be sure we are on the same page, do you see those boundary elements already on the side of the 3D code before exporting the mesh?

I'm not concerned about efficiency in the 2D solver since 2D solves represent a tiny fraction of the overall 3D solve times.  However, more efficiency is better than less efficiency.  I just don't want to spend a lot of time on it.
Per your question on boundaries, the ParSubMesh functionality creates the boundaries for the 2D meshes as needed.  So yes, they are seen in the 3D code before exporting the 2D mesh.
My 2D program can read serial or parallel meshes.  The issue is how to get the solved 2D fields into the 3D solver to apply as boundary conditions at the ports.  The 2D tangential field solution must be forced at the driven port in the 3D space.
From 3D mesh to a 2D port mesh file:
import 3D mesh -> ParMesh -> ParSubMesh for 2D ports -> custom processing [rotate, flip (if necessary), set space dimension, drop z] -> save 2D mesh file
2D solver (frequency domain using Petsc/Slepc complex numbers):
import 2D mesh -> solve complex vector fields on the port -> Petsc complex Vec of DOFs -> Petsc VecView to file
From 2D solution to 3D boundary condition:
custom 2D import [DOFs] -> ParGridFunction (built off ParSubMesh fes) -> transfer to 3D ParGridFunction (built off ParMesh fes) -> 3D solve -> 3D ParGridFunction -> etc.
Going from 3D to 2D is no problem in either serial or parallel.  The issue is how to get the 2D solution back into 3D.  My understanding is that MFEM is built around the DOFs being in proper order in Vectors, so I have to get the ordering exactly right across distributed vectors.  Right now, I rely on ParPrint to keep the ordering in place across common partitioning in the 2D and 3D simulators, but that works only almost all the time.  Hence the point of this ticket.  If there is another way to get the 2D solution back into the 3D space, then I can try that.

I meant if you see those "non-boundary" elements in 3D, but I guess you do. That almost is then probably the case when the partitioning assign the whole boundary to a single processor, so you have a serial mesh in 2D virtually. Am I right?

If I understand correctly, I think you just want to turn off ParMesh::print_shared (using ParMesh::SetPrintShared) in order to avoid printing the subdomain boundary elements along with the true boundary elements when printing the parallel mesh to disk. This is on by default because I think it is used by visualization programs like GLVis.
That said, it sounds like your entire workflow would be drastically simplified by just using SubMesh/ParSubMesh and the corresponding transfer methods for GridFunction objects, and not dealing with any file IO.

I added a line for SetPrintShared:
     parSubMesh->SetPrintShared(false);
     parSubMesh->ParPrint(parout);

I see the same behavior as before.

If you just use ParPrint from a true (2D) ParMesh, do you get the same issue? Is this related to ParSubMesh or generally to parallel meshes?

I don't have a way to test vs. a true 2D ParMesh.  All of my 2D meshes are generated by ParSubMesh.

@sebastiangrimberg , that option SetPrintShared is only for Print, not for ParPrint. It seems to me that you have generally problems with discontinuity of the mesh for the 2D solver. If I am right that the code worked when the whole boundary was assigned to a single processor, which might be very often, then the simplest solution would to use some manually constructed/modified partitioning, which would guarantee this 😮

My setup works fine when the 2D mesh is distributed across multiple processors.  Different examples and setups distribute in different ways depending on how the mesh was split up with ParMesh and ParSubMesh.  It is not the case that I sometimes get lucky and have all of the 2D mesh on a single processor.  I get the same answer no matter how the mesh is split across processors in the 2D solution except when ParPrint makes interior mesh elements into boundary elements.

Yes, it could be in ParSubMesh.
I can put together an example starting with a mesh, going to a ParMesh, going to a ParSubMesh, then ParPrint.  That will be far more involved than my prior example and will take some time to code, debug, and test.  I'll post back when I have that.

Do not spend too much time on that, just something simple 😉

I put together the attached test package that demonstrates the issue starting with a mesh produced by gmesh.  If you need to compile, there is a make file.  If not, you can just go to the test directory and run "./run.sh".  It sequences through 30 ranks and produces a pass/fail message for each run.  The results I get are in the file "results.txt".
meshdemo.tar.gz

I don't think I understand your question.  The 3D mesh is created in gmsh.  After that, how the 2D mesh is created is documented in the source code of the example I provided.  I'm not using any meshing utility outside of MFEM.

I have a likely culprit but I haven’t tested it. In Mesh::FinalizeTopology, there is a bug where elements are generated for a parallel mesh when a subdomain has no boundary elements but the parallel mesh does. This is probably triggered when you’re constructing your ParSubMesh. This bug is actually fixed as part of https://github.com/mfem/mfem/pull/2669, an old PR. You can cherry pick the changes involving ReduceInt in mesh.cpp and it should resolve your problem, I hope.

In Mesh::FinalizeTopology, there is a bug where elements are generated for a parallel mesh when a subdomain has no boundary elements but the parallel mesh does.

@sebastiangrimberg I think this is the intended behavior. You can't compute on the SubMesh otherwise.

You're right, it does look like ParSubMesh calls FinalizeTopology(false); and so the mesh partition boundary elements shouldn't be generated in any case. Perhaps though there is some issue with the ParSubMesh constructor creating extra 1D boundary elements in parallel when constructed from the boundary of a 3D mesh? Not sure about this, but that's where I suspect something is going on (should be easy enough to trace this issue down).

Hmm, I see a different story here. I tried the code on 16 slots and the test truly fails, showing 11 boundary elements, but the files look totally fine to me with 8 boundary elements in total (also glvis sees that 🙂 ). I played with the test and it seems that the extra boundary elements are generated during finalization of the loaded mesh when refine or fix_orientation are true. @M8kmyday , could you confirm that with refine and fix_orientation being false the test passes on your machine?

Oh my, it is terrible 😩 . The thing is Mesh::GenerateBoundaryElements() is purely serial and does not check anyhow if the edge is shared or not. It is just luck if the loaded local mesh has at least one boundary element and then everything is ok and the original boundary elements are preserved even when the local mesh has many more shared edges. Otherwise when there is no original boundary element, the method generates a boundary element for every shared edge. This is totally inconsistent and not meaningful anyhow for distributed meshes 😔 .

I was checking your request, but it does not look like it is needed now.  Let me know if/when I can help.

@M8kmyday , have you tried that refine and fix_orientation? If they are both false, that generation of boundary elements is skipped altogether. So please try it.

I can't see how to set fix_orientation.  There isn't a method, and it is not in a constructor.  I can set it using ParMesh::Load, but for that I need to construct a ParMesh on a communicator, and I do not see how to do that.  I can create a blank ParMesh, but I don't see a method to set its communicator.  How can I set fix_orientation?

It is in the constructor, try this ParMesh(PETSC_COMM_WORLD, ifs, false, 0, false);.

It does not work for me:
meshtest.cpp:22:57: error: no matching function for call to ‘mfem::ParMesh::ParMesh(ompi_communicator_t*&, std::ifstream&, bool, int, bool)’
There are 5 arguments in your ParMesh call, but the longest ParMesh constructor only has 4.  The constructor to load a mesh only has three arguments, and I can set refine there.  That still leaves fix_orientation.

You need to use the master branch of MFEM, exposing these arguments was introduced in https://github.com/mfem/mfem/pull/3918.

I'm on the production release, and to switch to the Master branch will require a 1 hour re-compile, and then I won't be on the production release.
Since this is a near-trivial change to my test program, can one of you that are already on the Master branch make that change and try it?

I'll go ahead and compile the Master branch.  It can just grind away in the background while I work on other stuff.

I have tried that of course (without PETSc though, just MPI) and it worked for me, so I wanted to check if it is the same problem you had or something different, because the description sounded somewhat different. However, it is not meant to be a solution for your main code, because you will probably experience problems with the mesh when orientation of the faces is not fixed, but you may try it. I have put together a solution, but I am testing it and wanted to check this with you first.

make config is failing for me:
make[1]: Leaving directory '/home/briany/Desktop/mfem-4.6.2-rc0/config'
cd "." && ln -sf "/home/briany/Desktop/mfem-4.6/data" .
ln: ./data: cannot overwrite directory
make: *** [/home/briany/Desktop/mfem-4.6/makefile:647: build-config] Error 1

Ok, I just pushed the fix in #4128 . Try it (even with the old version of MFEM eventually) and let me know if it works. We would close this one in favor of the PR 😉 .

I downloaded and compiled mfem-najlkin-pmesh-load-fix, but somehow, it is still pulling in parts of mfem-4.6.  Can't seem to track down why.  I'll try again tomorrow.

Got it compiled, and I see the test setup working properly with no failures.  I re-compiled my simulators and ran the 3D regression suite, and I do not see the failures I was seeing before, and nothing new cropped up.  It looks like a 100% fix to me.

Good to hear! :wink: Closing this one in favor of #4128 .


Google Analytics: API Update

The Google Analytics package that this project calls has been updated in a backwards incompatible manner.  These edits are updates to address these changes.
This API clash is currently causing users of ng-cordova to be unable to log properly in Google Analytics after fresh builds.
Note:

For an unknown reason (at least to me), a unit test is broken for $cordovaToast before I made any edits. Not sure what's causing it, but it should be pop up if retest your master branch as well.
This contains the same edits as https://github.com/driftyco/ng-cordova/pull/1392 which is based off the master branch instead, given the current release doesn't work with the current release of https://github.com/danwilson/google-analytics-plugin

@gortok why this haven't been merge? this is needed change for ngCordova to work with GA. I am the maintainer of GA; I got a lot of issues related to this.


Creating a new application errors

The output from Openshift is the following
The initial build for the application failed: Shell command '/sbin/runuser -s /bin/sh 5684552c7628e1ecff0000bb -c "exec /usr/bin/runcon 'unconfined_u:system_r:openshift_t:s0:c3,c392' /bin/sh -c \"gear postreceive --init >> /tmp/initial-build.log 2>&1\""' returned an error. rc=255

I've sometimes noticed unpredictable errors when doing git push and I think they may have been related to #17, which is now fixed (I hope :-) )
Can you reproduce with a new cartridge?

Any news on this one?

I'm no longer able to reproduce this :-)

Thanks! ;-)


resnet v2 maybe better?

I have a question about resnet here:
layers/resnet.py
Google says resnet v2 maybe better ?
resnet-in-tensorflow

Probably~, You can try to make a comparison.


Integration tests for RedisBackedJobManager

Suite of automated tests (not necessarily yet passing) for verifying behavior of RedisBackedJobManager implementation and its interaction with Redis instance.

@robertbartel A test in the communication suite is failing with this PR.  Do you want to fix that before merging?

@hellkite500, yeah, let me work in a few more changes before we fully merge this in.


Feature/i230 authorisation

Authorisation mechanism for users
Upon authentication (either via database / LDAP / CAS), a call is made to the specified LDAP server to query the user's employeeType and extract the employee_type_code.
Also defines new abilities corresponding to the authorisation of the user.
https://github.com/antleaf/nims-mdr-development/issues/230

merge conflicts resolved


Implement bigtable_check_table_exists sample.

The region tag is bigtable_check_table_exists.
This example is described as "Check if a table exists" there is one implementation in other languages:
https://github.com/googleapis/google-cloud-python/blob/f29e36ca7d8b5502be72b5edc2767e9b5a794abe/bigtable/google/cloud/bigtable/table.py

This is a duplicate of #2299.


AMP-64943 update CI workflows to use self hosted runners to access st…

…aging APIs

The runners are currently failing to process jobs due to the repo being public. I am working with @ersmith to resolve.


pry gem dependency

Missing D:

Yeah, i'll add it when i release the Pry gem since i need to specify a version too


ignores rules from tslint.json

I have this tslint.json:
{
  "rules": {
    "semicolon": [true, "always"],
    "no-consecutive-blank-lines": true
  }
}

And this code in example.ts:
if (true)
    var a = 1

var a = 1

I run:
node_modules/.bin/tsfmt ./js/*.ts -r --useTslint ./tslint.json
And nothing changes. But I expect semicolons to be added and extra empty lines to be removed.
It follows the rules from tsfmt.json though, related to indentation and whitespaces.
I also found that running tsfmt ./js/*.ts -r --useTslint ./tslint.json (without node_modules) produces very weird formatting that does not follow any rules.

I expect semicolons to be added

tsfmt uses compiler api of tsc.
this behavior is not supported by tsc.
I recommended to use tslint --fix option.
https://github.com/palantir/tslint#cli-1
patched welcome!

@vvakame But update file twice makes no sense.
Can't use pipe the output from tslint --fix into tsfmt somehow?


Implementation of semantic highlighting

I took a liberty to implement basic textDocument/semanticTokens request handling based on proposal here : https://github.com/microsoft/vscode-languageserver-node/blob/master/protocol/src/protocol.semanticTokens.proposed.ts.
Adjusted VSCode plugin accordingly

Semantic token disabled :
enabled :

Notes:

I'm using editor.open sourcekit query to get as much data as possible to construct sematic tokens, it wasn't enough, so I needed to access indexed symbols (for type references detection) thus IndexStoreDB dependency added for server implementations.
token modifier are not covered
token legend is hardcoded - eventually it should be negotiated between server and client
Requires Visual Studio Code Insiders build (nightly builds) as it uses proposed API
Could use some more tests

About editor.open request and indexed symbols - do you see any other way how to gather token data? I think index and doc_info requests from SourceKit would provide more than enough additional information to properly parse semantic tokens, but I guess since workspace management and index is handled externally, those requests can't be used directly (I was getting 'missing primary file' errors when experimenting with it, altough I didn't spent much time trying to make it work)? Any suggestions here?
Cheers!

Wow, very cool!
You should be able to get everything you need directly from sourcekitd.  Using the index is straightforward for a document that hasn't been modified, but it will quickly get difficult to keep up with changes.
Luckily, sourcekitd provides both syntactic tokens (what you are using now) as well as semantic tokens, which should allow you to colour type references, etc.  The trick is that the semantic tokens are not returned directly by opening the document - instead they get calculated after we build an AST, at the same time we produce semantic diagnostics.  Here is how it could work:

Instead of opening a new document, capture the syntax map from the existing one -- when we do textDocument/didOpen  we currently ignore the syntax map, but you can capture it there.
We can get semantic tokens after an AST is built, which will send a notification_documentupdate. To capture the tokens, you will want to modify handleDocumentUpdate.  The same sourcekit response that we are using for diagnostics there will also contain the semantic tokens in the same format as the syntax map. https://github.com/apple/sourcekit-lsp/blob/5cc541312d6221f58dbf38e2c3376eb98721ce61/Sources/SourceKit/sourcekitd/SwiftLanguageServer.swift#L132
Update the information after edits. During textDocument/didChange, we perform a "replacetext" request to sourcekitd, which returns the set of modified tokens.

I don't know if the exact details of which tokens will be returned after an edit are documented, but feel free to ask any questions you have on the forums and I or someone can help out. @nathawes was the last person to make major changes to the highlighting API in sourcekitd, so maybe he knows if there was any documentation.

The Swift project moved the default branch to main and deleted master branch, so GitHub automatically closed the PR. Please re-create the pull request with main branch.
More detail about the branch update - https://forums.swift.org/t/updating-branch-names/40412

Is this completely dead ? Since semantic token have moved out of proposed state.

Sorry, I was quite busy with other things past few months - I have plan to pick it up starting today and push some changes in next few weeks

I have https://github.com/apple/sourcekit-lsp/pull/388 to add the Language Server Protocol types for semantic highlighting as well as clangd support, once that is submitted we'll just need to rework this PR in order to add Swift semantic highlighting.


Error in testing the ORM module ( follow-on)

After making these changes, i was able to. get past the error complaining about cls= , but now
it fails with this error:
anvil.tables.TableError:` Column 'uid' is a number - cannot set it to a string
in this code:
in orm_server/persistence.py
row = table.add_row(uid=uid, **members)
## uid is a string here . uid = uuid4().hex
i fixed that by doing uid = int(uuid4().hex, 10)      ## in code a few lines above
but that led to more errors , i gave up ....

That's another bug in the tutorial. The uid columns in the data tables should be text columns rather than numbers. (We used to use an integer sequence for the uid but we swapped to a uuid and the tutorial didn't get updated).


Add API v2 module

This pull request starts off the new v2 API. The endpoint is located at /api/v2beta/.
The first commit copies the V1 module to wagtail.api.v2. All subsequent commits are changes that I'd like to be in the new v2 API.
Changes in v2 API so far

All available fields are shown in the API by default
Multiple page types can be specified in type filter
Add html_url to page meta
Show download_url on document listings
Removed meta at top of listings
Renamed results list to results (previously copied endpoint name)

Future changes in v2 API

New representations for tags and streamfields
Better errors
Assign a code for each possible error
Include any useful information as separate fields on the message
Link to doc explaining the error
?fields= has power over id and meta subfields too
More control over summary fields
More fields by default (slug, first_published_at, expires_at, show_in_menus)
Special urlpath field that can be used for routing when filtered on (eg: ?urlpath=/blog/)
API root (#1921)
Search operators (#1972)
Allow true/false as filter values for boolean fields (currently, you have to use 1/0)

Rebased onto #2002

Is there an upgrade path planned from v1 to v2?
What happens if we are currently using v1, can we run v2 at the same time?
Is v2 intended to replace v1 outright in a future release/are you dropping support for v1, so if we are stuck on v1 because we can't force consumers to upgrade does that mean that down the line we won't be able to upgrade to a new release?

Yep, it would be possible to run multiple versions of the API alongside each other in the same site.
The plan is that Wagtail will always support two versions of the API. A "stable" version that will never change and an "unstable" version where new features get added.
This pull request adds a new version "v2beta" which would become the "unstable" version. If getting clients to update is difficult, I don't recommend that you don't update to this before it's stabilised. When it is stabilised, you would be able to run both the old v1* and the new v2 APIs side-by-side giving a window for clients to update.

When we stabilise a new version of the API, we would move the previous stable version into a pip-installable package so you could continue to use it for as long as you need.

Github has missed this commit (should be right at the beginning): https://github.com/kaedroho/wagtail/commit/a63d5832d05b1b2bcc47963dd338e0ec889db7bc