17:10 <Socke> hmm somehow my neovim setup partially stopped working with my esp projects. I still see code actions when I press the mapped keys, but I don't see diagnostics anymore. it still works for non-esp projects. not sure if this is an issue of rust analyzer or my nvim config. how would I go and debug this?

17:14 <Socke> well... nvim rust-tools is deprecated, time to switch again...

17:19 <swaits[m]> Socke: I use LazyVim with the rust lang enabled. It automatically switched away from rust-tools for me. Not everyone's cup of team, but very convenient.

17:21 <Socke> might be worth a try

17:22 <Socke> my vim config grew exponentially over the last 10 years

17:26 <vollbrecht[m]> upgrading to the latest nightly compiler also can sometimes break your rust-analyzer diagnostics. So if your plugin doesn't work, you can check if its related to you using the latest compiler version

17:53 <thejpster[m]> https://github.com/rust-embedded/cortex-m/issues/514 - maybe an interesting one to discuss later today?

17:59 <dirbaio[m]> oh interesting

17:59 <dirbaio[m]> maybe it's possible to annotate the asm with metadata so that probe-rs can unwind through it?

18:04 <vollbrecht[m]> the archenemy of stack-frame unwinding, external code alla asm macros or othere externally linked stuff just breaks everything. Time to add eh_frames and ditch stack-frames. Though doing so will also lead to loosing your sanity by learning the DWARF spec 😅

18:05 <vollbrecht[m]> but at least it works™

19:02 <adamgreig[m]> hi @room , meeting time again! agenda is (going to be) https://hackmd.io/dA39X_TRQD2PE7k-DFbZfQ, please add anything you want to announce/discuss and we'll start in a couple of mins

19:06 <calisti[m]> Are these meetings Working Group members only, or can folks drop in for a passive listen if just interested in embedded Rust? (and where would I join?)

19:06 <adamgreig[m]> anyone is very welcome, it's just text chat here though so you're already in it :)

19:06 <adamgreig[m]> feel free to interject and discuss

19:06 <adamgreig[m]> (well, try to stay on-topic during the meeting, though...)

19:07 <calisti[m]> adamgreig[m]: thanks!

19:07 <calisti[m]> > <@adamgreig:matrix.org> feel free to interject and discuss

19:07 <calisti[m]> * thanks! I guess I'm gonna read along quietly ❤️

19:07 <adamgreig[m]> ok, let's begin, I don't have a lot on the agenda today, only announcement from me is to remind anyone planning to come to the RustNL embedded unconf to confirm by ticking your name on the table in the hackmd in the other channel, and that if you're interested in booking the conf hotel, the block-booking for it expires in a few days (on the 15th)

19:08 <NickStevens[m]> Regarding RustNL, is there going to be a livestream or any way for remote people to join the unconf?

19:08 <AdamHott[m]> I think Erik mentioned that deadline has been extended until March 25th

19:09 <NickStevens[m]> I'm also fine just hacking in solidarity and on US time 😄, mostly just curious

19:09 <adamgreig[m]> not sure on the details yet, I don't think it's been planned

19:10 <adamgreig[m]> any other announcements from anyone?

19:10 <adamgreig[m]> AdamHott[m]: ah, you're right, thanks!

19:11 <JamesMunns[m]> Do we want to capture unconf discussion topics? I know "static mut" got nominated, not sure if we have a list or are tracking any other things that would be good to hash out in person

19:11 <therealprof[m]> Actually hotel was extended, changed it in the meeting notes.

19:12 <JamesMunns[m]> ah, there's a "topics" section, but it's mostly empty :)

19:12 <JamesMunns[m]> might be worth soliciting ideas prior to the conf so we don't spend both days brainstorming :)

19:12 <adamgreig[m]> the other thing on my mind is the dereferenceable/PACs/cortex-m stuff

19:12 <therealprof[m]> Please feel free to add yout ideas. Tracking them was indeed what we had in mind. ;)

19:13 <adamgreig[m]> rust 1.77 will be long out by then so i'm sure the static mut thing will be high on everyone's mind

19:13 <jannic[m]> rp2040-hal 0.10.0 with full support for embedded-hal 1.0 was released. And a lot of other updates.

