04:34 <AndoThorNando[m]> Did a few tweaks and added a paragraph about writing to a register. It’s published now :)

11:54 <hicklin[m]> I have submitted a couple of PRs ([#521](https://github.com/rust-embedded/heapless/pull/521) and [#524](https://github.com/rust-embedded/heapless/pull/524)) to the heapless crate that implement some missing features for `Deque`. These have been open for a month but there hasn't been any communication or reviews. Is this the correct forum to ask for reviews?

12:51 <thejpster[m]> Is it possible for force cargo to consider a pre-release as a stable release? and use that pre-release across the dependency tree?

12:51 <thejpster[m]> https://rust-lang.github.io/rfcs//3493-precise-pre-release-cargo-update.html implies it isn't :(

13:07 <AlexandrosLiarok> is anyone aware of any convenient method to generate const lookup tables using rust math expressions ?

13:08 <AlexandrosLiarok> * expressions ? Either a const-fn math library or a procedural macro one maybe.

13:08 <AlexandrosLiarok> * is anyone aware of any convenient method to generate const tables using rust math expressions ? Either a const-fn math library or a procedural macro one maybe.

13:12 <AlexandrosLiarok> I guess main problem is I need to use f32 const-fn logs/exps

13:13 <AlexandrosLiarok> I can do this with build-script generated tables but I don't think it is ideal.

13:19 <AndoThorNando[m]> There’s an issue with const fn for floating point as the compiler evaluating the function may be on a different architecture with a conflicting floating point implementation to the target architecture causing potential for unsound code

13:20 <AndoThorNando[m]> There is https://docs.rs/const_soft_float/latest/const_soft_float/index.html which might be of use?

13:21 <diondokter[m]> Const floating point has been stabilized in 1.82!

13:22 <AndoThorNando[m]> I stand corrected! Great news

13:25 <AlexandrosLiarok> yea one annoying issue is that I don't think many of the floating point functions are available in the non-std targets

13:25 <AlexandrosLiarok> so one can't take advantage of the const fn. I guess I will just go with the build script and be done with it

13:27 <AndoThorNando[m]> The crate I linked above is no_std and const fn if that helps

13:29 <AlexandrosLiarok> I am aware of it but it doesn't have exp/log functions unfortunately.

13:55 <burrbull[m]> <AlexandrosLiarok> "I am aware of it but it doesn'..." <- Yeah, unfortunately https://github.com/rust-lang/libm/issues/310

16:07 <dirbaio[m]> rust 1.84 is out 🚀

16:07 <dirbaio[m]> https://blog.rust-lang.org/2025/01/09/Rust-1.84.0.html

16:09 <danielb[m]> finally you can bump msrv in patch releases and people who opt in, won't get mad at you :D

16:42 <thejpster[m]> ooooh: https://doc.rust-lang.org/std/ptr/fn.with_exposed_provenance.html

16:42 <thejpster[m]> > This is fully equivalent to addr as *const T. The provenance of the returned pointer is that of some pointer that was previously exposed by passing it to expose_provenance, or a ptr as usize cast. In addition, memory which is outside the control of the Rust abstract machine (MMIO registers, for example) is always considered to be accessible with an exposed provenance, so long as this memory is disjoint from memory that will be

16:42 <thejpster[m]> used by the abstract machine such as the stack, heap, and statics.

16:44 <JamesMunns[m]> Oh I didn't realize that was stabilizing!

16:44 <danielb[m]> > The provenance of the returned pointer is that of some pointer that was previously exposed

16:44 <danielb[m]> You still have to start with a pointer 🥲

16:45 <JamesMunns[m]> whatcha mean?

16:46 <danielb[m]> I mean this still doesn't handle the "we conjure up a register block at a particular address" case I asked about yesterday

16:47 <danielb[m]> the Exposed Provenance chapter contains this:

16:47 <danielb[m]> > Bare-metal platforms can also require the synthesis of a pointer “out of thin air” without anywhere to obtain proper provenance from.

16:47 <danielb[m]> so the current api still doesn't cover all the author wants, it seems?

16:47 <JamesMunns[m]> it doesn't? the second part of what JP quoted seems to cover that?

16:47 <JamesMunns[m]> > In addition, memory which is outside the control of the Rust abstract machine (MMIO registers, for example) is always considered to be accessible with an exposed provenance, so long as this memory is disjoint from memory that will be used by the abstract machine such as the stack, heap, and statics.

16:47 <JamesMunns[m]> which means you can use yolo ints as long as the addrs are outside of the AM?

16:48 <danielb[m]> ah okay I didn't read far enough :D

16:48 <JamesMunns[m]> like you can't use that for a static addr, but you can use it for a hw addr outside of the linker script basically

16:49 <JamesMunns[m]> I wonder why it isn't a const fn 🤔

17:47 <thejpster[m]> You should ask :)

17:47 <thejpster[m]> (Like it EDWG doesn’t know, the rest of us don’t stand a chance)