00:50 <JamesMunns[m]> For unsafe code, I do a LOT more "one step at a time" stuff

00:51 <JamesMunns[m]> like, I do this out of paranoia of accidentally double casting wrong:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/RGRCzzgQIiUWeLLlmAiXUAIZ>)

00:52 <JamesMunns[m]> <dirbaio[m]> "fun footgun..." <- `[T: Copy; N]` is `Copy`

00:52 <JamesMunns[m]> unsafe code and T: Copy is for sure a dangerous combo. I definitely suggest taking references/ptrs explicitly

00:53 <dirbaio[m]> Yea. If you think about it it makes sense

00:53 <dirbaio[m]> But still

00:53 <dirbaio[m]> You write `FOO.get_mut()`

00:54 <dirbaio[m]> Then get the error that accessing FOO is unsafe

00:54 <dirbaio[m]> So you wrap it with `unsafe{}`

00:54 <dirbaio[m]> And bang

00:55 <dirbaio[m]> Broken code :S

00:55 <JamesMunns[m]> yep

00:55 <JamesMunns[m]> I had something similar in some unsafe FFI code before

00:55 <JamesMunns[m]> I definitely know what you mean

00:55 <JamesMunns[m]> honestly might be worth opening a diagnostics issue for that

00:56 <JamesMunns[m]> "unsafe block performs copy of static mut" or something

00:56 <dirbaio[m]> My Mental model for unsafe{} is it let's you do more stuff, but it doesn't change the meaning of the code

00:56 <dirbaio[m]> But in this case it does :D

00:56 <JamesMunns[m]> would { foo }.get_mut() do the same if it was a local var?

00:57 <dirbaio[m]> I think so yes

00:59 <JamesMunns[m]> https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=604c5111bcd72deac735e208726b4c90

00:59 <JamesMunns[m]> its more clear that a temporary is being made in this code

01:00 <JamesMunns[m]> ahh I see you're not binding it

01:03 <dirbaio[m]> Yea. With "if let" the temporary lives for the entire if block.

01:03 <dirbaio[m]> So you don't "notice" it heh

01:04 <JamesMunns[m]> I still think it's worth a diagnostic issue :)

01:04 <JamesMunns[m]> All the help we can get with unsafe, y'know?

01:06 <dirbaio[m]> Yea.. With static mut it's easy to fall into the trap because you have a reason to wrap it with {}

02:46 <JamesMunns[m]> Hey ithinuel, lemme know if you have some time to chat. I've been working on a next gen version of bbqueue :)

07:29 <ilya-epifanov[m]> guys, how do you use floating point functions on a compatible target (thumbv7em-none-eabihf)? Stuff like .powi(), .sqrt(), trigs?

07:47 <ilya-epifanov[m]> I'm now using libm but there's gotta be a better way

09:31 <sourcebox[m]> <ilya-epifanov[m]> "I'm now using libm but there's..." <- You can use `micromath` if precision is not that important: https://crates.io/crates/micromath

10:43 <reitermarkus[m]> Hi, does anyone know if there is a crate for controlling GPIOs via DMA on a Raspberry Pi? Or any other way of getting reliable timings for sending RF signals.

15:29 <AlexandrosLiarok> what is my best bet on getting an async ssd1309 driver compatible with embedded_graphics ?

15:29 <AlexandrosLiarok> the ssd1309 crate is on an old hal, there is a PR for bumping it to v1 but that is still blocking and doesn't play well with my embassy superloop.

15:29 <JamesMunns[m]> tbh, it's complicated because embedded_graphics isn't async

15:30 <JamesMunns[m]> one option is to use interrupt executors, and do display stuff at the lowest priority, and just do it blocking

15:31 <AlexandrosLiarok> the driver uses a framebuffer and only transmits on flush call.

15:31 <AlexandrosLiarok> I am /mostly/ okay as long as just that is async because I can yield between draw calls.

15:32 <JamesMunns[m]> so, do JUST your graphics rendering at low prio, and do basically everything else at one or more higher prio levels.

15:32 <JamesMunns[m]> you can also make a "fake" display framebuffer, render to that, then do your own manual "flush" command

15:33 <JamesMunns[m]> (i'm not familiar to the ssd1309 specifically tho, but I don't think theres a specific awesome way to do it)

15:36 <AlexandrosLiarok> fair enough, it seems it uses display_interface's WriteOnlyDataCommand to implement the functionality and then has a light layer for the embedded_graphics part.

15:37 <AlexandrosLiarok> I guess I could port it to use AsyncWriteOnlyDataCommand

15:38 <AlexandrosLiarok> then it can be async for all methods including flush and also implement DrawableTarget with a framebuffer.

15:39 <AlexandrosLiarok> there is also this crate: https://docs.rs/oled_async/latest/oled_async/mode/graphics/struct.GraphicsMode.html