| 7 Aug 2021 |
 balsoft | Yes, exactly. | 20:09:02 |
 tomberek | Okay... then i'd want some sort of warning at least if the underlying flake adds/removes their lock. (compared to the last time i updated my flake.lock). | 20:11:35 |
| balsoft | That would be fairly difficult to implement | 20:12:06 |
| balsoft | We don't keep how we got the input versions in flake.lock | 20:12:37 |
| tomberek | My thought is that it's a bigger change than one would normally expect because the semantics change a bit. Is there a warning just in the situation that there is no flake.lock? | 20:13:58 |
| balsoft | In reply to @tomberek:matrix.org
My thought is that it's a bigger change than one would normally expect because the semantics change a bit. Is there a warning just in the situation that there is no flake.lock? The PR in question doesn't change anything apart from the interactivity requirement for this particular setting. | 20:15:18 |
| tomberek | Yes, sorry. It's a slightly wider question than your PR. | 20:16:11 |
| tomberek | I think we can add an informative output any time there is no flake.lock for an input flake.
* Flake 'myflake' has no lockfile
* Updated 'myflake': ASDSAD -> ASDSADA"
| 20:22:31 |
| tomberek |
hrm... that would be super noisy with nixpkgs | 20:49:51 |
| tomberek | * I think we can add an informative output any time there is no flake.lock for an input flake.
* Flake 'myflake' is not locked
* Updated 'myflake': ASDSAD -> ASDSADA"
| 21:06:48 |
| 8 Aug 2021 |
 Las | Wasn't Nix going to support storing Git repositories natively in /nix/store? I seem to remember an issue about it on https://github.com/NixOS/nix. | 15:24:01 |
|  Kha joined the room. | 15:27:54 |
| tomberek | #1006 has discussion ^^^^ | 15:31:47 |
| Las | Thanks! | 15:32:33 |
|  infinisil removed their profile picture. | 22:48:52 |
| 9 Aug 2021 |
 manveru | i wonder if there's even a way to fix https://github.com/NixOS/nix/blob/master/src/libexpr/symbol-table.hh#L79 easily... maybe using std::unordered_set::count first to find the key without too many allocations and making life a bit easier for our GC? But of course that adds CPU overhead by doing the lookup twice... | 08:47:22 |
 Mic92 | manveru: what do you save this way? | 12:13:14 |
| Mic92 | * manveru: what do you safe this way? | 12:13:22 |
| Mic92 | Ah constructing a string. | 12:13:37 |
| manveru | yeah :) | 12:13:43 |
| manveru | would need to bench to see if it's worth it... just stumbled over it when reading the code | 12:14:08 |
| Mic92 | I was also trying to optimize the very same code yesterday | 12:14:25 |
| Mic92 | There are different hash table implementations one can use. | 12:14:41 |
| Mic92 | llvm also has a hash set specific to symbols that allocates strings within the hash table to save memory. | 12:15:08 |
| Mic92 | I guess a count should be cheaper than a malloc but maybe you can do the benchmark. | 12:16:08 |
| manveru | well, i'd imagine a count won't allocate anything in the GC, so it should help for stuff like haskell.nix which has a ton of symbols afaik... | 12:20:46 |
 andi- | Why count over find? Do you fear the allocation an allocator might produce? count could probably be more costly than find that (should?) return on the first positive match. | 12:40:15 |
| Mic92 | There are also other interesting hash tables. For example for pointer to pointer maps, a dense hash map is better. | 14:29:57 |
| andi- | We probably want to store only the ptr but sort/bucket them by a hash for the string value to make lookups fast(er)? | 15:54:12 |
|  dadada (they/them) changed their display name from dadada to dadada (they/them). | 15:59:41 |
