Zoffix t/spec/S32-io/IO-Socket-Async.t wobbly :( gist.github.com/zoffixznet/eac1da1...30211d14cc 01:33
(worked fine when I ran it by itself)
MasterDuke i seem to remember getting that a bunch when i 'make spectest' 01:39
Zoffix m: use Test; cmp-ok 2, '<', 5
camelia rakudo-moar 2126ed: OUTPUT«not ok 1 - ␤␤# Failed test at <tmp> line 1␤# Could not use '<' as a comparator␤»
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…»
Zoffix PR to fix both of the above: github.com/rakudo/rakudo/pull/786
timotimo you are *mean* :)
why am i not in bed yet
Zoffix m: say 100 ≅ -100 02:16
camelia rakudo-moar 2126ed: OUTPUT«True␤»
Zoffix RT: rt.perl.org/Ticket/Display.html?id=128421
Fix: github.com/rakudo/rakudo/pull/787
Tests: github.com/perl6/roast/pull/128
dalek kudo/nom: 102b0ea | (Zoffix Znet)++ | / (2 files):
Fix cmp-ok

  * Make it possible to use '<' and '>' (strings) as comparators.
  * Avoid EVAL to prevent exploitable code ( rt.perl.org/Ticket/Display.html?id=128283 )
Note that we explicitly don't support user-defined operators passed as comparators
  *as strings* and we can't use CALLER:: (see irclog.perlgeek.de/perl6-dev/2016-0...12678792).
Those are to be used with &[op] notation.		 02:47
kudo/nom: 21f0be1 | lizmat++ | / (2 files):
Merge pull request #786 from zoffixznet/fix-cmp-ok

Fix cmp-ok ee915c3 | (Zoffix Znet)++ | src/core/Numeric.pm: Fix RT#128421
Fix ≅ incorrectly handling negative numbers, e.g. producing True for 100 ≅ -100
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128421
dalek kudo/nom: 70c19dd | lizmat++ | src/core/Numeric.pm:
Merge pull request #787 from zoffixznet/fix-approx-op

