Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
00:02 reportable6 left 00:03 reportable6 joined 00:18 tealecloud joined 00:23 tealecloud left 00:56 linkable6 joined 01:00 frost joined 01:42 tealecloud joined 01:48 tealecloud left 04:02 sourceable6 left, bloatable6 left, benchable6 left, squashable6 left, committable6 left, releasable6 left, shareable6 left, quotable6 left, reportable6 left, unicodable6 left, coverable6 left, greppable6 left, linkable6 left, statisfiable6 left, nativecallable6 left 04:03 greppable6 joined 04:04 nativecallable6 joined, linkable6 joined, shareable6 joined, releasable6 joined 04:05 quotable6 joined, statisfiable6 joined, squashable6 joined 04:48 squashable6 left 04:56 evalable6 joined 05:04 benchable6 joined, bloatable6 joined, committable6 joined 05:48 squashable6 joined 06:03 reportable6 joined 06:04 coverable6 joined, unicodable6 joined, sourceable6 joined 06:22 squashable6 left 08:28 tealecloud joined
Nicholas good *, #moarvm 08:45
so next step on new-disp is a blin run (or maybe two - new-disp and master), and then figure out how many failures are regressions on new-disp? 08:46
nine Nicholas: yes 08:58
jnthnwrthngtn moarning o/ 09:10
There's some args flattening bug that seems to afflict a number of the modules on new-disp; I might try and figure that out ahead of the next blin run 09:11
Nicholas \o 09:12
dogbert11 there's also the 'lang-call cannot invoke object of type 'VMNull' belonging to no language' bug which has made a return 09:14
perehaps we can trick nine++ to take a look at that one :) 09:15
perehaps => ENOCOFFEE
lizmat but I understand roast is clean now ? 09:22
dogbert11 lizmat: yes 09:24
lizmat cool
jnthnwrthngtn 1.4% of CPU cycles off CORE.setting compilation by having $*REGALLOC looked up via the QAST compiler instance instead. (Was something I hacked up over the weekend, and left callgrind with it to see what the impact was...) 09:36
Ah, actually 1.4% of IFs, to be prefcise
*precise
09:39 evalable6 left, linkable6 left 09:40 linkable6 joined
lizmat wow 09:41
09:41 evalable6 joined
MasterDuke jnthnwrthngtn: going to do the same thing with $*MAST_FRAME? 09:47
dogbert11 tested a few modules, that I have on my machine, under new-disp. Unsurprisingly most of them passes their tests :) 09:58
two of them have failing tests, i.e. Async::Workers and DOM::Tiny 10:00
meh, Async::Workers should be Test::Async which fails with: [Test::Async] ===SORRY!=== No registered operation handler for 'invokewithcapture' 10:02
the other one runs into 'Non-trivial multi dispatch step NYI for MultiDispatchAmbiguous'
10:09 lizmat_ joined 10:10 TempIRCLogger left, TempIRCLogger joined 10:13 lizmat left 10:16 lizmat_ left, lizmat joined 10:22 sena_kun joined
jnthnwrthngtn The invokewithcapture one is for the module to fix; it depended on an nqp::op that has gone away 10:23
*depends
Probably the best we can do is open an issue 10:24
10:24 squashable6 joined
lizmat vrurg ^^ 10:24
sena_kun jnthnwrthngtn, o/ 10:25
if you're looking at new-disp today, I'll along the $dayjob way check some modules and filter out clear failures
jnthnwrthngtn sena_kun: Do you have an example or two that failed with the flattening issue? I seem to remember that was quite a common failure mode... 10:26
sena_kun Colorizable is the smallest, I believe, the other are HTML::Canvas and PDF::Content or PDF::API6, but I would look at Colorizable first 10:27
nine dogbert11: any other non-standard things for reproducing the VMNull issue? 10:35
Geth MoarVM/new-disp: 11c50b3a0a | (Jonathan Worthington)++ | src/core/args.c
Allow MultiDimArray flattening args also