19:13 <adamgreig[m]> nice! and there were a few esp-hal/esp-wifi releases too

19:14 <AdamHott[m]> awesome!

19:15 <thejpster[m]> last call for nominations for council rep: https://rust-lang.zulipchat.com/#narrow/stream/384197-t-launching-pad/topic/Renewal.20or.20Replacement.20of.20Rep

19:16 <adamgreig[m]> I'm very happy with the current nominee :D

19:17 <adamgreig[m]> ok, the other thing on the agenda is https://github.com/rust-embedded/cortex-m/issues/514

19:17 <dirbaio[m]> remove it 🔥

19:17 <adamgreig[m]> I think the boring answer is that we can't make the trampoline default-off in 0.7 because it's definitely a breaking change

19:18 <adamgreig[m]> so it probably still makes sense to do a new 0.7 release with the option to disable it, and then remove it in 0.8

19:18 <thejpster[m]> So, I was giving a training on embedded last week and this was a bit of a mess. The new probe-rs crashed on Intel Mac, but seemed to work OK on my Apple Silicon Mac. Possibly cortex-m-rt was at a different version, but not sure.

19:18 <adamgreig[m]> however we will then have the usual total horror show of 0.8 because "can only have one cortex-m-rt" and "all PACs depend on 0.7"

19:18 <JamesMunns[m]> thejpster[m]: (that might be `nusb` based differences? depending on the versions)

19:18 <adamgreig[m]> cortex-m-rt hasn't changed in a long time (>1y) so probably not that?

19:18 <thejpster[m]> Also the new probe-rs prints a bunch of warnings, and handles println wrong. Serves me right for not checking before hand! All credit to the team for a great application though - it is by and large a joy to use and puts openocd to shame.

19:19 <JamesMunns[m]> adamgreig[m]: one point oh! one point oh!

19:19 <thejpster[m]> yeah and I'm pretty sure I ship a lock file, so I expect everyone to use the same crates on the target

19:19 <adamgreig[m]> ah, but lock file doesn't help with probe-rs version huh

19:20 <adamgreig[m]> so I guess that's probably it

19:20 <adamgreig[m]> yea, I wouldn't object to c-m-rt at 1.0, god knows it's stable enough now

19:20 <adamgreig[m]> ambitions of "handle multiple memory sections properly" aside

19:20 <adamgreig[m]> the main possibly-breaking change we had in mind was the change to exception/interrupt handling we talked about a little while ago, to decouple PACs from c-m-rt

19:21 <adamgreig[m]> I think that would be well worth getting in place before a 1.0 release, and so it's part of that general PAC topic for the unconf in my head

19:21 <adamgreig[m]> but it's possible we want to resolve this sooner too

19:21 <thejpster[m]> we should also think about RISC-V interrupts, because I'd like those to be handled in a similar fashion

19:21 <adamgreig[m]> yep, makes sense. I don't know if they'll be type-identical but it would be nice if the overall shape matched. That said I think the risc-v people have been pushing ahead here so it might just be a case of copying what they've done for cortex-m :p

19:22 <dirbaio[m]> riscv interrupt handling varies too much across chips, it ends up being partof the HAL instead of the arch support crate

19:22 <thejpster[m]> right, but if we could at least agree what #![interrupt] does (e.g. in terms of static mut) we can make a RISC-V one that does the same.

19:23 <thejpster[m]> * right, but if we could at least agree what #[interrupt] does (e.g. in terms of static mut) we can make a RISC-V one that does the same.

19:23 <thejpster[m]> ah., hmm, I wonder if beta will get shouty about the static mut transform

19:24 <thejpster[m]> do warnings apply to the crate the macro is in, or the crate the macro gets expanded in? Sorry. Idle thoughts.

19:25 <adamgreig[m]> hah, maybe another reason to remove that feature

19:26 <sourcebox[m]> I think I tried beta on static mut, didn't give me any warnings.

19:28 <adamgreig[m]> anything else anyone wanted to discuss this week?

19:30 <cr1901> adamgreig[m]: Ngl, I've been busy doing a refactor and coupled with DST, I forgot the meeting :P

19:30 <cr1901> Despite being physically here

19:30 <therealprof[m]> Hm, everyone happy? That's rare... :D

