[01:33] <Zoffix> t/spec/S32-io/IO-Socket-Async.t wobbly :( https://gist.github.com/zoffixznet/eac1da1d59a5babf42e2d730211d14cc

[01:33] <Zoffix> (worked fine when I ran it by itself)

[01:39] <MasterDuke> i seem to remember getting that a bunch when i 'make spectest'

[01:39] <Zoffix> m: use Test; cmp-ok 2, '<', 5

[01:39] <camelia> rakudo-moar 2126ed: OUTPUT«not ok 1 - ␤␤# Failed test at <tmp> line 1␤# Could not use '<' as a comparator␤»

[01:40] <Zoffix> m: use Test; cmp-ok '', '~~>;warn run "ls"; <z', '', '';

[01:40] <camelia> rakudo-moar 2126ed: OUTPUT«Perlito␤dalek-queue␤evalbot␤evalbot.log␤foo␤lib␤log␤mbox␤nqp-js␤p1␤p2␤p6eval-token␤perl5␤rakudo-j-1␤rakudo-j-2␤rakudo-j-inst␤rakudo-j-inst-1␤rakudo-j-inst-2␤rakudo-m-1␤rakudo-m-2␤rakudo-m-inst␤rakudo-m-inst-1␤rak…»

[01:40] <Zoffix> PR to fix both of the above: https://github.com/rakudo/rakudo/pull/786

[01:40] <timotimo> you are *mean* :)

[01:40] <timotimo> why am i not in bed yet

[02:16] <Zoffix> m: say 100 ≅ -100

[02:16] <camelia> rakudo-moar 2126ed: OUTPUT«True␤»

[02:16] <Zoffix> RT: https://rt.perl.org/Ticket/Display.html?id=128421

[02:16] <Zoffix> Fix: https://github.com/rakudo/rakudo/pull/787

[02:16] <Zoffix> Tests: https://github.com/perl6/roast/pull/128

[02:47] <dalek> rakudo/nom: 102b0ea | (Zoffix Znet)++ | / (2 files):

[02:47] <dalek> rakudo/nom: Fix cmp-ok

[02:47] <dalek> rakudo/nom:

[02:47] <dalek> rakudo/nom: * Make it possible to use '<' and '>' (strings) as comparators.

[02:47] <dalek> rakudo/nom: * Avoid EVAL to prevent exploitable code ( https://rt.perl.org/Ticket/Display.html?id=128283 )

[02:47] <dalek> rakudo/nom:

[02:47] <dalek> rakudo/nom: Note that we explicitly don't support user-defined operators passed as comparators

[02:47] <dalek> rakudo/nom: *as strings* and we can't use CALLER:: (see http://irclog.perlgeek.de/perl6-dev/2016-06-16#i_12678792).

[02:47] <dalek> rakudo/nom: Those are to be used with &[op] notation.

[02:47] <dalek> rakudo/nom: review: https://github.com/rakudo/rakudo/commit/102b0eade9

[02:47] <dalek> rakudo/nom: 21f0be1 | lizmat++ | / (2 files):

[02:47] <dalek> rakudo/nom: Merge pull request #786 from zoffixznet/fix-cmp-ok

[02:47] <dalek> rakudo/nom:

[02:47] <dalek> rakudo/nom: Fix cmp-ok

[02:47] <dalek> rakudo/nom: ee915c3 | (Zoffix Znet)++ | src/core/Numeric.pm:

[02:47] <dalek> rakudo/nom: Fix RT#128421

[02:47] <dalek> rakudo/nom:

[02:47] <dalek> rakudo/nom: Fix ≅ incorrectly handling negative numbers, e.g. producing True for 100 ≅ -100

[02:47] <dalek> rakudo/nom: review: https://github.com/rakudo/rakudo/commit/ee915c3a42

[02:47] <synopsebot6> Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=128421

[02:47] <dalek> rakudo/nom: 70c19dd | lizmat++ | src/core/Numeric.pm:

[02:47] <dalek> rakudo/nom: Merge pull request #787 from zoffixznet/fix-approx-op

[02:47] <dalek> rakudo/nom:

[02:47] <dalek> rakudo/nom: Fix RT#128421

[02:47] <synopsebot6> Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=128421

[02:47] <dalek> rakudo/nom: review: https://github.com/rakudo/rakudo/commit/70c19dd34c

[03:37] <Zoffix> Is there a point in throws-like taking a Str at all?

[03:38] <Zoffix> If one can't reference any current-scope symbols in the string to be evaled, what is left that would still be useful?

[03:38] <timotimo> if you want compile-time errors

[03:38] <timotimo> like "undefined symbols"

[03:39] <Zoffix> Like what symbols?

[03:40] <Zoffix> m: use Test; eval-dies-ok q[my $joffrey = "nasty"; die "bye bye Ned" if $joffrey ~~ /nasty/], "Ned Stark dies";

[03:40] <camelia> rakudo-moar 70c19d: OUTPUT«ok 1 - Ned Stark dies␤»

[03:40] <Zoffix> m: use Test; eval-dies-ok q[my $joffrey = "nasty"; die "bye bye Ned" if $joffrey ~~ /dfsadsadsadasnasty/], "Ned Stark dies";

[03:40] <camelia> rakudo-moar 70c19d: OUTPUT«not ok 1 - Ned Stark dies␤␤# Failed test 'Ned Stark dies'␤# at <tmp> line 1␤»

[03:40] <Zoffix> why is this working :/

[03:41] <Zoffix> Oh

[03:41] <Zoffix> I guess I should say, yeah, that's working, but is entirely useless.

[03:42] <Zoffix> timotimo, what sort of symbols? None of the symbols from where the test is being run would be defined.

[03:43] <timotimo> um

[03:43] <timotimo> like '$joffrey = "nasty"'

[03:43] <timotimo> you want that to throw an "undefined symbol" error

[03:43] <timotimo> don't forget we have a language test suite as the biggest user of the test library

[03:45] <Zoffix> Thanks

[03:45] <Zoffix> Well, sorta.

[03:46] <Zoffix> The stuff in roast is testing core features that are available in the context of the code EVALed.

[03:47] <timotimo> right

[03:49] <Zoffix> [21:41:14] <timotimo> why am i not in bed yet

[03:50] <Zoffix> [23:50:15] <Zoffix> [21:41:14] <timotimo> why am i not in bed yet

[03:50] <Zoffix> :)