This happens when we flatten in a fixed dimension array.		 10:38
jnthnwrthngtn That fixes Colorizable and so probably the others with that error too
sena_kun yay
that's awesome
Should I post broken modules I am sure? Maybe I can post 1, then it can be fixed, then 2 and so on, not to make it overwhelming. 10:40
lizmat Q: if I checkout "new-disp" on rakudo, will it do the right thing when running Configure.pl ?
sena_kun s/sure/sure about/
nine lizmat: probably not 10:41
lizmat ah too bad... was thinking of running test-t while writing the weeklt
*weekly
nine You'd need to checkout new-disp in all 3 repos
lizmat and then refer to each in the build? 10:42
dogbert11 nine: 80k nursery and 'while MVM_JIT_DISABLE=1 MVM_SPESH_NODELAY=1 ./rakudo-m -Ilib t/spec/S02-types/range.t; do :; done'
I have MVM_GC_DEBUG=0 (untouched) 10:43
jnthnwrthngtn sena_kun: Well, can post a few at least 10:44
lizmat tried it, didn't work indeed :-)
sena_kun jnthnwrthngtn, try AccessFacade, passes on 08, weird errors on new-disp.
jnthnwrthngtn I can reproduce the DOM::Tiny one
$ zef look AccessFacade 10:45
nine dogbert11: got it in rr right after asking you :)
jnthnwrthngtn ===> Searching for: AccessFacade
sena_kun oops, sorry
jnthnwrthngtn Failed to resolve any candidates. No reason to proceed
sena_kun AccessorFacade
jnthnwrthngtn Ah
I did try :: in the middle also
Yeah, that fails its tests 10:47
dogbert11 nine: yay 10:55
jnthnwrthngtn m: role P { method CALL-ME(|) { say "here" } }; class C { method m() { } does P }; C.m
camelia ( no output )
nine Darn...more than 9 hours of sleep but brane feels like the hand break is put on 10:56
dogbert11 nine: lack of coffee perhaps
nine Nah, just recovering from yesterday's hike 10:57
jnthnwrthngtn m: role P { method CALL-ME(|) { say "here" } }; multi trait_mod:<is>(Method $m, :$p!) { $m does P }; class C { method m() is p { } }; C.m
camelia here
MasterDuke lizmat: if you're using --gen-(nqp|moar), i think you can add `=new-disp` to them and it'll use that branch in those repos 10:58
jnthnwrthngtn Aha, that produces no output on new-disp
On master a CALL-ME mixed into a code object apparently wins over the default invocation behavior. Interesting. 10:59
nine jnthnwrthngtn: that's how you implemented NativeCall :)
lizmat MasterDuke: meh, that still finds the old nqp-m, uses that and dies 11:01
nine Ok, actually there was some setinvokespec involved
jnthnwrthngtn nine: Yes, but invokespec is gone and...uh...NativeCall works anyway 11:02
lizmat MasterDuke: gist.github.com/lizmat/4f4bf55e5b7...fb86586207
argh... spello
nine NativeCall doesn't use CALL-ME anymore. Replacing $!do now instead
jnthnwrthngtn nine: Also seems that...right :)
So I guess in a post-invoke-spec world we should always first check for a CALL-ME 11:03
nine That sounds expensive?
lizmat MasterDuke: even with properly spelled branch name no luck (see updated gist) 11:04
MasterDuke --force-rebuild maybe? 11:07
jnthnwrthngtn nine: Dunno; this only happens when we're setting up the dispatcher; once we've set it up then its just falling out of the type guards 11:08
nine: If we really want to avoid it we could eqaddr the .WHAT of it for some common cases
MasterDuke but i just have all three repos separately checked out, so i'm not the best person to help with --gen-* settings. patrickb would know better i think 11:09
lizmat looks like --force-rebuild is doing the right thing :-)
nine dogbert11: I think, we're dealing with yet another inlining issue 11:12
And it's again in finalization handlers
lizmat nine: I see Inline::Perl5 tests fail on new-disp, is that expected ? 11:15
nine lizmat: no
lizmat perhaps I need to update Inline::Perl5 ?
ok, will get back to you on that :-)
nine You need at least 0.54 (current is 0.56)
new-disp actually uncovered 2 stupid mistakes 11:16
lizmat hmmm... it claims I need to install Inline::Perl5
dogbert11 nine: didn't you fix a bug relating to finalization handlers recently? 11:17
nine dogbert11: I did. Actually 3 bugs. MVM_frame_find_lexical_by_name was ignoring inlining entirely and both the frame walker's code parts for finding the current inlinee had problems as well 11:20
i.e. the code path for JITed code and the one for non-JITed code
jnthnwrthngtn Accessor::Facade fixed 11:22
sena_kun awesome
next?
*want something netx? 11:23
lizmat hmmm... trying to install Inline::Perl5 on new-disp says:
===> Failed to find dependencies: perl:from<native>
Failed to resolve some missing dependencies (use e.g. --exclude="perl" to skip
jnthnwrthngtn sena_kun: Sure. Well, want lunch also, but feel free to feed another one
lizmat only fails I see in roast, are the Inline::Perl5 ones 11:24
sena_kun we have AttrX::Mooish (horrible inf loop + leak), Scalar::History behaves the same way. Just failing ones are ClassX::StrictConstructor and Test::Base (something with "method mro is not found on a metamodel)").
nine Huh... MVM_spesh_deopt_find_inactive_frame_deopt_idx is looking for a ret_offset of 428, but the closest deopt_bytecode_pos are 416 and 444
sena_kun Text::Tabs is a super simple module yet it fails it's tests. Other than that I'll need to do another Blin run, but I need the infinite ones fixed for that. 11:25
s/it's/its/
nine lizmat: so you still get the same errors?
lizmat yes 11:26
it claims Inline::Perl5 is not installed
and trying to install it fails with a missing dependency
jnthnwrthngtn I suspect Scalar::History will be easier to debug than AttrX::Mooish :)
nine lizmat: the missing dependency message does tell you how to fix that 11:27
lizmat so I should do that, is what you're saying :-)
nine indeed
sena_kun jnthnwrthngtn, well, if it's the same bug then yes, unless...
lizmat nine: Inline::Perl5 installed and spectest clean! 11:30
guess I'll be developing on the new-disp branch from now on :-) 11:31
nine lizmat: only for a short while I hope :) 11:38
Aaah! It's finally a bug in my own code :D 11:44
I changed MVMuint32 ret_offset = f->return_address - f->spesh_cand->body.bytecode;
to MVMuint32 ret_offset = (f == tc->cur_frame ? *(tc->interp_cur_op) : f->return_address) - f->spesh_cand->body.bytecode;
So for the currently executed frame, we'd use the up-to-date position when looking for the inlinee we're in.
But tc->interp_cur_op points at the currently executing sp_getlexstatic_o which doesn't have a deopt annotation. Without that annotation we don't find it in the deopt table which is how we'd find a deopt_idx which we'd use for looking up the inlinee 11:46
11:50 TempIRCLogger left 11:51 TempIRCLogger joined
lizmat ^^ now running on new-disp 11:51
dogbert11 very cool 11:53
12:02 reportable6 left
lizmat hmmm... --profile -> MoarVM panic: Need to update profiling continuation support 12:02
for reference: test-t is now about 2x as slow as it is on master (on my machine) 12:03
12:05 reportable6 joined
nine I think, I fixed the original bug at the wrong layer. The point of finding the deopt_idx is to then look at the deopt table to....get the position in the bytecode the inlinee was called from! So for the currently executed frame *tc->interp_cur_pos is already the answer 12:05
jnthnwrthngtn: does this sound right? ^^^ 12:06
Nicholas jnthnwrthngtn: that most recent thing you fixed with CALL-ME - that doesn't have any sort of regression test in the rakudo repository? 12:15
jnthnwrthngtn Nicholas: Well, I'd maybe not expect it to have on in the Rakudo repo, but indeed it means there's not a spec test for it 12:44
Nicholas yes, I phrased that badly. You answered the question I should have asked. Thanks. 12:45
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2021/09/06/2021-...lean-disp/ 12:47
nine dogbert11: do you remember which test case triggered my first rounds of sp_getlexstatic_o/inlining fixes? 12:49
dogbert11 nine: you mean the VMNull messages? 12:55
nine yes
jnthnwrthngtn nine: I'm not sure I've enough context...why are we trying to deopt on an sp_getlexstatic_o?
nine jnthnwrthngtn: we're not! But the frame walker is using deopt indexes to find the current position. And I argue that for tc->cur_frame that's just a roundabout way to find *tc->interp_cur_op, so it's better to use that directly 12:56
dogbert11 hmm: I can check but I think t/spec/S02-types/range.t might be one of them
jnthnwrthngtn nine: Maybe, but that won't be anything interesting if we're in the JIT? 12:58
Also I think cur_op is a complete memory address, not an offset
nine jnthnwrthngtn: yes, this is only for non-JITed situations. For JITed code what we're currently doing may be quite OK. And yes, I meant *tc->interp_cur_op - spesh_cand->body.bytecode 12:59
Basically I think github.com/MoarVM/MoarVM/commit/8b...f875e4922d was the wrong fix 13:00
jnthnwrthngtn nine: Well, the "inactive" in MVM_spesh_deopt_find_inactive_frame_deopt_idx means "not currently executing" 13:03
Thus why it only cares for return address
nine Or rather it was the right fix, but for a different problem. It does fix deopting, but not the frame walker
jnthnwrthngtn So if anything we should have an assert in there that it's not asking about the currently executing frame.
nine Hah...I just did exactly that. And it the assert triggers immediately. 13:04
13:05 linkable6 left, evalable6 left
nine MVM_frame_try_return -> remove_one_frame -> MVM_callstack_unwind_frame -> MVM_spesh_deopt_during_unwind -> MVM_spesh_deopt_find_inactive_frame_deopt_idx -> assert -> abort 13:05
13:06 linkable6 joined
jnthnwrthngtn oh hah, right, that's too simplistic 13:06
That case is on the transition point from inactive to active (e.g. when the frame was inactive but we're now returning into it) 13:07
13:07 evalable6 joined 13:22 frost left
dogbert11 jnthnwrthngtn: is Scalar::History supposed to be working now? 13:31
jnthnwrthngtn dogbert11: Passes tests for me with the latest Rakudo push 13:32
dogbert11 thx: I must have done something wrong then because it hangs for me :( 13:33
sena_kun builds to test 13:34
dogbert11 jnthnwrthngtn: I didn't have your latest latest fix :)
sena_kun confirmed 13:36
dogbert11 confirmed here as well, jnthnwrthngtn++ 13:37
sena_kun awesome, AttrX::Mooish is fixed as well 13:38
oki, I am starting another Blin run. Other confirmed cases to look at while the test goes are: Test::Base, ClassX::StrictConstructor, Text::Tabs. 13:39
if those are not enough then PDF (Use of uninitialized value of type <anon> in numeric context) and maybe PDF::Class. 13:40
dogbert11 Text::Tabs is written by non other than ... 13:41
sena_kun :)
I think somebody rewrote it completely along the way 13:42
but were too modest to claim authorship
hmm, I need to do bumps
jnthnwrthngtn sena_kun: I think I know what's wrong with ClassX::StructConstrictor, working on that one now 13:44
Uh, StrictConstructor :D
sena_kun :)
jnthnwrthngtn Too much C...
sena_kun done bump commits, please be careful... 13:45
Geth MoarVM/new-disp: 1dbb222938 | (Stefan Seifert)++ | src/spesh/frame_walker.c
Fix frame walker still using wrong address for inline check if not JITed

