| 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 |
|  Yongli Blidirmir 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 |
| 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 (or both?)? and am I expected to run anything else in order to force it to be freed? | 16:47:43 |
| 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? should I use both? and am I expected to run anything else in order to force it to be freed? | 16:48:13 |
| Leonardo Santiago | the documentation in nix_alloc_value says that one should use nix_gc_decref but there's no explanation regarding when (if?) to use nix_value_decref | 16:48:43 |
| Leonardo Santiago | okay, looking at the code it's clear that value_decref is just a gc_decref behind the curtains so it shouldn't make a difference, but the API sure could use some explanation/refinement here | 16:52:16 |
| Leonardo Santiago | one of my concerns is that nix flake check takes way too much memory (32GB~) as we have a ton of hosts to check (200~), and surely that is because it's not freeing the previous hosts while iterating, and so my idea was to try to explicitly evaluate and deallocate each attribute | 17:02:02 |
| Leonardo Santiago | ...but the memory is not being freed? I don't understand what is going on, there should only be one ref as the Value's themselves are not being incref'd, and on rust Drop it's calling decref to hopefully free it once and forall | 17:03:33 |
| Leonardo Santiago | but that doesn't seem to be happening? or at least, the memory footprint isn't getting any smaller | 17:03:49 |
| Robert Hensing (roberth) | nix_alloc_value should be released with nix_value_decref. The main benefit for now is that it has a more specific type, but future evaluators might hypothetically require this | 17:58:13 |
| Robert Hensing (roberth) | as for the garbage collection, neither bdwgc (a conservative gc) nor the interpreter data model are particularly conducive to gc. See https://github.com/NixOS/nix/issues/8621, and for the representation of closures: https://github.com/NixOS/nix/issues/8285 | 18:01:13 |
| Robert Hensing (roberth) | Leonardo Santiago: ^ | 18:01:23 |
| Leonardo Santiago | not sure I 100% understand the issue, I'm not holding a reference to a closure | 18:08:51 |
