09:15 <ryan-summers[m]> Man, my `menu` changes got merged and released before I even came back online for the day :) Thanks thejpster and eldruin - I'll go ahead and publish the 0.4.0 release

09:17 <eldruin[m]> <jannic[m]> "I don't know how much I'll..." <- Sounds great! could add yourself to the [meta repo](https://github.com/rust-embedded-community/meta) in a PR?

09:19 <ryan-summers[m]> Also, there's an interesting overlap between the REWG libs team and the REC now

11:55 <StephenD[m]> What does it mean when spawn_after returns an Err? I can't find that in the rtic docs anywhere

11:55 <StephenD[m]> They just unwrap it everywhere. Which is what I was doing and just got a panic

12:01 <xiretza[cis]> <StephenD[m]> "What does it mean when ..." <- what's a `spawn_after`?

12:06 <StephenD[m]> xiretza[cis]: https://rtic.rs/1/book/en/by-example/monotonic.html

12:06 <StephenD[m]> This is the closest I can find for documentation for it

12:06 <StephenD[m]> I wish I could find the real docs. I.e. a docs.rs page on that specific function instead of a high level overview

12:15 <xiretza[cis]> <StephenD[m]> "https://rtic.rs/1/book/en/by-..."; <- > <@stephen:crabsin.space> https://rtic.rs/1/book/en/by-example/monotonic.html... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/KnhMjORTTncXAEduiyhnwEtN>)

12:17 <StephenD[m]> Thanks

12:17 <StephenD[m]> I'll admit I have a bit of trouble following that code. I guess it errors when the fq queue is empty. But what does that actually mean?

12:20 <xiretza[cis]> see https://rtic.rs/1/book/en/by-example/message_passing.html

12:24 <StephenD[m]> Ahh I see

12:25 <StephenD[m]> So if it's panicking it means there's a spawn for that task already in the queue

12:51 <StephenD[m]> Thanks

13:49 <andodeki2[m]> I have this snippet for ESP32 with a GPRS/module which works when I use Serial Monitor software in my laptop.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/HjEAvdiybMQuJIgXzpdfraYW>)

14:15 <spinfast[m]> Is there something like a Box<T> but for statically allocated things so I can do like StaticRef<dyn X>

14:17 <spinfast[m]> the use case I have is the SAI peripheral for iMX.RT which can have 1 to 4 data channels associated, and I'm working on creating a Builder for the peripheral

14:17 <K900> `&dyn T`

14:18 <ryan-summers[m]> Is there a meaningful difference between dyn T and impl T?

14:19 <spinfast[m]> Won't that not move it though? e.g.

14:19 <spinfast[m]> fn add_tx_channel<const PeriphInst: u8, const Channel: u8, TxPin>(self, tx_pin: TxPin) -> Self { self.tx_pins[Channel] = Some(tx_pin); self

14:19 <spinfast[m]> }

14:19 <spinfast[m]> * Won't that not move it though? e.g.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/AoETYDziEZgHShCBxRyyWJIv>)

14:19 <spinfast[m]> * Won't that not move it though? e.g.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/EhhAWBHeuIkKTUpIlxqMVrVF>)

14:20 <spinfast[m]> * Won't that not move it though? e.g.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/QNKVHMSZhYWbsqDdjmydsNMX>)

14:20 <spinfast[m]> * Won't that not move it though? e.g.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/LqWXTcrGnmyFwMFUkFVoIPjx>)

14:20 <spinfast[m]> * Won't that not move it though? e.g.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/SZUuHXubOnQouPxJVOdCuaUe>)

14:25 <spinfast[m]> Or I guess alternatively, I create something like.. TxDataPins<T0, T1, T2, T3> = (T0, T1, T2, T4); and go from there, adding another generic param I guess

14:26 <spinfast[m]> * Or I guess alternatively, I create something like.. type TxDataPins\<T0, T1, T2, T3> = (T0, T1, T2, T4); and go from there, adding another generic param I guess