While since commit 8b78433023e8a99 MVM_spesh_deopt_find_inactive_frame_deopt_idx uses the actual current position to find the deopt_idx for the currently executing frame, this position does not necessarily have to be at a deopt point. Thus it can still happen that we don't find a deopt_idx.
... (7 more lines)
vrurg Test::Async is workarounding broken wrap. Can be ignored for now. 13:53
sena_kun ā³ 105 out of 1688 modules processed
nine dogbert11: lang-call cannot invoke object of type 'VMNull' should really be gone now 13:54
dogbert11 nine++ very cool 13:55
jnthnwrthngtn Seems I've got ClassX::StrictConstructor fixed (locally, spectesting) 14:01
Test::Base has a different failure mode alas 14:03
sena_kun well, I did not say they have a common reason
jnthnwrthngtn Ah, then I misunderstood (thought they both complained about mro) 14:06
sena_kun I ran out of the modules which are grouped by now, some you fixed and some were already fixed when I tried them out, so now it's a more precise sniping. 14:07
ā³ 1037 out of 1688 modules processed
ā³ 1136 out of 1688 modules processed 14:10
very nice, I wonder if it's really faster this time
jnthnwrthngtn m: lass C { method m() { } }; role R { method m() { } }; sub c() { for ^10_000_000 { C.m }; say now - ENTER now; }; sub r() { for ^10_000_000 { R.m }; say now - ENTER now; }; c; r; 14:11
camelia 5===SORRY!5===
Undeclared name:
C used at line 1
Undeclared routine:
lass used at line 1. Did you mean 'last'?

