| 14 Jan 2022 |
 Pacman99 | @room I just made this to update the devos "In the Wild" section: https://github.com/divnix/devos/pull/416. I want to collect a lot of examples, so if anyone has a working repo that uses digga can you please add a suggestion to the PR, or make a PR of your own to add it. | 04:10:04 |
|  @cw:kernelpanic.cafe changed their display name from Rev. CornWallace III (novus ordo seclorum) to coilWinder. | 04:40:44 |
| @cw:kernelpanic.cafe changed their display name from coilWinder to CoilWinder (novus ordo seclorum). | 04:42:51 |
 David Arnold (blaggacao) | Gytis Ivaskevicius: digga is using a fork which does avoid the inputs detection since that auto-detection once generated false positives in one of my use cases. I think it would be good to burry that fork, hence is there a chance we could avoid such automagics that can cause false positives? | 14:37:04 |
| David Arnold (blaggacao) | * Gytis Ivaskevicius: digga is using a fork of FUP which does avoid the inputs detection since that auto-detection once generated false positives in one of my use cases. I think it would be good to burry that fork, hence is there a chance we could avoid such automagics that can cause false positives? | 14:37:17 |
| David Arnold (blaggacao) | * Gytis Ivaskevicius: digga is using a fork of FUP which does avoid the inputs detection since that auto-detection once generated false positives in one of my use cases. I think it would be good to burry that fork, hence is there a chance we could avoid such automagics that can potentially cause hard-to-debug false positives? | 14:37:46 |
| David Arnold (blaggacao) | In reply to @pachumicchu:myrdd.info
I think the simplest reason is that it hurts the performance of nix search Yes, there is an elco's comment on the relevant nix PR that's the source of this wisdom. | 14:39:02 |
| David Arnold (blaggacao) | In reply to @gytis-ivaskevicius:matrix.org
This way you could not only solve this issue but also gain improvements in terms of parallelism/memory usage/caching At one point, not only entire flake evals are to be cached, but also individual function calls. If/when that happens, it also means fetchurl and derivatives are prohibitive within the flake body. | 14:40:25 |
| David Arnold (blaggacao) | * Gytis Ivaskevicius: digga is using a fork of FUP which does avoid the inputs detection since that auto-detection once generated false positives in one of my use cases. I think it would be good to burry that fork, hence is there a chance we could avoid such upstream automagics that can potentially cause hard-to-debug false positives? | 14:41:08 |
 @gytis-ivaskevicius:matrix.org | In reply to @blaggacao:matrix.org
Gytis Ivaskevicius: digga is using a fork of FUP which does avoid the inputs detection since that auto-detection once generated false positives in one of my use cases. I think it would be good to burry that fork, hence is there a chance we could avoid such upstream automagics that can potentially cause hard-to-debug false positives? Sure, lets do it. | 15:03:57 |
| @gytis-ivaskevicius:matrix.org | Lets go for 1 normal release and 1 breaking changes release like last time | 15:04:16 |
| @gytis-ivaskevicius:matrix.org | In reply to @blaggacao:matrix.org
At one point, not only entire flake evals are to be cached, but also individual function calls. If/when that happens, it also means fetchurl and derivatives are prohibitive within the flake body. yeah, but function calls arent cached between evaluations | 15:04:58 |
| David Arnold (blaggacao) | In reply to @gytis-ivaskevicius:matrix.org
yeah, but function calls arent cached between evaluations Afaik, not yet. But I had the impression that this is the long term goal of flakes. | 16:03:02 |
| David Arnold (blaggacao) | I've been musing about using dqlite as a drop in for sqlite for a while now so to have distributed eval caches 😃 | 16:03:33 |
| David Arnold (blaggacao) | One could think of eval-cache as the "compiled" version of a nix program. So why not distribute (content &/or input) addressed compiled code? 🤕😃 | 16:04:19 |
| @gytis-ivaskevicius:matrix.org | Please elaborate? What's so special about dqlite and how it impacts anything? SQLite contains metadata about derivations only | 16:05:03 |
| @gytis-ivaskevicius:matrix.org | Yeah, evaluating nix and sharing result as something along the lines of bison would make sense | 16:06:07 |
| David Arnold (blaggacao) | dqlite uses raft to distribute state, so you could construct a mesh with peers (collegues or build servers), for all that is cached in sqlite. | 16:07:07 |
| David Arnold (blaggacao) | Metadata only? I used to think it holds the eval cache. | 16:08:26 |
| @gytis-ivaskevicius:matrix.org | I'm pretty sure it's just minimal metadata | 16:08:49 |
| @gytis-ivaskevicius:matrix.org | Maybe evaluation of whole flake too. Not sure where that is stored | 16:09:07 |
| @gytis-ivaskevicius:matrix.org | Actually whole flake eval is probably stored in daemon heap | 16:09:21 |
| @gytis-ivaskevicius:matrix.org | Also these days nixpkgs takes up like 30gb of ram to evaluate.... | 16:09:54 |
| @gytis-ivaskevicius:matrix.org | Is your SQLite half the size of whole nix store? :d | 16:10:12 |
| Pacman99 | Nix does use sqlite for eval caching but I believe it creates a separate file meant for eval caching in your home directory. The daemon's db isn't used for eval caching. | 17:51:34 |
| Pacman99 | And I think its actually multiple databases | 17:52:08 |
| Pacman99 | Also, with a rebase I feel like https://github.com/gytis-ivaskevicius/flake-utils-plus/pull/89 is ok to merge. Its not a breaking change since it keeps auto channel detection just with a better strategy. | 18:02:37 |
| @gytis-ivaskevicius:matrix.org | https://github.com/gytis-ivaskevicius/flake-utils-plus/pull/110 | 18:24:53 |
| @gytis-ivaskevicius:matrix.org | before merging this one - can we collectively give some thought if there is a better solution that does the same thing and if there is a better name for it | 18:25:42 |
| @gytis-ivaskevicius:matrix.org | In reply to @pachumicchu:myrdd.info
Also, with a rebase I feel like https://github.com/gytis-ivaskevicius/flake-utils-plus/pull/89 is ok to merge. Its not a breaking change since it keeps auto channel detection just with a better strategy. lets not 'just merge it', lets do a proper release | 18:33:32 |