[03:50] <timotimo> yeah, can't sleep :(

[03:50] <Zoffix> ditto

[03:50] <Zoffix> 10 to midnight here

[03:50] <timotimo> right now i'm looking for a mini usb cable

[03:50] <timotimo> it's ten to six here

[03:51] <jdv79> its ten of tomorrow round these parts

[04:01] <Zoffix> So basically RT#128419 is all just about fixing roast. The docs explicitly say EVAL won't be in context.

[04:01] <synopsebot6> Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=128419

[04:02] <b2gills> m: sub test ($s) { &CALLERS::("infix:<$s>") }; { sub infix:<b> ($a,$b){}; say test 'b' }

[04:02] <camelia> rakudo-moar 70c19d: OUTPUT«sub infix:<b> ($a, $b) { #`(Sub+{Precedence}|47569280) ... }␤»

[04:06] <Zoffix> b2gills, you should read RT tickets more often :) there was a lot of effort to figure that out: https://rt.perl.org/Ticket/Display.html?id=128283

[04:07] <Zoffix> b2gills++

[04:10] <Zoffix> I'll send a fix to cmp-ok tomorrow or in a few days

[04:16] <Zoffix> There's a shitzillion roast failures with RT#128419 fix: https://gist.github.com/zoffixznet/0ca7276773cb53ebd4c08339dff3b05b

[04:16] <synopsebot6> Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=128419

[04:17] <Zoffix> Before I expend time fixing them, it's fine to just convert all of them to throws-like { EVAL '...' }, right?

[06:42] <[Tux]> This is Rakudo version 2016.05-156-g70c19dd built on MoarVM version 2016.05-18-g1339332

[06:42] <[Tux]> test            17.352

[06:42] <[Tux]> test-t           9.743

[06:42] <[Tux]> csv-parser      21.946

[07:18] <patrickz> http://www.ugexe.com/when-open-source-doesnt-work/

[07:19] <patrickz> I guess someone should give ugexe a commit bit to rakudo.

[07:31] <stmuk> I think he just has to sign a contribution agreement?

[07:32] <stmuk> or chase people over PRs :)

[07:42] <masak> I... don't understand the message of that post.

[07:43] <masak> is it a comment on something that happened recently that I missed?

[08:01] <flok420> did some benchmarking of some code and perl 5 ran it in 2 minutes and 43 seconds and perl 6 took around 15 hours. this may already be known by you guys but if not example code can be found at https://vanheusden.com/misc/blog/2016-05-19_brainfuck_compilers_compared.php

[08:04] <nine> masak: I can pretty much guess what it's about: PR 729

[08:04] <flok420> the perl script generated is http://vps001.vanheusden.com/~folkert/test.pl (perl 6 version, the 5 version can be generated with the scripts on the site mentioned)

[08:04] <nine> masak: which is all the more surprising since it has been waiting for ugexe to fix a backwards compatibility issue.

[08:05] <nine> masak: I'd be very happe to see it merged once it doesn't break installed modules for everyone.

[08:11] <psch> flok420: the 'Perl 6' link seem to link to python code?

[08:12] <psch> ...actually, everything links to python code?

[08:13] <psch> oh, now i get it

[08:13] * psch is still waiting on the coffee

[08:13] <nine> If only people would at least try to talk first before storming off and leaving a rant on a blog :/

[08:17] <psch> flok420: well, the only obvious thing i can think of is adding module code, which would allow you to precompile the compiler itself, which should reduce runtime after the first run

[08:18] <psch> or, well, after installing the distribution if you want to go that far vOv

[08:37] <flok420> psch yeah those python scripts generate e.g. perl or cobol or javascript etc code from a brainfuck program.

[08:38] <flok420> psch: sorry if I don't respond immediately: am at work currently

[08:38] <psch> right, and in general you probably don't particularly care to run the same generated program more than once, which kind of makes "turn it into a module" a bit of a not-terribly-fitting solution

[08:39] <psch> fwiw, if i wanted to generate something that can work on the rakudo compiler, i'd probably straight generate the corresponding QAST via hooking into Perl6::{Grammar,Actions}, but that's also far removed from a fairly comparable solution

[08:40] <psch> not to mention probably terribly annoying to write :P

[08:42] <psch> anyway, yeah, NQP is probably the reasonable target for a compiler (it's what it's for after all), but the compilers are all in python already

[08:43] <psch> so, the general slowness is probably "iteration could be faster" and "invocation could have less overhead", which both are well known

[08:44] <psch> unfortunately 4.9k loc is definitely too much for our profiler, as we don't have an output target for that yet that works with big profiles afaik

[08:44] <psch> as in, the json we generate usually comes with some HTML around, which probably won't work out with 4.9k loc :)

[08:46] <jnthn> It's more about how deep the call tree goes and how varied it is than the number of lines of code

[08:47] <psch> well, the file in question declares 43 subs, and calls at least a few nested vOv

[08:47] <jnthn> Worth a try... :)

[08:48] <jnthn> fwiw, I've been sent a generated output from that to look at also

[08:48] <psch> ah, alright then

[08:48] <psch> i'll do some more waking up and then back at the nested CU thingy...

[08:50] <jnthn> :)

[08:50] * jnthn will continue trying to fix return stuff on JVM this afternoon :)

[08:55] <psch> although i really can't shake the feeling that we're just somehow messing up in the cuid_to_qbid mapping...

[09:41] <masak> nine: huh. sounds like a misunderstanding, or unintended deadlocking, or something.

[09:51] <nine> yep

[09:51] <nine> which could have been cleared up by simply asking

[10:24] <Zoffix> Turns out "* ugexe (ugexe@p6.nu) has left ("pointless")" was weird...

[10:37] <Zoffix> So there are now two raging blog post about nine and precompilation over a few bugs? 😂

[10:37] <Zoffix> No one's rage-posting about .hyper being broken! Priorities! 😂

[10:47] <Zoffix> Are we doing R* release for 2016.06.06? Seems there were many speed improvements since 04

