00:01 <dirbaio[m]> i'm quite sure that's not breaking

00:03 <adamgreig[m]> I think the breaking change is in the PACs swapping to use c-m-i-n instead of c-m's own trait

00:03 <adamgreig[m]> but at least it's very easily resolved

00:03 <dirbaio[m]> ah yes that's breaking

00:03 <dirbaio[m]> but every PAC release is breaking anyway..

00:04 <adamgreig[m]> yea...

00:04 <adamgreig[m]> it feels like replacing a trait with one that has the same name but is technically a different type could be breaking, but I'm not convinced it is since everything in the build will now only know about the new type and therefore keep working fine

00:04 <adamgreig[m]> anyway I'll do a little test this weekend

00:05 <dirbaio[m]> it's not breaking, you've moved the type somewhere else and added a reexport

00:05 <dirbaio[m]> but it's still the "same" type

00:06 <adamgreig[m]> will cargo-semver-checks agree 🤔

00:06 <dirbaio[m]> cargo-semver-checks is still in very early stages 🥲

00:07 <adamgreig[m]> it doesn't violate anything in https://doc.rust-lang.org/cargo/reference/semver.html anyway

00:08 <adamgreig[m]> I was also going to see how it looks to revert cortex-m master branch back to 0.7(.7) and yank the only breaking-change commit to a new branch

08:46 <dsvsdveg[m]> what are library for esp32 please

08:55 <Lumpio-> What kind of library are you looking for? There's many

08:56 <Lumpio-> Or are you just getting started and would like to know how to get it running to begin with

09:01 <dav1d> Here's a list of things to get started: https://github.com/esp-rs/awesome-esp-rust

09:09 <jake_001[m]> What is the recommended toolchain for working with thes riscv32imac ISA? I'm playing around with WCH series of micro-controllers the ch32v203C8T6 at the moment.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ithRQMcuZokQmrOlnOtcAbtR>)

09:33 <fu5ha[m]> <dsvsdveg[m]> "> <@9names:matrix.org> this is..." <- It's not really a collaboration if it's "your" project but others are just telling you what to do. If you want collaborators then you should be bringing things to the collaboration and making something better together than any could do on their own. If you're doing a term project for school, it's *your* project and yes it's totally valid to ask for help but you shouldn't expect

09:33 <fu5ha[m]> people to just tell you what to do from the very start. You need to pick your own direction and try to accomplish the task and then when you run into concrete issues/questions you can come back and ask for help on those. Nobody else is going to care enough about your project to truly "collaborate" with you unless you're bringing something new to the table that they think they can also benefit from themselves.

09:48 <jake_001[m]> Never-mind solved my issue of getting it to compile. The problem was the directory I was working in was on my NFS share and I forgot about that being an issue. Moved the directory/repo to my dev machine locally and compiled and linked just fine

14:55 <waveguide[m]> Anyone make progress on an armv7-a or -r crate? I thought I read someone wanted to make one for zynq

17:21 <BenPyeHeThey[m]> dirbaio Would there be any opposition to adding unsafe register variants?

17:23 <BenPyeHeThey[m]> Some of the peripherals I'm trying to support (via chiptool) include DMA addresses or interrupt vectors, etc. I think it would be preferable to have options of UnsafeRead, UnsafeWrite, UnsafeReadWrite, ReadUnsafeWrite to model that sort of thing. These all fall under ReadUnsafeWrite - but it's not inconcievable that some hardware has a register whose read has unsafe effects.

17:50 <lulf[m]> -

18:28 <dsvsdveg[m]> <fu5ha[m]> "It's not really a collaboration..." <- imo rust is too much fresh for what i'm looking, in C it would be more modular to do what i want du of the big ecosystem for embedded but in Rust i truly need some advice from more experiment then me

18:28 <dsvsdveg[m]> Anyway, what crate do you guys advice for ESP32

21:01 <thejpster[m]> TIL that Github Merge Queues break my release model

21:03 <thejpster[m]> I do all my changes on the `develop` branch, then cut a release branch off that which gets merged into `main`. The `main` branch is tagged, and then backported on to `develop`. This means `main` only has a series of merge commits, each corresponding to a release.

21:03 <thejpster[m]> However, github merge queues don't do merge commits, they just rebase all the changes over onto `main`, which makes a huge mess and I have to turn off force-push protection so I can put things back as they were.

21:03 <thejpster[m]> You'll probably tell me I'm just holding it wrong, but I quite like my process.

21:47 <dav1d> Anyone know how I can build the patched rust toolchain for Xtensa with a new nightly version? / https://github.com/esp-rs/rust-build

21:52 <danielb[m]> You need to rebase the changes in esp-rs/rust first, I believe

21:52 <danielb[m]> Easier to fork your dependencies and add back the feature gates ;)

21:53 <dav1d> damn, yeah looks like it wont be as easy as I hoped

22:09 <BenPyeHeThey[m]> Blah - I managed to break bindeps again 🙁 Looks like it isn't handling features correctly when something is both a dependency and a build-dependecy of your artifact dependecy, and so it tries to enable std for the bare metal target

23:02 <adamgreig[m]> <thejpster[m]> "I do all my changes on the `..." <- > <@thejpster:matrix.org> I do all my changes on the `develop` branch, then cut a release branch off that which gets merged into `main`. The `main` branch is tagged, and then backported on to `develop`. This means `main` only has a series of merge commits... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/HnoERdhHhMREHmUJMvNjNSto>)

23:02 <adamgreig[m]> https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue#managing-a-merge-queue