ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #rust-embedded
nex8192 has left #rust-embedded [Error from remote client]
crabbedhaloablut has joined #rust-embedded
tafa has quit [Quit: ZNC - https://znc.in]
tafa has joined #rust-embedded
sigmaris has quit [Ping timeout: 250 seconds]
sigmaris has joined #rust-embedded
nex8192 has joined #rust-embedded
sigmaris_ has joined #rust-embedded
sigmaris has quit [Ping timeout: 246 seconds]
sigmaris_ is now known as sigmaris
id_tam has quit [Ping timeout: 246 seconds]
IlPalazzo-ojiisa has joined #rust-embedded
dirbaio[m] has joined #rust-embedded
<dirbaio[m]> s/then the defmt macros break, because they emit code doing `defmt::blahblah/then the defmt macros break, because they emit code doing \`defmt::blahblah`/
<dirbaio[m]> * doing `defmt::blahblah`
<dirbaio[m]> is there a way to have different Cargo features import different defmt versions, but have them all be named defmt from the crate code's PoV? not defmt_03
drebbe[m] has joined #rust-embedded
<drebbe[m]> I'm actually curious about this also, I have a crate that needs different package versions based on distro (underlying library version breakage)
<dirbaio[m]> context is this, we want to be able to support future defmt versions without breaking changes https://github.com/rust-embedded/embedded-hal/pull/450
<dirbaio[m]> so, naming Cargo features defmt-03, defmt-04, defmt-1 instead of just defmt
diondokter[m] has joined #rust-embedded
<diondokter[m]> I guess this needs to be changed in defmt. I think there's a crate for macros that figures out what crate:: would be named for macros, but I've forgotten the name
<diondokter[m]> Also, I did not emotionally prepare for the face reveal :P
<dirbaio[m]> but it suuuuuucks
<dirbaio[m]> and it breaks if you enable both
<diondokter[m]> I think it's the only option without changing defmt
<dirbaio[m]> <diondokter[m]> "I guess this needs to be changed..." <- https://docs.rs/proc-macro-crate/latest/proc_macro_crate/ ?
<diondokter[m]> That could be it yeah
<diondokter[m]> Oh wow, a macro crate not made by Dave Tolnay? 😲
<dirbaio[m]> omg, it reads Cargo.toml. Seems a giant hack
<dirbaio[m]> it'll break non-Cargo build systems.. :(
<dirbaio[m]> seems like this is a legit unsolved problem https://github.com/rust-lang/rust/issues/54363
GenTooMan has quit [Ping timeout: 245 seconds]
GenTooMan has joined #rust-embedded
emerent has quit [Ping timeout: 246 seconds]
emerent has joined #rust-embedded
<dirbaio[m]> GHA is so broken
adamgreig[m] has joined #rust-embedded
<adamgreig[m]> because the previous one overwrites the existing matrix entry
<adamgreig[m]> all rust x all target generates 3x3=9 jobs
<adamgreig[m]> the include lines say "for the matching one of those 9 jobs, add these extra items"
<adamgreig[m]> I think it's already not testing both std and alloc features
<adamgreig[m]> I think possibly if you added a new matrix element features with just [] or [""] or something it might mean all the entries in include are added as new jobs?
<dirbaio[m]> wtf
<dirbaio[m]> oh my god I understood it now
<dirbaio[m]> first the matrix is "expanded" into all possible combinations... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/FdnIAQJPIQoGTccyfxJIvqnz>)
<dirbaio[m]> wtf
<dirbaio[m]> * wtf, why is it this way? it makes no sense
<dirbaio[m]> if that was true though, why did the 1st feature combination win ('std,tokio-1,futures-03') instead of the last ('std,tokio-1,futures-03,defmt-03')???
whitequark[cis] has joined #rust-embedded
<whitequark[cis]> github actions matrices are so confusing
<dirbaio[m]> same issue happens with alloc vs std, only one is being tested :V
<dirbaio[m]> and no one noticed lol
<adamgreig[m]> it's designed to support the use-case of "expand matrix, but add a few extra elements to some of those matrix jobs", I think
<adamgreig[m]> moreso than "expand matrix, then add some more jobs to the list"
<dirbaio[m]> they could've added a non-confusing field that does the 1st, then another non-confusing field that does the 2nd 🤪
<adamgreig[m]> instead they chose violence, lol
<dirbaio[m]> instead of a single "omg look how smart I am, with these ununderstandable rules, you can do both with a single field 🤓"
<adamgreig[m]> also it does of course add new entries if the keys you specified aren't all an existing matrix job
<dirbaio[m]> s/a single//
<adamgreig[m]> <dirbaio[m]> "if that was true though, why did..." <- once the first combination had been applied, maybe the second no longer matched it 💀
<dirbaio[m]> but then it'd have added a new combination?
<adamgreig[m]> I dunno though, naively you'd think that might make it add it as a new entry
<dirbaio[m]> but it didn't
<adamgreig[m]> but obviously not
<dirbaio[m]> ¯\_(ツ)_/¯
<dirbaio[m]> <adamgreig[m]> "I think possibly if you added..." <- yep, this worked :D thanks for the trick
<dirbaio[m]> e-h has 16 checks now
<adamgreig[m]> More of a lucky guess than a trick
<dirbaio[m]> I wonder if testing for thumbv6 and thumbv7 is worth it, or could we just do only one of them
<adamgreig[m]> For e-h it seems overkill maybe?
<dirbaio[m]> yea, there's nothing depending on the arch :P
<adamgreig[m]> Like it should work on arbitrarily many platforms and doesn't have platform specific code so
<dirbaio[m]> just x86 would be enough
<adamgreig[m]> Yea...
<dirbaio[m]> * be enough even
<adamgreig[m]> Could leave tv6 just in case maybe but not sure why
IlPalazzo-ojiisa has quit [Remote host closed the connection]
GenTooMan has quit [Ping timeout: 246 seconds]
GenTooMan has joined #rust-embedded
crabbedhaloablut has quit []
GenTooMan has quit [Excess Flood]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 260 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #rust-embedded