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:05 reportable6 joined 00:07 linkable6 left 00:08 linkable6 joined 00:22 jgaz left 01:22 linkable6 left, evalable6 left 01:24 linkable6 joined, evalable6 joined
timo | * 00372e46f - (origin/disp-prog-spesh-codegen) disp prog spesh codegen for LoadAttribute* ops (1 year ago) <Timo Paulssen> 01:52
oof, haha
one year already
MasterDuke heh. i have some old PRs still open(ish) 01:53
looks like oldest are 4 years old. should probably close them 01:54
timo feed them, clothe them, do whatever it takes to give them a good life 02:20
02:21 frost joined
MasterDuke closed the oldest, next oldest i've actually done some recent work with on the desktop (guess i haven't pushed it though) 02:23
but ugh, not making any progress with this current exploration. adding `.node($/)`s and `QAST::Stmts.new(<...>)`s all over the place, but no change so far 02:24
02:32 frost left 03:07 Kaiepi joined 03:08 Kaipi left 05:57 evalable6 left, bisectable6 left, nativecallable6 left, releasable6 left, quotable6 left, linkable6 left, squashable6 left, coverable6 left, greppable6 left, benchable6 left, statisfiable6 left, unicodable6 left, committable6 left, tellable6 left, sourceable6 left, shareable6 left, notable6 left, reportable6 left, bloatable6 left, reportable6 joined, evalable6 joined 05:58 releasable6 joined, notable6 joined, bisectable6 joined, tellable6 joined, sourceable6 joined, nativecallable6 joined, greppable6 joined, coverable6 joined, squashable6 joined 05:59 bloatable6 joined, committable6 joined, statisfiable6 joined, unicodable6 joined 06:00 linkable6 joined, shareable6 joined, quotable6 joined, benchable6 joined 06:02 reportable6 left 06:04 reportable6 joined 07:08 patrickb joined 07:22 Kaiepi left 07:23 Kaiepi joined 07:54 brrt joined
brrt \o 07:55
tellable6 2021-07-14T08:56:16Z #moarvm <Nicholas> brrt Good *, brrt. colabti.org/irclogger/irclogger_lo...1-07-14#l8
Nicholas o/
and it's pure chance that I'm here when you arrived
and I'd forgotten that question from $other 07:56
you missed - a lot of new-disp progress
jnthn was on a roll
brrt jnthn++ :-)
actually, that's not the nickname here 07:57
ehm, I think there might've been a silly thing for that actually
08:26 Kaiepi left 08:31 Kaiepi joined 08:32 brrt left 09:20 Kaiepi left
lizmat perhaps also interesting for the people here: github.com/rakudo/rakudo/issues/4456 09:22
Label lost with spesh enabled
09:22 frost joined 09:23 Kaiepi joined 10:23 evalable6 left, linkable6 left 10:25 evalable6 joined, linkable6 joined 10:27 Kaiepi left, Kaiepi joined 10:32 sena_kun joined
sena_kun re blin for new-disp: spec tests aside, it's a must for the `make install` to work (AFAIK it doesn't work yet now?) to test the branch. 10:38
nine sena_kun: make install already works 10:41
sena_kun nine, oh, great! I'll do a run today in a couple of hours (just started the release one) 10:42
Geth MoarVM/hash-fsck-fixes: 8b36d1230b | (Nicholas Clark)++ | src/core/str_hash_table.c
Fix another bug in MVM_str_hash_fsck().

Calling `MVM_str_hash_entries` when just the control structure was allocated
  (the empty hash optimisation) would trigger an assertion failure.
We need to check `control->cur_items` and `control->max_items` explicitly. It also makes sense to check for `control` being NULL and handling that case
  (instead of segfaulting).		 10:53
MoarVM: nwc10++ created pull request #1514:
Fix another bug in MVM_str_hash_fsck().
11:05 Kaiepi left 11:07 Kaiepi joined 12:02 reportable6 left 12:05 reportable6 joined 12:16 patrickb left 12:21 patrickb joined
Geth MoarVM: 1180c98820 | (Stefan Seifert)++ | src/core/bytecodedump.c
Fix read buffer overflow in bytecode dumper

