<re_irc>
<manasiwibi> Thanks for references. Barely know about Rust and Microcontroller world, so it all seems unkown to me xd. I have fixed it now.
<re_irc>
<manasiwibi> 9names: Yea I tried to install it via Rosetta but couldn't make the installation procces works. Turns out the GDB is already installed, I've just need to use the "arm-none-eabi-gdb .. " command. I believe it already installed from "brew install arm-none-eabi-gcc"
<re_irc>
<newam> Is there a way to "format!" a string without jumping into the global alloc failed handler when OOM?
<re_irc>
I know "heapless::String" can work around this, but I would prefer that this is heap allocated.
<re_irc>
<newam> And the size is not known upfront, so I can't use try_reserve and "write!" without massive hacks.
<Lumpio->
If you make your own Write implementation it's not necessarily such a massive hack
<Lumpio->
Just wrap the String, call try_reserve in your own write_str and return an error if it fails (and then maybe arrange for a descriptive error to be returned even though fmt::Write doesn't allow that)
<re_irc>
<adamgreig> hi room, meeting time again! agenda is https://hackmd.io/solxYWVFRbO7t5-mhviRWQ, please add anything you'd like to announce or discuss and we'll start in ~5 minutes
<re_irc>
<adamgreig> fairly quiet week! i've been at emf camp since thursday morning and only back yesterday evening, though i did have a few occasions to spread the good word about rust :P
<cr1901>
Quiet can be good sometimes.
<cr1901>
Means things are working smoothly maybe :P
<re_irc>
<therealprof> Yeah, after manic months...
<re_irc>
<adamgreig> ok, well let's start and see where we get to, I don't have any announcements for this week
<re_irc>
<therealprof> Has anyone tried the latest nightly by any chance?
<re_irc>
<adamgreig> we released cortex-m 0.7.5 last week with inline-asm feature available on stable, no complaints about it so far
<re_irc>
<adamgreig> interesting, does that only affect forbid(unsafe_code)?
<re_irc>
<therealprof> That's my understanding. They've done a crater run but I wouldn't expect too many link sections to appear in regular code.
<re_irc>
<adamgreig> probably not uncommon for embedded applications to have both forbid(unsafe_code) and link_section
<re_irc>
<therealprof> That's what I was thinking, though I only vaguely remember some no_std libaries using forbid(unsafe_code).
<re_irc>
<adamgreig> libraries don't tend to use link_section, though
<re_irc>
<adamgreig> I just had a quick check and indeed the lint only shows if you have forbid(unsafe_code)
<re_irc>
<therealprof> Right.
<re_irc>
<dirbaio> I guess you can "allow(unsafe_code)" just the fn with link_section
<re_irc>
<dirbaio> or its parent mod
<re_irc>
<adamgreig> yea, that works
<cr1901>
I do allow(unsafe_code) with a comment personally
<re_irc>
<adamgreig> so I guess the worst thing is it might be a breaking change for some applications, but probably not for (m)any libraries
<re_irc>
<therealprof> Lots of interesting changes in the Rust compiler lately.
<re_irc>
<therealprof> Many huge performance improvements but also some disruption potential.
<re_irc>
<adamgreig> hopefully stabilising naked functions gets unstuck soon too
<re_irc>
<adamgreig> the only other thing from the agenda I wanted to briefly mention is this question about whether embedded-hal's CAN error enum should include the Acknowledge error since drivers won't generally be able to return it, https://github.com/rust-embedded/embedded-hal/issues/387
<re_irc>
<adamgreig> it's possible some driver implements some method to return error status on previous enqueued frames and then the variant could be useful, and having it means we cover all the bases of the official documented types of can mac error, so there's probably no compelling reason to remove it, but maybe the docs should mention this?
<cr1901>
I say keep it just in case- You Are Gonna Need It
<re_irc>
<adamgreig> well, that's all I had for this week, if anyone wants to mention anything else please go for it, otherwise we can wrap up here
<re_irc>
<therealprof> I got nothing... still catching up... 😅
mattgirv_ has joined #rust-embedded
mattgirv has quit [Ping timeout: 248 seconds]
mrkajetanp has quit [Ping timeout: 248 seconds]
mrkajetanp_ has joined #rust-embedded
vancz_ has quit []
vancz has joined #rust-embedded
dc740 has joined #rust-embedded
<re_irc>
<firefrommoonlight> When is the next planned stm32 PAC release? It would be nice to have the G0 fixes etc. Last was in October
<re_irc>
<firefrommoonlight> I understand these are tricky since they're breaking