06:24 <FrreJacques[m]> There is a thing I don't understand with error handling.... (full message at <https://catircservices.org/_irc/v1/media/download/AaOWJbbHbUn9THttwcio9kYnYnVKT-MHlVG7PblZQ1894fqAM-mfvf7sO85Ilw-DY-QyTRzgSKfaJzSVxT2hhdW_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9nVGpNaUVFUmp2eHpJRlRYS0xRdVVBTUQ>)

06:24 <danielb[m]> I think it's not fundamentally impossible to implement blocking SpiDevice trait for the async embassy-embedded-hal SpiDevice struct 🤔

06:25 <danielb[m]> FrreJacques[m]: it's possible for a struct to implement a function in some way, then implement a trait that has a function named the same way and have a different signature

06:26 <danielb[m]> you'll find a separate `impl Trait for Struct` block that also has `fn set_high(&mut self) -> Result<(), Self::Error>`

06:27 <FrreJacques[m]> 😳

06:30 <FrreJacques[m]> Found it:... (full message at <https://catircservices.org/_irc/v1/media/download/AaB-hxpsAKo8q3sa4BLnccSoIaBSapzYubLsezUZmpGObo-UpacJX8dbjH-Dd_Y_vknCe9QG3F58xtcWU4qAJu2_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9EZWZKYXB2RnpFbHBMYmJObHpIZURLd1g>)

06:32 <danielb[m]> look at https://doc.rust-lang.org/reference/expressions/method-call-expr.html

07:06 <FrreJacques[m]> I see. Because I use the ehal trait and therefor handling a result, the compiler knows that this can't be resolved to the function with the non result.

07:11 <FrreJacques[m]> So the ErrorType of ehal is generic. Which means implementers could use all sorts of different errors. Which means I am required to keep that generic too.

07:15 <FrreJacques[m]> Can I expect that if I require a type to impl ehal InputPin + OutputPin that the associated errortypes are identical. Don't see already whether this could complicate things further.

12:16 <LiamKinne[m]> https://umi.engineering/blogs/engineering/how-we-use-tlv-c-to-encode-our-product-data

12:16 <LiamKinne[m]> I wrote a short blog post on how I'm using TLV-C to encode product data in the things I make and sell. Interested to hear if anyone else is using something like this for OTP data.

13:19 <jduck[m]> I think it's pretty common to store such things in OTP. I'm not familiar with TLV-C

13:23 <jduck[m]> It looks neat but i have some concerns about how such flexibility can undermine security. Of course that assumes someone depends on it for security to begin with.

18:06 <thejpster[m]> https://docs.rs/corstone300-pac 👀

18:07 <thejpster[m]> that's a PAC for a system that QEMU can emulate (and also Arm has a Fixed Virtual Platform emulator for it) - and it's published by Arm

18:07 <JamesMunns[m]> Maybe we should ping mousius to come hang out and say hi here :D

18:07 <thejpster[m]> Thanks ithinuel ! just what I needed for this example I'm writing

18:07 <ithinuel[m]> thejpster[m]: guilty

18:08 <thejpster[m]> (Today I'm writing "How to write your own fully buffered interrupt-driven global-state UART driver")

18:08 <ithinuel[m]> ithinuel[m]: It’s not been updated ever since I generated it back in the days, let me know if there’s need to get it updated with latest svd2rust)

21:10 <almindor[m]> <danielb[m]> "I think it's not fundamentally..." <- Yes I suspect it's an exclusive and/or in the end. I'm now looking into possibility to use something like `maybe-async` instead to avoid absolute code duplication

21:11 <almindor[m]> s/and/or/choice/

21:12 <almindor[m]> I really think a "called decides what's async" approach would possibly work for Rust. If you think about it, that's what it always boils down to in the end. It'd be interesting if it was "automatic language feature". Essentially a separate "asyncmorphisation".

21:12 <almindor[m]> s/called/caller/

21:13 <danielb[m]> like [this](https://blog.rust-lang.org/inside-rust/2022/07/27/keyword-generics.html)?

21:14 <almindor[m]> yeah, I'm sure I'm not the only or even early person to think up something like this :D

21:16 <almindor[m]> I've got a feeling there's also a lot of hidden "gems" in this approach due to the horrors of Pin at al. and other "hacks" that made it because it was too late for changes to move, drop and a bunch of others