Other potential difficulties:
Useless declaration of a has-scoped method in mainline (did you mean 'my methodā€¦
jnthnwrthngtn m: class C { method m() { } }; role R { method m() { } }; sub c() { for ^10_000_000 { C.m }; say now - ENTER now; }; sub r() { for ^10_000_000 { R.m }; say now - ENTER now; }; c; r;
camelia 0.097447874
10.442654768
jnthnwrthngtn Wowser, that's a big difference :)
sena_kun indeed 14:12
jnthnwrthngtn I accidentally just implemented the stuff to optimize such calls using the dispatch mechanism
I mean, I thought I needed to implement it to fix a bug, then realized now, I'd misunderstood the bug. :)
m: say 2.77 / 1.89 14:13
camelia 1.465608
jnthnwrthngtn m: say 10.4 / 0.0974
camelia 106.776181
timo oh my, what's this
jnthnwrthngtn No spesh linking or inlining yet on new-disp, but the ratio is a lot nicer :) 14:14
(And should stay this nice after we can spesh link and inline, I expect)
timo ah i see
on new-disp it's only 1.45 times slower, on master it's 106 times slower
to call a method on a punned role 14:15
jnthnwrthngtn Yes 14:17
Well, yes-ish
Because we're calling an empty method so it inlines away to nothing
But with new-disp we'd be able to inline away the method on the punned role also 14:18
timo ah, hehe.
so we're still emitting noticeably more guards or sometihng liek that 14:19
no, scratch that
you think there's anything much we can do for subs and methods whose bodies look like { other-sub($arg, $narg, $farg) }; ? 14:21
14:22 evalable6 left, linkable6 left
timo if we inline that, the dispatcher that does the other-sub call will also be there i guess 14:22
14:22 linkable6 joined
jnthnwrthngtn I think inlining mostly will take care of that? 14:24
14:24 evalable6 joined
timo it'll also be super good at not-juggling-the-arguments? 14:33
well, not actually important
carry on
sena_kun 87 modules to test, that's the longest part to wait for... from the 1601 tested, 12 modules (including the ones I named) are broken so far. 14:35
jnthnwrthngtn Seems Text::Tabs was a missing guard 14:44
Spectesting a fix, but should have that one nailed
sena_kun is Test::Base fixed locally or not yet?
jnthnwrthngtn No 14:45
sena_kun roger
jnthnwrthngtn I did repro it, but wasn't immediately sure what's going on 14:46
Yup, spectest is fine, Text::Tabs is fixed 14:47
Weird failure more. Hm. 14:48
sena_kun yay 14:49
jnthnwrthngtn oh, Test::Base is...subtle. I dunno if/how we can fix that. 14:52
method FALLBACK($name) { 14:53
::?CLASS.^add_method($name, method () { $!data{$name} });
return $!data{$name};
}
sena_kun ā³ 1663 out of 1688 modules processed
jnthnwrthngtn It adds a method to the class. But the callsite is already linked to FALLBACK by that point. 14:54
So the next time around it cals the method again
*calls
The FALLBACK method again, that is. And tries to add a method of the same name again.
So it's relying on an implementation detail of how method caching previously worked. I wonder if it's alone in that. 14:55
greppable6: FALLBACK
greppable6 jnthnwrthngtn, 104 lines, 31 modules: gist.github.com/f02ce6de48ffcc52ea...5f2cd23ce1
jnthnwrthngtn greppable6: method FALLBACK 14:56
greppable6 jnthnwrthngtn, 56 lines, 28 modules: gist.github.com/2de04fca1d92b9719e...0a6feaa36c
jnthnwrthngtn Inline::Perl5 sorta does the same trick except it uses a mixin, forcing a type change, and thus meaning the inline cache entry won't go for the FALLBACK the next time: github.com/lizmat/raku-all-modules...ct.pm6#L32 14:58
nine Oh, I thought ^add_method isn't allowed after ^compose.
Actually that mixin trick shouldn't even be in use anymore. Will have to test if there's some weird use case left. 14:59
Nowadays github.com/niner/Inline-Perl5/blob...assHOW.pm6 is the work horse
jnthnwrthngtn nine: Well, it sure ain't if you re-compose 15:01
uh, if you don't re-compose
But that won't help here either without some significant effort
It seems it's the only module that's doing this 15:02
And best of all, the fix is to delete a line of code, unless it actually wants the methods added for introspection reasons too
dogbert11 jnthnwrthngtn: are you talking about Text::Tabs?
jnthnwrthngtn No, Test::base 15:04
sena_kun dogbert11, Test::Base, tabs are fixed already
jnthnwrthngtn I think Test::Base goes on the "send a PR" list
dogbert11 ah, I got confused 15:05
jnthnwrthngtn sena_kun: Did AttrX::Mooish start passing, or just no longer eat all the memory?
sena_kun jnthnwrthngtn, it passes fine for me
jnthnwrthngtn, do you want something next? 15:06
jnthnwrthngtn Sure
sena_kun jnthnwrthngtn, I think you reproduced DOM::Tiny, right?
jnthnwrthngtn That one I still have to look at 15:07
I thought I knew what it was, but then it wasn't so clear...
nine jnthnwrthngtn: I bet the ^add_method trick is only for the speedup (which used to be substantial)
jnthnwrthngtn nine: It may sorta still be, but we can rewrite the args directly to FALLBACK with the dispatcher :) 15:08
I don't think I did that yet
sena_kun well, this one is on the list. others to try are maybe Audio::Liquidsoap (typecheck failed to bind), hide-methods, Pretty::Table.
jnthnwrthngtn The middle one of those sounds scary :) 15:09
15:09 brrt joined
brrt \o 15:09
tellable6 2021-08-31T09:39:17Z #moarvm <Nicholas> brrt Pyston (finally) seems to have solved its "how do we monetise this?" problem: blog.pyston.org/2021/08/30/pyston-...-anaconda/ www.anaconda.com/blog/pyston-team-...s-anaconda
sena_kun well, lizmat++ wrote it, so it is small, at the very least, less golfing
jnthnwrthngtn Pretty::Table I can repro. Hm. 15:11
sena_kun Cro::WebApp is broken as well, if you fancy. :) 15:13
jnthnwrthngtn Oh? What failure mode?
And does this mean the rest of Cro is OK? :)
sena_kun Type check failed in assignment to $!path; expected type Path cannot be itself (perhaps Nil was assigned to a :D which had no default?)
in a test for forms 15:14
rest of the Cro - not sure about HTTP, it fails but I have no idea if because of a flapper or not.
ah no
Type check failed in assignment to $!path; expected type Path cannot be itself (perhaps Nil was assigned to a :D which had no default?)
Type check failed in assignment to $!path; expected type Path cannot be itself (perhaps Nil was assigned to a :D which had no default?) 15:15
in cookies handling
so it's something related, I suspect
so we are at about 30 modules. in fact, less, maybe around 22-25. 15:16
brrt .tell Nicholas question is, who is making money from open source perl... 15:17
tellable6 brrt, I'll pass your message to Nicholas
brrt let alone raku
ohai jnthnwrthngtn :-P
nine "New type Stash for Perl6::Metamodel::PackageHOW is not a mixin type" when loading a module seems to be the only (reproducible) failure in our Cro-based applications at work 15:27
And that went away after removing .precomp directories... 15:30
Nicholas brrt: I don't think that many folks are making money from open source *anything* (see ActiveState trying to encourage firms to take up the offer of long term Python 2.7 support) - at least for "open source you install locally to your own systems" 15:34
tellable6 2021-09-06T15:17:21Z #moarvm <brrt> Nicholas question is, who is making money from open source perl...
brrt yeah, I think that's accurate these day s 15:38
jnthnwrthngtn o/ brrt 16:03
16:07 brrt left
jnthnwrthngtn m: subset S where ($_ ~~ <a b c> || die); say "a" ~~ S 16:07
camelia Died
in block <unit> at <tmp> line 1
jnthnwrthngtn m: enum e <a b c>; subset S where ($_ ~~ e || die); say a ~~ S; say S ~~ S 16:08
camelia True
True
jnthnwrthngtn Pretty::Table is fixed 16:16
sena_kun yay 16:27
something else or hide-methods time?
jnthnwrthngtn I'm looking at hide-methods now. Trying to understand how/why the test would pass on master :) 16:31
timo "how did this ever work" time
jnthnwrthngtn I missed something important in the test 16:42
So it's OK, I just...need to figure out the bug
It feels like "missing guard" but I can't imagine where
timo well it could also be wrngly removed guard
jnthnwrthngtn oh 16:46
It's probably 'cus it's also playing "add methods at runtime" tricks
Yeah, I see. 16:48
nine At least it composes ;) 16:50
jnthnwrthngtn It does 16:51
The trouble is that if we already reoslved a method to one in a parent at a callsite, then it won't be reevaluated later
This policy is largely OK for augment 16:52
(So long as it happens at module load times)
But there's not yet an invalidation strategy
sena_kun really not sure if I can suggest anything simpler... 17:06
except Audio:: one
jnthnwrthngtn I suspect that needs a native dep
DOM::Tiny seems just an NYI in the multi dispatcher 17:08
Just compiling an attmept at it
sena_kun the rest are basically metamodel-related ones (each need a check if it's a bug or a reliance on internals), Cro failures, PDF-related failures (that's deep). 17:09
jnthnwrthngtn Yeah, kinda hoping some of the other fixes might nail the PDF one 17:10
Seems I have a working fix for DOM::Tiny 17:11
sena_kun wow
jnthnwrthngtn I've lost count of how many I've fixed today :)
sena_kun IIUC PDF ones have a couple of different issues exposed, so that's pretty entangled
a lot
[Coke] Do these fixes need spec tests?
jnthnwrthngtn [Coke]: Most of them probably do, yes 17:12
Well, or at least, we'd know about the issues sooner 17:13
Fix for DOM::Tiny pushed 17:14
sena_kun: Which Cro things have failures?
sena_kun jnthnwrthngtn, Cro::HTTP and Cro::WebApp. The failure mode is very similar (the same exception, but in different places), so maybe better to narrow down the HTTP one and then check if it fixes the WebApp. 17:16
jnthnwrthngtn Makes sense, thanks
Though...hmm, was it something involving a subset type
sena_kun As for what ones were fixed today: Colorizable, AccessorFacade, DOM::Tiny, AttrX::Mooish, Scalar::History, ClassX::StrictConstructor, Test::Base, Text::Tabs, Pretty::Table
jnthnwrthngtn, Type check failed in assignment to $!path; expected type Path cannot be itself (perhaps Nil was assigned to a :D which had no default?) 17:17
jnthnwrthngtn Not bad for a day when I woke up and felt rotten enough that I wondered if I'd get anything done at all...
sena_kun in submethod BUILD at /mnt/data/pakku/.cache/Cro-HTTP/Cro-HTTP-0.8.5-JonathanWorthingtonjnthn@jnthn.net-/lib/Cro/HTTP/Cookie.pm6 (Cro::HTTP::Cookie) line 138 17:18
in block at t/http-session-persistent.t line 91
^ here is the test
jnthnwrthngtn, yes, that's an outstanding pace
hmm, I'll also test out if Template::Anti and Oddmuse6 were fixed with the same fix as DOM::Tiny, this will mean that 11 modules in a single day were fixed... 17:19
jnthnwrthngtn Cro::HTTP passes 17:21
I think it was the same issue that afflicted Pretty::Table
sena_kun interesting 17:22
can you try WebApp then?
jnthnwrthngtn Yeah, doing so
sena_kun the test is `t/form-router-integration.t`
jnthnwrthngtn It passes 17:25
sena_kun that's 13 modules then. Template::Anti passes, so 14 and... 17:26
hmm, I won't check Oddmuse6, but let's assume 15.
jnthnwrthngtn, time for some rest?
jnthnwrthngtn Yeah, I think so :) 17:27
sena_kun jnthnwrthngtn, you deserve plenty 17:28
jnthnwrthngtn Need a day with a clear head to finish up the spesh linking / inlining work so we get much of the perf back, though I fear tomorrow shall not be that day. 17:30
sena_kun indeed
d'oh, I probably should have saved some easier ones for tomorrow. :/
OTOH not sure if you'll work tomorrow
jnthnwrthngtn Dunno, we'll see. 17:31
afk for a bit
Thanks for the feed of things to work on :) 17:32
17:33 sena_kun left 17:37 tealecloud left 18:02 reportable6 left 18:05 tealecloud joined 18:10 tealecloud left
Nicholas jnthnwrthngtn: after your last commit, is it still possible to reach that NYI failure? (Is this a fuzzing challenge?) 18:45
18:57 tealecloud joined
MasterDuke timo: www.phoronix.com/scan.php?page=new...curses-2.4 seems like the sort of thing you'd be interested in 18:59
timo this "sexblitter" has only half the vertical resolution of sixel, what a shame 19:01
i forget how many pixels per cell it has in width
19:02 tealecloud left 19:04 reportable6 joined
timo is that first demo video meant to be played on two screens side-by-side? 19:08
MasterDuke i think so 19:09
honestly i wasn't a huge fan of the demo video
timo " That's not a TUI; it's a slow and inflexible GUI. Many terminal emulators don't support Sixel. Sixel doesn't work well with mouse selection. Sixel has a limited color palette. With that said, both Sixel and the Kitty bitmap protocol are well-supported." 19:16
19:38 TempIRCLogger left, TempIRCLogger joined 19:57 tealecloud joined
MasterDuke hm, i've got some more diagnostic info about what's going on with this gc'ed mutex, but haven't figured out exactly why the source of the problem is happening 20:18
so my stack of now two ex_release_mutexes seems to be working fine 20:19
i see one being set in MVM_load_bytecode, then a second in prepare_and_verify_static_frame, then a clear in prepare_and_verify_static_frame and a clear in MVM_load_bytecode
however, between the the last time that happens and the panic, in prepare_and_verify_static_frame there's an additional set / clear and then a release 20:23
but no MVM_load_bytecode between that release and the final release before the panic 20:26
oh, gist.github.com/MasterDuke17/33f0c...f05126dfe3 is an interesting backtrace 20:34
timo i assume you turned off jit so backtraces don't go wacky? 20:42
MasterDuke yeah 20:43
timo ah, hehe 20:50
the exception is being thrown, then caught, and the chandler hasn't run yet, so it now has to be verified as well
this might even be able to infinitely loop?
if the handler is also the target for the exception thrown by the handler not verifying correctly? 20:51
MasterDuke this is the example with YAMLish and EVAL that ends in an MVM_panic: tried to gc a locked mutex 20:52
20:53 vrurg left
MasterDuke so i think what i expected to happen is set in MVM_load_bytecode, set in prepare_and_verify_static_frame, then the exception and both be released 20:53
but that's not what's happening 20:54
timo i guess the mutexes are cleared when the stack is unrolled, so they would still be held while the handler runs 20:55
jnthnwrthngtn Nicholas: Should be impossible. 20:56
MasterDuke because before the panic, it's set in MVM_load_bytecode, set in prepare_and_verify_static_frame, clear in prepare_and_verify_static_frame, clear in MVM_load_bytecode. then a bunch of other code, set in prepare_and_verify_static_frame, exception, release
but the mutex from MVM_load_bytecode wasn't set again, so it doesn't get released 20:57
20:59 vrurg joined
timo is the problem not that it's two levels deep? 21:04
21:05 vrurg left, vrurg joined 21:27 tealecloud left
MasterDuke jnthnwrthngtn: nice, measured the effect of those $*MAST_FRAME commits? 21:39
timo: i think yes and no 21:40
well, maybe more no than yes
i guess it depends on what you mean by levels 21:41
so it's in prepare_and_verify_static_frame twice in that backtrace, yeah. but the panic happens later 21:42
timo right, when the stack gets unwound after the handler has run? 21:44
and the inner verify function has set some stuff and overwrote the outer one? 21:45
and on the way back, the data is bogus?
MasterDuke no, data is fine 21:46
there's just a locked mutex being gc'ed because of the exception 21:47
that wasn't set in ex_release
jnthnwrthngtn MasterDuke: valgrind says around 2 billion less IFs 22:42
So I guess 0.6% off or so
MasterDuke cool beans 22:43
jnthnwrthngtn I think $*REGALLOC was going to be the big one both in terms of frequency but also because it leaves the cache slots free for other things
There's still some streamlining to do around producing callsites though 22:44
We're pretty much tied with master at this point for CORE.setting compilation total time (a tad slower on parse, winning it back elsewhere) 22:47
This is good in the sense that there's still plenty of optimization opportunities to go. 22:48
22:48 linkable6 left, evalable6 left 22:50 linkable6 joined
MasterDuke nice. i'm guessing really big wins at parse are only going to come from an nqp nfa/regex re-write? 22:50
i.e., new-disp will help everything, but it's not a silver bullet for parse by itself? 22:51
jnthnwrthngtn Indeed
I think there'll be some ways new-disp will be able to help us optimize regex performance. 22:55
Well, especially grammars 22:56
But we'll need a re-work of NFAs and how we use them 22:57
MasterDuke i keep flirting with the idea of trying to start doing something in that area, but i feel that just blindly making changes and hoping for the best (my preferred method of jumping into a codebase) isn't going to work, and some theory and concrete plans are going to be required 23:03
jnthnwrthngtn For sure 23:10
And before that deciding what problems we're aiming to solve with it
timo my brain is still incapable of coming up with the right peg to hang a "this regex should be a simple sub instead" feature of the optimizer 23:18
23:23 MasterDuke left
jnthnwrthngtn I think it'll be easier in RakuAST 23:24
timo ah, makes sense 23:43
you may have told me this already at some point in the past 23:44
23:49 evalable6 joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!