| 26 Oct 2024 |
 Mic92 | It shouldn't be too complicated to try it out for attrsets I think | 09:01:28 |
|  svrana left the room. | 15:51:41 |
| svrana joined the room. | 15:53:29 |
|  ubalot joined the room. | 16:05:09 |
|  Morgan (@numinit) left the room. | 23:46:30 |
| Morgan (@numinit) joined the room. | 23:47:43 |
| 27 Oct 2024 |
| Morgan (@numinit) set a profile picture. | 07:18:28 |
|  @rczb:envs.net joined the room. | 08:08:26 |
| @rczb:envs.net left the room. | 08:09:18 |
|  @jolly.roberts:matrix.org joined the room. | 15:19:15 |
| 29 Oct 2024 |
|  Samuel joined the room. | 03:18:06 |
 connor (burnt/out) (UTC-8) | I decided to start with lists hoping it’d be a smaller change
I have to say I don’t understand the rules governing lifetime of values
I also think the way Values are constructed (pointers and mutation) makes it difficult to use immer in an idiomatic way (at least, as far as I can infer from the docs)
At any rate, most of the tests pass so I’ll upload the work in progress hopefully today | 09:01:13 |
|  @docbrown101:matrix.org left the room. | 10:35:44 |
 tazjin |
I have to say I don’t understand the rules governing lifetime of values
the rule is "YOLO"
| 12:11:38 |
| connor (burnt/out) (UTC-8) | I don't know enough CPP to know if you're kidding lmao | 17:34:31 |
 K900 | That's the rule for all C++ code | 17:35:37 |
 Bryan Honof | Redacted or Malformed Event | 18:49:16 |
| Bryan Honof | Wrong channel, sorry. 🙃 | 18:54:38 |
|  eva changed their profile picture. | 22:26:41 |
| 30 Oct 2024 |
| connor (burnt/out) (UTC-8) | Design-wise, why does so much of libexpr take in pointers, mutate state, and return void? Is this "the way" interpreters or state management should be implemented when using C++?
To be clear, not criticizing! Just wanted to check if this pattern is one that just happened over the evolution of the codebase, is known to be a good way to do the implementation, or something else. | 00:19:11 |
|  Lach joined the room. | 00:25:02 |
 emily | it's a codebase from 2003 :) | 00:25:15 |
| emily | trying to infer any kind of best practice from the Nix code can only lead to madness, I think. it is the way it is because it is the way it is. it's research code that has survived 20 years | 00:25:49 |
 tomberek | The lazy evaluation of thunks is represented by mutation of a Value. This way pointers to it remain valid. This also allowed for using boehmgc to do GC. This is the remnants of an evaluation method that worked okay when Nixpkgs was far smaller and had far fewer layers of abstraction.
A new evaluation engine would be interesting. Some people discussed this a bit at NixCon (@flokli ), but implementing it and showing an actual speedup remains to be done. | 00:36:04 |
| tomberek | I'd love to see if this provides any benefit. Not sure how much effort it would be to run a test. | 00:40:50 |
| connor (burnt/out) (UTC-8) | Alrighty, this is as far as I've gotten: https://github.com/NixOS/nix/pull/11767
It builds in a shell (not all the tests pass, though I guess you could use nix build -L .#hydraJobs.buildNoTests.x86_64-linux?) and I used it to build hello world.
Haven't done any investigation into performance because I think that'd be premature (but anyone is welcome of course). | 01:25:10 |
| tomberek | I specifically suspect that the update operator for attrs would benefit from such persistence. | 01:51:26 |
| tomberek | (There are lots of instances of large attrsets in Nixpkgs being appended to.) | 01:52:02 |
 magic_rb | This is interesting, i am definitely looking forward to any progress on this front | 02:32:52 |
| connor (burnt/out) (UTC-8) | I've got the attention of a goldfish and split my time with maintaining CUDA packaging so expect progress to be sporadic ;) | 02:42:24 |