[10:49] <nine> Zoffix: damn...now I read the post again. I skimmed it only the first time around because I knew already what it was about and I feared to find exactly what I now read: unfair accusations and personal attacks :/

[10:53] <Woodi> .o(*Patience* is a virtue)

[10:54] <Zoffix> Well, I've read the PR and channel log and the post seems to make a huge number of assumptions and invent reasons for deadlocking, so don't take it too personally.

[10:54] <Zoffix> Looks like just a very strange way to vent frustration.

[10:56] <Zoffix> Hell, I have 56 still-open PRs some of them going back years: https://github.com/search?utf8=✓&q=is%3Aopen+is%3Apr+author%3Azoffixznet

[10:57] <nine> All the frustration about me taking on the precomp stuff could have been avoided by ugexe or tony-o dropping a note about them working on a solution already. Instead they worked on "open" source in private.

[10:58] <Zoffix> Waaaait a minute. A ton of them are to masak's repos!

[11:03] <nine> You should clearly rage quit working on masak!

[11:03] <nine> .oO(that somehow sounds very wrong)

[11:04] <psch> hrm

[11:05] <psch> i am unsure if i have reasonable suspicion to not persue the nested JCLASS solution, or if i'm just procrastinating a lot of annoying work :P

[11:05] <psch> 'cause (1) the missing qbid feels off.  we never generate a method for that and (2) i remember the NPE in 'sub f { sub g { 1 } }; f()()'

[11:05] <nine> psch: oh I can sympathize so well

[11:06] <psch> which seems somewhat related, even though it's *very* hunchy

[11:08] <psch> nine: but what do i doo D:

[11:08] <nine> I can only say that I probably lost a week due to putting off the lot of annoying work and trying to muddle through instead

[11:10] <psch> i mostly don't want to put in all the annoying work and then find out it wasn't the right solution in the first place

[11:13] <nine> those were my thoughts exactly :)

[11:13] <nine> Of course, it's still possible that it's not the right solution after all :/

[11:16] <psch> yeah...

[11:16] <psch> i think i'll have to figure out why we don't generate a strictly ascending list of qb_* methods

[11:16] <psch> because, well, that's kind of a hint, right

[11:17] <psch> if it is because we somehow skip it but shouldn't, it means that the cuid => qbid mapping gets wonky

[11:17] <psch> ...although i'm not sure yet how to figure out if we wrongfully don't gen it /o\

[11:17] <nine> What makes you think that they should be strictly ascending?

[11:18] <psch> well, they're not sorted, but all number from 0 to num-methods - 1 exist

[11:18] <psch> sooo i'm probably again wrongly saying "strictly ascending" :)

[11:19] <psch> and they don't all exist we break during initializeCompunit in CompUnit.java

[11:20] <psch> because each CU gets its lexical values set during init

[11:20] <psch> *and *if* they

[12:24] <[Coke]> rakudo.org certs are tripping up chrome.

[12:24] <[Coke]> "This server could not prove that it is rakudo.org; its security certificate is from host.pmichaud.com. This may be caused by a misconfiguration or an attacker intercepting your connection.

[12:24] <[Coke]> "

[12:24] <[Coke]> oh, and actually the front page is dead.

[12:25] <[Coke]> oh. https doesn't work, http does. (I have https everywhere enabled)

[12:27] <AlexDaniel> Zoffix: the situation with .hyper is too depressing… I don't think that you can go through writing a blog post without commiting suicide ;)

[12:27] <BrokenRobot> :D reminds me of a coworker who claimed one of our website was broken, so I come over to their desk and watch them go to the browser, pull down "https://google.com" from location bar, delete the "google" part and try to visit the site via HTTPS :P

[12:28] <AlexDaniel> but he was right! What's your reasoning for not having https set up? ;)

[12:28] <BrokenRobot> AlexDaniel: it's very simple: money

[12:28] <nine> What? pmicheaud trying to usurp Perl 6!

[12:29] <AlexDaniel> BrokenRobot: oh right. What's the cost of letsencrypt nowadays? ;)

[12:29] <BrokenRobot> AlexDaniel: then I'll make the broken .hyper work for me and write a blog post when it's fixed!

[12:29] <BrokenRobot> https://xkcd.com/1172/

[12:29] <BrokenRobot> AlexDaniel: the cost of paying me to learn how to use it and use it. But the event happened before letsencrypt existed anyway

[12:30] <AlexDaniel> okay

[12:32] <BrokenRobot> Though we probably should have it on rakudo.org :D

[12:33] <[Coke]> I opened an RT, and forwarded the rt to [email@hidden.address]
[12:33] <[Coke]> (which i assume is pm)

[12:34] <[Coke]> MasterDuke: are you still having trouble commenting on RT tickets?

