<JamesMunns[m]>
that runs cargo with the proper environment set
<JamesMunns[m]>
(so you could run rustup from an absolute path using that command, without rustup in path)
<huayra1[m]>
<JamesMunns[m]> "like, do you have measurable..." <- i spend a lot of time parsing the same headers if that's what you mean
<huayra1[m]>
<dirbaio[m]> "and then you can build using..." <- it's asking me to install this target with rustup
<huayra1[m]>
i managed to figure it out
yruama_lairba[m] has joined #rust-embedded
<yruama_lairba[m]>
hello need help, i'm doing some avr embed stuff and i have a linking issue, i have many erro like this : undefined reference to `core::panicking::panic::h391309c3ce9a86cb' . I don't know what's wrong ?
<yruama_lairba[m]>
after some test, the problem seems to come when i'm trying to use float type
emerent has quit [Killed (iridium.libera.chat (Nickname regained by services))]
emerent_ is now known as emerent
GolfMike has joined #rust-embedded
GolfMike has quit [Quit: Client closed]
<sourcebox[m]>
Stupid questions: this PR fails because of changelog not updated, but there's already an entry for clippy fixes in the changelog, so nothing to add. https://github.com/rust-embedded/heapless/pull/512
<sourcebox[m]>
There's some label skip-changelog, how can this be added?
<sourcebox[m]>
Maybe, but I feel stupid not knowing this after such a long time.
<M9names[m]>
it's a permissions thing. some repos allow users to set their own labels, others restrict it to members.
<M9names[m]>
if you ask for the label to be added and a maintainer agrees they will add it for you
<M9names[m]>
sourcebox[m]: maybe you should have asked sooner?
<M9names[m]>
nobody is born with knowledge, either you spend all your time discovering everything from first principles or you're going to have to ask someone eventually
<sourcebox[m]>
If a maintainer can approve it, that's fine. I only want to avoid that the PR gets stuck because of this issue.
<M9names[m]>
sure, good idea! write that down in the PR comment, maintainers can't read your mind
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
<sourcebox[m]>
But I thought, you just can add skip-changelog somewhere in the title or similar.
<M9names[m]>
not that i'm aware of, maybe we'll both learn something today
<sourcebox[m]>
This check is useful in general, so it's good to have it by default.
<yruama_lairba[m]>
Hi, Is someone doing some avr embeded stuff ? hi have linking issue when trying to use floating type
<diondokter[m]>
Thanks for sharing! Yeah we were talking with Julius and he kept saying awesome things I really wanted to share
mameluc[m] has joined #rust-embedded
<mameluc[m]>
> It's hard to think about having to go back to something that's not Rust
<mameluc[m]>
I am kind of in the same situation, I don't want to go back 😁
<mameluc[m]>
great article, good read 👍️
<danielb[m]>
QM components are perfect as automotive Rust gateway drugs :D
<danielb[m]>
* QM (as in, not safety critical) components are
AlexandrosLiarok has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
yeah hats off to diondokter for getting someone to actually say out loud a success story they are having in Rust
<thejpster[m]>
and of course Ferrocene is here for all your QM needs, as well as your safety certified needs.
<thejpster[m]>
all my success stories are covered in NDAs
<diondokter[m]>
It's doing great on the socials so far, so people seem to enjoy it :D
<thejpster[m]>
I am of course annoyed that we didn't manage to write this piece :)
<thejpster[m]>
but if it's good for Rust, it's good for us
pbsds3 has quit [Ping timeout: 248 seconds]
pbsds3 has joined #rust-embedded
kriszd[m] has joined #rust-embedded
<kriszd[m]>
Hi, is it okay to ask for career advice here? I'm currently a little bit lost and I would really appreciate some guidance
<thejpster[m]>
I can't remember if it came up, but the compiler-builtins infinite recursion bug that plagued SPARC got fix. Because it also plagued WASM.
GolfMike has joined #rust-embedded
<thejpster[m]>
so as of today, debug builds with nightly rust should work on Leon 3 again, as long as you only make static libraries. Binaries are still blocked pending https://github.com/rust-lang/rust/pull/131222
<thejpster[m]>
replacing some default trait methods with inherent methods that have exactly the same contents
<thejpster[m]>
one of these avoids a function call and the other does not. I have no idea why. But a function call is bad, because we're defining that very function.
<diondokter[m]>
Wait... ok that's weird
<diondokter[m]>
Can default trait functions not get inlined or something?
cinemaSundays has joined #rust-embedded
GolfMike has quit [Quit: Client closed]
<thejpster[m]>
surely nothing is inlined on the standard debug profile build?
<diondokter[m]>
Oh yeah that's true regardless. (Also I checked on godbolt. At least in simple cases it inlines the same as the concrete impl)
<FreeKill[m]>
So today at work, our newest (pretty young) hire heard me mention Segger having added Rust support to Ozone and started singing the praises of embedded Rust, having used it in one of his previous jobs with cbindgen to the ST HAL.
<FreeKill[m]>
Feels like the young guns are being convinced!
<dirbaio[m]>
> with cbindgen to the ST HAL.
<dirbaio[m]>
interesting to hear they were happy with rust even if they did it that way :D
<FreeKill[m]>
Which i think is a reasonable place to end up
<FreeKill[m]>
Certainly when I've brought up Rust at work, the only use case that people have been at all curious about is writing Rust modules and linking them in to an otherwise C codebase
cinemaSundays has quit [Quit: Connection closed for inactivity]
<thejpster[m]>
Did everyone see that Raspberry Pi now sell SD Cards? Very timely given my talk on Friday.
<thejpster[m]>
They patched Linux to support Command Queuing on SD Cards, allowing the card to cache writes and return results out of order. Like SATA started doing 20 years ago.
<thejpster[m]>
Most cards have bad support for this, and while Sandisk is good many Sandisk cards are knock-offs. So now they sell their own brand SD Cards made by Longsys.
<sourcebox[m]>
My personal experience with SD cards on RPi is not that good. They wear out quite fast. Not sure about possible config options to prevent that.
<dirbaio[m]>
great, until knockoffs of Raspberry Pi branded sdcards start appearing :D
<dirbaio[m]>
crazy that linux couldn't do OoO sdcard until today tho
<JamesMunns[m]>
sourcebox[m]: I'm surprised they don't have a default/one-click config that does the best practices here: make the rootfs read only, move most runtime logged things to RAM to reduce write impact.
<JamesMunns[m]>
I suppose it also requires whatever software you use to also be respectful of write cycles
<sourcebox[m]>
In my case it was most likely just the logging.
<sourcebox[m]>
I would expect that Raspbian has better defaults for this to be minimized.
<sourcebox[m]>
In one case, we used a RPi 2 as a file server, but all the data was on an external SSD connected via USB.
<thejpster[m]>
I mean Debian is Debian. If you want a read only root, there’s CoreOS and other stuff for that.
<thejpster[m]>
And my Pi 5 has an NVME SSD on it anyway
<sourcebox[m]>
log2ram looks interesting. Can surely lose some logs in case of power loss, but if you don't look at them anyway, who cares...
chrysn[m] has quit [Quit: Idle timeout reached: 172800s]
<huayra1[m]>
update: with rust, compile times went from 2 seconds to 2.7 seconds. the difference is 56 lines of rust.
<huayra1[m]>
this is with -Z threads, -C codegen-units, and cargo -j
roklobsta[m] has joined #rust-embedded
<roklobsta[m]>
<sourcebox[m]> "My personal experience with SD..." <- Cactus cards might be good. https://www.cactus-tech.com/products/industrial-pslc/microsd/ A looong time ago in the CF days we settled on Cactus as every other card maker we tried had some sort of issue including death-in-the-field usually if the card was reset for some reason or the power was cut during a write cycle.
<dirbaio[m]>
this is not breaking, right? thanks to the seal
<huayra1[m]>
<dirbaio[m]> "what do you want us to do?" <- is there not anything left to improve? i use like 1% of libcore, surely i can only compile the parts i use?
<dirbaio[m]>
huayra1[m]: I just don't understand why you're so concerned about cold build time. what matters for dev productivity is warm build time.
<dirbaio[m]>
`dyn` won't monomorphize yep, but once you put an addr in a dyn you can't use it anymore (unless some HAL impls `I2c<dyn Address>` which I don't think any do
<huayra1[m]>
dirbaio[m]: with that mindset, you can easily justify a 5 minute cold compile which could've been a 30 second cold compile had some compiler/cargo flags been applied
<jannic[m]>
dirbaio[m]: Ah right - the AddressMode is a type parameter of `I2c`. That's what I missed.
<dirbaio[m]>
i'm not saying you shouldn't optimize cold build time
<dirbaio[m]>
5s cold build time is pretty good considering you're using build-std
<huayra1[m]>
have you ever had a project that always cold compiled in under a second no matter what you did? it gets addicting, doesn't it?
<huayra1[m]>
dirbaio[m]: ``-Zbuild-std=core``. not the whole sts
<dirbaio[m]>
no? dev experience is the same as long as hot builds are 1s
<huayra1[m]>
* ``-Zbuild-std=core``. not the whole std
<JamesMunns[m]>
huayra1[m]: I really don't notice below 10-20 seconds honestly.
<dirbaio[m]>
no matter whether cold build is 1s or 10s
<JamesMunns[m]>
cargo watch -x check means I know whether it compiled or not in a few seconds anyway. Or IDE highlighting.
<AlexandrosLiarok>
I have had 2minutes + cold build times for C++ projects.
<huayra1[m]>
JamesMunns[m]: this is crazy to hear, i really thought people were used to lightning fast builds
<dirbaio[m]>
your computer takes more than 1s to turn on
<JamesMunns[m]>
huayra1[m]: it's fast enough to not get in my way :p
<dirbaio[m]>
even your monitor takes more than 1s to wake up when you sit down at your chair and move the mouse
<AlexandrosLiarok>
Yea we are used to lightning fast builds. Warm ones.
<huayra1[m]>
"fast on my machine" also isn't fast on everyone's machine. if my laptop can't do it fast, then the laptop of another person 3 gens older than mine won't do much better
<JamesMunns[m]>
huayra1[m]: If you're here to argue about whether build times are important, I might say there are better places to do it than here. it's just generally off topic wrt embedded stuff.
<AlexandrosLiarok>
It does matter for CI stuff though.
<dirbaio[m]>
even in CI you can cache
<huayra1[m]>
my own laptop is my CI if that helps for context
<AlexandrosLiarok>
I consider 5sec builds completely fine for CI just to be clear.
<huayra1[m]>
yes if it's automated and i don't have to watch it, launch it in a vm, and manually run unit tests.
<huayra1[m]>
should i work on my CI? absolutely.
<jannic[m]>
I guess nobody would object faster build times. But at some point, there are more important things to work on.
<huayra1[m]>
i'm not rewriting libcore here. i'm just asking if there is more code i can turn off.
<huayra1[m]>
i looked at build-std-features but the docs are sparse
<dirbaio[m]>
you can't turn off parts of libcore
<huayra1[m]>
some people say you can do "core/whatever" but it might be a bug
<dirbaio[m]>
the features are to tweak behavior, not to turn off parts
<dirbaio[m]>
compiler-builtlins and core take a few seconds to build, no way around it
<danielb[m]>
technically there is an unstable #![no_core] I believe but ... why
<huayra1[m]>
compiler-builtins i can get around because it's not available for my target
<dirbaio[m]>
note they're prebuilt in pre-made targets so you're only seeing this because you're using a custom target
<dirbaio[m]>
your C cold builds would also be a few seconds slower if you were building compiler_builtins/libgcc and libc every time :P
<huayra1[m]>
shivers not gcc
<huayra1[m]>
* shivers not glibc
<huayra1[m]>
* *shivers* not glibc!
<huayra1[m]>
at least give me musl with the freestanding headers!
crabbedhaloablut has quit [Read error: Connection reset by peer]