Perl 6 - the future is here, just unevenly distributed

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

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

All times shown according to UTC.

Time Nick Message
12:54 ilbot3 joined #perl6-release
12:55 lizmat joined #perl6-release
12:57 moritz FROGGS: could you please add http://irclog.perlgeek.de/perl6-release/2016-01-11 to the channel title? kthxbye
12:59 Topic for #perl6-release is now »r« - Discussions about Perl 6 and Rakudo release strategies - http://irclog.perlgeek.de/perl6-release/2016-01-11
13:04 _Gustaf__ joined #perl6-release
13:13 FROGGS so, I made this channel because there is some need for discussion and consensus regarding upcoming releases as well as how we can add features to rakudo
13:14 FROGGS I think, one way to let somebody "depend" on a feature that gets added to rakudo post 6.c is to do a "use rakudo:ver(v2016.01)"
13:14 FROGGS this clearly indicates that someone is relying on a compiler specific feature
13:15 FROGGS on the other hand, we probably should make sure that new features do not leak
13:16 FROGGS so, with out a "use rakudo" I expect that I get the functionality of 2015.01 including bugfixes and performance changes
13:17 FROGGS the other approach is to make all new additions experimental and give it a tag
13:17 moritz that would be better, IMHO
13:17 FROGGS so one could "use experimental :foobar"
13:18 moritz is there also a catch-all "use experimental"?
13:18 FROGGS I dunno
13:18 FROGGS potentially
13:18 lizmat well, the idea of use rakudo:ver is rather perpendicular to use 6.c
13:19 FROGGS the good thing about experimental is that if we change a feature month by month because we're still developing it, we can just do that
13:19 lizmat and Perl 6 being a language definition
13:19 lizmat if we're going to do that, we might as well drop the whole "language definition" idea
13:19 FROGGS why?
13:20 moritz lizmat: we can then say v6.d includes feature :foo, :bar and :baz as no longer experimental
13:20 lizmat because everybody will be checking for rakudo:ver, and not for the language version
13:20 lizmat as a module developer, the "use 6.c" has become meaningless
13:20 FROGGS lizmat: ohh, you are referring to my first lines
13:20 lizmat it doesn't tell you anything about which features are supported
13:21 moritz lizmat: but I agree with you; the idea of depending on a rakudo version feels wrong
13:21 FROGGS yes yes, okay
13:21 moritz if we think in terms of future, other implements
13:21 FROGGS I think I agree
13:21 moritz *implementations
13:21 moritz ok, I'll drop it
13:21 lizmat I like the idea of settings
13:22 lizmat but I also think that just about any commit since 2015.12 should be considered part of 6.d.DEV
13:22 lizmat aka, freeze 6.c on 2015.12 completely
13:23 lizmat I think that's the only thing that will be guaranteeing a feature set to module developers / other programmers
13:23 FROGGS except bugfixes etc
13:23 lizmat *and* be maintainable
13:23 FROGGS like, fixing segfaults and crashed
13:23 FROGGS or fixes to plain bugs that slipped through roast
13:23 lizmat I would say: not even bugfixes
13:23 FROGGS no
13:24 FROGGS that would mean that most users have to switch to 6.d.dev
13:24 FROGGS and get all weird things for free
13:24 lizmat because if your code in module depends on a fixed bug, you *still* cannot use "use 6.c" and be sure it will work with all compiler versions that claim to support 6.c
13:25 FROGGS I don't buy that argument
13:25 FROGGS (I hope that is not harsh)
13:26 lizmat it's not harsh  :-)
13:26 lizmat no worries
13:26 FROGGS we cannot ship bugs by default, knowing them fixed in a dev version
13:27 lizmat I think we should
13:27 FROGGS we wanna ship a bugfree, ultra stable and lightspeed fast 6.c compatible compiler
13:27 lizmat but, I've stated this point already a few times, and I think we should wait for other people to chime in
13:27 lizmat TimToady jnthn even pmichaud hopefully
13:27 FROGGS if that means that one has to pull in experimental features... I mean, that feels wrong
13:28 FROGGS yeah
13:28 FROGGS that's why I wanted to bundle these things here
13:28 lizmat yup, and that's a good idea  FROGGS++  :-)
13:28 FROGGS :o)
13:31 FROGGS also, even if you know that your dists works on all 6.c compatible compilers today, how long will this be true?
13:31 FROGGS until Windows 18? Ubuntu 17.04? or OS XI?
13:32 FROGGS I mean, there are operating system out there where we surly dont pass the spectests
13:32 FROGGS so I think there is no proper way to specify a compiler that fits the dist you wanna ship beyond specifying 6.c
13:33 lizmat hmmmm.... good point
13:33 FROGGS or perhaps the META6.json can list features, whatever these are experimental by compilers or not
13:33 lizmat still, those are external factors
13:33 FROGGS sure, just wanna say that you dont have it under control anyway
13:34 lizmat if we're not taking the internal factors seriously first, managing the external factors is even worse
13:34 lizmat so, in fact, I think you actually made a point for my position  :-)
13:35 FROGGS what if I make rakudo 2016.03 work on cygwin? is this allowed to be in core.c or what it is called?
13:35 FROGGS what if I just patch the build scripts?
13:35 FROGGS that has nothing to do with the language
13:36 FROGGS we also had patches to moarvm that fix bigint bugs on 32bit platforms
13:37 lizmat the last one I see as a point supporting my position
13:37 FROGGS k
13:37 lizmat but again, we don't need to convince each other :-)
13:37 lizmat I will abide with any consensus we reach here
13:38 FROGGS sure, same here
13:38 lizmat but it would have to be a broader consensus than the 3 people curently not lurking on this channel
13:38 FROGGS (community ware ftw)
13:39 lizmat afk for a few hours&
13:41 FROGGS <[Coke]> I am tempted to skip 2016.01; we need a really good plan for backwards compatibility, and I think it'll take us a little longer to have the infrastructure in place for that.
13:41 FROGGS <[Coke]> (in which ase, we should think about what this means for R*: perhaps we will need a very minimal 2015.12.1 that has some precomp or installer fixes that we agree our safe - whatever is blocking R* at the moment.)
13:42 [Coke] joined #perl6-release
13:44 PerlJam joined #perl6-release
13:45 nine joined #perl6-release
13:46 nine [Coke]: we did make quite some progress over the weekend with regards to backwards compatibility infrastructure. In fact I hope to make it mergeable this evening
13:46 [Coke] ok. is there a spec you're working off of/
13:47 [Coke] Last I heard we had some good ideas, some code, but not a written down plan to discuss.
13:49 nine docs/language_versions.md
13:58 [Coke] printing a hardcopy, danke.
14:13 PerlJam Just to make sure I understand that document ... as written, it seems the only way to get behavior "beyond" 6.c (or the current release) is with a use line of some sort.   i.e. unlike gcc where you have to explicitly turn on some mode to get a particular standard, we're always at a particular standard and have to turn on a way to get something beyond the standard
14:13 PerlJam correct?
14:25 nine Yes, that sounds correct.
14:35 PerlJam Is this document meant only for Rakudo, or all Perl 6 implementations?
14:42 nine The line is blurry. The chapter about Language versioning is valid for all Perl 6 implementations. The rest is really about how to implement it in Rakudo.
14:43 nine And now that I read it again: a source file without any use v6* at all should be compiled with all features turned on. That's not what the current implementation does.
15:06 PerlJam Well ... the section on language versioning should be part of the standard for all Perl 6 implementations.  Otherwise, you end up with "use v6.mumble" meaning something slightly different between implementations as some decide to implement == while others may implement <=  (for instance)
15:07 PerlJam I mean it should be not just "valid for" implementations, but more of "implementations MUST ..."
15:10 nine I dare say that the spec test suite will take care of this quite nicely
15:12 FROGGS and I think it is more like v6.something (compiler) ~~ v6.mumble (the use statement)
15:12 FROGGS and we already know what smartmatch is supposed to do there
15:12 PerlJam If someone uses a feature that's available in a particular implementation, but not in the spec, how are they to know?  (unless, as it is currently written, they have to enable all non-spec features somehow)
15:13 FROGGS I dont know
15:19 nine The question should be: why is such a feature in the implementation but not in the spec?
15:20 FROGGS nine: because we're still developing it
15:20 FROGGS and because the spec does not change every month
15:21 nine But those features really should only be active in v6.X.PREVIEW code.
15:23 FROGGS nine: what if we try something a month before that v6.X, and it most likely wont make it in v6.X? will it be automatically in v6.Y?
15:24 FROGGS v6.X.PREVIEW implies that a certain feature will make it into v6.X, which might not be true
15:24 FROGGS that said, why dont we use an experimental pragma, with tags that let you turn on *specific* things?
15:25 nine Actually I have already suggested something like that.
15:25 nine Of course the "PREVIEW" may still be bikeshedded. I personally haven't come up with something better yet.
15:26 FROGGS I mean, if I only care about feature X, why should I turn on evrything?
15:27 nine Because maintaining rakudo as a collection of optional features sounds like hell indeed. The number of possible feature combinations explodes quickly.
15:27 nine And if you really want to use feature X and continue to use it, you're gonna have to use v6.X anyway.
15:27 FROGGS isnt it better to keep the problems central?
15:28 nine What do you mean?
15:29 FROGGS if we decide that the user cant pick "unofficial" features, we pollute the users side and probably cause trouble there
15:30 FROGGS and if we call the pragma 'use feature :X', and that :X makes it into the next language release, that line would just be a noop
15:30 FROGGS because at a time, we will have compilers from different years that target different language versions
15:31 FROGGS your script should run on all of them ideally
15:33 FROGGS imagine you state you want 6.d.PREVIEW which ships 12 additional features, and you now got a 6.d compliant compiler which only ships 10 of these twelve features
15:33 [Coke] (feature in impl. but not spec: "dd")
15:33 [Coke] there are no spec tests for this, but it's part of rakudo, and you don't need a use to get it.
15:33 FROGGS would the compiler just switch to 6.d and hide the two?
15:34 [Coke] Our main priority at this point is rakudo & the spec; It's nice to worry about other perl6s, but that part doesn't have to be perfect.
15:35 [Coke] if you're using a .PREVIEW, you're going to have to do work to keep up to date.
15:36 [Coke] we can bikeshed a better name than .preview, but I imagine that if you're using that, it's the same as :experimental
15:36 nine FROGGS: if those two features don't make it into 6.d, they either get postponed to 6.e, or removed completely. And yes, using .PREVIEW means, that you can't rely in any way on those features. They may be changed or removed without notice. The responsibility is your's.
15:36 [Coke] (or worse in terms of stability; but not better.)
15:41 nine We may still use the existing "experimental" mechanism for some features. But not all changes to the language may suitable for that mechanism. There may be interdependencies between new features.
15:41 FROGGS nine: still, what does a 6.d compliant compiler do with a 6.d.PREVIEW script?
15:42 nine Bail out because 6.d is frozen.
15:42 nine (That was actually a hypothesis more than a definitive answer)
15:45 nine I actually do have a use case right now: as soon as language_versions is merged, I'm gonna merge query_repos and would of course like to use that functionality in panda, but keep compatibility with rakudo versions that don't support the new API.
15:45 nine So I'll have to test if the API is available and use it conditionally.
15:47 nine That probably means testing if v6.d.PREVIEW is available and if load a module that then checks if the new methods are available and use them.
15:53 nine From that example we can already learn that we need a means to query support for language versions. $*PERL.version tells us only for which version the current comp unit is compiled.
15:57 FROGGS nine: just a few days ago I was looking at an implementation attempt of module 'if'
16:11 [Coke] I would double check with TimToady on the end of the language_versions doc. I was under the impression that 6.c.1 was not out of the realm of possibility.
16:12 [Coke] (but perhaps that was a spec clarification rather than a "use" directive)
16:14 [Coke] (clean spectest on JVM) - mark as NYI (can't even install rakudo-j at this point)
16:18 PerlJam nine: I'm not so sure 6.d.PREVIEW even works in general.   Will it only ever contain features for 6.d that were available at the time of the 6.c release?  Are the features that are developed between the 6.c and 6.d release considered 6.e.PREVIEW features?
16:20 PerlJam nine: or, put another way, 6.d.PREVIEW may be a moving target over time -- There will be one set of features when 6.c ships and this set will change over time until 6.d is actually released.
16:20 nine PerlJam: everything that gets added after the 6.c and before the 6.d release is 6.d.PREVIEW material
16:20 nine PerlJam: exactly. The whole point is that it's a moving target rather than a frozen release.
16:22 PerlJam sure, but one person's 6.d.PREVIEW may not be the same as another person's 6.d.PREVIEW.  As an identifier, it contains insufficient information.  Only "expect something extra"
16:25 PerlJam If I'm going to share some 6.d.PREVIEW code with someone else, I'd need to also let them know exactly which features to turn on/off so that they can try it out.  (unless I'm missing something)
16:26 PerlJam If the versions were more like 6.d.PREVIEW-2016-06-25 then they'd know they'd need at least whatever feature set was in PREVIEW on that date.
16:28 nine And how would we implement this 6.d.PREVIEW-2016-06-25?
16:28 [Coke] PerlJam: given that's it's experimental, you'd have to do that even if you asked for it by feature.
16:29 PerlJam I dunno, I'm just thinking out loud
16:29 [Coke] and because it's experimental, we're not going to commit to it working a certain way.
16:30 [Coke] I think we should consider separate 6.c compatible releases, and 6.d developer releases.
16:31 * PerlJam meeting &
16:45 japhb joined #perl6-release
16:45 nine [Coke]: what would we gain by splitting off developer releases?
17:17 stmuk_ joined #perl6-release
17:17 stmuk_ http://irclog.perlgeek.de/perl6-release/2016-01-11
17:17 stmuk_ oops
17:21 [Coke] nine: we've speculated that a 6.d can run 6.c code with proper use statements; by having a single release that is 6.c until it isn't, we can't really test that.
17:21 [Coke] we're going to have to have 2 versions anyway; the question is do we integrate that into our release process or not.
17:27 [Coke] (otherwise we end up with something that has bitten us in the past: we update a dependency just before a release, and it has no time to be tested in the wild (e.g. bump nqp revision at the last minute before the release...)
17:30 nine I don't see how having different releases would make a difference there? Quite the opposite: by making the user decide upfront which release to install (2016.04 or 2016.04.dev) we will get less testing of the dev version that is 6.d.PREVIEW capable. People will have less of a reason for trying out those experimental 6.d.PREVIEW features, as their users won't be able to run the code.
17:30 [Coke] but they're testing it in a way that isn't what it'll be like when it's "real"
17:31 nine Was the testing of nom before the big christams release in vein?
17:31 nine That was just as much a preview release of the language than 6.d.PREVIEW is going to be.
17:31 [Coke] I agree the individual mechanisms might get better testing if they're available for people to play with, but then when 6.d goes live, the code is different.
17:32 nine People use unstandardized CSS features all the time by way of vendor prefixes. That gives the vendors valuable real life experience which influences the standardization process. That would not work at all if people had to use development versions of browsers to use them.
17:33 nine And those web developers are usually quite aware of using unstable features and deal with changes in the standardized version.
17:34 TimToady joined #perl6-release
17:35 ZoffixW joined #perl6-release
17:38 hoelzro joined #perl6-release
17:39 rjbs joined #perl6-release
17:39 rjbs Coke told me there would be punch and pie.
17:40 [Coke] well, I also owe you a dinner!
17:41 rjbs What's for dinner, dear?  //  Punch and pie.
17:41 rjbs This is a topic (/topic, not pie) about which I would be happy to help if I can, but I'm likely to be quiet today.  A couple plates spinning at the office.
17:41 nine rjbs: actually we're just trying to figure out how to make different mistakes when providing backwards compatibility ;)
17:42 rjbs If you'd like well-understood mistakes, I'll sell you ours cheap.
17:45 nine rjbs: today's log is still a very readable size and ~ 100 % on topic: http://irclog.perlgeek.de/perl6-release/2016-01-11
17:47 stmuk_ at what point is master going to get branched from nom?
17:47 stmuk_ what point on nom that is
17:49 nine stmuk_: that should not matter, since the plan is to fast forward master to nom automatically at regular intervals
17:50 stmuk_ so when the 6.c tests past on master it becomes nom
17:51 stmuk_ errr other way around
17:51 stmuk_ when nom (dev) passes 6.c it becomes the master (release)
17:55 nine passes all spec tests (including 6.c), panda's bootstrap and the selected 100 modules' tests
17:55 stmuk_ ok that's not really want I meant
17:56 stmuk_ there isn't a master branch so one has to be created first and there are two options 1. branch at 2015.12 2. branch at a point past that and do the test/module passing work
17:58 nine It doesn't matter where exactly we branch because it will be fast forwarded anyway. So if current nom passes the quality criteria a branch at 2015.12 that's fast forwarded to current nom is indistinguishible from a branch from today's nom
17:59 stmuk_ I think it matters because there are non-6.c changes in nom
17:59 nine branches in git really are only a pointer to the HEAD commit + a config entry for what the upstream branch is
18:00 stmuk_ so you either remove those changes or start from not having them in the first (and add changes apart from the non-6.c ones)
18:00 stmuk_ those two options correspond to my options 1. and 2. above
18:01 nine that's not a question of where we branch off as much as a question of "do we want to fast foward the branch to nom". As long as you do the latter, it does not matter at all where you start.
18:01 stmuk_ there are changes in nom which have to be removed I'm talking about how to do that
18:02 nine stmuk_: have you had a look at the language_versions branch?
18:02 stmuk_ is that the branch with the 6.d settings?
18:03 nine yes
18:04 stmuk_ so you are proposing not to use version control to remove 6.d features?
18:04 stmuk_ but just doing it programmatically
18:05 nine absolutely
18:05 nine FWIW it's jnthn's proposal
18:11 * stmuk_ rereads language_versions.md
18:14 stmuk_ does the language_versions branch pass 6.c roast? or does 6.c roast need "use 6.c" spec'd some how/
18:16 JimmyZ joined #perl6-release
18:19 FatalNIX joined #perl6-release
18:19 jnthn joined #perl6-release
18:19 jnthn When will Perl 6 be released???
18:20 nine jnthn! \o/
18:20 nine stmuk_: the branch is just a prototype on it's way to getting mergeable
18:20 jnthn o/ nine :)
18:23 TimToady jnthn: if you want a very short thing to backlog, this channel is less than a day old :)
18:26 jnthn OK, that stands a chance. #perl6 doesn't :)
18:26 jnthn Apparently I'm getting food in just a moment, though :)
18:55 TimToady joined #perl6-release
19:09 lucasb joined #perl6-release
19:13 lucasb is that a "R" letter with butterfly wings?
19:13 ZoffixW Where? :)
19:13 ZoffixW Oh /topic
19:14 lucasb make it a capital R! »R«
19:15 lucasb ahh, it's "r" for release... not Rakudo... or maybe could mean both :)
19:19 TimToady »r̈«
19:19 [Coke] >>℞<<
19:24 rjbs There is no Rx implementation on p6 yet... http://rx.codesimply.com/
19:31 jnthn Heh, I thought you were talking about Rx as in Reactive Extensions, which Perl 6 already embraced enough to put into the language and make its own :)
22:52 rjbs time to read scrollback
22:59 Zoffix joined #perl6-release

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