00:41 <spinfast[m]> And people wonder why no one likes dealing with C/C++ dependencies in distros...

00:41 <spinfast[m]> "1.59" sheesh

00:44 <spinfast[m]> I get nix probably can't produce as small of an image or whatever but yocto was pretty painful from my experience with it... nothing like some unintelligible bitbake error hours in

08:28 <Ralph[m]1> not exactly an embedded problem per-se, but rustc complains about some code where i really don't understand why:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/WllvgIEimNQGhmGUqLPZbmIi>)

13:30 <jannic[m]> Ralph: I'd say it's a rustc bug. This one: https://github.com/rust-lang/rust/issues/76053

13:32 <Ralph[m]1> thanks a lot for pointing me to that issue jannic! i'll add a comment to the one in the error message so that people can find it easier in the future

14:33 <spinfast[m]> I forget, can chiptool specify the register size somewhere in yaml?

14:39 <spinfast[m]> ugh actually nevermind I don't think it'll work for what I want without a custom generator, wanted to use it to generate a regmap for an i2c device... nothing like hand writing out 55 registers worth of bitmaps and masks...

14:41 <spinfast[m]> kind of wish the svd/yaml -> IR would be split from the generator part, I guess I could PR that

14:41 <spinfast[m]> no real reason it couldn't be? dirbaio ?

14:49 <JamesMunns[m]> https://github.com/diondokter/device-driver was a proc macro approach to this

15:02 <diondokter[m]> It works fine, but it's grown too big. Can't really add anything anymore

15:02 <diondokter[m]> <JamesMunns[m]> "https://github.com/diondokter/..."; <- Not a proc macro. Way too big normal macro 😅

15:21 <spinfast[m]> I was thinking it’d be cool to do this with yaml like chiptool honestly

15:21 <spinfast[m]> Easy to describe registers, field sets, etc

15:22 <spinfast[m]> But yeah then wiring that up to i2c/spi/whatever non mmio would be interesting

15:22 <spinfast[m]> The macro looks neat

15:55 <JamesMunns[m]> Not sure if it helps, but I've sorta found a pattern I like recently for coupling types, by using a marker trait with a marker type. I use it in postcard-rpc:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/uqdJVBiYOuZUcDsUkPxeWGNf>)

15:55 <JamesMunns[m]> then you can have functions like:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/uVlUSFSjbDcOVpaijBTrAVKM>)

16:00 <JamesMunns[m]> basically, using it to "bundle" a bunch of metadata into a single entity. For I2C registers, you might have something like:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/NzIJgxsuDcjQUsZehyEtyRVL>)

16:04 <JamesMunns[m]> something like that

16:05 <JamesMunns[m]> That way you don't need to codegen a ton of functions, you just codegen a bunch of marker types and trait impls, and let the compiler do all the monomorphizing for you.

16:07 <JamesMunns[m]> At least, I find it helpful for building a suite of functions that all need to take a bunch of consts and types, and that way you don't end up with some silly function that takes like 4 parameters and 4 different generic types lol

16:10 <JamesMunns[m]> like, you can also make functions like:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/DPFTMqASMfCRrxHpbFveDyPR>)

16:11 <JamesMunns[m]> or even monomorphize a function that builds the right-sized transaction for you, with the proper endianness, like:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/PugBtIZCCCpMsUlNhWBaOdTA>)

16:12 <JamesMunns[m]> anyway, this is the end of my "you can use marker traits to bundle metadata" braindump, that I now realize should be a blog post lol

16:16 <diondokter[m]> That could be a neat system! But something that's not in there is being able to specify the bitfields in a nice way.

16:17 <JamesMunns[m]> totally fair! I tend to use this with postcard a lot, maybe lean on a similar `ToBits` or `FromBits` trait? but that still leaves you with "implement serde but for bitfields"

16:21 <diondokter[m]> So my macro reads or creates some specified bytes and then uses bitvec to be able to read or write data to it with specified bit positions. It follows the integers or enums as integers.