Fix RT#128421
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128421
Zoffix Is there a point in throws-like taking a Str at all? 03:37
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
like "undefined symbols"
Zoffix Like what symbols? 03:39
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␤»
Zoffix m: use Test; eval-dies-ok q[my $joffrey = "nasty"; die "bye bye Ned" if $joffrey ~~ /dfsadsadsadasnasty/], "Ned Stark dies";
camelia rakudo-moar 70c19d: OUTPUT«not ok 1 - Ned Stark dies␤␤# Failed test 'Ned Stark dies'␤# at <tmp> line 1␤»
Zoffix why is this working :/
Oh 03:41
I guess I should say, yeah, that's working, but is entirely useless.
timotimo, what sort of symbols? None of the symbols from where the test is being run would be defined. 03:42
timotimo um 03:43
like '$joffrey = "nasty"'
you want that to throw an "undefined symbol" error
don't forget we have a language test suite as the biggest user of the test library
Zoffix Thanks 03:45
Well, sorta.
The stuff in roast is testing core features that are available in the context of the code EVALed. 03:46
timotimo right 03:47
Zoffix [21:41:14] <timotimo> why am i not in bed yet 03:49
[23:50:15] <Zoffix> [21:41:14] <timotimo> why am i not in bed yet 03:50
:)
timotimo yeah, can't sleep :(
Zoffix ditto
10 to midnight here
timotimo right now i'm looking for a mini usb cable
it's ten to six here
jdv79 its ten of tomorrow round these parts 03:51
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: rt.perl.org/rt3//Public/Bug/Displa...?id=128419
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) ... }␤»
Zoffix b2gills, you should read RT tickets more often :) there was a lot of effort to figure that out: rt.perl.org/Ticket/Display.html?id=128283 04:06
b2gills++ 04:07
I'll send a fix to cmp-ok tomorrow or in a few days 04:10
There's a shitzillion roast failures with RT#128419 fix: gist.github.com/zoffixznet/0ca7276...39dff3b05b 04:16
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128419
Zoffix Before I expend time fixing them, it's fine to just convert all of them to throws-like { EVAL '...' }, right? 04:17
[Tux] This is Rakudo version 2016.05-156-g70c19dd built on MoarVM version 2016.05-18-g1339332 06:42
test 17.352
test-t 9.743
csv-parser 21.946
patrickz www.ugexe.com/when-open-source-doesnt-work/ 07:18
I guess someone should give ugexe a commit bit to rakudo. 07:19
stmuk I think he just has to sign a contribution agreement? 07:31
or chase people over PRs :) 07:32
masak I... don't understand the message of that post. 07:42
is it a comment on something that happened recently that I missed? 07:43
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 vanheusden.com/misc/blog/2016-05-1...mpared.php 08:01
nine masak: I can pretty much guess what it's about: PR 729 08:04
flok420 the perl script generated is vps001.vanheusden.com/~folkert/test.pl (perl 6 version, the 5 version can be generated with the scripts on the site mentioned)
nine masak: which is all the more surprising since it has been waiting for ugexe to fix a backwards compatibility issue.
masak: I'd be very happe to see it merged once it doesn't break installed modules for everyone. 08:05
psch flok420: the 'Perl 6' link seem to link to python code? 08:11
...actually, everything links to python code? 08:12
oh, now i get it 08:13
psch is still waiting on the coffee
nine If only people would at least try to talk first before storming off and leaving a rant on a blog :/
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:17
or, well, after installing the distribution if you want to go that far vOv 08:18
flok420 psch yeah those python scripts generate e.g. perl or cobol or javascript etc code from a brainfuck program. 08:37
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
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:39
not to mention probably terribly annoying to write :P 08:40
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:42
so, the general slowness is probably "iteration could be faster" and "invocation could have less overhead", which both are well known 08:43
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
as in, the json we generate usually comes with some HTML around, which probably won't work out with 4.9k loc :)
jnthn It's more about how deep the call tree goes and how varied it is than the number of lines of code 08:46
psch well, the file in question declares 43 subs, and calls at least a few nested vOv 08:47
jnthn Worth a try... :)
fwiw, I've been sent a generated output from that to look at also 08:48
psch ah, alright then
i'll do some more waking up and then back at the nested CU thingy...
jnthn :) 08:50
jnthn will continue trying to fix return stuff on JVM this afternoon :)
psch although i really can't shake the feeling that we're just somehow messing up in the cuid_to_qbid mapping... 08:55
masak nine: huh. sounds like a misunderstanding, or unintended deadlocking, or something. 09:41
nine yep 09:51
which could have been cleared up by simply asking
Zoffix Turns out "* ugexe (ugexe@p6.nu) has left ("pointless")" was weird... 10:24
So there are now two raging blog post about nine and precompilation over a few bugs? 😂 10:37
No one's rage-posting about .hyper being broken! Priorities! 😂
Are we doing R* release for 2016.06.06? Seems there were many speed improvements since 04 10:47
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:49
Woodi .o(*Patience* is a virtue) 10:53
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
Looks like just a very strange way to vent frustration.
Hell, I have 56 still-open PRs some of them going back years: github.com/search?utf8=✓&q=is%...zoffixznet 10:56
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:57
Zoffix Waaaait a minute. A ton of them are to masak's repos! 10:58
nine You should clearly rage quit working on masak! 11:03
.oO(that somehow sounds very wrong)
psch hrm 11:04
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
'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()()'
nine psch: oh I can sympathize so well
psch which seems somewhat related, even though it's *very* hunchy 11:06
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
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:10
nine those were my thoughts exactly :) 11:13
Of course, it's still possible that it's not the right solution after all :/
psch yeah... 11:16
i think i'll have to figure out why we don't generate a strictly ascending list of qb_* methods
because, well, that's kind of a hint, right
if it is because we somehow skip it but shouldn't, it means that the cuid => qbid mapping gets wonky 11:17
...although i'm not sure yet how to figure out if we wrongfully don't gen it /o\
nine What makes you think that they should be strictly ascending?
psch well, they're not sorted, but all number from 0 to num-methods - 1 exist 11:18
sooo i'm probably again wrongly saying "strictly ascending" :)
and they don't all exist we break during initializeCompunit in CompUnit.java 11:19
because each CU gets its lexical values set during init 11:20
*and *if* they
[Coke] rakudo.org certs are tripping up chrome. 12:24
"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.
"
oh, and actually the front page is dead.
oh. https doesn't work, http does. (I have https everywhere enabled) 12:25
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 "google.com" from location bar, delete the "google" part and try to visit the site via HTTPS :P
AlexDaniel but he was right! What's your reasoning for not having https set up? ;) 12:28
BrokenRobot AlexDaniel: it's very simple: money
nine What? pmicheaud trying to usurp Perl 6!
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!
xkcd.com/1172/
AlexDaniel: the cost of paying me to learn how to use it and use it. But the event happened before letsencrypt existed anyway
AlexDaniel okay 12:30
BrokenRobot Though we probably should have it on rakudo.org :D 12:32
[Coke] I opened an RT, and forwarded the rt to [email@hidden.address] 12:33
(which i assume is pm)
MasterDuke: are you still having trouble commenting on RT tickets? 12:34
(github.com/rakudo/rakudo/pull/775)
MasterDuke__ [Coke]: yeah, my account seems to be messed up 13:01
per AlexDaniel's advice i emailed the admin account (about 3 weeks ago), but haven't heard back 13:02
and when i email perl-bugs-followup it takes a while for my emails to show up 13:04
see #128280 for example
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128280
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
(also that's kind of a #perl6 question i think)
flok420 ah ok. thought it was a bug. 13:08
psch m: say 3 +& 2
camelia rakudo-moar 70c19d: OUTPUT«2␤»
psch m: say 3 & 2
camelia rakudo-moar 70c19d: OUTPUT«all(3, 2)␤»
BrokenRobot flok420: there *is* a bug though. $test will have -1
AlexDaniel m: uint8 $test = 0; $test--; say $test
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␤…»
AlexDaniel m: my uint8 $test = 0; $test--; say $test 13:09
camelia rakudo-moar 70c19d: OUTPUT«-1␤»
AlexDaniel holy…
psch m: my uint8 $t = 0; $test--; $test +&= 255; say $test
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␤»
AlexDaniel bisect: my uint8 $test = 0; $test--; say $test
bisectable AlexDaniel: on both starting points the exit code is 0 and the output is identical as well
psch m: my uint8 $test = 0; $test--; $test +&= 255; say $test
camelia rakudo-moar 70c19d: OUTPUT«-1␤»
BrokenRobot That's been the case since pre-Christmas.
AlexDaniel m: my UInt $test = 0; $test--; say $test
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␤␤»
BrokenRobot digs for the RT detaling a lot of discrepancies
AlexDaniel /o\
psch AlexDaniel: UInt unfortunately doesn't get native fastitude anymore :/
well, "anymore" as in "in contrast to uint" 13:10
flok420 ok thanks guys! 13:11
BrokenRobot Here, I didn't get through all of them tho: rt.perl.org/Ticket/Display.html?id=127409
AlexDaniel flok420: by the way, it is mentioned here: doc.perl6.org/language/5to6-nutshell
flok420 thanks, I'll read it 13:13
AlexDaniel /o\ 13:14
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␤␤»
jnthn m: my Int $test = 1; $test div= 2 13:20
camelia ( no output )
dalek p/return-without-lexotic: 390a1c5 | jnthn++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/ExceptionHandling.java:
Skip compiler stubs as well as thunks.
 13:28
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("<", "\␤»
psch m: sub infix:['<»'] { } 13:31
camelia ( no output )
BrokenRobot Fixed by escpaing the < in <, but I guess we can't make a better error?
psch fwiw, i think $*W.canonicalize_pair needs some deeper thought in general
and, well, ::() needs to go through it too to make things easier 13:32
probably only when we do find a pair in ::(), though
jnthn Yay, seems I managed to get rakudo-j on its feet again after the return changes :) 13:35
psch jnthn++
it's probably too much to hope that magically fixed the precomp/install bug too, isn't it? :)
jnthn 'fraid so 13:38
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
jnthn BrokenRobot: Are you the person doing The Release this weekend? 13:41
BrokenRobot jnthn: yup.
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
(The for ^158 {...} one)
I don't think I've time/energy to do a real fix for it this side of the release :) 13:43
BrokenRobot bisect: sub foo { return 42 }; for ^158 { foo } 13:44
bisectable BrokenRobot: (2016-06-01) github.com/rakudo/rakudo/commit/7250543
BrokenRobot Wouldn't just avoiding the above commit avoid the bug too? 13:45
timotimo but that's the whole point of the branch :) 13:46
psch fwiw, i'd be ok with hiding
BrokenRobot timotimo: to fix (or "hide") the bug, right? 13:47
dalek kudo/return-without-lexotic: f7577ee | jnthn++ | / (5 files):
Remove now-unused p6routinereturn op.
 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
