infinisil changed the topic of #nix-lang to: Channel for discussing Nix as a language - https://nixos.org/nix/manual/#chap-writing-nix-expressions - Logs: https://logs.nix.samueldr.com/nix-lang/
Synthetica has quit [Quit: Connection closed for inactivity]
samueldr has quit [*.net *.split]
samueldr has joined #nix-lang
andi- has quit [Ping timeout: 245 seconds]
andi- has joined #nix-lang
pie_ has quit [Ping timeout: 245 seconds]
pie_ has joined #nix-lang
__monty__ has joined #nix-lang
__monty__ has quit [Quit: rebootying]
__monty__ has joined #nix-lang
atopuzov[m] has quit [Read error: Connection reset by peer]
colemickens has quit [Write error: Connection reset by peer]
colemickens has joined #nix-lang
atopuzov[m] has joined #nix-lang
<puck> hrmm, found another side-effect: derivations; the issue is that this is a one-time fuse until the next GC run
<puck> "Construct (as a unobservable side effect) a Nix derivation" turns out this is false
<__monty__> How can you determine whether a derivation already exists from nix?
<puck> builtins.pathExists :p this seems to break with restrict-eval or pure-eval, it seems, luckily
<puck> i'm suspecting this can be done with builtins.path in the same way
<puck> oh oops
<puck> yeah, builtins.path combined with a filter function breaks pure-eval
<puck> :)
<__monty__> I'm not sure it's even possible to do caching without opening yourself up to exploits.
<puck> actually wait, i'm not sure this is noticable
<puck> builtins.path does take a different path, but there's no way to get that info out, i think
<puck> would've been cool tho. anyways builtins.pathExists can definitely be used to implement the fuses
<__monty__> You could probably also time evaluation.
<puck> i don't believe you really can from inside nix
<__monty__> Not the language per se. But most build scripts are bash.
<puck> yes, but bash is not an immutable functional language :p
<puck> oh huh, actually
<puck> pathExists can return false if a file exists but pure-eval is set.. and will start returning true after the file has actually been downloaded
<__monty__> My reasoning is just from a pragmatic perspective. What do we use nix for? To describe a build process essentially. If what nix produces isn't deterministic. Then the evaluation of nix is only a small part of the problem.
<__monty__> And I definitely don't think anyone should be worrying about caching being observable at this point.
<puck> well yes but i also really love just breaking things
<puck> note that what i'm doing is deterministic across evaluations, *but* allows one to break the expected determinicism inside one evaluation
<puck> e.g. builtins.toString returning two different values when applied to the same value
pie_ has quit [Ping timeout: 250 seconds]
demize has left #nix-lang ["WeeChat 2.7-dev"]
<puck> https://github.com/NixOS/nix/issues/3249 i'm probably calling the side-effect hunt quits after this :p
<{^_^}> nix#3249 (by puckipedia, 27 seconds ago, open): toFile causes noticable side-effects
<infinisil> :O
<infinisil> puck++
<{^_^}> puck's karma got increased to 2
<puck> interestingly this is more efficient in pure mode
<puck> because it means it has a local fuse state instead of global
__monty__ has quit [Quit: leaving]