ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
kenny has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
jfsimon has quit [Max SendQ exceeded]
jfsimon has joined #rust-embedded
Hallo124 has quit [Remote host closed the connection]
Hallo124 has joined #rust-embedded
Hallo124 has quit [Ping timeout: 272 seconds]
pbsds35 has quit [Quit: The Lounge - https://thelounge.chat]
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
BentoMon has quit [Ping timeout: 252 seconds]
corecode[m] has joined #rust-embedded
<corecode[m]> i'm trying to do tdd using mockall - using a lot of wrapped vendor code. tests are quite painful and complicated. am i missing something to make test setup easier?
<corecode[m]> the result is great, the firmware just runs well because everything is tested on host
Ralph[m] has joined #rust-embedded
<Ralph[m]> corecode[m]: if you want to test your embedded code on an std environment you can use https://crates.io/crates/embedded-hal-mock to mock the HAL
<corecode[m]> Ralph[m]: i don't have a HAL interface
<corecode[m]> i guess i could manually write mocks for my vendor wraps
<corecode[m]> instead of using mockall
BentoMon has joined #rust-embedded
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
t-moe[m] has quit [Quit: Idle timeout reached: 172800s]
chrysn[m] has joined #rust-embedded
<chrysn[m]> t-moe, before I do a full PR: Would you be open for defmt-or-log to grow helper wrappers that allow doing things like ``{=[u8]:02x}` (`{:02x?}` in log) or `{=[u8]:cbor}` (falling back to `{:02x?}` in log b/c the expansion is otherwise rather costly) in a protable way?
<chrysn[m]> They could take the shape of `info!("Comparing {} and {}", Hex(my_data), Cbor(my_cbor_data));` type wrappers, are [implemented in Ariel already](https://github.com/ariel-os/ariel-os/blob/25d9245c8b928e949926b190c13fceb84540a2f5/src/ariel-os-debug-log/src/lib.rs#L212), but I'll need them both inside and outside of there.
<chrysn[m]> * t-moe, before I do a full PR: Would you be open for defmt-or-log to grow helper wrappers that allow doing things like `{=[u8]:02x}` (`{:02x?}`in log) or`{=[u8]:cbor}`(falling back to`{:02x?}` in log b/c the expansion is otherwise rather costly) in a protable way?
<chrysn[m]> (So the decision is between copying code, making a 30-line defmt-or-log-tools crate, or moving that into defmt-or-log)
t-moe[m] has joined #rust-embedded
<t-moe[m]> chrysn: Yes, I would take a PR on defmt-or-log. But can we do it in a backwards-compatible way?
<t-moe[m]> Btw, whats the state of the std/log backend for defmt? I've lost track a bit, but I'm still hoping that will make defmt-or-log obsolete one day...
Kaspar[m] has joined #rust-embedded
<Kaspar[m]> <t-moe[m]> "chrysn: Yes, I would take a PR..." <- > <@t-moe:matrix.org> chrysn: Yes, I would take a PR on defmt-or-log. But can we do it in a backwards-compatible way?... (full message at <https://catircservices.org/_irc/v1/media/download/Ab2Kxs8_rxe7lxH236T3U5XKwptkKvq60yt7KRoJcUvEaxQGmPazHgoGV2b3U2ELEk5N08N4TZESv-9VHOnLlre_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9XenNlQ0poS29xb0RvaEFlZmZjWkdtVk4>)
M9names[m] has joined #rust-embedded
<M9names[m]> is there a public log anywhere for the things discussed at rustweek?
<chrysn[m]> <t-moe[m]> "chrysn: Yes, I would take a PR..." <- It's purely backwards compatible: It's a type that one can opt in to use to get the best possible rendition of hex (or CBOR) that a backend offers, and won't affect existing use.
<chrysn[m]> Thanks, on it :-)
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]> James Munns: In the grounded crate, the method [get_element_mut_unchecked](https://docs.rs/grounded/latest/grounded/uninit/struct.GroundedArrayCell.html#safety-3) of GroundedArrayCell comes with 4 invariants. Though the wording of the 3rd point confuses me a bit. It states: `No modifications (even via pointers) are made to to the element pointed to while the reference is live` .
<vollbrecht[m]> For more clarity would it still be correct to instead say "you can't modify the data through any other means (like another raw pointer or another &mut T alias) while the &mut T returned by this function is alive"? E.g you "can modify it but only through the given &mut T". Or do i miss something here?
<JamesMunns[m]> I'll give it a think when I'm back at my PC
<vollbrecht[m]> i mean having a second &mut T is UB so no good wording.. but you may understand what i try to convey? :D
<JamesMunns[m]> You have the right understanding, I'm just saying "you can only modify through the returned mutable reference for as long as the mutable reference is live"
<JamesMunns[m]> The full sentence is:
<JamesMunns[m]> "The caller must ensure... No modifications (even via pointers) are made to to the element pointed to while the reference is live"
<JamesMunns[m]> But yeah, it should include "except via the returned mutable reference"
<JamesMunns[m]> Quick note: `postcard` v1.1.2 just released with a bunch of nice fixes and updates from a lot of people who are (mostly) not me!
<JamesMunns[m]> And reminder, the "postcard cinematic universe" is coming up to date, more info on progress and current status here, if you want to follow along: https://github.com/jamesmunns/postcard/issues/241
AdamHorden has quit [Quit: Adam Horden | adam.horden.me]
sroemer has quit [Quit: WeeChat 4.5.2]
jfsimon has quit [Quit: Leaving]
jfsimon has joined #rust-embedded