BrokenRobot Oh, then sure, let's merge :D
AlexDaniel :D
jnthn Yeah, the merge and (hopeful, testing now) workaround would let us keep most of the performance win without having the bug 13:50
BrokenRobot Went to teach cmp-ok to take custom ops as Str... found a bug in custom ops exported from a module 13:54
(comprehensive tests)++
[Coke] email through RT can end up in a manual spam filter. 13:55
if it's been weeks, a followup to the bugadmins saying "any progress on this" is reasonable. 13:56
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: gist.github.com/zoffixznet/4cf75e2...f0f5302f0c 13:57
Fails with &CALLERS::("infix:<\<=»>"); too 13:59
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) ... }␤»
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:05
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) ... }␤»
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␤␤»
psch m: package Foo {our sub infix:<op> { $^a < $^b }}; import Foo; say Foo::.keys
camelia rakudo-moar 70c19d: OUTPUT«(&infix:<op>)␤»
b2gills m: package Foo {sub infix:<op> is export { $^a < $^b }}; import Foo; say { &CALLERS::("infix:<op>") }()
camelia rakudo-moar 70c19d: OUTPUT«sub infix:<op> ($a, $b) { #`(Sub+{Precedence}|56250272) ... }␤»
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
camelia rakudo-moar 70c19d: OUTPUT«(&infix:<\<=»>)␤»
BrokenRobot Ah. Thanks
psch m: package Foo {our sub infix:<\<=»> { $^a < $^b }}; import Foo; say Foo::.keys; say Foo::<&infix:<\<=»>>
camelia rakudo-moar 70c19d: OUTPUT«(&infix:<\<=»>)␤(Any)␤»
psch ah, but the import doesn't work for the &[] form..? 14:09
i think that's another notch in "we need to make canonicalize_pair do something during runtime lookups"
BrokenRobot psch: it works, but not with a weird op name 14:10
m: package Foo {sub infix:["op"] is export { $^a < $^b }}; import Foo; say &[op]
camelia rakudo-moar 70c19d: OUTPUT«sub infix:<op> ($a, $b) { #`(Sub+{Precedence}|67198896) ... }␤»
BrokenRobot m: package Foo {sub infix:["<=»"] is export { $^a < $^b }}; import Foo; say &[<=»]
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 &[<=⏏»]␤»
jnthn BrokenRobot: Confirm that my workaround fixes the loop/return thing 14:13
BrokenRobot \o/
jnthn So, we can not have that bug for release and keep the other return improvements :)
BrokenRobot jnthn++ 14:14
m: m: package Foo {sub infix:«<=\»» is export { $^a < $^b }}; import Foo; say { &CALLERS::("infix:«<=\»»") }()
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␤␤»
BrokenRobot ^ seems the issue is that op. Doesn't work with CALLERS either
b2gills: any ideas? 14:15
b2gills m: say sub infix:«<=\»» is export { $^a < $^b } 14:16
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:<\\<=»>") }()
camelia rakudo-moar 70c19d: OUTPUT«sub infix:<\<=»> ($a, $b) { #`(Sub+{Precedence}|46764128) ... }␤»
BrokenRobot Awesome, b2gills++
psch BrokenRobot: yeah, i figured that a not-easily-canonicalized pair is what makes stuff weird there 14:20
BrokenRobot does rakudo's make test skip 02-rakudo on purpose? 14:33
dalek Heuristic branch merge: pushed 19 commits to nqp by jnthn
BrokenRobot t/02-rakudo tests that is
dalek kudo/nom: 7ee6578 | jnthn++ | src/ (5 files):
Switch Rakudo away from using lexotic for return.
 14:39
rakudo/nom: fcd0093 | jnthn++ | src/core/Exception.pm:
rakudo/nom: Update Exception.fail after return changes.
jnthn Here goes dalek...
:P
Only 11 commits. Can't possibly be a merge!
lizmat builds and spectest and keeps fingers crossed 14:45
dalek ast: a9597e6 | jnthn++ | integration/weird-errors.t:
Untodo inline/return test.

MoarVM has a workaround for it, and untodoing this will keep us honest in doing a real fix before removing the workaround there. :-)		 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 )
lizmat jnthn: I'm seeing some Inline::Perl5 breakage :-( 14:48
b2gills ... and back down to 2m9s 14:49
jnthn Funny, I had my fastest Rakudo build on my Windows box just now...
96.25s for Rakudo itself 14:50
b2gills I use ｢time rakudobrew build moar｣ so it includes git pull
jnthn ah, fair enough 14:51
lizmat: Any details for me?
lizmat in a mo, when the spectest is finished :-)
jnthn k 14:52
b2gills
.oO( I assume that means mo-ment not mo-nth )
jnthn If anything, that merge might make them a tad faster :) 14:53
lizmat gist.github.com/lizmat/3f447654c91...d9b3bcc9b9
jnthn: ^^^
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] ??
lizmat nukes install to make sure Inline::Perl5 issues aren't transitionary 14:55
jnthn Hmmm 14:56
mst I know it wasn't, but I really wanted that to be a Banks reference 15:05
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'?␤␤»
BrokenRobot m: "<><>".subst(/<?before <[<>]>>/, '\\', :g).say;
camelia rakudo-moar 519e76: OUTPUT«\<\>\<\>␤»
BrokenRobot (never mind; found my bug while trying to ask wtf I had a difference :P) 15:07
jnthn lizmat: Well, I can reproduce it. I've not much idea what it means or what can be done about it. 15:10
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 :)
ohhh...I see it 15:16
It's doing a CONTROL and assuming that every control exception is a warning
And return exceptions are now control exceptions too
geekosaur again? :p 15:17
jnthn lol!
Maybe I should implement them in terms of hardware traps? :P
BrokenRobot :) 15:18
geekosaur thatd be a step backwards (to, oh, the 1940s...)
actually don't even need to go that far back, considering the history of algol-60 15:19
jnthn OK, got a clean Inline::Perl5. 15:20
And, good news, the patch is fully backward-compatible
BrokenRobot \o/
jnthn aww, no commit bit :) 15:21
lizmat jnthn: I could merge a PR
jnthn PR submat 15:23
nine++ # Inline::Perl5 was easy to patch 15:24
lizmat merged 15:25
Inline::Perl5 now installed ok 15:26
jnthn phew :)
Any improvement for you in spectest time? :)
nine Thanks jnthn++, lizmat++! 15:27
That CONTROL handler is actually for Inline::Perl6
jnthn nine: np, figured I'd see if I could quickly figure it out rather than you having to :)
lizmat jnthn: will know in a min
jnthn k 15:28
nine So everyone's looking forward to test-t now?
jnthn Will be interesting to see how much the next/return changes help 15:29
[Tux] seemed to think the next ones more than the return ones 15:30
lizmat Files=1109, Tests=52351, 272 wallclock secs (15.50 usr 4.18 sys + 1653.50 cusr 133.22 csys = 1806.40 CPU) 15:32
this seem much faster, but then again, roast is not your typical Perl 6 code 15:33
afk&
jnthn Well, it's probably a speedup for the compiler itself too
BrokenRobot m: say 272/60 15:34
camelia rakudo-moar 519e76: OUTPUT«4.533333␤»
jnthn Of course I don't know what it was before so... ;)
lizmat jnthn: yes, allomorphs e.g.
BrokenRobot I've been waiting for mine to complete for 14 minutes already :) still on S12
2-core 32-bit box :(
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
I've seen faster, I've also seen much slower
jnthn Well, you're in Florida, so I assume it's hot :P
lizmat yup, 33 outside
jnthn eww
Prague is about 20 today. Perfect. :) 15:36
lizmat jnthn: maybe some entries about this in docs/ChangeLog are in order :-)
really afk&
dalek kudo/nom: 5ca43c2 | jnthn++ | docs/ChangeLog:
Note return/next improvements in ChangeLog.
 15:40
