Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
00:11 pamplemousse left 00:25 lucasb left
vrurg My next merge is gonna deprecate 'v6.d.PREVIEW' with a warning message. 00:36
00:39 MasterDuke joined, MasterDuke left, MasterDuke joined
Geth rakudo: c5171d431f | (Vadim Belman)++ | CREDITS
Added description
 00:42
rakudo/master: 28 commits pushed by (Vadim Belman)++
review: github.com/rakudo/rakudo/compare/c...9aa440c5e2		 00:43
rakudo: 136e8a43f1 | (Vadim Belman)++ | tools/templates/6.e/moar_core_sources
Deleted obsolete file.

Overlooked while merging.		 00:51
rakudo: 5e79177d1f | (Vadim Belman)++ | docs/Building-Rakudo.md
Corrected stylistic error (autocompletion result)
vrurg .tell lizmat 6.e release cycle started with github.com/rakudo/rakudo/compare/c...9aa440c5e2
yoleaux vrurg: I'll pass your message to lizmat.
02:09 MasterDuke left 02:32 travis-ci joined
travis-ci Rakudo build passed. Vadim Belman 'Corrected stylistic error (autocompletion result)' 02:32
travis-ci.org/rakudo/rakudo/builds/539482779 github.com/rakudo/rakudo/compare/9...79177d1f43
02:32 travis-ci left 03:47 skids left 05:40 vrurg left 06:39 vrurg joined 07:17 robertle_ joined
[Tux] Rakudo version 2019.03.1-539-g5e79177d1 - MoarVM version 2019.05-24-g1c279a231
csv-ip5xs0.724 - 0.739
csv-ip5xs-206.033 - 6.056
csv-parser22.402 - 22.609
csv-test-xs-200.436 - 0.437
test7.484 - 7.936
test-t1.686 - 1.743
test-t --race0.812 - 0.812
test-t-2027.640 - 29.466
test-t-20 --race9.309 - 9.314
 07:29
