| 16 Aug 2025 |
 connor (burnt/out) (UTC-8) | I would also like such tooling, but I really don't like reading or writing C/C++ :(
I've only ever read/written C/C++ in anger and I very much consider myself incompetent with C/C++
I haven't looked at or touched the Immer stuff in a long while; the biggest road blocks I saw to moving forward with it were:
- the issue where the GC would still collect values while they were needed
- creating wrappers around lists/bindings to abstract over the implementation (and the changes that would cause to the C API), although I think you did or started this with your
Value refactoring
- rewriting relevant portions of the evaluator to use the different implementations offered by Immer (using the mutable APIs where appropriate)
- making changes to the stats reported by the Nix evaluator
- the lack of any sort of benchmark suite or platform on which to benchmark making it hard to discern what exactly changed and how
I think 1. was being looked at by the author of Immer, not sure whether they ever got the chance to get into it; 2. and 5. should happen regardless as a code/project hygiene thing.
Fundamentally I still think it's important we look at the data structures Nix offers, the ways in which those data structures are most commonly used, and implementations that make those operations fast :l
| 19:20:50 |
 magic_rb | Well going by how lambda calculus is evaluated in general. The import will be evaluated anew for each N. So what id try is wrapping the genList with a map seq to force evaluation of each thunk explicitly and see if that helps | 19:32:44 |
| magic_rb | But tbh i have no clue how nix evals, im going by how GHC does things, kinda. Just my first idea when i read your message | 19:34:27 |
| connor (burnt/out) (UTC-8) | There’s an import cache | 22:44:45 |
 Sergei Zimmerman (xokdvium) | In reply to @connorbaker:matrix.org
There’s an import cache The import is cached, but the function call is not. | 22:47:40 |
| connor (burnt/out) (UTC-8) | Also IIRC using JSON output forces everything | 22:52:32 |
| connor (burnt/out) (UTC-8) | Any ideas if the value storing the result of import applied to the path would be cached, or if the use of import is unrelated to what’s happening here, memory usage wise | 22:53:57 |
 emily | you're instantiating numClosures Nixpkgs and none of them are garbage | 22:58:26 |
| 17 Aug 2025 |
| connor (burnt/out) (UTC-8) | It's my understanding that all of them should be garbage, because the only value retained from the instantiation is forced with deepSeq and should hold no references to that instantiation of Nixpkgs (though I suppose since it's a string with context it could hold references that way?). Put another way, is it possible there are still live references to those instances of Nixpkgs, or something about their instantiation is keeping them around? | 05:21:43 |
| emily | hmm. maybe you are right. well, I don't think deepSeq is doing anything there since strings are atomic afaik | 05:22:31 |
| emily | so each thunk will keep around a reference until it is forced at least | 05:22:52 |
| emily | but then the instantiation is in the thunk so… eh | 05:23:02 |
 Robert Hensing (roberth) | deepSeq is not sufficient to drop all closures, as functions (lambdas) are normal form, but also have closures, much like thunks. You'd have to drop all functions (if any exist in your result, idk) | 18:54:59 |
| emily | .drvPath shouldn't contain any functions I hope | 18:55:58 |
 fzakaria | It won't even run it though; using CLIon's gtest runner -- do you have it working? | 20:22:30 |
| fzakaria | I was looking today at https://github.com/jart/json.cpp -- vs nlohman | 20:23:42 |
| emily | the JSON library is extremely load-bearing for evaluation semantics, please don't switch it out without a very thorough test suite and fuzzing; the switch to nlohmann_json in 2.4 already produced a lot of eval changes | 20:30:05 |
| fzakaria | Just sharing it; I sponsor jart via GitHub (I wish a larger amount) so I try to follow up on the work she does. -- I really like all the work she does + I find her code outstanding. | 20:32:43 |
| Sergei Zimmerman (xokdvium) | Also let's first handle the TOML fiasco | 20:40:26 |
| emily | I did my best :D | 20:41:03 |
| fzakaria | was that solvable ? I thought it's just not because of the spec | 20:41:06 |
| emily | it was solved by fixing the TOML spec violation in Nixpkgs | 20:41:30 |
| emily | (that 2.3 already barfed on, and that was present when 2.3 was still minver, so it was just unambiguously a bug) | 20:41:45 |
| fzakaria | is boost supposed to be a pkg-config? | 21:05:38 |
| fzakaria | i'm surprised i am missing it when trying to use Nix as a library
ix/store/dxar61b2ig87cfdvsylfcnyz6ajls91v-nix-2.28.3-dev/include/nix/util/fmt.hh:4:10: fatal error: boost/format.hpp: No such file or directory
4 | #include <boost/format.hpp>
| ^~~~~~~~~~~~~~~~~~
| 21:05:50 |
| fzakaria | I would have thought Nix .pc files should declare all their dependencies or something | 21:06:17 |
| fzakaria | I add boost as a buildInput and it's fixed but .. feels wrong | 21:07:04 |
| emily | no, Boost does not support pkg-config | 21:09:42 |
| emily | but that sounds like a bug in the Nix .pc files | 21:09:55 |
| fzakaria | I see it when I added it boost specifically though | 21:10:00 |
