<NiaLinaLunaStorm>
<adamgreig[m]> "it will also tell you how much..." <- I can't figure out how I get it to show the ram usage
<adamgreig[m]>
in the default output of cargo size, text+data is what gets written to flash, and bss is the size of statically allocated memory that's also initialised to zero... in my recollection it also shows total static allocation but perhaps not by default. use cargo size --release -- -A to show in the alternate format where you'll get a size for each section: vector_table+text+rodata+data go to flash, data+bss+uninit are
<adamgreig[m]>
statically allocated in ram
<NiaLinaLunaStorm>
thanks for exmplaining
sugoi has quit [Ping timeout: 246 seconds]
majors has quit [Quit: ZNC 1.8.2+deb2ubuntu0.1 - https://znc.in]
majors has joined #rust-embedded
dnm has quit [Ping timeout: 245 seconds]
dnm has joined #rust-embedded
<jonored>
I've had code measuring "peak stack" given a non-recursive program before, which can get you there as well but has program organization implications.
<jonored>
https://github.com/obsidiansystems/stack-sizes/tree/canary-check-llvm-17 seems to be one of the more recent branches of it since I parted ways with obsidian. It's not a polished tool for the job but _would_ be a decent starting point of getting something that works, if your call tree is shaped right.
starblue has quit [Ping timeout: 246 seconds]
starblue has joined #rust-embedded
Amanieu has quit [Quit: No Ping reply in 180 seconds.]
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
korken89[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]1>
I fixed Bare Metal SPARC (which has a very small but growing user base for space things) but might have broken Rust on Linux on 32-bit SPARC - a machine they haven’t made in 30 years.
<roklobsta[m]>
Is that the sparc on a diamond or ruby substrate?
starblue has quit [Ping timeout: 255 seconds]
starblue has joined #rust-embedded
m5zs7k has quit [Quit: m5zs7k]
m5zs7k has joined #rust-embedded
Artea has quit [Remote host closed the connection]
dinkelhacker_ has joined #rust-embedded
sugoi has joined #rust-embedded
sugoi has quit [Ping timeout: 245 seconds]
cajt[m] has joined #rust-embedded
<cajt[m]>
.... but my old sparcstation2, oh no (jk!)
sugoi has joined #rust-embedded
sugoi has quit [Ping timeout: 246 seconds]
sugoi has joined #rust-embedded
sugoi has quit [Ping timeout: 255 seconds]
dinkelhacker_ has quit [Quit: Client closed]
cinemaSundays has quit [Quit: Connection closed for inactivity]
<jannic[m]>
Breaking because of the MSRV bump, or is the change itself somehow breaking?
<adamgreig[m]>
not worried about the msrv bump especially
<adamgreig[m]>
admittedly it's targetting cortex-m master branch which is already a nominal 0.8 breaking release so in that sense not a problem
<adamgreig[m]>
perhaps better to merge it and then worry about whether it comes as 0.7.x or a new 0.8
<adamgreig[m]>
i'm sure the new behaviour is correct at least (though i don't know if the new version of vect_active() with unchecked_unsafe is necessarily better than the match statement?)
<adamgreig[m]>
hmm no I see, it is an improvement
<jannic[m]>
Well in some sense every bugfix is a breaking change. That doesn't keep us from doing bugfix versions.
<adamgreig[m]>
adamgreig[m]: oh, I misread, it's not, it does target 0.7 as a backport
<adamgreig[m]>
ok, I think it's fine and it's already approved, let's get it in
<adamgreig[m]>
thanks for triage :D we'll need to get a c-m 0.7 and c-m-rt release out soon
<adamgreig[m]>
I guess it was literally a new feature, heh
<adamgreig[m]>
I think strictly speaking it's right, though i'm surprised it caused an actual problem
<jannic[m]>
That's the curse with all these 0.x.y versions: We are not used to having a separate patch version.
<therealprof[m]>
adamgreig[m]: Well, if someone uses the feature and someone else has the older version pinned...
<jannic[m]>
I'd say yes, it should have been a minor version bump. But fixing this now (yanking this version and rereleasing with a new number) would cause even more problems.
<rmsyn[m]>
that is strange, I'm not sure what they mean by going "down". afaiu, minor bumps are only required for removing / changing existing APIs, not adding to them
<therealprof[m]>
therealprof[m]: It is a bit weird though if one colleagues uses a new feature and the repo is shared with another colleague and they's no shared Cargo.lock... I mean, that creates weird problems all the time and one should be prepared to fix them.
<jannic[m]>
(But traditional SemVer obviously does.)
eldruin[m] has joined #rust-embedded
<eldruin[m]>
think they had critical-section="1.1.2" in a common cargo.toml. Then somebody started using something from 1.1.3, as they had that version due to cargo update, etc. Then the other person tried to compile but had not done cargo update and that failed because of the 1.1.2 local version
<eldruin[m]>
* I think
<adamgreig[m]>
good link, thanks
<adamgreig[m]>
so that classifies a new feature as a minor change and suggests minor changes should typically be a semver minor release, but sometimes are a patch release
<rmsyn[m]>
how is that an issue, to get the new version (minor or patch) they have to specify either way. is there a part of the semantic versioning spec that defines new APIs must be introduced in a minor version release?
whitequark[cis] has joined #rust-embedded
<adamgreig[m]>
rmsyn[m]: yea, semver says patch release is for bug fixes only, new features being added causes a minor release
<eldruin[m]>
yeah, I'm not very convinced we should yank 1.1.3 due to the breaking. we should release 1.2.0, though.
<adamgreig[m]>
yea, I also don't think yanking it will help anyone
<therealprof[m]>
eldruin[m]: Yanking means nothing for people refusing to update their dependencies anyway.
<adamgreig[m]>
so re-release as 1.2.0?
<eldruin[m]>
therealprof[m]: sure, you would get a warning, though, right?
<jannic[m]>
Does releasing a 1.2.0 really provide some advantage?
<therealprof[m]>
Nope, because you wouldn't even detect the problem.
sugoi has joined #rust-embedded
<andar1an[m]1>
If there was a locked crate you may see yank
<dirbaio[m]>
<eldruin[m]> " think they had critical-section..." <- this scenario would also have happened with 1.1.2 vs 1.2.0
<eldruin[m]>
jannic[m]: just correctness
<adamgreig[m]>
jannic: it prevents the problem the issue reporter had from re-occuring
<andar1an[m]1>
But i don't think that affects this context
<adamgreig[m]>
s/occuring/occurring/
<dirbaio[m]>
I honestly can't think any scenario where releasing this as 1.1.3 vs 1.2.0 would've changed the outcome
<dirbaio[m]>
Cargo treats minor and patch updates the exact same
<jannic[m]>
adamgreig[m]: Wouldn't that require yanking?
<eldruin[m]>
dirbaio[m]: depending on the dep specification. if you write =1.1.2 it will update to 1.1.x but not 1.2.0 IIRC
kenny1 has quit [Ping timeout: 252 seconds]
<dirbaio[m]>
why would you write =1.1.2
<adamgreig[m]>
jannic[m]: ah, well, true. the exact scenario could repeat. I was imagining someone updating their cargo.toml to 1.2 to use the new feature, and then their colleague would have got the update, but... it's true that they could just use 1.1.3 still
<eldruin[m]>
dirbaio[m]: why would that be a problem?
<jannic[m]>
=1.1.2 wouldn't allow any update. I think it should be ~1.1. But nobody uses that.
<adamgreig[m]>
dirbaio[m]: in other words, when the person using the new feature ran cargo update, they'd be on 1.2 even though their cargo.toml says 1.1, and their colleague who hasn't run cargo update would therefore have a broken build?
<dirbaio[m]>
adamgreig[m]: exactly
<dirbaio[m]>
I can't think of any normal usage scenario where this "release new feature in patch version" could've caused an issue
<eldruin[m]>
Sorry I was not being clear enough: critical-section="1.1.2" will update to 1.1.x with x>=2 but not 1.2.x
<andar1an[m]1>
Isn't that desired?
<dirbaio[m]>
eldruin[m]: no, it will update to 1.2
<dirbaio[m]>
it won't update to 2.x
<eldruin[m]>
dirbaio[m]: True, I just checked. sorry for mixing them up
<adamgreig[m]>
yea, critical-section="1.1.2" is the same as critical-section="^1.1.2" which is "anything semver-compatible with 1.0.0 and at least 1.1.2"
<andar1an[m]1>
dirbaio[m]: Traceability?
<therealprof[m]>
I've recently had a lot of other breakage as well in other crates. That's a life risk if you don't use Cargo.lock. Technically it's correct to complain about it but a) it's impossible to fix after the fact and b) by not using Cargo.lock you're opting into being willing to fix issues arising from it yourself.
<adamgreig[m]>
so basically... it makes no real difference if this is a patch or minor release, the same problem would happen either way, and so there's no benefit from releasing 1.2.0?
<dirbaio[m]>
adamgreig[m]: yep that's my opinion
<dirbaio[m]>
imo that issue is a non-issue
<adamgreig[m]>
except that technically, we did add a feature, and we say it follows semver, which says to do a minor release with new features
<jannic[m]>
So in the end, even doing the correct thing and releasing it as 1.2.0 wouldn't actually help. Yes, it would be more correct. But it wouldn't have avoided the situation described in the ticket.
<dirbaio[m]>
semver minor vs patch is just about communicating expectations to humans
<dirbaio[m]>
cargo doesn't use it for anything
<eldruin[m]>
adamgreig[m]: just correctness according to the guide
<adamgreig[m]>
so we should have, but it's maybe not worth going back to fix it
<dirbaio[m]>
so imo we should just close the issue with "you're right this should've been a minor bump, we'll do better next time sorry"
<dirbaio[m]>
yep
<therealprof[m]>
dirbaio[m]: Agree.
<adamgreig[m]>
sgtm
<andar1an[m]1>
Why can't you just bump minor and make a note that it matches patch release? Is it complicated?
<therealprof[m]>
andar1an[m]1: It doesn't fix the problem for the reporter.
<dirbaio[m]>
effort
<adamgreig[m]>
it's easy to do, but it won't solve anything for anyone, so it's not clear there's much point going back to do it
<adamgreig[m]>
I already have the PR ready to submit if anyone really wants it, lol
<andar1an[m]1>
The only reason I would imagine is traceability. If there is a bug down the line and you are looking for a feature that was added, will it be tedious to see this? Or because cargo doesnt care it doesn't matter?
<adamgreig[m]>
you'll have to look through the changelog anyway, so this would only make it noisier I think
<adamgreig[m]>
it wouldn't change what versions cargo will select
<adamgreig[m]>
of course we'll have to keep our existing error traits, so this basically extends the existing "impl error on std" feature to core as well
<whitequark[cis]>
i feel like that is worth having a breaking change
<whitequark[cis]>
but from what i understand there's been some fatigue about rust-embedded breaking changes
<whitequark[cis]>
(maybe after Read and Write end up having core variants?)
<eldruin[m]>
adamgreig[m]: fresh out of the oven :) PR sgtm
<adamgreig[m]>
Read/Write would go into embedded-io rather than embedded-hal now, I think
<adamgreig[m]>
there's no way we'll do embedded-hal 2.0 over getting core::Error though
<adamgreig[m]>
it took almost the entire lifetime of embedded rust to get to 1.0
<therealprof[m]>
Not sure where the conclusion that a MSRV jump of that magnitude to the latest and greatest would be okay comes from. 😅
<adamgreig[m]>
therealprof[m]: the policy is "latest stable is fine", so I think that's what they're going off
<eldruin[m]>
we do not need to make a release immediately
<eldruin[m]>
maybe by the time we do the release 1.81 is stable -1 or -2
<dirbaio[m]>
my question is, what use cases does the Error trait enable for e-h
<dirbaio[m]>
typically when writing drivers you either inspect the errorkind and match on it, or you return the errors up
<eldruin[m]>
exactly, not much, that's why a new release is not very pressing
<dirbaio[m]>
so what does Error bring?
<adamgreig[m]>
I think if we were writing it now you'd naturally impl Error because it's there and it makes sense semantically, though?
<dirbaio[m]>
there's the `fn source() -> &dyn Error` thing, but `dyn` is terrible for embedded
<eldruin[m]>
I think it just brings general alignment with the rest of the ecosystem
<dirbaio[m]>
and I'm not sure what marking a struct as "yep this is an error" without implementing any methods like source helps for
<dirbaio[m]>
* and I'm not sure what's the benefit of marking a struct as "yep this is an error" without implementing any methods like source
<dirbaio[m]>
you can't even return "any error" without alloc
<dirbaio[m]>
so it's not like in std where you careleslly fling `Box<dyn Error>`s around
<adamgreig[m]>
so I'm not completely sure for ErrorKind if it's "an error" as such
<adamgreig[m]>
but for all the other error types, we already did impl std::error::Error when std was enabled
<adamgreig[m]>
if nothing else it's nice to remove the cfg gate and always impl core::error::Error there, right?
<dirbaio[m]>
also these impls should return the inner E as source()
<dirbaio[m]>
but only if E: Error, which is only possible with specialization...
<therealprof[m]>
Well, there's more features like downcasting...
<therealprof[m]>
I think it's a very exciting and cool feature (like everything else that moved from std into core).
<therealprof[m]>
Would have been nice if it had been available for e-h 1.0.
<adamgreig[m]>
does it make sense to have on ErrorKind?
<dirbaio[m]>
we're already implementing our own Error traits for ErrorKind
<dirbaio[m]>
for lazy hals that want to use the ErrorKind enum as-is for errors instead of defining their own
<dirbaio[m]>
so probably yes
<adamgreig[m]>
ah fair, yea ok
<dirbaio[m]>
to be clear I'm not opposed to #630
<dirbaio[m]>
imo if we add support for Error that's the best way to do it
<dirbaio[m]>
(the other PR with dyn is weird)
<dirbaio[m]>
I just don't get the excitement :D
<adamgreig[m]>
years of waiting for error to be usable in core and it suddenly happens without much fanfare, I think
<adamgreig[m]>
so verdict is merge it or wait another week and see?
<adamgreig[m]>
it's not pressing to release it, especially with the version bump, but does it need to be different/is there a reason not to have it?
<dirbaio[m]>
i'd just merge, what benefit do we get from waiting?
<adamgreig[m]>
s/version/msrv/
<adamgreig[m]>
none, if everyone's happy with this implementation then it would just be to let people think on it a bit longer, no need to wait
<adamgreig[m]>
OK, i'll let the hal team make the call anyway, thanks for the discussions!
<adamgreig[m]>
the final issue is I won't be here or running the next 3 meetings
<adamgreig[m]>
just checked last week, james said he could probably help with the 24th and 1st, but he's away next week
<adamgreig[m]>
so if anyone would like to run the meeting next week please shout, otherwise we can have a week off :P
<jannic[m]>
I'm sure we can do a meeting without you, but a week off wouldn't hurt either :-)
<adamgreig[m]>
I guess I'll leave it to you!
<adamgreig[m]>
ok, thanks everyone, see you in four weeks 😎
<jannic[m]>
I think bartmassey said he could run the meeting on 17ths.
<adamgreig[m]>
I mean I'll still be here, just not in meeting times
<bartmassey[m]>
I can take it if no one more qualified steps up. Almost everyone is more qualified😀
<jannic[m]>
I'll be there and try to bring a few tickets that can be closed.
sugoi has quit [Ping timeout: 248 seconds]
<therealprof[m]>
adamgreig: I'll be just lurking for a bit longer, still drowning in paperwork and the readjustment of family life to the new situation.
<adamgreig[m]>
no worries!
<adamgreig[m]>
good to see you back a bit :)
sugoi has joined #rust-embedded
sugoi has quit [Ping timeout: 246 seconds]
sugoi has joined #rust-embedded
chrysn[m] has joined #rust-embedded
<chrysn[m]>
Sorry for the semver thing – I was the one asking for the release as 1.1.3, well aware that this was a feature addition but unaware that Cargo will go down patch levels.
<chrysn[m]>
Gotta gather a bit more experience with post-0.x crates, gotta stabilize my stuff (and if it breaks I can still do a 2.x and 3.x and 128.x *mad laught* – jk, trying to release responsibly)
<chrysn[m]>
s/(/… /, s/*/\*/, s/*/\*/
sugoi has quit [Remote host closed the connection]
<Sam[m]12>
(I'm ready to do what's needed to get it merged if there is something missing of course, but I have received no feedback at all)
* thejpster[m]1
waves from Montreal
<thejpster[m]1>
I have Neotrons with me if you want to see one
sugoi has quit [Ping timeout: 246 seconds]
GrantM11235[m] has quit [Quit: Idle timeout reached: 172800s]
sugoi has joined #rust-embedded
<andar1an[m]1>
<thejpster[m]1> "I have Neotrons with me if you..." <- What are these?
<thejpster[m]1>
Computers I made. I’m talking about them on Thursday.
<roklobsta[m]>
How's your French?
<andar1an[m]1>
I didn't see you were speaking - the schedule seems to have changed. So excited now
<andar1an[m]1>
Apparently there were some visa issues? I think before there were more embedded talks
nandnor[m] has quit [Quit: Idle timeout reached: 172800s]
<andar1an[m]1>
Surrealdb doesn't seem to be there anymore either
newam[m] has quit [Quit: Idle timeout reached: 172800s]
<andar1an[m]1>
Nvm, still seems to be a bunch of embedded related, cool
merayen has quit [Ping timeout: 252 seconds]
merayen has joined #rust-embedded
sugoi has quit [Remote host closed the connection]
sugoi has joined #rust-embedded
sugoi has quit [Ping timeout: 255 seconds]
sugoi1 has joined #rust-embedded
sugoi1 is now known as sugoi
sugoi1 has joined #rust-embedded
sugoi has quit [Ping timeout: 246 seconds]
sugoi1 is now known as sugoi
SeanWykes[m] has joined #rust-embedded
<SeanWykes[m]>
Hi, rust embedded newbie here .. trying to get my head around rust for Pi Pico .. is this somewhere I can ask a few newbie questions .. or can somebody suggest a suitable forum?
<SeanWykes[m]>
Hi, rust embedded newbie here .. trying to get my head around rust for Pi Pico .. is this somewhere I can ask a few newbie questions .. or can somebody suggest a suitable forum?
d3zd3z[m] has joined #rust-embedded
<d3zd3z[m]>
Just got setup with the Rustconf server (attending remotely).
sugoi1 has joined #rust-embedded
sugoi has quit [Ping timeout: 245 seconds]
sugoi1 is now known as sugoi
jduck[m] has joined #rust-embedded
<jduck[m]>
<d3zd3z[m]> "Just got setup with the Rustconf..." <- Do you have a pointer for how to do that? The site for the conference seems like it's really struggling
<jduck[m]>
<SeanWykes[m]> "Hi, rust embedded newbie here ....." <- rp-rs is a good place imho
<d3zd3z[m]>
<jduck[m]> "Do you have a pointer for how to..." <- I got an email from rustconf with a link to the discord server (two in fact).