16:33 <JamesMunns[m]> makes sense!

16:34 <JamesMunns[m]> If it was backed with a trait, you could use my marker trait by requiring type Value: ToBits; or something

20:06 <chrysn[m]> Looking through old photos just found what is probably the first hint at emebbed-nal, from April 2019 at the Oxidize conference:

20:07 <chrysn[m]> (image description: Picture of a whiteboard. Black marker / my handwriting: "Is it time for embedded-hal style network abstractions yet? --christian". Blue marker / dunno whose handwriting: "yeh")

20:50 <sirhcel[m]> While you are talking about the oxidize conference. I really enjoyed it 2020 and I would love to attend a conference of this kind again. What's the reason it did not got repeated yet? The incredible amount of work necessary for organizing it?

20:53 <thejpster[m]> well there was a pandemic in the middle

20:53 <thejpster[m]> it's been discussed, but we were a bit busy making Ferrocene

20:53 <thejpster[m]> I think Tweede Golf want to do something around Rust NL next year, possibly

20:54 <thejpster[m]> plus EuroRust 2022 was in Berlin anyway

20:55 <sirhcel[m]> thejpster[m]: That's good to hear and a pretty good excuse as well.

20:56 <sirhcel[m]> Then i will watch out for rust nl. Crossing fingers.

21:00 <sirhcel[m]> <thejpster[m]> "plus EuroRust 2022 was in Berlin..." <- That's another good point. I remember the talk from hendrik alser and ai maiga but i missed the embedded deep dive.

21:04 <sirhcel[m]> And something completely different: `rustfmt` puzzles me by reporting different results on linux and macos. I'm running the same version on both systems. But I'm getting different results with respect to presumed line lengths and wrapping. For example, I'm getting things like... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/qcdqDiVLmpIfFcTFNrHlTtDu>)

21:08 <thejpster[m]> daft question - same version?

21:09 <diondokter[m]> Also make sure you don't have a rogue rustfmt.toml file in your filesystem

21:09 <JamesMunns[m]> also rustfmt has a config file... yeah like Dion said :D

21:17 <sirhcel[m]> No config files are present on the systems. But to my surprise: despite having an `rustup update` on both machines and having the same toolchain versions on both, the actual version of `rustfmt` differs.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/JIWodUkeHYeLZPwSyktGvGpf>)

21:17 <sirhcel[m]> * No config files are present on the systems. But to my surprise: despite having ran `rustup update` on both machines and having the same toolchain versions on both, the actual version of `rustfmt` differs.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/UARDNgeXsDkqUWyYOEvbBCgK>)

21:19 <sirhcel[m]> No, i misread the version on linux for 1.7.0. It's actually the same version on both systems.

21:21 <sirhcel[m]> It's getting late for me ... 😅

21:34 <thejpster[m]> > Rustfmt is designed to be very configurable. You can create a TOML file called rustfmt.toml or .rustfmt.toml, place it in the project or any other parent directory and it will apply the options in that file. If none of these directories contain such a file, both your home directory and a directory called rustfmt in your global config directory (e.g. .config/rustfmt/) are checked as well.

21:50 <sirhcel[m]> Neither is present in my project and i checked out the same revision on both machines. By moving `rust-toolchain.toml` out of the way, I'm getting back the same result on both targets. But strangely enough even the nightly toolchain selected by this file is the same on both machines.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/VOdMLcRPldwqGwrPEVswCKjQ>)

21:50 <sirhcel[m]> * Neither is present in my project and i checked out the same revision on both machines. By moving `rust-toolchain.toml` out of the way, I'm getting back the same result on both targets. But strangely enough even the nightly toolchain selected by this file is the same on both machines.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/giqzLINADfWEJiciBJGBUQYL>)

22:02 <thejpster[m]> Almost all of the binaries in ~/.cargo/bin are actually rustup wearing a hat

22:02 <thejpster[m]> which is why they all have the exact same size

22:10 <sirhcel[m]> Thanks! I have never looked at these binaries from this perspective.