| 10 Dec 2025 |
 piegames | unclear about profit though | 17:44:06 |
 Rutile (rootile) | 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 (they/them) | 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 |
