02:47
ddellacosta has quit [Ping timeout: 245 seconds]
06:04
pie_ has joined #nix-lang
07:32
<
manveru >
man, there are so many cool undocumented builtins :)
07:33
<
manveru >
> builtins.genericClosure { startSet = [{key=10;}]; operator = {key}: if key > 0 then [{key = key - 1;}] else [{inherit key;}]; }
07:33
<
{^_^} >
[ { key = 10; } { key = 9; } { key = 8; } { key = 7; } { key = 6; } { key = 5; } { key = 4; } { key = 3; } { key = 2; } { key = 1; } { key = 0; } ]
07:34
<
manveru >
this one is a bit dangerous too
07:34
<
EsperLily >
huh I haven't seen that one before
07:34
<
EsperLily >
I really wish these builtins had documentation
07:35
<
manveru >
2.3 has builtins.getContext
07:35
<
EsperLily >
I take it genericClosure iterates the operator until it returns its input?
07:36
<
manveru >
i think it does tail-call-optimization, so if you never converge it will break your nix instance
07:37
<
manveru >
don't wanna try here because someone would have to restart the bot i think
07:37
<
manveru >
> builtins.nixVersion
07:38
<
EsperLily >
hmm yeah if I run it in nix repl it just hangs forever
07:38
<
EsperLily >
even ^C doesn't work at that point
07:39
<
EsperLily >
d'oh you're right it's not lazy either
07:39
<
EsperLily >
I wrapped it in `builtins.elemAt ... 2` and it's still hanging
07:40
<
manveru >
it was actually commented out in the release notes :P
07:40
<
manveru >
not sure why
07:41
<
EsperLily >
huh nixpkgs has a deprecated lib.lazyGenericClosure but there's no builtins.lazyGenericClosure
07:46
<
EsperLily >
ok so specifically it uses the required `key` attribute of each set to determine when it's done
07:46
<
manveru >
yeah, so you can pass more arguments
07:46
<
manveru >
that's why its usage is so... cumbersome i guess
07:53
<
manveru >
> __findFile __nixPath "nixpkgs"
07:53
<
{^_^} >
/var/lib/nixbot/nixpkgs/master/repo
07:54
<
manveru >
well, not very useful i guess
08:03
<
manveru >
i should maybe do some blog posts about those, love playing with nix :)
08:03
<
manveru >
i like how minimal `derivationStrict` is
08:11
<
pie_ >
<manveru> 2.3 has builtins.getContext
08:11
<
pie_ >
does that do what i thikn it does
08:11
<
pie_ >
i dont even remember why i wanted that but
08:11
<
pie_ >
wait actually no
08:11
<
pie_ >
to be clear i was thinking of "get the variables that are in scope"
08:12
<
pie_ >
ok its the other context
08:12
<
pie_ >
what does that get us again? :D
08:12
<
pie_ >
infinisil: do you have a watchdog for the bot yet? :D <manveru> don't wanna try here because someone would have to restart the bot i think
08:14
<
manveru >
so... my usecase is something like "<head>${ ./some.css }</head>" in a template, and it'll grab the css, build it, add it to the outputs, and do a string replace for the path with a tag to the file
08:14
<
pie_ >
people should get a smack on their hands for not documenting builtins
08:14
<
manveru >
replacing the string also removes the context :)
08:16
<
manveru >
now i wonder if i can even compile templates that reference nix paths without keeping the reference, or i have to call `unsafeDiscardStringContext` on it
08:17
<
manveru >
would be kinda awkward if you write a blog post about nix with some output and end up deploying it with your blog :P
08:31
<
pie_ >
actually thats kind of a neat corollary
08:31
<
pie_ >
nix:// links or something
08:31
<
pie_ >
yooo come and get it from the cacheee
08:31
<
pie_ >
my binary cache brings all the boys to the yard
08:38
<
manveru >
pie_: well, that actually works already
09:36
__monty__ has joined #nix-lang
13:14
<
infinisil >
manveru: Oh try to run it, I wonder what happens with the bot
13:14
noonien has joined #nix-lang
13:15
<
infinisil >
It does restart if it crashes
13:20
__monty__ has quit [Ping timeout: 244 seconds]
13:20
__monty__ has joined #nix-lang
13:22
<
manveru >
infinisil: thing is that it doesn't crash, but let's see :)
13:23
<
manveru >
> builtins.genericClosure { startSet = [{key = 0;}]; operator = {key}: [{key = key + 1;}]; }
13:23
<
infinisil >
Hehe, yeah this might be problematic
13:23
<
infinisil >
I was hoping it would use more memory over time, but that's not the case
13:24
<
manveru >
it's strange, yeah
13:24
<
infinisil >
I've been wanted to implement a timeout for the nix evaluation for a while
13:24
<
infinisil >
I'm looking at it in htop: 15% CPU usage, 100MB memory
13:25
<
infinisil >
Now 50% (which is the limit it's allowed to)
13:25
<
infinisil >
Kinda weird that it fluctuates with CPU usage
13:25
<
infinisil >
> 1 + 1
13:26
<
manveru >
well, how many workers does it have ;)
13:26
<
infinisil >
Spawns a new one for every request
13:27
<
infinisil >
But the other one is still going, could definitely DDos it with that :o
13:28
* infinisil
kills it manually
13:28
<
{^_^} >
(no output)
13:40
hmpffff has joined #nix-lang
13:42
hmpffff has quit [Client Quit]
13:44
hmpffff has joined #nix-lang
14:22
hmpffff has quit [Quit: Bye…]
14:29
ddellacosta has joined #nix-lang
15:24
ddellacosta has quit [Ping timeout: 245 seconds]
18:03
hmpffff has joined #nix-lang
18:07
ddellacosta has joined #nix-lang
18:40
ddellacosta has quit [Ping timeout: 245 seconds]
19:23
__monty__ has quit [Ping timeout: 245 seconds]
19:42
__monty__ has joined #nix-lang
20:48
sheelx has joined #nix-lang
21:23
sheelx has quit [Ping timeout: 272 seconds]
22:42
__monty__ has quit [Quit: leaving]
22:59
sheelx has joined #nix-lang
23:10
hmpffff has quit [Quit: nchrrrr…]
23:13
sheelx has quit [Ping timeout: 272 seconds]
23:14
sheelx has joined #nix-lang
23:38
sheelx has quit [Ping timeout: 246 seconds]