Geth | rakudo/nom: 01c2a22a66 | (Zoffix Znet)++ (committed using GitHub Web editor) | CREDITS Add `pmurias` to credits to fix them appearing twice |
01:34 | |
Zoffix | "fatal: write failure on 'stdout': Connection reset by peer" :/ | 02:20 | |
ah, it's from a Proc, never mind. | |||
Geth | rakudo/nom: 9d63eccf7f | (Zoffix Znet)++ | tools/contributors.pl6 Make contributors tool skip point releases Since point releases often include just the bug-fix commits, if we go by last commit to VERSION as last date of release, we end up missing all the commits that happened between last non-point release and the latest point release. Fix by looking up last non-point-release tag and using its date as the date of last release. |
02:27 | |
rakudo/nom: 2354cbddd6 | (Zoffix Znet)++ | tools/contributors.pl6 Simplify tag-searching code a bit |
02:32 | ||
rakudo/nom: 2aa6bc045b | (Zoffix Znet)++ | tools/contributors.pl6 Simplify tag-search code even more |
02:35 | ||
rakudo/nom: 180041adc5 | (Zoffix Znet)++ | tools/contributors.pl6 Fix comment |
02:36 | ||
rakudo: the-eater++ created pull request #1085: Add eater |
07:36 | ||
eater | why the ++ behind everyone's name? | 07:37 | |
for the lingering karma bots? | |||
Geth | rakudo/nom: 1946aee247 | eater++ (committed using GitHub Web editor) | CREDITS Add eater |
07:41 | |
rakudo/nom: 6064e0e1a2 | niner++ (committed using GitHub Web editor) | CREDITS Merge pull request #1085 from the-eater/patch-1 Add eater |
|||
eater | \o/ | 07:45 | |
masak | eater: yes/no | 08:02 | |
eater: the surface reason is to distribute karma to contributors | |||
eater: but the deep reason is to set up a community where contributions are the quickest way to karma (but where the karma points/gamification are just a trick to make that happen, not something important in itself) | 08:03 | ||
eater | aka positive reinforcement? :) | 08:04 | |
masak | just so | ||
once every year or so, we check people's scores. mostly just for fun. some people are in the thousands. | |||
I was once double-minus'd by moritz++, which I'm duty-bound to mention in conversations like this :P | |||
eater | D: | 08:05 | |
moritz | some things will never be forgotten! | ||
moritz doesn't remember the trigger though | 08:06 | ||
masak | moritz: trying to reproduce the one-liner now | ||
moritz: seems we've had some regressions thereabouts :P | |||
this is how we find bugs! :P | |||
eater | I see alot of positive reinforcement in perl6 tho, which is nice :) | ||
masak | m: my $lang = "perl"; $lang++; say $lang | ||
camelia | perm | ||
masak | m: my $lang = "perl"; $lang++ for ^2; say $lang | ||
camelia | pern | ||
eater | say "eater".succ | 08:08 | |
evalable6 | eates | ||
eater | :D | ||
masak | ah, here we go | ||
m: my $lang = "perl"; $lang++ for ^45_565; say $lang | |||
camelia | ruby | ||
masak spreads his arms and waits for moritz | 08:09 | ||
moritz hugs masak | |||
masak | ...we've changed as a community :P | ||
eater | :') | 08:10 | |
masak | this one works nowadays, too | ||
m: my $lang = "perl"; $lang++ for ^46_002; say $lang | |||
camelia | rust | ||
masak | oh, and I hadn't discovered any regressions. I just wrote `for 45_565` first without the ^. PEBCAK. | ||
moritz | irclog.perlgeek.de/perl6/2007-07-17#i_64543 | 08:11 | |
masak | man, almost 10 years ago | ||
moritz: I find it funny that I didn't make a big deal about it at all *at the time* :D | 08:12 | ||
moritz: but it's later been promoted into "the time moritz double-minus'd me" :P | |||
with a wink and a "no offence", no less | |||
moritz | must've been quite the traumatic experience :-) | 08:14 | |
eater | m: my $lang = "perl"; $lang-- for ^108_067; say $lang | 08:15 | |
camelia | java | ||
masak | moritz: "better have a thick skin in order to be part of our community" :P :P :P | 08:16 | |
eater++ :P | |||
moritz: man, now I'm picturing someone being extremely hurt by what I just wrote and mentioning it to me ten years from now. | 08:17 | ||
moritz | masak: the emotional stress you're putting me through... :-) | 08:18 | |
masak | huh, I seem to have a speech tick where I prefix my utterances with "man, " -- maybe I should write "humanoid, " instead | ||
but that's a bit excluding wrt our bots | 08:19 | ||
"entity, " | |||
moritz | or write "*, " instead | ||
masak | "splat, " | 08:20 | |
actually, referring to someone as "star" sounds like it has good connotations | |||
"greetings, my stars" | |||
m: my $lang = "perl"; $lang++ for ^13_568; say $lang | 08:21 | ||
camelia | pyth | ||
masak | m: my $lang = "perl"; $lang++ for ^64_592; say $lang | 08:22 | |
camelia | swft | ||
masak | hm, what am I doing wrong here? I expected this to work: | 08:25 | |
m: multi infix:<**>(&fn, Int $n) { -> $val is copy { $val = fn($val) for ^$n; $val } }; say (&postfix:<++> ** 45_565)("perl") | |||
camelia | perl | ||
masak | ooh! | 08:26 | |
m: multi infix:<**>(&fn, Int $n) { -> $val is copy { $val = fn($val) for ^$n; $val } }; say (&prefix:<++> ** 45_565)("perl") | |||
camelia | ruby | ||
moritz is surprisingly incompetent at building Debian packages. 3 instances of "worked on my machine, failed on build server" in a row | 08:27 | ||
4 now :( | 08:28 | ||
masak | m: multi infix:<**>(&fn, Int $n) { -> $val is copy { $val.=&fn for ^$n; $val } }; say (&prefix:<++> ** 45_565)("perl") | 08:29 | |
camelia | ruby | ||
masak | m: multi infix:<**>(&fn, Int $n) { -> $val is copy { $val.=&fn for ^$n; $val } }; say (*.succ ** 45_565)("perl") | 08:41 | |
camelia | Cannot convert string to number: base-10 number must begin with valid digits or '.' in '3⏏5perm' (indicated by ⏏) in block <unit> at <tmp> line 1 Actually thrown at: in block <unit> at <tmp> line 1 |
||
masak | oh, aha | ||
it creates a WhateverCode of the whole expression, I guess | 08:42 | ||
lizmat | Files=1192, Tests=58608, 204 wallclock secs (12.41 usr 4.82 sys + 1212.94 cusr 114.51 csys = 1344.68 CPU) | 08:55 | |
jnthn | haha, now I don't have to be jealous of spectest in 204 wallclock :P | 09:01 | |
The machine I'm sat on now can do them in 106 wallclock :) | |||
lizmat | hmmm | 09:12 | |
lizmat is jealous | |||
is it a notebook ? | |||
jnthn | No :) | 09:13 | |
6-core Xeon | 09:14 | ||
eater | jnthn: how many Ghz? | 09:17 | |
jnthn | 3.6 base, 4.0 turbo | 09:19 | |
eater | hmm, mine 3.5 base, turbo 3.9 | 09:20 | |
but has 8 cores :D | |||
jnthn | I thought about the 8 core one, but it was quite a bit more pricey than the 6 core one | 09:21 | |
eater | jnthn: which one do you have? | ||
jnthn | E5-1650 v4 | ||
eater | I have the E3-1241 v3 | ||
ah 12 threads? | |||
jnthn | Yeah | ||
6 cores, 12 virtual | 09:22 | ||
eater | ah | ||
yeah I have 4 cores, 8 virt | |||
jnthn | Ah, I thought you meant 8 cores :) | ||
nine | 106 seconds on a Ryzen 1800X. With the hope of becoming faster with a future BIOS update as the memory is not yet running at its rated speed. | 09:23 | |
eater | nah, when I'm talking about cores Im mostly talking about threads | ||
nine: :D | |||
I wish I had the money to buy one | |||
nine | I guess a 1700X is not much slower and costs only ~ 320 Euros | 09:24 | |
eater | haha | ||
I need to replace my mobo and ram, it's a joke of 500e | 09:25 | ||
nine | yeah, there's that | ||
eater | currently running my desktop on a Phenom II X4 | 09:26 | |
Geth | rakudo/refactor-socket-encoding: 7508a1b3de | (Jonathan Worthington)++ | 2 files Switch socket .get to use streaming decoder. Therefore hopefully removing the last place that the VM-provided char I/O on sockets is used. |
09:43 | |
jnthn | That wasn't all that bad | ||
Doing it for file handles will probably be more effort. | 09:44 | ||
Geth | nqp: 7da8da68ad | (Jonathan Worthington)++ | src/vm/moar/QAST/QASTOperationsMAST.nqp Remove deprecated async str I/O ops. They've been marked deprecated in MoarVM for a while, and not used in Rakudo for just as long. This paves the way for removing the code that is associated with them in MoarVM. |
10:04 | |
Zoffix gives up backlogging | 10:38 | ||
jnthn | Zoffix: Here, of | 10:39 | |
*or #perl6? | |||
jnthn gave backlogging #perl6 up long ago, but still kinda attempts here :) | |||
Zoffix | Here | 10:40 | |
I gave up #perl6 long time ago, though I see today it's pretty dead :) | |||
eater | dont have a bouncer Zoffix? | 10:47 | |
Zoffix | eater: "bouncer"? what's that? | 10:49 | |
eater | Zoffix: wiki.znc.in/ZNC | ||
Zoffix | eater: I have an easier solution: weechat running in screen on my server... | 10:51 | |
eater: but that doesn't solve the problem of having to read enormous amounts of text to keep up with the channel traffic :) | |||
eater | doesn't work well for me, since I need to be in different servers on different clients | 10:52 | |
yeah true | |||
Zoffix | Weird. Noticing some "duplicated" commits. Same message, date, and changes, but different shas. e.g. github.com/rakudo/rakudo/commit/3c...4cc43a0c67 and github.com/rakudo/rakudo/commit/01...0f34cc9e21 | 10:58 | |
one is pointing to 2017.04.3 tag another to nom :\ | |||
Since people were bragging about their spectest times... I got everyone beat: Files=1192, Tests=58608, 78 wallclock secs (14.89 usr 2.44 sys + 1577.35 cusr 105.72 csys = 1700.40 CPU) | 11:00 | ||
jnthn | On your everyday work machine? Or on the awesome google cloud VM you fire up for fast spectests? :) | 11:01 | |
m: say 78 / 106 | |||
camelia | 0.735849 | ||
Zoffix | :D my awesome google cloud VM :) | 11:02 | |
jnthn | Ah, OK :) | 11:03 | |
The 106 is on the machine sat next to me :) | 11:04 | ||
Zoffix | :) | ||
jnthn | A bit surprised that a it manages it in almost 3/4 of the time a 24-core of whatever monster does | ||
*or | |||
Righty, lunch time :) | 11:05 | ||
bbl | |||
Zoffix | "Model name: Intel(R) Xeon(R) CPU @ 2.30GHz" | ||
m: say 24/12 | |||
camelia | 2 | ||
Zoffix | Well, half the cores but more hurts is how I'm guessing:) | 11:06 | |
... ... did... did I just used a calculator to solve 24/12? ... | 11:08 | ||
Zoffix blames it on too much blood in coffee veins | |||
dogbert11 | Zoffix, how long does a spectest take for you if you set TEST_JOBS to 16 or thereabouts? | 11:12 | |
Zoffix | As opposed to current value of 30? | 11:13 | |
1 sec; doing bumps to get latest and greatest for release testing. | |||
dogbert11 | will be interesting | 11:14 | |
Zoffix | BTW, the other day you hypothesized about too many open files being the reason for my test flops... unlikely as turns out my default limit is 65536 | 11:16 | |
Wonder what these travis failures are about :S travis-ci.org/zoffixznet/perl6-Tes...tification | 11:20 | ||
I do have `zef --debug install .` so I'd expect more output on proper failures | |||
timotimo | it doesn't use that | 11:23 | |
that part of the output is from rakudobrew build-zef | |||
Zoffix | ah | ||
ZOFVM: Files=1242, Tests=135584, 117 wallclock secs (23.13 usr 3.21 sys + 2425.86 cusr 135.76 csys = 2587.96 CPU) | 11:29 | ||
Geth | nqp: de324a2d0f | (Zoffix Znet)++ | tools/build/MOAR_REVISION Bump MoarVM MoarVM bump brought commits: github.com/MoarVM/MoarVM/compare/2...8-g5f23324 5f23324 Remove asyncreadchars op and supporting code. 9d3ede0 Remove asyncwritestrto op and supporting code. 863e920 Remove asyncwritestr op and supporting code. 22fb8e4 don't crash on reading a closed dir handle |
||
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...8-g5f23324 | |||
rakudo/nom: 902fac5cec | (Zoffix Znet)++ | tools/build/NQP_REVISION Bump NQP NQP bump brought commits: github.com/perl6/nqp/compare/2017....8-gde324a2 de324a2 Bump MoarVM 7da8da6 Remove deprecated async str I/O ops. ... (25 more lines) |
11:30 | ||
¦ rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....8-gde324a2 | |||
nqp: 9c4d4586c0 | (Zoffix Znet)++ | t/nqp/019-file-ops.t Test no SEGV when reading from closed dir handle RT#131301: rt.perl.org/Ticket/Display.html?id=131301 Fix: github.com/MoarVM/MoarVM/commit/22...6815c8e526 github.com/perl6/nqp/commit/de324a...57e3631f9e |
11:35 | ||
synopsebot6 | Link: rt.perl.org/rt3/Public/Bug/Display...?id=131301 | ||
Zoffix | ZOFFLOP: t/spec/S17-promise/nonblocking-await.t | 11:40 | |
... make it twice | 11:41 | ||
huh, weird. both harness6 and prove seem to be perfectly fine with nested subtests not correctly nested: gist.github.com/zoffixznet/3af63ed...677f8cdc95 | 11:43 | ||
TIL | 11:44 | ||
almost makes me feel like I shouldn't bother fixing this bug in Testo :P | |||
dogbert11: with TEST_JOBS=16: Files=1192, Tests=58608, 95 wallclock secs (13.65 usr 2.49 sys + 1126.09 cusr 92.65 csys = 1234.88 CPU) | |||
dogbert11 | Zoffix: isn't that better than before? | 11:56 | |
Zoffix | m: say 95-78 | 11:57 | |
camelia | 17 | ||
Zoffix | dogbert11: nope, 17s slower | ||
dogbert11 was speculating about the default thread scheduler only having 16 threads and that adding more jobs might not be optimal | |||
Zoffix | this is harnes5 it don't use Perl 6 to schedule tests | 11:58 | |
dogbert11 is always using harness6 | 12:00 | ||
even though it's a bit slower than harness5 | 12:01 | ||
Zoffix | It's twice as slow for me | ||
dogbert11 | so 'halving' the number of threads mad you lose ~20% | ||
s/mad/made/ | 12:02 | ||
perhaps a number around 20 is optimal from cost/performance standpoint | |||
btw, there's a known bug in t/spec/S17-promise/nonblocking-await.t | 12:03 | ||
i.e. github.com/MoarVM/MoarVM/issues/554 | 12:04 | ||
timotimo | the second output is useless, that's just the global destruction not being careful about threads | 12:05 | |
so i wonder if the parametric 6model stuff is not threadsafe, and perhaps should be | |||
dogbert11 | timotimo: what kind of output would you like to have? | 12:10 | |
timotimo | hmm. maybe the cross thread write log could help | 12:11 | |
if you get this segfault in gdb again, could you print out parts of the obj argument to MVM_repr_elems? | 12:13 | ||
i wonder what this "<main_arena+88>" is supposed to tell us | 12:14 | ||
hm, i wonder if this object here is corrupted | 12:18 | ||
its REPR has a name of "" | |||
dogbert11 | let me give it a shot ... | ||
timotimo | what's the magic gdb command for "re-run until segfault" | 12:21 | |
actually, i'm not sure the crossthreadwrite log will even notice this, as it's happening from C code | 12:22 | ||
brrt | just 'run' | 12:23 | |
timotimo | brrt: that doesn't re-run if it exits normally | ||
brrt | oh, right | ||
timotimo | i have to arrow-key-up + return a bunch of times | ||
brrt | that i don't know | ||
timotimo | ha! there is the segfault | ||
it does look like a corrupt object's being put into that paramet.ric.lookup array | 12:27 | ||
aha | 12:28 | ||
finish_parameterizing has a "XXX handle possible race" comment | |||
doesn't seem to break any more with a mutex added to it | 12:34 | ||
dogbert11 | have you already fixed it? | 12:36 | |
timotimo | it may not be the fix jnthn wanted :) | 12:37 | |
dogbert11 | :) let's see what he says | 12:38 | |
too late I guess, but now I have the SEGV in gdb | 12:40 | ||
turns out that there are two tests which fails intermittently, test 8 and 11 | 12:41 | ||
timotimo | pushed | ||
dogbert11 | when test 8 fails all I get is: | 12:42 | |
Unhandled exception in code scheduled on thread 3 | |||
This continuation has already been invoked | |||
timotimo | i didn't see that yet | ||
i'll switch over to dayjob work | 12:43 | ||
robertle | jnthn: I was thinking a bit more about our discussion yesterday regarding "non-blocking await". this would be super cool, but i am wondering whether the fact that you are potentially running under another thread after await(), and the fact that this depends on whether the thread comes fomr a threadpool or is created explicitely is safe | 13:07 | |
either swapping the thread underneath your nose is always safe, in which case you can do it for all threads | 13:08 | ||
or it isn't safe in all cases, in which that distinction doesn't really help due to composition problems: | |||
if I write code in my module and do await, then I can't possibly know whether whoever is calling my module uses the main thread, starts one explcicitely or uses a pool | 13:09 | ||
the place where the threading decision is made is not where the await() happens | |||
so I call MyModule::some-stuff() and it works fine, and I then do that in a start { } block and weird shit happens *within* the module because it relies on the thread not being swapped | 13:10 | ||
jnthn | As I said yesterday, the cases where it matters will be when you're dealing with stuff *outside* of Perl 6 that cares about it, which essentially means "doing native calls". | 13:12 | |
robertle | ah, ok I missed that part. so are you saying I call some native stuff, which uses TLS, then do await, then call native again? | 13:13 | |
which relies on being in the same thread | |||
jnthn | Right, then you could have an issue. But...if you're scheduling stuff on the thread pool you already don't know what thread it will be on. | ||
So that problem already exists today. | 13:14 | ||
robertle | but currently you know that a sequence of statements will be run on the same one, and that's what I am wondering about | ||
jnthn | Right, that's what will change | ||
robertle | I think I just don't understand the use case where it would ever matter if the thread changes... | 13:15 | |
jnthn | You'd pretty much have to be binding a library that uses thread local storage | ||
A much more common situation is that you're binding a library that's not threadsafe and exposes an event loop | 13:16 | ||
In which case you run a real Thread | |||
robertle | ok, the latter makes a lot of sense! regarding TLS, I am not sure whether the distinction between pool or not helps: | 13:17 | |
because your code would call native-stuff-with-tls-A() and later native-stuff-with-tls-B() and the problem is that these two need to happen in the same thread | |||
so if you do that in your main code, you are safe because you can choose what sort of thread to run it under | 13:18 | ||
but if your code that does these calls is in a module, then you may not... | |||
but I do get your point that this only matters if you do something in native code, and that does help a lot because if you do then you need to be quite careful anyway... | 13:19 | ||
jnthn | Well, yes. I think it's on the people writing native library bindings to understand this stuff and make bindings that will not be fragile to such cases | 13:20 | |
And even then, in reality, the problem is more typically that the library is just not thread safe at all, or only is if you follow certain rules. | |||
Zoffix | .tell lizmat These commits [c1bd844][0e0ac2fb][0338ce46][14e09532][c61c7f88] fix RT #131241 for [Bag/Mix]Hash, but it appears the same problem exists in SetHash as well: `m: my $b = <a b b c c c>.SetHash; $_ = -1 for $b.values; dd $b` retains all the keys. Are you able to fix that case as well? | 13:21 | |
yoleaux | Zoffix: I'll pass your message to lizmat. | ||
synopsebot6 | Link: rt.perl.org/rt3/Public/Bug/Display...?id=131241 | ||
robertle | sure. I also wonder whether the assumption that the thread does not change when calling into stuff is so deep in people's minds that they could get quite confused... | 13:22 | |
Zoffix | .tell lizmat from changelog, the affected methods are .values/.iterator/.pairs/.kv | ||
yoleaux | Zoffix: I'll pass your message to lizmat. | ||
robertle | but this is super-powerful and exciting! I do look at systems that receive http calls and then make calls into other systems with retries and standoffs, collate the results and feed them back. these systems would benefit massively from this... | 13:23 | |
jnthn | I don't think there's any silver bullets, but I think the improved scalability and lower risk of deadlocks from pool exhaustion will massively outweight the very small number of surprises that may occur. | 13:25 | |
C | 13:26 | ||
oops | |||
C# does the same thing, fwiw, and I can't think of a case where I got bitten. | 13:27 | ||
Of course I understood the rules so could avoid getting bitten, but even then I struggle to recall needing to work around it. | |||
robertle | cool, really looking forward to this! | 13:35 | |
Zoffix | FWIW non-blocking await is already available if you use `use v6.d.PREVIEW` pragma | 13:36 | |
m: await ^30 .map: {start await start sleep 1}; say now - INIT now | 13:39 | ||
m: use v6.d.PREVIEW; await ^30 .map: {start await start sleep 1}; say "6.d: ", now - INIT now | 13:40 | ||
camelia | (timeout) | ||
6.d: 2.0387999 | |||
jnthn | It'll work even better if you use await Promise.in(1) :) | ||
Zoffix | m: use v6.d.PREVIEW; await ^16 .map: {start await Promise.in: 1}; say now - INIT now | ||
camelia | 1.0214228 | ||
Zoffix | m: await ^16 .map: {start await Promise.in: 1}; say now - INIT now | ||
cool. | 13:41 | ||
camelia | (timeout) | ||
Zoffix | m: use v6.d.PREVIEW; await ^3000 .map: {start await Promise.in: 1}; say "6.d: ", now - INIT now | ||
camelia | 6.d: 1.6653901 | ||
Zoffix | <3 | 13:42 | |
.ask pmurias I see the commits[^1] that look to be about removing too liberal str->num coersions, but this code still coerses them without error. Do we need to do more work to make this stuff fail to coerce on RakudoMoar? `m: my num $x = my str $ = '6 cute'; my num $y = my str $ = '!'; dd [$x, $y ];` [1] github.com/perl6/nqp/compare/2017....2-gc60df1e | 13:51 | ||
yoleaux | Zoffix: I'll pass your message to pmurias. | ||
Zoffix | Future-Zoffix: if we're adding ^ that to changelog, add: + Fixed native str to native int/num coersion accepting non-numeric strings [c776c087] | ||
.tell lizmat seems there's inconsistency in behaviour introduced in 31be512 and 08b5c10 ; BagHash.pick throws when given NaN or -Inf $count, while BagHash.pickpairs equates those value to $count = 0 | 14:13 | ||
yoleaux | Zoffix: I'll pass your message to lizmat. | ||
Zoffix | .tell lizmat just noticed: also for negative values: .pick treats them as Inf, while .pick as 0 | 14:14 | |
yoleaux | Zoffix: I'll pass your message to lizmat. | ||
Zoffix | yoleaux: help | 14:15 | |
.help | |||
yoleaux | Zoffix: I'm yoleaux. Type .commands to see what I can do, or see dpk.io/yoleaux for a quick guide. | ||
Zoffix | .in 24h Zoffix: ensure these (and and few lines up/below) issues are resolved/filed before release: irclog.perlgeek.de/perl6-dev/2017-...i_14607286 | 14:17 | |
yoleaux | Zoffix: I'll remind you on 20 May 2017 14:17Z | ||
dogbert11 | jnthn: did you see timo's recent MoarVM fixes? he was slightly worried that you might not find them 100% agreeable. | 14:22 | |
jnthn | Yeah, I left a comment :) | 14:24 | |
dogbert11 | :) | 14:30 | |
Zoffix | .tell AlexDaniel something's wrong with commitable. I was doing a bunch of runs for `c: 2016.12 for ^1000_000 { }; say now - INIT now` and after doing a few it stopped and even after restarting it it no longer responds | 14:46 | |
yoleaux | Zoffix: I'll pass your message to AlexDaniel. | ||
Zoffix | BTW: the reason I was doing ^ that is I noticed on 2016.12 Rakudo `my $x = 42.abs; my $y = 2.abs; for ^1000_000 { $ = $x }; say now - INIT now` is 2x faster than on HEAD :/ | 14:47 | |
m: for ^1000_000 { }; say now - INIT now | |||
camelia | 0.47756551 | ||
Zoffix | star: for ^1000_000 { }; say now - INIT now | ||
camelia | 0.188090 | ||
eater | oh | ||
Zoffix | m: say .47756551/.0188090 | ||
camelia | 25.39026583 | ||
Zoffix | m: say .47756551/.188090 | 14:48 | |
camelia | 2.539026583 | ||
Zoffix | .ask lizmat `m: for ^1000_000 { }; say now - INIT now` is 2.5x faster on 2016.10 release than on current HEAD. You're the expert on this stuff... is that due to bugs fixed or something that's potentially fixable? | 14:49 | |
yoleaux | Zoffix: I'll pass your message to lizmat. | ||
Zoffix | AlexDaniel: you have a robo message | 15:05 | |
AlexDaniel | . | 15:06 | |
yoleaux | 14:46Z <Zoffix> AlexDaniel: something's wrong with commitable. I was doing a bunch of runs for `c: 2016.12 for ^1000_000 { }; say now - INIT now` and after doing a few it stopped and even after restarting it it no longer responds | ||
AlexDaniel | :O | ||
AlexDaniel slaps commitable | 15:07 | ||
oh wait, it's not here | |||
AlexDaniel slaps committable6 | 15:08 | ||
c: 2014.01 say 42 | |||
committable6 | AlexDaniel, ¦2014.01: «42» | ||
AlexDaniel | c: 2016.12 say 42 | 15:09 | |
committable6 | AlexDaniel, ¦2016.12: «42» | ||
Zoffix | \o/ | ||
AlexDaniel | why the f does it happen though | ||
I mean, it failed to delete extracted build | |||
so when you tried it again it was like “wait, I see it's already there, I think another bot is using it right now… it'll probably delete this build soon so I'll just wait here for my turn” | 15:10 | ||
committable6: why did you leave it there in the first place? | 15:11 | ||
committable6 | AlexDaniel, ¦why: «Cannot find this revision (did you mean “all”?)» | ||
AlexDaniel | e: say 42 | ||
evalable6 | 42 | ||
AlexDaniel | /o\ | 15:12 | |
Zoffix: in case it comes up again, the solution is: rm -rf /tmp/whateverable/rakudo-moar/b2a3441749878e338b0861b14b3b9433cc902f42/ | 15:15 | ||
Zoffix will try to remember that | 15:16 | ||
AlexDaniel: is it always the same hash? | |||
Zoffix giggles at title of github.com/rakudo/rakudo/commit/70...9de7a700da | |||
AlexDaniel | Zoffix: for 2016.12, yes | ||
Zoffix | ZofBot: the IO gran! She's old, but tech savvy! | ||
ZofBot | Zoffix,  in block <unit> at <tmp> line 1» m: class { multi method x ($l = *, :$close) {say "here"}; multi method x (:$close) { say "there" } } | ||
Zoffix | Oh, turns out I already have that in my notes.... | 15:17 | |
<AlexDaniel> now, the problem we have right now is that some of them may leave some crap behind | |||
<AlexDaniel> especially if it segfaulted | |||
<AlexDaniel> so you'd probably need to do something like this: rm -rf /tmp/whateverable/rakudo-moar/* | |||
AlexDaniel | /* is a bit too radical given that right now we are building stuff :) | ||
Zoffix | AlexDaniel: so I can just rm -fr /* ? No need to look for a hash? | ||
Ah. OK | |||
AlexDaniel | so it will have some folders where new builds are actually being… built :) | 15:18 | |
Zoffix reminds eater to write docs for Proc::Async.ready | 15:22 | ||
Zoffix wants a `make` target in Rakudo that does Step 12 of release guide: clone zef, setup paths, and install Inline::Perl5 | 15:36 | ||
jnthn | NeuralAnomaly: status | 15:41 | |
NeuralAnomaly | jnthn, [✘] Next release is today. Since last release, there are 37 new still-open tickets (0 unreviewed and 2 blockers) and 0 unreviewed commits. See perl6.fail/release/stats for details | ||
jnthn | Will do the MoarVM release this evening | 15:42 | |
AlexDaniel | (if anybody wants to write a workaround for whateverable issue, here is the ticket: github.com/perl6/whateverable/issues/144 ) | 15:47 | |
Geth | rakudo/nom: 164c0b5c2d | (Zoffix Znet)++ | docs/ChangeLog Log all commits to date Adds commits: 01dd2138 0338ce46 05479793 06d8800e 07feca67 08a8075f 08b5c101 09506dc8 0bd39de2 0c46aff2 0e0ac2fb 0f21f511 12c50b63 12cec7a7 134efd83 13924397 14568496 146f3a39 14e09532 1562da07 18706852 1a920dcc 1b0e41f9 1c21974d 1c4d8451 1cf7ccba 1d6a0023 1e58925c 1ed76a90 204ea59b 226cd8b6 22bd2bbd ... (20 more lines) |
15:48 | |
Zoffix | ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? | ||
REMINDER: Rakudo 2017.05 will be released this Saturday. Please check | |||
docs/ChangeLog to ensure your work has been correctly recorded. | |||
???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? | |||
timotimo | whoa! | 15:50 | |
life comes at you fast, bro | |||
AlexDaniel | yeah, I just blinked and there's a new release coming | 15:54 | |
didn't we have all these release issues yesterday? :P | 15:55 | ||
timotimo | and how | ||
Zoffix | .tell ugexe latest `zef --debug test` puts an extra blank line after each test. The issue got introduced somewhere in github.com/ugexe/zef/compare/23e80f6...HEAD | 16:03 | |
yoleaux | Zoffix: I'll pass your message to ugexe. | ||
ugexe | github.com/ugexe/zef/blob/master/l...m6#L26-L36 probably this adding the extra \n (the .emit basically goes to a .tap: { .say }) | 16:08 | |
yoleaux | 16:03Z <Zoffix> ugexe: latest `zef --debug test` puts an extra blank line after each test. The issue got introduced somewhere in github.com/ugexe/zef/compare/23e80f6...HEAD | ||
Zoffix | huggable: modules :is: 100 Most Popular (by github stars) Modules: perl6 -MWWW -e 'jget("modules.perl6.org/.json")<dists&....grep(none <p6doc panda>).head(100).say' | 16:10 | |
huggable | Zoffix, Added modules as 100 Most Popular (by github stars) Modules: perl6 -MWWW -e 'jget("modules.perl6.org/.json")<dists&....grep(none <p6doc panda>).head(100).say' | ||
Zoffix | Gonna use ^ that list as a yard-stick for release testing for now... until we get a bot doing this daily | ||
ugexe | mayve check last commit/update too | 16:13 | |
Zoffix | "===> Failed to find dependencies:"... OK, Plan B :) | 16:19 | |
github.com/ugexe/zef/blob/master/l...m6#L26-L36 got an `$out` but it never uses it... | 16:28 | ||
ugexe | ah, yeah i moved that stuff to Zef::Report so not needed | 16:30 | |
Zoffix | this solves the issue and passes t/ tests: github.com/ugexe/zef/pull/163 | 16:34 | |
And xt/ tests seem to be wonky even without this patch | 16:35 | ||
"not ok 3 - Ecosystems => cpan" and unhandled failures in destroy | |||
full output: gist.github.com/zoffixznet/5bd101e...7e9ea4bf6b | |||
ugexe | eh probably cause i just emptied the cpan dist list | 16:36 | |
unhandled failures are from deleting temp files i think... they always happen | |||
so is ok | 16:37 | ||
dunno if .chomp is right, since print doesnt have to end with a \n | 16:38 | ||
e,g, probbly should do .tap: {.print} instead of .say | 16:39 | ||
evalable6 | ugexe, Full output: gist.github.com/d5bed44d0003be4fc6...e1fc6f5c31 | ||
(exit code 1) 04===SORRY!04=== Error while compiling /tmp/TT0gKnM6oR Strange… |
|||
Zoffix | huggable: modules | 16:44 | |
huggable | Zoffix, 100 Most Popular (by github stars and recently updated) Modules: perl6 -MWWW -e 'jget("modules.perl6.org/.json")<dists&...dated>) after Date.new: "2017-01-01"}).head(100)»<name>.grep(none |<p6doc panda v5>, /^ "Inline::"/).put' | ||
Zoffix | Well, I'm up to that ^ but still doesn't want to zef --serial install install them :/ Dies with "Failed to find some required dependencies", but doesn't tell which and I grepped the ecosystem for all the modules it says " Searching for missing dependencies:" and they're all in ecosystem :/ | 16:45 | |
Changed say to print in tap: github.com/ugexe/zef/pull/164 | 16:49 | ||
re-tried the 100-module install... seems to be moving now... | 16:51 | ||
"No extracting backend available" ... ok... Plan E... | 16:57 | ||
""source-url" : "github.com/araraloren/Getopt-Kinok...2.9.zip"," | 16:58 | ||
ugexe | works for me, but I have the unzip command available | 16:59 | |
japhb | ugexe: Does it only try that particular command? | 17:01 | |
ugexe | depends | 17:02 | |
on windows there is a powershell unzip | |||
so if the unzip command wasnt available it would make it to that | |||
probably should just create a zip version of github.com/ugexe/zef/blob/master/r...erl5tar.pl | 17:03 | ||
Zoffix | Yeah, it works if I have unzip installed, but I didn't by default | 17:13 | |
ugexe | hmm maybe your first PR with .chomp is the technically correct one. I will have to test with other backends to see which pr gets more consistent output, but thanks | 17:28 | |
for once windows comes out ahead | 17:29 | ||
[Coke] | one thing we should probably do is start bumping nqp/moarvm releases in advance of the release instead of waiting. Most of the time it's fine, but seems like nom HEAD should have the updates asap (which isn't immediately) | 17:56 | |
Zoffix | [Coke]: I genereally do the bumps when I do my pre-release testing, like today | 18:03 | |
we can have a bot auto-bump daily too, I guess | |||
timotimo | then we'll have to be much more branchy in nqp and moarvm | 18:11 | |
Zoffix kinda thought that was already the case | 18:15 | ||
i.e. nqp/moar are kept in the same "spectest is clean" state as nom | |||
rather than having some partial work in it | |||
jnthn | We generally do try to keep "master is shippable" discipline | 19:01 | |
timotimo | not always, though. like when i was dumb enough to merge telemeh before it was readý | 19:04 | |
jnthn | Well, yes, it only works as well as people committing make it work :) | 19:09 | |
Zoffix | bah... my super twittable trick of `but`ing a Promise to attach a tag to it failed :( | 19:25 | |
m: my @s = start { sleep 1; say "one"; }, start { sleep 2; say "two" }; await Promise.anyof: @s; | |||
camelia | one | ||
Zoffix | m: my @s = (start { sleep 1; say "one"; } but role {}), (start { sleep 2; say "two" } but role {}); await Promise.anyof: @s; | ||
.anyof seems not to like butted promises | |||
s: Promise, 'anyof', \(start {}) | |||
SourceBaby | Zoffix, Sauce is at github.com/rakudo/rakudo/blob/164c...se.pm#L231 | ||
camelia | (timeout)one two |
||
jnthn | I'm not surprised | 19:27 | |
but does a clone | |||
timotimo | hah, of course | ||
jnthn | does would be more suitable | ||
Zoffix | Ohh, right | ||
m: my @s = (start { sleep 1; say "one"; } does role {}), (start { sleep 2; say "two" } does role {}); await Promise.anyof: @s; | 19:28 | ||
camelia | one | ||
Zoffix | yey | ||
jnthn++ | |||
man, forgot role is not a closure | 19:43 | ||
eater | can I note that the docs around Proc::Async.start are very confusing | 19:44 | |
Zoffix | m: my @s = ^1 .map: -> $m { start { sleep 1; say "one"; } does role { method Name { $m } } }; await Promise.allof: @s; @s».Name.say | 19:45 | |
camelia | one [0] |
||
Zoffix | eater: well-volunteered! :) BTW, reminder to add Proc::Async.ready docs. Release soon will ship and it's in the changelog and people will look it up | 19:46 | |
eater | Zoffix: ye :p that's why Im noting that | ||
building and checking now if it's any good | |||
Zoffix | m: my @s = <foo bar ber>.map: -> $m { start { } does role { method Name { $m } } }; await Promise.allof: @s; @s».Name.say | ||
camelia | [ber ber ber] | ||
Zoffix | m: role Foo[$m] { method Name { $m } }; my @s = <foo bar ber>.map: -> $m { start { } does Foo[$m] }; await Promise.allof: @s; @s».Name.say | 19:51 | |
camelia | [foo bar ber] | ||
Zoffix | win | ||
eater | m: my $d = Proc::Async.new(<bash -c>, "exit 1"); $d.ready.then({ say "Kept! "; }); try sink await $d.start; say $d.ready.status | 19:53 | |
camelia | Proc::Async is disallowed in restricted setting in sub restricted at src/RESTRICTED.setting line 1 in method new at src/RESTRICTED.setting line 32 in block <unit> at <tmp> line 1 |
||
eater | :( | ||
anyway this results in "Kept! Broken" | 19:54 | ||
A promise can be broken after it has been Kept? | |||
Zoffix | eater: .then starts a new promise that runs after the first one finished, regardless of whether it was Kept or Brokenb | 19:55 | |
m: await start { die }.then: {say "Live!"} | |||
camelia | Live! | ||
Zoffix | m: await start { die }.then: { say .status } | 19:56 | |
camelia | Broken | ||
Zoffix | m: await start { 42 }.then: { say .status } | ||
camelia | Kept | ||
eater | ah | ||
thanks Zoffix :) | |||
or wait! | 19:58 | ||
eater++ | |||
eh | |||
Zoffix++ | |||
[Tux] | This is Rakudo version 2017.04.3-291-g164c0b5c2 built on MoarVM version 2017.04-68-g5f233249 | 20:13 | |
csv-ip5xs 2.491 | |||
test 12.723 | |||
test-t 4.258 - 4.289 | |||
csv-parser 12.727 | |||
japhb | huggable: speed | 20:19 | |
huggable | japhb, tux.nl/Talks/CSV6/speed4.html | ||
japhb | buggable: speed | ||
buggable | japhb, ↑↑▅▄▄▇█▄▄▇▆▃▄▃▂▄▃▃▃▃▃▂▂▂▂▂▂▂▂↑▂▁▁▃▁▁▂▁▁▂▁▁▃▃▃▃▃▃▂▂ data for 2017-04-30–2017-05-19; range: 4.194s–6.181s; 25% faster | ||
Zoffix | buggable: speed 20 | 20:20 | |
buggable | Zoffix, ▂▁▂▃▁▁▂▁▁▂▁▁▄▃▃▃▃▄▂▃ data for 2017-05-12–2017-05-19; range: 4.194s–4.352s; 1% slower | ||
jnthn | Yes, .then is called even on a Broken Promise | ||
The idea being that you'll usually call .result in there | |||
Zoffix | .oO( there are lies, damned lies, and buggable... ) |
||
jnthn | And that will rethrow the exception | ||
Geth | rakudo/nom: a61746feda | (Zoffix Znet)++ | src/core/Promise.pm Make Promise subclass-friendly Instead of hardcoded `Promise`, use `self` when instantiating new Promises, that way if we're a subclass, we instantiate a sublcass instead of the original `Promise`. |
20:28 | |
Zoffix | grrr... someone's grinding concrete upstairs... What a pleasant environment to hack in >_< | 20:36 | |
5pm before a long weekend... go home... | 20:37 | ||
m: await Promise.in(-0.001).then: {say "done"} | 20:38 | ||
camelia | (timeout) | ||
Geth | roast: 7e9451614b | usev6++ | 2 files [JVM] X::Parameter::InvalidConcreteness NYI |
||
roast: 225d12ba80 | usev6++ | 7 files [JVM] Fudge some newly added tests |
|||
roast: 105e18043b | usev6++ | S16-io/comb.t [JVM] Two new failing tests, one passer for comb |
|||
Zoffix | ZofBot: engage Anti-Concrete-Grinding-Device! Blast it, baby: www.youtube.com/watch?v=mxDiKSHqBIc | 20:40 | |
ZofBot | Zoffix, new(2, "2")),) | ||
Zoffix | hm, this one's better: www.youtube.com/watch?v=7EvOTkEMlug | 20:42 | |
Geth | rakudo/nom: a7c23aa214 | (Zoffix Znet)++ | src/core/Promise.pm Make .then on completed Promise subclass-friendly |
21:04 | |
roast: 926f20d109 | (Zoffix Znet)++ | S17-promise/basic.t Test Promise is subclass-friendly Rakudo fix: github.com/rakudo/rakudo/commit/a61746feda github.com/rakudo/rakudo/commit/a7c23aa214 |
|||
lizmat | . | 21:34 | |
yoleaux | 13:21Z <Zoffix> lizmat: These commits [c1bd844][0e0ac2fb][0338ce46][14e09532][c61c7f88] fix RT #131241 for [Bag/Mix]Hash, but it appears the same problem exists in SetHash as well: `m: my $b = <a b b c c c>.SetHash; $_ = -1 for $b.values; dd $b` retains all the keys. Are you able to fix that case as well? | ||
synopsebot6 | Link: rt.perl.org/rt3/Public/Bug/Display...?id=131241 | ||
yoleaux | 13:22Z <Zoffix> lizmat: from changelog, the affected methods are .values/.iterator/.pairs/.kv | ||
14:13Z <Zoffix> lizmat: seems there's inconsistency in behaviour introduced in 31be512 and 08b5c10 ; BagHash.pick throws when given NaN or -Inf $count, while BagHash.pickpairs equates those value to $count = 0 | |||
14:14Z <Zoffix> lizmat: just noticed: also for negative values: .pick treats them as Inf, while .pick as 0 | |||
14:49Z <Zoffix> lizmat: `m: for ^1000_000 { }; say now - INIT now` is 2.5x faster on 2016.10 release than on current HEAD. You're the expert on this stuff... is that due to bugs fixed or something that's potentially fixable? | |||
Zoffix | :} | ||
lizmat | just back from a Guardians of the Galaxy / Alien Covenant marathon | 21:35 | |
fwiw, I think the SetHash behaviour has been around a long time already | 21:37 | ||
and I'm not clearminded enough atm to attempt to fix that (although I think I know how) | 21:38 | ||
how much time do I have before release ? | |||
Zoffix | m: say (DateTime.new('2017-05-20T11:00:00-04:00') - DateTime.now.in-timezone(-4*3600)) / 3600 | 21:41 | |
camelia | 17.3136951431377 | ||
Zoffix | lizmat: that many hours, but I'm flexible. | ||
lizmat | well, I'm gonna need at least 9 hours of sleep | 21:42 | |
MasterDuke | Zoffix, lizmat: graph for `for 1000_000 { }` gist.github.com/Whateverable/36a4c...aaf82c39c7 | 21:46 | |
Zoffix | cool | ||
c: c069f45 for ^1000_000 { }; say now - INIT now | 21:48 | ||
committable6 | Zoffix, ¦c069f45: «0.5158494» | ||
Zoffix | c: c069f45~1 for ^1000_000 { }; say now - INIT now | ||
committable6 | Zoffix, ¦c069f45~1: «0.5253575» | ||
Zoffix | c: c069f45~10 for ^1000_000 { }; say now - INIT now | ||
committable6 | Zoffix, ¦c069f45~10: «0.4419105» | ||
lizmat | $ 6 'for 1000000 {}; say now - INIT now' | 21:49 | |
0.0015960 | |||
Is my machine so much faster ? | |||
MasterDuke | c: bfbf348,c069f45 for ^1000_000 { }; say now - INIT now | ||
committable6 | MasterDuke, ¦bfbf348: «0.171921» ¦c069f45: «0.5364211» | ||
MasterDuke | lizmat: missing a `^` | ||
japhb | lizmat: You forgot ^ | ||
lizmat | ah, duh | 21:50 | |
see, I'm in no shape to be programming :-) | 21:51 | ||
Zoffix | :) | ||
c: c069f45,87f61d9,18e6f0d,f2b97b0,6c92994,ab3162c,7384939,9f15a4d,bc53f67,97359ae,951a441,9493ffb,d69f375,b9d9279,0152316,9ed4449,f8b3469,5401a1a,f94cb21,4366603,f22170f,a2d69a0,ee7c1bb,3e28b1e,87d40ab,ac37a20,084cae1,9086216 for ^1000_000 {}; say now - INIT now | 21:52 | ||
lizmat | reverting c069f4598b0a8a51a9 to see if that makes a difference, don't think it will but... | ||
committable6 | Zoffix, gist.github.com/8fa9999eb3502a7c79...836f88a2d3 | ||
Zoffix | c: 5401a1a for ^1000_000 { }; say now - INIT now | 21:53 | |
committable6 | Zoffix, ¦5401a1a: «0.4943332» | ||
Zoffix | c: 5401a1a~1 for ^1000_000 { }; say now - INIT now | ||
committable6 | Zoffix, ¦5401a1a~1: «0.1777426» | ||
Zoffix | Looks to be due to 5401a1a | ||
lizmat | points to jnthn :-) and indeed looks like we lost the ^N optimization again | 21:54 | |
jnthn | Again? Urgh | ||
lizmat decides she is too tired to look at the Baggy / Setty stuff now | |||
will check in the morn | 21:55 | ||
nighty night! | |||
jnthn | That opt is fragile as heck... | ||
'night lizmat | |||
Zoffix | Filed as rt.perl.org/Ticket/Display.html?id=131330 | 21:56 | |
MasterDuke++ nice bots :) | |||
MasterDuke | thanks | 21:57 | |
Zoffix | m: ^2 .grep: {try 1 after 0} | 22:23 | |
camelia | WARNINGS for <tmp>: Useless use of "after" in expression "1 after 0" in sink context (line 1) |
||
Zoffix | Filed as rt.perl.org/Ticket/Display.html?id=131331 | 22:24 | |
hm. looks like something broke my `M` module I made in Feb :/ travis-ci.org/zoffixznet/perl6-M | 22:31 | ||
18% of top 100 modules fail :( Tested with my zefyr.p6 tool: gist.github.com/zoffixznet/5909465...7fb4915598 | 22:34 | ||
s: [], 'head', \() | |||
SourceBaby | Zoffix, Sauce is at github.com/rakudo/rakudo/blob/a7c2...s.pm#L1852 | ||
Zoffix | I think it needs `is nodal` | 22:35 | |
Failures in top 100: Bailador Crust November Digest Frinfon Slang::SQL List::Utils XML::Parser::Tiny ANTLR4 Perl6::Maven GraphQL MagickWand WebSocket IO::Prompter BioInfo Flower Plosurin MongoDB | 22:36 | ||
Zoffix builds 2017.03 to see if numbers change | 22:37 | ||
Actually strike Digest from the list. I know a fix for it | 22:40 | ||
ZofBot: ♫ everyone's asleep ♫ it's just youuuuu and meeee ♩ tood-todoooo ♩ tad-tadaaaaa | 22:44 | ||
ZofBot | Zoffix, 10 (Debian) Content-Length: 301 Connection: close Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2 | ||
Zoffix | ZofBot: HTML 2?! What kind of places do you visit! BAD ROBOT! NO COOKIE! | 22:45 | |
ZofBot | Zoffix, (This message differs from what "fail", "warn", and "die" would say by default, since the latter operators typically point out bad data or programming rather than just an incomplete design | ||
Zoffix | holy crap... I'm having trouble even counting the number of spectests that fail on Windows :| gist.github.com/zoffixznet/856593c...16ffe14809 | 22:50 | |
Ah, ok. Good news. Many of them are due to apparently-busted `make-temp-file` routine | 22:51 | ||
or crap.. bad news, make-temp-file is likely busted due to some IO unholiness :S "Failed to open file C:\C:\Users\zoffi\AppData\Local\Temp\perl6_roast__e_line1_0_1603368517871361495234412: no such file or directory" | 22:53 | ||
'C:\' x 2 :/ | |||
Well. Glad I ran the tests on Win32. 'cause I can fix this before release \o/ | 22:54 | ||
MasterDuke | yay for testing | ||
Zoffix | hm; ok. it's `.resolve` stuff. Won't fix for release. Was broken since Christmas | 22:59 | |
well, `WWW` that zefyr.p6 needs won't install on 2017.03 :| | 23:00 | ||
Zoffix tries an earlier-still release | 23:01 | ||
Geth | roast: b5b975b7d8 | (Zoffix Znet)++ | packages/Test/Util.pm Temporarily remove .resolve for Windows in make-temp-* Currently Rakudo's IO::Path.resolve isn't Windows-friendly; should might be fixed in a month or so. |
23:12 | |
Zoffix | Hm... JSON::Unmarshal appears to fail on Rakudos < 2017.04 or so. And that module is used by META6 | 23:25 | |
Zoffix feels stupid making Test::META a mandatory, user-facing test now |