19:30 <adamgreig[m]> oh yea, I forgot we're in the chaos weeks

19:30 <dirbaio[m]> quick, someone bring up a controversial topic

19:30 <adamgreig[m]> noooo we could finish the meeting early instead!

19:31 <AdamHott[m]> Can we rename mutable references to "changeable mirrors"?

19:31 <AdamHott[m]> indeed

19:31 <M9names[m]> No

19:31 <adamgreig[m]> sign my petition to make statics mut by default 📋️

19:32 <dirbaio[m]> deprecate non-mut statics and variables

19:32 <cr1901> Over my dead body

19:32 <adamgreig[m]> "oh that's not so bad, we're already doi------ OH"

19:32 <dirbaio[m]> they're always getting in the way of writing code

19:32 <cr1901> There is more to life than stack addressing

19:32 <adamgreig[m]> it would be much easier if we just said which ones weren't mut

19:32 <JamesMunns[m]> adamgreig[m]: 🫠

19:32 <adamgreig[m]> like const static or something

19:33 <cr1901> Like garbage collection. Or "free is a noop".

19:33 <dirbaio[m]> public static synchronized final const

19:33 <sourcebox[m]> Why not just a "boss mode" that disable all compile time checks?

19:34 <cr1901> That's mrustc

19:34 <dirbaio[m]> call it "the Crab language", or "C" for short

19:34 <geky[m]> I vote rename mut to volatile, they mean basically the same thing right?

19:34 <AdamHott[m]> haha

19:34 <adamgreig[m]> hmm idk, you might get confused with "tcl"

19:35 <adamgreig[m]> seems a bit of a short name for a language :P

19:35 <dirbaio[m]> omg that gave me openocd ptsd

19:35 <adamgreig[m]> hah

19:35 <adamgreig[m]> the thinking man's scripting language

19:35 <adamgreig[m]> ok, well, we're obviously done here :P thanks everyone, see you next week!

19:36 <AdamHott[m]> thanks everyone, good day good night!

19:46 <Noah[m]12> <thejpster[m]> "Also the new probe-rs prints a..." <- i think we still have some QA issues and I wanna get it sorted for a long ehile but ohwell ... also I really wanna try a weekly call/meeting to do some socializing, triaging and roadmapping.

20:11 <sourcebox[m]> Just for fun:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/VkHNVgFyypVXoRppnkvPcfvu>)

20:44 <vollbrecht[m]> <sourcebox[m]> "Just for fun:..." <- > <@sourcebox:matrix.org> Just for fun:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/zBxsAbfSOidtndktAfeHcKSB>)

20:46 <vollbrecht[m]> * if you will open it in a hex editor you will find more than 13k, if not tamed rust likes to put alot of "stringlike" junk into the elf - that is than still in the end bin

20:47 <JamesMunns[m]> Also strings looks for null terminated strings

20:47 <vollbrecht[m]> * if you will open it in a hex editor you will find more than 13k, if not tamed rust likes to put alot of "stringlike" junk into the elf - that is than still in the end after espflash converts it

20:47 <JamesMunns[m]> Which rust generally doesn't use

20:47 <dirbaio[m]> yeah if you want to measure string junk you should convert to bin first

20:48 <JamesMunns[m]> > For each file given, GNU strings prints the printable character sequences that are at least 4 characters long (or the number given with the options below) and are followed by an unprintable character.

20:48 <JamesMunns[m]> Huh, it's a little more flexible than I thought, but yeah not sure what sourcebox is trying to measure

20:49 <sourcebox[m]> This is not some serious measurement, was just poking around with it.

20:50 <sourcebox[m]> But there's more text in it than expected, most not even from my code but deps.

20:51 <vollbrecht[m]> it gets fun if you build the rust std-lib and include it in esp-idf-* . You have a huge pile of full-path env leaking and it all ends in the binary. So if you are building the std-lib by yourself for any target you really need to look out for that :D

20:52 <vollbrecht[m]> or another big place is panic handling etc, lots of strings ;D

20:52 <sourcebox[m]> The absolute paths are annoying because they can include sensitive information.

20:54 <vollbrecht[m]> before you ship any rust binary, best to open it first in a hex editor ;D Not only for embedded binary's but in general