| 10 Dec 2025 |
 rosssmyth | https://matklad.github.io/2020/04/13/simple-but-powerful-pratt-parsing.html | 16:27:05 |
| rosssmyth | Why do you need a library for that? | 16:27:42 |
| rosssmyth | They integrate just fine | 16:28:05 |
 kloenk | Friend looked at the lib for it and was very unhappy. Not looked myself into it. Mostly happy with logos and hand rolled conversion into rowan | 16:28:48 |
| rosssmyth | Yeah my latest project has a lexer that is just a copy of Rustc's lexer with my tokens in it, ungrammar for the cst data structures, and then hand-rolled parser. | 16:29:58 |
| rosssmyth | Logos is cool though | 16:30:09 |
| rosssmyth | Used it before | 16:30:14 |
| rosssmyth | The thing about parsing is that perf doesn't really matter that much, it's such a small amount of time unless you really mess it up. Better to focus on making it have really good errors | 16:32:12 |
 piegames | In reply to @rosssmyth:matrix.org
The thing about parsing is that perf doesn't really matter that much, it's such a small amount of time unless you really mess it up. Better to focus on making it have really good errors narrator voice indeed it is really messed up | 16:34:30 |
| piegames | Due to unfortunate design decisions made (or rather, not made) back when I was in Kindergarten, parsing is on the critical path for evaluation time | 16:35:23 |
| rosssmyth | amazing | 16:35:33 |
| rosssmyth | If you want the highest performance possible, larlpop will be hard to beat. But recovery is bad so it would be difficult to get good diagnostics out of it. | 16:43:50 |
 helle (just a stray cat girl) | what is the process if we need to do a backport of a patch (or other proposals of how to handle this one)
this as nixpkgs mdbook 0.5.0 update depends on https://gerrit.lix.systems/c/lix/+/4653 being in
see https://github.com/NixOS/nixpkgs/pull/462777#issuecomment-3637993347 & https://github.com/NixOS/nixpkgs/pull/467009 | 16:50:39 |
 Qyriad | In reply to @piegames:flausch.social
narrator voice indeed it is really messed up something something C++ parsing… | 17:18:05 |
| piegames | that too, but that's not even what I meant | 17:18:20 |
 KFears (burnt out) | In reply to @piegames:flausch.social
Due to unfortunate design decisions made (or rather, not made) back when I was in Kindergarten, parsing is on the critical path for evaluation time Is that because parsing is so unbearably slow, or is there a more cursed reason? | 17:18:25 |
| Qyriad | In reply to @piegames:flausch.social
Due to unfortunate design decisions made (or rather, not made) back when I was in Kindergarten, parsing is on the critical path for evaluation time we would like to see benchmarks on this… we'd honestly sooner suspect filesystem IO as a bottleneck over parse-time | 17:18:48 |
| Qyriad | In reply to @piegames:flausch.social
Due to unfortunate design decisions made (or rather, not made) back when I was in Kindergarten, parsing is on the critical path for evaluation time * we would like to see benchmarks/profiles on this… we'd honestly sooner suspect filesystem IO as a bottleneck over parse-time | 17:19:17 |
| Qyriad | (having looked at profiles of eval before, but not in a while) | 17:19:29 |
| piegames | no, parsing is super fast, mostly thanks to horrors, it's just that Nixpkgs is 3.6MLOC over 40k files and every single NixOS eval loads a good chunk of that, realistically multiple times. The main issue is that caching was never a thought in the architecture and adding it afterwards is really tricky | 17:21:27 |
| Qyriad | don't forget that every single Nixpkgs package loads hundreds if not thousands of other nix files | 17:22:24 |
| piegames | yes, we're close enough to that atm, there still is one full AST walk for bindVars that's still costly (I tried to remove it with horrors but unexplicably did not make anything faster) and general AST allocation cost (more bump allocators would help a lot there probably) | 17:22:40 |
| Qyriad | In reply to @qyriad:katesiria.org
don't forget that every single Nixpkgs package loads hundreds if not thousands of other nix files (and instantiates half a gazillion derivations…) | 17:22:52 |
| piegames | we won't get much faster than that (though I expect that a parse that can directly emit Bytecode should be a little bit faster still because more compact representation), but the Rust rewrite still needs to be at least as fast as now and that's no small feat | 17:23:20 |
| piegames | * we won't get much faster than that (though I expect that a parser that can directly emit Bytecode should be a little bit faster still because more compact representation), but the Rust rewrite still needs to be at least as fast as now and that's no small feat | 17:23:45 |
 Rutile (Commentator2.0) feel free to ping | In reply to @piegames:flausch.social
we won't get much faster than that (though I expect that a parser that can directly emit Bytecode should be a little bit faster still because more compact representation), but the Rust rewrite still needs to be at least as fast as now and that's no small feat Could the rust version be possibly be writtten with cache in mind from the beginning? | 17:25:15 |
| piegames | yes, but the issue is, what is your cache key? | 17:25:37 |
| piegames | inode number and ctime might be our best bet | 17:28:31 |
| piegames | but in terms of cachable data structures, bytecode gives us that for free | 17:29:02 |
| piegames | * but in terms of cachable data structures, bytecode gives us that bit for free | 17:29:28 |