jnthn lizmat++ # reminding me to do that :)
OK, enough for now :) Time to rest a bit, then make some cheese curry :) 15:41
mst likes microwaving curries then melting 250g of cheddar into them 15:45
[Coke] I thought the US disabled all C temperature measurements on native soil. 15:49
(I actually have my car set to report in C so I have to do the conversions on the regular) 15:50
it was 30c in upstate new york last night. 15:51
perlpilot looks like the lows/highs will be around 22/32 C in Orlando next week. 15:52
jdv79 [Coke]: where? the bank time/temp signs around here alternate C and F - at least most i think. 15:54
BrokenRobot PR to support custom ops via Str params in cmp-ok: github.com/rakudo/rakudo/pull/788 15:55
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...
psch BrokenRobot: note that i don't mean to say you have to do that... :)
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
And I'd do that, but I don't know how :P
psch BrokenRobot: well, Perl6::World.canonicalize_pair is one spot that needs a looks 15:59
because i think we need a better way to store the op symbols
as in, only &[<] and &[>] get stored in the symbol table with french quotes
BrokenRobot Why do they need French quotes at all? 16:01
psch because &infix:<>> and &infix:<<> can't parse 16:02
the first is TTIAR, the second is missing delimiter
..no, the first parses, but doesn't DWYM
BrokenRobot And @infix:<<=> works fine? 16:03
psch m: say &infix:<<=>
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␤»
psch s/only/at least/ :)
BrokenRobot Right, it needs some sorta escape, so why not have the same sorta escape for < and > too?
And not bother with French quotes
psch well, as you found out, look-up with escapes also doesn't work right currently 16:04
at least over a module border
BrokenRobot This is actually the reason for one of the &CALLERS in my PR, the escapes don't work with < and >
They work through &CALLERS but not &[]
They == escapes 16:05
BrokenRobot greps for canonicalize_pair 16:07
That looks scary enough for me to not need to have an opinion on how it's implemented :P
psch fwiw, i think storing in the &infix:[' '] form would be best 16:08
but then we also need a way to teach ::() to canonicalize to that
...i'm not sure if that should be generalized to other foofix
and, well, in the end its still just shifting to ' as broken in infixes :| 16:09
[Coke] jdv79: in capdist NY, all F 16:33
dalek p: a66ceb4 | (Steve Mynott)++ | docs/bootstrapping.pod:
attempt to update stage0 bootstrap directions
 16:52
