| 11 Jul 2023 |
 @piegames:matrix.org | I thought the idea was to have local module system instances for individual packages or groups thereof | 10:39:01 |
 profpatsch | that sounds … even worse? | 11:12:29 |
| @piegames:matrix.org | I don't know | 11:16:56 |
| @piegames:matrix.org | IMO we should rewrite all builders so that there is exactly only one override function (or maybe two for now). Because I'm pretty sure this should be possible | 11:18:56 |
 toonn | Has any profiling been done? I'd be interested to see which parts of Nixpkgs a typical system build spends most time in. | 11:20:30 |
 raitobezarius | In reply to @profpatsch:augsburg.one
roberthensing: I don’t think it’s any question I think you are forgetting you are discussing this with the person who works actively on NixOS modules and has ideas to make it fast… | 11:31:33 |
| profpatsch | raitobezarius: It’s fundamentally impossible to make it fast as far as I understand, but I’d love if it were otherwise | 12:27:34 |
| profpatsch | If you can get it to work without having to strictly evaluate all options first, then you might be able to | 12:28:15 |
| profpatsch | but then you have something that’s not the nixos module system anymore, because the semantics is different | 12:28:36 |
 nbp | It would be possible to make NixOS module use less memory and potentially be faster … by implementing it in C++.
But one must understand that the module system, while not evolving frequently is still evolving. And from my point of view, of someone who never managed to get anything large accepted in Nix source code, this is a not an option. | 12:30:54 |
 infinisil | It could be implemented as a Nix plugin | 12:31:50 |
| nbp | Not mentioning the fact that evolution would be restricted to evolution of the Nix binary. | 12:31:54 |
| nbp | Can Nix plugin extend the grammar, to experiment new syntax / primitive? | 12:34:01 |
| @piegames:matrix.org | In reply to @infinisil:matrix.org
It could be implemented as a Nix plugin Are these a thing already? What can they do? | 12:42:09 |
| @piegames:matrix.org | In reply to @nbp:mozilla.org
Can Nix plugin extend the grammar, to experiment new syntax / primitive? Simply being able to efficiently implement external functions exposed in Nix would probably be sufficient | 12:42:47 |
| * @piegames:matrix.org dreams of a WASM interface to Nix, to be able to implement complex functions efficiently in other languages, without being tied to the Nix code base | 12:43:36 |
| nbp | the reason I am asking is for S.O.S. implementation. | 12:43:38 |
| nbp | * the reason I am asking is for S.O.S. implementation draft. | 12:43:59 |
| profpatsch | nbp: does SOS fix the strictness problem of merging options? | 12:58:24 |
| nbp | SOS has nothing to do with modules, so no. | 12:58:45 |
| nbp | SOS focuses on replacing all override* by the update operator. | 12:59:07 |
| profpatsch | Or rather, does it reduce the power of the module system (modules can depend on each others’ config values recursively and cycic-ly) | 12:59:15 |
| profpatsch | because that power is the main reason for the slowness | 12:59:32 |
| profpatsch | you can’t expect a global arbitrary fixed-point to be performant, because there’s literally no optimizations you can make | 12:59:52 |
| profpatsch | esp if you want the result to be a maximally lazy data structure, which for packages definitely has to be the case | 13:00:28 |
| profpatsch | you can say what you want about callPackage, but laziness it does preserve | 13:01:00 |
| nbp | What makes NixOS slow is the delegation of properties. If instead of delegating properties one level at a time, you were to spam all options covered by it … that would reduce the memory and time. | 13:01:15 |
| nbp | This might actually be doable in Nix … | 13:01:28 |
| profpatsch | nbp: what do you mean by “delegation of properties”? | 13:04:06 |
| nbp | mkIf cond { foo = …; } ==> { foo = mkIf cond …; } | 13:05:14 |
