| 16 Aug 2025 |
 connor (he/him) (UTC-7) | 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 (he/him) (UTC-7) | 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 |
| emily | of which there were quite a few last time I tried using them IIRC | 21:10:02 |
| fzakaria | pkg-config --list-all | grep boost
boost boost - Pkg-config file for boost
| 21:10:07 |
| emily | yeah Nixpkgs patches one in | 21:10:17 |
| emily | for some reason | 21:10:19 |
| emily | probably we should not | 21:10:21 |
| fzakaria | what's the answer then for pkg-config if you do depend in boost ? | 21:11:02 |
