dygear[m] has quit [Quit: Idle timeout reached: 172800s]
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
milan[m] has quit [Quit: Idle timeout reached: 172800s]
ivmarkov[m] has joined #rust-embedded
<ivmarkov[m]>
<JamesMunns[m]> "This is very good but not what I..." <- I can't keep but wondering whether the "cleanup/refactor-post-commit" strategy does work for keeping around contributors though. As in - it can be misinterpreted as "oh well, I'm tired explaining and providing feedback, it is just easier for me to just re-code it my way" which is not exactly motivating either.
morfertaw[m] has quit [Quit: Idle timeout reached: 172800s]
sirhcel[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
<ivmarkov[m]> "I can't keep but wondering..." <- Yep, I'm sure it's more subtle than a single blog post. That being said, there are likely a lot of projects that end up not merging drive by commits that could be useful, but the submitter never came back to address review comments
<ivmarkov[m]>
JamesMunns[m]: ...which shifts the whole load back to the maintainer, which is not the desired state either...
<ivmarkov[m]>
ivmarkov[m]: I think in the end, this could only work if indeed some of the maintainers are paid and have like 8 hours per day to review/merge stuff.
<JamesMunns[m]>
<ivmarkov[m]> "I think in the end, this could..." <- 100% agree there is no "one size fits all" approach. I think Aleksey's approach worked really well for RA (where he was largely a paid maintainer for many years!), where there were a lot of PRs that fit that profile.
IlPalazzo-ojiisa has joined #rust-embedded
M-[m] has joined #rust-embedded
<M-[m]>
Hi
derek_ has joined #rust-embedded
derek_ has quit [Quit: derek_]
dcn has joined #rust-embedded
Foxyloxy has joined #rust-embedded
Foxyloxy_ has quit [Ping timeout: 264 seconds]
ragarnoy[m] has joined #rust-embedded
<ragarnoy[m]>
Hey, I'm making a parser that expects a reader that is Read+BufRead (from embedded-io-async), and I want it to be able to be used on std, what's the recommended ways to handle it ? And also how is the recommended way to be compatible with async and non async implementations ?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/XfkjCzlESDHaerAJWNdYNKnX>)
<ragarnoy[m]>
* Hey, I'm making a parser that expects a reader that is Read+BufRead (from embedded-io-async), and I want it to be able to be used on std, what's the recommended ways to handle it ? And also how is the recommended way to be compatible with async and non async implementations ?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/BrpIcuEikBYhcNoboBsIWSfL>)
<dirbaio[m]>
> want it to be able to be used on std, what's the recommended ways to handle it?
<dirbaio[m]>
use `embedded-io-async`, require the user to use an adapter from `embedded-io-adapters` to convert from `std::io` to `embedded-io`. (Or offer it yourself, but it might be annoying because you then have to wrap everything)
<dirbaio[m]>
* > want it to be able to be used on std, what's the recommended ways to handle it?
<dirbaio[m]>
use `embedded-io-async`, require the user to use an adapter from `embedded-io-adapters` to convert from `std::io` to `embedded-io`. (Or offer a wrapper yourself that does it, but it might be annoying because you then have to wrap everything)
<dirbaio[m]>
> how is the recommended way to be compatible with async and non async implementations ?
<dirbaio[m]>
unfortunately no good way to do this today. Essentially you have to maintain the two versions of the code. Maybe you can isolate the "core" parsing to some IO-less functions and then have both async and blocking wrappers that actually do the IO, but that's not always posssible.
<dirbaio[m]>
(There's some crates that attempt to solve this, for example `maybe_async`. I wouldn't recommend using them, they're horrible to use, but feel free to take a look...)
<dirbaio[m]>
btw: I'd suggest taking an `R` instead of a `&'a mut R`. There's blanket impls for `&mut`, so if you take an `R` you still allow the user to choose passing a borrowed reader. While if you take a borrowed reader then the user has no option to use owned.
<dirbaio[m]>
so you can write your driver with embedded-io, it'll Just Work for std::io with the adapter. you don't have to "worry" about compatibility.
<dirbaio[m]>
ragarnoy[m]: yes 🥲
<ragarnoy[m]>
oh so it's user side I wouldn't have to use the adapter in the library I guess?
<dirbaio[m]>
yeah, the user has to
<ragarnoy[m]>
<dirbaio[m]> "yes 🥲" <- could be worse i guess
<ragarnoy[m]>
<dirbaio[m]> "btw: I'd suggest taking an `R..." <- After re-reading this I'm kind of confused about it, if i'm using say `BufferedUartRx`, I don't see how this would not consume the variable ?
<dirbaio[m]>
if `T` implements `Read`, then `&mut T` also implements `Read` automatically.
<dirbaio[m]>
so
<dirbaio[m]>
if you take an `R: Read`, the user can do BOTH `SbusParser::new(reader)` and `SbusParser::new(&mut reader)`
<dirbaio[m]>
at their choice
<dirbaio[m]>
if you take `&mut R`, then the user can ONLY do `SbusParser::new(&mut reader)`
<ragarnoy[m]>
oh so &mut rx would allow me to use it here new(reader: &'a mut R) -> Self
<ragarnoy[m]>
damn
<dirbaio[m]>
which is more restrictive, for no benefit
<ragarnoy[m]>
i get it, thanks
<ragarnoy[m]>
* i get it now, thanks :)
dcn has quit [Remote host closed the connection]
AtleoS has quit [Ping timeout: 264 seconds]
AtleoS has joined #rust-embedded
MathiasKoch[m] has quit [Quit: Idle timeout reached: 172800s]
RobertJrdens[m] has quit [Quit: Idle timeout reached: 172800s]
avery71[m] has quit [Quit: Idle timeout reached: 172800s]
mali[m] has quit [Quit: Idle timeout reached: 172800s]
<ivmarkov[m]>
What is the point of `embedded_io_async::BufRead`? It doesn't have the `read_line` & other extras of its blocking STD equivalent, so I can't see the point of its existence? Why isn't a "buffered" reader that just takes a `&mut [u8]` buf on construction and just fullfills the `Read` contract good enough?
<ivmarkov[m]>
Am I missing some use case related to cancellation safety? Can't see it... :(
<dirbaio[m]>
it's just that it allows avoiding copies
<dirbaio[m]>
like you can implement read_line on top of it efficiently
<ivmarkov[m]>
Got it. That's because the BufRead contract actually alllows the user to borrow the internal buffer and operate off from it. Thanks for the clarification.
<dirbaio[m]>
and we could add helpers like read_line to embedded-io. they're not there because none has done it, PRs welcome
<dirbaio[m]>
when I originally wrote it I focused on just the traits because otherwise it was a never-ending task 🤣
<ivmarkov[m]>
Minimal is good.
<ivmarkov[m]>
dirbaio: No rush, just noticed these two things:
<gdamjan[m]1>
why would cargo size work for the src/main.rs binary, but cargo size --example abc shows 0 bytes text, etc. the target/thumbv8m.main-none-eabihf/debug/examples/abc binary is 2.4M actually. (yes llvm-tools is installed, and cargo-binutils too)