00:15 <M762spr[m]> how do I share data between threads in no_std? like in std I could use Arc<Mutex<data>> and then close the Arc and send it wherever. compiler is suggesting heapless::pool::arc but I'm not sure how to set that up

00:15 <M762spr[m]> * how do I share data between threads in no\_std? like in std I could use Arc\<Mutex\<data>> and then clone the Arc and send it wherever. compiler is suggesting heapless::pool::arc but I'm not sure how to set that up

00:33 <M762spr[m]> so I tried using mkstatic! which now requires defining lifetimes, but apparently I can't do that for task functions?

00:36 <M762spr[m]> basically I have my state object in the main thread, I want a background task to do calculations on a a few fields of that data, but I can't figure out how to access it from the sub task

00:37 <M762spr[m]> in std I would just use Arc, but I'm drawing a blank here...

00:45 <petekubiak[m]> Can you just spawn a task, pass the data in and async await the result of the calculation?

00:46 <petekubiak[m]> I guess I should have asked first: are you using an async runtime?

00:46 <M762spr[m]> hm. possibly. I would like the task to loop in the background. and yes I am using embassy

00:46 <M762spr[m]> I could probably ask there but I'm not sure if it is specific to embassy

00:50 <petekubiak[m]> The cost of spawning a task is extremely low, so if the calculation is only occasionally being run it might be worth spawning tasks that only live for the lifetime of the calculation.

00:50 <petekubiak[m]> If you want the task to stay alive and receive further calculations I'd suggest using a Channel https://docs.embassy.dev/embassy-sync/git/default/channel/struct.Channel.html

00:54 <M762spr[m]> hmmm I guess I will have to rethink my approach. I was looking at it like I would with std/tokio...

00:54 <M762spr[m]> I am currently using channels to inform my main loop of app events that occur and sharing data that way. I could spawn a new task when I get new data and that task could send an app event over the channel when it completes to save the result 🤔

00:57 <M762spr[m]> I have always used tasks as looping though. what would be the point of a one and done task vs a regular async function?

01:32 <petekubiak[m]> Calling an async function and awaiting the result will mean that execution on your main task code will halt until the result of the async function is yielded. Spawning the function in a new task with a copy of the channel's sender will allow the main task's execution to continue in "parallel"

01:41 <M762spr[m]> ah. that's what I want to do, thanks!

10:25 <wassasin[m]> I have a memrd memory dump of the peripheral addressing space and want to conveniently check the register values. Is there a convenient tool to import an offline memory dump and relate it to the SVD? I know cortex-debug can do this for online devices

10:26 <wassasin[m]> Plan B is to write a quick tool myself

11:48 <thejpster[m]> Quick cargo question - if I have some published crate at 0.3.10 and I publish 0.3.11-rc.1, the only circumstance in which the resolver will pick that version is with foo = "^0.3.11-rc.1", correct? No-one with = "^0.3" will get it?

12:09 <thejpster[m]> seems so: https://doc.rust-lang.org/cargo/reference/resolver.html#pre-releases

12:09 <thejpster[m]> > For example, if `1.0.0-alpha` of package `foo` is published, then a requirement of `foo = "1.0"` will not match, and will return an error. The pre-release must be specified, such as `foo = "1.0.0-alpha"`

21:20 <PhilMarkgraf[m]> Is anyone using Bazel or Buck2 build systems with their embedded systems work?

21:20 <PhilMarkgraf[m]> In a "Rust in Production" podcast, Steve Klabnick mentioned his interest in potentially using Buck2 at Oxide for what sems like a similar use case. I am seeing issues with Cargo needing to rebuild everything all the time, which I think is because I'm building the same code for multiple targets (host and target)

22:07 <diondokter[m]> <PhilMarkgraf[m]> "Is anyone using Bazel or Buck2..." <- > <@shakencodes:matrix.org> Is anyone using Bazel or Buck2 build systems with their embedded systems work?

22:07 <diondokter[m]> > In a "Rust in Production" podcast, Steve Klabnick mentioned his interest in potentially using Buck2 at Oxide for what sems like a similar use case. I am seeing issues with Cargo needing to rebuild everything all the time, which I think is because I'm building the same code for multiple targets (host and target)

22:07 <diondokter[m]> That's not an issue in general for me. This can happen when you have a build.rs that has a rebuild if changed for a file that doesn't exist

22:08 <diondokter[m]> I wish cargo would give a warning for that

22:09 <M9names[m]> https://github.com/rust-lang/cargo/issues/4213#issuecomment-310697337

22:09 <M9names[m]> How could you give a warning and still support the intended use though?

22:10 <doom_potako[m]> I've also had this issue when there were some environment variables affecting the build (e.g. this happens with ESP32 xtensa development) and rust-analyzer (which I run behind ra-multiplex) was not getting those environment variables and was invalidating everything, failing to compile, and blocking builds from the CLI.

22:13 <M9names[m]> Best I can think of (while staying backwards compatible) is add a new directive thats equivalent to rerun-if-changed that errors if missing

22:15 <doom_potako[m]> in redo there is redo-ifcreate which is something (and I always felt like cargo must have taken inspiration from redo) cargo doesn't have and which would be precisely what you want in this scenario

22:20 <doom_potako[m]> (I should not imply that redo is a well specified build system with a set of agreeing implementation. It's more like that's the consensus for what redo-ifcreate should do based on stuff DJB once wrote about and then never implemented: http://cr.yp.to/redo/honest-nonfile.html)

22:20 <doom_potako[m]> s/implementation/implementations/

22:20 <doom_potako[m]> * (I should not imply that redo is a well specified build system with a set of agreeing implementations. It's more like that's the consensus for what redo-ifcreate should do based on stuff DJB once wrote about and then never properly implemented: http://cr.yp.to/redo/honest-nonfile.html)

22:36 <diondokter[m]> <M9names[m]> "https://github.com/rust-lang/..."; <- > <@9names:matrix.org> https://github.com/rust-lang/cargo/issues/4213#issuecomment-310697337

22:36 <diondokter[m]> > How could you give a warning and still support the intended use though?

22:36 <diondokter[m]> It could keep track of wether it was present last time. Or it could give the warning if after the build script has run the file still isn't there