Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-release, 2016-02-02

| Channels | #perl6-release index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:58 _Gustaf__ joined #perl6-release
02:11 japhb Shouldn't the "<!!until_version('e')>" constraint mean that a feature will be supported up to *and including* version 6.e, rather than "not going to be supported in 6.e and later"?
02:12 japhb Or is 'until' one of those words whose meaning is subtly different for different English speakers?
02:12 japhb (And if so, then we should probably pick a different word.)
02:32 _Gustaf_ joined #perl6-release
03:01 [Coke] cutting nqp release now...
03:02 [Coke] ... done.
03:02 [Coke] (easy peasy because RC already done.)
03:05 [Coke] testing rakudo release...
03:06 [Coke] I'm going to kick off the test runs, have to run out, will pull the trigger when I return.
03:09 llfourn_ joined #perl6-release
03:18 [Coke] only testing against 6.c for this release, since we're not trying to match roast/master just yet.
05:01 [Coke] uploading rakudo tarballs.. tag already in...
05:04 [Coke] tarballs uploaded.
05:07 [Coke] lots of core files in rakudo's public_html  on rakudo.org
05:08 [Coke] 2016.01 release cut
05:09 [Coke] if someone wants to merge that branch back to nom, that'd be most helpful. I don't want to get yelled at by someone for doing the merge wrong. :|
07:53 nine Do we need to merge it?
08:27 FROGGS joined #perl6-release
09:24 jnthn japhb: Well, I called it before_version to be clearer, and TimToady suggested until
09:25 jnthn Though
09:25 jnthn until foo() { }
09:25 jnthn Loops until foo becomes True
09:26 lizmat m: say $?PERL
09:26 lizmat [10:26:43]  <+camelia>rakudo-moar a5fe34: OUTPUT«===SORRY!=== Error while compiling /tmp/MDZ9r4T2ki␤Variable '$?PERL' is not declared␤at /tmp/MDZ9r4T2ki:1␤------> say ⏏$?PERL␤»
09:27 lizmat I remember trying to implement that quite some time ago, but couldn't make that work
09:27 jnthn Yes, I was surprised by that
09:27 jnthn ah, OK :)
09:27 jnthn Well, we can work that out :)
09:27 lizmat same for $?VM and $?KERNEL btw
09:27 jnthn It needs to be something lexically resolvable
09:31 lizmat ironically, $?PERL will never be in the 6.c setting
09:32 lizmat as stipulated by CORE.setting lexical change guidelines, point 6
09:32 lizmat jnthn: point 1 mentions "impelementations", rather than "implementations"
09:33 lizmat afk&
09:37 jnthn Well, bootstrapping is mostly about cheating, so we may cheat a $?PERL in there, given the low risk and high pay-off. I called them guidelines, not rules, or a reason. They're there to help us do the right thing more often, not to force awkwardness upon us without cause.
09:38 jnthn s/or a reason/for a reason/
09:55 jnthn [Coke]++ # 2016.01 release
11:45 nine Ah man, seems like I missed one of the most important patches :/ https://github.com/rakudo/rakudo/commit/fb00ed3d71f9407a776c82f03855d1242997878c#commitcomment-15823245
11:46 jnthn Ah, so it was accidental... :(
11:46 nine openSUSE package build fails without that patch
11:46 nwc10 http://www.dieangewandte.at/jart/prj3/angewandte/main.jart?rel=de&amp;content-id=1229508255643&amp;aktuelles_id=1454062658245
11:47 nwc10 oh, that wasn't *meant* to go here, but it's not like it's emarassing. Sorry :-)
11:49 jnthn Damn, I don't qualify. Guess I have to keep compiler hacking. :P
13:13 [Coke] nine - yes, it needs to be merged. release-only stuff happened on it that needs to be incorporated into the next release, I think.
13:15 [Coke] nine: is that patch -crucial-? If so, we can consider a 2015.01.1
13:20 nine [Coke]: yes, I'd actually consider doing a 2016.01.1. I needed to manually add the patch to be able to build the openSUSE packages. Same will be true for most other distributions.
13:21 [Coke] ... I keep saying 2015.
13:22 [Coke] ok. and as I said in #perl, this is why I did an RC. :)
13:22 [Coke] er, #Perl6
13:23 nine The reason why I didn't package -RC1 is that I didn't know if rpm would consider the final 2016.01 a later version than 2016.01-RC1.
13:24 [Coke] Didn't have to submit it upstream, I guess.
13:24 nine Yes, I could have built it locally. The Open Build Service is just too darn convenient.
13:25 [Coke] ok. I'll do a 2016.01.1 later today.
13:27 [Coke] no reason for this to impact nqp/moar releases, yes?
13:28 nine I submitted my MoarVM, NQP and Rakudo packages for inclusion into the official openSUSE repo
13:30 [Coke] pulled that commit into the branch.
13:31 [Coke] don't see a need to do a new nqp.
13:31 nine No, nqp's fine :)
13:32 [Coke] branch has that merge and a new VERSION; about to transit, will kick off the tests at $dayjob.
13:34 nine We can cherry-pick the release-changes back into nom.
13:38 crux joined #perl6-release
13:43 moritz is there a reason not to merge the release branch?
13:44 moritz into nom, that is
13:45 perlpilot [Coke]++
13:47 jnthn Branches that had lots of stuff cherry-picked into them can be icky to merge
13:47 jnthn (Not saying we should/shouldn't, just that it may end up being easier to cherry-pick the things unique to the branch)
13:53 nine A merge would create lots of conflicts (I tried) while the list of commits we need to cherry-pick is rather short.
13:54 jnthn Yeah, do what's expedient
13:55 moritz right
14:00 jnthn meeting &
15:13 MadcapJake joined #perl6-release
15:39 lizmat joined #perl6-release
16:20 [Coke] ok, ready to cut the .1 releaes...
16:20 [Coke] *release
16:20 [Coke] ... I'm going to walk away for 10m and wait for someone to say "WAIIIIT"
16:20 [Coke] :)
16:20 lizmat well, I;m not sure it was that urgent?  I didn't get that from the mail, actually
16:21 lizmat especially since we're only three weeks away from the next release anyway?
16:21 jnthn lizmat: As far as I understand, it was a blocker for packaging.
16:21 lizmat ah, ok, the only blocker ?  :-)
16:22 [Coke] ... from the discussion here and on perl6, this sounded like a critical patch that is required for downstream packaging.
16:22 jnthn Well, probably not for every kind of packaging, but it sounded like the only one for OpenSUSE.
16:22 lizmat ok, I missed the discussion, I was only going by the mail
16:22 [Coke] jnthn: and macports.
16:22 jnthn That's already two :)
16:22 lizmat ok, then +1 from me and *no* WAIIIIT  :-)
16:23 lizmat so, do we have clarity on where we should commit for 6.c or 6.d.a   and how to handle additional tests for 6.c / 6.d.a ?
16:25 jnthn lizmat: Depends if there's any major objections to the guidelines. And I think nine++ did some work to enable the per-language settings, but I don't think that's merged yet.
16:26 lizmat that's definitely not merged yet
16:26 lizmat I don't have any objections against the guidelines
16:26 lizmat it was the lack of I had objections against
16:26 lizmat I don't fully agree with all of them, but as you say, it's a matter of tradeoffs
16:27 lizmat and I can live with the tradeoffs
16:27 jnthn Which areas did you find less agreeable, out of curiosity?
16:30 * lizmat goes to check one more time
16:31 [Coke] ok, .1 tarball is up.
16:31 [Coke] can someone test the destdir bug before I commit a tag?
16:31 lizmat if we're doing a minor bump for each release, one may wonder why we have language releases at all
16:31 [Coke] isn't necessarily for each release.
16:32 jnthn lizmat: The language minor bumps?
16:32 [Coke] and those changes are more likely to happen right now, just after christmas, I think.
16:32 lizmat jnthn: yes
16:32 [Coke] generally more just after a release, and more after our first ever release.
16:32 jnthn lizmat: I wasn't expecting "every Rakudo release"
16:32 jnthn lizmat: "At present, a minor version can likely be expected every 2-3 months."
16:33 [Coke] we are going to have just bugfix/speedup releases for christmas, I'm sure.
16:33 lizmat the concept of "errata specification compatibility" feels artificial
16:34 jnthn I think we already have a place we'll need it (iirc, there are wrong spectests with regard to sprintf formatting)
16:35 [Coke] "is not perfect plan"
16:35 lizmat and there is a faulty test for Date.later
16:36 timotimo joined #perl6-release
16:36 timotimo i didn't even know we have to have a 2016.01.01
16:38 lizmat jnthn: How would this be handled:
16:39 lizmat use v6.c; EVAL "use v6.d; ..."
16:39 lizmat the EVAL would be a new compilation unit
16:39 jnthn I think it'd have to be forbidden.
16:39 lizmat but would basically be embedded in the outer one
16:40 jnthn Because the mechanism wants to give you an alternate setting
16:40 jnthn But an EVAL's setting is the scope it's EVAL'd in
16:41 jnthn The alternative is that an EVAL declaring a langauge version can't see outer lexicals.
16:41 jnthn But that may be...too magical.
16:41 lizmat ok, so it should be the same as "use v6.c; use v6.d"
16:41 lizmat and thus fail, either because it's not the first statement, or because it is a version override
16:41 jnthn There's probably a third alternative in there somewhere.
16:41 jnthn Right.
16:42 jnthn Do you see a use case for the EVAL with a version, ooc?
16:42 jnthn Thinking forward a little, I think we'll probably end up with a more "interesting" API for doing code evaluation in the future, that allows sandboxing at the like.
16:42 timotimo maybe someone would intuitively reach for "eval with a different version" to get around our versioning limitations
16:42 lizmat not directly, but it may happen inadvertently under the hood
16:43 jnthn *and
16:43 lizmat especially in the case of EVALFILE
16:43 jnthn *nod*
16:43 [Coke] timotimo: it's not hard to cut a release with a single change. if it were not specifically to make packaging easier I would probably delay. (despite that fact that 2 of our packagers have already done this manually)
16:44 [Coke] I have offsite lunch plans today - so that I don't screw things up, will tag and email shortly after I get back. as I said, the .1 tarballs are available for testing.
16:44 [Coke] glun
16:44 [Coke] ww
16:44 jnthn Have a nice lunch :)
16:44 timotimo understood
16:44 timotimo lunch well!
16:45 lizmat it's getting too loud for me to hear myself think, so I'll get back at this tomorrow, after getting back from Amsterdam.pm meeting
16:47 [Coke] ~~
17:02 tony-o_ joined #perl6-release
17:21 lizmat joined #perl6-release
18:35 [Coke] 2016.01.1 cut
18:35 [Coke] updating wikipedia, replying to 2016.01 email
18:53 FROGGS[mobile] joined #perl6-release
18:54 FROGGS[mobile] o/
18:55 hankache joined #perl6-release
19:00 lizmat joined #perl6-release
19:06 FROGGS joined #perl6-release
19:09 [Coke] FROGGS[mobile]: were you the one pushing for R*?
19:11 FROGGS [Coke]: I can create one if that was the question
19:11 FROGGS dunno if I can do that today though
19:12 [Coke] well, there's a 2016.01.1 now.
19:12 FROGGS yes, just seen it
19:13 [Coke] it'd be awesome if an R* happened in the next 2-3 days. I can't remember the last time I tried to cut one of those.
19:13 FROGGS I an do that for sure
19:13 [Coke] You're the best. Thanks!
19:14 nine joined #perl6-release
19:31 jnthn \o/
19:31 jnthn FROGGS++
19:35 hankache joined #perl6-release
20:17 moritz 2016.01.1 was only rakudo, no extra NQP or MoarVM release, right?
20:18 [Coke] correct.
20:28 [Coke] jnthn: does your doc talk about branching, except for dealing with LTS release point fixes?
20:28 [Coke] I'm assuming the lack of that means you think we can keep working on nom?
20:30 jnthn https://gist.github.com/jnthn/c10742f9d51da80226fa now addresses `use v6.c` style things in EVAL (lizmat++) and dynamic variables (nine++); the latter was a tad subtle.
20:31 jnthn [Coke]: We'll continue working on nom
20:31 jnthn [Coke]: However, we may not always release from nom
20:32 jnthn [Coke]: An earlier write-up saw us introducing a master branch, which we perform "continuous delivery" to
20:32 jnthn That is, an automated process tests nom each time it's committed to, and if it passes a set of checks then an automatic fast-forward of master is done.
20:33 jnthn This would simplify release management somewhat, and also provide a more stable target for those who like to rakudobrew.
20:33 jnthn I'm still quite keen for us to head in that direction.
20:34 jnthn But it needs a bit of effort to set up
20:36 jnthn FROGGS: Still considering the "mark newly added methods with their introduction version". I think it's a good idea, didn't quite figure out what such a trait wants to be called.
20:36 jnthn TimToady: Thoughts on ^^ would be helpful. :)
20:37 lizmat jnthn: would that also apply to new MMD candidate methods ?
20:37 [Coke] jnthn: yup, sounds good. (direction for master/nom and that we're not quite ready yet.)
20:37 [Coke] asof?
20:37 [Coke] since?
20:38 [Coke] We definitely want that for docs.perl6.org, too.
20:38 jnthn lizmat: Seems reasonable, yes.
20:39 lizmat perhaps document in pod, not in a trait ?  or do we need it for runtime checks?
20:39 jnthn Pod in the setting will likely have bootstrapping fun
20:40 jnthn What if we add a method in Mu? :)
20:41 jnthn (To be clear, we solve many bootstrapping issues by being very careful about ordering, but things still have to occur ahead of their children.)
21:02 moritz http://hack.p6c.org/~moritz/rakudo-star-2016.01-RC0.tar.gz # please test
21:45 FROGGS[mobile] joined #perl6-release
22:24 jnthn sleep &
22:37 stmuk_ joined #perl6-release
23:44 lizmat joined #perl6-release

| Channels | #perl6-release index | Today | | Search | Google Search | Plain-Text | summary