02:07 <AaronTsui[m]> Hi, about "rust async infectious", what is your thoughts? For me, it is annoying sometimes, indeed.

02:24 <JamesMunns[m]> <AaronTsui[m]> "Hi, about "rust async infectious..." <- This is a very contentious question, and you are likely to get passionate answers from people who do and do not prefer working with async.

02:26 <JamesMunns[m]> In my opinion, it is sort of like using allocations: it's difficult to only use it sometimes, and if you really aren't using an allocator, having one library that does use it is challenging.

02:27 <JamesMunns[m]> But also like using allocation or not, neither way is "right" or "wrong". It's a mix of preference and whether it makes sense for what you are doing.

02:29 <JamesMunns[m]> so: yeah! it can be a little difficult to mix async and not-async code in a project! They solve problems in fairly different ways, and that means that sometimes it's hard to mix them practically, especially on embedded systems where resources are limited.

02:36 <JamesMunns[m]> Anyway, I hope that helps, and you get more constructive thoughts from other folks than "I like async" or "I don't like async" :)

07:04 <Kaspar[m]> Well, on non-MMU systems, heap allocations do have the fragmentation issue. So using the heap for more than boot-time static stuff is way more "wrong" than using or not using async.

07:04 <Kaspar[m]> > But also like using allocation or not, neither way is "right" or "wrong".

07:05 <Kaspar[m]> Other than the analogy, IMO a nice answer. 😄

07:49 <JamesZow[m]> https://github.com/rust-embedded/rust-raspberrypi-OS-tutorials/pull/198

07:49 <JamesZow[m]> Hi guys, a new committer has submitted a QEMU patch for Raspberry Pi 4. can take a look?

08:28 <FreeKill[m]> <FreeKill[m]> "image.png" <- Now also supports Linux 😊

08:30 <M9names[m]> What does?

08:52 <FreeKill[m]> GitHub.com/eekle/nesiac

09:50 <romancardenas[m]> Hey folks! I'm moving my library crates to `portable-atomic` and I have a doubt regarding the features to be enabled. Right now I specify the dependency as:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/GIupYxOkKFZVwzWRGipsvzDN>)

10:16 <dirbaio[m]> > And leave two features to let users use either `critical-section` or `unsafe-assume-single-core`

10:16 <dirbaio[m]> Yes this is the way

10:17 <romancardenas[m]> Great, thank you!

10:18 <dirbaio[m]> Or you can not add the features and tell the user to add a dep on portable-atomic themselves

10:18 <dirbaio[m]> less intuitive maybe tho

10:20 <romancardenas[m]> I guess that the main "issue" with this is cascading the feature selection when you depend on other portable-atomic-dependent crate

11:36 <mciantyre[m]> <vrakaslabs[m]> "Added MIT License file 🤠" <- The example on the `broken` branch appears to overflow the stack. It places a `TxDT<512, 12>` and a `RxDT<512, 12>` on the stack, requiring 12KiB just for data buffers. We're OK at this point.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/kAoQoxzCEVsvquEfnpRNmNws>)

11:37 <mciantyre[m]> s/just//, s/on the stack//

11:46 <mciantyre[m]> * The example on the `broken` branch appears to overflow the stack. It places a `TxDT<512, 12>` and a `RxDT<512, 12>` on the stack, requiring 12KiB just for data buffers. We're OK at this point.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/VtLRWkCeOPrLwqYgKIXkUUNt>)

14:00 <thejpster[m]> weeeeeeeeee

14:00 <thejpster[m]> https://www.youtube.com/watch?v=GiOyHH1eJhE

14:01 <diondokter[m]> Sadly can't make it :(

14:09 <JamesMunns[m]> <thejpster[m]> "https://www.youtube.com/watch?v..." <- Congrats to all y'all :)

15:04 <thejpster[m]> diondokter: it's a YT stream you can catch the panels later. Or keep smashing refresh on our blog for the announcement (if cloudflare don't fuck it up again).

15:04 <Lumpio[m]> 🎉

15:05 <thejpster[m]> We build our website in GHA and any branch gets pushed to a private instance with a secret hostname. Except the other day when any branches got pushed to the production site. What a day for that bug to drop.

15:05 <thejpster[m]> s/fuck/screw/

15:24 <JamesMunns[m]> By the way, just published a blog post called "interrupts is threads", which is mostly meant to help non-embedded-rust folks understand why we model interrupts as if they were threads:

15:24 <JamesMunns[m]> https://onevariable.com/blog/interrupts-is-threads/

16:26 <thejpster[m]> Ferrocene's source code is available under Apache-2.0 / MIT, including all the RST documents for our qualification material under the same licence.

16:27 <thejpster[m]> https://github.com/ferrocene/ferrocene

16:27 <JamesMunns[m]> Congrats y'all, I know that was the original dream, and you deserve a ton of credit for making it a reality :)

16:28 <thejpster[m]> https://ferrous-systems.com/blog/ferrocene-open-source/

16:28 <JamesMunns[m]> SIL4/ASIL D, yowza! that's even more than the original (initial) dream :)

16:30 <JamesMunns[m]> Can't wait until the first customer calls and asks for help putting something into production!

16:30 <ryan-summers[m]> Gotta get them on the Rust hype train

16:30 <ryan-summers[m]> Finally can send this to my safety critical consulting friends :) Glad to see it announced!

17:10 <diondokter[m]> Oh wow, I didn't expect ferrocene to be open sourced! And the pricing is very workable too, even for small teams or companies.

17:10 <diondokter[m]> Very exciting 😁

17:10 <diondokter[m]> I have some slide decks that need updating now 🙂

17:13 <juliand[m]> diondokter[m]: > <@diondokter:matrix.org> Oh wow, I didn't expect ferrocene to be open sourced! And the pricing is very workable too, even for small teams or companies.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/LTPppAJyYpbOCdTUdanaRNDG>)

19:00 <GrantM11235[m]> <JamesMunns[m]> "By the way, just published a..." <- > <@jamesmunns:beeper.com> By the way, just published a blog post called "interrupts is threads", which is mostly meant to help non-embedded-rust folks understand why we model interrupts as if they were threads:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/jQOXAlFzMCFdGXwAZfMEGfHN>)

19:01 <JamesMunns[m]> GrantM11235[m]: Hah! Also 100% true :)

19:01 <JamesMunns[m]> (dma is, in fact, also threads)

20:25 <adamgreig[m]> <JamesMunns[m]> "SIL4/ASIL D, yowza! that's even..." <- Yea, wow!! Very pleasant surprise

22:26 <ilpalazzo-ojiis4> So, how does one go about describing the process to a prospective client? Is the phrase “The rubber stamp has already been inked, and all that's left is to press it on the paper, which will take a few weeks give-or-take” accurate enough?

22:26 <ilpalazzo-ojiis4> s/does/would/

22:26 <ilpalazzo-ojiis4> s/does/would/, s/process/progress/