| 2 Nov 2021 |
niksnut | bew: Hm no, I'll create an issue. | 14:00:14 |
niksnut | moritz.hedtke: Yes | 14:00:20 |
niksnut | Getting mysterious errors on macOS in GitHub actions for Nix PRs (and other repos):
/nix:
Error: unable to perform operation. (-400)
Error: unknown indexing state.
child_process.js:642
throw err;
^
Error: Command failed: /Users/runner/work/_actions/cachix/install-nix-action/v14/lib/install-nix.sh
at checkExecSyncError (child_process.js:621:11)
| 14:04:21 |
niksnut | Anybody have an idea where this is coming from? | 14:04:29 |
balsoft | The only relevant place where it can fail is https://github.com/cachix/install-nix-action/blob/master/lib/install-nix.sh#L55 | 14:20:42 |
balsoft | * The only relevant place I can see where it can fail is https://github.com/cachix/install-nix-action/blob/master/lib/install-nix.sh#L55 | 14:20:50 |
balsoft | Ahh ok, I was wrong https://github.com/cachix/install-nix-action/commit/3e0e991ad23eecb3d772c65a89c0ab57adb858f6#diff-eecb50daed745e6b4e91c28b52dd71041a69e97e4b254e32b68cd38f9e43dd41 | 14:26:29 |
balsoft | It's just an old action version :( | 14:26:36 |
fzakaria | What do people think about using $ORIGIN in RPATH vs. explicit /nix/store | 19:59:58 |
fzakaria | if things were relative paths, then they can be moved to other /nix/stores | 20:00:08 |
matthewkenigsberg | fzakaria I heard Regnat was working on being able to move /nix/store | 20:16:55 |
sterni | you can already in theory, but you need to recompile everything anyways | 20:17:20 |
sterni | as long as you use a derivations outPath it's fine | 20:17:32 |
balsoft | In reply to @matthewkenigsberg:matrix.org fzakaria I heard Regnat was working on being able to move /nix/store Store references are not limited to RPATHs | 20:34:08 |
balsoft | * Store references are not limited to RPATHs | 20:34:18 |
sterni | also the drv files already reference the store path, so moving the store path wouldn't be useful as it wouldn't match the drv hash in that store | 20:52:12 |
Moritz Hedtke | niksnut: Are Expr* not deallocated? Because with my limited understanding of AdressSanitizer it seems like it. And if thats the case would a PR to fix that be accepted (probably using unique_ptr if that works)? | 21:44:24 |
| 3 Nov 2021 |
fzakaria | balsoft: store references could still always be written relatively | 04:12:24 |
fzakaria | since everything is present within the store itself | 04:12:44 |
niksnut | In reply to @moritz.hedtke:matrix.org niksnut: Are Expr* not deallocated? Because with my limited understanding of AdressSanitizer it seems like it. And if thats the case would a PR to fix that be accepted (probably using unique_ptr if that works)? Indeed they're not. Keeping track of the lifetime of ASTs would just be unnecessary overhead (since usually we can't free them until the end of the program anyway). | 10:19:05 |
niksnut | Using unique_ptr wouldn't work, they would have to be allocated using the Boehm GC, since Values have pointers to Exprs. | 10:20:03 |
Moritz Hedtke | Mmh damn. I also realized that using GC for some and not using for some other values is impressively hard to reason about at boundaries and thought about just using it for everything. But I don't know how big the overhead would be. | 10:21:20 |
Moritz Hedtke | In reply to @niksnut:matrix.org Using unique_ptr wouldn't work, they would have to be allocated using the Boehm GC, since Values have pointers to Exprs. Good to know | 10:21:28 |
Moritz Hedtke | In reply to @moritz.hedtke:matrix.org Mmh damn. I also realized that using GC for some and not using for some other values is impressively hard to reason about at boundaries and thought about just using it for everything. But I don't know how big the overhead would be. Are there any large (amounts) of objects where using the GC would be bad? | 10:25:40 |
Moritz Hedtke | In any case I could probably just use the GC for everything for my AddressSanitizer efforts and not upstream it if it causes performance regressions | 10:28:20 |
Moritz Hedtke | Any other ideas? | 10:28:43 |
niksnut | Yeah you could try using Boehm for allocations. Since Boehm is generational, it's possible the overhead will be small. | 10:32:21 |
niksnut | Though now that I look at it, it seems we're not using the incremental/generational collector... | 10:33:36 |
tomberek | Thoughts on bundle API? it currently passes a program path, rather than a structured attrset which would better support additional uses. | 12:30:26 |
Ambroisie | In reply to @tomberek:matrix.org Thoughts on bundle API? it currently passes a program path, rather than a structured attrset which would better support additional uses. Are there actual uses of the bundle API? I tried looking for some but only found nix-bundle | 12:43:24 |