sena_kun github.com/perl6/user-experience/issues/40 is very interesting 11:04
lizmat bisectable6: use nqp; dd nqp::elems(nqp::decodelocaltime(nqp::time_i)) 11:42
bisectable6 lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight
lizmat, Output on all releases: gist.github.com/d281278d2a37c386ae...4c7161d2e7
lizmat, Bisecting by exit code (old=2018.08 new=2018.09). Old exit code: 1
lizmat, bisect log: gist.github.com/324305f3e8223c8b32...79a4ae1f52 11:43
lizmat, (2018-09-15) github.com/rakudo/rakudo/commit/8f...b8fff905ae
lizmat, Output on all releases and bisected commits: gist.github.com/7fa9fabd2262fb592c...b6feb7a55a
[Tux] Rakudo v2020.10-63-g08f5d028e (v6.d) on MoarVM 2020.10-31-gb13f6a24c
csv-ip5xs0.815 - 0.843
csv-ip5xs-208.074 - 8.158
csv-parser23.980 - 25.282
csv-test-xs-200.385 - 0.415
test7.640 - 7.868
test-t1.797 - 1.861
test-t --race0.843 - 0.856
test-t-2030.041 - 30.461
test-t-20 --race8.794 - 9.318
 16:33
Geth rakudo: 2f3de2faab | (Elizabeth Mattijsen)++ | src/core.c/operators.pm6
Do not allow infix:<does> on Int or Str

Issue #4015 points out an undesired behaviour of applying does to an Int or Str value. This commit does *not* take away the underlying issue with this, but it does inhibit applying the undesired behaviour and supplies an error message that will hopefully be helpful.		 18:14
linkable6 RAKUDO#4015 [open]: github.com/rakudo/rakudo/issues/4015 `does` on an Int|Str affects other variables holding that Int|Str
MasterDuke . 20:32
tellable6 2020-11-12T23:13:12Z #raku-dev <timotimo> MasterDuke github.com/timo/rakudo-appimage/re...ag/2020.10
MasterDuke nice, thanks 20:34
vrurg MasterDuke: do you know how to handle exceptions in JVM backend? 20:44
MasterDuke java exceptions? or raku exceptions? 20:45
vrurg I mean, nqp code throws with nqp::die in .bindOneParam and instead of it being reported back to the user I get a weird Java exception.
Other code in bindOneParam uses error variable to setup an exception, but I want this to be uniform with moarvm and thus let the metamodel code to be responsible for error reporting. 20:46
vrurg never wrote a single Java line until before yesterday... :) 20:47
MasterDuke hm, i don't think i've done anything with nqp::die in the jvm code. maybe look at the couple other nqp::die's and try to trigger them and see what it looks like? 20:50
vrurg I think I can find out something one way or another. Just hoped to find out sooner than later. :) 20:51
MasterDuke sorry, i've done a little tiny bit with the jvm backend, but not really enough to be helpful to anyone else 20:53
vrurg No problem, of course. After all, it was about the same path I made while entering the NQP world. 20:59
But the mantra I always repeat: Java must die! Never liked it, and never will. :) 21:00
.seen usev6 21:33
tellable6 vrurg, I haven't seen usev6 around, did you mean user6?
vrurg .seen bartolin
tellable6 vrurg, I saw bartolin 2020-11-01T12:15:12Z in #raku-dev: <bartolin> lizmat: maybe you have a quick idea how to fix this? github.com/rakudo/rakudo/issues/3999
Geth rakudo: MasterDuke17++ created pull request #4026:
Gen faster code for some kinds of `when` cases		 21:35
timotimo cool 21:40
i wonder if anybody ever uses a native int or str variable to pass into a `given` 21:41
MasterDuke greppable6: given \$ 21:44
greppable6 MasterDuke, 1721 lines, 353 modules: gist.github.com/af9a31be1a6498bea3...f4347c2080
timotimo oof 21:45
you know, a given (whatever).WHAT { ... } could probably get an optimization too
MasterDuke ugh, really want a -B option for that
timotimo should be doable
MasterDuke ? don't follow 21:46
timotimo to give greppable a way to add -A, -B, -C options somehow
oh you already generate an istype for type values 21:47
MasterDuke yeah and yeah 21:50
arg, i don't see that rebuild link that ugexe pointed out for the failed azure job 21:52
timotimo i'm not sure how to sensibly get the Stringy/Numeric stuff much faster
since we don't know what type we'll get; neither definitely, nor likely 21:53
ugexe MasterDuke: its there now i think
github.com/rakudo/rakudo/pull/4026...1398007348 21:54
(i dont think it was there when i first clicked on it)
MasterDuke oh, i was clicking details from the overview tab, not the checks tabs 21:55
thanks again 21:56
timotimo: like i mention in the commit message, and was chatting about with lizmat a day or two ago, the cost is dominated by the backtrace creation for failed matches 21:57
though of course it would also be good to make successful matches as quick as possible
timotimo yes, i know 21:58
MasterDuke it's ~44% of a profile's exclusive time, next biggest is ~5% 21:59
any ideas for how to make it faster? or just not do it at all?
timotimo if you knew the exact type coming in, you could implement a non-fatalizing version of the method in question and put them in the qast directly 22:00
MasterDuke implement a non-fatalizing `.(Numeric|Stringy)`? 22:02
timotimo yes, but also: must be able to handle classes that have overridden it, and such 22:05
hmm. what if you made it a multi sub with extra checks if the type coming in is exactly what we expect, and otherwise fall back to the regular method again 22:06
MasterDuke but it's the otherwise that's slow. `.Numeric` on an int/num/etc is fast, it's on a str that's slow 22:10
MasterDuke well, it's on a str that won't convert that's slow 22:11
timotimo that case we should be able to make faster 22:15
by reacting directly to "failure to numerify the string"
MasterDuke in the code genned for the when? because the fail is coming from val() 22:16
timotimo well, by moving it to a multi sub we don't have to output so much code from the optimizer 22:18
but yeah, essentially, steal the val implementation i guess
MasterDuke it's not small...github.com/rakudo/rakudo/blob/mast...#L196-L524 22:19
but maybe something can be done here? github.com/rakudo/rakudo/blob/mast...#L216-L222 22:20
timotimo hm, i think that's just a trick to return past subs called from there 22:22
since it's a pointy block it's transparent to return
hm. isn't "fail abc" the same as "return Failure.new(...)"?
maybe that makes stuff just the tiniest bit faster 22:23
doesn't remove the need to build backtraces of course
MasterDuke that's where the profile says the fail comes from at some point. i mean maybe add an option to create a fail that doesn't have a backtrace 22:24
line 276 is where it's called iirc 22:26
timotimo so, like, var("12ohshit", :HARD-FAIL) 23:29
MasterDuke yeah. and a change here github.com/rakudo/rakudo/blob/mast...r.pm6#L803 23:40
timotimo oh what's :val-or-fail 23:46
that could be the right thing for our optimizer 23:48
check if the return value is the same as the value passed
and interpret that as "did not work"

Powered by Cro and the Raku® Programming Language.

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

Thank you!