| 19 May 2025 |
|  oak 🏳️🌈♥️ changed their display name from oak 🫱⭕🫲 to oak. | 10:58:46 |
| oak 🏳️🌈♥️ changed their display name from oak to oak 🏳️🌈♥️. | 11:00:36 |
|  mgaughan joined the room. | 20:36:06 |
| 20 May 2025 |
 @trofi:matrix.org | You can make linux select() to work for large FDs as well, but you would have to roll your own bit setting code to avoid glibc's limit (or override FD_SETSIZE). | 05:41:45 |
| 21 May 2025 |
 fzakaria | cherry-pick: https://github.com/NixOS/nix/pull/13241 | 02:28:13 |
 Winter | that should probably have --author set to the original author ^^ | 02:30:45 |
 tomberek | I might be totally clueless, but I don't know why https://github.com/NixOS/nixpkgs/pull/408846 fails on aarch64-linux. Anyone can help? | 03:24:12 |
| @trofi:matrix.org | /build/source/build/src/nix/nix-store: cannot execute: required file not found suggests the binary is corrupted perhaps? | 06:00:09 |
|  WeetHet changed their profile picture. | 10:59:01 |
|  sinan changed their profile picture. | 11:59:58 |
| sinan changed their profile picture. | 12:00:45 |
 emily | is there a way to trace imports of an evaluation that isn't as horribly slow as nix eval -v -v or scopedImport { import = x: builtins.trace x (import x); }? | 13:26:03 |
| emily | actually I guess the latter needs to be recursive which would make it even slower | 13:27:14 |
 Sergei Zimmerman (xokdvium) | In reply to @emilazy:matrix.org
is there a way to trace imports of an evaluation that isn't as horribly slow as nix eval -v -v or scopedImport { import = x: builtins.trace x (import x); }? Hm, do you need the trace to be super precise? Would a flamegraph suffice? | 14:33:28 |
| emily | yes, precision is the aim (dependency tracking) | 14:34:24 |
| emily | though only a subset of paths (beneath a given root) are required | 14:34:39 |
| emily | possibly I can use that to help short-circuit things | 14:35:04 |
 hacker1024 | Is modifying the implementation of `import` in the Nix source itself an option? | 14:36:37 |
| emily | I suppose I'd really rather not :) | 14:46:21 |
| emily | I don't really know why -v -v is slow in the first place | 14:46:35 |
| Sergei Zimmerman (xokdvium) | Can you share a repro for the slowdown? | 14:59:40 |
| emily | just import a fetchTarball of Nixpkgs and do anything with it. but yeah I can put one up in a couple hours | 16:43:13 |
| emily | I'm on Darwin which does have slower FS perf but presumably it shouldn't be amplifying FS operations | 16:43:33 |
| 22 May 2025 |
| emily | Sergei Zimmerman (xokdvium): whoops, sorry for forgetting about this. hm, a minimal reproducer seems way less slower than expected. let me try and see what i was observing | 05:44:49 |
| emily | I can't reproduce. I guess -v -v is great :) | 05:46:34 |
| emily | I wish it would trace other file accesses though | 05:46:45 |
| emily | like builtins.readFile | 05:46:54 |
| emily | does anyone understand why nix eval .?rev=X#foo will sometimes produce "copying …" messages even when the rev did not change? | 09:35:24 |
 Mic92 | https://discourse.nixos.org/t/nix-2-29-0-released/64609 Nix 2.29.0 released | 13:09:10 |
| Mic92 | I think if you do a lot of -v than it will print the flake cache that causes the copying. | 13:10:53 |
