<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
<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]>
* 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...
<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]