| 10 Dec 2025 |
 piegames | I'm dreaming of tackling it for 2.96 really | 17:36:58 |
| piegames | I already have a half-working prototype from a year ago, horrors had one too, and we should soon have all the parts together for doing it | 17:37:37 |
| piegames | main question is whether to do it in C++ or to block it on RPC and do it in Rust | 17:37:53 |
 helle (just a stray cat girl) | please don't do it in C++ | 17:38:13 |
| helle (just a stray cat girl) | we don't want to have to migrate that later on | 17:38:26 |
 Qyriad | 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 | 17:40:46 |
 Sergei Zimmerman (xokdvium) | FWIW v8 uses the source code hash as the cache key https://github.com/v8/v8/blob/427f7cce6d69a2d6ce113200e8dcc1151765058c/src/snapshot/code-serializer.cc#L820-L834 | 17:41:09 |
| Sergei Zimmerman (xokdvium) | So the closest thing would be to hash .nix files -> cached bytecode -> cached optimizer -> .... -> profit? | 17:42:32 |
| 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 |
