12 Sep 2024 |
| @kaisercalm:matrix.org joined the room. | 11:04:54 |
| @kaisercalm:matrix.org left the room. | 11:05:32 |
h7x4 | I realize this might be implementation specific and doesn't belong in this channel, but does anyone know whether there is a time/space complexity table for the builtins anywhere? I find it hard to reason about the complexity of the functions on top when it comes to builtins like listToAttrs , // and removeAttrs . | 14:46:20 |
emily | time complexity is a subtle thing when you're talking about a lazy language, but my understanding is that attrsets are strict in the spine and represented as flat tables | 14:55:00 |
emily | so listToAttrs and // should be O(n), not sure about removeAttrs | 14:55:22 |
h7x4 | That makes sense I guess. With the assumption that nix will make just enough space to contain those n items and nothing more, until it is told to do so by doing another // , and that will always instantiate a new allocation? | 15:02:40 |
h7x4 | * That makes sense I guess. And I'm assuming nix will make just enough space to contain those n items and nothing more, until it is told to do so by doing another // , and that will always instantiate a new allocation? | 15:07:45 |
| Elorm left the room. | 15:51:04 |
| Elorm joined the room. | 15:55:42 |
emily | not sure. I wouldn't be surprised if there is the usual powers of two / prime numbers size bucket stuff going on | 15:58:16 |
tomberek | Other than in the trivial cases, "//" will always allocate a new table; the values can often re-use existing values as pointers. (Reference: https://github.com/NixOS/nix/blob/master/src/libexpr/eval.cc#L1913 )
Robert has a proof-of-concept where chains of "//" would be collected and resolved at once, reducing allocations. I've also tried out a few related things, but the GC is quite efficient. There might be some gains here, but it is easy to accidentally make a smarter algorithm that ends up slower. | 17:21:58 |
| Denilson Ebling joined the room. | 18:18:43 |
| llakala joined the room. | 19:43:48 |
13 Sep 2024 |
| @chrischinch:matrix.org left the room. | 14:57:15 |
aleksana (force me to bed after 18:00 UTC) | This case {
/** This is a random doc-comment */
a2 = let
c = d: d + 1;
in b: c b;
}
doesn't render doc-comments in Nix 2.24, doesn't output name of the function, and the position is reported to be the fifth line (argument) instead of the third. Is this the ideal behavior or just not implemented? Are we expected to move let-in after the arguments? This currently affects lib.getName and lib.getVersion . | 15:02:54 |
aleksana (force me to bed after 18:00 UTC) | The related code in Nix implementation is here: https://github.com/NixOS/nix/blob/11452ce674918084be9aac1d92e1481177f78e0c/src/libexpr/eval.cc#L571 | 15:05:15 |
14 Sep 2024 |
| lexserest joined the room. | 11:06:45 |
| Mahmoud changed their profile picture. | 11:30:49 |
| SomeoneSerge (utc+3) changed their display name from SomeoneSerge (nix.camp) to SomeoneSerge (utc+3). | 11:37:38 |
| Tennix joined the room. | 14:04:11 |
| mwoodpatrickmx joined the room. | 16:10:36 |
| bonofiglio joined the room. | 22:53:42 |
15 Sep 2024 |
| Daniel Beecham joined the room. | 14:50:38 |
| Daniel Beecham set a profile picture. | 14:59:56 |
| Daniel Beecham changed their display name from dbeecham to Daniel Beecham. | 15:00:06 |
| @matt:mymu.pub left the room. | 19:08:19 |
| @jordan.steinke:matrix.org changed their display name from Jordan Steinke 🪻 to Jordan🪻. | 19:47:32 |
| carbolymer` joined the room. | 21:38:58 |
16 Sep 2024 |
| @matrix:03j.de left the room. | 17:20:52 |
| silentlurker joined the room. | 19:53:40 |