| 22 Feb 2026 |
 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 |