[12:34] <[Coke]> (https://github.com/rakudo/rakudo/pull/775)

[13:01] <MasterDuke__> [Coke]: yeah, my account seems to be messed up

[13:02] <MasterDuke__> per AlexDaniel's advice i emailed the admin account (about 3 weeks ago), but haven't heard back

[13:04] <MasterDuke__> and when i email perl-bugs-followup it takes a while for my emails to show up

[13:04] <MasterDuke__> see #128280 for example

[13:04] <synopsebot6> Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=128280

[13:07] <flok420> I've got my uint8 $test = 0; $test--; $test &= 255; this fails with This type cannot unbox to a native integer: P6opaque, Junction

[13:07] <psch> flok420: & isn't bitwise and

[13:07] <psch> (also that's kind of a #perl6 question i think)

[13:08] <flok420> ah ok. thought it was a bug.

[13:08] <psch> m: say 3 +& 2

[13:08] <camelia> rakudo-moar 70c19d: OUTPUT«2␤»

[13:08] <psch> m: say 3 & 2

[13:08] <camelia> rakudo-moar 70c19d: OUTPUT«all(3, 2)␤»

[13:08] <BrokenRobot> flok420: there *is* a bug though. $test will have -1

[13:08] <AlexDaniel> m: uint8 $test = 0; $test--; say $test

[13:08] <camelia> rakudo-moar 70c19d: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Two terms in a row␤at <tmp>:1␤------> uint8⏏ $test = 0; $test--; say $test␤    expecting any of:␤        infix␤        infix stopper␤        statement end␤        statement modifier␤…»

[13:09] <AlexDaniel> m: my uint8 $test = 0; $test--; say $test

[13:09] <camelia> rakudo-moar 70c19d: OUTPUT«-1␤»

[13:09] <AlexDaniel> holy…

[13:09] <psch> m: my uint8 $t = 0; $test--; $test +&= 255; say $test

[13:09] <camelia> rakudo-moar 70c19d: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Variable '$test' is not declared␤at <tmp>:1␤------> my uint8 $t = 0; ⏏$test--; $test +&= 255; say $test␤»

[13:09] <AlexDaniel> bisect: my uint8 $test = 0; $test--; say $test

[13:09] <bisectable> AlexDaniel: on both starting points the exit code is 0 and the output is identical as well

[13:09] <psch> m: my uint8 $test = 0; $test--; $test +&= 255; say $test

[13:09] <camelia> rakudo-moar 70c19d: OUTPUT«-1␤»

[13:09] <BrokenRobot> That's been the case since pre-Christmas.

[13:09] <AlexDaniel> m: my UInt $test = 0; $test--; say $test

[13:09] <camelia> rakudo-moar 70c19d: OUTPUT«Type check failed in assignment to $test; expected UInt but got Int (-1)␤  in block <unit> at <tmp> line 1␤␤»

[13:09] * BrokenRobot digs for the RT detaling a lot of discrepancies

[13:09] <AlexDaniel> /o\

[13:09] <psch> AlexDaniel: UInt unfortunately doesn't get native fastitude anymore :/

[13:10] <psch> well, "anymore" as in "in contrast to uint"

[13:11] <flok420> ok thanks guys!

[13:11] <BrokenRobot> Here, I didn't get through all of them tho: https://rt.perl.org/Ticket/Display.html?id=127409

[13:11] <AlexDaniel> flok420: by the way, it is mentioned here: http://doc.perl6.org/language/5to6-nutshell

[13:13] <flok420> thanks, I'll read it

[13:14] <AlexDaniel> /o\

[13:19] <BrokenRobot> m: my Int $test = 1; $test /= 2

[13:19] <camelia> rakudo-moar 70c19d: OUTPUT«Type check failed in assignment to $test; expected Int but got Rat (0.5)␤  in block <unit> at <tmp> line 1␤␤»

[13:20] <jnthn> m: my Int $test = 1; $test div= 2

[13:20] <camelia> rakudo-moar 70c19d: ( no output )

[13:28] <dalek> nqp/return-without-lexotic: 390a1c5 | jnthn++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/ExceptionHandling.java:

[13:28] <dalek> nqp/return-without-lexotic: Skip compiler stubs as well as thunks.

[13:28] <dalek> nqp/return-without-lexotic: review: https://github.com/perl6/nqp/commit/390a1c53d6

[13:30] <BrokenRobot> m: sub infix:<<»> {}; sub foo ($c) {say &CALLERS::("infix:<$c>") // &CALLERS::("infix:<{$c.subst("<", "\\<", :g)}>") // &CALLERS::("infix:«$c»") }; foo $_ for "<", "<»"

[13:30] <camelia> rakudo-moar 70c19d: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Cannot declare a variable by indirect name (use a hash instead?)␤at <tmp>:1␤------> b foo ($c) {say &CALLERS::("infix:<$c>")⏏ // &CALLERS::("infix:<{$c.subst("<", "\␤»

[13:31] <psch> m: sub infix:['<»'] { }

[13:31] <camelia> rakudo-moar 70c19d: ( no output )

[13:31] <BrokenRobot> Fixed by escpaing the < in <, but I guess we can't make a better error?

[13:31] <psch> fwiw, i think $*W.canonicalize_pair needs some deeper thought in general

[13:32] <psch> and, well, ::() needs to go through it too to make things easier

[13:32] <psch> probably only when we do find a pair in ::(), though

[13:35] <jnthn> Yay, seems I managed to get rakudo-j on its feet again after the return changes :)

[13:35] <psch> jnthn++

[13:35] <psch> it's probably too much to hope that magically fixed the precomp/install bug too, isn't it? :)

[13:38] <jnthn> 'fraid so

[13:39] <jnthn> Though it lets me get rid of a bit of Rakudo-specific Java code, and it should give a bit of a speedup

[13:39] <psch> well, that's great too

[13:41] <jnthn> BrokenRobot: Are you the person doing The Release this weekend?

[13:41] <BrokenRobot> jnthn: yup.

[13:42] <jnthn> BrokenRobot: OK. I'm wondering about merging the return branch. I think I know how to do a MoarVM patch that, for now, disables the inlinings that cause that return bug. I'm less sure how to do such a patch for the pre-merge state.

[13:42] <jnthn> (The for ^158 {...} one)

[13:43] <jnthn> I don't think I've time/energy to do a real fix for it this side of the release :)

[13:44] <BrokenRobot> bisect: sub foo { return 42 }; for ^158 { foo }

[13:44] <bisectable> BrokenRobot: (2016-06-01) https://github.com/rakudo/rakudo/commit/7250543

[13:45] <BrokenRobot> Wouldn't just avoiding the above commit avoid the bug too?

[13:46] <timotimo> but that's the whole point of the branch :)

[13:46] <psch> fwiw, i'd be ok with hiding

[13:47] <BrokenRobot> timotimo: to fix (or "hide") the bug, right?

[13:48] <dalek> rakudo/return-without-lexotic: f7577ee | jnthn++ | / (5 files):

[13:48] <dalek> rakudo/return-without-lexotic: Remove now-unused p6routinereturn op.

[13:48] <dalek> rakudo/return-without-lexotic: review: https://github.com/rakudo/rakudo/commit/f7577ee713

[13:48] <timotimo> the branch is there for making return much more efficient. without that commit, we're going to get a gigantic part of the inefficiency back

[13:48] <BrokenRobot> Oh, then sure, let's merge :D

[13:48] <AlexDaniel> :D

[13:50] <jnthn> Yeah, the merge and (hopeful, testing now) workaround would let us keep most of the performance win without having the bug

[13:54] <BrokenRobot> Went to teach cmp-ok to take custom ops as Str... found a bug in custom ops exported from a module

[13:54] <BrokenRobot> (comprehensive tests)++

[13:55] <[Coke]> email through RT can end up in a manual spam filter.

[13:56] <[Coke]> if it's been weeks, a followup to the bugadmins saying "any progress on this" is reasonable.

[13:57] <BrokenRobot> Am I doing something wrong? &[<=»] fails if the op is imported from a module, but works if it's defined inside the same file: https://gist.github.com/zoffixznet/4cf75e2219a80430e58da6f0f5302f0c

[13:59] <BrokenRobot> Fails with &CALLERS::("infix:<\<=»>"); too

[14:03] <b2gills> m: say sub infix:«<=\»» ($a,$b){}; say &::('infix:<\<=»>')

[14:03] <camelia> rakudo-moar 70c19d: OUTPUT«sub infix:<\<=»> ($a, $b) { #`(Sub+{Precedence}|46884752) ... }␤sub infix:<\<=»> ($a, $b) { #`(Sub+{Precedence}|58466328) ... }␤»

[14:05] <BrokenRobot> For some reason even if I call it "op" and the &CALLERS::("infix:<op>") fails. Even though I'm pretty sure I tested that last night on my home box :/

[14:06] <b2gills> m: say sub infix:<\<=»> ($a,$b){}; say { &CALLERS::('infix:<\<=»>') }()

[14:06] <camelia> rakudo-moar 70c19d: OUTPUT«sub infix:<\<=»> ($a, $b) { #`(Sub+{Precedence}|39421936) ... }␤sub infix:<\<=»> ($a, $b) { #`(Sub+{Precedence}|51003512) ... }␤»

[14:07] <BrokenRobot> m: package Foo {sub infix:<op>  is export { $^a < $^b }}; import Foo; say &CALLERS::("infix:<op>")

[14:07] <camelia> rakudo-moar 70c19d: OUTPUT«No such symbol '&::CALLERS::infix:<op>'␤  in block <unit> at <tmp> line 1␤␤Actually thrown at:␤  in block <unit> at <tmp> line 1␤␤»

[14:07] <psch> m: package Foo {our sub infix:<op>  { $^a < $^b }}; import Foo; say Foo::.keys

[14:07] <camelia> rakudo-moar 70c19d: OUTPUT«(&infix:<op>)␤»

[14:07] <b2gills> m: package Foo {sub infix:<op>  is export { $^a < $^b }}; import Foo; say { &CALLERS::("infix:<op>") }()

[14:07] <camelia> rakudo-moar 70c19d: OUTPUT«sub infix:<op> ($a, $b) { #`(Sub+{Precedence}|56250272) ... }␤»

[14:08] <b2gills> You need at least one call level to use CALLERS

[14:08] <psch> m: package Foo {our sub infix:<\<=»>  { $^a < $^b }}; import Foo; say Foo::.keys

[14:08] <camelia> rakudo-moar 70c19d: OUTPUT«(&infix:<\<=»>)␤»

[14:08] <BrokenRobot> Ah. Thanks

[14:08] <psch> m: package Foo {our sub infix:<\<=»>  { $^a < $^b }}; import Foo; say Foo::.keys; say Foo::<&infix:<\<=»>>

[14:08] <camelia> rakudo-moar 70c19d: OUTPUT«(&infix:<\<=»>)␤(Any)␤»

[14:09] <psch> ah, but the import doesn't work for the &[] form..?

[14:09] <psch> i think that's another notch in "we need to make canonicalize_pair do something during runtime lookups"

[14:10] <BrokenRobot> psch: it works, but not with a weird op name

[14:10] <BrokenRobot> m: package Foo {sub infix:["op"] is export { $^a < $^b }}; import Foo; say &[op]

[14:10] <camelia> rakudo-moar 70c19d: OUTPUT«sub infix:<op> ($a, $b) { #`(Sub+{Precedence}|67198896) ... }␤»

[14:10] <BrokenRobot> m: package Foo {sub infix:["<=»"] is export { $^a < $^b }}; import Foo; say &[<=»]

[14:10] <camelia> rakudo-moar 70c19d: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Unable to parse expression in infix noun; couldn't find final ']' ␤at <tmp>:1␤------> ort { $^a < $^b }}; import Foo; say &[<=⏏»]␤»

[14:13] <jnthn> BrokenRobot: Confirm that my workaround fixes the loop/return thing

[14:13] <BrokenRobot> \o/

[14:13] <jnthn> So, we can not have that bug for release and keep the other return improvements :)

[14:14] <BrokenRobot> jnthn++

[14:14] <BrokenRobot> m: m: package Foo {sub infix:«<=\»»  is export { $^a < $^b }}; import Foo; say { &CALLERS::("infix:«<=\»»") }()

[14:14] <camelia> rakudo-moar 70c19d: OUTPUT«No such symbol '&::CALLERS::infix:«<=»»'␤  in block <unit> at <tmp> line 1␤␤Actually thrown at:␤  in block <unit> at <tmp> line 1␤␤»

[14:14] <BrokenRobot> ^ seems the issue is that op. Doesn't work with CALLERS either

[14:15] <BrokenRobot> b2gills: any ideas?

[14:16] <b2gills> m: say sub infix:«<=\»»  is export { $^a < $^b }

[14:17] <camelia> rakudo-moar 70c19d: OUTPUT«sub infix:<\<=»> ($a, $b) { #`(Sub+{Precedence}|50857776) ... }␤»

[14:17] <BrokenRobot> m: package Foo {sub infix:<\<=»> is export { $^a < $^b }}; import Foo; say { &CALLERS::("infix:<\\<=»>") }()

[14:17] <camelia> rakudo-moar 70c19d: OUTPUT«sub infix:<\<=»> ($a, $b) { #`(Sub+{Precedence}|46764128) ... }␤»

[14:17] <BrokenRobot> Awesome, b2gills++

[14:20] <psch> BrokenRobot: yeah, i figured that a not-easily-canonicalized pair is what makes stuff weird there

[14:33] <BrokenRobot> does rakudo's make test skip 02-rakudo on purpose?

[14:33] <dalek> Heuristic branch merge: pushed 19 commits to nqp by jnthn

[14:33] <BrokenRobot> t/02-rakudo tests that is

[14:39] <dalek> rakudo/nom: 7ee6578 | jnthn++ | src/ (5 files):

[14:39] <dalek> rakudo/nom: Switch Rakudo away from using lexotic for return.

[14:39] <dalek> rakudo/nom: review: https://github.com/rakudo/rakudo/commit/7ee6578ce9

[14:39] <dalek> rakudo/nom: fcd0093 | jnthn++ | src/core/Exception.pm:

[14:39] <dalek> rakudo/nom: Update Exception.fail after return changes.

[14:39] <jnthn> Here goes dalek...

[14:39] <jnthn> :P

[14:39] <jnthn> Only 11 commits. Can't possibly be a merge!

[14:45] * lizmat builds and spectest and keeps fingers crossed

[14:46] <dalek> roast: a9597e6 | jnthn++ | integration/weird-errors.t:

[14:46] <dalek> roast: Untodo inline/return test.

[14:46] <dalek> roast:

[14:46] <dalek> roast: MoarVM has a workaround for it, and untodoing this will keep us honest

[14:46] <dalek> roast: in doing a real fix before removing the workaround there. :-)

[14:46] <dalek> roast: review: https://github.com/perl6/roast/commit/a9597e6781

[14:46] <b2gills> That last pull+rebuild took just over 4 minutes, it usually takes less than three ( rebuilding again to see if it goes back down )

[14:48] <lizmat> jnthn: I'm seeing some Inline::Perl5 breakage  :-(

[14:49] <b2gills> ... and back down to 2m9s

[14:49] <jnthn> Funny, I had my fastest Rakudo build on my Windows box just now...

[14:50] <jnthn> 96.25s for Rakudo itself

[14:50] <b2gills> I use ｢time rakudobrew build moar｣ so it includes git pull

[14:51] <jnthn> ah, fair enough

[14:51] <jnthn> lizmat: Any details for me?

[14:51] <lizmat> in a mo, when the spectest is finished  :-)

[14:52] <jnthn> k

[14:52] <b2gills> .oO( I assume that means mo-ment not mo-nth )

[14:53] <jnthn> If anything, that merge might make them a tad faster :)

[14:53] <lizmat> https://gist.github.com/lizmat/3f447654c9150e823f2057d9b3bcc9b9

[14:53] <lizmat> jnthn: ^^^

[14:54] <b2gills> actually I think my build timings haven't been below 2m30s until just now

[14:54] * lizmat looks forward to the next test-t, [Tux]  ??

[14:55] * lizmat nukes install to make sure Inline::Perl5 issues aren't transitionary

[14:56] <jnthn> Hmmm

[15:05] <mst> I know it wasn't, but I really wanted that to be a Banks reference

[15:06] <BrokenRobot> m: "<><>"..subst(/<?before <[<>]>>/, '\\', :g).say;

[15:06] <camelia> rakudo-moar 519e76: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Undeclared routine:␤    subst used at line 1. Did you mean 'substr'?␤␤»

[15:06] <BrokenRobot> m: "<><>".subst(/<?before <[<>]>>/, '\\', :g).say;

[15:06] <camelia> rakudo-moar 519e76: OUTPUT«\<\>\<\>␤»

[15:07] <BrokenRobot> (never mind; found my bug while trying to ask wtf I had a difference :P)

[15:10] <jnthn> lizmat: Well, I can reproduce it. I've not much idea what it means or what can be done about it.

[15:13] <lizmat> jnthn : I guess nine will need to shine his light on it  :-)

[15:13] <jnthn> It's nothing to do with spesh, at least :)

[15:16] <jnthn> ohhh...I see it

[15:16] <jnthn> It's doing a CONTROL and assuming that every control exception is a warning

[15:16] <jnthn> And return exceptions are now control exceptions too

[15:17] <geekosaur> again? :p

[15:17] <jnthn> lol!

[15:17] <jnthn> Maybe I should implement them in terms of hardware traps? :P

[15:18] <BrokenRobot> :)

