| 10 Dec 2025 |
 piegames | that's the goal yes | 17:44:02 |
| piegames | unclear about profit though | 17:44:06 |
 Rutile (Commentator2.0) feel free to ping | Do we understand the overall parsergoal correctly as "use the fastest parser available, errors be damned and if it fails reparse with a good error handling one performance be damned"? | 17:44:16 |
| piegames | unclear. Having a single fast parser with decent error handling and performance would be nice | 17:44:52 |
 KFears (burnt out) | In reply to @qyriad:katesiria.org
we would either block it on RPC, or bind it to existing libexpr over C bindings. the refactoring necessary for libexpr to use a bytecode interpreter over C ABI would be like half the battle for the decoupling we need to do anyway I obviously don't participate in development so my voice matters little, but doing C ABI jumps sounds miserable | 17:45:11 |
 Qyriad | We will need C interop for many parts of the codebase one way or another | 17:45:37 |
| Qyriad | However, we are in the very lucky position that we don't need that ABI to be stable | 17:46:09 |
| Qyriad | Which helps a lot | 17:46:25 |
| piegames | yes, that's why doing it in Rust will mean interop via RPC and subprocesses (which we want anyways) | 17:46:29 |
 Sergei Zimmerman (xokdvium) | That's the hard part too. I imagine bytecode to not be so compact so that serialising it and persisting would have a big overhead. Needs a policy and profiling to see which code is worth caching at all | 17:46:35 |
 rosssmyth | There are interpreters in which parsing is on the critical path, but generally they are ones in which data is loaded dynamically. | 20:05:04 |
| rosssmyth | * There are other interpreters in which parsing is on the critical path, but generally they are ones in which data is loaded dynamically. | 20:05:21 |
 jade_ | we could RPC a thread too | 21:42:54 |
| jade_ | either way is fine tbh | 21:43:00 |
| piegames | long-term the evaluator would be better as a subprocess anyways so I don't see the downsides | 21:43:39 |
| piegames | also it elegantly side-steps the current Rust linking issues | 21:43:48 |
| jade_ | smack the cherry-pick button, get it into the release branch of supported releases, include as patch in nixpkgs if you don't want to wait on someone releng'ing it. | 21:43:55 |
| jade_ | naming a piranha plant stuffie nom chompsky | 21:44:20 |
 helle (just a stray cat girl) | I'll see if I can handle that in the morning, sure | 21:48:29 |
| helle (just a stray cat girl) | ty | 21:49:38 |
 raitobezarius | In reply to @xokdvium:matrix.org
So the closest thing would be to hash .nix files -> cached bytecode -> cached optimizer -> .... -> profit? Inchallah | 22:17:03 |
| rosssmyth | mmmmm challah | 22:18:59 |
| 11 Dec 2025 |
|  Ross joined the room. | 06:45:30 |
 kloenk | just stumbled over that meson 1.9 addes a lot of new rust things and also allows cross language targets apparently? did anyone look into that yet? | 11:26:50 |
| Qyriad | woah what | 11:27:30 |
| Qyriad | oh shit | 11:28:17 |
| kloenk | phoronix, but still: https://www.phoronix.com/news/Meson-1.9-Released
(mostly looking at meson with rust test integration, and wonder if that also could be interesting for lix-doc) | 11:28:24 |
| Qyriad | I'm looking at their release notes now and it does indeed say that | 11:28:39 |
| Qyriad | is 1.9 in stable Nixpkgs? | 11:28:46 |
| kloenk | 1.9.1 in 25.11, so guess yeah | 11:29:11 |
