07:04 <re_irc> <@boiethios:matrix.org> So, I extracted a part of my code into a library, and created a workspace, but it looks like I cannot add a target only to the binary with Cargo stable. The solution to build the binary for the right target is this: https://doc.rust-lang.org/cargo/reference/unstable.html#per-package-target which is only available in nightly builds. I prefer to remain with the stable version, so I'm writing a Makefile. Tiresome.

07:04 <re_irc> <@boiethios:matrix.org> Maybe someone has better advice about how to extract the controller-independent code?

11:21 <re_irc> <@9names:matrix.org> Not sure what you mean.

11:21 <re_irc> Have you tried _not_ using a workspace? It's pretty common for crates to depend each other through path/git/crates.io without workspaces, and in that form they are entirely independent and you can do whatever you need to without effecting anything else.

11:28 <re_irc> <@boiethios:matrix.org> : Yeah, that's a good point… I (wrongly) assumed that since it's all in the same repo (at least at the moment), I had to put them in the same workspace.

11:58 <re_irc> <@chemicstry:matrix.org> If you are using rust-analyzer it has option "rust-analyzer.linkedProjects", which works like workspaces, but better. I can't remember what the actual problem with cargo workspaces was, something with feature/target sharing across all crates, which did not work well for embedded

15:50 <re_irc> <@thejpster:matrix.org> Yes because all the workspace dependencies are shared and compiled only once I don’t think you can set features separately by crate.

15:52 <re_irc> <@thejpster:matrix.org> Also xtasks can be a good replacement for a build script or make file. You add an alias called xtask that does “cargo run xtask”, where xtask is a binary crate you write.

15:53 <re_irc> <@thejpster:matrix.org> https://github.com/matklad/cargo-xtask

16:22 <re_irc> <@besselfn:matrix.org> I'm writing a driver for an IC currently. I have most of it worked out and it's reading the sensor just fine. The sensor provides a checksum though, and I'm not sure what I should do in the event that the checksum fails. I'm pretty sure that I don't want the program to panic, but I also want to report the event to the user

16:22 <re_irc> <@besselfn:matrix.org> Is there a good way to handle something like this?

16:22 <re_irc> <@besselfn:matrix.org> I know I can define a custom error type

16:23 <re_irc> <@besselfn:matrix.org> But I'm not sure if that's the usual/best way to go about it

16:24 <re_irc> <@k900:0upti.me> Return a "Result<Reading, ChecksumError>"?

16:37 <re_irc> <@besselfn:matrix.org> Ok, so a custom error type?

16:38 <re_irc> <@besselfn:matrix.org> Is it typical to leave the error handling on something like my defined checksum error to the user? Or should there be predefined behavior (like retry the measurement?)?

16:38 <re_irc> <@k900:0upti.me> I'd probably leave it to the user

16:53 <re_irc> <@besselfn:matrix.org> OK. Thanks!

17:36 <re_irc> <@firefrommoonlight:matrix.org> : Depends entirely on the use case and details. Especially how critical the system is

17:36 <re_irc> <@firefrommoonlight:matrix.org> One approach is to maintain a SystemStatus struct etc that maintains state of each system. Pass, fail, not connected etc

17:36 <re_irc> <@firefrommoonlight:matrix.org> What you do with that information may be displaying it to the user, or any number of complicated behaviors

17:38 <re_irc> <@firefrommoonlight:matrix.org> Maybe a checksum failure is a critical malfunction and means all data is corrupt. Maybe it happens once in a while, and the next reading will be ok. Maybe it's not a big deal in itself, but is a warning of something like a scheduling conflict

18:06 <re_irc> <@thejpster:matrix.org> If it’s I2C you can also have a bus error so you might need an enum of Error::Transport and Error::Checksum.

18:58 <re_irc> <@almindor:matrix.org> any linking experts around that could help us with https://github.com/riscv-rust/longan-nano/pull/35 ? It seems linking changed between rust v1.60 and v1.61 that causes us to "lose" 2k bytes in the .text section. There's a note in the release changelog (https://github.com/rust-lang/rust/blob/master/RELEASES.md#compatibility-notes-6) mentioning a linking change. I tried using the "--whole-archive" option but it only...

18:58 <re_irc> ... results with missing symbol errors

19:24 <re_irc> <@boiethios:matrix.org> : I think that's exactly what I was looking for. Thanks for the help ;)

19:41 <re_irc> <@thejpster:matrix.org> What symbols are missing? Can you do a build with the old version and the new version and diff the objdump?

19:42 <re_irc> <@thejpster:matrix.org> * missing from your .text section?

19:55 <re_irc> <@almindor:matrix.org> : Nothing is missing, it just has ~2k less "space" with rust v1.61+ as with rust v1.60