[15:18] <geekosaur> thatd be a step backwards (to, oh, the 1940s...)

[15:19] <geekosaur> actually don't even need to go that far back, considering the history of algol-60

[15:20] <jnthn> OK, got a clean Inline::Perl5.

[15:20] <jnthn> And, good news, the patch is fully backward-compatible

[15:20] <BrokenRobot> \o/

[15:21] <jnthn> aww, no commit bit :)

[15:21] <lizmat> jnthn: I could merge a PR

[15:23] <jnthn> PR submat

[15:24] <jnthn> nine++ # Inline::Perl5 was easy to patch

[15:25] <lizmat> merged

[15:26] <lizmat> Inline::Perl5 now installed ok

[15:26] <jnthn> phew :)

[15:26] <jnthn> Any improvement for you in spectest time? :)

[15:27] <nine> Thanks jnthn++, lizmat++!

[15:27] <nine> That CONTROL handler is actually for Inline::Perl6

[15:27] <jnthn> nine: np, figured I'd see if I could quickly figure it out rather than you having to :)

[15:27] <lizmat> jnthn: will know in a min

[15:28] <jnthn> k

[15:28] <nine> So everyone's looking forward to test-t now?

[15:29] <jnthn> Will be interesting to see how much the next/return changes help

[15:30] <jnthn> [Tux] seemed to think the next ones more than the return ones

