<thejpster[m]>
I guess proc macros can do anything, so no. It could convert from inline to uninline and then proceed as before.
<thejpster[m]>
Just, we haven’t. And as I format a lot of expressions, it’s not high on my list of things to do.
n_vl[m] has joined #rust-embedded
<n_vl[m]>
Note that I'm linking with the same lib artefact in both modes.
<n_vl[m]>
Anything particular I can try to deal with this?
<n_vl[m]>
Hey, I have some rust code that behaves as expected with the debug build but goes in hardreset when in release mode when I'm calling a linked C-lib (to the best of my guess).
<jason-kairos[m]>
I think I've got myself confused. I'm fairly certain that it's a pointer vs reference issue
<jason-kairos[m]>
* reference issue coupled with some fancy new diagnostic messages from the compiler
<thejpster[m]>
<RobinMueller[m]> "thejpster: Maybe I should have a..." <- Please do. I know it needs doing, I just haven’t done it yet.
cr1901_ is now known as cr1901
pcs38 has joined #rust-embedded
<thejpster[m]>
I lost the clippy format lint argument.
<thejpster[m]>
If you use log and defmt you’re about to have a bad time.
<thejpster[m]>
dirbaio: you have a crate that does this don’t you?
JamesMunns[m] has joined #rust-embedded
<JamesMunns[m]>
it's not a crate, it's a macro that gets copy and pasted across many crates for macro expansion issues/reasons I don't remember offhand
<danielb[m]>
<thejpster[m]> "If you use log and defmt you’..." <- time to deprecate log, then
<danielb[m]>
* log, then (as in, start recommending against, I guess)
<JamesMunns[m]>
* it's not a crate, it's a macro that gets copy and pasted across many crates for macro expansion issues/reasons I don't remember offhand
<JamesMunns[m]>
edit: It's a file that gets copy and pasted, with a bunch of macros in it
<JamesMunns[m]>
ahhh, that't the reason
<JamesMunns[m]>
s/t/s/
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
Yeah the fmt.rs needs copypasting into each crate because the defmt proc macros break if you reexport them
<dirbaio[m]>
Can't make it into a crate
diondokter[m] has joined #rust-embedded
<diondokter[m]>
I've started using the derive-more crate so, with the same fmt.rs trick, I don't have to use {:?} which defmt rejects. I just implement display on everything I guess
<thejpster[m]>
I’m happy to take PRs to make defmt pass days onto a log backend. I have a proof of principle. I just don’t have time.
<thejpster[m]>
There’s a request in to change the format trait method argument which apparently makes this easier, but I’m snowed under with cortex-ar stuff for embedded world
<diondokter[m]>
Yeah fair
<diondokter[m]>
I tried like two years ago, but them I found I also didn't really have time then
<diondokter[m]>
s/them/then/
<thejpster[m]>
s/days/stuff/
<thejpster[m]>
<diondokter[m]> "I've started using the derive-..." <- We could probably fix that. Make :? Use Debug2Format automatically or something.
<diondokter[m]>
That would definitely make it better!
<diondokter[m]>
But not entirely what I'd want
<danielb[m]>
I think I'd prefer making the syntax no-op. Keep it for compatibility, but don't negate defmt's selling points
<diondokter[m]>
Yeah, this is a problem for types that have a Debug and Format impl. When logging to Log, I need Debug, but with defmt, I need Format
<diondokter[m]>
They use incompatible format strings right now
<thejpster[m]>
The fix there is to make defmt optionally write to a log backend
<diondokter[m]>
Indeed
pcs38 has quit [Quit: leaving]
Andy[m]1 has joined #rust-embedded
<Andy[m]1>
Hi there. I'm writing a short program to read an external sensor on my microbit board with the keyestudio sensor shield, and I'm getting a weird reading. I'm pretty sure I'm doing something wrong and can't find what is it.