11 Jan 2025 |
| pandapip1 joined the room. | 21:23:02 |
14 Jan 2025 |
Mic92 | I used nixstorerealize instead of buildPaths in the past | 13:39:33 |
Mic92 | I used nix_store_realize instead of buildPaths in the past | 13:39:49 |
15 Jan 2025 |
Robert Hensing (roberth) | contributions welcome | 06:19:41 |
Robert Hensing (roberth) | we do have nix_string_realise , in case your paths come from the same string in the expression language | 06:20:43 |
Robert Hensing (roberth) |
what's the difference
The string one also works for strings that have multiple store paths in them, whereas nix_store_realise doesn't require the nix-expr library
| 06:22:58 |
Leonardo Santiago | honestly I have been thinking about contributing given the amount of time I have been reading nix source code the last couple of days, but I have literally 0 experience in C++ | 15:23:43 |
Leonardo Santiago | and most of the code still confuses me, specially regarding inheritance and file importing that creates "spooky action from distance" | 15:25:04 |
Leonardo Santiago | but yeah, right now I need to implement a way to build a derivation through the C FFI, and honestly I think the easiest way will be to re-export as string, eval it, and use nix_string_realise onto it | 15:32:40 |
16 Jan 2025 |
| watersucks changed their profile picture. | 02:55:40 |
| watersucks changed their profile picture. | 03:07:10 |
17 Jan 2025 |
Leonardo Santiago | hmph, not as easy as I thought. when you parse the derivation from the file, it loses the contexts on the strings, and there's not simple way to readd it, such that if I just try to export it back to a derivation it does not return to the same one | 18:34:15 |
Leonardo Santiago | my idea was to parse builtins.derivation as a function and then pass an attrset as argument, to see if I could generate the exact same derivation, but I guess this is not as easy as I initially thought | 18:35:01 |
19 Jan 2025 |
Leonardo Santiago | I mean, it works, but it does not generate the same derivation back, because I cannot for the life of me make inputSrcs and inputDrvs appear in the resulting derivation. | 16:01:45 |
Leonardo Santiago | even if I add buildInputs and inputDrvs and inputSrcs as attributes in the argument passed to builtins.derivation , they do not put anything in the correct fields and instead only appear as environment variables | 16:03:56 |
Leonardo Santiago | can anyone think of any simple way of doing this? I'm very close to just trying to hack exporting derivations in the C API, though I'm fairly certain I'm not qualified for doing it | 16:05:33 |
20 Jan 2025 |
Robert Hensing (roberth) | That's kind of the purpose of inputDrvs and inputSrc .
correct fields
Which fields would that be? Are you trying to produce the full package attribute set? That can not be recovered from the .drv due to things like meta and passthru to put it simply
| 08:09:59 |
| emily 🐾 joined the room. | 23:50:01 |
| emily 🐾 left the room. | 23:50:12 |
21 Jan 2025 |
Leonardo Santiago | ...all of them? As I've stated before, I'm trying to reproduce the nix develop behavior utilizing a different caching mechanism for evaluation | 03:00:54 |
Leonardo Santiago | the problem is that I realised that source $stdenv/setup during shell entering is very slow and nix develop can only be so fast because it also caches that behind a derivation | 03:01:35 |
Leonardo Santiago | I'd like to do what it does (cache source $stdenv/setup by making it an output of a derivation) but in order to do it I'd need to fiddle with the actual derivation | 03:02:19 |
Leonardo Santiago | specifically, I'd like to be able to write it back to the store, so that it can be built, but if I just do it the dumbest way possible (copy the parsed env vars and pass it to derivation primop) then inputSrc and inputDrvs get empty | 03:04:49 |
Leonardo Santiago | I know that it's not strictly necessary to get it working in this specific case, but it's expected from the library I'm writing that parse_drv(parse_drv(path).serialize()) == parse_drv(path) | 03:11:58 |
Leonardo Santiago | * specifically, I'd like to be able to write it back to the store, so that it can be built, but if I just do it the dumbest way possible (copy the parsed env vars and pass it to derivation primop) then inputSrc and inputDrvs are generated empty | 12:33:37 |
24 Jan 2025 |
| @idioticself55:matrix.org joined the room. | 14:19:47 |
Leonardo Santiago | about memory management | 16:45:11 |
Leonardo Santiago | let's say I have a Value , how am I supposed to free it? there's nix_gc_decref and nix_value_decref | 16:45:50 |
Leonardo Santiago | * let's say I have a Value , how am I supposed to free it? there's nix_gc_decref and nix_value_decref and there's not a clear explanation on which should be used when. | 16:46:30 |
Leonardo Santiago | after calling nix_alloc_value , if I don't cal nix_value_incref nor nix_gc_incref , which one should I use to decrement the gc? and am I expected to run anything else in order to force it to be freed? | 16:47:33 |