Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-release, 2016-01-14

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

All times shown according to UTC.

Time Nick Message
01:12 _Gustaf__ joined #perl6-release
02:49 ilbot3 joined #perl6-release
02:49 Topic for #perl6-release is now »r̈« - Discussions about Perl 6 and Rakudo release strategies - http://irclog.perlgeek.de/perl6-release/today
07:12 FROGGS joined #perl6-release
07:18 _Gustaf_ joined #perl6-release
15:06 FROGGS joined #perl6-release
19:16 nine language_versions fails 6.c spec tests for 2 reasons: DateTime.later('2008-12-31T23:59:60Z').later(day => 1) now returns '2009-01-01T23:59:50Z' instead of '2009-01-02T00:00:00' which may arguably be more correct.
19:16 nine Second is the removal of IO::Dir in "Rip out remaining dead code from newio branch"
19:17 nine I think both qualify as needing case by case discussions
19:20 nine I also wonder how we can replace methods in 6.d. augment doesn't do it and supersede is NYI
19:21 jnthn I don't know it *can* be "just supersede" either
19:21 jnthn Because supersede is in-place
19:22 jnthn So would mutate the original 6.c class
19:22 jnthn (As is the case with augment)
19:22 nine Do we have any other tool that could do this? Short of subclassing that is...
19:22 jnthn Not yet :)
19:23 jnthn Subclassing is an OK approximation
19:24 nine We are so gonna need this...soon. lizmat++ has added some optional arguments to DateTime
19:24 nine 's methods
19:24 jnthn Hah, once again I've got time-pressure to come up with good designs :P
19:24 nine I'd love to be able to do class DateTime:ver<6.d> is DateTime:ver<6.c>
19:25 nine Because that's exactly what we're trying to do
19:25 TimToady well, we were always going to really use longnames internally, and just have lexical shortnames as aliases
19:29 nine So what's missing to get that going?
19:29 jnthn Well, more fundementally we need to figure out the relationship between the 6.c and 6.d version
19:29 [Coke] (time pressure). I see no reason to rush a release here. we have some tough questions to answer
19:31 nine Well we could buy ourselves some time by doing a release with just the changes that we can already do in a backwards compatible way. Having a release that's actually packageable and allows for trouble free installation of modules would take a lot of pressure away.
19:31 [Coke] oh. we need a command line switch also that lets us change the default assumptions for which language is being used, so people can over the course of the year be trying out 6.d without having it surprise them when the spec congeals and we flip a switch in rakudo. (or some mechanism) (might just be perl6 -Mv6.d)
19:32 [Coke] nine - sure; if we're going to do that, I think we need to branch nom back from the 2015.12 release and then cherry pick what we want for a 2016.01 that has no potentially scary commits.
19:32 [Coke] s/nom //
19:32 nine [Coke]: sounds like a plan
19:34 jnthn +1 on a safe, packagable release
19:35 jnthn Especially if we can make a * of it
19:36 TimToady [Coke]: note that "play with" will not be enabled by -Mv6.d since that would only start with -Mv6.d.0, so you'd need -Mv6.d.MUMBLE
19:36 TimToady also, it bothers me that we keep talking about "PREVIEW" as if it were a version
19:37 TimToady it's just a kind of wildcard, and the actual versions will go like v6.d.a, v6.d.b ... v6.d.0
19:40 * TimToady wonders how soon till someone misapprehends that v6.c.* means rakudo star...
19:41 * PerlJam bets it happens the first time v6.c.* is seen in the wild
19:42 TimToady another consideration, 'use v6.d.PREVIEW;' won't actually work right, since it'd have to be 'use v6.d.PREVIEW+;' instead
19:42 nine TimToady: is your commit 16c5fc7ab4a522a9702f6b922dfb731f5c6564a2 safe?
19:43 nine Ah I think it is
19:44 TimToady yes, all it's doing is marking wanted
19:45 nine now https://github.com/rakudo/rakudo/commit/386905f6f62f9fa3525c887a8a86fa48b22b4b35 is more complicated
19:45 TimToady for some metaop or other, iirc
19:45 PerlJam Maybe we should have "use v6.d :PREVIEW"  or something
19:46 TimToady nine: that one needs to go in, along with a later fix
19:47 TimToady in fact, just in general, I don't think I've done anything towards 'd' yet, everything I've done is for c.1
19:49 TimToady 37e742f0bb6f36f1a9d9a5f947c5c0de15d236c2 is scary but needs to go in anyway, or lots of loops don't work right
19:51 TimToady in fact, I've been testing all of my patches against 6.c, so you can be pretty confident that they won't break the 6.c tests
19:51 FROGGS PerlJam: I think I like that
19:51 TimToady I don't like adding more mechanism
19:52 TimToady use 6.c.A+ would work fine
19:52 TimToady as would use 6.c.*
19:52 nine jnthn: what about this? https://github.com/rakudo/rakudo/commit/42326d1b72f658f6dc54a0052d04cb933f219acc
19:52 TimToady well, with a v
19:52 FROGGS TimToady: but all our additions are not part of v6.c
19:52 TimToady I meant to be talking about d
19:52 FROGGS maybe not even v6.d when we get closer to it
19:53 TimToady if we're gonna hack something that allows previews, it should probably be an envvar, not something you have to edit out
19:54 FROGGS we are talking about loading an additional setting, right?
19:54 TimToady or bypassing an existing setting, depending on how you look at it :)
19:54 FROGGS ... or an alternative
19:54 FROGGS yeah
19:54 PerlJam that doesn't feel right to me.  Environment variables can be invisible and the whole point of mentioning PREVIEW is to loudly proclaim "here be dragons" in this code
19:54 FROGGS so maybe we can label it that way
19:55 TimToady I think v6.d.* would be sufficient for dragons
19:55 TimToady and wouldn't look wrong after v6.d.0
19:55 FROGGS RAKUDO_SETTING=core.d perl6 -e 'say hurz'
19:55 nine We'll want to make it easy for people to test those new features
19:56 FROGGS though that looks weird if my script has a 'use v6.c' in it
19:56 TimToady if we can just use the current versioning system, I think that would be ideal
19:57 TimToady Occam's Razor, and all that
19:57 PerlJam aye
19:58 PerlJam but shoe-horning it into the existing versioning system would be the anti-ideal  :)
19:59 TimToady .oO( -MMONKEY )
20:27 nine I pushed a 2016.01-preparation branch with cherry-picked post 2015.12 commits. It passes roast/6.c
20:30 nine panda seems to work, too
20:34 [Coke] nine++
20:47 PerlJam nine++ nice
20:51 jnthn nine: re 42326d1b7, sounds reasonable; you'd need to use a slurpy and nqp::existskey on it to detect presence of default, or otherwise set it to a sentinel value (the NO_VALUE trick QAST::Node does).
21:06 nine Ok, it's included in the 2016.01-preparation branch
21:23 [Coke] nine - I'll start hacking a release announcement together that mentions that this release is the first post christmas, nothing breaking, nothing that will eventually end up in 6.d yet...
21:24 [Coke] are we still trying to come up with names for each release?
21:26 nine [Coke]: thanks :)
21:28 PerlJam [Coke]: fwiw, I don't think we should  (naming is hard and just adds another barrier to release).  Maybe "significant" releases could be named, but generally not.
21:29 [Coke] That does mean that 2016.01 would be the first unnamed release.
21:29 [Coke] I would also be happy with christmas-related names.
21:29 [Coke] or something dumb and monotonically increasing.
21:31 [Coke] If someone wants to review the changes that landed in that branch and summarize them in the release bullet list, that'd be great.
21:31 [Coke] nine: do we need to bump moarvm/nqp?
21:31 [Coke] and if so, we probably need to manually go through commit logs for names, since this is a new way of doing a release.
21:41 nine [Coke]: yes, there's at least one nqp bump in the commits
21:45 TimToady is it worth pulling in some of the new tests into a v6.c.1 roast that also has to pass, to prevent regressions?
21:45 TimToady I put in a bunch of tests for the new loop stuff
21:50 TimToady well, I guess most of the loop tests went in pre-christmas, but still
21:50 TimToady any tests I wrote this month were in aid of bug fixes you've inclluded
21:53 [Coke] (regressions, v6.c.1) that is outside the scope of the 2016.01 release.
21:53 [Coke] SFAIK. I think nine's palce is to make 2016.01 be v6.c (bugfixes only)
21:54 TimToady well, would be nice to test the bugs stay fixed
21:55 nine The tests are still there in roast/master which is what we will use for day to day development. So that should be covered. 2016.01 is a compiler release for Perl 6.c.
21:56 nine We _can_ release a Perl 6.c.1 at any point in time, independent of any compiler release.
21:56 TimToady does 2016.01 pass our current tests in roast?
21:57 nine You mean roast/master? Probably not as there are already tests for 6.d features
21:57 TimToady well, then we won't know if regressions happen till we separate those out that apply to 6.c
21:57 TimToady or put up with noisy tests against master
21:58 nine Do we plan to continue the 2016.01 branch after the release?
21:58 TimToady "continue"?
21:59 TimToady anything released continues automatically :P
21:59 nine Regressions can only happen if we do development on that branch. If all development happens on nom instead, roast/master should be enough
21:59 TimToady regressions can happen with mis-cherry-picks down the road as well
22:00 nine Well we can still do a 6.c.1 branch after the compiler release to prevent that from happening :)
22:01 TimToady well, I don't *know* that people will want to say 'use v6.c.1;' just yet, but the more the tests get out of sync, the harder it becomes later
22:02 TimToady and waiting till we actually get regressions is probably Too Long
22:03 TimToady I can also see it might be impolitic to advertise a 6.c.1 right now :)

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