<cr1901>
>or whatever else implements embedded-io-async traits Meaning I have to bring in a block_on loop to use it in non-async code?
<JamesMunns[m]>
I only have async versions of the stack, correct
<cr1901>
Of course...
<JamesMunns[m]>
it's unlikely to work with a simple block-on, as it handles both incoming and outgoing comms concurrently.
<JamesMunns[m]>
I'm not against someone implementing a blocking version of the protocol, and would take a PR for it, but I am unlikely to implement one. Comms are very amenable to async.
<cr1901>
I've been reluctant to learn embassy b/c it happily uses a bunch of medium-to-advanced Rust features that I've been unable to wrap my head around (mainly GATs and how they replace HKTs). I don't have the bandwidth to give "why were async traits so hard to implement in rustc?" the attention it deserves.
<JamesMunns[m]>
you really really don't need any of that stuff for the day to day, and you can use it on stable really without any problem.
<cr1901>
Don't see myself using it before I get a grasp on the concepts, but good to know
<JamesMunns[m]>
Always happy to chat if you want to get a working mental model of it going :D
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
<cr1901>
I'll decide later whether to stick w/ the async API or submit a PR out of spite
<cr1901>
But at some point I'll _have_ to learn embassy for a blog post, so I'll ask you or dirbaio[m] if he's up for it when it's time
<JamesMunns[m]>
❤️
rukai[m] has quit [Quit: Idle timeout reached: 172800s]
Lumpio- has quit [Ping timeout: 272 seconds]
Lumpio- has joined #rust-embedded
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
m5zs7k has quit [Ping timeout: 272 seconds]
m5zs7k has joined #rust-embedded
rmsyn[m] has quit [Quit: Bridge terminating on SIGTERM]
TomB[m] has quit [Quit: Bridge terminating on SIGTERM]
marmrt[m] has quit [Quit: Bridge terminating on SIGTERM]
whitequark[cis]1 has quit [Quit: Bridge terminating on SIGTERM]
dngrs[m] has quit [Quit: Bridge terminating on SIGTERM]
sirhcel[m] has quit [Quit: Bridge terminating on SIGTERM]
thejpster[m] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
Ralph[m] has quit [Quit: Bridge terminating on SIGTERM]
dirbaio[m] has quit [Quit: Bridge terminating on SIGTERM]
diondokter[m] has quit [Quit: Bridge terminating on SIGTERM]
gregormoritz[m] has quit [Quit: Bridge terminating on SIGTERM]
jannic[m] has quit [Quit: Bridge terminating on SIGTERM]
towynlin[m] has quit [Quit: Bridge terminating on SIGTERM]
Kaspar[m] has quit [Quit: Bridge terminating on SIGTERM]
flippette[m] has quit [Quit: Bridge terminating on SIGTERM]
RobertJrdens[m] has quit [Quit: Bridge terminating on SIGTERM]
jokers[m] 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]
n_vl[m] has quit [Quit: Bridge terminating on SIGTERM]
burrbull[m] has quit [Quit: Bridge terminating on SIGTERM]
therealprof[m] has quit [Quit: Bridge terminating on SIGTERM]
vollbrecht[m] has quit [Quit: Bridge terminating on SIGTERM]
i509vcb[m] has quit [Quit: Bridge terminating on SIGTERM]
henrik_alser[m] has quit [Quit: Bridge terminating on SIGTERM]
Nate[m]1 has quit [Quit: Bridge terminating on SIGTERM]
ZachHeylmun[m] has quit [Quit: Bridge terminating on SIGTERM]
mabez[m] has quit [Quit: Bridge terminating on SIGTERM]
<thejpster[m]>
so it's a good point, and I thank you for raising it
<thejpster[m]>
do you have thoughts on how to implement it in a backwards-compatible way? I suspect it might need a defmt::Format2 trait where we can impl defmt::Format2 for T where T: defmt::Format
<t-moe[m]>
to be honest, I havent worked with (embedded) rust for the past 3 month, since my previous client went bankrupt 😅. It would take me some time to think about it and articulate it in english. You guys are probably much faster thinking about the consequences and how to best implement this in a backwards compatible way. I just wanted to have it mentioned again, so that you can actively decide against this change.
<thejpster[m]>
Do you have a working branch you can share?
<t-moe[m]>
(I think i havent applied the change in question on that branch yet. Thats why I had to remove Copy from Format .)
<t-moe[m]>
I'm happy to polish this a bit, if there is real interest.
<t-moe[m]>
But I think you guys might be able to agree on whether we want this change (to keep the door open for later) without having the full solution implemented yet.
_whitelogger has joined #rust-embedded
Socke has joined #rust-embedded
Christian[m]1 has joined #rust-embedded
<Christian[m]1>
Is anyone familiar with this message ASSERT_PARAM(0 20), in lld_evt.c at line 2371
JamesMunns[m] has joined #rust-embedded
<JamesMunns[m]>
Looks like an #esp-rs:matrix.org question maybe?
<thejpster[m]>
it shows you the assembly for each line of source, in-line.
diondokter[m] has joined #rust-embedded
<diondokter[m]>
Ah nice! But surely it's only as good as the debug info the compiler generates. So, pretty good in most cases, but sometimes pretty wrong too
<thejpster[m]>
they can't do magic, no
jason-kairos[m] has joined #rust-embedded
<jason-kairos[m]>
Silly question, why does the compiler struggle so much even at low optimization levels to keep track of which instruction belongs to which line(s)
<jason-kairos[m]>
Often debug information will claim that an instruction will belong to no lines of rust/C, which is almost never the case
AdamHorden has quit [Ping timeout: 252 seconds]
<JamesMunns[m]>
I find that LTO screws with the debug info the most. I don't think that's a mandatory thing, just LLVM not handling things as well as it could.
<JamesMunns[m]>
At least in GDB. I haven't seen if other tools are less affected
AdamHorden has joined #rust-embedded
<thejpster[m]>
It doesn’t help that doing a volatile pointer read involves half a dozen function calls to do various alignment checks
Brendan[m] has joined #rust-embedded
<Brendan[m]>
Was there any discussion about leveraging Github's dependabot to pull in updates for dependencies?
arso82 has joined #rust-embedded
ouilemur has joined #rust-embedded
kenny has quit [Quit: WeeChat 4.5.1]
kenny has joined #rust-embedded
<Brendan[m]>
I'm asking here because it could be enabled for multiple GitHub repos in the rust-embedded GitHub org. It seems redundant to raise this issue for multiple repos individually.
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
different repos are maintained by different teams in the WG which might have different opinions
<Brendan[m]>
Ah, my main focus is on the embedded-linux team then. Are there rooms for each team? I'm rather new to matrix chats.
<Brendan[m]>
I'm under the impression that lock files are pointless for lib crates, only useful for binary crates.
<Brendan[m]>
You can configure dependabot to satisfy your other concerns. Notifications are more of a user settings scope.
<dirbaio[m]>
there's no way to configure github to notify me for PRs from humans but not from dependabot.
<dirbaio[m]>
anyway, it's my opinion :D
<dirbaio[m]>
feel free to enable it on your repos lol
<dirbaio[m]>
* anyway, it's just my opinion
<Brendan[m]>
I usually configure dependabot to check deps weekly instead of daily, less "spam" that way. I have enabled it on my repos. And I love not having to subscribe to releases of deps just to learn when an update is ready.
<RobertJrdens[m]>
I would like to see this change https://github.com/knurling-rs/defmt/issues/861 reconsidered, even for 1.0. There is a clear solution that looks natural and favorable (reduces size) and it enables object safe/dyn compatible `Format`. But granted: it's an untested breaking change to the wire format and there is no immediate visible use of that feature.
<dirbaio[m]>
it reduces wire size, but what about code size?
<Brendan[m]>
There's also a way to make dependabot group updates into 1 PR per "ecosystem" (ie cargo).
<thejpster[m]>
wire format bumps don't need to go into 1.0
<thejpster[m]>
they can go in at any time
<thejpster[m]>
and that issue only needs a wire-format bump, IIRC
<dirbaio[m]>
it needs changing the trait
<dirbaio[m]>
but only these _methods() that are "public but actually not"
<dirbaio[m]>
so maybe it's okay? :P
<thejpster[m]>
the internal ABI between the log macro and the machinery that logs messages is not stable, because you must always have only one defmt crate in your tree
<thejpster[m]>
as long as custom defmt::Format trait implementations don't break, it's OK
<thejpster[m]>
(and as long as those custom trait impls stick to the public API, i.e. defmt::write! and friends)
<dirbaio[m]>
there's one problem with that design though, it breaks if you print a slice of dyns I think?
<dirbaio[m]>
`&[&dyn Format]`
<dirbaio[m]>
because it'll take the format tag of the first, which is not necessarily the same for all?
<thejpster[m]>
does &dyn Format impl Format? I guess it does.
<thejpster[m]>
I don't know you can format that kind of slice currently. Let me check.
<thejpster[m]>
on right, that's currently not available because it's not object safe
<dirbaio[m]>
yeah, if we made it object-safe I mean
<dirbaio[m]>
currently defmt assumes the tag is constant for a type, dyn breaks that
<thejpster[m]>
I don't know how it could tell the difference between a homogenous slice and heterogenous slice
<thejpster[m]>
Robert Jördens: if you want to propose a PR, we can look at how it works in practice. But I'm unlikely to have the time to implement it myself.
<dirbaio[m]>
that requires removing the `+ ?Sized` in the `&T` blanket impl tho
<dirbaio[m]>
so you can't print `&MyUnsizedStruct` anymore
<dirbaio[m]>
that's a rare thing to need, but so is printing dyns, so i'm not sure...
<dirbaio[m]>
also the slice impl is currently `impl<T> Format for [T]`. removing `+?Sized` on the blanket impl means defmt would have to impl it manually for `&[T]`, `&mut [T]`, `Box<[T]>`, `Arc<[T]>`, etc
<RobertJrdens[m]>
I have the feeling that one could also argue that the issue is with the existing design and only made more prominent by supporting dyn Format. The causal attribution isn't clear to me.
<dirbaio[m]>
what do you mean?
<dirbaio[m]>
current design assumes the tag is constant for a given type.
<dirbaio[m]>
dyn violates that
<RobertJrdens[m]>
I feel like there should be a way to trigger that issue without dyn Format by having a type that has similarly _format_data() but right now I can't construct it.
<RobertJrdens[m]>
But by definition dyn Format is just "one type".
<dirbaio[m]>
so possible solutions are
<dirbaio[m]>
- Do not assume "1 type = 1 tag". Slices must transmit the tag for each element. Downside: bloats the wire format.
<dirbaio[m]>
- Do not assume "1 type = 1 tag" *only for slices of dyn*. Downside: requires specialization.
<RobertJrdens[m]>
I'd argue that the issue is with the transparent _format_data() forwarding.
<RobertJrdens[m]>
dirbaio[m]: But `dyn Format` satisfies that!
<RobertJrdens[m]>
RobertJrdens[m]: And the "tag stripping" in slices.
<dirbaio[m]>
no it doesn't. a u32 behind a `&dyn Format` will have one tag, a u64 will have another.
<RobertJrdens[m]>
Ah. The misunderstanding is there. `<&dyn Format>::_format_tag()` would be constant and is constant under the `MaybeDynFormat` trait change in that gist. `<&dyn Format>::_format_tag(&self)` isn't constant.
<dirbaio[m]>
the solution on your playground works because you wrote `impl<T> Format for &T where T: Format`
<dirbaio[m]>
while defmt currently has `impl<T> Format for &T where T: Format + ?Sized`
<dirbaio[m]>
with ?Sized you get conflicting impls
<dirbaio[m]>
also defmt does `impl<T> Format for [T]`, not `impl<T> Format for &[T]`
<dirbaio[m]>
* for &[T]` which is more general as well
<dirbaio[m]>
i'm 95% sure this is unsolvable in the real defmt if we can't use specialization
<RobertJrdens[m]>
<dirbaio[m]> "also the slice impl is currently..." <- That's not true. I can `impl<T> Format for [T] where T: MaybeDynFormat`
<dirbaio[m]>
that's why your idea works in the playground but not in the real defmt
<RobertJrdens[m]>
Yes. I agree on that. But that wasn't the critique you had about the need for explicit `impl Format for Box<[T]>` etc.
<RobertJrdens[m]>
Sue. I need to drop the blanket `impl Format for &T where T: ?Sized`.
<dirbaio[m]>
that was me explaining what the consequences of removing the +?Sized are
<dirbaio[m]>
there's bad consequences
<RobertJrdens[m]>
That's clear. But there is no need for explicit impls for all kinds of slice containers.
<RobertJrdens[m]>
Explicit slice container impls is not a consequence.
<dirbaio[m]>
as I said, if you're so sure it will work, then implement it.
<RobertJrdens[m]>
But please, you seem to imply that you know already why that mock up above differs from "the real defmt". Please point it out. It would save me time!
<RobertJrdens[m]>
To stress again: yes. I'm dropping the blanket impl for borrows of unsized types.
<dirbaio[m]>
that's exactly the problem
<dirbaio[m]>
if you drop that, you break things
<dirbaio[m]>
because you can't print `&MyUnsizedStruct` anymore
<dirbaio[m]>
there's more unsized types beyond dyn Format and [T]
<dirbaio[m]>
* there's more unsized types beyond dyn Trait and [T]
<RobertJrdens[m]>
But you do agree that `Box<[T]>` does not need special handling?
<dirbaio[m]>
it will when you remove the `?Sized` in the `impl<T: Format+?Sized> Format for Box<T>` blanket impl
<dirbaio[m]>
and you will need to remove it to add `impl MaybeDynFormat for Box<dyn Format>`
<dirbaio[m]>
which you need or else printing `&[Box<dyn Format>]` is broken
<dirbaio[m]>
same for Arc, etc
<dirbaio[m]>
* same for &mut, Arc, etc
<RobertJrdens[m]>
Ah. Now I get it. I didn't think of that knock-on effect.
<RobertJrdens[m]>
Thanks!
EthanGardner[m] has joined #rust-embedded
<EthanGardner[m]>
Are there any good example repos floating around that use lvgl on an stm32
<Ralph[m]>
good catch! hadn't really paid attention to that. i don't think that it particularly matters - though with `--locked` it's (hopefully) sure to always work while without there's a (low) risk that things might fail. should i raise a new PR to add `--locked` to `cargo install` in the CI?
arso82 has quit [Read error: Connection reset by peer]
flr7919174955 has joined #rust-embedded
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
flr7919174955 has quit [Remote host closed the connection]