<disasm>
gchristensen: be ready to be asked where all you went this trip, how long you've been here, where your going back to, what the purpose of the trip was for, and most importantly when they ask you do you want to go home, say yes :)
jushur has quit [(Ping timeout: 260 seconds)]
jushur has joined joined #nixos-dev
makefu has quit [(Ping timeout: 260 seconds)]
ckauhaus has joined joined #nixos-dev
jtojnar has quit [(Remote host closed the connection)]
<niksnut>
copumpkin: your nagging wrt aws-sdk-cpp paid off :-)
<pierron>
peti: I found it! I found a way to remove the extend & fix-point from Haskell Packages, Python, Emacs, Linux modules, …
jushur has quit [(Ping timeout: 248 seconds)]
<pierron>
peti: and to express the duplication of expression without newScope nor callPackage
<pierron>
peti: and to fix the issue they were asking about cloning a set of packages including some override, but with a different package set, in a much more cleaner and efficient way :)
<pierron>
peti: The idea came after I realized that the "recursive-update operator" can also be made to merge function arguments.
jtojnar has quit [(Read error: Connection reset by peer)]
jtojnar has joined joined #nixos-dev
jushur has joined joined #nixos-dev
<peti>
pierron: Hmm, this sounds good. :-) What are you thinking about?
<pierron>
peti: newScope & callPackages are used to basically make sure you can take mutated elements within the scoped content.
<pierron>
peti: so basically, this is like having an extra function, which captures a "scope"
<pierron>
peti: I am thinking of pythonPackages = { _type = "scope"; fun = self: { … python-packages … }; }
<peti>
pierron: OK, I'm with you so far.
<pierron>
peti: if we have a recursive update operator which can continue the recursive update beyond the self: argument, then we can merge overrides of these python packages, such as:
<pierron>
peti: //< { pythonPackages = { _type = "scope"; fun = self: { foo = >: … ; }; } , where //< … >: are delimiters for starting and stoping the recursive update.
<pierron>
peti: which implies that overriding a python package would just repeat the same scope.
<pierron>
peti: The "self" argument would be provided by the fix-point of nixpkgs, by looking for sets which have the `_type = "scope";` attribute.
<pierron>
peti: as a self-reference to the final version of the packages within this set.
<pierron>
peti: so in the previous example, "self" would be bound to "nixpkgsSelf.pythonPackages"
<pierron>
peti: still with me?
<peti>
pierron: I don't think I fully understand that. I'm not sure how to interpret the //<..>: syntax.
<pierron>
>: is a way to stop the recursive update operator, and give it a function.
<pierron>
the function, is specific for each attribute, and is used to update the old value, or replace it by the new one, if there is nothing to update.
<peti>
OK, so "foo >: CONST" is basically the same thing as "foo = CONST", but "foo >@old: ..." applies the given lambda function to the previous value of foo.
<pierron>
peti: yes, just a sugar syntax on top of the recursive update.
<pierron>
peti: now it we can also make it work for function arguments:
<peti>
What does "//< { foo = >@old: old + 1; }" do when foo is not set in the LHS? Default to "null"?
<peti>
pierron: OK, I think I understand that operator.
<pierron>
peti: note that in the last example the >: is after the argument b:
<pierron>
peti: for example: …
<peti>
pierron: Yes, it modifies the the body of the original foo lambda function.
<pierron>
peti: ({ foo = a: { a = a; }; } //< { foo = b: >: { b = b + 1; } }).foo 1 == { a = 1; b = 2; }
<pierron>
peti: now, if foo is pythonPackages, and the "1" argument is the result of Nixpkgs' fix-point self.pythonPackages, then we got the same behaviour as the extend + newScope
<pierron>
peti: ^ and the extra fix-point which used to be in pythonPackages
<peti>
pierron: The "b:" binding in the RHS is unified with the "a:" on the LHS, right? The name of the argument does not matter?
<pierron>
peti: right, the name does not matter.
<pierron>
oh, the above example is wrong, it should be:
<pierron>
peti: ({ foo = a: { a = a; }; } //< { foo = b: { b = >: b + 1; }; }).foo 1 == { a = 1; b = 2; }
<pierron>
the previous example result should only be { b = 2; }
<peti>
pierron: Wouldn't it be possible to apply //> to a rec {..} attr set? In that case, we wouldn't need the fix point at all.
<pierron>
peti: the right-hand-side is the override.
<pierron>
peti: rec is a fix-point.
<peti>
Well, yes, that is true.
<pierron>
peti: and the reason of mentioning the fix-point is because we already have it in Nixpkgs.
<pierron>
peti: so, this give us the ability to remove the per-language fix-points.
<pierron>
peti: now, with these we can also implement the same feature they wanted in the pull request, i.e. taking an already overriden package set, and move it to a different attribute name.
<peti>
pierron: Yes, I see what you mean. That sound like it work work. At the cost of having to implement unification/pattern matching that can look into a lambda abstraction.
<pierron>
peti: this is easy to do, we already have the isFunction primitive
<pierron>
peti: updateFunction = f: g: (x: f x // g x);
<peti>
pierron: Very nice! This is a great idea.
<pierron>
This way, we can remove the inner fix-point o/ out of Nixpkgs.
<peti>
pierron: One more question about the last example: ({ foo = a: { a = a; }; } //< { foo = b: { b = >: b + 1; }; }).foo 1 == { a = 1; b = 2; }. This comes out as "{ a = 1; b = 2; }" because the rewrite pattern does not match the "a = a" bit and therefore inserts the "b = b + 1" bit as a new attribute. Is that right?
<pierron>
({ foo = a: { a = a; }; } //< { foo = b: { b = >: b + 1; }; }).foo 1
<pierron>
{ foo = (a: { a = a; }) //< (b: { b = >: b + 1; }) }.foo 1
<pierron>
(a: { a = a; }) 1 //< (b: { b = >: b + 1; }) 1
<pierron>
{ a = 1; } //< { b = >: 2; }
<pierron>
{ a = 1; b = 2; }
<peti>
We'll need a formal'ish specification of the semantics that operator.
<pierron>
That sounds doable :)
<peti>
The //< part is straight-forward, IMHO, that's simple. The >: bit is trickier. But it's probably okay, too.
<pierron>
I guess I should probably split the SOS RFC into the"recursive update" operator, and the "strictly dynamic binding" one.
<pierron>
peti: it's a matching part, if the expression is being resolved with it, then recursive update will behave like the extend function
<pierron>
or not the extend operator, but sort-of
<pierron>
extend = a: b: a //< (>@arg: b arg); # arg == a
<pierron>
I guess "recursive extend" might be another name for it.
<peti>
I see what you mean.
<peti>
pierron: I'll have to experiment with that operator a bit to figure out how such a thing would be implemented.
<pierron>
peti: This is basically the same as described in the SOS rfc, except that the enlightment came from also adding the capability to handle function arguments too.
* pierron
back in a few minutes
* pierron
back
orivej has joined joined #nixos-dev
<pierron>
peti: ok, I will draft a RFC for the recursive update operator, and mark it as a blocker for SOS, and for a having a single fix-point for Nixpkgs.
<peti>
pierron: OK. I'll try to model the operator in some high-level language.
mog has quit [(Ping timeout: 252 seconds)]
jushur has quit [(Max SendQ exceeded)]
jushur has joined joined #nixos-dev
mog has joined joined #nixos-dev
MichaelRaskin has quit [(Ping timeout: 246 seconds)]
yorick has joined joined #nixos-dev
zraexy has joined joined #nixos-dev
<peti>
pierron: Am I correct assuming that { a = {b = "foo";}; } //< {b = "bar";} == {a = {b = "bar"}; b = "bar";} ?
ckauhaus has quit [(Remote host closed the connection)]
sphalerite has quit [(Ping timeout: 246 seconds)]
sphalerite has joined joined #nixos-dev
<domenkozar>
niksnut: thanks for all the source fixes!
<domenkozar>
do you have some opinions how to fix ./.?
orivej has quit [(Ping timeout: 260 seconds)]
pbogdan has quit [(Ping timeout: 248 seconds)]
pbogdan has joined joined #nixos-dev
<gchristensen>
hi everyone, my bot will now label PRs as having _no_ rebuilds. example: "10.rebuild-linux: 0" if you think this is an error, please ping me
<simpson>
Nice.
<gchristensen>
this fixes the obvious problem of "are there no rebuilds, or did it just not get to it?"
<gchristensen>
schedule.nixcon2017.org/ <- url to do that
<orivej>
gchristensen: please, publish your slides too :)
<gchristensen>
trying :?
<gchristensen>
I can't
<gchristensen>
"413 Request Entity Too Large"
<orivej>
I guess you could ask orgateam@nixcon2017.org
<gchristensen>
done
taktoa has quit [(Remote host closed the connection)]
FRidh has joined joined #nixos-dev
FRidh has quit [(Quit: Konversation terminated!)]
disasm has quit [(Quit: WeeChat 1.9.1)]
disasm has joined joined #nixos-dev
<copumpkin>
wow, PRs are through the roof
<gchristensen>
:chart-with-upwards-trend:
<disasm>
copumpkin: yeah... I tried to put a dent in it last night, but it seemed like everyone I closed 2 opened.
<gchristensen>
58 PRs in the last 24hrs
<gchristensen>
" Excluding merges, 38 authors have pushed 56 commits to master and 99 commits to all branches. On master, 112 files have changed and there have been 3,006 additions and 9,800 deletions.
<gchristensen>
051015
<globin>
Have to really automate the stats stuff...
<LnL>
gchristensen: whoa!
<disasm>
lol... I think we need an all hands mass effort to go through all the PR's and close stuff that doesn't apply anymore and merge any low hanging fruit :)
<gchristensen>
it'd help!
<gchristensen>
but we've ~never gotten 60 prs in a day before
<domenkozar>
orivej: sadly I don't have access
<domenkozar>
what's the username?
<domenkozar>
I've sent slides to christine
<orivej>
Thank you, hope they are published. I'd like to ponder upon some points, and that's not as convenient with the video, although it's amazing that there are videos, and so soon!
<gchristensen>
agreed
<orivej>
I am mostly interested in the part about the Nix language, since I'm working on something that is going to encompass nixfmt.
<copumpkin>
o/
<gchristensen>
ok I'm going to go sleep, and pretend we didn't get a million PRs today