[15:32] <lizmat> Files=1109, Tests=52351, 272 wallclock secs (15.50 usr  4.18 sys + 1653.50 cusr 133.22 csys = 1806.40 CPU)

[15:33] <lizmat> this seem much faster, but then again, roast is not your typical Perl 6 code

[15:33] <lizmat> afk&

[15:33] <jnthn> Well, it's probably a speedup for the compiler itself too

[15:34] <BrokenRobot> m: say 272/60

[15:34] <camelia> rakudo-moar 519e76: OUTPUT«4.533333␤»

[15:34] <jnthn> Of course I don't know what it was before so... ;)

[15:34] <lizmat> jnthn: yes, allomorphs e.g.

[15:34] <BrokenRobot> I've been waiting for mine to complete for 14 minutes already :) still on S12

[15:34] <BrokenRobot> 2-core 32-bit box :(

[15:35] <lizmat> the CPU and wallclock really depend on what I'm doing at the same time, and on the temperature of my notebook

[15:35] <lizmat> I've seen faster, I've also seen much slower

[15:35] <jnthn> Well, you're in Florida, so I assume it's hot :P

[15:35] <lizmat> yup, 33 outside

[15:35] <jnthn> eww

[15:36] <jnthn> Prague is about 20 today. Perfect. :)

