00:10 frost-lab joined 00:20 leont left 00:21 raku-bridge left, raku-bridge joined 00:41 vrurg left 00:42 vrurg joined 02:36 lucasb left 04:15 notable6 left, nativecallable6 left, unicodable6 left, statisfiable6 left, benchable6 left, evalable6 left, releasable6 left, committable6 left, quotable6 left, bloatable6 left, linkable6 left, bisectable6 left, greppable6 left, shareable6 left, coverable6 left, tellable6 left, squashable6 left, sourceable6 left, bloatable6 joined, bisectable6 joined 04:16 nativecallable6 joined, tellable6 joined, statisfiable6 joined, quotable6 joined 04:17 unicodable6 joined, committable6 joined, coverable6 joined, evalable6 joined, linkable6 joined 04:18 notable6 joined, shareable6 joined, sourceable6 joined, squashable6 joined, benchable6 joined, greppable6 joined, releasable6 joined 05:28 squashable6 left, bisectable6 left, linkable6 left, statisfiable6 left, unicodable6 left, committable6 left, coverable6 left, evalable6 left, greppable6 left, bloatable6 left, nativecallable6 left, notable6 left, tellable6 left, benchable6 left, shareable6 left, releasable6 left, sourceable6 left, quotable6 left 05:29 bloatable6 joined, evalable6 joined, nativecallable6 joined, tellable6 joined, linkable6 joined, squashable6 joined, sourceable6 joined, coverable6 joined 05:30 shareable6 joined, unicodable6 joined, releasable6 joined, committable6 joined 05:31 benchable6 joined, quotable6 joined, statisfiable6 joined, greppable6 joined, notable6 joined, bisectable6 joined 08:06 domidumont joined 08:53 sena_kun joined 09:18 leont joined 10:25 raku-bridge left 10:26 raku-bridge joined, raku-bridge left, raku-bridge joined
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
11:54 Geth joined 12:09 Altai-man joined 12:12 sena_kun left 12:31 raku-bridge left, raku-bridge joined, raku-bridge left, raku-bridge joined 13:17 frost-lab left 15:00 lucasb joined 16:10 sena_kun joined 16:12 Altai-man left
[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
17:29 b2gills joined
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.
linkable6 RAKUDO#4015 [open]: github.com/rakudo/rakudo/issues/4015 `does` on an Int|Str affects other variables holding that Int|Str
18:15 domidumont left 19:24 MasterDuke joined 20:10 Altai-man joined 20:12 sena_kun left
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
20:48 Kaeipi joined, Kaiepi left
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
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
22:10 Altai-man left, sena_kun joined
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
22:35 raku-bridge left, raku-bridge joined, raku-bridge left, raku-bridge joined 23:26 sena_kun left
timotimo so, like, var("12ohshit", :HARD-FAIL) 23:29
23:39 vrurg_ joined
MasterDuke yeah. and a change here github.com/rakudo/rakudo/blob/mast...r.pm6#L803 23:40
23:44 vrurg_ left
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"