ilya-epifanov[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
btw we should definitely report the speed regression upstream if we can repro it
<JamesMunns[m]>
It looks like our test was wrong for some reason (haven't woke up fully yet), but rustc shouldn't pathologically slow down like that either
sourcebox[m] has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiisa has joined #rust-embedded
M9names[m] has joined #rust-embedded
<M9names[m]>
<dirbaio[m]> "how widely used is ufmt these..." <- > it seems unmaintained
<M9names[m]>
r-e-c should at least be able to merge soundness fixes and bugs, which is more attention than it's getting presently.
<M9names[m]>
if there's still users maybe it should be adopted by rust-embedded-community?
<thejpster[m]>
Thank you to everyone here who took part.
AlexandrosLiarok has quit [Quit: Idle timeout reached: 172800s]
<ryan-summers[m]>
Wow, just converted an old 2.x embedded-hal SPI device (the W5500) over to the new 1.0 traits and its an incredible improvement. This device actually can make use of both the SpiBus and SpiDevice traits and the new transaction API is wonderful
<ryan-summers[m]>
The end result was me essentially just deleting mountains of code
<ryan-summers[m]>
* Wow, just converted an old 0.2.x embedded-hal SPI device (the W5500) over to the new 1.0 traits and its an incredible improvement. This device actually can make use of both the SpiBus and SpiDevice traits and the new transaction API is wonderful
dirbaio[m] has quit [Quit: Bridge terminating on SIGTERM]
M9names[m] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
adamgreig[m] has quit [Quit: Bridge terminating on SIGTERM]
JamesMunns[m] has quit [Quit: Bridge terminating on SIGTERM]
diondokter[m] has quit [Quit: Bridge terminating on SIGTERM]
FreeKill[m] has quit [Quit: Bridge terminating on SIGTERM]
ryan-summers[m] has quit [Quit: Bridge terminating on SIGTERM]
pkoevesdi[m] has quit [Quit: Bridge terminating on SIGTERM]
juliand[m] has quit [Quit: Bridge terminating on SIGTERM]
thejpster[m] has quit [Quit: Bridge terminating on SIGTERM]
newam[m] has quit [Quit: Bridge terminating on SIGTERM]
omniscient_[m] has quit [Quit: Bridge terminating on SIGTERM]
<Ralph[m]>
i plan to create a new 0.3 release of `tb6612fng` (a motor driver crate for the chip of that name + probably other similar H-bridges) since i just realised that i haven't released the e-h 1.0 support yet (even though i was quite early in adding it) 🙈 ([full changelog](https://github.com/rust-embedded-community/tb6612fng-rs/blob/master/CHANGELOG... (full message at
<JamesMunns[m]>
I'm just saying: the state of things is what it is. We could push everyone to make it 1.0, but that wouldn't change the fact that if they made a breaking change it would have the same net effect.
<vollbrecht[m]>
most rust crates somewhat follow semver but its not a 100% given. If its not clearly communicated i also would not automatically think that it follows it.
<JamesMunns[m]>
if defmt was 1.0 today, and makes a breaking wire change to 2.0, and you had a defmt feature before, you have the same problem as if it made a breaking 0.4 release in the real world.
<JamesMunns[m]>
IMO cargo new should default to 1.0, but that's a sailed ship, anyway :)
<vollbrecht[m]>
there is also the "unwritten" rust semver rule that 0.x.x crates only try's to do breaking changes in minor patches, while semver allows for any updates to be breaking < 0.x.x e.g it can also break in a patch release.
<vollbrecht[m]>
* there is also the "unwritten" rust semver rule that 0.x.x crates only try's to do breaking changes in minor patches, while strictly semver allows for any updates to be breaking \< 0.x.x e.g it can also break in a patch release.
<vollbrecht[m]>
at least thats how the cargo parsing works to check if crate version a and b are compatible
<JamesMunns[m]>
I don't think it's "unwritten", cargo's semver rules are written
<JamesMunns[m]>
it's the largest non-zero number that is a breaking change
<Ralph[m]>
JamesMunns[m]: sure, i fully agree with that and am aware of it. but it being 1.0 would indicate a "we're happy with the current situation and think it's good for production usage" vs. "hey, this is a sneak preview, give it a spin and report back, but don't use it productively yet" (sure, in the rust ecosystem you can't follow that since then there'd be nearly no crates to use^^)
<vollbrecht[m]>
JamesMunns[m]: that is not written like in the document afaik
<JamesMunns[m]>
> This guide uses the terms “major” and “minor” assuming this relates to a “1.0.0” release or later. Initial development releases starting with “0.y.z” can treat changes in “y” as a major release, and “z” as a minor release. “0.0.z” releases are always major changes. This is because Cargo uses the convention that only changes in the left-most non-zero component are considered incompatible.
<JamesMunns[m]>
this is unique to the Rust/Cargo interpretation of semver, vs the "official" definition of semver, for sure.
<Ralph[m]>
JamesMunns[m]: not as per the semver specification:
<Ralph[m]>
> 4. Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
<vollbrecht[m]>
JamesMunns[m]: yeah thats what i mean sorry to be not clear
<dirbaio[m]>
semver tells you "0.x bad, may break, scary, no production use pls"
<dirbaio[m]>
but that's not what 0.x means in Rust
<dirbaio[m]>
JamesMunns[m]: brain reading backlog lag
<vollbrecht[m]>
dirbaio[m]: its not what it means in "cargo" and everybody that is using it for sure
<dirbaio[m]>
dirbaio[m]: so just feel free to release 1.0
<dirbaio[m]>
* release 1.0 depending on defmt 0.3
<dirbaio[m]>
and if you want to accomodate future defmt releases do the defmt-03 feature name trick, with that you can update to newer defmt breaking releases without doing breaking changes to your own crate
<JamesMunns[m]>
JamesMunns[m]: I for one welcome our new semver overlords at TüV Rhineland.
<dirbaio[m]>
this DOES allow you to be "more stable" than your dependencies
<dirbaio[m]>
which makes it so ignoring the guideline is okay
<JamesMunns[m]>
JamesMunns[m]: And am so willing to pay many CHFs for the official SemVer IEC standard
<JamesMunns[m]>
> Versions are considered compatible if their left-most non-zero major/minor/patch component is the same. For example, 1.0.3 and 1.1.0 are considered compatible, and thus it should be safe to update from the older release to the newer one. However, an update from 1.1.0 to 2.0.0 would not be allowed to be made automatically. This convention also applies to versions with leading zeros. For example, 0.1.0 and 0.1.2 are compatible,
<JamesMunns[m]>
but 0.1.0 and 0.2.0 are not. Similarly, 0.0.1 and 0.0.2 are not compatible.
<JamesMunns[m]>
dirbaio[m]: tbh I wonder if defmt could stabilize the "defmt trait"
<dirbaio[m]>
uh maybe
<JamesMunns[m]>
maybe that's just my new favorite solution to all the problems
<dirbaio[m]>
but still, to impl you need write!() and that brings in all the formatting specifiers etc
<dirbaio[m]>
and the trait has hidden spicy implementation detail methods :D
<JamesMunns[m]>
yeah, that's fair
<JamesMunns[m]>
the actual wire protocol has versioning, which is fun
<dirbaio[m]>
yea. that was to avoid repeating the defmt 0.2 -> 0.3 thing 🤣
<dirbaio[m]>
I think defmt is kinda de facto 1.0
<dirbaio[m]>
a 0.3->0.4 release would be so annoyingly disruptive
<dirbaio[m]>
that nobody wants it
<JamesMunns[m]>
yeah, tbh 0.2 was 1.0, and 0.3 is 2.0
<JamesMunns[m]>
and there's probably room for a 3.0.
henrik_alser[m] has joined #rust-embedded
<henrik_alser[m]>
<JamesMunns[m]> "maybe that's just my new..." <- Traitor
<Ralph[m]>
<Ralph[m]> "i plan to create a new 0.3..." <- > <@rursprung:matrix.org> i plan to create a new 0.3 release of `tb6612fng` (a motor driver crate for the chip of that name + probably other similar H-bridges) since i just realised that i haven't released the e-h 1.0 support yet (even though i was quite early in... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ZZWfNjxOXKDimdJZYtpTFEpV>)
ryan-summers[m] has joined #rust-embedded
<ryan-summers[m]>
R-E-C doesn't have any specific process/requirements imposed. But as a fellow R-E-C maintainer, please just at least tag the respective commit at least :)
<ryan-summers[m]>
s/at least//
<ryan-summers[m]>
Generally, just try to make it so that someone coming in without any knowledge of what you did could do something similar to get a new version out :P
<Ralph[m]>
changelog update, tag & GH release are no-brainers and i'll certainly do that 👍️
ello has joined #rust-embedded
AtleoS has quit [Ping timeout: 268 seconds]
AtleoS has joined #rust-embedded
Sophie[m] has joined #rust-embedded
<Sophie[m]>
Alright I have maybe a stupid question. I'm using RTIC 1; is it not possible to put a `&'static RefCell` in the Local struct? I imagine the issue is moving that reference between the main() method and the struct, since they could technically be different priorities/whatever. Any simple solution here or should I just change it to a mutex?
AtleoS has quit [Ping timeout: 264 seconds]
AtleoS has joined #rust-embedded
whitequark[cis] has joined #rust-embedded
<whitequark[cis]>
whats the bitfield crate that people use the most these days?