<re_irc>
<@gussius:matrix.org> Hi All, I am using "defmt:: debug!(...)" for some nice output, but is there a way to ignore the call location of each output?
mrtazz has quit [Read error: Connection reset by peer]
mrtazz_ is now known as mrtazz
crabbedhaloablut has quit [Ping timeout: 240 seconds]
crabbedhaloablut has joined #rust-embedded
duderonomy has joined #rust-embedded
DisconSented has joined #rust-embedded
<re_irc>
<@thejpster:matrix.org> probe-run is deliberately a tool with strong opinions. It is a spork, not a Swiss Army Knife, designed to be easy to get started with and Just Work. If you look at the help text, there is an option for producing JSON output instead of text output. You can then do whatever you like with the output. If we tried to accommodate every need or wish within probe-run it would quickly become an big unmanageable thing.
<re_irc>
<@thejpster:matrix.org> You can probably also do something with probe-rs-cli and pipe the RTT output into defmt-print and then on to wherever you wish.
duderonomy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
duderonomy has joined #rust-embedded
duderonomy has quit [Client Quit]
duderonomy has joined #rust-embedded
duderonomy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Foxyloxy_ has quit [Read error: Connection reset by peer]
Foxyloxy has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
duderonomy has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> > Probe run is... designed to be easy to get started with and Just Work.
<re_irc>
And there, they're done something no C compiler or toolchain has accomplished
<re_irc>
<@fuse117:matrix.org> how does the above compile?
<re_irc>
<@fuse117:matrix.org> runtime error. index out of bounds. i would think the compiler could easily catch this.
<re_irc>
<@jamesmunns:beeper.com> normal usage like that is typically fine, it's probably the rprintln macro making things a slice (by taking a reference), which confuses the compiler enough that it misses this.
<re_irc>
<@jamesmunns:beeper.com> regular println does catch this, so maybe there is something that rprintln could change to fix this
<re_irc>
<@jamesmunns:beeper.com> If I had to guess, somehow the rprintln macro is going from "[u8; 1] -> &[u8]" instead of "[u8; 1] -> &[u8; 1]" when taking a reference, the former can't be compile time checked (easily)
starblue1 has quit [Ping timeout: 260 seconds]
<re_irc>
<@jamesmunns:beeper.com> It's the fact that it's in an async function
<re_irc>
<@dirbaio:matrix.org> in settings -> branches -> master
<re_irc>
<@dirbaio:matrix.org> in "Require status checks to pass before merging" remove "bors", add the 11 existing checks
<re_irc>
<@dirbaio:matrix.org> and then enable "Require merge queue"
<re_irc>
<@dirbaio:matrix.org> defaults are fine
<re_irc>
<@dirbaio:matrix.org> (also why don't I have premissions as a HAL team member? who has?)
<re_irc>
<@adamgreig:matrix.org> @room meeting time again! agenda coming as soon as hackmd lets me log in, we'll start in a few mins
<re_irc>
<@adamgreig:matrix.org> : done, and HAL team also now has settings access
<re_irc>
<@thejpster:matrix.org> : can you, or another team lead, drop by #t-launching-pad on Zulip? We're trying to organise a first meeting on the team that's not a team.
<re_irc>
<@adamgreig:matrix.org> sure
<re_irc>
<@adamgreig:matrix.org> is anyone else able to log in at https://hackmd.io/login ? my work desktop's not logged in to hackmd but their recaptcha box says "error for site owner: invalid key type"
<re_irc>
<@adamgreig:matrix.org> which doesn't bode well, lol
<re_irc>
<@therealprof:matrix.org> Same.
<re_irc>
<@adamgreig:matrix.org> oh well, no hackmd for this meeting I guess! I'll see if I can fill it in retrospectively from my home computer later
<re_irc>
<@adamgreig:matrix.org> let's start then, does anyone have any announcements?
<re_irc>
<@jannic:matrix.org> Login to hackmd with github works for me.
<re_irc>
<@adamgreig:matrix.org> unfortunately my hackmd account is by email rather than sso
<re_irc>
<@jannic:matrix.org> Does it help if I share an empty document? I know next to nothing about hackmd.
<re_irc>
<@adamgreig:matrix.org> sure, I guess that works, could you set it so anyone can edit?
<re_irc>
<@thejpster:matrix.org> I will be working on t-launching-pad things with your fellow not-teams.
<re_irc>
<@therealprof:matrix.org> : overruled!
<re_irc>
<@adamgreig:matrix.org> nice, good luck !
<re_irc>
- This Week in Rust
<re_irc>
- community (and sub-groups)
<re_irc>
<@thejpster:matrix.org> You are in with:
<re_irc>
- wg-cli
<re_irc>
- wg-async
<re_irc>
- wg-gamedev
<re_irc>
- wg-embedded (and sub-groups)
<re_irc>
- wg-rust-by-example
<re_irc>
- wg-secure-code
<re_irc>
- wg-security-response
<re_irc>
- wg-wasm
<re_irc>
<@adamgreig:matrix.org> first up then, bors has been not responding to a few PRs now, I don't think this is an official change in bors policy so much as a temporary issue but nevertheless a good reason to accelerate moving to GHMQ
<re_irc>
<@adamgreig:matrix.org> oh oops, I tried to leave a comment on that earlier today and I guess didn't actually click leave review as it was still pending
<re_irc>
<@adamgreig:matrix.org> I don't think we need to mention gh-readonly-queue in our gha files for this, unless anyone knows otherwise
<re_irc>
<@adamgreig:matrix.org> I have now enabled ghmq for embedded-hal, but it's worth noting we'll need to update the github repo settings when the msrv changes as it changes the name of the required status check
duderonomy_ has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> OK, I guess there's been no updates on the book translations issue this week
<re_irc>
<@diondokter:matrix.org> I used 2023-06-09
<re_irc>
<@diondokter:matrix.org> Ok, I now know everything I need
<re_irc>
<@therealprof:matrix.org> nightly 🤷♂️
<re_irc>
<@jannic:matrix.org> Also succeeds with "cargo 1.72.0-nightly (0c14026aa 2023-06-14)". Strange. But I think we don't need to solve that during the meeting.
<re_irc>
<@adamgreig:matrix.org> cool, thanks for investigating!
<re_irc>
<@adamgreig:matrix.org> ok, next up is the svd2rust steal() business
<re_irc>
<@adamgreig:matrix.org> we did hear back from japaric about why steal() sets DEVICE_PERIPHERALS, namely that it allows rtic to use steal() and then be sure no one can safely use take() afterwards
<re_irc>
<@adamgreig:matrix.org> it's not documented behaviour but it is relied on for some level of soundness in rtic, so it might be worth keeping?
<re_irc>
<@diondokter:matrix.org> : _newest nightly works as well. Whatever it was, it's probably fixed_
<re_irc>
<@adamgreig:matrix.org> in terms of per-peripheral steal(), I guess in some sense there's the same concern - if one library steal()s a single peripheral, and then later the user uses take() and thinks they have the only copy of the peripheral, you could get into trouble...
<re_irc>
<@thejpster:matrix.org> yeah, it looks like stealing anything should break a subsequent take()
<re_irc>
<@thejpster:matrix.org> safely doing a take() but not obtaining ownership seems bad, if you are relying on ownership (cue people saying we should have ownership for PAC objects...)
<re_irc>
<@thejpster:matrix.org> +not
<re_irc>
<@adamgreig:matrix.org> well, the problem is that anyone could just as unsafely use transmute() to get a peripheral, or use a totally different PAC that doesn't use DEVICE_PERIPHERALS
<re_irc>
<@adamgreig:matrix.org> so the guarantee that when you take() you have the only copy is already pretty broken, I think
<re_irc>
<@thejpster:matrix.org> is steal unsafe?
<re_irc>
<@adamgreig:matrix.org> it seems more like rtic should have used take() from the beginning to set the flag
<re_irc>
<@adamgreig:matrix.org> yes
<re_irc>
<@adamgreig:matrix.org> (the only reason rtic doesn't, I believe, is to avoid the overhead of unwrapping, since it "knows" it can't fail since it's running before the user code)
<re_irc>
<@thejpster:matrix.org> but we have &mut and you can break an &mut by transmuting a new one. Any abstraction can only operate if you assume people follow the rules.
<re_irc>
<@jannic:matrix.org> I'd say it's the responsibility of the code doing the "unsafe" steal call to make sure that nobody else gets hurt?
<re_irc>
<@jamesmunns:beeper.com> "SAFETY: if you use steal, you must never use take" boom ship it
<re_irc>
<@jamesmunns:beeper.com> ("/s", btw)
<re_irc>
<@adamgreig:matrix.org> that's more restrictive than we need though, you just can't access the same registers at the same time. or you can because it's not UB but it would probably lead to logic errors.
<re_irc>
<@jannic:matrix.org> Well or only steal in a critical section and make sure you don't keep it.
<re_irc>
<@adamgreig:matrix.org> : this is right, but that code doesn't have any obvious way to ensure that
<re_irc>
<@jamesmunns:beeper.com> but honestly, we could add a "mark taken" function that rtic calls at startup
<re_irc>
<@adamgreig:matrix.org> that ship has kind of sailed for rtic since a lot of versions are already out there, though I think it's a neat idea (but that function is just "take()")
<re_irc>
<@jannic:matrix.org> Or it could just use "take" and live with the small overhead?
<re_irc>
<@jannic:matrix.org> Well yes, changing the safety contract in that way could be seen as a breaking change.
<re_irc>
<@adamgreig:matrix.org> yea. it's a bit frustrating because that was never part of the documented safety contract, but it _is_ already widely used, so
<re_irc>
<@adamgreig:matrix.org> it feels a little inconsistent, but maybe the best option is to keep Peripherals::steal() setting DEVICE_PERIPHERALS to avoid changing existing behaviour, but add the new per-peripheral steal() which doesn't set the flag
<re_irc>
<@adamgreig:matrix.org> and perhaps improve the documentation on both to clarify what they do
<re_irc>
<@jannic:matrix.org> "conjure"?
<re_irc>
<@adamgreig:matrix.org> then you can always unsafely get a peripheral using the per-peripheral steal() with no overhead, and you're responsible for making sure it's not used racily
<re_irc>
<@adamgreig:matrix.org> but the existing global steal(), which is probably rarely the right function because it makes the entire object and has the flag-setting overhead, continues to exist for backwards compatibility and rtic
<re_irc>
<@jannic:matrix.org> Sounds reasonable to me.
<re_irc>
<@thejpster:matrix.org> works for me. And I'll be very happy if this doesn't come up again :rofl:
<re_irc>
<@adamgreig:matrix.org> great, I'll update the PRs accordingly and we can hopefully merge it soon
<re_irc>
<@adamgreig:matrix.org> thanks for checking with japaric
<re_irc>
<@thejpster:matrix.org> np
<re_irc>
<@adamgreig:matrix.org> the only thing left on the agenda was e-h spi::operation, which I believe will be merged as soon as bors/ghmq is sorted
<re_irc>
<@adamgreig:matrix.org> so, that's it for this week, thanks all!
<re_irc>
<@jamesmunns:beeper.com> Thank you !
<re_irc>
<@adamgreig:matrix.org> home time 😴
starblue1 has quit [Ping timeout: 240 seconds]
<re_irc>
<@sourcebox:matrix.org> : I have a use case for "static_cell" which is a bit different to what the crate is intended for. But I have to check if the cell is already initialized and currently, there is no way to do that.
<re_irc>
<@adamgreig:matrix.org> : it's currently "require permission for first-time contributors" which I think usually makes sense but it's annoying it doesn't keep re-running after the first approval
<re_irc>
<@adamgreig:matrix.org> could change to "require perm from first-time contributors who are new to github" instead
<re_irc>
<@diondokter:matrix.org> Ah, guess I'm not a 'second'-time contributor yet because the PR hasn't been accepted yet
<re_irc>
<@newam:matrix.org> : Yeah that's what I was thinking, is there a reason not to?
<re_irc>
It's fine as-is, but yeah, annoying to keep re-running after the first approval.
<re_irc>
<@adamgreig:matrix.org> indeed, swapped
starblue1 has joined #rust-embedded
<re_irc>
<@grantm11235:matrix.org> : They could do "take().unwrap_unchecked()", but there would still be the overhead of a critical section
IlPalazzo-ojiisa has quit [Quit: Leaving.]
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
<re_irc>
<@firefrommoonlight:matrix.org> Has anyone successfully used nalgebra's matrix inverse without an allocator?
<re_irc>
<@firefrommoonlight:matrix.org> I think I am up a pickle here
<re_irc>
<@firefrommoonlight:matrix.org> Solved; needed "libm" in features