[15:36] <lizmat> jnthn: maybe some entries about this in docs/ChangeLog are in order  :-)

[15:36] <lizmat> really afk&

[15:40] <dalek> rakudo/nom: 5ca43c2 | jnthn++ | docs/ChangeLog:

[15:40] <dalek> rakudo/nom: Note return/next improvements in ChangeLog.

[15:40] <dalek> rakudo/nom: review: https://github.com/rakudo/rakudo/commit/5ca43c26d2

[15:40] <jnthn> lizmat++ # reminding me to do that :)

[15:41] <jnthn> OK, enough for now :) Time to rest a bit, then make some cheese curry :)

[15:45] * mst likes microwaving curries then melting 250g of cheddar into them

[15:49] <[Coke]> I thought the US disabled all C temperature measurements on native soil.

[15:50] <[Coke]> (I actually have my car set to report in C so I have to do the conversions on the regular)

[15:51] <[Coke]> it was 30c in upstate new york last night.

[15:52] <perlpilot> looks like the lows/highs will be around 22/32 C in Orlando next week.

[15:54] <jdv79> [Coke]: where?  the bank time/temp signs around here alternate C and F - at least most i think.

[15:55] <BrokenRobot> PR to support custom ops via Str params in cmp-ok: https://github.com/rakudo/rakudo/pull/788

[15:56] <psch> BrokenRobot: i still think there's a lot of bandaiding that could be fixed in CORE

[15:56] * geekosaur has not seen a bank time/temp sign in years...

[15:56] <psch> BrokenRobot: note that i don't mean to say you have to do that... :)

[15:58] <BrokenRobot> Sure and &[<=»] doesn't work. When that's fixed the stuff in this PR can be amended (the $matcher code fixed and broken tests uncommented)

[15:58] <BrokenRobot> And I'd do that, but I don't know how :P

[15:59] <psch> BrokenRobot: well, Perl6::World.canonicalize_pair is one spot that needs a looks

[15:59] <psch> because i think we need a better way to store the op symbols

[15:59] <psch> as in, only &[<] and &[>] get stored in the symbol table with french quotes

[16:01] <BrokenRobot> Why do they need French quotes at all?

[16:02] <psch> because &infix:<>> and &infix:<<> can't parse

[16:02] <psch> the first is TTIAR, the second is missing delimiter

[16:02] <psch> ..no, the first parses, but doesn't DWYM

[16:03] <BrokenRobot> And @infix:<<=> works fine?

[16:03] <psch> m: say &infix:<<=>

[16:03] <camelia> rakudo-moar 5ca43c: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Unable to parse expression in shell-quote words; couldn't find final '>>' ␤at <tmp>:1␤------> say &infix:<<=>⏏<EOL>␤    expecting any of:␤        colon pair␤        shell-quote words␤»

[16:03] <psch> s/only/at least/ :)

[16:03] <BrokenRobot> Right, it needs some sorta escape, so why not have the same sorta escape for < and > too?

[16:03] <BrokenRobot> And not bother with French quotes

[16:04] <psch> well, as you found out, look-up with escapes also doesn't work right currently

[16:04] <psch> at least over a module border

[16:04] <BrokenRobot> This is actually the reason for one of the &CALLERS in my PR, the escapes don't work with < and >

[16:04] <BrokenRobot> They work through &CALLERS but not &[]

[16:05] <BrokenRobot> They == escapes

[16:07] * BrokenRobot greps for canonicalize_pair

[16:07] <BrokenRobot> That looks scary enough for me to not need to have an opinion on how it's implemented :P

[16:08] <psch> fwiw, i think storing in the &infix:[' '] form would be best

[16:08] <psch> but then we also need a way to teach ::() to canonicalize to that

[16:08] <psch> ...i'm not sure if that should be generalized to other foofix

[16:09] <psch> and, well, in the end its still just shifting to ' as broken in infixes :|

[16:33] <[Coke]> jdv79: in capdist NY, all F

[16:52] <dalek> nqp: a66ceb4 | (Steve Mynott)++ | docs/bootstrapping.pod:

[16:52] <dalek> nqp: attempt to update stage0 bootstrap directions

[16:52] <dalek> nqp: review: https://github.com/perl6/nqp/commit/a66ceb4d8b

[16:52] <dalek> nqp: 720cf19 | (Steve Mynott)++ | docs/bootstrapping.pod:

[16:52] <dalek> nqp: jnthn++ feedback and minor tweaks

[16:52] <dalek> nqp: review: https://github.com/perl6/nqp/commit/720cf19c22

[16:52] <dalek> nqp: d1a950f | jnthn++ | docs/bootstrapping.pod:

[16:52] <dalek> nqp: Merge pull request #291 from stmuk/master

[16:52] <dalek> nqp:

[16:52] <dalek> nqp: attempt to update stage0 bootstrap directions

[16:52] <dalek> nqp: review: https://github.com/perl6/nqp/commit/d1a950f8ce

[16:54] <BrokenRobot> Any hints for what exception to throw if one of the args in a given possibly-lazy-or-infinite list isn't the right type?

[16:55] <BrokenRobot> Like, I wanna throw when that arg is reached

[16:55] <stmuk> I suppose the js backend doesn't bootstrap itself?

[16:58] <BrokenRobot> m: X::TypeCheck.new(:operation("processing a divisor in polymod()"), :got(2.5), :expected(Int)).throw # I'll go with that

[16:58] <camelia> rakudo-moar 5ca43c: OUTPUT«Type check failed in processing a divisor in polymod(); expected Int but got Rat (2.5)␤  in block <unit> at <tmp> line 1␤␤»

