<re_irc>
<@dirbaio:matrix.org> let decompressed_out: impl Write = ...;
<re_irc>
<@dirbaio:matrix.org> let compressed_in: impl Read = ...;
<re_irc>
<@bobmcwhirter:matrix.org> I prefer wrappers myself.
<re_irc>
<@dirbaio:matrix.org> the problem with wrappers is I need to be able to "suspend" decompression
<re_irc>
<@ryan-summers:matrix.org> Doesn't that work well though? Then you can decompress it into a provided slice
<re_irc>
<@ryan-summers:matrix.org> So you control how much is getting decompressed at any point
<re_irc>
<@ryan-summers:matrix.org> While you can't interrupt that, you can control its execution time pretty effectively
<re_irc>
<@dirbaio:matrix.org> yeah...
<re_irc>
<@ryan-summers:matrix.org> You seem unsatisfied
<re_irc>
<@dirbaio:matrix.org> read-->read wrapper seems the nicest
<re_irc>
<@dirbaio:matrix.org> but to impl that I need to turn the decompressor into state machine spaghetti :D
<re_irc>
<@ryan-summers:matrix.org> Agreed with taking in the input stream in new() and writing out to an output slice, but I'd use `de.write(&mut output)`
<re_irc>
<@ryan-summers:matrix.org> You're making a decompressor that can write into some output buffer aren't you? Or does the `Write` trait not work like that?
<re_irc>
<@dirbaio:matrix.org> they're supposed to be the io Read/Write (or a nostd equivalent)
<re_irc>
<@dirbaio:matrix.org> so "gimme bytes" is read
<re_irc>
<@ryan-summers:matrix.org> Ah yeah, `Write` means you can write into the object
<re_irc>
<@ryan-summers:matrix.org> Yeah, agreed with read -> read API then
<re_irc>
<@dirbaio:matrix.org> the straight `decompress` func is way easier to implement though :S
<re_irc>
<@ryan-summers:matrix.org> It depends if you want to be able to hand around your decompression object as you do the decompression
<re_irc>
<@dirbaio:matrix.org> for context: I'm writing an `inflate` lib for embedded optimized for code size
<re_irc>
<@dirbaio:matrix.org> for decompressing firmware updates and scuh
<re_irc>
<@ryan-summers:matrix.org> Would allow you to decompress chunks at a time and move them to different users
<re_irc>
<@dirbaio:matrix.org> oh, hmm
<re_irc>
<@ryan-summers:matrix.org> Basically: Do you ever want to pass the yet-to-be-decompressed data to a function where it can do some decompression? If so, wrapper. If you just want to blindly decompress some data in one location, a one-off function makes more sense
<re_irc>
<@dirbaio:matrix.org> shame generators are still unstable 😠
<re_irc>
<@dirbaio:matrix.org> they'd be awesome for this
<re_irc>
<@dirbaio:matrix.org> I can probably abuse async to get the same
<re_irc>
<@dirbaio:matrix.org> but not sure if worth it :S
<re_irc>
<@therealprof:matrix.org> Please grab your favourite beverage, sign in an feel free to add additional topics. We'll start in a few minutes.
<re_irc>
<@therealprof:matrix.org> Alright. 5 past the hours, let's get started. Anything have anything to announce?
<re_irc>
<@therealprof:matrix.org> I was just checking the current high water mark on the blog post which is overdue since August. I think we have enough material now with the latest addition to get that out the door. I can apply the finishing touches after the meeting.
<re_irc>
<@therealprof:matrix.org> Okay, moving on to embedded-hal. Where are we with the I2C NACK change?
<re_irc>
<@thejpster:matrix.org> As I I have 5 bytes to send and then 7 bytes to receive. But anything received during the send is garage, and dummy data must be sent during the receive?
<cr1901>
Isn't this a lot of SPI devices (read and write don't overlap)?
<re_irc>
<@thejpster:matrix.org> Do I have to make my read buffer 5 + 7 = 12 bytes long?
<re_irc>
<@thejpster:matrix.org> cr1901: Yes, I believe most SPI devices are like this.
<cr1901>
SPI flash and SD cards are my goto exaples
<cr1901>
examples*
<re_irc>
<@thejpster:matrix.org> Do I just do a write(5) and then do a read (7)?
<re_irc>
<@therealprof:matrix.org> Well, by definition read and write always overlap because you'll have to clock out data in order to receive.
<re_irc>
<@thejpster:matrix.org> [ SD cards have the additional fun of spinning for an indeterminate period until the returned byte is not FF, but you can solve that with a lot of read (1) ]
<re_irc>
<@therealprof:matrix.org> The big question is how that is implemented internall.y
<re_irc>
<@thejpster:matrix.org> Yeah, it's a shame to waste memory of you know it's really only half duplex.
<re_irc>
<@ryankurte:matrix.org> eldruin:matrix.org: given we’re okay with the mismatched length thing seems alright to me
<re_irc>
<@therealprof:matrix.org> Especially with DMA that is a big questionmark to me.
<cr1901>
thejpster: Remind me to ask you something after the meeting lol
<cr1901>
(tech q)
<re_irc>
<@thejpster:matrix.org> But the mismatched length still means that the read buffer and write buffer start at the same point in time. There's no API to say "discard the first N bytes as they are garbage"
<re_irc>
<@ryankurte:matrix.org> right the only time that can happen is at the end
<cr1901>
And "discard until the byte is not 0xFF" :)
<re_irc>
<@therealprof:matrix.org> thejpster:matrix.org: That sounds painful to implement. 😅
<re_irc>
<@eldruin:matrix.org> you can always use `TransferInplace` to continue using the current one-buffer interface
<re_irc>
<@ryankurte:matrix.org> they’re relevant questions / problems but, given it’s not removing any functionality, perhaps not in the scope of this particular PR?
<re_irc>
<@thejpster:matrix.org> As a total aside, can we just buy our own home server because this is almost unusably laggy tonight. I've got "read up to here" markers going back three pages.
<re_irc>
<@therealprof:matrix.org> Hm, seems snappy to me.
<re_irc>
<@eldruin:matrix.org> it is snappy for me
<re_irc>
<@therealprof:matrix.org> I'm fine with merging this if you are.
<re_irc>
<@ryankurte:matrix.org> i’m in a web client because the apps are crash-looping but, probably unrelated 😅
<re_irc>
<@therealprof:matrix.org> (pending resolution of the merge conflict)
<re_irc>
<@xiretza:xiretza.xyz> thejpster:matrix.org: slightly offtopic now, but you can use whatever homeserver you want, rooms are not bound to any specific server.
<re_irc>
<@eldruin:matrix.org> I'm fine with merging as well
<re_irc>
<@ryankurte:matrix.org> me too
<re_irc>
<@therealprof:matrix.org> Can you add a comment?
<re_irc>
<@thejpster:matrix.org> Ok, fine. I might do a PR for TransferNonOverlapping or somesuch.
<re_irc>
<@eldruin:matrix.org> done
<re_irc>
<@ryankurte:matrix.org> thejpster:matrix.org: 👍️ interesting to see whether you can split one buffer into a set of transactional ops to achieve this
<re_irc>
<@therealprof:matrix.org> Okay. Moving on.
<re_irc>
<@therealprof:matrix.org> I think the proposal of feature gating behind an `async` feature seems interesting. What's the feeling about that?
<re_irc>
<@therealprof:matrix.org> It seems dirbao has put a bit review work in so there's a good chance it might be usable/useful.
<re_irc>
<@ryankurte:matrix.org> i’d be happy with gating it, though at the same time, now the approach seems sound / we have a high level i have some feeling that it would be preferable to approach it piecewise with real implementations per the way we approach other traits.
<re_irc>
<@lulf_:matrix.org> Similar versions of these traits are already implemented in embassy
<re_irc>
<@therealprof:matrix.org> Seems good but my understanding is it might not be implementable in stable yet.
<re_irc>
<@lulf_:matrix.org> But embassy will likely switch to them once they're in (correct me if I'm wrong dirbaio )
<re_irc>
<@ryankurte:matrix.org> i need to double check but i think most of this works on stable now
<re_irc>
<@ryankurte:matrix.org> (either way still fine to gate with `async`, just, would like to see impls on both sides)
<re_irc>
<@lulf_:matrix.org> Hmm, you need GAT for this I think
<re_irc>
<@lulf_:matrix.org> For `type WriteReadFuture<'a>: ...`
<re_irc>
<@therealprof:matrix.org> Okay, would be good if we could make some progress on this.
<re_irc>
<@therealprof:matrix.org> Other than that it seems we're close to finally calling it 1.0?
<re_irc>
<@lulf_:matrix.org> I can have a look at ping people about that PR
<re_irc>
<@ryankurte:matrix.org> but it’s also not critical for 1.0
<re_irc>
<@therealprof:matrix.org> Please do. 1.0 is long overdue; would be great if we could start procrastinating on 2.0 instead. Plenty of ideas for that already. 😉
<re_irc>
<@therealprof:matrix.org> Okay, I have another topic for today.
<re_irc>
<@therealprof:matrix.org> We briefly discussed the idea of merging `cortex-m-rt` into `cortex-m` to eliminate a ton of issues.
<re_irc>
<@therealprof:matrix.org> Anyone had some time to think about it?
<re_irc>
<@ryankurte:matrix.org> from the outside, not doing the conflicting version dance sounds great to me
<re_irc>
<@therealprof:matrix.org> I think most concerns circled around bringing in concepts which might conflict with other runtimes.
<re_irc>
<@thejpster:matrix.org> Yeah, seems ok to me. There's already other stuff in the repo anyway.
<re_irc>
<@emilgardis:matrix.org> `cortex-m` with `rt` feature?
<re_irc>
<@therealprof:matrix.org> emilgardis:matrix.org: Seems most likely to end up that way.
<re_irc>
<@therealprof:matrix.org> Hm, I guess I need to sleep some more about this. Sounds to easy to come true. 😀
<re_irc>
<@therealprof:matrix.org> Okay, I'm out of topics and ideas. Any famous last words for the remaining minutes?
<re_irc>
<@thejpster:matrix.org> Can anyone recommend a good matrix server?
<re_irc>
<@therealprof:matrix.org> ... on embedded? 😀
<re_irc>
<@thejpster:matrix.org> honestly I think I had less lag back when I had a 386 and dial up
<re_irc>
<@thejpster:matrix.org> Also, if you like stm32 you should look in the #stm32-rs:matrix.org room.
<re_irc>
<@therealprof:matrix.org> Maybe reactivate that then? 😀
<re_irc>
<@therealprof:matrix.org> That's a good call, thejpster has some hardware to spare.
<Shellhound>
matrix has been full of lag for years, switching server away from matrix.org just makes it worse ime
<re_irc>
<@therealprof:matrix.org> Alright, I'm calling it then. Thanks for your participation.
<re_irc>
<@therealprof:matrix.org> ryankurte: Good to have to you on live!
<re_irc>
<@ryankurte:matrix.org> thanks (as always) for running the meeting!
<re_irc>
<@ryankurte:matrix.org> we're GMT+13 again now so it's only 9am here (8am meetings instead of 6am) so, hopefully be a bit more regular over (our) summer ^_^
<re_irc>
<@xiretza:xiretza.xyz> irc_libera_shellhound:psion.agg.io: I've heard lots of complaints about lag from matrix.org users, my own homeserver has been running very snappily ever since I moved it from a raspberry pi to a VPS ;)
<re_irc>
<@therealprof:matrix.org> ryankurte:matrix.org: My son showed me a new trick today: Wear the watch upside down. 😀
<re_irc>
<@thejpster:matrix.org> +13 or -11?
<re_irc>
<@ryankurte:matrix.org> therealprof:matrix.org: that's definitely a southern hemisphere appropriate gag
<re_irc>
<@ryankurte:matrix.org> thejpster:matrix.org: +13, we come from the future :-P
<re_irc>
<@eldruin:matrix.org> ok I'll ask what everyone else is wondering: Does the toilet water spin the other way or not? I need to know this
<re_irc>
<@ryankurte:matrix.org> we have different (imo way more sensible) toilets, there's no spinning involved 😅
<re_irc>
<@matoushybl:matrix.org> eldruin:matrix.org: what is the reference water spinning direction? might run some tests tonight
<re_irc>
<@eldruin:matrix.org> ach, you guys are holding science back!
<re_irc>
<@eldruin:matrix.org> matoushybl:matrix.org: good question
<re_irc>
<@eldruin:matrix.org> xD
<re_irc>
<@ryankurte:matrix.org> it's a US specific thing though right? everywhere i've been in europe also has the water-saving ones
<re_irc>
<@eldruin:matrix.org> I wouldn't know, all toilets I have seen do not spin
<re_irc>
<@eldruin:matrix.org> but the same thing happens on the sink or so
<re_irc>
<@eldruin:matrix.org> IIRC, water spins clockwise
starblue has quit [Quit: WeeChat 3.0]
<re_irc>
<@ryankurte:matrix.org> preliminary results indicate, it's random / depends entirely on any spin imparted by asymmetric flow. but i'm gonna need more sinks
<re_irc>
<@eldruin:matrix.org> haha thanks for checking on it!
<re_irc>
<@therealprof:matrix.org> Hm, doesn't seem like a good source of entropy...
<re_irc>
<@ryankurte:matrix.org> probably more difficult to scale than a wall of lava lamps too
<re_irc>
<@gauteh:matrix.org> I need to put a device to deep-sleep, including re-configuring a bunch of pins used for i2c, etc, while in deep-sleep mode. Waking up needs to re-configure those pins. the i2c pins are used by a driver crate which takes embedded-hal traits. how could I share those without needing to re-initialize the driver? do you know of any examples of this?
unmanbearpig has quit [Ping timeout: 260 seconds]
unmanbearpig has joined #rust-embedded
tokomak has quit [Read error: Connection reset by peer]
engest has quit [Read error: Connection reset by peer]
engest has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> Where are you running into problems?
<re_irc>
<@firefrommoonlight:matrix.org> The answer is probably to not use the driver, or to fork it
<re_irc>
<@firefrommoonlight:matrix.org> What specifically are you doing?
emerent_ has joined #rust-embedded
emerent_ is now known as emerent
emerent is now known as Guest376
Guest376 has quit [Ping timeout: 260 seconds]
SomeWeirdAnon has joined #rust-embedded
loki_val has quit [Remote host closed the connection]