| 21 Feb 2026 |
 vczf | I was able to get some info out of value after adding the suggested line to my gdbinit | 18:33:34 |
| vczf | I’m not experienced with c++, so I might just be expecting too much from gdb vs java/dart as far as debugging goes | 18:35:35 |
 piegames | Some people swear on gdb, but for me it's a downgrade from IntelliJ Java land | 18:36:20 |
|  lolvich joined the room. | 23:34:43 |
| 22 Feb 2026 |
|  @yimi4:matrix.org changed their display name from yimi to moved to @yimi:yinix.me. | 19:38:41 |
| @yimi4:matrix.org left the room. | 19:40:07 |
 raitobezarius | vczf FYI, Gerrit etiquette is that "ack" means "you read the comment but you are not addressing it" and "done" means "you read the comment and addressed it" usually | 20:43:59 |
| raitobezarius | (it doesn't really matter a lot in practice because we can compare patchsets) | 20:44:32 |
| vczf | In reply to @raitobezarius:matrix.org
vczf FYI, Gerrit etiquette is that "ack" means "you read the comment but you are not addressing it" and "done" means "you read the comment and addressed it" usually Should I have left it unresolved? Felt odd to leave it unacknowledged when it may be some time before I update the code | 22:31:15 |
|  mei 🌒& changed their profile picture. | 22:54:40 |
| raitobezarius | In reply to @vczf:matrix.org
Should I have left it unresolved? Felt odd to leave it unacknowledged when it may be some time before I update the code Yeah it helps keep the "todo list" synced with your reviewer to leave unresolved if the code is non updated | 23:15:45 |
| 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 |