[17:17] <[Tux]> This is Rakudo version 2016.05-168-g5ca43c2 built on MoarVM version 2016.05-37-ga126e0f

[17:17] <[Tux]> test            15.801

[17:17] <[Tux]> test-t           9.400

[17:17] <[Tux]> csv-parser      22.201

[17:19] <BrokenRobot> nine: so the .rev-dep stuff... you said it was meant to be after the release. Is it OK to include it or do I need to do some sort of git stuff to exclude it? http://irclog.perlgeek.de/perl6-dev/2016-06-16#i_12679648

[17:19] <[Tux]> second run 9.410

[17:35] <nine> BrokenRobot: I think it's ok to include it. I was aiming at after the release just to be safe. It passes all tests I could think of, should in theory be harmless and noone has complained since it went in.

[18:25] <jnthn> [Tux]: So, another .3s off? Not bad :)

[18:54] <RabidGravy> I actually assumed that would be a high (low?) water mark and the slack would slowly get taken up by de-optimisations in other areas. I'm glad I was wrong

[19:54] <Hotkeys> m: say "a̩".uninames

[19:54] <camelia> rakudo-moar 5ca43c: OUTPUT«(LATIN SMALL LETTER A COMBINING VERTICAL LINE BELOW)␤»

[19:54] <Hotkeys> oops wrong place

[20:13] <BrokenRobot> So it's 33 in Orlando, but it'll be 37-39 here in Canuckistan this weekend :) Go ahead, make a Canadians live in igloos joke :p

[20:50] <mst> I thought you lived in buildings made entirely out of apologies

[20:51] <Zoffix> :)

[20:52] <hoelzro> 37?!

[21:15] <geekosaur> we had a big cold front go through yesterday. naturally it's like 15 degrees (F) warmer today... wtf

[21:16] <geekosaur> (no, it didn't go back through overnight as a warm front. we actually are supposed to see temperatures drop as the center of the high pressure area arrives, but the outer parts are warm. "yay")

[21:17] <jnthn> We've escaped anything especially hot here so far this summer.

[21:17] <jnthn> Certainly a cooler summer than last year...so far.

[21:17] <jnthn> A load of rain though. The pub downstairs hasn't even bothered to set up its outside terrace.

[21:29] <Zoffix> m: say 2 mod 1.5

[21:29] <camelia> rakudo-moar 5ca43c: OUTPUT«Cannot resolve caller infix:<div>(Int, Rat); none of these signatures match:␤    (Int:D \a, Int:D \b)␤    (int $a, int $b --> int)␤  in block <unit> at <tmp> line 1␤␤»

[21:29] <Zoffix> LTA IMO

[21:30] <jnthn> How so?

[21:30] <jnthn> Oh...it mentions div in the error

[21:30] <jnthn> wtf

[21:30] <Zoffix> Yeah

[21:31] <jnthn> Yeah, that can pay a visit to the RT queue imo :)

[21:37] <Zoffix> Is there a specific timezone for "releasing on 3rd Saturday"? 'cause it's 18th somewhere already :)

[21:38] <Zoffix> Wondering if I should start the process now or wait until tomorrow

[21:38] <Zoffix> (tomorrow = after I wake up in EDT :P)

[21:43] <jnthn> Zoffix: Whatever's most comfortable for you.

[21:43] <jnthn> It's not strict at all.

[21:44] <Zoffix> cool

[22:17] <Zoffix> Oh, I'd need to wait for MoarVM release anyway, right?

[22:17] <Zoffix> Or should I do that too

[22:22] <jnthn> Ohhhh

[22:22] <jnthn> No, I'm meant to do that :)

[22:22] <jnthn> I can do it tomorrow :)

[22:23] <jnthn> And I'm in Europe, so... :)

[22:23] <Zoffix> K :D

[22:23] <jnthn> What's HEAD now will be The Releaes modulo ChangeLog updates.

[22:23] <jnthn> *The Release

[22:24] <jnthn> If I can't spell release, I probably shouldn't do one :D

[22:24] <Zoffix> hehe :D

[22:24] <jnthn> Pardubický porter FTW, I guess :)

[22:39] <Zoffix> The LTA mod error stuff seems to actually be due to our not implementing mod/div according to the spec. They're supposed to work on all numerics: <Zoffix> m: say 2 mod 1.5

[22:39] <Zoffix> <camelia> rakudo-moar 5ca43c: OUTPUT«Cannot resolve caller infix:<div>(Int, Rat); none of these signatures match:␤    (Int:D \a, Int:D \b)␤    (int $a, int $b --> int)␤  in block <unit> at <tmp> line 1␤␤»

[22:39] <Zoffix> Oops

[22:40] <Zoffix> The LTA mod error stuff seems to actually be due to our not implementing mod/div according to the spec. They're supposed to work on all numerics:  https://rt.perl.org/Ticket/Display.html?id=128428

[23:46] <TimToady> Zoffix: div and mod are spec'd to only work on numerics of identical type

[23:46] <TimToady> 2 and 1.5 are of different types

[23:46] <TimToady> S03 sez "Not coercive, so fails on differing types."

[23:48] <Zoffix> Right, bad example in the ticket, but only Int Int stuff is implemented, not numerics

[23:48] <Zoffix> m: &infix:<div>.candidates.say; &infix:<mod>.candidates.say

[23:48] <camelia> rakudo-moar 5ca43c: OUTPUT«(sub infix:<div> (Int:D \a, Int:D \b) { #`(Sub|58335552) ... } sub infix:<div> (int $a, int $b --> int) { #`(Sub+{Callable[int]}|58335400) ... })␤(sub infix:<mod> (Real $a, Real $b) { #`(Sub|61141920) ... })␤»

[23:48] <Zoffix> And mod uses div

[23:49] <Zoffix> m: say 2.5 mod 2.5

[23:49] <camelia> rakudo-moar 5ca43c: OUTPUT«Cannot resolve caller infix:<div>(Rat, Rat); none of these signatures match:␤    (Int:D \a, Int:D \b)␤    (int $a, int $b --> int)␤  in block <unit> at <tmp> line 1␤␤»