08:49 squashable6 left 08:53 squashable6 joined, ChanServ sets mode: +v squashable6 09:03 leont joined
lizmat Files=1262, Tests=108009, 203 wallclock secs (26.63 usr 7.56 sys + 2838.55 cusr 273.85 csys = 3146.59 CPU) 09:59
yoleaux 00:51Z <vrurg> lizmat: 6.e release cycle started with github.com/rakudo/rakudo/compare/c...9aa440c5e2
09:59 vrurg left
lizmat weekly: 6.e release cycle started with github.com/rakudo/rakudo/compare/c...9aa440c5e2 09:59
notable6 lizmat, Noted!
10:51 leont left 12:24 jnthn left 12:25 gugod left, gugod joined, go|dfish left 12:26 jnthn joined, hoelzro_ left 12:27 hoelzro joined, Brock left, awwaiid joined 12:32 pamplemousse joined 12:51 leont joined 12:53 go|dfish joined 12:59 ggoebel joined 13:20 ggoebel left, vrurg joined 13:36 skids joined 15:53 jmerelo joined 15:57 patrickb joined
vrurg greppable6: v6.d.PREVIEW 16:42
greppable6 vrurg, 57 lines, 11 modules: gist.github.com/c0249d1d21eef36651...b6051bb3a7 16:43
vrurg Hm... It's about time to deprecate 6.d.PREVIEW. 16:44
japhb vrurg: A lot of those look like things that needed the new concurrency semantics. (I know Terminal::Print does, as I wrote that section of the code -- but looking at the others, there's a lot of async, scheduling, networking, etc.) 16:49
I guess the question is, what is the penetration in various package systems/distros of a rakudo that claims non-PREVIEW 6.d? 16:50
I hadn't changed the version requirement for Terminal::Print because I didn't want to break anyone who got rakudo from their distro's package manager and wouldn't have a new enough one for 'use v6.d;' 16:51
vrurg japhb: 6.d is in the release state for long enough now. I'd say it's time to move on. 16:52
ugexe debian is still packaging rakudo from 2017 from what i remember 16:53
vrurg I have activated v6.e.PREVIEW as of yesterday. So, 6.d.PREVIEW is something out of the pre-historic era now. ;)
japhb vrurg: Why still 2017? What's blocking it from flowing through Debian testing?
ugexe i think it not running on some obscure architecture that it did at one time 16:54
japhb vrurg: Perl 6 is about to leave its teenage years. 2 years is not pre-historic IMO.
vrurg ugexe: with things like that we'd never get rid of those.
ugexe well, ive always been one of the opinion there is no reason to get rid of .PREVIEW
vrurg japhb: you know how many 1 year means for small children? enough to call it 'an era' ;) 16:55
japhb ugexe: Does Debian have a method by which you can drop an arch intentionally? Maybe if they made a new 'perl6d' package or something that didn't force-remove the old one?
ugexe no idea 16:56
but we missed the last freeze a few months back so
japhb vrurg: <tongue-in-cheek>Yes, and we call those children 'node developers'</>
vrurg japhb: :D :D :D 16:57
japhb Does anyone know who our resident Debian packager is? 16:58
vrurg It already looks like another issue for problem solving... I was about to raise a question of branching for releases. So, perhaps it would make one subject or release process.
ugexe im not sure renaming the binary is enough because it would still share some things with the perl6 binary 16:59
like the home repo
japhb ugexe: But that shouldn't be a problem, should it? Shouldn't any rakudo that understands 6.d.PREVIEW at least already have build-specific repo subdirs? 17:00
japhb is fuzzy on exactly when that happened.
ugexe ah yeah thats right, they go into sha1 subdirs 17:01
nope im wrong 17:02
$ ls ~/.perl6
bin/ dist/ precomp/ resources/ short/ sources/ version
japhb Oh, ~/.perl6/bin -- yeah, that one might be a problem. 17:04
japhb wonders how python2/python3 worked that out.
vrurg As a small note: rakudo never really cared about versioning. Event when 6.d was introduced, Zoffix did it in a quck'n'dirty way just to have something workable. This is a big field of work to settle things down. 17:11
Geth nqp: patzim++ created pull request #550:
Fix non-reloc install & fix install into different prefixes for MoarVM, NQP, Rakudo		 17:15
rakudo: patzim++ created pull request #2939:
Fix non-reloc install & fix install into different prefixes for MoarVM, NQP, Rakudo		 17:20
rakudo: patzim++ created pull request #2940:
Move the core comp unit repo to a separate folder		 17:25
patrickb vrurg++ # The version handling work got merged! Whoot! 17:35
vrurg patrickb: Aha. ;) 17:37
AlexDaniel vrurg: why deprecate it?
just submit a PR to every module that has it… 17:38
there are just 11
vrurg patrickb: BTW, can you re-implement install-moar-runner.pl with templates, is it is done in rakudo? I could do it but wanna finish some fixes started months ago. 17:39
AlexDaniel ugexe: we didn't really miss it, debian testing currently has rakudo with v6.d by default
vrurg AlexDaniel: I've made a PR for Cro::HTTP::Client already. 17:40
AlexDaniel and there was a lot of work put into making this happen, by everyone
as for v6.d.PREVIEW, it doesn't matter I think 17:41
just leave it in, it hurts nobody…
vrurg AlexDaniel: I consider .PREVIEW as something unstable. Perhaps having experimental stuff which didn't make it into the release. Deprecation means we can drop off these remains to keep the code tidy.
AlexDaniel vrurg: you can drop these things without removing .PREVIEW 17:42
vrurg Eventhough we don't have such remains with 6.d.PREVIEW it'd be good to train ourselves on procdeures.
What the point of having it then in first place? I mean, if a module experimentally using PREVIEW features – it's ok. But if we drop something and still have PREVIEW available – it would siltently break things. Sure, this is what PREVIEW is for, but since we can reduce such complications – why not then? 17:44
Deprecation would only mean a warning message, nothing else. 17:45
AlexDaniel vrurg: sorry I'm not following 17:57
vrurg: how having v6.d.PREVIEW can silently break things?
vrurg AlexDaniel: not having it but removing obsoleted features which didn't make it into the release. Say, it was promised that some feature is available in PREVIEW and a module decides to rely on it. 18:00
Then we remove it without deprecating PREVIEW. Oops...
AlexDaniel vrurg: but same is true for any feature before the new language version is released 18:01
so anyone using whatever.PREVIEW consents to things changing unexpectedly :)
and even then, any public module is or at least should be checked with Blin before any release, so we will notice stuff breaking if we remove too much… 18:02
vrurg I know. My only point is that we still can make the risk of breaking things smaller. Even when it comes to PREVIEW.
Otherwise I don't care. I have introduced a mechanizm of deprecation and dropping. Wether to use it or not – up to the community. 18:04
AlexDaniel vrurg: btw here's a ticket related to your work: github.com/perl6/roast/issues/506
and this one too, I guess? github.com/rakudo/rakudo/issues/2557 18:05
vrurg AlexDaniel: I think the outcome of github.com/perl6/problem-solving/issues/31 obsoletes #2557. 18:12
AlexDaniel vrurg: just close it then :)
vrurg Ok 18:13
AlexDaniel preferably with a comment explaining why it is no longer an issue :)
vrurg As to 2557 – VERSION is now 6.e-proposals. But as I think of it now, it has to be 6.e.PREVIEW to maintain uniformity. The only time VERSION would have 6.<release> without .PREVIEW is when revision is released and the tag is nailed down. 18:15
AlexDaniel tag? 18:16
oh… we do have a tag…
but why… :)
just wondering, like what's the use of say `git checkout 6.d` 18:17
why do that when you can use 6.d-errata
do we keep it for like, historical purposes? Or something? 18:18
vrurg To my veiew historical is the answer. So, let me correct my self: VERSION will have 6.<release> when tag is put and in the -errata branch. 18:19
18:19 leont left
vrurg master would be .PREVIEW most of the time for that matter. 18:20
18:20 pamplemousse left
AlexDaniel right 18:21
vrurg AlexDaniel: I'm working on roast release guide paper. Do you think problem solving is a godd place for revision-specific discussions? I think it is and gonna make it part of the release preparation process. 18:55
patrickb vrurg: In NQP there are template subfolders for unix and windows. In rakudo there are file name postfixes .in and .windows Is one approach prefered over the other? 18:59
AlexDaniel vrurg: yeah it's a nice place. Another potentially nice place is github.com/perl6/roast/blob/master...e-guide.md 19:00
vrurg AlexDaniel: the latter is what I edit now and it's not the place for discussions. ;) 19:01
AlexDaniel vrurg: yeah
vrurg Zoffix created Prep Repo back in time for that. Now we have Problem Solving which way more useful.
AlexDaniel vrurg: I wonder if all release guides should be put into problem-solving… not sure it's the right thing
vrurg patrickb: It depends on the amount of files and how they're used. Extensions are preferable when you create an exclusion for a common rule. Directories are for when you have something purely platform specific. 19:02
patrickb OK. 19:03
vrurg AlexDaniel: More like a catalogue of references, I think. 19:04
AlexDaniel: they belong to their respective projects and this is where one would expect to find them in first place. Having them pointing back to problem solving we'd make it easier to find the resot of the information. 19:05
resot/rest/
19:07 jmerelo left 19:14 leont joined
nine vrurg: the quick and dirty 6.d support was actually mine. It was a bit of a proof of concept. Zoffix++ actually cleaned it up quite a bit. 19:26
vrurg nine: I mostly seen his commits related to the matter and made a wrong conclusion. Anyway, hopefuly I managed to minimize the pain of adding new revisions. 19:28
nine vrurg: seems like "implement something by using horrible hacks and heroes will come along and make it shiny" is a viable strategy after all :) 19:29
vrurg nine: Arrrrgh... So, was it just a bait???? 19:31
nine Let me put it this way: claiming that it was a strategy all along makes me look much smarter ;) 19:32
vrurg thoughts: "I'll be back..." 19:33
19:40 pamplemousse joined 20:11 ufobat_ joined 20:15 ufobat__ left, pamplemousse left 20:22 pamplemousse joined 20:40 pamplemousse left
japhb nine: Sometimes the fastest way to get the right answer is to state the wrong one publicly. I think your "strategy" fits that perfectly. :-) 21:00
vrurg: I've seen a couple different forms of deprecation, both from the "we have total knowledge of -- and an easy way to contact -- all users of our API" world, and from the "we know some but not all of our users, many of whom are hard to reach" world. My recommendation for the 6.d.PREVIEW turndown is: 1. Send PRs for every use of 6.d.PREVIEW that Blin can find. 2. Deprecate 6.d.PREVIEW with 21:04
approximately a max(2 releases, 1 calendar quarter) timeframe. 3. Remove support sometime between the next normal release after the deprecation window and the next LTS release (which in this case would be one that feeds into Star or suchlike). 21:05
DarkPAN is a thing, and it behooves us to have a reputation for being respectful of its needs without feeling utterly beholden to it.
21:12 skids left
ugexe the other thing is examples from e.g. blog posts 21:43
21:51 leont left
japhb ugexe: Oh yeah, that's a really good point actually. 21:57
AlexDaniel japhb: 6.d.PREVIEW can be simply grepped, no need for blin 22:06
greppable6: 6\.d\PREVIEW
greppable6 AlexDaniel, Sorry, can't do that
AlexDaniel greppable6: 6\.d\.PREVIEW
greppable6 AlexDaniel, 58 lines, 11 modules: gist.github.com/a11a73c07c1acc1587...15578742a3 22:07
AlexDaniel quick and easy :)
japhb: also fwiw your number 3 wouldn't fly if I was doing the release 22:10
I have written a bunch of scripts in perl 6 over the years, some of them are executed rarely (like once a year if not less) 22:11
and yes, some of them have use v6.d for one reason or another
changing `use v6.d.PREVIEW` to `use v6.d` is not a big deal, but I'm kinda expecting things to just work, especially so given that v6.d is now fixed 22:12
22:19 patrickb left
AlexDaniel just leave the damn thing :) 22:21
Also, I still don't understand the reasoning. I used to spend so much time trying to make sure that existing code keeps working, so why remove that little thing that might make some things stop working without modification? :S 22:25
maybe this proposal should go through github.com/perl6/problem-solving
where you *have to* first clearly define what the actual problem is :)
japhb AlexDaniel: ugexe's point was a good one, and I can see leaving it for longer (perhaps forever) -- but I didn't get to say that earlier because I was moving to a new location (I'm on a bus now). :-) 22:26
vrurg Another way to do things: leave 6.d.PREVIEW alone (the law is not retroactive), but have a rule for e+.
But then again, I don't insist on this. Just feel like .PREVIEW is a termporary thing. 22:27
japhb What I outlined I think is a bare minimum of stages and time. For other deprecation cycles, we may want it to go longer, or only do steps 1&2 and not 3 for a long time thereafter (or ever). 22:28
But I've also seen what happens when people try to support edge cases forever, so I don't want to get into the "we can never break anything" game. 22:29
ugexe how difficult can it be to have a mechanism that, at a given point, simply ignores the .PREVIEW from all versions under it? 22:30
vrurg ugexe: Basically it is already there. Though it's used for deprecation but can be used to set a flag or alike. 22:31
japhb ugexe: I am of two minds on that one -- 1. It seems like a practical workaround, 2. What about people actually requesting the PREVIEW version because it had some feature or behavior that didn't make it into the final release, but their code needs?
ugexe that is what they opted into using .PREVIEW 22:32
they did not opt into some weird dependency error because 6.d.PREVIEW doesnt exist anymore
AlexDaniel and I'm still failing to understand what the problem is
like, did anyone ever define it? :)
and if not, just let the damn thing be 22:33
japhb ugexe: Well, that brings up the question of whether someone using .PREVIEW is opting into the possibility that their code may stop working some day with an error that those semantics are no longer supported, or opted into their code silently changing semantics at some point.
ugexe sure. but look at the timespan that the two different failures will happen at 22:34
japhb AlexDaniel: Breathe please. I am not trying to pick a fight. :-)
vrurg I was about to open a discussion on problem solving about the release process anyway.
Perhaps we shall let it settle down for a while.
ugexe i would argue behavior change from .PREVIEW to the final version will happen short enough period that e.g. blog posts wont be essentially set in stone
having .PREVIEW simply fail will happen years down the road after deprecation 22:35
AlexDaniel japhb: it's hard to breathe while I'm screaming my lungs out :D
vrurg is looking around for a fire gidrant. Time to extiguish the heat... ;)
japhb raises hands placatingly and steps back 22:36
vrurg *hydrant
AlexDaniel well, the problem-solving repo is intentionally designed to avoid mindless discussions about changes that don't solve actual problems… though it doesn't help if we keep discussing stuff here instead of creating a ticket :) 22:38
japhb Oh, on a different version-related note, I just got this trying to rebuild at rakudo HEAD and install modules: "No compiler available for Perl v6.*" trying to build JSON::Unmarshal. 22:39
So it's not just 'use v6.d.blah' that's potentially broken in the ecosystem 22:40
AlexDaniel m: use v6.d.PREVIEW 22:42
camelia ( no output )
AlexDaniel m: use v6.d.PREVIEW; say $*PERL
camelia Perl 6 (6.d)
AlexDaniel m: use v6.c.PREVIEW; say $*PERL
camelia ===SORRY!===
Cannot call method 'typed_panic' on a null object
AlexDaniel oh yeah, that error message…
vrurg github.com/perl6/problem-solving/issues/34 22:52
^ The place to talk about PREVIEW. 22:53
AlexDaniel: how often camelia is been rebuilt?
AlexDaniel vrurg: I don't know, every 15 minutes or something like that? 22:54
evalable6 is a bit faster, but even it is not triggered with github hooks
vrurg ===SORRY!=== Error while compiling /Users/vrurg/src/Perl6/experiments/revision.p6 22:55
No compiler available for Perl v6.f
Thoufh 6.c.PREVIEW results in a weird error. Oops... 22:56
AlexDaniel aaa I remember lizmat mentioning that camelia is stuck
e: use v6.c.PREVIEW; say $*PERL
evalable6 (exit code 1) ===SORRY!===
existskey requires a concrete object (got a NQPMu type object instead)
AlexDaniel o_o 22:57
well that's not any better
e: use v6.f
evalable6 (exit code 1) 04===SORRY!04=== Error while compiling /tmp/vr0CtdcwOD
No compiler available for Perl v6.f
at /tmp/vr0CtdcwOD:1
------> 03use v6.f08⏏04<EOL>
AlexDaniel heh
vrurg AlexDaniel: 6.c is handled specially because it doesn't have own CORE.c.setting. Thus the difference. Will get it fixed today. 23:00
Geth ¦ problem-solving: AlexDaniel assigned to jnthn Issue The status of PREVIEW modifier. github.com/perl6/problem-solving/issues/34 23:12
roast: vrurg++ created pull request #545:
Changed release guide to reflect the latest state of things.		 23:15
vrurg AlexDaniel: ^ put short excerpt of problem solving #1 into roast release guide. 23:17

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!