| 15 May 2024 |
|  Mia :) changed their profile picture. | 18:39:55 |
 @jade_:matrix.org | In reply to @qyriad:katesiria.org
We are killing the online flake registry julia submitted a patch for this today :O
i do wonder if we want to be able to support alternate "online" registry fs paths
| 18:47:00 |
| @jade_:matrix.org | (in case enterprise users actually use this thing. or something. but otoh we could just ship a deprecation warning and see who complains) | 18:47:31 |
 Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | how come we have builtins.fromTOML but not builtins.toTOML ? | 18:53:39 |
| Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | its fine, we have a writer for toml and worst case i can just write and then read the written thing (though ugly). But figured i'd ask as it is weird... | 18:56:15 |
 aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | In reply to @grimmauld:grimmauld.de
how come we have builtins.fromTOML but not builtins.toTOML ? I remember there was an issue in nix about this. The main idea is that the toml library implementation is unstable? | 18:58:27 |
| Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | One more question: genAttrs can generate an attrset from a list of names; is there an equivalent that generates an attrset to a list of values taking a function that assigns a name to each value instead of a value to each name? | 19:03:59 |
| @jade_:matrix.org | In reply to @aleksana:mozilla.org
I remember there was an issue in nix about this. The main idea is that the toml library implementation is unstable? yeah that makes sense, you would need a canonical repr and trusting someone else's code to do that is a huge risk | 19:04:44 |
| @jade_:matrix.org | i really desperately want to have builtins not form part of the derivation interface somehow | 19:05:08 |
| @jade_:matrix.org | really what i want is that someone just goes and shoves this shit into a lib that is not on our stability guarantees | 19:05:24 |
| Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | In reply to @jade_:matrix.org
yeah that makes sense, you would need a canonical repr and trusting someone else's code to do that is a huge risk Yeah makes sense to me. Bit awkward but workable considering there is a writer. With my current approach i need to write it anyways so might as well. | 19:05:28 |
| @jade_:matrix.org | this is the real reason i want builtins.importWasm or whatever | 19:05:38 |
| @jade_:matrix.org | i want to make this stuff versioned separately from the evaluator | 19:06:01 |
| Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | In reply to @jade_:matrix.org
yeah that makes sense, you would need a canonical repr and trusting someone else's code to do that is a huge risk * Yeah makes sense to me. Bit awkward but workable considering there is a writer in nixpkgs lib. With my current approach i need to write it anyways so might as well. | 19:06:10 |
 Qyriad | 🤔 Maybe Nixpkgs could/should ship builtin-adding plugins? | 19:06:33 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | That sounds like IFD | 19:06:45 |
| Qyriad | No, it precisely would avoid IFD | 19:06:56 |
| Qyriad | Lix has literal plugin support | 19:07:12 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | In reply to @qyriad:katesiria.org
No, it precisely would avoid IFD I'd like to have IFD to avoid this | 19:07:17 |
| Qyriad | Like Lix can load arbitrary shared libraries which can add arbitrary primops to the evaluator | 19:07:30 |
| Qyriad | This functionality just barely sees any use | 19:07:39 |
 puck | this requires a stable ABI | 19:07:59 |
| Qyriad | In reply to@aleksana:mozilla.org
I'd like to have IFD to avoid this That's in the "fixing IFD path", which we want to do but is a ways off | 19:08:01 |
| Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | Oh god what discussion have i started again... But hey, at least people are being productive over here :3 | 19:08:01 |
| Qyriad | In reply to@puck:puck.moe
this requires a stable ABI Yeah true | 19:08:10 |
 Lily Foster | In reply to @grimmauld:grimmauld.de
One more question: genAttrs can generate an attrset from a list of names; is there an equivalent that generates an attrset to a list of values taking a function that assigns a name to each value instead of a value to each name? you could make your own inverted genAttrs i guess? something like genAttrsFromValues = values: f: builtins.listToAttrs (builtins.map (v: builtins.nameValuePair (f v) v) values) | 19:08:29 |
| Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | OH GOD | 19:08:48 |
| Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | I'll have a poke then :) | 19:09:14 |
| Qyriad | brb adding a new lib.attrsets API =P | 19:09:42 |
| Lily Foster | (is there a lib function to invert attrset names/values too?) | 19:09:47 |
