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:26 coverable6 joined, quotable6 joined, evalable6 joined 00:57 Altai-man_ joined 01:00 Altai-man left 01:04 reportable6 joined 01:14 frost joined 01:26 tellable6 joined 01:27 statisfiable6 joined 02:26 squashable6 joined 02:35 frost left 02:39 frost joined 03:14 frost left 03:20 frost joined 04:20 coverable6 left, committable6 left, squashable6 left, statisfiable6 left, releasable6 left, reportable6 left, tellable6 left, bloatable6 left, unicodable6 left, notable6 left, greppable6 left, shareable6 left, sourceable6 left, linkable6 left, quotable6 left, evalable6 left, benchable6 left, nativecallable6 left, linkable6 joined 04:21 committable6 joined, nativecallable6 joined 04:22 reportable6 joined, bloatable6 joined, squashable6 joined, benchable6 joined, evalable6 joined, statisfiable6 joined 05:20 shareable6 joined, notable6 joined 05:21 quotable6 joined, tellable6 joined 05:22 releasable6 joined 05:23 sourceable6 joined 06:02 reportable6 left 06:03 reportable6 joined 06:21 unicodable6 joined 06:27 bisectable6 joined
Nicholas good UGT, #moarvm 06:43
07:49 brrt joined, patrickb joined 08:07 patrickb left
nine Good times for a universal greet! 08:15
japhb Good times! 08:17
08:22 coverable6 joined
nine Just checked: for JITed code, the frame walker already did exactly the same as it is doing in the non-JITed case after my change: just taking the current position and looking for matching inlines. 08:23
08:24 tealecloud joined
nine Speaking of which: during debugging I noticed that the list of inlinees can already be somewhat long (and we're going to become better still at inlining!). The list is also sorted. So I wonder if instead of the linear search we're doing now we ought to bisect the list instead. 08:25
I guess it depends on whether for such small to medium sized lists, plain iteration is more cache and branch prediction friendly 08:33
brrt good times indeed 08:36
08:38 brrt left
nine Of course, the fastest way to search is to not search at all. Which should be a viable approach for at least some users of e.g. MVM_frame_find_lexical_by_name. After all, at code gen time (normal and spesh) we already know perfectly well, whether we are in an inline or not and if yes in what inlinee! 08:38
So we'd just have to pass that inline_idx to the op. 08:39
09:29 brrt joined
jnthnwrthngtn moarning o/ 09:37
nine moarning jnthnwrthngtn! 09:38
brrt good * 09:39
09:39 discord-raku-bot left 09:40 discord-raku-bot joined
Nicholas \o 09:48
jnthnwrthngtn nine: The deopt point list can also be very long, but I think in part because its design was such that even deopt points that turn into instructions that can never deopt remain in it, and the design doesn't really make it easy to sweep 09:51
Urgh. I'm not allowed any coffee today. :( 09:52
Nicholas but will you be allowed ice cream?
jnthnwrthngtn Yes, encouraged in fact. 09:58
nine Lose some, gain some :)
Nicholas aha, so I guessed right... :-/
jnthnwrthngtn Beer apparently is OK from 24 hours or so after the procedure too, "because it's cold" 09:59
09:59 brrt left
jnthnwrthngtn (Although I'm quite sure that it won't help me get any work done. :)) 10:00
Nicholas They are making cultural assumptions about beer... 10:01
dogbert11 jnthnwrthngtn: dentist? 10:02
jnthnwrthngtn I've only so far been in one country where a watier asked if I wanted my beer warm or cold, and I said cold, and got warm anyway, and it wasn't nice.
dogbert11: Indeed.
That said, the Christmas before last, the nearby microbrewery had...hm, I guess "mulled beer" is a working translation. 10:04
Ah, yes, searching for it gives the right thing :)
Altai-man_ jnthnwrthngtn, o/ 10:05
plan to look at new-disp today or?
jnthnwrthngtn Altai-man_: Still trying to decide what to do. Though quite possibly that. 10:06
Got a small admin task to take care of first
Altai-man_ jnthnwrthngtn, alright, I'll rush to the office soon and will be able to do a new Blin run. Prior to that we still have some targets to address. 10:07
jnthnwrthngtn Altai-man_: OK. I won't do the office today; I suspect the walk there will in itself be exhausting. 10:09
Altai-man_ yeah, a wise choice
10:11 squashable6 left
dogbert11 we're running a bit low on SEGV's and deadlocks atm 10:16
i guess that's a good thing :)
the only thing I have is the deadlock/hang in t/spec/S17-procasync/no-runaway-file-limit.t but I'm not certain that it's a new-disp problem 10:18
nine I'm on a train on the way to a vacation and will come back on 2021-09-19 10:23
Nicholas that's after the release? :-) 10:24
jnthnwrthngtn nine: Have a really nice vacation! :) 10:26
releasable6: status
releasable6 jnthnwrthngtn, Next release in ā‰ˆ10 days and ā‰ˆ8 hours. There are no known blockers. Changelog for this release was not started yet
jnthnwrthngtn, Details: gist.github.com/b9e0d0efbf2decebc6...884ae965d0
nine Next release will be from current master anyway. Though I wouldn't mind if someone were to merge the applicable fixes from new-disp before the release. There are a few that actually don't depend on new-disp.
jnthnwrthngtn Yup, but also I think the realistic aim is to merge new-disp shortly after the release.
Then we have a month of testing/tuning/fixing 10:27
nine jnthnwrthngtn: thanks a lot :)
Nicholas My personal risk-averse view/finite wetware view is that (on balance) we might end up with more problems/delay by trying to unpick them, then just waiting a month for them to ship. But, I'm not quailified to do any of the actaul *work* here, nor do the bugs affect what I want as an end user 10:28
nine: have fun. Stay safe.
dogbert11 nine: have a nice vacation 10:29
nine Nicholas: will try :D
10:51 sena_kun joined
sena_kun hmm, I'll bump new-disp branches 10:57
11:18 tealecloud left 11:24 brrt joined
dogbert11 FWIW, the PDF module seems to 'hang' on this line github.com/pdf-raku/PDF-raku/blob/...akumod#L98 11:58
12:02 reportable6 left 12:03 reportable6 joined 12:11 frost left 12:14 squashable6 joined
sena_kun interesting 12:15
13 modules left to process, so far 12 are to investigate 12:16
jnthnwrthngtn Hm, not quite into single digits yet, alas 12:22
Nicholas Take your shoes off, and claim otherwise :-)
sena_kun a lot better compared to ~60 I'd say, in such a short time
Nicholas well, OK, single digits in hex. That's better...
jnthnwrthngtn is working from home and shoeless anyway :) 12:24
lizmat
.oO( shoeless programming, the trend of the 2020's :-)
 12:34
12:39 brrt left 12:41 tealecloud joined 12:51 brrt joined
jnthnwrthngtn OK, time for some new-disp work, I think... 12:58
sena_kun jnthnwrthngtn, want some suggestions or will you pick up something from Monday? 13:00
jnthnwrthngtn I've already forgotten what was left on Monday :)
I thought DOM::Tiny but I think I did fix that after all 13:01
sena_kun you did fix it, yes
jnthnwrthngtn And Cro::HTTP and Cro::WebApp passed for me, hopefully they are good in blin too 13:02
sena_kun alright, I have three options for you to choose from: PDF scary bunch, MOP scary bunch, "the rest" bunch with a couple of "typecheck failed", "too few positionals" and the a lot more weird ones.
jnthnwrthngtn, yes, they are fine
jnthnwrthngtn The PDF modules are huge, so I'd prefer to go for smaller ones first 13:03
sena_kun alright
try Math::PascalTriangle
jnthnwrthngtn argh, that seems spesh sensitive bug vanishes under blocking and nodelay 13:06
*but
oh worse, it doesn't fail every time either 13:07
sena_kun hmm, I wonder if it flaps on master as well 13:09
jnthnwrthngtn It still flaps with rash randomization turned off, so I wondered if it might be a memory corrption issue, but valgrind doesn't see one 13:11
No luck with GC debug and smaller nursery either. In fact, I can't get it to happen with any of those 13:13
sena_kun hmm 13:14
can you check if App::MoarVM::ConfprogCompiler fails? 13:15
this is probably an easier target as it should fail reliably 13:16
jnthnwrthngtn Well, Math::PascalTriangle looks very new-disp related at least, because: 13:17
multi method get(:$line!, :$col! where * == 0) {1}
Is where we get:
Constraint type check failed in binding to parameter '$col'; expected anonymous constraint to be met but got Int (11)
But that should never report an error, it should resume going through multi candidates 13:18
Adding --ll-exception means it happens in the candidate at line 9 instead... 13:19
.oO( Smells like stack limit )
 13:20
13:22 sena_kun left 13:23 sena_kun joined
Geth MoarVM/new-disp: 5d43eeaee7 | (Jonathan Worthington)++ | src/core/args.c
Fix search for bind control records

It is possible that the bind control record is in a stack segment prior to the one that a frame is allocated in. In code that recurses enough to trigger multiple stack segments, this situation may occur, and could lead to multiple dispatch of candidates with `where` clauses and similar wrongly reporting an error instead of continuing to the next candidate.		 13:26
sena_kun wow 13:27
jnthnwrthngtn That was Math::PascalTriangle 13:28
sena_kun yup
now App::MoarVM::ConfprogCompiler?
timo oh no what did i do wrong :S 13:34
jnthnwrthngtn That one is using the MAST code-gen API, and I think the change in github.com/MoarVM/MoarVM/commit/0f...3549cc9458 is to blame
I'm not sure what we can easily do about that
timo whoops. the perils of being a core developer making stuff with core tie-ins 13:35
sena_kun alright, then probably no help for it other than fixing the module
jnthnwrthngtn Probably that
OK, next.
sena_kun can you check if App::Lorea fails for you?
jnthnwrthngtn Dunno if I've said this already, but `zef look` makes it so darn easy to grab the source of a module and be in a directory containing it 13:36
zef++
timo indeed 13:37
jnthnwrthngtn sena_kun: Fails
sena_kun but on 2021.08 it's fine 13:38
jnthnwrthngtn hah, of course it fails, I didn't install its dependencies :) 13:39
It did a nice job of disguising that problem though :) 13:40
sena_kun huh
in Blin log it just fails its tests
Failed test 'Happy output to STDOUT'
ļ½¢App::Lorea:ver<0.2.0>:auth<cpan:JJATRIA>:api<>ļ½£
jnthnwrthngtn OK, with its dependencies installed, it now passes its tests
sena_kun ah-ha
jnthnwrthngtn Its deps are properly declared to be clear 13:41
sena_kun Audio::Liquidsoap then. It has no native libs to install.
jnthnwrthngtn I just forgot to install them, the the test actually runs without them, and is running something in the bin/ directory, and *that* uses the thing I failed to install 13:42
So I don't think the module is doing anything wrong. But still, it doesn't fail for me.
sena_kun alright, I'll investigate it later
Audio::Liquidsoap has issuus with type checking around binding 13:43
jnthnwrthngtn It is doing file watch-y stuff, I think, and it's possible to get into bother with timing and async
sena_kun yes, can be
jnthnwrthngtn That said, I can't make it fails even with running it while running a spectest, which creates quite a load 13:44
OK, no further investigation on that one for now.
Can reproduce the fails in Audio::Liquidsoap 13:49
Hmmm. Certainly looks new-disp-y but... 13:59
m: multi m(Str :$s!) { }; multi m(List :$s!) { }; BEGIN m(:s[1,2]) 14:06
camelia ( no output )
jnthnwrthngtn Golfs to that, the BEGIN being the key to it
Fix developed, spectesting 14:15
Also going to take a short break, but feel free to feed the next module :)
Will commit/push when I'm back if spectest is clean 14:16
sena_kun DateTime::Timezones is next, I guess, it's the last I am sure about without MOP magic. 14:17
timo sometimes all you can really do is MOP up the pieces
14:56 evalable6 left, linkable6 left
jnthnwrthngtn spectests were fine, pushed the fix, so that's Audio::Liquidsoap done 15:03
sena_kun yay 15:14
the next one is DateTime::Timezones with a nice error.
the next one is DateTime::Timezones with a nice error. 15:15
jnthnwrthngtn Two different errors, though we'll see if they boil down to the same thing 15:17
It's quite involved, using wrap etc.
sena_kun alternatively I can suggest MOP ones or PDF ones. :( 15:18
15:21 greppable6 joined
jnthnwrthngtn Bother, it's a callwith problem 15:28
I know what's going on. I need to think a bit about how to fix it.
It's not an LHF one
Maybe we're out of those :) 15:30
sena_kun aha
want another?
jnthnwrthngtn I'm curious about the MOP ones
sena_kun try "Kind"
there is also Kind::Subset::Parametric depending on it, not sure if the same bug. Also Data::Record. 15:31
jnthnwrthngtn Wow. "Unknown type check mode 0" 15:33
Fixed with NQP commit fd4956b8c. Next! 15:40
Oh, you gave two others already
sena_kun yes, first check if the Kind::Subset::Parametric was fixed by your fix 15:41
jnthnwrthngtn Yeah, already on that
No, it's different 15:42
OK, that needs a PR, I can do it 15:45
It's using an nqp::op rather than something in Metamodel::Primitives; if it had used the latter it'd have worked.
sena_kun phew, those were not so scary then 15:46
japhb jnthnwrthngtn++ sena_kun++ # Damn fine teamwork 15:47
jnthnwrthngtn Filed as github.com/Kaiepi/p6-Kind-Subset-P...ric/pull/1 15:51
The nice thing is that the fix makes it use less impl specific things too :)
sena_kun great
Data::Record?
jnthnwrthngtn Let's see...
sena_kun by the way, did you think about hide-methods?
I remember it being involved 15:52
jnthnwrthngtn Data::Record is the very same problem as Kind::Subset::Parametric and thus gets a PR too. With the one-line changes it passes in full. 15:56
sena_kun awesome 15:57
Can you check Trait::Traced? I am not sure if the tests are depending on the implementation or it's the module got broken. 15:58
jnthnwrthngtn github.com/Kaiepi/ra-Data-Record/pull/1 15:59
hide-methods is involved indeed
Well, for one Trait::Traced depends on Kind 16:00
Which I fixed
Testing if it's got its own issues beyond that
yes 16:01
sena_kun yes fixed, yes broken? :)
jnthnwrthngtn Yes, it has issues 16:06
The first is because of the way eliding calling a `proto` has changed: previously we always called it once per time we hadn't got a result in the dispatch cache. 16:07
And so always if there was a candidate with a `where` clause, I guess 16:08
This is...pretty arbitrary :)
sena_kun so it's implementation details testing then?
jnthnwrthngtn Now we consistently avoid calling it
Yeah, there was no spec about if an onlystar proto would get called or not, and when
If we spec anything it'll be the new semantics
At least for this particular situation though, it's possible to cope with master and new-disp at once in the tests 16:09
Well, easily cope.
That's only some of the failing tests, though. Picking over the others still. 16:10
Oh, it was the same implementation detail depended on, but in disguise 16:11
sena_kun alright, now one which can be really easy... or not. Can you just try to install Sustenance? If it just installs then fine. 16:12
jnthnwrthngtn OK, all failing tests in Trait::Traced have the same cause and the same resolution 16:13
github.com/Kaiepi/ra-Trait-Traced/pull/7 16:21
Sustenance passes its one test file at least 16:23
sena_kun alright
then it's "fixed" too, I guess.
jnthnwrthngtn Installs fine too
sena_kun I'm afraid we ran out of options to ignore PDF by now 16:24
jnthnwrthngtn OK.
In the dream situation we already fixed it of course :P
So iirc there's multiple PDF modules to look at?
sena_kun let's try by testing if just "PDF" works? if it works, then try PDF::Content.
yeah, I'll arrange them one by one. 16:25
jnthnwrthngtn OK, I guess deepest dep first
sena_kun yup
jnthnwrthngtn OK, installing deps of PDF 16:26
What was the failure mode of PDF on blin? 16:29
for me it passed everything up to t/pdf-open.t and now is seemingly hanging and eating memory 16:30
sena_kun what version do you use?
jnthnwrthngtn Did zef look and it says PDF-0.4.15.tar.gz 16:31
Yeah, 2 tests hang 16:32
Test files, that is
sena_kun that's the failure mode
šŸ’€ TST: ļ½¢PDF:ver<0.4.15>:auth<cpan:WARRINGD>:api<>ļ½£
jnthnwrthngtn ah, OK, I thought we were done with the hangy/eaty ones
Infinite recursion, and there's a callsame involved, which is a clue 16:40
Goodness, what is it doing... 16:44
lizmat
.oO( contemplating very deeply )
 16:49