The append_string function relied on the target buffer being calloced, so any strings we copied into it would automatically get a trailing \0. However, when the buffer became too small, we realloced it without zeroing the extension. This resulted in reading past the buffer when actually printing the result string.
Fix by just appending that \0 manually whenever we append a string. This also fixes the unsafe use of vsnprintf which caused us to read past the line buffer when a line exceeded the maximum allowed length.		 12:33
13:06 frost left 13:12 Util_ joined 13:13 jdv_ joined 13:15 [Coke]_ joined 13:18 [Coke] left, Util left, jdv left
sena_kun Commit exists, but an executable could not be built for it 13:48
that's info for github.com/rakudo/rakudo/commit/43...86a1b564a4 13:49
nine ? 13:50
sena_kun nine, that's what blin says
I'll look at it later, $dayjob time 13:51
nine jnthnwrthngtn: Turns out you did break reproducible build. But that was 2 years agon in github.com/Raku/nqp/commit/d97f308...a82b173b70 :D 13:54
jnthnwrthngtn nine: Ahread of my time, I guess. :P But hm, is that the same issue that causes it to fail now? 14:04
nine Unfortunately no. Looks like NQP is OK now with my fix though. So it must be something in Rakudo itself 14:05
jnthnwrthngtn I think at some point you did some fixes so that anything that is compiled while compiling gets incorporated into the enclsoing compunit to fix EVAL at BEGIN time, and I wonder if the stuff I'm compiling is accidentally getting lumped in with that? 14:06
nine The most notable differences are strings that look like "104733760" 14:11
jnthnwrthngtn In case you missed me mentioning this: it was passing, and I broke it with ded9a561417e 14:16
Though that implies there was a problem anyway, just a hidden one
14:17 linkable6 left, linkable6 joined
jnthnwrthngtn I'm not sure how the logic in !produce-reader could lead to that; those numbers are too big to be cuids of the generated blocks... 14:17
sena_kun ok, I know why new-disp branch cannot be built: one needs to bump the thing so that the correct versions were taken (right now it tries to build with moarvm from master and so fails). 14:29
I am not sure how to properly make it work from branches, though, I suspect putting just the branch name into the revision is not the way. 14:30
14:35 vrurg_ joined 14:36 vrurg left
nine jnthnwrthngtn: fun fact: the ProxyReaderFactory is not even used during reproducible-builds.t 14:38
jnthnwrthngtn o.O
By code in the test maybe not, but I think during startup (CORE.setting init) it is used... 14:39
sena_kun as I thought, revision templates have no idea about branches 14:40
nine jnthnwrthngtn: well, this patch makes the problem go away (note line 10) gist.github.com/niner/2c0700ac42d5...03de1e69f7 14:41
Oh, wait, that should be nqp::die. How does it even survive this?! 14:44
14:50 vrurg_ is now known as vrurg
jnthnwrthngtn nine: That's just a revert of the PR I pointed at? 14:52
Plus some error code that won't be reached
(because if we pre-fill the readers then we never need to produce them for any cases that you're likely hitting) 14:53
We can't just pre-define them because then they're not marked as thunks and that causes other failures
nine jnthnwrthngtn: no, I also added a die; in method new. Which in NQP can't work and seems to have been ignored. 14:56
jnthnwrthngtn I don't think it does listops, so it'll have interpreted it as a term 14:57
And it doesn't seem to bail over those 14:58
die() likely woulda whined
nine It seems to be this entry that does the trick: '1%0,', -> $a1, *%n { nqp::dispatch('boot-resume', 6, nqp::decont($a1), |%n) } 15:03
The other's don't make a difference
Because 1%0 is the only key that's in use 15:11
jnthnwrthngtn Possibly, yes; a bunch of them I added to cover unary/binary ops 15:38
If the code in question never passed a Proxy to such an op then they'd not be used
The original idea was to prime the hash with a few such cases so we'd not need to go and eval a QAST tree for them 15:39
But that doesn't work out, because there's no way to get them marked as a thunk
Thus why I dropped everything in the hash and relied on always going through the generation pass
Thus why I dropped everything in the hash and relied on always going through the generation pass 15:40
And it's going through that which seems to trip things up
nine Yeah, the Proxy in question is CompUnit::RepositoryRegistry's short-id2class 15:45
jnthnwrthngtn Yes, I was a little surprised to find myself having to handle multi dispatch over Proxy so relatively early on 15:52
Had to do it at some point though :)
Geth MoarVM/new-disp: 375b818094 | (Jonathan Worthington)++ | src/core/callstack.c
Fix exception handling situation with dispatchers