p: 720cf19 | (Steve Mynott)++ | docs/bootstrapping.pod:
jnthn++ feedback and minor tweaks
p: d1a950f | jnthn++ | docs/bootstrapping.pod:
Merge pull request #291 from stmuk/master

attempt to update stage0 bootstrap directions
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:54
Like, I wanna throw when that arg is reached 16:55
stmuk I suppose the js backend doesn't bootstrap itself?
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␤␤»
[Tux] This is Rakudo version 2016.05-168-g5ca43c2 built on MoarVM version 2016.05-37-ga126e0f 17:17
test 15.801
test-t 9.400
csv-parser 22.201
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? irclog.perlgeek.de/perl6-dev/2016-0...i_12679648 17:19
[Tux] second run 9.410
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. 17:35
jnthn [Tux]: So, another .3s off? Not bad :) 18:25
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 18:54
Hotkeys m: say "a̩".uninames 19:54
camelia rakudo-moar 5ca43c: OUTPUT«(LATIN SMALL LETTER A COMBINING VERTICAL LINE BELOW)␤»
Hotkeys oops wrong place
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:13
mst I thought you lived in buildings made entirely out of apologies 20:50
Zoffix :) 20:51
hoelzro 37?! 20:52
geekosaur we had a big cold front go through yesterday. naturally it's like 15 degrees (F) warmer today... wtf 21:15
(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:16
jnthn We've escaped anything especially hot here so far this summer. 21:17
Certainly a cooler summer than last year...so far.
A load of rain though. The pub downstairs hasn't even bothered to set up its outside terrace.
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␤␤»
Zoffix LTA IMO
jnthn How so? 21:30
Oh...it mentions div in the error
wtf
Zoffix Yeah
jnthn Yeah, that can pay a visit to the RT queue imo :) 21:31
Zoffix Is there a specific timezone for "releasing on 3rd Saturday"? 'cause it's 18th somewhere already :) 21:37
Wondering if I should start the process now or wait until tomorrow 21:38
(tomorrow = after I wake up in EDT :P)
jnthn Zoffix: Whatever's most comfortable for you. 21:43
It's not strict at all.
Zoffix cool 21:44
Oh, I'd need to wait for MoarVM release anyway, right? 22:17
Or should I do that too
jnthn Ohhhh 22:22
No, I'm meant to do that :)
I can do it tomorrow :)
And I'm in Europe, so... :) 22:23
Zoffix K :D
jnthn What's HEAD now will be The Releaes modulo ChangeLog updates.
*The Release
If I can't spell release, I probably shouldn't do one :D 22:24
Zoffix hehe :D
jnthn Pardubický porter FTW, I guess :)
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
<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␤␤»
Oops
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: rt.perl.org/Ticket/Display.html?id=128428 22:40
TimToady Zoffix: div and mod are spec'd to only work on numerics of identical type 23:46
2 and 1.5 are of different types
S03 sez "Not coercive, so fails on differing types."
Zoffix Right, bad example in the ticket, but only Int Int stuff is implemented, not numerics 23:48
m: &infix:<div>.candidates.say; &infix:<mod>.candidates.say
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) ... })␤»
Zoffix And mod uses div
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␤␤»

Powered by Cro and the Raku® Programming Language.

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

Thank you!