<re_irc>
<9names (@9names:matrix.org)> Why are you suggesting they should avoid a dependency?
fabic has joined #rust-embedded
<re_irc>
<firefrommoonlight> You don't need a crate for circular buffers, and adding unnecessary dependencies is a major contributor to why modern software is fragile and complex
<re_irc>
<9names (@9names:matrix.org)> Ivan Levitskiy: Check out BBQueue, it's pretty neat
<re_irc>
<James Munns> firefrommoonlight: This is fairly counter to the rust ethos, btw. Like, you're entitled to your opinions, but you might want to avoid stating it as a decided fact.
<re_irc>
<James Munns> Especially if you are talking about a thread safe circular buffer, like Ivan had been asking about.
<re_irc>
<James Munns> There's a ton of great work out there in crates (heapless and embassy were mentioned). I'd be fooling myself if I thought rewriting it all from scratch was the best use of my time :)
<Shell>
correct thread safe circular buffers are a small nightmare. :)
<re_irc>
<Udayakumar Hidakal> chemicstry: Thank you so much for this suggestions , after using delay before the erase function/write function it is working and also it is connecting to "stm32 cube programmer".
<re_irc>
🙂
<re_irc>
<James Munns> Next day: Postcard is still at docs rs position 115/116 😭
gsalazar_ has joined #rust-embedded
<Lumpio->
firefrommoonlight: I need a crate for a circular buffer, because if I write my own I'll also have to write a full test suite to find that pesky off-by-one error that will undoubtedly sneak in there. Plus writing solved things again and again is boring.
<re_irc>
<James Munns> bbqueue is great, but generally only spsc!
<Lumpio->
That was just a reply about they seeming to think it's better to write a new one for every project
<re_irc>
<jamwaffles> Oh apologies, I didn't know the context. Bbqueue is indeed great anyway though 😉
<Lumpio->
I know I've read the code heh
<re_irc>
<jamwaffles> Is there such a pattern as a "low priority spin loop"? I have a blocking function that waits for a variable to be updated by another task and it needs to respond asap, but ideally not chew up any CPU. I want this to be portable, so I can't use interrupts
<re_irc>
<Simon Sapin> jamwaffles: what does "task" mean in your context? Do you have an async executor? Could you manually poll for the other thing from inside your spin loop?
<re_irc>
<Simon Sapin> Unrelated question: on a target without atomic instructions is there a safe way to have runtime-initialized "static" items? I don’t mind if access is fallible (returns "None" if not initialized) or if init is not protected against running more than once. I can _maybe_ manage with only pointer-sized values.
<re_irc>
<jamwaffles> "another task" would be an Ethernet DMA interrupt which feeds a buffer
<re_irc>
<jamwaffles> The spinloop is waiting for a packet with particular data in it
<re_irc>
<jamwaffles> Some shitty pseudocode might look like this:
<re_irc>
// Initialise the thing
<re_irc>
// Hook up `ethernet_interrupt` to ETH DMA
<re_irc>
<chemicstry> jamwaffles: well if you want multiple concurrent tasks there is no way around interrupts, unless you use async to simulate busy loop by polling all futures. I'm not sure what you mean by "portable, so no interrupts" - nothing is really portable, you just use crates that abstract over the hardware, be it rust's std lib or rtic/embassy/etc on embedded
<re_irc>
<jamwaffles> Yeah, I think Embassy is probably the way to go here. I'd still like to support "raw" embedded rust but I think the only way I can do that for now at least is a spinloop. Thanks for the reply 🙂
fabic has joined #rust-embedded
<re_irc>
<James Munns> unportably, theres also wfe/sev on cortex m
<re_irc>
<James Munns> but you're pretty perfectly describing "wakers" in async/await :D
<re_irc>
<jamwaffles> I am lol. I had a small prototype working with async functions but I’m trying really hard to support e.g. RTIC. I think I’m going to just have to remove that requirement for the time being. Unless there’s a way to fake a future without using the async keyword
<re_irc>
<mabez> jamwaffles: IIRC RTIC is getting support for async functions at some point
<re_irc>
<jamwaffles> That looks like literal magic 🤯 it's amazing
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
<re_irc>
<telecominfo123 (@telecom.info123:matrix.org)> hi Team,
<re_irc>
<telecominfo123 (@telecom.info123:matrix.org)> For practing Real-Time Interrupt-driven Concurrency, on real board for reading some sensors and having many interrupt handles.
<re_irc>
Please give me instruction about reference (or template project) that I can start with.
<re_irc>
Thank you in advance.
<re_irc>
<firefrommoonlight> James Munns: Good point. I think of the Rust ethos as one point to consider. Tribes, identities, mindsets etc. Python programmers look to the Zen of Python, or the concept of Pythonic. It can be nice to consider different philosophies, and take the strengths while leaving the weaknesses
<re_irc>
<firefrommoonlight> On one hand, being able to use crates.io libraries is a big time saver. Why reinvent the wheel? 2 things to consider: #1: Where is the line between this, and the unpleasant consequences of the NPM ecosystem. #2: What is the long term complexity/maintenance cost of adding a dependency? (#2 depends heavily on what the dep does, and how deep its own dep tree is)
<re_irc>
<firefrommoonlight> I think there are things Rust does exceedingly well, and some parts I'd rather ignore, or minimize
<re_irc>
<firefrommoonlight> You could say this about most tools and concepts.
<re_irc>
<firefrommoonlight> What is the expected maintenance or usability half-life of a given library? What about historically? What if you need to change something minor - PR? Fork? Copy+paste code locally? Work around?
<re_irc>
<firefrommoonlight> What's the churn rate of similar libs?
<re_irc>
<James Munns> > Where is the line between this, and the unpleasant consequences of the NPM ecosystem.
<re_irc>
Not sure what you mean. Rust has a concept of lockfiles (added much later to NPM), and packages generally CAN'T be fully removed (wrt the "left pad" incedent). If you worried about it, you can pin exact versions you have reviewed, or even vendor dependencies directly to your machine, or a local/company crates io server
<re_irc>
> What is the long term complexity/maintenance cost of adding a dependency?
<re_irc>
Again, not seeing how "start from scratch" is necessarily better than using/improving/forking an existing dependency. I'm not saying "never roll your own", but "adding deps is bad" is just as single minded of an approach.
<re_irc>
<James Munns> Don't get me wrong - dependencies, especially deeply nested and complex ones, certainly have a cost
<re_irc>
<James Munns> but there's no one right answer here, and we don't need to avoid well reviewed, targeted, and widely used libraries - like heapless' circular buffers, just because some large deps exist
<re_irc>
<James Munns> shades of grey.
<re_irc>
<firefrommoonlight> James Munns: Exactly! I think we agree
<re_irc>
<James Munns> Anyway, you hit a nerve. As a consultant, I have reviewed literally DOZENS of circular buffers across many companies.
<re_irc>
<James Munns> nearly EVERY one had some kind of bug.
<re_irc>
<James Munns> ESPECIALLY the "thread safe" ones.
<re_irc>
<James Munns> (everyone writes their own, it's bizzare)
<re_irc>
<James Munns> firefrommoonlight: I don't think I would have spoke so much if I got that impression from your initial messages.
<re_irc>
<James Munns> And details matter, especially when you make sweeping advice.
<re_irc>
<firefrommoonlight> I wonder if here I haven't experienced the sort that you've been using. The circular buffs I've been using have been arrays. Use cases are audio input and output, and continuously monitoring communication from an offboard module
<re_irc>
<firefrommoonlight> So I've misunderstood complexity of them in other uses
gsalazar_ has quit [Ping timeout: 246 seconds]
<cr1901>
>(everyone writes their own, it's bizzare) <-- I'm not sure heapless existed when I wrote mine for AT2XT. There is already a bug in it, but I'm willing to accept the code savings in exchange for something up the stack panicking b/c it's rare in practice
<cr1901>
James Munns: FWIW, I have thought about spinning out my super minimal circular buffer into a crate (but don't feel like trying to figure out whether existing ones accommodate my use case before I do the work lmao)
<re_irc>
<James Munns> Again, I'm not saying "don't write your own"! MnemOS is an exercise in re-inventing the world for no good reason other than I feel like it!
<re_irc>
<James Munns> and "dealing with constraints sharper than the general case", like your code size/mem restrictions, or some folks recently on the RTIC room that needed like < 20 CPU cycles of jitter, are totally valid reasons to roll (or customize) your own!
<re_irc>
<James Munns> I'm just saying the rust ethos is to generally re-use well understood, common functionality, so you don't _have_ to rewrite everything from scratch :D
<cr1901>
The bit_reverse crate, which predates the existence in the stdlib, still has better code size than the stdlib version
<re_irc>
<James Munns> and if that's a make or break feature, you should use it!
<cr1901>
(I think my bigger q is "how the hell aren't they equivalent codegen"? But yes, I will use it until stdlib gets better codegen)
<cr1901>
Also, even tho embassy exists, I'll prob roll my own basic async runtime for msp430, using the async book as a guide, just so I can understand how to do it
<re_irc>
<James Munns> I'll admit to trying that, and sort of giving up and deciding to work on Eliza's executor instead of writing my own from scratch, because it kicked my butt lol
<re_irc>
<James Munns> (the one I wanted for MnemOS is sort of weird, sort of in the middle of Embassy and something like tokio/async-std)
<re_irc>
<James Munns> e.g. I wanted allocations (sort of), and dynamic tasks
<re_irc>
<James Munns> but without all of the everything you'd have.
<re_irc>
<James Munns> for like "actually an embedded system, and not a funky mini-desktop OS", embassy (or something like it or styled like it) is certainly the way to go.
<cr1901>
dynamic tasks?
<re_irc>
<James Munns> yeah, you can spawn tasks at runtime
<re_irc>
<James Munns> I do have an allocator, just not "liballoc"
<re_irc>
<James Munns> (specifically you can spawn an arbitrary number of arbitrary tasks at runtime, whereas in embassy, you can start and stop them (IIRC?), but you can only have a fixed compile time known number of them)
<cr1901>
that's what I thought you meant, but I didn't know that required special handling, even without liballoc (fixed array of tasks)
<re_irc>
<James Munns> If you know how many of each task you can have at runtime, you can pre-allocate the space like embassy does.
<re_irc>
<James Munns> (if I'm wrong dirbaio will correct me, he knows way more about this than I do, and will for a long time lol)
<cr1901>
Well, if you run out of space in the array, then panic or Err(()) from your executor :P
<re_irc>
<James Munns> so, that's the weird part
<re_irc>
<James Munns> my allocator is async
<re_irc>
<James Munns> so when you allocate something and you don't have space, you yield, and hopefully later space will become available.
<re_irc>
<James Munns> (the plan is to have deadlock detection for this, but none of it _really_ exists yet)
<re_irc>
<dirbaio> it's a fixed number of each task (not a fixed number of mask total tasks), because each task is a different future "type"
causal has quit [Quit: WeeChat 3.5]
<re_irc>
<dirbaio> (you usually have just 1 of each, but having multiple copies of one task is handy for example for handling multiple TCP connections in an HTTP server)
<re_irc>
<Noah> Hey folks, when updating to newer than 1.59 and link to C, it will results in "undefined reference to "rust_eh_personality'`. Does anyone know what changed?
<re_irc>
<dirbaio> missing target, or missing panic=abort
<re_irc>
<dirbaio> +maybe?
<re_irc>
<Noah> yeah but why did it change behavior?
<re_irc>
<James Munns> not anything that I'm aware of that would change it, what was your old rust version?
<re_irc>
<Noah> So with 1.59 it still works. with 1.61 it fails.
<re_irc>
<Noah> We have panic=abort active
<re_irc>
<dirbaio> could be a bug
<re_irc>
<dirbaio> "rust_eh_personality" is about unwinding, it shouldn't be used if you have panic=abort
<re_irc>
<James Munns> 2021 edition was 1.56, so it's not that either
<re_irc>
<dirbaio> perhaps check what's referring to it
<re_irc>
<James Munns> (that shouldn't matter tho if you had 2018 set before)
<re_irc>
<dirbaio> * it, that could give some clues
<re_irc>
<James Munns> (2021 did enable resolver 2, but again, not the right version)
<re_irc>
<bugadani> Noah: are you using the upstream rustc or some derivative (like Espressif's)?
<re_irc>
<adamgreig> hi room, meeting time again! agenda is https://hackmd.io/mBG48g1fSoqzQ_ilERdTQg, please add anything you'd like to announce or discuss and we'll start in about 5min
<re_irc>
<James Munns> (last time, I promise!) Postcard 1.0 released yesterday! Release notes here covering all the 1.0 changes: https://jamesmunns.com/blog/postcard-1-0/
<re_irc>
<James Munns> That's all the announcements I have for this week :D
<re_irc>
<adamgreig> great work!
<re_irc>
<adamgreig> the only announcement from me is a minor 0.3.6 release of cargo-binutils
<re_irc>
<James Munns> I was going to mention 254, but you already linked to it!
<re_irc>
<therealprof> I did? I think that was burrbull .
<re_irc>
<newam> therealprof: Is there a reason to do that by MCU instead of by peripheral?
<re_irc>
e.g. crate per common peripheral, with features as needed per MCU?
<re_irc>
<therealprof> It's a rejig of an old idea but with the new spin that by default it doesn't change anything.
<re_irc>
<dirbaio> for "single PAC supporting multiple chips" imo the cargo feature names should be chip names, not peripheral names or "groups". ie the PAC should know which chip has what, the user shouldn't have to specify it
<re_irc>
<adamgreig> it's nice that it's opt-in, and it's not a totally weird way to use group-name
<re_irc>
<adamgreig> yea, ultimately it should be like that
<re_irc>
<adamgreig> but svd2rust could generate features per peripheral group that the maintainer could select in cargo.toml for per-chip features
<re_irc>
<therealprof> newam: The proponent has multiple chips with identical peripherals but only wants to write one svd file for them. As far as my understanding goes those chips are even different architectures.
<re_irc>
<adamgreig> for example, the stm32f405 and f415 share a svd file, the different is the presence of the crypto peripheral, atm it generates one crate that both devices share, but you could imagine feature-gating the crypto stuff and only enabling that for the 415 feature
<re_irc>
<dirbaio> and it would only for for "chip has $thing or hasn't", not "chip has $thing v1 or v2"
<re_irc>
<adamgreig> in extremis I guess you could imagine one ginormous SVD that has every type of IP block and you feature-select the ones you want
<re_irc>
<adamgreig> dirbaio: well, you could have group-name=thingv1 and thingv2 co-exist in one svd
<re_irc>
<dirbaio> (unless you rename THING to THING_V1 and THING_V2, but then the _Vx will be visible in the public API which is ugly)
<re_irc>
<adamgreig> only in the feature names, not the type names?
<re_irc>
<adamgreig> since it's the group-name attribute which (iirc) isn't currently emitted into the API?
<re_irc>
<dirbaio> how'd the SVD look like? two peripherals with the same name? that's not allowed
<re_irc>
<newam> therealprof: Does arch play a role in that?
<re_irc>
At the RTL level peripherals are usually defined by the bus they interface with; accesses would be the same on the bus level (+/- MMU/MPU, but that's outside the scope anyway)
<re_irc>
<adamgreig> hmm yea, even with different group names you're right, couldn't have same name attribute
<re_irc>
<adamgreig> so it would be strictly presence/absence rather than selecting between versions
fabic has quit [Ping timeout: 256 seconds]
<re_irc>
<therealprof> newam: Semi. SVD is officially an ARM only specification. One could argue that using SVD for other architectures is some form of abuse.
<re_irc>
<newam> SVD was for Cortex-M only originally and now ARM themselves abuses it for R and A series :D
<re_irc>
<adamgreig> the only difference is what architecture it says it is in the cpu block, right? not like it matters for peripheral description
<re_irc>
<therealprof> Well, the point is: officially it's only supported for ARM and I can totally understand people not wanting to undergo the effort to write a SVD file for a non-supported architecture. If you have two similar chips, one ARM and another non-ARM you can focus on the ARM parts and get everything tested and then take the thing over to the other architecture and reuse most of it.
<re_irc>
<therealprof> I don't think it makes a huge difference though effort-wise but that's my understanding of the usecase.
<re_irc>
<adamgreig> sure, it seems a distraction to the point of #614 is all
<re_irc>
<therealprof> Fair, just saying the point is deduplication.
<re_irc>
<newam> Yeah, I think it's a good idea, I was just curious about the implementation :)
<re_irc>
<therealprof> I could imagine Campbell He would be happy to discuss details, they are in bad timezone for this meeting though.
<re_irc>
<adamgreig> yea, I think ultimately one day we should handle multiple chips differently (maybe like chiptool) but for today it's quite a neat feature to add that doesn't affect existing uses but does make it quite neat to support common chip variants
<re_irc>
<adamgreig> hopefully it doesn't result in a million features though, I wonder how widely used group-name is already?
<re_irc>
<adamgreig> at least in stm32 it's quite prevalent
<re_irc>
<dirbaio> (chiptool doesn't have anything for multi-chip currently, what it has is a feature to generate rust code for a _single_ peripheral, so pac authors can roll their own with duct tape and tears)
<re_irc>
<adamgreig> ah, I stand corrected
<re_irc>
<adamgreig> well that + something to replace the duct tape with more xml or whatever violence de jour
<re_irc>
<therealprof> Can't go wrong with moar XML. 😄
<re_irc>
<dirbaio> (and the multi-chip stuff in stm32-data/stm32-metapac is all stm32-specific, but I imagine it'd be possible to somehow generalize it)
<re_irc>
<adamgreig> from a quick look it seems like you'd only generate a sensible number of features per stm32 svd, so it would seem to be quite workable
<re_irc>
<adamgreig> how widely used by PAC authors it would be, idk
<re_irc>
<adamgreig> it would be nicer than people having to duplicate the svd and delete chunks and then make two crates or glue two pacs into one crate, though
<re_irc>
<dirbaio> yeah
<re_irc>
<dirbaio> somthing like "file per peripheral, file per chip with references to peripherals"
<re_irc>
<dirbaio> but that requires using a custom format, it can't work from a single SVD
<re_irc>
<dirbaio> but SVD is not designed to hold multiple chips
<re_irc>
<newam> dirbaio: or even multiple CPUs on the same chip :/
<re_irc>
<adamgreig> if that's all there is for #614, I guess basically sounds cool, wouldn't mind seeing a PR
<re_irc>
<adamgreig> the other thing I wanted to briefly discuss was how we're looking for embedded-hal 1.0, we haven't really discussed it in a while
<re_irc>
<adamgreig> dirbaio, did you still want to do an i2c in the style of the new spi?
<re_irc>
<dirbaio> hot take: could we _not_ have "nb" traits in 1.0?
<re_irc>
<adamgreig> of which basically i2c is the only big ticket left?
<re_irc>
<adamgreig> 😱
<re_irc>
<dirbaio> 😂
<re_irc>
<adamgreig> make 1.0 by removing as much as possible from 0.2 until we discover what was really load-bearing
<re_irc>
<adamgreig> why remove nb, anyway?
<re_irc>
<adamgreig> I was going to say it's not like it's required to be implemented over the blocking one, but I guess it's common to implement nb and do blocking by wrapping nb?
<re_irc>
<adamgreig> for people writing non-async projects nb does feel like it would be useful, though admittedly in my own projects I usually do something that's sort of spiritually like it without actually using nb
<re_irc>
<adamgreig> you could argue that all such uses should use async, but given the async traits still aren't stable..?
<re_irc>
<therealprof> Dunno. nb is typically not that efficient and a bit of a mind bender....
<re_irc>
<newam> I don't know how nb is supposed to be used in practice and at this point I'm too afraid to ask
<re_irc>
<dirbaio> re nb: IMO long term (for example when async traits are stable) nb should to be deprecated in favor of async
<re_irc>
<James Munns> exclusively with "block!()", duh!
<re_irc>
<James Munns> (it's cool, I don't know either)
<re_irc>
<adamgreig> so I guess the question is, is anyone actually using nb from e-h 0.2 today...
<re_irc>
<dirbaio> (I'm not sure if people agree with this or not)
<re_irc>
<adamgreig> yea I've never used nb 😆
<re_irc>
<dirbaio> but if people do agree, then the question is: do we want to have "nb" stuff in EH1.0, which is supposed to be "forever"?
<re_irc>
<dirbaio> like
<re_irc>
<dirbaio> there's not even an "nb" i2c trait
<re_irc>
<adamgreig> dirbaio: I'm not really sure here, if we had just async traits for non-blocking, and my HAL had async impls, but I wasn't using an executor, can I still just call the function to get a future then check the future whenever I want to see if it's ready? compared to nb the difference is needing to hold on to the future for state, instead of the HAL implicitly having state internally?
<re_irc>
<James Munns> remove, it, add it back if anyone gets mad :D
<re_irc>
<adamgreig> in other words: if we have async traits as the only non-blocking traits, can someone still use non-blocking without really "using async" per se?
<re_irc>
<jessebraham> Just my $0.02 as a HAL developer but I've always found "nb" to be annoying
<re_irc>
<adamgreig> I'm sorry for this constant insistence on how things would work without async, I promise to one day use async on a project and I'm sure I will be immediately converted :P
<re_irc>
<therealprof> dirbaio: Sorry, I didn't notice any major concerns so I went with the final words from adamgreig. Feel free to add your concerns to the issue. Also I noticed that there's been some work on a svd2rust fork so a PR might not actually be that far away.
<re_irc>
<dirbaio> adamgreig: you can yup
<re_irc>
<dirbaio> it's slightly less ergonomic because you have to supply a dummy waker to the fut, but you can
<re_irc>
<adamgreig> ah yea, I've run into that occasionally, it's surprisingly annoying to make a dummy waker too
<re_irc>
<dirbaio> but there are util crates out there for that, and we could have an embedded-specific one too
<re_irc>
<adamgreig> so... less ergonomic than nb, but still doesn't totally force people to use async themselves
<re_irc>
<dirbaio> but honestly, all the problems that apply to "nb" apply to "hand-polled Futures" as well
<re_irc>
<therealprof> adamgreig: I think there're a few users, also there're many examples using it. Since the API is changing anyway I'm not sure it's too much of a hassle.
<re_irc>
<adamgreig> I just wonder if those users would miss it
<re_irc>
<adamgreig> or be relieved it's gone
<re_irc>
<newam> Could always add it back if we remove it. Harder to go the other way
<re_irc>
<dirbaio> (like, error-prone state machine spaghetti)
<re_irc>
<dirbaio> so I have no idea why would you do that
<re_irc>
<adamgreig> that's the 1.0 spirit for sure
<re_irc>
<dirbaio> vs using "async fn"s or "async{}" blocks
<re_irc>
<dirbaio> +to compose everything into a big future
<re_irc>
<dirbaio> and then hand-polling just that one at the "top level"
<re_irc>
<dirbaio> and that "top level hand-polling" is effectively an executor already :D
<re_irc>
<James Munns> ("cassette" or just "future_util::block_on" would probably be enough for 99% of folks)
<re_irc>
<adamgreig> not hearing many words of support for nb, anyway
<re_irc>
<therealprof> The annoying thing about "nb" is that it's easy to miss that it might not actually do anything unless properly blocked upon.
<re_irc>
<James Munns> cassette makes it a little easier to "poll until completion", instead of "block_on"'s "block until completion"
<re_irc>
<therealprof> Trap for young players...
<re_irc>
<dirbaio> yeah I'm surprised no one yelled at me for proposing dropping it 😂
<re_irc>
<therealprof> With async you automatically get a nice warning telling you that nothing will happen if you don't await it.
<re_irc>
<therealprof> And blocking is... well, it blocks.
<re_irc>
<adamgreig> question is do you change the module structure or keep embedded-hal::serial::blocking :P
<re_irc>
<adamgreig> I guess we'll want embedded_hal::serial::async vs ::blocking eventually
<re_irc>
<adamgreig> it'l just look funny for 1.0 to come out with serial::blocking and no other types
<re_irc>
<dirbaio> probably keep if the plan is to eventually fold EHA
<re_irc>
<newam> adamgreig: async can't be used in module names because keyword, but yeah.
<re_irc>
<dirbaio> but we could also keep EH and EHA as separate crates forever
<re_irc>
<adamgreig> sure, asynch or whatever
<re_irc>
<dirbaio> now that i've gotten used to it, I don't think it's that bad
<re_irc>
<adamgreig> dirbaio: hmm, though eha woudl probably re-export a bunch of common things from eh in that case?
<re_irc>
<dirbaio> EHA already reexports some stuff from EH (the error traits for example)
<re_irc>
<adamgreig> once async traits are stable i don't see why they'd need to be separate, but yea, could also keep them separate if we wanted
<re_irc>
<dirbaio> you're right that's a bit weird
<re_irc>
<adamgreig> I guess if you did keep them separate then you wouldn't need the blocking modules
<re_irc>
<dirbaio> yeah
<re_irc>
<dirbaio> and making the import paths cleaner is nice imo
<re_irc>
<GrantM11235> What about splitting the common stuff out into a different crate and reexporting it in eh and eha
<re_irc>
<dirbaio> from the user's PoV it's the same
<re_irc>
<adamgreig> eh, it's not like using e-h from e-h-a causes any problems or has compile-time implications
<re_irc>
<adamgreig> yea
<re_irc>
<adamgreig> maybe make a PR for deleting nb and a separate issue for the idea of keeping eha separate from eh and thus removing the blocking modules? the latter seems a bit more controversial and can't easily be undone in the futurewwwwwwwwwwwwwwwww
<re_irc>
<adamgreig> * future
<re_irc>
<mabez> I have a quick thing to mention before we end, just FYI https://github.com/rust-lang/rust/pull/98333 has been opened to try an re-enable atomic load/stores on non A RISCV chips. I've made some comments about the options I think we have, but I definitely don't proclaim to be an expert in atomic implementations, so more eyeballs on it the better 👀
<re_irc>
<adamgreig> nice, thanks!
<re_irc>
<adamgreig> that's all we have time for today, thanks everyone!
<re_irc>
<adamgreig> dirbaio: shall I drop a quick note on the e-h 1.0 tracking issue about maybe nuking nb and perhaps keeping gha separate or do you wanna make some issues about it?
<re_irc>
<dirbaio> go ahead :)
<re_irc>
<Noah> all on mainline :)
* cr1901
took a power nap at 1:30, intending to wake up at 2. It is now 4:23.
<cr1901>
wheee...
<re_irc>
<Noah> classic rookie mistake :P
<re_irc>
<dirbaio> sleeping sucks
<cr1901>
If only we didn't need sleep. Then we'd have like 33% more time to do everything :o
<re_irc>
<dirbaio> wouldn't happen if the human firmware was written in Rust!
<re_irc>
<dirbaio> no need for garbage-collection pauses