<thejpster[m]>
so the way a defmt message is encoded is:
<thejpster[m]>
1. write the interned ID for the format string
<thejpster[m]>
where, if the argument has a fixed format (like =u32), then you can just write the argument, but if it doesn't (like {}) then you write out the interned string ID required to format the value, and then the value.
<thejpster[m]>
so if someone wrote {=u32:counter}, it's not clear where the defmt-decoder would get 'counter' from at decoding time.
<thejpster[m]>
it's not even easy to support {2}, because you don't know what the 'second' item is until you've decoded the first two, and you need their formats in order to be able to do that.
<thejpster[m]>
the std write! macro can handle it because it breaks your format string and argument list down into a list of &'static str, a list of closures which know how to print each value you wanted. The ordering and naming can all be handled at log time.
<thejpster[m]>
I *guess* you could make a more advanced procedural macro that turned `"{counter} {0}", x` into `"{} {}", x, counter` at macro time. Sounds like quite a lot of work though.
limpkin has quit [Quit: limpkin]
limpkin has joined #rust-embedded
emerent_ has joined #rust-embedded
emerent is now known as Guest802
emerent_ is now known as emerent
Guest802 has quit [Ping timeout: 272 seconds]
cinemaSundays has joined #rust-embedded
<thejpster[m]>
dirbaio: you know how we changed the defmt macros to use the new function `acquire_and_header`? Someone is using `-Z direct-minimal-versions` and now has defmt-0.3.8 but defmt-macros-0.3.10 and everything is broken.
<thejpster[m]>
one option is to yank the release and push out defmt-macros-0.4.0, to stop older versions of defmt trying to use it. The other is to tell users pinned to 0.3.8 that they need to also pin defmt-macros at the same time.
<thejpster[m]>
Any thoughts?
<dirbaio[m]>
oh wow, I never realized this was something that could break
<dirbaio[m]>
bumping the macro crate prevents "new defmt, old macros" but nothing prevents "old defmt, new macros". how annoying
<thejpster[m]>
I assume it's a problem with proc-macros in general?
<dirbaio[m]>
yeah...
<thejpster[m]>
or, proc macros that emit code that calls library functions
<thejpster[m]>
if defmt-0.3.8 said defmt-macros = "=0.3.9" we'd have been OK I think
<diondokter[m]>
Ooohhh, that's a good point for device-driver too...
<dirbaio[m]>
yeah i'm sure i've done this mistake in embassy-executor releases as well :D
<dirbaio[m]>
I guess it makes sense, if the macro calls code that it didn't exist before, it's a breaking change
<dirbaio[m]>
s/it//
<dirbaio[m]>
* I guess it makes sense. Ifthe macro calls code that didn't exist before, it's a breaking change
<dirbaio[m]>
s/,/./, s/if/If/, s/it//
<thejpster[m]>
cargo semver-checks has no opinions here
<thejpster[m]>
and there's nothing I can put in defmt-macros that says "hey, we need at least defmt-0.3.9"
<dirbaio[m]>
yeah..
<dirbaio[m]>
so we have to either major-bump the macros every time
<dirbaio[m]>
or do the defmt-macros = "=0.3.9" thing
<dirbaio[m]>
but now that it's already screwed up, the latter only works if we had a time machine
<thejpster[m]>
so I think both. I have to major bump this time, to draw a line under what 0.3.8 can use, and pin the macro crate in any future release
<dirbaio[m]>
pinning the macro crate prevents doing a macros-only release to fix things, it'd need a "dummy" defmt release that bumps the macrso
<dirbaio[m]>
s/macrso/macros/
<thejpster[m]>
but from defmt-0.3.10 onwards (which uses defmt-macros = "=0.4.0") I think we're OK to then make a defmt-0.3.11 which uses defmt-macros = "=0.4.1"
<dirbaio[m]>
but maybe that's good? so macro changes can be documented inside defmt changes and the user doesn't have to worry about them
<thejpster[m]>
ugh, hmm
<dirbaio[m]>
s/them/the macro crate version they got/
<thejpster[m]>
would I ever want to change defmt-macros without changing defmt.
<dirbaio[m]>
* but maybe that's good? so macro changes can be documented inside the defmt changelog and the user doesn't have to worry about the macro crate version they got
<thejpster[m]>
defmt-macros is an internal implementation detail forced by how proc macros work. If they were macros by example, the crate wouldn't exist.
<thejpster[m]>
so, no, I should never bump defmt-macros without bumping defmt.
<thejpster[m]>
because defmt-macros isn't a thing. It's a mandatory quirk.
<thejpster[m]>
let me have a cup of tea and see if I still hold the position in five minutes.
<thejpster[m]>
s/the/that/
<dirbaio[m]>
there could be a dumb small bug in the macro crate that could be fixed with just a macro crate release
<dirbaio[m]>
but then you wouldn't have a defmt version to document the fix in the changelog
<thejpster[m]>
oh, the changelog got better ;)
<dirbaio[m]>
so maybe it's good that you bump defmt as well
<dirbaio[m]>
so the user knows for sure "if I got defmt 0.13.0 I got the bug, if I got defmt 0.14.0 I don't"
<thejpster[m]>
I basically don't want anyone to have to know that defmt-macros exists.
<thejpster[m]>
it's my problem, not theirs.
<dirbaio[m]>
yea
<dirbaio[m]>
then bumping macros to 0.4.0 now then pinning from now on makes sense
<diondokter[m]>
Wasn't there talks about adding the ability to add proc macros to normal crates at some point?
<dirbaio[m]>
it's a recurring topic, but there's no progress because it's Hard
<diondokter[m]>
Ah ok. Because that would be the true solution
<thejpster[m]>
ok, step 1, let's prepare a new defmt release. Then we can talk about the merits of yanking 0.3.9
<thejpster[m]>
is anyone from rust-embedded-community around to publish a dummy release of something like https://github.com/rust-embedded-community/ssd1306? That also uses package.metadata.docs.rs to specify a target to build on docs.rs.
<thejpster[m]>
oh actually, I think I can.
<thejpster[m]>
actually I don't want to clutter up the release history.
pbsds3 has quit [Quit: Ping timeout (120 seconds)]
apirkle has quit [Quit: Ping timeout (120 seconds)]
<thejpster[m]>
they could, but they do not. So until the PAC is rebuild, users are stuck. Unless they start cargo patching.
<dirbaio[m]>
also that's an argument against doing cortex-m-rt releases
<dirbaio[m]>
not against removing the static mut transform :D
<dirbaio[m]>
fwiw cortex-m-rt git main already has breaking changes queued
<thejpster[m]>
if you're going to put out a breaking change, this might be a good time to harmonise the RISC-V and Cortex-M #[interrupt] syntax.
<dirbaio[m]>
yeppp
<thejpster[m]>
No, I accept I've lost that one. I'm fine to see it go. It's not sound on RP2350 anyway.
<thejpster[m]>
* sound on RP2040/RP2350 anyway.
<dirbaio[m]>
ohh multicore, right 💀
<thejpster[m]>
you can enter the same routine on both cores at the same time
<thejpster[m]>
trivially even
<dirbaio[m]>
thejpster[m]: about this: is there any conversation started somewhere about it
<dirbaio[m]>
* about it?
<dirbaio[m]>
there's also the thing we discussed at rustnl
<dirbaio[m]>
the "pac interface crate"
<thejpster[m]>
I brought it up at RustNL
<thejpster[m]>
because I had the RP2350 in my head and I was trying to write one application that could compile for either architecture, and the interrupt syntax makes it really hard
<thejpster[m]>
I know risc-v people were proposing a new API and then maybe cortex-m-pac was going to implement it or something
<dirbaio[m]>
another similar case is the nrf54 riscv coprocessor thingy
<thejpster[m]>
there will probably be others.
<dirbaio[m]>
vectors are (almost?) the same between the main cortex-m core and the riscv core
<thejpster[m]>
in general there's a function that takes no arguments and it can be called when a named hardware event occurs. So they are similar in that sense.
<thejpster[m]>
On RP2350 the interrupt names are identical on both architectures. The exceptions are different though but you don't usually need to specify an exception handler.
<thejpster[m]>
> vectors are (almost?) the same between the main cortex-m core and the riscv core
<thejpster[m]>
On you mean on nRF54? near.
<thejpster[m]>
s/near/neat/
<dirbaio[m]>
yeah
<dirbaio[m]>
the riscv is clearly intended as a coprocessor there so maybe it's less likely you want the exact same code to compile for either tho
<dirbaio[m]>
bu still
<dirbaio[m]>
* but still
<thejpster[m]>
anyway, I guess the workaround for errors about the static mut transform is "don't use the static mut transform". If you don't use it, you don't need a new version, right? The new version just takes it away from you to force you to not use it.
<thejpster[m]>
So a PSA might be enough.
<dirbaio[m]>
yeah
<dirbaio[m]>
it's sneaked a few times into embassy examples tho
<JamesMunns[m]>
I think the esp32 folks had a way to show warnings in deps, I guess you could put a deprecation warning on the expansion of the macro?
<dirbaio[m]>
and since it just repurposes existing syntax it's impossible to grep for, and very easy to overlook when PR reviewing 😬
<thejpster[m]>
well now it's easy to find
<dirbaio[m]>
yep rust 1.83 gave us the warning for free 🤣
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
cinemaSundays has quit [Quit: Connection closed for inactivity]
bartmassey[m] has quit [Quit: Idle timeout reached: 172800s]
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
sroemer has quit [Ping timeout: 260 seconds]
sroemer has joined #rust-embedded
rmsyn[m] has quit [Quit: Idle timeout reached: 172800s]