| 20 Aug 2021 |
 sterni | In reply to @gytis-ivaskevicius:matrix.org
Also i feel like trivial-builders.nix is somewhat similar. I feel like thats something that Nix itself should be able to do 🤔 in the end these are just wrappers around derivation and add nothing new and they mostly exist to make very simple derivation integrate well with our mkDerivation infrastructure | 21:54:51 |
 Gytis Ivaskevicius | In reply to @sternenseemann:systemli.org
You were saying that it should be avoided for normal usecase - I disagree: fetching a repo used at eval time (something like naersk) is a normal use case yeah, i kinda forgot about cases like that, have been on flakes for quite sometime | 21:54:56 |
| sterni | In reply to @gytis-ivaskevicius:matrix.org
Now back to the question - What is the reason of not having the one that could be used for derivations (aka the one that returns a derivation) I'd say simplicity and flexibility, but it has been proposed before to change this: https://github.com/NixOS/nix/issues/2270 | 21:55:32 |
| Gytis Ivaskevicius | In reply to @sternenseemann:systemli.org
in the end these are just wrappers around derivation and add nothing new and they mostly exist to make very simple derivation integrate well with our mkDerivation infrastructure I would expect bit of a speed up due to amount of it is being used | 21:56:01 |
| Gytis Ivaskevicius | (to be fair one could just create a custom binary for this) | 21:56:23 |
| Gytis Ivaskevicius | Also I am not sure about simplicity, its like "bit of code in nix" vs "loats of code in nixpkgs" | 21:57:18 |
| sterni | simplicity is not about code size and less code in nix is always good | 21:58:22 |
| sterni | it'd mostly be having another special thing in nix | 21:58:32 |
| sterni | whereas derivations and fixed-output derivations are quite simple concepts that can be used for all sorts of things | 21:58:56 |
| Gytis Ivaskevicius | Yeah, its simple and flexible | 22:06:36 |
| Gytis Ivaskevicius | I was thinking more along the lines of in addition to what we currently have add few more derivation builders | 22:07:09 |
 tomberek | random comment; in the course of doing Summer of Nix, it has been extremely helpful to be able to help people with issues due to the effectiveness of "show me the flake.nix repo and we can reproduce the problem". Thanks niksnut ! | 22:46:36 |
| 21 Aug 2021 |
| sterni changed their display name from sterni (he/him) to sterni[m]. | 22:21:27 |
| sterni changed their display name from sterni[m] to sterni. | 22:21:41 |
| 22 Aug 2021 |
| tomberek | In a flake, nixConfig.bash-prompt works when entering a nix develop, but not for nix shell. Is this on purpose? I've noticed some issues where people end up in nested nix develop or nix shell which ends up causing confusion. Is this a bug? thoughts? | 05:57:38 |
| tomberek | I'm trying to figure out why/how bash-prompt affects nix develop, but not nix shell. I'm not finding the right way to access the right settings objects in run.cc
I thought that I can add a bit around here: https://github.com/NixOS/nix/blob/master/src/nix/run.cc#L122
that would modify PS1 in the same way as: https://github.com/NixOS/nix/blob/master/src/nix/develop.cc#L467-L471 | 08:30:54 |
|  siraben changed their display name from siraben (he/him) to siraben. | 16:16:29 |
| tomberek | for ^^^^: https://github.com/NixOS/nix/pull/5162 | 20:16:13 |
| 23 Aug 2021 |
 abathur | Redacted or Malformed Event | 19:56:49 |
| 24 Aug 2021 |
 andi- | Running nix-build as a regular user right now does eval + drives the build in a single process, correct? I was thinking of doing the eval in a forked child such that we can (safely?) discard all the memory from the eval that we don't have to hold on to anymore. Are there any obvious roadblocks that I'd run into? | 15:13:51 |
 pamplemousse |
does eval + drives the build in a single process, correct?
AFAICT, yes; And it uses threads for parallelism.
| 18:51:57 |
| pamplemousse | andi-: FYI, I considered doing something similar to be able to fuzz the parsing / evaluation part of nix (because it's not reentrant - i.e. mutates a global state)
I don't remember exactly why I abandoned this, but speed was definitely a problem (fork/exec is much slower - but it might not be problematic in your use case). | 18:55:03 |
| pamplemousse | (it kinda defeated the purposed of having an "in-memory" fuzzer) | 18:55:31 |
| andi- | Yeah for fuzzing you probably want something much faster even thought you could fuzz multiple cases in one process (as long as you keep the history of invocations to minimize the case afterwards) | 18:56:05 |
| pamplemousse | In reply to @andi:kack.it
Yeah for fuzzing you probably want something much faster even thought you could fuzz multiple cases in one process (as long as you keep the history of invocations to minimize the case afterwards) The problem is that it raises a lot of false positives this way in practice; Every "next" run is corrupted by dangling global state left by the previous... | 19:02:40 |
| pamplemousse | (I am really talking about nix specifically here) | 19:03:01 |
| andi- | Yeah, I'd only run like 3-5 or so per fork. That is still a 5x speedup? | 21:08:42 |
| andi- | Another thing that we talked about earlier in #infrastructure:nixos.org : Could we tell the kernel / emulate the load in the sandbox so it only covers the load produced from the contained jobs? That topic came up as running many builds with a small number of cores might always be limited by load if the build system is load aware (e.g. ninja & gnumake with -l). lxc apparently does something like that. The open question was if the kernel is able to do that or else if we could/should do that in userspace (in the nix-daemon). | 22:11:22 |
| 25 Aug 2021 |
 VladimÃr ÄŒunát | I'm actually not sure it's a good idea. If the CPU is shared, strictly partitioning it doesn't sound like a good approach for overall efficiency... though it depends how exactly we'd use it. | 18:55:00 |
|  trofi joined the room. | 21:42:44 |
