| 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 |