14:20 <thalesfragoso[m]> reitermarkus: For the heapless problem, I was thinking on a way to still keep UnionNode. I thought about one, but it isn't wait-free: the idea is to have a stub pointer on the `Stack` structure, and replace the head with it before reading the next node. That way, if a second thread tries to pop one too, it would see the stub and wait/try-again.

14:21 <thalesfragoso[m]> But that is awful for bare metal without real threads, it would be a live-lock.

14:22 <thalesfragoso[m]> Let me know if you have any ideas, because I close to giving up and just suggest to get rid of `UnionNode` and eat the 4/8 bytes per boxed object :/

14:22 <thalesfragoso[m]> * because I'm close

14:25 <thalesfragoso[m]> Context for other people that might have suggestions:

14:25 <thalesfragoso[m]> https://github.com/rust-embedded/heapless/issues/554

16:26 <reitermarkus[m]> No, I also don't have a better idea at the moment. I think waiting isn't an option even with real threads since you will deadlock if the interleaved try_pop happens in an interrupt, right?

16:43 <thalesfragoso[m]> Probably, unless we return something else, like Error::Busy, which would make application logic more complex. I don't think it's a decent trade-off

16:44 <thalesfragoso[m]> I'm writing some tests with loom + miri now, to see if I can trigger the problem, which would be quite reassuring for future changes.

17:03 <JamesMunns[m]> 👀 is this a trieber stack for heapless pool?

17:26 <thalesfragoso[m]> <JamesMunns[m]> "👀 is this a trieber stack for..." <- Yep

17:26 <thalesfragoso[m]> See the linked issue above.

17:43 <thalesfragoso[m]> Hmm, loom's UnsafeCell::new isn't const .-.

17:44 <thalesfragoso[m]> Let's see if more config flags can solve this...

17:45 <JamesMunns[m]> Yeah, you might need a cfg not loom on the const version

17:45 <JamesMunns[m]> you could look at maitake-sync or cordyceps' loom tests for how we handle that

17:49 <JamesMunns[m]> cordyceps has a module for switching between loom and not loom types: https://github.com/hawkw/mycelium/blob/main/cordyceps/src/loom.rs

17:52 <thalesfragoso[m]> Thanks, I found a ready-to-go macro-rules in maitake-sync

19:14 <thalesfragoso[m]> Hmm, doesn't transmute work on const generic arrays?

19:14 <thalesfragoso[m]> Trying:

19:14 <thalesfragoso[m]> ```rust

19:14 <thalesfragoso[m]> Hmm, doesn't transmute work on const generic arrays?

19:14 <thalesfragoso[m]> Trying:

19:14 <thalesfragoso[m]> ```rust

19:17 <thalesfragoso[m]> Hmm, doesn't transmute work on const generic arrays?... (full message at <https://catircservices.org/_irc/v1/media/download/ASWbAgM8m4FkYyLR2IZcegmah93CRgvQouxfj3hoHfY9BoKkV1Qle8tgfAx1pK-tBGVcpbJUHDS_aIMPByCVuVa_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy93b0xRVlVGSnJUUVVyVURJSlhoa2d2c2o>)

19:21 <thalesfragoso[m]> * Hmm, doesn't transmute work on const generic arrays?... (full message at <https://catircservices.org/_irc/v1/media/download/AZ2-V16bj-rWTv-rr4MCfrwMMpZgoyt7DAqa_MgqXBguY7NdjBgAGPg0UFZ72-48m1OL_PpOltGQb55WzkoabOS_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy93YkV2Q0lKQ3Nia3FLcWZidG5xTUh3YUU>)

19:28 <dirbaio[m]> Nope, the compiler currently can't see "if N is the same then the two arrays' size is the same"

19:29 <dirbaio[m]> You can sorta workaround it with transmuting pointers/references/slices

19:29 <dirbaio[m]> Because their size doesn't depend on N

19:44 <thalesfragoso[m]> I just used transmute_copy

19:44 <thalesfragoso[m]> s//`/, s//` for now/

19:50 <thalesfragoso[m]> But now I need AtomicU128 to properly run the tests...

21:05 <rafael[m]> Hi, out of sudden madness and possibly explained by too much beer I have tried my hand on implementing overclocking in embassy-rp for the rp2040. After shouting at an AI for a long time and reading through the datasheet and trying to... (full message at

21:05 <rafael[m]> <https://catircservices.org/_irc/v1/media/download/AWmMjw_klpoL1c9xMrnoHHKliGtHFYUH9_UecwOtyjICgsjhTCXnPl4C7xP7WB15XPX9NeOemkiBeOFd2OF8iyi_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9zWE5oZlBSSHhBZHFFU0NCVnloZmVaRVY>)

21:19 <dngrs[m]> <rafael[m]> "Hi, out of sudden madness and..." <- the #rp-rs:matrix.org might have additional people knowledgeable about this

22:34 <M9names[m]> Maybe the default value for the register is bad? There are 3 writable fields in that register, maybe you should set all the values instead of just the one?