<re_irc>
<@dkhayes117:matrix.org> I'm working through the new microbit version of the discovery book :) I'm debugging in GDB but when I try `break main` I get ` No symbol table is loaded. use the "file" command`. What am I missing?
<re_irc>
<@adamgreig:matrix.org> when you run gdb, do you give it the location of the elf as the command line argument?
<re_irc>
<@adamgreig:matrix.org> you could also supply it after starting with "file /path/to/elf"
<re_irc>
<@dkhayes117:matrix.org> I ran cargo embed in one terminal where it halts_afterwards. Then I do ` gdb target/thumbv7em-none-eabihf/debug/led-roulette
<re_irc>
<@dkhayes117:matrix.org> `
<re_irc>
<@adamgreig:matrix.org> that seems reasonable... is your gdb multi-arch and does it give any warnings or errors when you start it?
<re_irc>
<@adamgreig:matrix.org> (maybe you need `arm-none-eabi-gdb` or `gdb-multiarch`)
<re_irc>
<@dkhayes117:matrix.org> I just reflashed it, then tried it again, and I get no warnings just `no symbol table is loaded` on the gdb side again.
<re_irc>
<@adamgreig:matrix.org> sorry, I mean whether gdb says anything when you start it
<re_irc>
<@adamgreig:matrix.org> (maybe you need to run `gdb-multiarch` instead of plain `gdb`?)
<re_irc>
<@adamgreig:matrix.org> huh, given you gave it a file path i'd have hoped for a warning or error instead of nothing
<re_irc>
<@dkhayes117:matrix.org> Okay I think I fixed it.
<re_irc>
<@adamgreig:matrix.org> maybe something's quietening it
<re_irc>
<@adamgreig:matrix.org> what was it?
<re_irc>
<@dkhayes117:matrix.org> I was running the gdb command from inside the `.../src/05-led-roulette directory`. running it from just `.../microbit` allowed the break point.
<re_irc>
<@adamgreig:matrix.org> huh
<re_irc>
<@dkhayes117:matrix.org> Now I get this
<re_irc>
<@dkhayes117:matrix.org> Breakpoint 1 at 0x164: file src/05-led-roulette/src/main.rs, line 9.
<re_irc>
<@dkhayes117:matrix.org> Oh. It says in the book about possibly using `gdb-multiarch` instead 🤦♂️
<re_irc>
<@dkhayes117:matrix.org> and running from the project directory and not the chapter dir, excuse my ignorance.
starblue has quit [Ping timeout: 256 seconds]
crabbedhaloablut has quit [Remote host closed the connection]
starblue has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
rardiol has quit [Ping timeout: 256 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 256 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 256 seconds]
smach has joined #rust-embedded
smach has quit [Remote host closed the connection]
fooker has quit [Ping timeout: 240 seconds]
fabic has joined #rust-embedded
gsalazar has joined #rust-embedded
<re_irc>
<@jamesmunns:beeper.com> If any of y'all have opinions on const generic parameters, and compile time configuration, I'd be interested in your feedback here:
<re_irc>
<@jamesmunns:beeper.com> (especially if you have a different/better way of dealing with this!)
<re_irc>
<@jamesmunns:beeper.com> It's one of the *few* places I miss C's `#define` capabilities vs Rust's config flags.
<cr1901>
I remember reading a blog post about this a few months ago asking for the same thing.
<cr1901>
It compared the 3 things (plus one other) you put in your poll and concluded that "no solution is strictly better than the others"
<cr1901>
jamesmunns: Sadly, the blog post is not in my recent browser history. But I'll see if I can find it in my backups later.
<re_irc>
<@dirbaio:matrix.org> just add a bunch of cargo features: `buffer-size-8`, `buffer-size-16`, `buffer-size-32`, `buffer-size-64`.. 🤪
<cr1901>
I wish "feature" wasn't the only blessed cfg option sometimes
<re_irc>
<@jamesmunns:beeper.com> dirbaio yeah, I guess that's an option, but I really don't want to do that lol
<re_irc>
<@jamesmunns:beeper.com> The three I listed are at least palatable, though I agree with cr1901, all of them are annoying in some way.
<re_irc>
<@jamesmunns:beeper.com> I'm leaning towards the "cargo patch" approach, though I haven't seen anyone use it after I wrote up the idea a while back. Maybe I'll start a trend.
<re_irc>
<@dirbaio:matrix.org> maybe it's possible to change the design so that you only pass slices around?
<cr1901>
>I wish "feature" wasn't the only blessed cfg option sometime <-- to elaborate
<cr1901>
cargo knows how to split --features so its automatically only passed to the correct crate
<cr1901>
So "cargo rustc" won't work for passing down compile-time defines w/o work
<re_irc>
<@jamesmunns:beeper.com> dirbaio not really. A lot of this is the propagation of the generics in `byte-slab` as my allocator type, similar to heapless' params
<cr1901>
build.rs+cfg file is what I chose for the poll, FWIW
<re_irc>
<@dirbaio:matrix.org> for example in smoltcp, only the lowest-level Device knows the buffer size (MTU), higher layers ask it for a buffer slice when they want to send/receive
<re_irc>
<@jamesmunns:beeper.com> Maybe I'll make up a boilerplate crate that does the toml parsing and generation of constants. Something like
<re_irc>
<@jamesmunns:beeper.com> `toml-config`, where you can set parameters on a per-crate basis
<re_irc>
<@dirbaio:matrix.org> so there's no const generics spam, and no mandatory allocator either
<re_irc>
<@jamesmunns:beeper.com> so it sort of becomes a standard
<re_irc>
<@dirbaio:matrix.org> the Device impl can use an allocator for a packet queue *if it wants to*
<re_irc>
<@jamesmunns:beeper.com> Yeah, I went from "all references" to "no references", there might be a happier middle ground
<cr1901>
(I guess my question is: "why do you want no references in the first place"?)
<re_irc>
<@dirbaio:matrix.org> but the whole stack works on slices borrowed from the Device
<cr1901>
This is my "I don't like passing EVERYTHING on the stack" talking
<re_irc>
<@jamesmunns:beeper.com> cr1901 it got REAL bad. like 3-4 references per function
<re_irc>
<@jamesmunns:beeper.com> with `byte-slab`, I don't pass by ownership, it's a mini-slab-allocator basically
gsalazar_ has joined #rust-embedded
<cr1901>
jamesmunns: Sorry I would have to see an example to comment (and feel free to not do that, as I'm still not doing so hot)
<re_irc>
<@jamesmunns:beeper.com> sort of like `heapless::Pool`, but it carries const generic parameters (size of each slab and the total number of slabs) on all of it's `Box`s and `Arc`s and such
<cr1901>
I mainly asked that question as a minddump for later
<re_irc>
<@jamesmunns:beeper.com> I appreciate it!
<re_irc>
<@jamesmunns:beeper.com> And hope you feel better soon :)
<cr1901>
Yup, I'm already feeling much better than last night. Just not at 100%. Esp not at 6am in the morning (I slept from like 10 to 5)
<cr1901>
Tyvm
gsalazar has quit [Ping timeout: 256 seconds]
<cr1901>
https://github.com/cr1901/AT2XT/blob/master/src/keybuffer.rs FWIW, I've thought about replacing this with the "worlds smallest Rust queue impl" as "My First Const Generics". But I want to be absolutely certain there's no code size penalty
<cr1901>
The other problem is I can't enforce "power-of-two" size, which is the only way this is "world's smallest".
<re_irc>
<@korken89:matrix.org> For people using Nordic's PPK2, does anyone know if there is a Rust crate for it? So one can write apps around it. I saw there is this Python package, but I can't find any Rust crate. https://github.com/IRNAS/ppk2-api-python
<re_irc>
<@korken89:matrix.org> I'd love to combine the PPK2 with probe-rs to do automatic programming, messaging and power measurements
<cr1901>
Except in toy examples, I've yet to see real world Rust code where e.g. "'me: 'req" is actually required.
<cr1901>
I would love for someone to work through a real world example of "being a manual borrow checker" and "how the borrow checker dies if that bound isn't there".
<re_irc>
<@jamesmunns:beeper.com> I streamed it a while back, but to be honest, I ripped it out instead of trying to re-understand it.
<re_irc>
<@jamesmunns:beeper.com> I admit some of the lifetimes were determined by throwing spaghetti at the wall to see what made the code compile, and done in a low-sleep deadline rush
<re_irc>
<@korken89:matrix.org> E.g. `fugit` gets a lot more powerful when it has a default as "base case"
<re_irc>
<@ia0:matrix.org> jamesmunns:beeper.com: What about using a `trait Config { const FOO: usize; ... }` then using `<C: Config>` n your functions? Essentially having traits act as type-level structs
<re_irc>
<@jamesmunns:beeper.com> Yup, I could do that! It would still mean I need to have one generic on every item, but one is certainly better than two!
fooker has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> jamesmunns:beeper.com: I don't have a twitter account, but I made use of them recently: A struct that holds a mic array, with each mic having flexible length. Eg so I can use it to analyze audio in large block sizes, or process realtime with short ones
<re_irc>
<@firefrommoonlight:matrix.org> I don't fully understand them, but it seems they solve the problem here. Re your syntax concern: Yea, it adds a `::<BLOCK_SIZE>` or w/e whenever you deal the struct (Or constructors for it etc)
<re_irc>
<@firefrommoonlight:matrix.org> Without that, I think I'd need egregious DRY
<re_irc>
<@firefrommoonlight:matrix.org> *I don't fully understand const generics and haven't IDed any use case; just my 2c where they helped me out recently
gsalazar_ is now known as gsalazar
gsalazar has quit [Quit: Leaving]
gsalazar has joined #rust-embedded
gsalazar has quit [Client Quit]
gsalazar_ has joined #rust-embedded
gsalazar_ has quit [Remote host closed the connection]
gsalazar has joined #rust-embedded
<re_irc>
<@diondokter:matrix.org> Hey all!
<re_irc>
<@diondokter:matrix.org> We're looking for someone that can help us with a small (paid) review task.
<re_irc>
<@diondokter:matrix.org> Due to circumstances, we're building a bootloader for the nRF9160. The decision to start building it came pretty last-minute, so we're in a hurry to finish it.
<re_irc>
<@diondokter:matrix.org> Because it is so last-minute, we don't have a lot of time to test. That's why we would value someone with a bit of experience with bootloaders to come help us and potentially spot some mistakes.
<re_irc>
<@jamesmunns:beeper.com> you could set "global configs" for both `dep` and `subdep`
<re_irc>
<@jamesmunns:beeper.com> so lets say `subdep` had a `BUFFER_SIZE` constant that you wanted to be user-overridable, but don't want to have `BUFFER_SIZE` const param on EVERY struct and function
<re_irc>
<@adamgreig:matrix.org> sorry yea, I mean, why not have the proc macro output a const item in subdep?
<re_irc>
<@jamesmunns:beeper.com> ```toml
<re_irc>
<@jamesmunns:beeper.com> you could then declare:
<re_irc>
<@jamesmunns:beeper.com> okay okay I'll use heck to convert to ShoutySNakeCase
<re_irc>
<@adamgreig:matrix.org> xiretza: neat, but now you can't `use` the const and it's a bit wordy?
<re_irc>
<@adamgreig:matrix.org> haha
<re_irc>
<@adamgreig:matrix.org> idk if it's necessarily better, just seems nice to be able to immediately reference a const
<re_irc>
<@jamesmunns:beeper.com> Yeah, agreed
<re_irc>
<@jamesmunns:beeper.com> Lemme clean up the unwraps, and I'll publish a v0.0.1 version
<re_irc>
<@xiretza:xiretza.xyz> adamgreig: ah, didn't think of that
<re_irc>
<@adamgreig:matrix.org> I've been thinking about register access and how it might be made more obvious whether you're modifying current values or resetting things
<re_irc>
<@adamgreig:matrix.org> ```rust
<re_irc>
<@adamgreig:matrix.org> // Write some fields, others set to 0.
<re_irc>
<@adamgreig:matrix.org> I kinda like the syntax combining my favourite parts of stm32ral (no methods/chaining, you just write out the fields you want), but gaining types per register to allow capturing values easily, using Rust's native "set fields" syntax including the struct update syntax which then combines with either default, reset values, or a read of the register for RMW
<re_irc>
<@adamgreig:matrix.org> under the hood, GPIOE is a `const GPIOE: GPIO<0x40020000>` (i.e. const generic base address), it has a method `write<T: WriteReg>(r: T)`, and there's a `struct ModeR` and `struct BSRR` which both `impl WriteReg`, so you can pass either to `GPIOE.write()` to cause them to be written
<re_irc>
<@adamgreig:matrix.org> it makes the actual operation (which is always "write a full set of fields to this register") more explicit, and the user has to either specify all the fields, or specify where the other fields come from - default, some existing struct, a fresh read, etc
<re_irc>
<@adamgreig:matrix.org> and it's also less visually noisy and less typing and no closures compared to svd2rust
<re_irc>
<@adamgreig:matrix.org> (plus obviously table stakes: no dereferenceable problem, generates optimal assembly, one type per peripheral with an instance/const per instantiation of it)
<re_irc>
<@dirbaio:matrix.org> IMO using const generics for the addr is not nice, it forces the compiler to duplicate code
<re_irc>
<@adamgreig:matrix.org> hmm
<re_irc>
<@adamgreig:matrix.org> trivial to use an instance attribute for the address instead
<re_irc>
<@adamgreig:matrix.org> like, it doesn't change anything in that code snippet
<re_irc>
<@adamgreig:matrix.org> be interesting to see how they compare in terms of codegen I guess
<re_irc>
<@adamgreig:matrix.org> since `GPIOE` is a `const`, maybe it would end up optimised identically
<re_irc>
<@dirbaio:matrix.org> say you have a `fn do_stuff(gpio: GPIO)`, where the addr is known at runtime: the compiler can compile the fn just once and use it for different ports
<re_irc>
<@dirbaio:matrix.org> if you have `fn do_stuff<const ADDR: usize>(gpio: GPIO<ADDR>)` then it'll duplicate it for each port
<re_irc>
<@adamgreig:matrix.org> at the cost of GPIOs not being ZST to pass around, I guess
<re_irc>
<@adamgreig:matrix.org> but whatever, if you're passing &GPIO to some const, nbd
<re_irc>
<@dirbaio:matrix.org> the compiler already optimizes/inlines everything that's trivial
<re_irc>
<@adamgreig:matrix.org> yea
<re_irc>
<@adamgreig:matrix.org> I think the interesting distinction is using structs with a field for every register field, instead of newtype u32s that have methods to change it
<re_irc>
<@adamgreig:matrix.org> which is what permits using struct update syntax to specify the other fields (and gives the nicer syntax imo)
<re_irc>
<@adamgreig:matrix.org> there's a few things that you have to be careful about, like how easy it is to work around buggy PAC data (provide some way to just read/write a raw u32 of the whole register, ensure the field enums have variants for unknown values you can construct if needed even if they're like a tag and a value), and it took a little fiddling to get it to output the optimal code and not try deserialising and...
<re_irc>
... reserialising the entire struct and all its fields etc
<re_irc>
<@adamgreig:matrix.org> but this prototype works on hardware and makes the optimal couple-of-instructions asm, so, promising
<re_irc>
<@adamgreig:matrix.org> James Munns: hmm, I guess even rerun-if-changed in build.rs wouldn't work, right?
<re_irc>
<@adamgreig:matrix.org> it won't rebuild the dep
<re_irc>
<@jamesmunns:beeper.com> Can I trigger that from a proc macro?
<re_irc>
<@dirbaio:matrix.org> jamesmunns:beeper.com: ooof... perhaps if you add a dummy `include_bytes!` to the macro output, to get it to consider cfg.toml as a "dependency"?
<re_irc>
<@jamesmunns:beeper.com> e.g. in:
<re_irc>
<@jamesmunns:beeper.com> `app->dep->subdep`, I want a change of `app/cfg.toml` to trigger a rebuild of `subdep`
<re_irc>
<@adamgreig:matrix.org> can include_bytes from the dep possibly know the path to the toml in the app?
<re_irc>
<@dirbaio:matrix.org> well, the proc macro knows the path since it's reading it
<re_irc>
<@adamgreig:matrix.org> even then idk if cargo would even check for a dep from crates.io instead of a local file path
<re_irc>
<@jamesmunns:beeper.com> Added a note, I'll let them triage :D
<re_irc>
<@adamgreig:matrix.org> dirbaio: unsurprisingly using instance attributes instead of const generics ends up with the exact same codegen
<re_irc>
<@dirbaio:matrix.org> nice! :D
<re_irc>
<@adamgreig:matrix.org> might need a bit more thought about where things take references I guess
<re_irc>
<@adamgreig:matrix.org> I can see the appeal though, does make it way easier to use
<re_irc>
<@dirbaio:matrix.org> the const generics make it easier to use?
<re_irc>
<@dirbaio:matrix.org> why?
<re_irc>
<@adamgreig:matrix.org> no, not having them makes it easier to use
<re_irc>
<@dirbaio:matrix.org> ah 👍️
<re_irc>
<@dirbaio:matrix.org> agreed
<re_irc>
<@adamgreig:matrix.org> I wish there was a shorter way to write `..Default::default()` though..
<re_irc>
<@dirbaio:matrix.org> I think you can `use` it then it's just `..default()`...
<re_irc>
<@adamgreig:matrix.org> hmm, I didn't think that worked for some reason
<re_irc>
<@adamgreig:matrix.org> anyway, welcome back room and happy new year, meeting time again! agenda is https://hackmd.io/1GX3gGqJRe-RSRuoz3DjnQ, please add anything you'd like to discuss and we'll start in 5min :)
<cr1901>
agg: I'm here, but I'll be in the background. Still not quite feeling 100% today (no, not C19 thankfully)
<re_irc>
<@adamgreig:matrix.org> dirbaio: ah, you can't import `std::default::Default::default`, but there _is_ a new nightly-only API `std::default::default()` which can be imported (but nightly)
<re_irc>
<@adamgreig:matrix.org> cr1901: ack, nw, hope you feel better soon!
<cr1901>
Tyvm, I'm sure I will
<cr1901>
although seeing std::default::Default::default just gave me a headache :P
<re_irc>
<@therealprof:matrix.org> adamgreig: Also for debug mode?
<re_irc>
<@adamgreig:matrix.org> the codegen isn't optimal in debug mode anyway, but I haven't checked if it's exactly the same
<re_irc>
<@adamgreig:matrix.org> the impact's probably negligible compared to the debug mode having to build the structs anyway...
<re_irc>
<@adamgreig:matrix.org> hah, yea, it's as bad as svd2rust, unsurprisingly I guess
<re_irc>
<@therealprof:matrix.org> Yeah, I'm just curious how const generics will fare against non-inlineable function stuff.
<re_irc>
<@adamgreig:matrix.org> oh, since you're around, what else needs doing after someone is added to the r-e org? just PR to https://github.com/rust-lang/team ?
<re_irc>
<@therealprof:matrix.org> Yes. Plus the org setup.
<re_irc>
<@adamgreig:matrix.org> ok, let's start the meeting
<re_irc>
<@adamgreig:matrix.org> few announcements first: cortex-m 0.7.4 was released last week with fixes for inline-asm on nightly and some new features around DWT and cm7 caching
<re_irc>
<@adamgreig:matrix.org> as you may have heard, #rtic:matrix.org released 1.0 on christmas day 🎉
<re_irc>
<@adamgreig:matrix.org> and YuhanLiin has joined the MSP430 team, welcome!
<re_irc>
<@adamgreig:matrix.org> anything else announcement-wise over the last few weeks?
<re_irc>
<@chrysn:matrix.org> RIOT has now native Rust support, might be announcement-worthy
<re_irc>
<@chrysn:matrix.org> (as in "it's upstream")
<re_irc>
<@adamgreig:matrix.org> cool!
<re_irc>
<@adamgreig:matrix.org> got a link or anything?
<re_irc>
<@eldruin:matrix.org> nice! would you add an entry to the newsletter?
<re_irc>
<@therealprof:matrix.org> Definitely worth a note in aer and blog. 😉
<re_irc>
<@chrysn:matrix.org> eldruin:matrix.org: Can do :-)
<re_irc>
<@adamgreig:matrix.org> cool, thanks!
<re_irc>
<@therealprof:matrix.org> chrysn:matrix.org: Copyright seems a bit stale. 😉
<re_irc>
<@adamgreig:matrix.org> onto cortex-m, now that 0.7.4 is out it we can think about a 0.8 alpha release so that it's possible to try out the recent breaking changes in the debugging peripherals, but this always causes such ecosystem heartache (plus semver hack agony) that I'm open to any good ideas about how we might do it differently to 0.7...
<re_irc>
<@adamgreig:matrix.org> it's frustrating that the only meaningful breaking change is to the debugging peripherals, i.e. the 0.8 upgrade as-is won't really offer any benefits to most users
<re_irc>
<@svenstaro:matrix.org> Any news about dear cross?
<re_irc>
<@adamgreig:matrix.org> heh, it's next on the agenda but no news, I thought I was waiting for emilgardis to reply to my comments on https://github.com/rust-embedded/wg/pull/590 but I guess actually he's waiting for me to update the RFC text?
<re_irc>
<@adamgreig:matrix.org> distressingly even "shunt cross to its own org so that new volunteers can help get it out of this quagmire" has gotten stuck too
<re_irc>
<@adamgreig:matrix.org> ok, all quiet on the cortex-m front I guess, the other thing on the agenda is the embedded-hal async trait location: did we finish that last time in the end?
<re_irc>
<@dirbaio:matrix.org> once 342 is merged, I'll send PRs adding each trait
<re_irc>
<@therealprof:matrix.org> eldruin:matrix.org: Looks okay for me.
<re_irc>
<@therealprof:matrix.org> Just curious: **NOTE** This HAL is in active development.
<re_irc>
<@therealprof:matrix.org> Not sure everyone will parse that in the same way.
<re_irc>
<@eldruin:matrix.org> hmm good point
<re_irc>
<@eldruin:matrix.org> maybe something along the lines of experimental, alpha,... any suggestions?
<re_irc>
<@therealprof:matrix.org> Something along the lines of experimental or unstable would be clearer I think.
<re_irc>
<@dirbaio:matrix.org> "Note: Rust async traits are still experimental. At least one breaking change is expected in the future (changing from GATs to `async fn`), but there might be more."
<re_irc>
<@eldruin:matrix.org> sounds good, I'll add the change later
<re_irc>
<@eldruin:matrix.org> and thanks!
<re_irc>
<@adamgreig:matrix.org> cool! anything else from embedded-hal (or anything else at all)?
<re_irc>
<@dirbaio:matrix.org> the "unify errors" thing
<re_irc>
<@adamgreig:matrix.org> aah, whether same type between async and blocking?
<re_irc>
<@therealprof:matrix.org> Still inching towards 1.0? 😅
<re_irc>
<@adamgreig:matrix.org> I wonder if we need another triage/tidyup of the open issues and PRs and see what's left in the v1.0.0 milestone
<re_irc>
<@adamgreig:matrix.org> there's a few big recent PRs like removing the TIme types and splitting up spi, and there's a bunch of older issues/PRs
<re_irc>
<@eldruin:matrix.org> yeah most is added to the 1.0 milestone
<re_irc>
<@eldruin:matrix.org> but we can go over it again
<re_irc>
<@eldruin:matrix.org> if we remove the traits with unconstrained types, then there is another blocking issue for 1.0 which does not need to be done (channel-wise enable/disable for PWM IIRC)
<re_irc>
<@eldruin:matrix.org> other than that I think it should be ready pretty soon
<re_irc>
<@therealprof:matrix.org> Pretty soon == somewhen in 2022/2023. 😬
<re_irc>
<@ryankurte:matrix.org> maybe 2025? :-P (actually i think we're getting close too)
<re_irc>
<@adamgreig:matrix.org> well it can't be earlier than 2022 :P
<re_irc>
<@eldruin:matrix.org> hmm if more inconsistencies do not come up, maybe within 2022/Q1
<re_irc>
<@eldruin:matrix.org> although it depends on how many beta/RC releases we want to make
<re_irc>
<@dirbaio:matrix.org> I think there are more inconsistencies 🙈
<re_irc>
<@ryankurte:matrix.org> a little cautious that the removal of some traits from 1.0.0 has pushed people into implementing / supporting both which, isn't _ideal_
<re_irc>
<@eldruin:matrix.org> yeah that's the drawback
<re_irc>
<@adamgreig:matrix.org> probably better to have people support both and then drop 0.2 support once 1.0 gains the traits they need?
<re_irc>
<@adamgreig:matrix.org> than just postpone 1.0 for even longer, I mean
<re_irc>
<@adamgreig:matrix.org> can't just kick everything down the road and release an empty 1.0 of course...
<re_irc>
<@eldruin:matrix.org> dirbaio:matrix.org: please file issues so that we can start the discussion early
<re_irc>
<@ryankurte:matrix.org> adamgreig: we were aiming to not need that with the compatibility stuff but, yeah agreed
<re_irc>
<@dirbaio:matrix.org> ryankurte:matrix.org: HALs? impling both 0.2 and 1.0 is quite worth it just for usability reasons, I think many HALs will do that
<re_irc>
<@dirbaio:matrix.org> because it'll take a while for drivers to update
<re_irc>
<@dirbaio:matrix.org> my plan for embassy is to support both
<re_irc>
<@dirbaio:matrix.org> so I don't think removing traits is bad
<re_irc>
<@ryankurte:matrix.org> dirbaio:matrix.org: `embedded-hal-compat` covers 90% of the reason for that so most folks shouldn't need to, but, whatever works
<re_irc>
<@ryankurte:matrix.org> anyway not meeting-critical i think ^_^
<re_irc>
<@dirbaio:matrix.org> yeah EHC is great, but having the HAL impl both makes it Just Work without the user having to wrap stuff
<re_irc>
<@dirbaio:matrix.org> yeah, not critical :D
<re_irc>
<@svenstaro:matrix.org> Can you just do the cross move? It's sadly quite obvious by now the no one really cares too much about it so much as well not burn too many potential contribs. Sorry for getting sour but this is probably the work of all of 10 minutes of calling someone and talking and moving them and then adding some contributors.
<re_irc>
<@adamgreig:matrix.org> yes, it can happen ten minutes from a majority of the tools team approving it
<re_irc>
<@adamgreig:matrix.org> I'll see if I can resolve emilgardis's points
<re_irc>
<@adamgreig:matrix.org> there's no technical blocker in terms of github permissions or anything
<re_irc>
<@adamgreig:matrix.org> there is a technical challenge a bit later in terms of CI and container hosting, though
<re_irc>
<@ryankurte:matrix.org> are we uhhh abdicating responsibility with this transfer? like it's a fair thing to do either way but, is there a consideration of the folks using it downstream?
<re_irc>
<@ryankurte:matrix.org> adamgreig: a couple of us started work moving this to actions so, it's at least well underway
<re_irc>
<@svenstaro:matrix.org> I'm a folk using it downstream and I don't like my upstream software unmaintained
<re_irc>
<@adamgreig:matrix.org> yea, I think there's a real argument that the folks using it downstream have already been effectivelyabandoned
<re_irc>
<@adamgreig:matrix.org> as stands the wg would give up responsibility for it entirely to the new org, yes
<re_irc>
<@adamgreig:matrix.org> the transition would be that some of the current maintainers would continue to maintain it in the new org, alongside any volunteers
<re_irc>
<@adamgreig:matrix.org> (rather than having new people join the wg, which is another option)
<re_irc>
<@adamgreig:matrix.org> I'm open to considering any other route but so far nothing has worked or even really been tried, so...
<re_irc>
<@ryankurte:matrix.org> yeah
<re_irc>
<@adamgreig:matrix.org> we can also just archive the whole repo, give up on it entirely and hope someone forks it, idk
<re_irc>
<@ryankurte:matrix.org> is there anything to stop us just adding some cross contributors like the pre-our-maintainership days without doing the EWG membership dance? if not enough maintainers is perceived to be the issue
<re_irc>
<@adamgreig:matrix.org> how do you square that with it still being maintained by the wg?
<re_irc>
<@adamgreig:matrix.org> in essence the hope with moving it to its own repo is exactly so that it's easy to just add some maintainers
<re_irc>
<@therealprof:matrix.org> We already added one maintainer to the WG for that reason but it clearly needs more personel.
<re_irc>
<@adamgreig:matrix.org> I mean, yea, technically we could add some cross-repo-only maintainers easily, who aren't in the wg or part of a wg team, and maybe that would be wise? it's not how we currently manage org members/maintainers/wg members, though
<re_irc>
<@therealprof:matrix.org> We have a few and it's messy.
<re_irc>
<@therealprof:matrix.org> Also no clear rules.
<re_irc>
<@ryankurte:matrix.org> ahh, bors wouldn't like it eh
<re_irc>
<@adamgreig:matrix.org> I think bors could be compelled easily enough, it should be able to sync whoever has write access to repo
<re_irc>
<@therealprof:matrix.org> Not sure. It's using groups at the moment.
<re_irc>
<@therealprof:matrix.org> or, teams rather.
<re_irc>
<@adamgreig:matrix.org> nah, it's just using whoever has push access to the repo atm
<re_irc>
<@ryankurte:matrix.org> i think adding some non-wg maintainers would be a good test of whether moving it out will help / as well as a step towards this? like if we move it out and nothing happens it's still not going to get the maintenance it needs but with it's own organisational overhead
<re_irc>
<@dirbaio:matrix.org> IMO if cross is not a priority for the WG (and it seems it isn't if it isn't getting much maintenance) it should be moved out of the WG
<re_irc>
<@dirbaio:matrix.org> it's not a very "embedded" thing in the first place
<re_irc>
<@ryankurte:matrix.org> ryankurte:matrix.org: contrarily, if a couple of our maintainers go with it it's basically in the same state as now in a new org, so maybe it's moot
<re_irc>
<@adamgreig:matrix.org> dirbaio: yea.. I think it started out useful for embedded bare-metal applications, but isn't any more, but maybe still useful for embedded linux?
<re_irc>
<@adamgreig:matrix.org> but it's not _used_ by many wg members, which is the issue
<re_irc>
<@dirbaio:matrix.org> I do use it to crosscompile a terminal app for raspis, but I wouldn't call that embedded (it doesn't even use the raspis gpio/i2c/uart/etc)
<re_irc>
<@dirbaio:matrix.org> "real" embedded linux like yocto/buildroot already has its own build system solving the same problems as cross
<re_irc>
<@adamgreig:matrix.org> probably it's used by a surprising number of wg members who just aren't me, then, heh
<re_irc>
<@eldruin:matrix.org> I use it to run tests on linux from a mac dev system
<cr1901>
I use it for CI for std Rust apps
<re_irc>
<@ryankurte:matrix.org> yeah i use it all the time in CI to avoid cursed glibc things for linux embedded
<re_irc>
<@ryankurte:matrix.org> anyway, i've hit approve so looks like we're 2 votes (and some changes) from action
<re_irc>
<@adamgreig:matrix.org> I haven't used it at all, so I'd be very happy to go with whatever the people who actually use it want to do
<re_irc>
<@adamgreig:matrix.org> I just can't tell what that is
<cr1901>
I'm not attached to cross being part of the WG
<re_irc>
<@therealprof:matrix.org> I think approvals are not the issue. Just fixing the remainder of nits.
<re_irc>
<@adamgreig:matrix.org> well, ultimately it needs to be approved :P
<re_irc>
<@adamgreig:matrix.org> are they just nits? I wanted to have a discussion in the comments
<re_irc>
<@therealprof:matrix.org> I think only Emil raised some points.
<re_irc>
<@adamgreig:matrix.org> I'll see if I can clear up the verbiage around the points he raised anyway
<re_irc>
<@therealprof:matrix.org> Perfect. I'll make sure to chase the votes once that it cleared.
<re_irc>
<@adamgreig:matrix.org> thanks!
<re_irc>
<@adamgreig:matrix.org> ok, that's all we have time for this week, thanks everyone!
crabbedhaloablut has quit [Remote host closed the connection]
<re_irc>
<@eldruin:matrix.org> give me a minute to adapt the disclaimer
<re_irc>
<@eldruin:matrix.org> so that I can save another PR
<re_irc>
<@chrysn:matrix.org> By the way, for those who followed my earlier link to the Rust on RIOT example: https://doc.riot-os.org/using-rust.html would have been the better link.
<re_irc>
<@chrysn:matrix.org> (That's also the one now in AER and upcoming in the newsletter -- just so those active here don't skip the item because they think they've read it, but didn't get the best suitable link on the topic.)
<re_irc>
<@chrysn:matrix.org> Doing Rust bindings for a C OS also *really* helps find subtle unsafeties there (just found one more today), so I'm glad that my oxidize-conf statement of "wrapping it up is a mutually beneficial thing" (Rust side gets readily-usable OS, C side gets a thorough API check) still holds.
<re_irc>
<@yatekii:matrix.org>...
<re_irc>
<@yatekii:matrix.org> uff
<re_irc>
<@dirbaio:matrix.org> lol
<re_irc>
<@yatekii:matrix.org> wrong channel
<re_irc>
<@yatekii:matrix.org> if yall interested in swiss pasta I can add it again :D
<re_irc>
<@dirbaio:matrix.org> nice pasta
<re_irc>
<@jacobrosenthal:matrix.org> *searches channel list for the swiss pasta channel
<re_irc>
<@yatekii:matrix.org> it's a secret lair, unreachable for the unworthy :P
<re_irc>
<@adamgreig:matrix.org> chrysn chrysn:matrix.org: one more for you... https://arewertosyet.com/
rardiol has quit [Ping timeout: 240 seconds]
fooker has quit [Quit: WeeChat 3.1]
fooker has joined #rust-embedded
<re_irc>
<@tholmie:matrix.org> adamgreig: back on the pain of cortex-m releases being a pain - the main reason that is the case is because it declares `links = "cortex-m"` to prevent multiple versions being linked in and used, right?
<re_irc>
<@tholmie:matrix.org> I can understand the theoretical argument here of how this might be unsound, but it seems highly unlikely that a difference in behavior actually manifests itself in bad behavior.
<re_irc>
<@tholmie:matrix.org> Have we considered removing this limitation?
<re_irc>
<@dirbaio:matrix.org> it's because it has owned singletons
<re_irc>
<@dirbaio:matrix.org> the user could get an NVIC singleton from cortex-m 0.7 and another from cortex-m 0.8 which whould be theoretically unsound
<re_irc>
<@tholmie:matrix.org> Ahhhh. That’s a reasonable enough hypothetical I suppose. Thanks for the explanation
<re_irc>
<@adamgreig:matrix.org> Also it means those types would differ, so a user couldn't take() all the 0.8 peripherals and pass one to a crate needing 0.7's
<re_irc>
<@adamgreig:matrix.org> But yea the main thing is you get two copies of something meant to be a singleton
<re_irc>
<@adamgreig:matrix.org> So no more safe read-modify-write etc
<re_irc>
<@grantm11235:matrix.org> The idea is that a combined spi trait would have a `with_inner` required method
<re_irc>
<@grantm11235:matrix.org> For a basic spi impl, it would just run the closure on it's self
<re_irc>
<@grantm11235:matrix.org> But it allows doing arbitrary operations while cs is active, or while an spi mutex is locked, or while the spi peripheral is powered up
<re_irc>
<@grantm11235:matrix.org> I don't think I am explaining it very well, so feel free to ask questions
<re_irc>
<@grantm11235:matrix.org> I also tried adding default method impls for `read` and `write` that use`with_inner`. That kinda works, but you will get a stack overflow at runtime if you forget to override those methods for your base type
<re_irc>
<@grantm11235:matrix.org> I was hoping that this could solve the default impl/chipselect problem, but it doesn't lol
rardiol has joined #rust-embedded
<re_irc>
<@dkhayes117:matrix.org> Still working through the microbit discovery book for fun. This is the first time I've got to use cargo embed, and it is sweet!
<re_irc>
<@dkhayes117:matrix.org> I really like rtt too