explore has quit [Quit: Connection closed for inactivity]
causal has quit [Quit: WeeChat 3.6]
<re_irc>
<jessebraham> Does anybody know what happened to "rust-analyzer" over the last few months that's made it so unusable? It seems like every week I have a new problem with it
<re_irc>
<newam> What frontend are you using for it?
<re_irc>
<newam> Though I do agree, has felt like it has gotten worse for embedded specifically.
<re_irc>
<jessebraham> I'm just using VSCode with the Rust Analyzer extension
<re_irc>
<jessebraham> Currently saving a file with format on save enabled takes like 15 seconds lol
<re_irc>
<newam> Whoa, mine hasn't been that bad, I've just had it stop working in the presence of too many macros.
<re_irc>
<jessebraham> Yeah normally I just have to restart it occasionally or set the odd configuration value, which doesn't bother me too much, but it's starting to get in the way of my work
<re_irc>
<newam> Can always roll it back to a version that worked
<cr1901>
agg: I'm just gonna level w/ ya... it's unlikely I will have any new progress to report re: the bloat. I have an MCVE, but have yet to make an issue, as I've been trying to upgrade all the msp430 crates and that takes time
<re_irc>
The author and readme are unchanged from thiserror (thus misleading), the source code is no longer part of any branch but still available from https://github.com/Stupremee/thiserror - but there is no documentation or explanation what happened to the idea - I checked that the code changes look benign.
<re_irc>
[Motivation: I am porting a crate which uses thiserror; for now displaydoc seems to be most futureproof solution]
rardiol has joined #rust-embedded
<re_irc>
<Mehmet Ali> Hi, I need an opinion on sth.
<re_irc>
pub struct Allocator <NF>
<re_irc>
So I have this struct that I want to manage NorFlashes with.
<re_irc>
<dirbaio> task args must be "'static" (ie live forever)
<re_irc>
<dirbaio> if you say "&mut" that means "a reference with *any* lifetime" which is not necessarily "'static"
<re_irc>
<dirbaio> if you say "&'static mut" that means "a reference with the "'static" lifetime"
<re_irc>
<dirbaio> to get a "&'static mut Allocator" you have to put the "Allocator" somewhere it'll actually live forever, a local variable in "main" won't cut it
<re_irc>
<dirbaio> you can do it with a "StaticCell" for example
<re_irc>
<dirbaio> also is there any particular reason you want to pass a reference? if not, it's probably easier to pass it by value: "async fn my_task(..., alloc: Allocator<Qspi<'static,QSPI,268435456>>)"
dc740 has joined #rust-embedded
<re_irc>
<Mehmet Ali> dirbaio: dirbaio: Argh now I get it.
<re_irc>
<Mehmet Ali> I have this notion that main is forever.
<re_irc>
<explodingwaffle101> i always thought it was a bit weird that lifetimes and references were interleaved. how come it’s like that
<re_irc>
<dirbaio> "main" can return before the child task returns
<re_irc>
<Mehmet Ali> dirbaio: Well, I would like one task to be able to write, but another only to read
<re_irc>
<dirbaio> when "main" returns all its local variables are destroyed
<re_irc>
<dirbaio> so you can't pass a reference to a "main" local variable to a task
<re_irc>
<Mehmet Ali> dirbaio: Ahh, so you actually return from main.
<re_irc>
<Mehmet Ali> executor.run () is not forever.
<re_irc>
<Mehmet Ali> * executor.run()
<re_irc>
<dirbaio> Mehmet Ali: ah well, you can return from "#[embassy::main]".
<re_irc>
the actual "main" ("#[cortex_m_rt::entry]" is actually noreturn: "fn main() -> !" so yes you _could_ consider local variables in "main" to live forever
<re_irc>
<dirbaio> but the compiler treats all local variables the same, ie they _don't_ live forever, even if the function is "-> !"
<re_irc>
<Mehmet Ali> explodingwaffle101: I think when not referenced, a lifetime is already defined. It is its scope. When borrowed, it becomes hairy?
<re_irc>
<dirbaio> you _can_ use "unsafe" to transmute a "&" pointing to a local variable in "main" to "&'static", that would be sound if "main" really never retursns
<re_irc>
<dirbaio> but it's unsafe, I recommend you use "StaticCell" instead
<re_irc>
<Mehmet Ali> dirbaio: Ah, thank you.
<re_irc>
<dirbaio> Mehmet Ali: ah then you'll need "&", not "&mut". because "&mut" won't allow you to share it
<re_irc>
<dirbaio> but it's the same thing, you need "&'static", not "&"
<re_irc>
<Mehmet Ali> dirbaio: I already use it, can use it one more time.
<re_irc>
<Mehmet Ali> dirbaio: Not "&'static mut"? Is it due to the fact that the task function does not explicitly mutate the struct, but the struct mutates itself through its methods.
<re_irc>
<dirbaio> you can't have two "&mut" to the same object at a time
<re_irc>
<Mehmet Ali> Oh, I meant one & and one &mut
<re_irc>
<Mehmet Ali> one reads, the other one writes.
<re_irc>
<dirbaio> you can have one "&mut" XOR many "&"
<re_irc>
<dirbaio> not "&mut + &mut", not "&mut + &"
<re_irc>
<Mehmet Ali> That might be also an issue, because a write can invalidate a read
<re_irc>
<Mehmet Ali> yep, thats correct.
<re_irc>
<dirbaio> the way to get around that is using "interior mutability"
<re_irc>
<Mehmet Ali> Therefore we need a Mutex, somehow.
<re_irc>
<Mehmet Ali> dirbaio: Oh what is that?
<re_irc>
<dirbaio> RefCell if you don't need to do async stuff with the inner guts
<re_irc>
<dirbaio> "embassy_sync::mutex::Mutex" if you do need to do async stuff
<re_irc>
<dirbaio> so even if you have just "&", you can lock the RefCell/Mutex and then get a "&mut" to the inner contents, but only one task at a time
<re_irc>
<dirbaio> the difference is RefCell panics if already locked, and the async Mutex waits
<re_irc>
<dirbaio> if you're going to do async reads/writes to the qspi flash then you want "Mutex"
<re_irc>
<Mehmet Ali> and ThreadModeMutex differs from embassy_sync::mutex::Mutex right?
<re_irc>
<dirbaio> ThreadModeMutex is a "blocking" mutex, you can't ".await" while holding it locked
<re_irc>
<Mehmet Ali> Okay, let me take a look at Mutex then
<re_irc>
<Mehmet Ali> But I already have these two tasks fully seperated through a mutex, therefore can use them both.
<re_irc>
<Mehmet Ali> Would StaticCell be required if I used a Mutex?
<re_irc>
<dirbaio> Mutex allows you to use a "&" instead of "&mut"
<re_irc>
StaticCell allows you to get a "&'static" (or "&'static mut") which you need if you want to share it across tasks
<re_irc>
<Mehmet Ali> e.g. I am using "ThreadModeMutex<RefCell<Option<[u8;BUF_SIZE]>>>"
<re_irc>
<Mehmet Ali> But it is defined as a static
<re_irc>
<dirbaio> depends on what you want to do, I have no idea
<re_irc>
<dirbaio> wasn't this about sharing a QSPI flash? 😅
neceve has joined #rust-embedded
<re_irc>
<Mehmet Ali> This one is, the "static xxx :ThreadModeMutex<RefCell<Option<[u8;BUF_SIZE]>>>" I used to share a bytearray across tasks.
<re_irc>
<dirbaio> ah if it's just data then the blocking mutex should work just fine, yes
<re_irc>
<Mehmet Ali> dirbaio: Sorry, I was carried away
<re_irc>
<Mehmet Ali> +(:
<re_irc>
<dirbaio> you can probably remove the Option even
<re_irc>
<Mehmet Ali> dirbaio: I would be relieved.
<re_irc>
<Mehmet Ali> Too many skins
<re_irc>
<Mehmet Ali> Wow, dirbaio you are a savior, thanks.
<re_irc>
<Mehmet Ali> I will get back to reading this stuff.
<re_irc>
<Mehmet Ali> Thanks for embassy, I will ship a proto with it this week.
<re_irc>
<Mehmet Ali> Will ping you
<re_irc>
<dirbaio> if you want to share the actual QSPI flash (not just plain old data like "[u8; N]")
<re_irc>
<dirbaio> then you'll want to do async operations with it, like "qspi.write(...).await;"
<re_irc>
<dirbaio> in that case you'll need the async mutex, instead of the blocking mutex
<re_irc>
<dirbaio> so that if one task is using the qspi, the other task will wait
<re_irc>
<Mehmet Ali> dirbaio: I will try that, but these two tasks never use it concurrently anyway.
<re_irc>
<Mehmet Ali> One is a "read from bluetooth" mode
<re_irc>
<Mehmet Ali> the other is a measurement mode.
<re_irc>
<Mehmet Ali> And I don't measure when BT is connected
<re_irc>
<Mehmet Ali> I mean, after BLE advertisement binds.
<re_irc>
<Mehmet Ali> but given that we have an async Mutex, one should use it.
<re_irc>
<dirbaio> if it's just data (ie you never do an .await while holding the mutex) then the blocking mutex will yield slightly smaller code
<re_irc>
<dirbaio> so in general it's a good idea to only use the async mutex if you actually need it
<re_irc>
<Mehmet Ali> The issue is that though we don't need it, it will lower the power consumption, right?
<re_irc>
<dirbaio> no, because if you don't .await while holding it you're not allowing the core to sleep anyway
<re_irc>
<dirbaio> if task A locks it, copies some data, unlocks it. then task B won't even get to run while task A has it locked
<re_irc>
<adamgreig> hi room, meeting time again! agenda is https://hackmd.io/Gd4CwNP-REG5lWAtcZwu3A, please add anything you'd like to announce or discuss and we'll start in ~5min
<re_irc>
<adamgreig> ok, let's start! I don't have any announcements for this week, anyone got anything?
<cr1901>
I have an MCVE, but haven't filed an issue yet
<cr1901>
I've decided to release msp430 0.4.0 w/ the bloat and work on things afterward
<cr1901>
because putting it off is making me unhappy
<re_irc>
<adamgreig> ah cool, sounds good
<re_irc>
<adamgreig> so msp430 at least _has_ c-s support, but the bloat needs resolving?
<cr1901>
yes
<re_irc>
<adamgreig> does it affect every cs or only the ones that have enough code inside that it duplicates the release?
<cr1901>
latter... not every cs
<cr1901>
but it
<cr1901>
that's enough to break size sensitive code
<cr1901>
Like 5% bloat on a real application (AT2XT)
<re_irc>
<adamgreig> weird that it didn't happen when calling msp430::interrupt::free
<re_irc>
<adamgreig> guess the extern thing must really throw it
<re_irc>
<adamgreig> anyway, thanks for continuing to dig into it and for getting msp430 0.4 with it sorted
<cr1901>
It's a combination of "extern" and "Rust does the wrong thing if acq/rel aren't in the same crate"
<cr1901>
(and #[inline] isn't specified)
<cr1901>
But since #[inline] is ignored w/ extern, the bad codegen stays
<re_irc>
<dirbaio> > #[inline] is ignored w/ extern
<re_irc>
<dirbaio> sounds like it should work with LTO at least, weird that it doesn't
<re_irc>
<adamgreig> isn't the problem that it is being inlined, twice?
<re_irc>
<adamgreig> I mean that previously acq/rel were in a different crate too (i.e. msp430, when being called from the application) but it didn't duplicate the release there
<re_irc>
<adamgreig> (admittedly I guess they were all just part of interrupt::free?)
<cr1901>
^this
<cr1901>
adamgreig: Yes, but interestingly enough, _not_ including #[inline] is what causes release to be duplicated
<re_irc>
<adamgreig> weird...
<cr1901>
I feel like "if good codegen is possible without extern and #[inline] as hints _internal to a single crate_, the same codegen should be possible w/ LTO across a second crate, regardless of "extern""
<cr1901>
regardless of "extern" or #[inline]*
<cr1901>
So I'll make an issue and see what happens. Note this affects Cortex-M too, but Cortex-M seems better at masking the problem
<cr1901>
(in that bloat is negligible w/ duplicated release)
<re_irc>
<adamgreig> everyone's too used to having huge flash storage on cortex-m :P
<cr1901>
don't get me started
<re_irc>
<adamgreig> sounds good anyway, thanks
<re_irc>
<adamgreig> hah
<re_irc>
<dirbaio> hehehe :D
<cr1901>
64kB is a HUGE amount of space
<cr1901>
It should be enough for everybody :)
<re_irc>
<adamgreig> don't you only get the first 48kB without the sort of PAE thing?
<cr1901>
(yes... shhh!)
<re_irc>
<adamgreig> each of the 48k hand-drawn fram cells, lol
<re_irc>
<adamgreig> aaanyway
<re_irc>
<adamgreig> any other announcements?
<re_irc>
<adamgreig> ok, otherwise a few e-h things from last week, first up is a new pr from reitermarkus about the std impl in the face of the std mutex getting poisoned, https://github.com/rust-embedded/critical-section/pull/26
<re_irc>
<dirbaio> LGTM I guess
<re_irc>
<dirbaio> I didn't think about this case when I wrote it at all, i'm just too used to thinking in panic=abort 🙈
<re_irc>
<dirbaio> I guess the downside is the same as mutex's poisoning itself: something panics midway of a state update, leaving inconsistent state visible to other threads
<re_irc>
<dirbaio> but you can't use that to cause UB (with Safe Rust)
<re_irc>
<adamgreig> might make it impossible to be sure you'll uphold invariants you need for unsafe stuff though?
<re_irc>
<dirbaio> yeah..? but that's the responsibility of the unsafe code
<re_irc>
<adamgreig> at least you still can't get two CSs at once, so..
<re_irc>
<dirbaio> like, unsafe writers must ensure the code doesn't panic midway. or if they call a user closure they should "catch_unwind" or "drop-guard" it
<re_irc>
<dirbaio> also, with Mutex you only poison _that_ particular mutex, vs with c-s you poison "the entire world"
<re_irc>
<dirbaio> so poisoning means the entire program's execution is broken because you can never take a CS again, so not very useful
<re_irc>
<jannic> Exactly - make CS do exactly one thing, guarantee that there is only one thread running inside a CS at any time.
<re_irc>
<dirbaio> I remember reading Rust people saying "poisoning" was a mistake, can't remember where
<re_irc>
<adamgreig> if anything panics in most no_std impls, it will also end the whole program execution, though?
<re_irc>
<adamgreig> like, no one using c-s is going to expect to or want to think about this weird detail of the std impl
<re_irc>
<dirbaio> yeah, the PR doesn't change the behavior with panic=abort
<re_irc>
<adamgreig> wonder if it will affect codegen either
<re_irc>
<adamgreig> I hadn't really clocked that it changes "with()" for everyone, not just std users
<re_irc>
<dirbaio> the non-panic path should be the same, after inlining everything
<re_irc>
<adamgreig> yea, hopefully, but it might be worth verifying on no-std I guess
<re_irc>
<adamgreig> dirbaio: I don't fully get this, which unsafe writers?
<re_irc>
<dirbaio> nice idea, because the compiler is clearly dumber than we think, as we've seen with msp430
<re_irc>
<dirbaio> adamgreig: if you write unsafe code that relies on c-s for soundness
<re_irc>
<dirbaio> if c-s says "unwinding out of a c-s is fine" then it's on _you_ to take that into account
<re_irc>
<dirbaio> either ensure such unwinding never happens, or if it does you leave everything in a "good" state
<re_irc>
<dirbaio> so yes, at the very least the behavior on unwind should be documented
<re_irc>
<adamgreig> yea, ok, and then it does seem like the better behaviour is to 1) ensure release is called on unwind and 2) for std impl, ignore the poison caused by a panic?
<re_irc>
<adamgreig> i guess the alternative is to leave the c-s locked after unwind
<re_irc>
<dirbaio> possible behaviors are:
<re_irc>
<dirbaio> 1. leave locked
<re_irc>
3. leave unlocked
<re_irc>
2. leave poisoned, so next lock panics
<re_irc>
<dirbaio> current behavior is 1, PR changes it to 3
<re_irc>
<dirbaio> IMO sanest is 3 yep
<re_irc>
<adamgreig> 2 only applies for the std impl though
<re_irc>
<dirbaio> 1. leave locked, so next lock deadlocks
<re_irc>
3. leave unlocked
<re_irc>
2. leave poisoned, so next lock panics
<re_irc>
<adamgreig> we get to choose whether the cs is left locked or not by having the drop guard, and separately whether the poison is ignored or not when attempting to lock in std
<re_irc>
<jannic> I think keeping it locked doesn't make much sense. If some "no_std" code does actually do unwind on panic (and catches it at some higher level), it for sure doesn't want to be locked for good next time it tries to enter a critical section.
<re_irc>
<adamgreig> yea
<re_irc>
<adamgreig> I guess in the usual embedded case the panic inside a c-s causes a whole program abort anyway
<re_irc>
<dirbaio> ah well there's a 4th option: don't specify what happens, leave it up to the impl
<re_irc>
<dirbaio> arguably current behavior is 4
<re_irc>
<adamgreig> hah
<re_irc>
<therealprof> DWIM, you just have to wish hardd enough. 😉
<re_irc>
<jannic> Yes, could be a good alternative in case the guard causes too bad code generation.
<re_irc>
<therealprof> * hard
<re_irc>
<jannic> (the 4th option... not DWIM)
<re_irc>
<dirbaio> okay, i'll write a small summary in the PR
<re_irc>
- we should check whether it causes dumb codegen
<re_irc>
- behavior should be documented in "with"
<re_irc>
- there's consensus that unwind behavior should be "leave unlocked" , but:
<re_irc>
<adamgreig> thanks, that sgtm
<re_irc>
<dirbaio> sounds good?
<re_irc>
<dirbaio> 👍️
<re_irc>
<adamgreig> should the general c-s docs also change, or is this just going to be localised to "with"? specifically the safety notes on "acquire"
<re_irc>
<dirbaio> hmm iiuc acquire/release stays the same
<re_irc>
<dirbaio> no semantics change there
<re_irc>
<dirbaio> actually, how did the MutexGuard even "know" the panic occured?
<re_irc>
<dirbaio> the std impl is storing it in a "static", so iiuc the behavior of the old code should be "leave locked", not "poison"?
<re_irc>
<adamgreig> right now acquire documents the safety contract, so if we want "unlock on unwind" to be something you can rely on, don't we also need to say this in acquire?
<re_irc>
<adamgreig> like, one doesn't have to use "with" or could write your own "with" calling "acquire"/"release"
<re_irc>
<dirbaio> adamgreig: it's "with" what catches the unwind
<re_irc>
<dirbaio> if you're using acquire/release directly, they can't catch the unwind
<re_irc>
<adamgreig> yea, but it would be "sound" for someone to write their own "with" that calls acq/rel and doesn't catch an unwind, but still provides a CriticalSection
<re_irc>
<jannic> The current contract on "acquire" already says it must be paired with a corresponding "release". Without the guard this contract could be violated (if two critical sections are nested and the inner one panics)
<re_irc>
<adamgreig> dirbaio: does that change it? the thread still has a MutexGuard and then starts to panic, which is what puts the poison in the mutex?
<re_irc>
<dirbaio> it's OK to never release a CS
<re_irc>
<dirbaio> you can do that with "with(|_| loop {})"
<re_irc>
<jannic> Yes, but then you won't call "release" on the outer CS.
<re_irc>
<adamgreig> so no change on the preconditions for acq/rel, only the notes for "with" specify its behaviour on unwinding?
<re_irc>
<dirbaio> perhaps the wording can be improved
<re_irc>
<dirbaio> I didn't intend it to mean "you MUST eventually release every acquire", more like "if you do, it must be properly paired/nested"
<re_irc>
<dirbaio> ie it's not OK to do "a = acquire(); b = acquire(); release(a)"
<re_irc>
<dirbaio> but it's still OK to do "a = acquire();" and then never "release()"
<re_irc>
<jannic> "with(|_| catch_unwind( || with( |_| panic!() ) )" is equivalent to "a = acquire(); b = acquire(); release(a) " if not using the guard.
<re_irc>
<dirbaio> aha
<re_irc>
<dirbaio> okay but that happens with the old "with" only, not with the fixed "with"
<re_irc>
<dirbaio> so actually the old "with" is unsound, yep 🤯
<re_irc>
<jannic> Exactly. :-)
<cr1901>
time for 1.2? :)
<re_irc>
<dirbaio> "1.1.1" :P
<cr1901>
ahh
<re_irc>
<dirbaio> adamgreig: so yes, this is unsound with panic=unwind
<re_irc>
<jannic> (do we have "catch_unwind" on "no_std"?)
<re_irc>
<dirbaio> I think catch_unwind with panic=abort is a noop? it'll never "catch" anything
<re_irc>
<dirbaio> oh it's not even in "core" huh
<re_irc>
<dirbaio> you can still build "std" programs with "panic=abort" though, in which case "catch_unwind" becomes a noop
<re_irc>
<adamgreig> cool, thanks for discussing :) hopefully codegen does not suffer lol
<re_irc>
<adamgreig> final quick point is about that splitting-nb PR on whether embedded-hal should be moved to a sub-dir, probably one for therealprof and eldruin to weigh in on?
<re_irc>
<adamgreig> in cortex-m land we just have /src and /cortex-m-rt/src and /cortex-m-semihosting/src and it's annoying, I would like to move to /cortex-m there too, but haven't yet
<re_irc>
<dirbaio> context: it was already discussed when we created "embedded-hal-async", the answer was "no"
<re_irc>
<dirbaio> but that's because EHA was supposed to be temporary, eventually folded into EH
<re_irc>
<dirbaio> but in the end seems the split is going to be forever, so i'd like to bring it up again
<re_irc>
<eldruin> e-h in a subdir would also be ok for me
<re_irc>
<adamgreig> and there's now a "forever" e-h-nb and e-c
<re_irc>
<therealprof> No opinion really, all options seem equally annoying to me.
<re_irc>
<dirbaio> subdirs is slightly more consistent, it helps simplifying the ci scripts a bit too
<re_irc>
<dirbaio> so you can do "cd $crate; cargo test"
<re_irc>
<dirbaio> with the split we're going to have _five_ crates in the repo
<re_irc>
<therealprof> Sounds good to me then.
<re_irc>
<eldruin> yep, agreed
<re_irc>
<therealprof> is there going to be workspace magic or just subdirs.
<re_irc>
<therealprof> * Is there going to be workspace magic or just subdirs?
<re_irc>
<dirbaio> imo just subdirs?
<re_irc>
<therealprof> Just asking.
<re_irc>
<dirbaio> workspaces sometimes do weird stuff unifying dep versions/features
<re_irc>
<therealprof> Indeed.
<cr1901>
does resolver=2 fix that or not?
<re_irc>
<dirbaio> no, resolver=2 just isolates deps from dev/build-deps
<re_irc>
<dirbaio> but workspaces still merge "all deps" and "all build/dev deps"
<cr1901>
ahhh, shared target/ is appealing to me, but I understand
<re_irc>
<dirbaio> this is probably not an issue for e-h though
<re_irc>
<therealprof> cr1901: Good ol' pro and cons. 😉
<re_irc>
<dirbaio> it's a big issue for repos containing actual firmwares for different targets for example
<re_irc>
<dirbaio> maybe i'll try adding a workspace, i'll commit it if it doesn't cause trouble
<cr1901>
>containing actual firmwares for different targets for example <-- IMO this is genuinely a use for mutually exclusive features where "the build completely fails if there's a conflict"
<cr1901>
put the logic in, pray that it's never triggered, and if it is, go from there
<re_irc>
<therealprof> dirbaio: Doesn't that need special magic for releasing?
<re_irc>
<dirbaio> seems a workspace in e-h works fine
<re_irc>
<dirbaio> * the e-h repo
<re_irc>
<dirbaio> and it's actually handy because you can then do "cargo test" etc to check all crates
<re_irc>
<dirbaio> +at once
rardiol has quit [Ping timeout: 252 seconds]
<re_irc>
<dirbaio> is there a way to exclude "embedded-hal-async" if not using nightly though?
<re_irc>
<newam> dirbaio: if you do find an answer for this I would also like to know.
<re_irc>
I have not found a solution I like when doing this for my crates.
<re_irc>
<dirbaio> :(
<re_irc>
<newam> The one I use the most is running "cargo test -p ..." then adding "if ${{ matrix.toolchain == "nightly" }}" to the crates that need nightly in CI.
<re_irc>
<newam> And adding aliases in ".config/cargo.toml" for "cargo test-stable" and "cargo test-nightly". Not great, but it works :/
<re_irc>
<newam> The one I use the most is running "cargo test -p ..." as individual steps in CI then adding "if ${{ matrix.toolchain == "nightly" }}" to the crates that need nightly in CI.
<re_irc>
<newam> The one I use the most is running "cargo test -p ..." as individual steps in CI then adding "if ${{ matrix.toolchain == "nightly" }}" to the crates that need nightly.
<re_irc>
<dirbaio> - run: sed -i '/nightly-only/d' Cargo.toml
<re_irc>
<newam> yeah, IIRC if you add "--deny-warnings" then it will never annotate because it assume the process must pass to annotate.
<re_irc>
<newam> That one was also a fork though, so it failed to annotate
<re_irc>
<dirbaio> ugh why are annotations so broken?
<re_irc>
<dirbaio> the permission issues are stupid
<re_irc>
<dirbaio> a PR from a fork should still be able to annotate itself, without "pull_request_target"
<re_irc>
<newam> github actions was made rather quickly as a response to gitlab pipelines, there's a lot of rough edges outside of the base features
<re_irc>
<dirbaio> GHA Is absolute hot garbage
<re_irc>
<dirbaio> only reason to use it is it's integrated and free 😂
<re_irc>
<newam> dirbaio: I reserve this title for travis CI after they got aquired
<re_irc>
<dirbaio> lol
<re_irc>
<newam> Is there any good CI system out there at all though?
<re_irc>
Tried many, some come close, but nothing ever has it all.
<re_irc>
<newam> Most things are still stuck in the jenkins era without synchronization between build jobs and the repository ☠️
<re_irc>
<chemicstry> maybe gitlab CI? they usually have everything better and cheaper than github to keep up the competition
<re_irc>
<dirbaio> caching sucks too
<re_irc>
<dirbaio> it's just doing compress/decompress/upload/download huge tarballs
<re_irc>
<dirbaio> gitlab's feels much more polished than github yup
<re_irc>
<newam> chemicstry: 🤔 yeah, they are one of the better ones.
<re_irc>
I think my problem is just that everything is trending towards reproducibility & sameness between environments, which is good, but leaves large deployments of hardware-in-the-loop runners without necessary features (e.g. re-running a job of a specific runner because it shows different results than others)
<re_irc>
<newam> * on
<re_irc>
<newam> I really liked concourse-ci as well, but they require everything to be containerized which makes embedded testing _really_ hard.
<re_irc>
<dirbaio> Drone is nice too, though it has grown a bit bloated and is now non-free
<re_irc>
<newam> I also wish so many CI products would stop using YAML and use a non-turning complete language instead, e.g. jsonette, nickel.
<re_irc>
it leads to a ton of different DSLs for DRY which really could be avoided by not using YAML
<re_irc>
<dirbaio> whew, embedded-hal CI green
<re_irc>
<dirbaio> all that's left is cleaning up the READMEs
<re_irc>
<dngrs (spookyvision@github)> M4f and upwards
<re_irc>
<adamgreig> relocations aren't supported so basically you just build against a memory map with just some ram at a fixed location, and your loader just reads the whole image into that ram and jumps into it
<re_irc>
<adamgreig> you could partition it into some ro and rw ram and use the mpu on m4-and-up to prevent write access to code i guess
<re_irc>
<adamgreig> and you could use the privileged/unprivileged modes to have a supervisor that controls more hardware access
<re_irc>
<adamgreig> depends if you want to write an os or not though...
<re_irc>
<dngrs (spookyvision@github)> ok so maybe clarification: I don't want a boot loader, I want to change an impl at runtime. No HW access required for the dynamic code, it's just going to do some math
<re_irc>
<adamgreig> if you want to load compiled machine code and run it, it looks just like a bootloader if you squint
<re_irc>
<dngrs (spookyvision@github)> (if "an impl" isn't "dyn Foo" but "extern "C"" I'm fine with that)
<re_irc>
<adamgreig> you could do something interpreted rather than compiled, then it's a case of having an interpreter and reading some source
<re_irc>
<dngrs (spookyvision@github)> yeah, I'm specifically musing about optimizing the interpreter case
<re_irc>
<dngrs (spookyvision@github)> I'll build the interpreter first
<re_irc>
<adamgreig> if you got more hardcore you could also write your own relocator and read an elf or some kind of elf-lite format to make up for the compiler not supporting dynamic relocation
<re_irc>
<dngrs (spookyvision@github)> so essentially I prepare a linker section and just change what's there by writing to this addr?
<re_irc>
<adamgreig> that's pretty much it, yea
<re_irc>
<dngrs (spookyvision@github)> ok that sounds rather straightforward!
<re_irc>
<dngrs (spookyvision@github)> only caveat is not overshooting the section I guess
<re_irc>
<dngrs (spookyvision@github)> and change the contents in a "free"
<re_irc>
<adamgreig> reserve some fixed block of ram in the linker script, for the loadable code you have just that section in memory.x with code/data all put into it
<re_irc>
<dngrs (spookyvision@github)> and what would be the most straightforward way to get the actual chunk o' instructions? (let's assume my dynamic code might also call out to functions that are defined by the "host" program)
<re_irc>
<adamgreig> calling back into the host program ramps up the complexity a bit
<re_irc>
<dngrs (spookyvision@github)> I was afraid you'd say that
<re_irc>
<adamgreig> for generating the binary the gist is you just want a linker script that dumps everything into your own section, and no cortex-m-rt or anything like that
<re_irc>
<adamgreig> (they are snippets of compiled rust code that probe-rs will load into ram on the target and execute, used to actually write data to the target flash)
<re_irc>
<dngrs (spookyvision@github)> oh that's nifty, I might be interested in that for other reasons too
<re_irc>
<dngrs (spookyvision@github)> and for calling back into host I suppose I'll have to do some runtime linking myself?
<re_irc>
<adamgreig> there's a few options, I think one common choice is a table of function pointers that the host program can put in a fixed location and the client program can read and call
<re_irc>
<adamgreig> a bit like the function pointer block in the rp2040 rom
<re_irc>
<dngrs (spookyvision@github)> any prior art I can ~rip off~ use as inspiration?
<re_irc>
<dngrs (spookyvision@github)> the set of functions is gonna be fixed and not huge so preparing a table sounds solid