| 18 May 2025 |
 Mic92 | We only need two fds for the case you were trying to fix. And my hope is that using multiple fds in select() is so common that it just works even on macOS. | 14:57:10 |
| Mic92 | This would avoid platform specific code. | 14:57:29 |
 Alyssa Ross | It's not the number of fds that select is limited by — it's the fd numbers | 14:59:21 |
| Alyssa Ross | like if you have two fds but both of them are high values that's not compatible with select | 14:59:39 |
| Alyssa Ross | I have heard that select on macOS does work though | 14:59:49 |
| Mic92 | Ok. that makes it a non-starter for this api. | 14:59:59 |
| 19 May 2025 |
|  @orzklv:floss.uz left the room. | 18:04:43 |
|  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 |