14:26 <spinfast[m]> * Or I guess alternatively, I create something like.. type TxDataPins\<T0, T1, T2, T3> = (T0, T1, T2, T3); and go from there, adding another generic param I guess

14:31 <jannic[m]> <ryan-summers[m]> "Is there a meaningful difference..." <- I think `impl T` will be monomorphised for each concrete T. So it might be slightly faster, but also produce a larger binary if you use it with more than one actual T.

15:36 <fu5ha[m]> <ryan-summers[m]> "Is there a meaningful difference..." <- Completely different things :P `impl Trait` can mean different things in different places, but it's *always* resolved by the compiler to some *single* actual type `T` at compiletime (like a generic). `&impl T` is just a regular thin pointer to that type that... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/hlODijnitWkMkOBUiBSnmTfS>)

15:41 <fu5ha[m]> (Just realized you may already know this and were asking the question specifically in reference to the situation presented, which would be a different answer)

16:30 <ryan-summers[m]> Ah interesting, so when wanting a trait object, it's probably better to do &dyn Trait. Is there any value in having the distinction in the language? It feels to me, as a user, to be a purely semantical issue

16:31 <dirbaio[m]> depends on what you want

16:32 <ryan-summers[m]> Ah okay yeah I had to reread the discussion. It sounds like it has to do with allocation sizes etc.

16:33 <ryan-summers[m]> Where there could be some niche locations where you'd want dyn instead of impl

16:33 <dirbaio[m]> generics/impl make faster code because the compiler inlines and optimzies everything

16:33 <dirbaio[m]> at the cost of bigger code size if you use multiple types

16:33 <dirbaio[m]> but perhaps that cost is OK if you really want max perf

16:33 <ryan-summers[m]> But still, this is essentially (mostly) irrelevant to a language user

16:34 <ryan-summers[m]> The performance characteristics are likely exceptionally marginal

16:34 <dirbaio[m]> dyn avoids the code growing for each type you use, but is slower, and bigger code if you actually use only one type

16:34 <dirbaio[m]> dyn allows putting different types in the same array, impl/generics don't

16:35 <dirbaio[m]> ryan-summers[m]: oh no it can make a big difference in some cases

16:35 <dirbaio[m]> especially in embedded where you care about code size a lot, or care about perf a lot, depending on what you're doing

16:37 <dirbaio[m]> and that's the whole point of Rust: give you the tools, don't hide how they work under the hood, so you can choose the best one for your use case to optimize

17:30 <thejpster[m]> <ryan-summers[m]> "Man, my `menu` changes got..." <- Don’t forget to tag it!

17:57 <fuse117[m]> is there a preferred method for debugging embedded rust apps? i am hitting some stack overflows on an app running on an nrf9160. i have never debugged an embedded rust app, but i feel like i need to now

18:08 <barnabyw[m]> <fuse117[m]> "is there a preferred method..." <- it’s a while since I’ve used it, but probe-rs and vscode can be used for interactive debugging https://probe.rs/docs/tools/debugger/

18:12 <TimSmall[m]> barnabyw[m]: fuse117: ...or Vim (Vimspector), or any other editor or graphical debugger which supports the Debug Adapter Protocol (DAP).

18:13 <TimSmall[m]> https://microsoft.github.io/debug-adapter-protocol//implementors/tools/

19:46 <thejpster[m]> Apropos my thoughts earlier on a no-std team, here’s what what-async are thinking: https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async/topic/checkboxes.20on.20async.20stabilizations

19:46 <thejpster[m]> s/what/wg/

20:25 <fu5ha[m]> <ryan-summers[m]> "But still, this is essentially..." <- Not really... They're very distinct concepts although can totally understand they feel similar. There's overlap in the things they can accomplish but dyn lets you write code that is impossible to express with generics/impl trait. A generic type, whether an... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/NAOIMpZLhJpOMzPkcmghehaX>)