19:56 <re_irc> <@almindor:matrix.org> it doesn't build with the new version because it runs out of memory for the .text section and fails to link with newer rust versions

20:00 <re_irc> <@dirbaio:matrix.org> perhaps try making flash bigger in memory.x so that it builds (even if it won't flash)

20:00 <re_irc> <@dirbaio:matrix.org> and then diff the two binaries to see what bloated

20:03 <re_irc> <@almindor:matrix.org> will do, but I'm pretty sure it has to do with this change in rust 1.61 "Previously native static libraries were linked as whole-archive in some cases, but now rustc tries not to use whole-archive unless explicitly requested. This change may result in linking errors in some cases. To fix such errors, native libraries linked from the command line, build scripts, or #[link] attributes need to (more common) either be...

20:03 <re_irc> ... reordered to respect dependencies between them (if a depends on b then a should go first and b second) (less common) or be updated to use the +whole-archive modifier."

20:04 <re_irc> <@almindor:matrix.org> what I don't understand is why +whole-archive doesn't seem to work (at all I mean) with it if it was default before

20:05 <re_irc> <@dirbaio:matrix.org> that sounds like it could cause linker failures

20:05 <re_irc> <@dirbaio:matrix.org> but not bloat

20:28 <re_irc> <@almindor:matrix.org> got the text sections dumped, it's def. bigger on the new one, will check details after lunch

20:50 <cr1901> almindor: Check when the critical_section crate was introduced into riscv-rt

20:51 <cr1901> https://github.com/cr1901/msp430-cs/tree/msp430-cs I have to work around bloat locally with a patch until https://github.com/rust-lang/rust/issues/102295 is fixed

21:44 <re_irc> <@almindor:matrix.org> cr1901: this is triggered by a change in rust version, I'm still using the old riscv-rt 0.6

21:47 <re_irc> <@almindor:matrix.org> as for the objdump diff, I don't see anything obvious "added" but it's phat with 17k lines vs almost 19k lines, hard to diff since the sections are in different order

21:48 <re_irc> <@dirbaio:matrix.org> perhaps "cargo bloat" helps

21:53 <re_irc> <@9names:matrix.org> Or nm maybe?

21:54 <re_irc> <@almindor:matrix.org> https://psion.agg.io/_matrix/media/r0/download/matrix.org/zcoAfilpcrpFDFKbywoKFpnj/screenshot_2023-02-27_13-53-51_727247828.png

21:55 <re_irc> <@almindor:matrix.org> interesting how much changes but nothing obvious jumps out

21:55 <re_irc> <@almindor:matrix.org> going to try with 1.61 so it's closer too

21:58 <re_irc> <@dirbaio:matrix.org> everything slightly larger! lol

22:00 <re_irc> <@almindor:matrix.org> 1.61 is even worse, it seems the size went down a bit in 1.66 :D

22:02 <re_irc> <@almindor:matrix.org> hah

22:02 <re_irc> codegen-units = 1

22:02 <re_irc> <@almindor:matrix.org> [profile.release]

22:02 <re_irc> opt-level = "z" # Optimize for size.

22:02 <re_irc> lto = true``` works, so at least there's a workaround

22:02 <re_irc> <@almindor:matrix.org> [profile.release]

22:02 <re_irc> opt-level = "z" # Optimize for size.

22:02 <re_irc> codegen-units = 1

22:02 <re_irc> lto = true

22:02 <re_irc> ```` works, so at least there's a workaround

22:02 <re_irc> <@almindor:matrix.org> -```` works, so at least there's a workaround

22:03 <re_irc> <@dirbaio:matrix.org> perhaps you can bisect the nightlies to see where it bloated https://github.com/rust-lang/cargo-bisect-rustc/blob/master/TUTORIAL.md

22:03 <re_irc> <@almindor:matrix.org> makes it work even with new rustc, I guess it's just a diff in the compiler performance then

22:03 <re_irc> <@dirbaio:matrix.org> but it'll probably point to a llvm update or something generic like that...

22:03 <re_irc> <@dirbaio:matrix.org> this is very interesting

22:04 <re_irc> <@dirbaio:matrix.org> how can optimizations get worse like this? :S

22:04 <re_irc> <@almindor:matrix.org> rust compiler itself + llvm is such a huge mess, I'm surprised it doesn't have more quirks tbh. :D

22:04 <re_irc> <@almindor:matrix.org> is there some specific regressions wg or such we could report to?

22:05 <re_irc> <@dirbaio:matrix.org> issue in rust repo probably

22:06 <re_irc> <@almindor:matrix.org> i'll try to open it today

22:07 <re_irc> <@almindor:matrix.org> seems like something that shouldn't happen, if it was like 100bytes or such jump but it seems something fundamental got borked on riscv at least

23:26 <re_irc> <@almindor:matrix.org> https://github.com/rust-lang/rust/issues/108543