08:19 <phycrax[m]> What is the best approach for having painless rust-analyzer experience where one:... (full message at <https://catircservices.org/_irc/v1/media/download/AT07FHgJ-g8gIXjOsEs_FmgwpD8BJGge5ZKWW8zDROCWfjTh8xwpHJqVz8KA9T7Oe1M4qqQ00Syr1Wk7b_Mz-1C_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy92S1R1c2RXVXRyWmR5UHN1ZmRtY1lmUFE>)

08:20 <phycrax[m]> * What is the best approach for having painless rust-analyzer experience where one:... (full message at <https://catircservices.org/_irc/v1/media/download/AUddbLQPMyVJLZxaqTcBG-HqUo9wYyH_ubc3m_pCbkolh1eLm3VS5coi7F4nnkmBiDWyjv1eIy7gTq7NtxwJ5DC_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9RelNIUllmWU5qQlJuQnlBYlNUeGRQUFU>)

08:36 <wassasin[m]> <phycrax[m]> What is the best approach for having painless rust-analyzer experience where one:...

08:36 <wassasin[m]> If someone has a good approach, also very interested

08:37 <wassasin[m]> For now I have consigned myself to multiple VS code instances, each on a separate i3 workspace, but this does not scale very well on my laptop which does not have enough RAM for all the rust-analyzer instances simultaneously :')

08:52 <atom_skillz[m]> maybe emacs or neovim can do that

10:39 <dngrs[m]> iirc r-a is working on deduplicating memory use or something

11:05 <dngrs[m]> <phycrax[m]> What is the best approach for having painless rust-analyzer experience where one:...... (full message at <https://catircservices.org/_irc/v1/media/download/AY0hSSiwrm6fE1EzMqD3VV6d9xsXwoVa7GYV8I1GbUEbSHe-NbD4C-iBOQG2d5F6-ftcbY7s9onAw_NVCeMU5Di_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9kSm1SQlhqaUpCR21QcGVjem1nTW1LWW8>)

11:06 <JamesMunns[m]> I do think we are in need of "someone writes a blog post that clearly explains where cargo/workspaces/rust-analyzer fail for embedded projects", particularly:... (full message at <https://catircservices.org/_irc/v1/media/download/AQKK9-C2IL1hoWOW2Fu5jriPNqvkFuW0CMjjrVIanrab7QLLflaLT6st6be3qkCYUub1VIdx673eFB_bksvtn0i_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9WQkJMR3hVTEx1VnRWcE5aTnFZalVPYmo>)

11:07 <JamesMunns[m]> I think to make it all nice, you're going to have to make it very clear what the *problem* is, but also what we *want* to be able to work.

11:07 <JamesMunns[m]> I'm happy to put it in front of the right people if someone will write it up

11:07 <dirbaio[m]> IME there really is no better way than opening N vscode windows

11:08 <JamesMunns[m]> I wrote this up a while back, if anyone wants to use it as a starting point: https://github.com/jamesmunns/bad-workspace

11:08 <dirbaio[m]> at work we have multiple blah.code-workspace files each with its own r-a linkedProjects and cargo features

11:09 <dirbaio[m]> so you just open the right one depending on what you want to work on

11:11 <dirbaio[m]> even if r-a allowed specifying target/features for each linkedProject, I don't think this'd solve the problem

11:12 <dirbaio[m]> because different target/features means r-a has to load+compile deps N times, blowing up RAM

11:12 <dirbaio[m]> so you'd open the one unified vscode workspace and then blow up your computer

11:12 <dirbaio[m]> with separate vscode workspaces you can choose what to open. so if you have little ram you open only 1 or 2 and not blow up your computer

11:22 <dngrs[m]> <dirbaio[m]> IME there really is no better way than opening N vscode windows

11:22 <dngrs[m]> You could open multiple lapce windows...

11:25 <dngrs[m]> Jokes aside that doesn't solve the memory ballooning either (but lapce language server stuff can indeed be much more responsive than vscode with large projects)

11:32 <KevinPFleming[m]> and here we go... Rust 1.89.0

11:35 <KevinPFleming[m]> Binary of my project got a little smaller, but not as dramatic as the last two compiler releases.

11:41 <Ralph[m]> ok, i'm in a bit of a pickle right now... i have a workflow which automatically flashes an RP Pico using UF2 (no debugger attached). it reboots the pico to bootloader mode (using a `postcard-rpc` endpoint... (full message at <https://catircservices.org/_irc/v1/media/download/Aa8-CE4BHKLY6Mw5S3EeScWh24ddXCz5ZrGkMR-GuFZ1PqKCk_T03m9Sv53nSnr3mgM46aNRyfkmazrF8i6pzIu_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9ibU9XZE5wR0F1dlpoZWd0YmRhaUd4eEQ>)

11:41 <JamesMunns[m]> I'd strongly recommend just using `picotool`

11:42 <JamesMunns[m]> Install it from the raspberry pi instructions, swap your runner to:... (full message at <https://catircservices.org/_irc/v1/media/download/ASVms-irwobHz4IdGN-3paUbxkn2KfAepOiKknjY_1Cxn_ClXBbsQAnsFdJKVRtPrbsIFybJCb29LXeiFU_4YQ2_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9CR1RhZFBzV25iS01DSnl2bWNhdFdQRHY>)

11:43 <JamesMunns[m]> I though I'd only seen the "unrecognized abi" stuff when using it with the RP2350, but afaik `elf2uf2-rs` isn't maintained, and the official `picotool` has gotten better.

11:44 <Ralph[m]> this is in a docker image; installing `elf2uf2-rs` with `binstall` is a lot faster & easier than trying to install the picotool from the SDK or even compile it from source. so i'd like to avoid that.

11:44 <Ralph[m]> i'm aware that it's bordering on being unmaintained now, which is really sad 😞

11:44 <Ralph[m]> this is for RP2040, not RP2350 - which is why i didn't expect this error

11:45 <JamesMunns[m]> https://github.com/JoNil/elf2uf2-rs/issues/40 seems to match what you're reporting

11:45 <JamesMunns[m]> Ralph[m]: you can `curl | tar` from the gh releases (this is also what binstall does basically): https://github.com/raspberrypi/picotool/releases/tag/2.2.0

11:47 <Ralph[m]> oh, FFS: i think rust 1.89 broke this. the workflow run this morning used 1.88 and worked fine:... (full message at <https://catircservices.org/_irc/v1/media/download/AYVaNrqBhJYvVP5bZOX_sNIQWYCVCAmhQHiZE4Dnn3U8orwyKrkJACrD4rQrWiqwqTxAUTTST4CVlHayrl18Y_S_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9SSWZ2em53UUZiWERqSGZYUFNlQnJ6V2o>)

11:47 <JamesMunns[m]> <KevinPFleming[m]> Binary of my project got a little smaller, but not as dramatic as the last two compiler releases.

11:47 <JamesMunns[m]> chekhov's gun

11:48 <JamesMunns[m]> Ralph[m]: > i'm aware that it's bordering on being unmaintained now, which is really sad

11:48 <JamesMunns[m]> forking and maintaining the fork is always an option, or talking to the original author to take over!

11:53 <Ralph[m]> Ralph[m]: confirmed: it is a regression... (full message at <https://catircservices.org/_irc/v1/media/download/AUZmen9g5jIAt2Hq_LuRJZkC7Q_PQ7CspOHvrWNnsnFeNaFDs9md9DkAN1YSRx6lcUQYs-aYYYgtKPfyqYonbyK_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9CTmNNUlByU1NyQmZxZHVXcXN0Y255Q0s>)

11:53 <JamesMunns[m]> The full explanation of why it fails is in the issue I linked, btw: https://github.com/JoNil/elf2uf2-rs/issues/40

11:54 <JamesMunns[m]> > the "OS/ABI" has changed from "UNIX - System V" to "UNIX - GNU".

11:56 <Ralph[m]> aaah, i missed that it's the same error because the issue was older. but the author was using nightly and thus already had that change. thanks for spotting that!

11:56 <Ralph[m]> well, crap. isn't that a breaking change of rust? 🤔

12:11 <JamesMunns[m]> I don't know if Rust particularly guarantees anything about "elf metadata fields"

12:11 <JamesMunns[m]> not all visible changes are breaking changes.

12:12 <JamesMunns[m]> and in this case, it's probably actually elf2uf2-rs being *too* strict in checking, because the two different abi codes are (mostly?) interchangable.

12:12 <corecode[m]> on this project that requires libc, weirdness. why is libc_nano compiled with reentrant support for stdin/stdout/stderr? 400 bytes of ram just squandered

12:13 <corecode[m]> and it seems to come from a crt0.o that references exit() that references __stdio_exit_handler

12:51 <firefrommoonligh> <KevinPFleming[m]> and here we go... Rust 1.89.0

12:51 <firefrommoonligh> AVX-512 SIMD!

12:51 <firefrommoonligh> twice the bits

12:51 <diondokter[m]> The one from this release I like most is that Result::flatten is finally stabilized!