16:51 lizmat_ joined, RakuIRCLogger left 16:52 RakuIRCLogger joined
jnthnwrthngtn A callsame in an AT-POS is managing to end up invoking a method that we deeper in the stack already did a callsame off, which smells of missing guard, except the guards look correct. 16:55
16:55 lizmat left 16:56 lizmat_ left, lizmat joined 16:57 brrt left
jnthnwrthngtn Think I'll hunt this one tomorrow (or at least later this evening after a bit of rest). Not immediately obvious what could be causing it. 16:57
sena_kun still quite a good hunt 16:58
I don't think I can offer a lot more for today
jnthnwrthngtn I guess by now we're down to something like: PDF (still diagnosing), DateTime::Timezones (callwith arguments not passed along properly between dispatch levels), and hide-methods (invalidation issues). 17:01
If we're lucky the three PRs I did will also get applied before the next blin run 17:02
afk for a bit 17:03
sena_kun jnthnwrthngtn, also: Test::Base, rest of PDF ones with different issues (PDF::Class says nextsame is not in the dynamic scope, scary), HTML::Canvas. 17:06
Kaiepi, ping? 17:17
17:27 sena_kun left
Kaiepi .tell sena_kun merged the Data::Record, Kind::Subset::Parameteric, Trait::Traced prs 17:27
tellable6 Kaiepi, I'll pass your message to sena_kun
17:58 evalable6 joined 18:02 reportable6 left 18:05 reportable6 joined
Altai-man_ Kaiepi++ 18:22
18:26 tealecloud left 18:32 brrt joined 19:18 brrt left
jnthnwrthngtn Hm, I thought I looked at Test::Base... 19:30
dogbert11 jnthnwrthngtn: valgrind gets a bit unhappy when trying to run the tests in HTML::Canvas 19:31
jnthnwrthngtn ah, right, it was one we probably send a PR for
dogbert11 ==2079904== Thread 2 spesh optimizer:
==2079904== Conditional jump or move depends on uninitialised value(s)
==2079904== at 0x4B7CFD1: optimize_bb_switch (optimize.c:2289)
==2079904== by 0x4B7D0C5: optimize_bb (optimize.c:2327)
jnthnwrthngtn dogbert11: That'll be even more interesting if it turns out disabling spesh fixes it :) 19:32
dogbert11 I would like to answer yes but alas ... 19:33
jnthnwrthngtn Goodness HTML::Canvas has a lot of deps...
Including native ones 19:34
dogbert11 for me it hangs on the very first test file (00-readme.t)
jnthnwrthngtn OK, I might first fix the infinite recursion bug in PDF and see if that helps (although likely not today; I'm tired)
dogbert11 the valgrind problem might be unrelated to the problem you're looking for but perhaps worth a note 19:35
jnthnwrthngtn Does it only happen with that file or quite often? 19:43
dogbert11 the valgrind error?
jnthnwrthngtn Yes 19:44
dogbert11 seems to happen for all of them 19:45
all test files in HTML::Canvas that is 19:46
the following is enough to provoke valgrind: perl6-valgrind-m -Ilib -e 'use HTML::Canvas' 19:50
jnthnwrthngtn OK, don't see anything in the code, will have to look again when I install the deps for that module 19:52
Ah, and I think timo++ did the leak fix for this, so may have a guess also 19:57
[Coke] kicking off a windows build with latest updates. 20:14
(I think "git clone nqp" may now be the slowest part of the process on windows. :P) 20:17
timo i blame the stage0s 20:19
Nicholas OpenBSD-- # can't do C11 thread local storage in shared objects, but doesn't actually error 20:22
Apple-- # can't do C11 thread local storage in shared objects, but doesn't actually error. And has lots more money
sigh.
I think that cygwin is also in this "fake it until you make it, er, whoops" 20:23
dogbert11 it turns out that the valgrind errors only turns up if MoarVM has been built with --no-optimize 20:31
if you do build with --no-optimize a golf which triggers valgrind is: rakudo-valgrind-m -e 'role PDF { }' 20:33
20:34 squashable6 left 20:37 tealecloud joined
MasterDuke speaking of timo++ doing leak fixes, there are still some leaks with --full-cleanup just for -e '' 20:42
jnthnwrthngtn I'm too tired to code, but today new stocks arrived for the beer fridge, and have now been loaded into it. 20:43
Nicholas \o/ 20:44
jnthnwrthngtn So far as stouts go, that's probably going to last much of the way through October. Some effort to fit it in and keep it mostly organized by style and brewery :) 20:47
And I'll now proceed to drink none of it, to give my body another easy day... 20:48
20:59 linkable6 joined 21:07 tealecloud left 22:18 lizmat left, lizmat joined 22:19 TempIRCLogger left 22:20 RakuIRCLogger left
Geth MoarVM/new-disp: 356e117815 | (Timo Paulssen)++ | src/jit/compile.c
prevent perf map output from segfaulting
 22:34
timo this bothered me :) 22:36
22:37 RakuIRCLogger joined
timo looking for performance issues in this one piece of code probably makes no sense yet, until we have spesh linking and extra inlining stuff in place 22:37
until then, 18.35% time spent in disp_program_run 22:38
22:39 TempIRCLogger 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!