ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
honeydatax has quit [Quit: Client closed]
honeydatax has joined #rust-embedded
honeydatax has quit [Client Quit]
honeydatax has joined #rust-embedded
honeydatax has quit [Quit: Client closed]
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
AdamHorden has quit [Ping timeout: 272 seconds]
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
sroemer has joined #rust-embedded
ska has quit [Ping timeout: 240 seconds]
AdamHorden has joined #rust-embedded
honeydatax has joined #rust-embedded
honeydatax has quit [Quit: Client closed]
honeydatax has joined #rust-embedded
<honeydatax> Hi users from the chanel check it out my code from wasm builder rust formater file https://pastebin.com/GPjqQZHm
<honeydatax> Can same one help me to get code betther
<honeydatax> Using a rust language type and save it from the type
honeydatax has quit [Quit: Client closed]
<JamesMunns[m]> honeydatax: this is a room for Rust on embedded systems, like microcontrollers. You might get better feedback in general Rust channels.
<diondokter[m]> Just released sequential-storage 5.0.0. Compared to 4.0.0 there are a nice bunch of edge case problems fixed.
<diondokter[m]> It's a barely breaking change, so easy to update!
<JamesMunns[m]> ooh, what WAS the breaking change?
<diondokter[m]> In the fetch_all_items of the map. Previously you have to specify the key type every time, but now the iterator already knows about it
<diondokter[m]> Small ergonomic change
honeydatax has joined #rust-embedded
mameluc[m] has quit [Quit: Idle timeout reached: 172800s]
dkm has quit [Ping timeout: 245 seconds]
honeydatax has left #rust-embedded [#rust-embedded]
<jason-kairos[m]> s/overvation/observation/, s///
<JamesMunns[m]> Is that RAM usage size or code usage size? Recent nightlies changed `#[used]` which causes an increase of RAM usage: https://github.com/oxidecomputer/hubris/issues/2165#issuecomment-3098126432
<JamesMunns[m]> and s vs z are not strictly "one is smaller than the other", all of `3`, `s`, and `z` can often produce smaller code: they just have different optimizer heuristic thresholds, sometimes one happens to work better/worse than others
<JamesMunns[m]> I'd suggest looking at the output of `cargo nm --release -- --nS` and diffing what is larger between the two builds.
<JamesMunns[m]> * RAM usage (edit:, * : in hubris specifically, due to how they are (mis)using `#[used]`): https://github.com/oxidecomputer/hubris/issues/2165#issuecomment-3098126432
<jason-kairos[m]> sorry, flash/code usage
<jason-kairos[m]> RAM is unchanged
<thejpster[m]> Yeah https://github.com/rust-lang/rust/commit/cf423712b9e95e9f6ec84b1ecb3d125e55ac8d56 might catch people by surprise and I don’t think is widely known
<JamesMunns[m]> @thejpster tagged you in https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Reverting.20.60.23.5Bused.5D.60.20default.20change.3F, which is discussing maybe reverting it before it lands on stable
dkm has joined #rust-embedded
ska has joined #rust-embedded
<whitequark[cis]> it's so weird that gold got dropped
<whitequark[cis]> like what do people who want a fast linker are supposed to do, use lld instead? fine by me but do GNU folks not want fast link times?
<thejpster[m]> It’s a good change, so I don’t want to revert it. But we definitely need more people to be testing on beta.
<thejpster[m]> Perhaps each beta needs a blog post warning you what’s coming.
<thejpster[m]> (I build my training material weekly on beta and nightly so I’m not worried)
andar1an[m]1 has joined #rust-embedded
<andar1an[m]1> Has cranelift progressed as a rust linking option? Is it possible to use for embedded?
<TomB[m]> wild is a rust linker, it'd be neat to see it working for embedded archs
<TomB[m]> * embedded archs, not sure cranelift has its own linker does it?
<andar1an[m]1> I thought it did, but I may be mistaken. I don't know much about https://github.com/rust-lang/rustc_codegen_cranelift
<andar1an[m]1> I assumed it would do linking. But it has been a while since I looked at that, just saw comment above and got curious about state
<andar1an[m]1> Ya, prbly my mistake. Just always see comparison with llvm, but maybe that doesnt include linker
<andar1an[m]1> Seems in this issue rust-lld is linker https://github.com/rust-lang/rustc_codegen_cranelift/issues/1530
<andar1an[m]1> Guess it would make sense that wasm wouldn't need a linker?
<whitequark[cis]> wasm does very much need a linker
<andar1an[m]1> Ah okay, so then wonder what is used there
<whitequark[cis]> the only wasm linker i'm aware of is based on lld
<andar1an[m]1> I saw one called mold mentioned on wilds page too, wonder how that is
<andar1an[m]1> I think bytecode alliance linker is llvm
<andar1an[m]1> Anyways sorry, not applicable to embedded now haha
<whitequark[cis]> yes, the one in wasi-sdk is the llvm linker, which is lld
<whitequark[cis]> i don't think mold supports wasm
<whitequark[cis]> > mold supports x86-64, i386, ARM64, ARM32, 64-bit/32-bit little/big-endian RISC-V, 32-bit PowerPC, 64-bit big-endian PowerPC ELFv1, 64-bit little-endian PowerPC ELFv2, s390x, 64-bit/32-bit LoongArch, SPARC64, m68k, and SH-4.
<whitequark[cis]> yeah
<whitequark[cis]> * > mold supports x86-64, i386, ARM64, ARM32, 64-bit/32-bit little/big-endian RISC-V, 32-bit PowerPC, 64-bit big-endian PowerPC ELFv1, 64-bit little-endian PowerPC ELFv2, s390x, 64-bit/32-bit LoongArch, SPARC64, m68k, and SH-4.
<whitequark[cis]> yeah
<andar1an[m]1> But is it applicable to embedded?
<andar1an[m]1> Wild seemed specific to linux atm
<whitequark[cis]> wasm itself is used pretty widely on embedded devices
<andar1an[m]1> Ya, I have been interested in that for myself. Just haven't played much with wasm since P1.
<andar1an[m]1> A bit rusty (pun intended)
<andar1an[m]1> 🦀🦀🦀
<andar1an[m]1> So in nutshell llvm ld is main linker option for embedded ATM?
<andar1an[m]1> s/ld/lld/
<JamesMunns[m]> lld is used by default in embedded rust, yes
<JamesMunns[m]> you can also use gcc ld as well, if you set configuration
<andar1an[m]1> Thanks James, PS started following pingora recently, saw you as contributor on that. Looks neat
jfsimon has quit [Remote host closed the connection]
<andar1an[m]1> Think it was river that guided me there. Gotta try still
<andar1an[m]1> Had to look up name lol
<JamesMunns[m]> I worked on River for a bit, not actively doing so at the moment, pingora is very neat :)
jfsimon has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
Kaspar[m] has quit [Quit: Idle timeout reached: 172800s]
<andar1an[m]1> Ya, why I mentioned. Not many Rust reverse proxies, and with http/3 on road map for pingora, wish River popped up more in searches.
<andar1an[m]1> I can't wait to get to point of investigating embedded networking more, was planning forward proxies for my embedded arch, but a ways to go before I understand fully
<M9names[m]> TIL there's a linker flag to allow you to allocate sections to non-contiguous memory regions:
jfsimon1981 has joined #rust-embedded
jfsimon has quit [Ping timeout: 245 seconds]
Socke has quit [Quit: WeeChat 4.7.0]
Assatadajamante[ has quit [Quit: Idle timeout reached: 172800s]
jesse-de-loore[m has quit [Quit: Idle timeout reached: 172800s]
Socke has joined #rust-embedded
AshconMohseninia has quit [Quit: Idle timeout reached: 172800s]
<jason-kairos[m]> I wonder if dataful or generic enums might not be supported in gdb or something
<jason-kairos[m]> I also wonder if gdb might get tripped up by unicode vs ascii brackets. As far as I can tell it shouldn't be a problem
<jason-kairos[m]> gdb people say "I guess that GDB isn't able to find the specific template instantiation. That specific template instantiation needs to exist in the DWARF for GDB to be able to find it"
<jason-kairos[m]> does anyone know if this is a possible known issue or not with rust's debug symbols?
d34db33f has joined #rust-embedded
d34db33f has quit [Ping timeout: 248 seconds]
d34db33f has joined #rust-embedded
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
<dngrs[m]> <jason-kairos[m]> gdb people say "I guess that GDB isn't able to find the specific template instantiation. That specific template instantiation needs to exist in the DWARF for GDB to be able to find it"...
<dngrs[m]> can you use lldb? I think it's better supported
<jason-kairos[m]> Has anyone ever made lldb work with a debug probe? (they all use the gdb extended remote protocol)
<jason-kairos[m]> I've never heard or anyone ever making lldb function on embedded
<jason-kairos[m]> s/I've never heard or anyone ever making lldb function on embedded/I've never heard or anyone ever making lldb function with real embedded hardware/
<jason-kairos[m]> s/I've never heard or anyone ever making lldb function on embedded/I've never heard of anyone ever making lldb function with real embedded hardware/
<jason-kairos[m]> s/I've never heard or anyone ever making lldb function on embedded/I've never heard of anyone ever making lldb function with real embedded hardware. I've asked here before about lldb once or twice, and the answer has always seemingly been "nope!"/
tiwalun[m] has joined #rust-embedded
<tiwalun[m]> lldb can connect to a GDB server, with gdb-remote 8000
fstracke has joined #rust-embedded
fstracke has quit [Ping timeout: 252 seconds]
d34db33f has quit [Ping timeout: 265 seconds]
d34db33f has joined #rust-embedded
RobinMueller[m] has joined #rust-embedded
<RobinMueller[m]> What naming conventions do you have for naming very common things like Control, Config, Clock etc.? I recently saw that I am not very consistent with this and I sometimes use Ctrl, Cfg and Clk, and sometimes the large variant. I am currently learning towards renaming everything to the short variants, but maybe there is an unwritten (or written) style guideline for embedded rustt code here? I tend to avoid abbreviations if they
<RobinMueller[m]> are not straightforward to understand, or even confusing (e.g. I don´t like abbreviating Interrupt with Int)
<JamesMunns[m]> I'm not aware of a standard one. Lots of folks mimic the name of things for their hardware, or names of registers, or just personal habit
<dngrs[m]> not really an answer to the specific question, but in general I find the Rust API guidelines well worth reading. They do have a [section on naming](https://rust-lang.github.io/api-guidelines/naming.html) but don't cover abbreviations
<dngrs[m]> personally I prefer not abbreviating struct/enum names. Variables: sometimes
<dngrs[m]> * personally I prefer not to abbreviate struct/enum names. Variables: sometimes
<dngrs[m]> fields: also sometimes, but rarer than variables
<dngrs[m]> the way I see it horizontal screen estate is basically free, and since good completion is imo a given, long names don't need to be typed out manually either
d34db33f has quit [Read error: Connection reset by peer]
d34db33f has joined #rust-embedded
<jason-kairos[m]> <tiwalun[m]> lldb can connect to a GDB server, with gdb-remote 8000
<jason-kairos[m]> But it's protocol implementation has been broken for quite a while as far as I can tell.
<jason-kairos[m]> * But it's gdb protocol implementation
<jason-kairos[m]> * But it's gdb protocol implementation has been broken for quite a while as far as I can tell.
<jason-kairos[m]> Has anyone ever successfully coaxed into into working?
<jason-kairos[m]> * But it's gdb protocol implementation has been broken for quite a while as far as I can tell.
<jason-kairos[m]> Has anyone ever successfully coaxed into into working? (maybe my past experiences were specific to a particular probe or gdb-server - I've never seen or heard or anyone actually using it)
<jason-kairos[m]> * But it's gdb protocol implementation has been broken for quite a while as far as I can tell.
<jason-kairos[m]> Has anyone ever successfully coaxed into into working? (maybe my past experiences were specific to a particular probe or gdb-server - I've just never seen or heard or anyone actually using it)
<jason-kairos[m]> * But it's gdb protocol implementation has been broken for quite a while as far as I can tell.
<jason-kairos[m]> Has anyone ever successfully coaxed into into working? (maybe my past experiences were specific to a particular probe or gdb-server - I've just never seen or heard of anyone actually using it)
<jason-kairos[m]> * But it's gdb protocol implementation has been broken for quite a while as far as I can tell.
<jason-kairos[m]> Has anyone ever successfully coaxed into into working? (maybe my past experiences were specific to a particular probe or gdb-server - I've just never seen or heard of anyone actually using it successfully with real hardware)
<tiwalun[m]> probe-rs gdb and then attaching with lldb seems to work fine
<tiwalun[m]> with a nRF54L15-DK
<firefrommoonligh> <RobinMueller[m]> What naming conventions do you have for naming very common things like Control, Config, Clock etc.? I recently saw that I am not very consistent with this and I sometimes use Ctrl, Cfg and Clk, and sometimes the large variant. I am currently learning towards renaming everything to the short variants...
<firefrommoonligh> I might, for example, call the top level one `Config`, and if passing it as a ref where it gets used several times, call it `cfg`. Overall, I wouldn't sweat it
<firefrommoonligh> You are choosing a balance of descriptive and clear vs avoiding syntactic clutter.
<GuineaWheek[m]> <RockBoynton[m]> I saw the you pushed a release to GH, anything blocking pushing to crates.io? Anxious for my compile times to be reasonable again 🙏
<GuineaWheek[m]> diondokter:
<firefrommoonligh> I think anchoring it least once with the full descriptive name can help anyone who m ight be confused, but passing around a big descriptive name (Config isn't too heinous though) can make code tough to read and maintain if used repeatedly
<firefrommoonligh> You want to avoid the case where someone new is wondering "Wtf is a CLk? Is it about clicking a button"
<firefrommoonligh> I had a case recently where I started with a function called build_masks, ended up confusing myself about wtf it's doing, and renamed this morning to setup_nonbonded_exclusion_scale_flags
fstracke has joined #rust-embedded
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #rust-embedded
thalesfragoso[m] has quit [Quit: Idle timeout reached: 172800s]
jfsimon1981 has quit [Remote host closed the connection]
fstracke has quit [Ping timeout: 240 seconds]
jfsimon1981 has joined #rust-embedded
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #rust-embedded
zeenix[m] has quit [Quit: Idle timeout reached: 172800s]
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
sroemer has quit [Quit: WeeChat 4.5.2]
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
LeandroMarceddu[ has quit [Quit: Idle timeout reached: 172800s]
bartmassey[m] has quit [Quit: Idle timeout reached: 172800s]
<diondokter[m]> <RockBoynton[m]> I saw the you pushed a release to GH, anything blocking pushing to crates.io? Anxious for my compile times to be reasonable again 🙏
<diondokter[m]> Oh lol... Did I really forget the publish? Lol
<diondokter[m]> diondokter[m]: Alright, done :P
<diondokter[m]> Guinea Wheek Rock Boynton
<diondokter[m]> diondokter[m]: (1.0.7)
d34db33f has quit [Remote host closed the connection]
therealprof[m] has quit [Quit: Idle timeout reached: 172800s]
<RockBoynton[m]> <diondokter[m]> (1.0.7)
<RockBoynton[m]> builds down from 3+ *minutes* to <20 *seconds*
<RockBoynton[m]> RockBoynton[m]: so hyped right now
HumanG331 has quit [Ping timeout: 252 seconds]
Pete[m]1 has quit [Quit: Idle timeout reached: 172800s]
Ralph[m] has joined #rust-embedded
<Ralph[m]> in rust i usually avoid abbreviations. remember that most modern IDEs have good autocomplete. if your function is called `very_long_and_descriptive_function_name` most IDEs will let you write `vladfn` (initials of each word) and still autocomplete it (when i switched from Eclipse to IntelliJ - maybe a decade ago? - that was _the_ selling point for me: finally a really good autocomplete! where i did not have to write
<Ralph[m]> `StupidlyLongAndObnoxiousAbstractJavaFactoryInterfaceImpl` in full anymore!)
<Ralph[m]> on the other hand if i just use something on 1-2 lines and it then goes out of scope again i do sometimes go short and an error just becomes `e` or a result just becomes `r` in cases where it's obvious what it is.
fstracke has joined #rust-embedded
fstracke has quit [Client Quit]
fstracke has joined #rust-embedded
fstracke has quit [Ping timeout: 252 seconds]
jfsimon1981 has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
jfsimon has quit [Max SendQ exceeded]
jfsimon has joined #rust-embedded
rukai[m] has joined #rust-embedded
<rukai[m]> Hi, I hope this is an appropriate place to post this, but I've been working on a rust crate to work around missing webusb support in some browsers by sending data over the FIDO protocol https://github.com/rukai/not-webusb-rs
khionu[m] has quit [Quit: Idle timeout reached: 172800s]
<dngrs[m]> <rukai[m]> Hi, I hope this is an appropriate place to post this, but I've been working on a rust crate to work around missing webusb support in some browsers by sending data over the FIDO protocol https://github.com/rukai/not-webusb-rs
<dngrs[m]> that sounds pretty cool - I've often been annoyed that Firefox does not support WebUSB
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded