<re_irc>
<@dirbaio:matrix.org> > Racer is not actively developped now. Please consider using newer software such as rust-analyzer
<chrisb>
thanks
rardiol has joined #rust-embedded
tokomak has quit [Read error: Connection reset by peer]
ni has quit [Remote host closed the connection]
<re_irc>
<@adamgreig:matrix.org> 👋 hello room, time for the last meeting of the year! agenda's https://hackmd.io/6EIKmpgqTXGldwKxw1K14w and we'll start in 5min as usual, please add anything you'd like to discuss to the agenda
<re_irc>
<@adamgreig:matrix.org> ok, let's go! no announcements from me, does anyone have any?
<re_irc>
<@thejpster:matrix.org> nope
<re_irc>
<@dkhayes117:matrix.org> Not really a WG announcement, but I will be starting my thesis this spring working with the [Conexio Stratus](https://www.crowdsupply.com/conexio/stratus) with Rust hopefully :) It uses the nrf9160
<re_irc>
<@adamgreig:matrix.org> cool!
<re_irc>
<@adamgreig:matrix.org> ok, onto cortex-m, we accepted the rfc about the itm crate which has now been archived, but there's going to be a bit of a delay publishing the new 0.4 as we need to sort out a new cortex-m release with breaking changes
<re_irc>
<@adamgreig:matrix.org> before we get to that, there's also been a recent fix for the inline asm stuff now that nightly has stabilised the feature and removed the macro from the prelude
<re_irc>
<@adamgreig:matrix.org> so it might be worthwhile publishing a new patch release with those changes, to allow nightly users to keep using inline asm
<re_irc>
<@adamgreig:matrix.org> that should be a relatively easy backport I think
<re_irc>
<@adamgreig:matrix.org> since 342 contains some (minor) breaking changes, iirc
<re_irc>
<@adamgreig:matrix.org> but this is somewhat unfortunate as making any breaking changes is a ginormous pain for everybody
<re_irc>
<@adamgreig:matrix.org> possibly we should have noticed and thought about this before merging 342...
<re_irc>
<@adamgreig:matrix.org> anyway, this maybe needs a little bit of thought; we could release a 0.8.alpha0 or something but maybe a better solution to the breaking everything all the time problem is called for
<re_irc>
<@adamgreig:matrix.org> I'd rather not do another semver-hack release if we can avoid it, as it's a lot of delicate work and also regularly confuses people
<re_irc>
<@thejpster:matrix.org> It's not impossible to unmerge it if it's a problem
<re_irc>
<@adamgreig:matrix.org> this is probably just more weight in favour of your push for a stricter git branch control thejpster :P we possibly could move it to a `next` branch and keep `master` on 0.7 for now, not sure
<re_irc>
<@tholmie:matrix.org> Or even a follow up to make it no longer breaking
<re_irc>
<@adamgreig:matrix.org> the changes are all localised to the debug modules
<re_irc>
<@tholmie:matrix.org> There’s also that 9 bit SCR reg change that is breaking but I suppose we could instead deprecate and make new functions
<re_irc>
<@adamgreig:matrix.org> yea
<re_irc>
<@thejpster:matrix.org> git-flow would have main track the releases and the exciting stuff goes into develop
<re_irc>
<@adamgreig:matrix.org> I guess at least that's two reasons to have a new release instead of just one
<re_irc>
<@thejpster:matrix.org> but you can call them what you like really
<re_irc>
<@adamgreig:matrix.org> perhaps the best option for right now is to think about a 0.8 and a semver-hack 0.7 to maintain compatibility throughout the ecosystem, ugh
<re_irc>
<@adamgreig:matrix.org> thanks for pointing out the scr reg too tholmie, I hadn't been considering that as well
<re_irc>
<@adamgreig:matrix.org> if anyone has any other good ideas please shout, I'll see if there's any other relevant changes and do a backport of the asm stuff at least
<re_irc>
<@therealprof:matrix.org> What needs doing?
<re_irc>
<@adamgreig:matrix.org> I think mainly just the open comments from emilgardis
<re_irc>
<@adamgreig:matrix.org> maybe have a look over those discussions
<re_irc>
<@therealprof:matrix.org> Okay, will do.
<re_irc>
<@adamgreig:matrix.org> on the embedded-hal front there's been a bunch of activity this week, eldruin do you want to talk about anything in particular?
<re_irc>
<@eldruin:matrix.org> yeah, we can talk about that
<re_irc>
<@eldruin:matrix.org> basically, should we have a separate repo for e-h-async or have a directory in the e-h repository?
<re_irc>
<@eldruin:matrix.org> Initially I thought of a separate repo that would be archived at some point, so I created a mostly empty shell
<re_irc>
<@eldruin:matrix.org> and opened the RFC
<re_irc>
<@thejpster:matrix.org> Does adding async things to e-h break anything for normal users? I presume it sets an MSRV but apart from that, it should be benign unless you call the async functions?
<re_irc>
<@eldruin:matrix.org> but I am also fine with keeping e-h as-is and add e-h-a as a subdir
<re_irc>
<@eldruin:matrix.org> and there is the confusion potential :)
<re_irc>
<@adamgreig:matrix.org> for now, it would be a new crate either way, thejpster
<re_irc>
<@eldruin:matrix.org> exactly
<re_irc>
<@adamgreig:matrix.org> just whether that crate lives in a new repo as well, or a directory of the existing repo
<re_irc>
<@newam:matrix.org> either way sounds good to me. There are pros and cons to both, but none of which I think are very significant.
<re_irc>
<@eldruin:matrix.org> the main disadvantage of a separate repo is interdependencies
<re_irc>
<@therealprof:matrix.org> Is there anything we could have in there at the moment? I don't think async stuff in traits are already a thing?
<re_irc>
<@eldruin:matrix.org> there are already traits for spi, i2c and serial
<re_irc>
<@eldruin:matrix.org> jsut with a future type
<re_irc>
<@adamgreig:matrix.org> keeping the existing repo seems fine to me, and just when it's stable we can pr moving the code into the main crate easily
<re_irc>
<@eldruin:matrix.org> a breaking release with async fn would be in the roadmap
<re_irc>
<@adamgreig:matrix.org> would it need to be breaking to add new traits?
<re_irc>
<@therealprof:matrix.org> I see.
<re_irc>
<@eldruin:matrix.org> it would only be a breaking change in e-h-a
<re_irc>
<@eldruin:matrix.org> not e-h
<re_irc>
<@adamgreig:matrix.org> ah yea got you
<re_irc>
<@dirbaio:matrix.org> adding new traits it not breaking
<re_irc>
<@adamgreig:matrix.org> sure, I misunderstood where the breaking change was
<re_irc>
<@adamgreig:matrix.org> hopefully these could be added to like e-h 1.1 or 1.2 or whatever
<re_irc>
<@eldruin:matrix.org> we would only add the traits to e-h proper when no breaking changes are foreseable
<re_irc>
<@eldruin:matrix.org> ok so subdir it is?
<re_irc>
<@firefrommoonlight:matrix.org> It might be worth letting Dirbaio manage the traits unilaterally
<re_irc>
<@firefrommoonlight:matrix.org> If he wants to do that
<re_irc>
<@dirbaio:matrix.org> I don't, I was already doing that in embassy-traits
<re_irc>
<@firefrommoonlight:matrix.org> Oh NVM !
<re_irc>
<@dirbaio:matrix.org> the point of having it in e-h is to have a "standard" set of traits with consensus from everyone
<re_irc>
<@therealprof:matrix.org> dirbaio:matrix.org: The question was probably more whether changing from manual `Future`s to `async` would be breaking.
<re_irc>
<@dirbaio:matrix.org> therealprof:matrix.org: ah yeah that's super likely to be breaking
<re_irc>
<@adamgreig:matrix.org> yea, so it breaks the new temporary embedded-hal-async crate, but we don't merge that into embedded-hal until after swapping to `async`
<re_irc>
<@newam:matrix.org> therealprof:matrix.org: I think that the hows of implementing async traits has not been stabilized yet.
<re_irc>
<@dirbaio:matrix.org> also most of the async traits are direct translations of the blocking traits
<re_irc>
<@dirbaio:matrix.org> just asyncified
<re_irc>
<@dirbaio:matrix.org> so they nicely mirror each other, and users have no surprises when switching between them
<re_irc>
<@dirbaio:matrix.org> so there's not a lot to "manage" to be honest
<re_irc>
<@dirbaio:matrix.org> like, design discussions for blocking traits trivially apply to the async ones usually
<re_irc>
<@adamgreig:matrix.org> any other e-h PRs worth chatting about now?
<re_irc>
<@adamgreig:matrix.org> plenty of new ones but i think mostly the unifying-errors is fairly uncontroversial?
<re_irc>
<@eldruin:matrix.org> hmm how to choose... :D
<re_irc>
<@adamgreig:matrix.org> haha
<re_irc>
<@dirbaio:matrix.org> there's the error unification ones, but they don't seem to be very controversial
<re_irc>
<@dirbaio:matrix.org> also worth noting: they unify errors between `blocking`, `nb` and `async` as well
<re_irc>
<@eldruin:matrix.org> that is an interesting point
<re_irc>
<@dirbaio:matrix.org> I don't see any drawback to that, but bringing it up because maybe someone else does
<re_irc>
<@therealprof:matrix.org> I haven't had time to check myself but if eldruin is happy we should merge them.
<re_irc>
<@eldruin:matrix.org> maybe async would like a different error type?
<cr1901>
dirbaio: You say IoPin bounds are _very cursed_, but doesn't seem that bad to me :P
<re_irc>
<@dirbaio:matrix.org> irc_libera_cr1901:psion.agg.io: they make eyes bleed
<re_irc>
<@dirbaio:matrix.org> eldruin:matrix.org: what'd be the usecase? async write and blocking write are the same "operation"
<re_irc>
<@dirbaio:matrix.org> not sure how async could fail in a "new" way that blocking can't, for a given peripheral
<re_irc>
<@adamgreig:matrix.org> HALs could always provide extra variants in the error enum as required, even if the blocking version never returned them?
<re_irc>
<@eldruin:matrix.org> the thing is that this forces the underlying error type to be the same for blocking or async. It might be that with async you would want to store something else inside for your underlying error cause
<re_irc>
<@dirbaio:matrix.org> I haven't come across any such case in embassy, they already all are the same enum
<re_irc>
<@eldruin:matrix.org> adamgreig: yes, but you force an unified error type where blocking operations have to match with async variants even though they would not be possible
<re_irc>
<@thejpster:matrix.org> like an async_std::io::Error instead of a std::io::Error?
<re_irc>
<@eldruin:matrix.org> something like error cause is future was cancelled
<re_irc>
<@newam:matrix.org> going from the same error -> not the same error wouldn't be a breaking change, would it?
<re_irc>
<@newam:matrix.org> Could start with the stricter bounds and see where it goes.
<re_irc>
<@eldruin:matrix.org> you would want your error enum to represent that, but has no business in the blocking traits
<re_irc>
<@dirbaio:matrix.org> thejpster:matrix.org: async_std Error is a reexport of std Error
<re_irc>
<@eldruin:matrix.org> newam:matrix.org: it would for dependencies
<cr1901>
it's a publicly visible API change, so I assume it would be breaking
<re_irc>
<@dirbaio:matrix.org> newam:matrix.org: yep we can break it in e-h-a, but it also unifies nb+blocking in e-h which we can't break once e-h1.0 is out
<re_irc>
<@dirbaio:matrix.org> also
<re_irc>
<@dirbaio:matrix.org> here's one advantage of unifying: a driver might want to require both blocking+async SPI
<re_irc>
<@dirbaio:matrix.org> for example for some SPI driver, doing tiny 2byte register writes at 32mhz is just a handful of clock cycles, it's not worth to use async there
<re_irc>
<@dirbaio:matrix.org> but transferring big fat chonky ethernet jumbo frames is worth it
<cr1901>
Rust in general has decided that function coloring is unavoidable, yes. Feels weird to me to unify any parts including error types
<re_irc>
<@dirbaio:matrix.org> so it *might* help code size / speed to write drivers in this "hybrid" way
<cr1901>
But that's a FEELING, I don't have any technical reason
<re_irc>
<@dirbaio:matrix.org> (I haven't actually measured this)
<re_irc>
<@dirbaio:matrix.org> so
<re_irc>
<@adamgreig:matrix.org> is that the only advantage of unifying the errors between blocking/nb/async? otherwise in general i wouldn't have thought it would matter, exactly assuming things rarely use both types
<re_irc>
<@adamgreig:matrix.org> but if actually many async drivers end up wanting both async and blocking versions, perhaps it's helpful
<re_irc>
<@adamgreig:matrix.org> (could they not just busy poll the async version?)
<re_irc>
<@dirbaio:matrix.org> if errors are unified, drivers can do `where T: blocking::SPI + async::SPI` and then just use `T::Error` everywhere which is really nice
<re_irc>
<@dirbaio:matrix.org> without unifying you need ugly bounds like today: `<T, BlockingE, AsyncE> where T: blocking::SPI<Error=BlockingE> + async::SPI<Error=AsyncE>`
<re_irc>
<@ryankurte:matrix.org> in practice imo you just end up type aliasing to avoid this anyway?
<re_irc>
<@eldruin:matrix.org> the thing is, we got ourselves a nice error mechanism where it is possible to define underlying causes and whatnot and have it play nicely with generic code. Unifying error types for the very different execution modes seems like a step back
<re_irc>
<@dirbaio:matrix.org> imo it's a step forward in usability
<cr1901>
Are we putting unified error types under an unstable feature?
<re_irc>
<@dirbaio:matrix.org> if we can come up with some counterexample where it's bad, then sure, let's not do it
<re_irc>
<@dirbaio:matrix.org> but I really can't think of it
<re_irc>
<@adamgreig:matrix.org> cr1901: it would just be part of e-h 1.0, but it doesn't rely on anything unstable, why/how would it be feature-gated?
<re_irc>
<@dirbaio:matrix.org> if your uart hardware can throw a FramingError, then all of blocking, nb, async can 🤷
<re_irc>
<@eldruin:matrix.org> dirbaio:matrix.org: but in a rather rare situation: a driver mixing two execution modes. then everyone else is forced to have a big error type fitting everything inside
<re_irc>
<@ryankurte:matrix.org> given we have the associated error traits, i don't think i'd expect the same error _type_ from blocking/nb/async, seems like a HAL implementation detail? say you're wrapping a CAN socket in MIO using the FD you
<re_irc>
<@newam:matrix.org> eldruin:matrix.org: is it? I think mixing execution modes would be standard for many devices that do data RX/TX like radios and Ethernet chips.
<re_irc>
<@ryankurte:matrix.org> would the expectation be that you map the MIO error into the standard CAN error types?
<cr1901>
adamgreig: Well, the why is to "experiment with whether someone actually needs non-unified error types in practice"
<cr1901>
before we go through with preventing this use-case outright
<re_irc>
<@adamgreig:matrix.org> ryankurte: in that case I guess you'd have MIO variants in your error type, and both your async and your blocking versions would return that same type, but blocking would presumably never return an mio variant
<cr1901>
Also, see my blurb on function coloring. I'm surprised that async-std exports std's errors
<re_irc>
<@dirbaio:matrix.org> ryankurte:matrix.org: mio just uses io::error
<re_irc>
<@dirbaio:matrix.org> because again, it's *the same thing*
<re_irc>
<@dirbaio:matrix.org> it's an IO operation
<re_irc>
<@dirbaio:matrix.org> it can fail in exactly the same ways
<re_irc>
<@dirbaio:matrix.org> and a good async runtime won't introduce any extra errors
<re_irc>
<@adamgreig:matrix.org> right, I guess that's the case everywhere, right? the question is if there's any situation where an async impl might fail in a way that a blocking one couldn't
<re_irc>
<@dirbaio:matrix.org> there's no "oops your executor is on holiday" error :D
<re_irc>
<@dirbaio:matrix.org> these are usually panics
<re_irc>
<@adamgreig:matrix.org> but it seems like the async implementation would never know about async issues in the executor anyway
<re_irc>
<@dirbaio:matrix.org> adamgreig: that too yup
<re_irc>
<@adamgreig:matrix.org> for example with `nb` vs `blocking`, is there any error `nb` might return that isn't also relevant to `blocking`?
<cr1901>
Yea, again, I don't have a good technical reason, just discomfort. If this change goes thru, I'll get over myself
<re_irc>
<@adamgreig:matrix.org> the `nb` method doesn't really know anything is different from above (?)
<re_irc>
<@dirbaio:matrix.org> adamgreig: there's nb::WouldBlock, but that's "added" by nb
<re_irc>
<@dirbaio:matrix.org> with its error enum wrapping the original error
<re_irc>
<@eldruin:matrix.org> it is clear that the `ErrorKinds` of both execution methods are the same, but the underlying error types may not be. It is not clear enough to me that there would never be an use case for different error sources, so I would keep them separate between modes
<re_irc>
<@adamgreig:matrix.org> sure, that's part of the `nb` trait signature, but isn't involved in the shared error type
<re_irc>
<@dirbaio:matrix.org> eldruin:matrix.org: can you provide an example?
<re_irc>
<@dirbaio:matrix.org> in non-embedded, all existing async stuff uses std::io::Error, just like blocking
<re_irc>
<@eldruin:matrix.org> I already did, "future was canceled" error
<re_irc>
<@dirbaio:matrix.org> eldruin:matrix.org: you cancel futures by dropping them, you never receive a "future canceled" error from it
<re_irc>
<@eldruin:matrix.org> I know too little about async rust
<re_irc>
<@eldruin:matrix.org> that is why I am saying it is not clear to me that such an use case would never exist. somuch so that I would be fine with forbidding it in e-h
<re_irc>
<@thejpster:matrix.org> Can I just note I did want to talk about TYIER and there's 5 minutes to the hour
<re_irc>
<@adamgreig:matrix.org> yep sorry, was about to get to that 😅
<re_irc>
<@dirbaio:matrix.org> is the unification between nb+blocking OK, at least?
<re_irc>
<@eldruin:matrix.org> we can continue the discussion in the issues
<re_irc>
<@dirbaio:matrix.org> that's the only required thing for merging the PRs to e-h
<re_irc>
<@dirbaio:matrix.org> async using the same errors or not is just changes to e-h-a
<re_irc>
<@adamgreig:matrix.org> yep, thanks for the insights everyone! let's quickly move on to the last agenda item and we can revisit the unification next meeting if it's not resolved in the issues first
<re_irc>
<@eldruin:matrix.org> dirbaio:matrix.org: hmm, would seem weird in the future to have a top-level error type that does not apply to async modules
<re_irc>
<@thejpster:matrix.org> also I should note the git stats are from a tool I wrote. So easy to re-calculate if you're busy with the PR button between now and posting.
<re_irc>
<@thejpster:matrix.org> and the tool can be used next-year too
<re_irc>
<@adamgreig:matrix.org> cool, well if anyone thinks of anything else please mention it! thejpster, I've gotta run now, but will try and add some of these ideas to the post later this evening or over the day tomorrow if you don't get to them first
<re_irc>
<@thejpster:matrix.org> Yes I spent two hours automating a tedious 10 minute task, and why yes, I used to be a perl programmer
<re_irc>
<@adamgreig:matrix.org> then maybe laster tomorrow or thursday we can put the PR together?
<re_irc>
<@thejpster:matrix.org> sounds good
<re_irc>
<@adamgreig:matrix.org> great!
<re_irc>
<@adamgreig:matrix.org> ok, thanks everyone, that's all for this week and this year!
<re_irc>
<@adamgreig:matrix.org> I mean obviously we're all here all the time anyway 🙈 but see you in 2022! 🎉
<re_irc>
<@jamesmunns:beeper.com> the idea was to walk crate deps (and reverse deps) starting from some "seed" crates, like `embedded-hal` and `cortex-m`, and try and discover related crates.
<re_irc>
<@jamesmunns:beeper.com> I uh, have no idea if it still works, but the nice thing is that it uses a snapshot of the crates io index, so no scraping required, and I suppose you could run it at different historical points. It generates a markdown doc, because I don't know HTML
<re_irc>
<@adamgreig:matrix.org> irc_libera_cr1901:psion.agg.io: Oh no, I put it on the agenda but I guess we didn't actually talk about it, no meeting for next two weeks
<re_irc>
<@jamesmunns:beeper.com> Also offhand question for adamgreig (and the rest of resources), I've been keeping a weekly email newsletter (and publishing it to my blog one week later, ex: https://jamesmunns.com/blog/) that's hardware + firmware related. All the firmware is in Rust, but some weeks are more electrical/mechanical. If I wanted to include it in the newsletter:
<re_irc>
<@jamesmunns:beeper.com> * How should I handle N issues/blog post?
<re_irc>
<@jamesmunns:beeper.com> * Should I only include ones that are more firmware focused?
<re_irc>
<@adamgreig:matrix.org> I guess just add each blog post you'd like to highlight on the newsletter to the bullet list of blog posts etc on the template? Not a problem if there's a few posts per newsletter imo
<re_irc>
<@adamgreig:matrix.org> Maybe worth a sentence or two summary of the relevant part of each post