infinisil changed the topic of #nix-lang to: Channel for discussing Nix as a language - - Logs:
rajivr has joined #nix-lang
Dotz0cat has quit [Ping timeout: 240 seconds]
Dotz0cat has joined #nix-lang
krkini has joined #nix-lang
kini has quit [Ping timeout: 264 seconds]
krkini has quit [Ping timeout: 240 seconds]
kini has joined #nix-lang
kini has quit [Quit: bye]
kini has joined #nix-lang
kini has quit [Ping timeout: 264 seconds]
kini has joined #nix-lang
kini has quit [Excess Flood]
kini has joined #nix-lang
kini has quit [Remote host closed the connection]
kini has joined #nix-lang
__monty__ has joined #nix-lang
Dotz0cat_ has joined #nix-lang
Dotz0cat has quit [Ping timeout: 272 seconds]
Dotz0cat_ has quit [Ping timeout: 240 seconds]
rajivr has quit [Quit: Connection closed for inactivity]
Dotz0cat has joined #nix-lang
<__monty__> I have two attrsets with the same attrNames. I want a list of the values in the second for which the corresponding value in the first is "true". Anything more elegant than `builtins.filter notNull (lib.mapAttrsToList (n: v: if first.n then v else null) second)`?
<infinisil> __monty__: I think `filter` and `map` over the `attrNames` should work better
<__monty__> I was rather hoping for a way to avoid the if-then-else with optional or something.
<infinisil> You won't need that
<infinisil> > set1 = { a = true; b = false; c = true; }
<{^_^}> set1 defined
<infinisil> > set2 = { a = 10; b = 20; c = 30; }
<{^_^}> set2 defined
<infinisil> > :p map (n: set2.${n}) (filter (n: set1.${n}) (lib.attrNames set2))
<{^_^}> [ 10 30 ]
<infinisil> __monty__: ^
mvnetbiz has joined #nix-lang
mvnetbiz is now known as mvnetbiz_2
<__monty__> infinisil: Ah, thanks. Didn't think of inverting my logic.
<infinisil> :)
<__monty__> > let set = { a = 1; }; bools = { set = true; }; in with bools; if set then "T" else "F"
<{^_^}> value is a set while a Boolean was expected
<__monty__> Why doesn't with shadow the set here?
<__monty__> The way with works is really inconvenient rn : /
<__monty__> With not shadowing is way more confusing than with shadowing imo. Even if the latter would cause infinite recursions.
<infinisil> __monty__: Yeah I've been meaning to change that
<infinisil> Currently all variable definitions in the bot are a top-level `let in`
<__monty__> infinisil: This is not a bot problem though. It's a problem with nix the language. This behavior was a "fix" to enable overriding without introducing infinite recursion or something. But I don't like the behavior `with set; [ a b c ]` should get those value from set unless they're not defined there.
<infinisil> Ah yeah, I think I agree
<infinisil> Or, let's get rid of `with` :)
<sterni> yeah with and rec { } sets are probably not that great of an idea
<sterni> they have pretty similar issues actually
<__monty__> Recursive sets are fine imo, as long as they close over their scope.
<sterni> well replacing them with fix points could be nice though
<sterni> but probably detremental to eval time
<__monty__> I've had more trouble understanding fixpoints than most things tbh.
<__monty__> Anyway, I rewrote the with stuff with lib.attrValues. Happens to be possible in this case but not exactly convenient.
<__monty__> nn, peeps
__monty__ has quit [Quit: leaving]