02:09 <whitequark[cis]> <vollbrecht[m]> "Catherine: hope it's ok to..." <- in what way?

02:40 <vollbrecht[m]> <whitequark[cis]> "in what way?" <- all users that used your bridge where constantly joining and leaving over a period of 30 min into this room

02:40 <vollbrecht[m]> vollbrecht[m]: at the time when i pinged you

02:41 <vollbrecht[m]> * and leaving this room over a

10:35 <dinkelhacker> Hi all, does anyone know how to force cargo to append ".eld

10:35 <dinkelhacker> Hi all, does anyone know how to force cargo to append ".elf" to the end of the executeable?

10:36 <dinkelhacker> I see there is https://doc.rust-lang.org/nightly/nightly-rustc/rustc_target/spec/struct.TargetOptions.html#structfield.exe_suffix but I don't get how I can set that?

10:52 <explodingwaffle1> https://doc.rust-lang.org/cargo/reference/cargo-targets.html#configuring-a-target this should work?

11:04 <dinkelhacker> That's what I tried but it seems to have no effect.

11:04 <dinkelhacker> so in my cargo toml I have

11:04 <dinkelhacker> [[myapp]]

11:04 <dinkelhacker> name = "myapp"

11:04 <dinkelhacker> exe_suffix = "elf"

11:05 <dinkelhacker> I also tried to add it to the target options in the cargo config file

11:10 <dinkelhacker> And I also tried to set it in my custom target.json (which I think should be the right place)

11:14 <dinkelhacker> omg ... the field "exe_suffix" translates to "exe-suffix" in the target json. So _ becomes -

16:14 <mheld[m]> I just set up a brand new project using the esp-idf-template (https://github.com/esp-rs/esp-idf-template/) but am running into compiling issues -- do I have cargo/rust misconfigured?

16:14 <mheld[m]> am getting yelled at (use of undeclared crate or module embedded_svc) even though I can see it in my Cargo.lock

17:57 <Ralph[m]1> <mheld[m]> "I just set up a brand new..." <- for esp related questions it's probably best to ask them over at https://matrix.to/#/#esp-rs:matrix.org

18:06 <mheld[m]> on it! ty

22:30 <barafael[m]> I have an e-h@0.2 Serial type, and I'm calling .forward (from e-h-compat on it). But when I call my function with it, which requires an `embedded-io::Read`, then I get:... (full message at <https://catircservices.org/_irc/v1/media/download/AdhjAXvHxD-_75az3sQl6pD98FD_vrlkMr4xBgMtaayrcNv3zyUhBbM1Ga9B7EYOQc_cYlKMFKLvFEx97znQlhy_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy94cXRrREJJb1FpQklzR2dmZ3lwcW9hb0Y>)

22:31 <barafael[m]> anybody got a hunch why that might be?

22:32 <barafael[m]> nope

22:32 <dirbaio[m]> missing Cargo feature embedded-io in embedded-hal-compat?

22:33 <barafael[m]> wait what

22:33 <dirbaio[m]> stm32h7xx_hal missing the 0.2 Read impls?

22:33 <dirbaio[m]> ah nope, e-h-compat doesn't forward Read https://github.com/ryankurte/embedded-hal-compat/blob/main/src/forward.rs#L310

22:33 <dirbaio[m]> probably because 0.2 didn't have blocking read, only nb read

22:35 <barafael[m]> ok, it's just an stm32h7 based example and the h7 hal isn't yet 1.0. Not a deal breaker I think

22:36 <dirbaio[m]> you can write your own adapter from the nb trait

22:36 <dirbaio[m]> or embassy-stm32 does support eh1.0 and e-io

22:39 <barafael[m]> this PR for e-h-1 look half way decent to you? https://github.com/tstellanova/ublox-core/pull/3

22:40 <dirbaio[m]> if you use SpiDevice then you don't want to handle the CS pin directly, that's done for you

22:41 <dirbaio[m]> ah it might not matter much because the SPI interface is all unimplemented!() 😅

22:42 <dirbaio[m]> still you might want to remove csn to not confuse someone if they decide to implement it

22:43 <dirbaio[m]> looks great otherwise 🚀

22:44 <barafael[m]> I'm not sure about that DeviceInterface trait...

22:45 <barafael[m]> dirbaio thanks for your hints!