| 22 Feb 2026 |
 raitobezarius | If you ack, your reviewer is the next one who needs to act | 23:16:01 |
| raitobezarius | When it should be you who should act | 23:16:14 |
 vczf | Gotcha | 23:18:24 |
| 23 Feb 2026 |
 sky1e | I think besadii had a spurious failure checking https://gerrit.lix.systems/c/lix/+/5250. Can someone poke it for me? | 19:32:07 |
| sky1e | ty! | 20:08:31 |
| 24 Feb 2026 |
 Sergei Zimmerman (xokdvium) | Would love to hear some thoughts on https://github.com/NixOS/nix/pull/15327. I recall chatting about symbol table order shenanigans and this seems to be an ok-ish solution to the f-ed up situation. Evaluation order already changes in practice, so making it more defined wouldn't be that bad I supppose? | 00:44:36 |
| Sergei Zimmerman (xokdvium) | * Would love to hear some thoughts on https://github.com/NixOS/nix/pull/15327. I recall chatting about symbol table order shenanigans and this seems to be an ok-ish solution to the f-ed up situation. Evaluation order already changes in practice (and thus symbol table), so making it more defined wouldn't be that bad I supppose? | 00:44:57 |
|  TikTorchic18 joined the room. | 03:47:34 |
 piegames | Any alternative solutions to this? | 07:20:52 |
| Sergei Zimmerman (xokdvium) | The only thing that comes to mind is to keep the status quo. One way or another some canonical order would have to be used I suppose. The cost of sorting doesn’t seem to matter that much, but there could be a way to amortise the cost by memoising the sorted order for commonly used attribute set shapes | 09:53:07 |
 K900 | Maybe it's time to make attrsets btreemaps after all | 09:53:53 |
| Sergei Zimmerman (xokdvium) | In reply to @k900:0upti.me
Maybe it's time to make attrsets btreemaps after all Not sure about the memory usage there… They did use to be just a std::map before 2010 (circa 0.16) | 09:54:45 |
| K900 | I mean it shouldn't be that much bigger but it will also undo the stacking trick | 09:55:14 |
| Sergei Zimmerman (xokdvium) | TVL’s fork of 2.3 did play around with that too | 09:55:16 |
| K900 | I wonder if there's like A Paper somewhere | 09:56:39 |
| Sergei Zimmerman (xokdvium) | In reply to @k900:0upti.me
I mean it shouldn't be that much bigger but it will also undo the stacking trick It would add quite a bit of pointer chasing even with a high degree of internal nodes too. And memory usage would probably jump by a lot. If the order is defined in the strings then lookup then also does string comparisons | 09:57:25 |
| K900 | I mean btrees shouldn't be that pointer chasey | 09:58:06 |
| K900 | With big enough node sizes | 09:58:12 |
| K900 | I think the rustc people found that it's basically even perf wise | 09:58:32 |
| K900 | When rustc got switched from hashmaps to btreemaps in a bunch of places | 09:58:41 |
| K900 | For r11y | 09:58:43 |
| Sergei Zimmerman (xokdvium) | I mean, if somebody does the crazy and switches to be a better representation that’d be great. FWIW there’s an immutable CHAMP implementation in immer that connor baker tried using for attrsets | 10:04:28 |
| Sergei Zimmerman (xokdvium) | But that’s not exactly the thing we want for a well-defined lexical order. For now sorting on demand doesn’t seem to cost too much to be a blocker for fixing the impurity | 10:06:48 |
| Sergei Zimmerman (xokdvium) | * I mean, if somebody does the crazy and switches to a better representation that’d be great. FWIW there’s an immutable CHAMP implementation in immer that connor baker tried using for attrsets | 10:10:21 |
| piegames | In reply to @piegames:flausch.social
Any alternative solutions to this? How about always evaluating all values in comparisons, so that eval order does not matter because it's not as lazy? | 10:17:35 |
| piegames | Or how about treating values that throw as incomparable instead of propagating it up and beyond the comparison? | 10:18:22 |
| Sergei Zimmerman (xokdvium) | In reply to @piegames:flausch.social
Or how about treating values that throw as incomparable instead of propagating it up and beyond the comparison? It’s not really only about throw expressions though. Forcing all values would be a workable, though a more radical solution | 10:20:49 |
| piegames | Do we have numbers on how many comparisons even happen in Nixpkgs? My assumption would be that it's not that common and that most instances already fast forward because of the pointer comparison | 10:23:30 |
| Sergei Zimmerman (xokdvium) | Something like ~1M that doesn't shortcircuit and falls through to per-attr equality | 11:19:04 |
| Sergei Zimmerman (xokdvium) | For all drv-paths via -qaP --drv-path for x86_64-linux | 11:19:44 |