If we have:
  * A dispatch with a catch handler around the dispatch instruction
  * A dispatcher written in bytecode that calls...
  * A dispatcher written in C that throws
Then we need to make sure that the interpreter's current address is sync'd up before we run the dispatcher written in C, otherwise the catch handler will be missed. This kind of sandwich hasn't come up much before, thus this case was missed.		 15:54
MoarVM/new-disp: e1df16065a | (Jonathan Worthington)++ | 5 files
Reinstate per-language method not found handling

Add a dispatcher that language dispatchers can defer to in order that the *calling* language's method not found handler is used. This is not quite backward compatible with the current solution, since now the method not found handler also receives the arguments. We'll call it a new feature.
jnthnwrthngtn With those MoarVM commits and the NQP ones I just did, we should now enjoy clean `make test` in NQP. 15:56
dogbert11 jnthnwrthngtn++, seems you got a few minutes for new-disp today as well :) 15:57
sena_kun jnthnwrthngtn++ 15:58
jnthnwrthngtn Head wasn't in the right place for figuring out new stuff on $other-project post-vaccination, so figured I'd work on some easy-ish things that needed stuff I've been looking at recently :) 15:59
dogbert11 have been subjected to dose 2 then? 16:00
*have you been ...
jnthnwrthngtn Yes 16:03
nine I don't see how just compiling that one block can lead to such massive differences. And it is compilation that throws in the wrench here. Even if we return the hard coded block, it still fails.
jnthnwrthngtn Yeah, that's how it looked to me (although I didn't do the analysis you have to rule out other possibilities) 16:04
nine Small discrepancies I could understand, but the diff is massive
sena_kun confirms nqp tests are fixes, 2 files left for rakudo ones
jnthnwrthngtn Where did the EVAL-at-BEGIN-time fix get integrated with the compilation pipeline?
Though I'm starting it from the QAST step so hmm 16:05
Yay, fixing that method not found thing up didn't just get us NQP tests clean, but also gained one more spectest 16:08
Presumably one of the "wrong kind of exception" ones dogbert11++ mentioned yesterday
nine jnthnwrthngtn: that'd be github.com/Raku/nqp/commit/be58f80...6cd1322cd4 github.com/Raku/nqp/commit/f18e017...094391089a and github.com/rakudo/rakudo/commit/53...b18c331b79 16:09
16:09 patrickb left
nine Another bit: it's this call: nqp::getcomp('Raku').compile($block, :from<optimize>); So just creating test QAST::Block object is harmless 16:10
jnthnwrthngtn I suspect integration/advent2011-day07.t 16:12
is the one I have the best chance of solving with my remaining energy today
It needs nqp::can to compile into some kind of dispatcher
I was sort of inclined to kill off findmethod and tryfindmethod entirely, but it's probably better to just have them delegate to the dispatcher stuff. 16:14
heh, it looks like a non-trivial amount of nqp::findmethod usage in Rakudo is working around the fact that NQP doesn't have $obj.Qualified::meth() 16:16
If we implemented that we could probably be rid of > 50% of it 16:17
greppable6: findmethod
greppable6 jnthnwrthngtn, 16 lines, 13 modules: gist.github.com/4ce10c9f8556210e74...3d7046c535
jnthnwrthngtn 13 modules that I won't break also 16:18
Though looking at what a few of them are doing, this is only a stay of execution until RakuAST takes them out
nine: The description of github.com/Raku/nqp/commit/f18e017...094391089a makes we wonder a bit 16:21
If we treat the compilation of the QAST as a nested compile, then is github.com/Raku/nqp/commit/f18e017...2bb027R387 happening? 16:22
16:25 dogbert17 joined 16:27 dogbert11 left 16:32 dogbert11 joined 16:34 dogbert17 left 16:39 patrickb joined
nine jnthnwrthngtn: yes, we're certainly on the right track there. This successfully works around the issue: gist.github.com/niner/1d0bb550f9fb...8c4747a867 16:49
I.e. turning it into a non-nested compilation
jnthnwrthngtn Ah, nice 16:55
I wonder if just declaring an empty `my %*COMPILING` would also
nine Already compiling just that :)
jnthnwrthngtn :) 16:56
nine And of course it does
jnthnwrthngtn Urgh, I suddenly feel very tired. Will continue the can/findmethod/tryfindmethod transition later
nine++ # figuring out the penultimate `make test` failure 16:57
bbia
*bbiab
nine Still this doesn't explain the differences between compilation runs though. Even if the compiled frame makes it into the bytecode file, so what? It should always be exactly the same one.
nine likes his computers to be mostly deterministic 16:58
jnthnwrthngtn nine: I don't know, but I didn't give the block a cuid, maybe it synthesizes a filename or compunit name, or something?
Or those sneak in somehow
nine Further research is needed :D 16:59
jnthnwrthngtn :)
jnthnwrthngtn really wanders afk
MasterDuke jnthnwrthngtn, et al.: gist.github.com/MasterDuke17/93d06...81c13cba1b does cause a minor change in the output of `raku --ll-exception -e 'grammar G { token TOP { $<foo>=(<xxx>) } }; G.parse("x")'` 17:05
from <unknown>:1 (<ephemeral file>:)
from -e:1 (<ephemeral file>:TOP)
becomes
from -e:1 (<ephemeral file>:) 17:06
from -e:1 (<ephemeral file>:TOP)
so it looks like it picks up the '-e', but still not the 'xxx'
timo: what was your example to try? 17:11
17:12 sena_kun left 17:13 patrickb left
timo for getting the lack of names? i think it was just a random piece of nqp code from either nqp build or rakudo build 17:14
17:15 patrickb joined 17:27 Kaiepi left 17:32 Kaiepi joined, Kaiepi left 17:33 [Coke]_ is now known as [Coke] 17:36 Kaiepi joined 17:38 Kaipi joined 17:39 Kaiepi left
MasterDuke ah 18:00
18:02 reportable6 left
dogbert11 nine: interested in fixing a spesh related problem in new-disp? 18:04
18:05 reportable6 joined 18:17 dogbert11 left, dogbert17 joined 18:33 dogbert11 joined 18:36 dogbert17 left 18:41 dogbert11 left
nine Interested sure, but I'm still busy with the reproducibility issue :) 18:48
18:50 dogbert11 joined 18:56 dogbert11 left 18:57 dogbert11 left 18:59 dogbert11 joined
nine So, on the two compilation runs in the test we actually write back exactly the same frames to the outer compilation in the same order. Still we end up with those vast discrepancies 19:01
19:03 jdv_ is now known as jdv
MasterDuke huh 19:03
nine Well the answer to that is that it's not the actual writing back that creates the issue 19:06
19:08 squashable6 left
MasterDuke reading then? 19:08
19:09 squashable6 joined
nine No, more that it's about other shared data 19:17
MasterDuke somewhat a change of topic, but that patch i linked earlier gives one (i think new) passing TODO in t/spec/S32-exceptions/misc2.rakudo.moar and one fail in t/spec/S02-lexical-conventions/comments.t 19:21
the fail is getting an X::Syntax::Comment::Embedded instead of an X::Syntax::Confused 19:23
for `Subtest: no spaces allowed between '#`' and '<'`
m: dd EVAL "3 * #`\n<invalid comment> 2" 19:24
camelia 5===SORRY!5=== Error while compiling /home/camelia/EVAL_0
Two terms in a row
at /home/camelia/EVAL_0:2
------> 3<invalid comment>7⏏5 2
expecting any of:
infix
infix stopper
statement end
st…
MasterDuke the passing TODO is also about X::Syntax::Comment::Embedded 19:25
jnthnwrthngtn MasterDuke: I wouldn't expect the `xxx` in the backtrace; the file and (probably accurate rather than always "1") line number is already good 19:27
MasterDuke yeah, if i put it in a file spread over a couple lines it give the right line number 19:28
jnthnwrthngtn yay
dogbert11: A spesh-related problem in new-disp? I didn't think it managed to spesh much of anything at the moment :)
MasterDuke m: EVAL "#`"; CATCH { default { dd } } # this is the new fail 19:29
camelia ( no output )
MasterDuke m: EVAL "3 * #`\n<invalid comment> 2"; CATCH { default { dd $_ } } # this is the new passing TODO
camelia X::Syntax::Confused.new(reason => "Two terms in a row", filename => "/home/camelia/EVAL_0", pos => 25, line => 2, column => Any, modules => [], is-compile-time => 1, pre => "<invalid comment>", post => " 2", highexpect => ["infix", "infix stopper", "s…
MasterDuke m: EVAL "#`"; CATCH { default { dd $_ } } # this is the new fail
camelia ( no output )
MasterDuke i have no idea if the failing test is correct or not 19:30
i have no idea if the failing test is correct or not 19:31
github.com/Raku/roast/blob/master/...#L187-L191 19:32
github.com/Raku/roast/blob/master/....t#L74-L76 19:34
oh, i had them backwards above. EVAL "#`" now correctly throws. EVAL "3 * #`\n<invalid comment> 2" now throws X::Syntax::Comment::Embedded instead of X::Syntax::Confused 19:36
nine So! It is just about %*COMPILING<moar><mast_frames>. Everything else can stay shared. 19:39
This is...quite weird as mast_frames is just a lookup hash to get a MAST::Frame by cuid.
dogbert11 jnthnwrthngtn: MVM_SPESH_BLOCKING=1 MVM_SPESH_NODELAY=1 ./rakudo-m -Ilib -MTest -e 'is do { [+] grep * %% 2, (1, 2, *+* ...^ * > 4_000_000) }, 4613732, "fibonacci"'
jnthnwrthngtn dogbert11: This is distinct to new-disp, not on master also? 19:40
dogbert11 on master I don't see it 19:41
MasterDuke don't see it here either 19:43
jnthnwrthngtn Curious. I can repro it 19:44
I'd just not expect very much to be being specialized at all at the moment
dogbert11 it still fails for me with inlining, osr and pea disabled but the problem vanishes with MVM_SPESH_DISABLE=1 19:45
nine I've added debug output in every places that accesses the moar_frames hash and the usage pattern is exactly the same between runs and regardless of whether it's shared or not. 20:06
Err... mast_frames hash 20:08
20:09 evalable6 left, linkable6 left 20:10 evalable6 joined 20:12 linkable6 joined 22:24 dogbert17 joined 22:28 dogbert11 left 22:34 dogbert11 joined 22:36 squashable6 left, dogbert17 left 22:39 squashable6 joined
Geth MoarVM/new-disp: 07f6ddd73b | (Jonathan Worthington)++ | 5 files
Introduce lang-find-meth

This dispatcher will be used to implement `can`, `findmethod`, and
  `tryfindmethod`. As with the other lang-* dispatchers, languages can
plug in their own versions of them.		 22:44
22:46 patrickb left 22:48 linkable6 left 22:49 linkable6 joined 23:27 sortiz joined 23:30 sortiz left
[Coke] tries a sour monkey sour tripel and ... meh 23:34
23:54 Merfont joined, Kaipi left

Powered by Cro and the Raku® Programming Language.

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

Thank you!