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:13 CaCode left, CaCode joined 00:19 patrickb left 02:02 CaCode_ joined 02:03 reportable6 joined 02:05 CaCode left 03:16 frost joined 04:14 CaCode- joined 04:16 CaCode_ left 04:43 gfldex left 04:48 gfldex joined 05:48 bloatable6 left, greppable6 left, statisfiable6 left, notable6 left, nativecallable6 left, bisectable6 left, benchable6 left, evalable6 left, committable6 left, coverable6 left, linkable6 left, committable6 joined 05:49 bisectable6 joined, coverable6 joined 05:50 nativecallable6 joined, greppable6 joined, evalable6 joined 05:51 statisfiable6 joined 06:02 reportable6 left 06:50 linkable6 joined, benchable6 joined 07:03 reportable6 joined 08:23 quotable6 left, statisfiable6 left, reportable6 left, greppable6 left, linkable6 left, coverable6 left, benchable6 left, shareable6 left, nativecallable6 left, squashable6 left, evalable6 left, sourceable6 left, releasable6 left, unicodable6 left, committable6 left, bisectable6 left, tellable6 left 08:24 squashable6 joined 08:25 greppable6 joined 08:26 bisectable6 joined, coverable6 joined, quotable6 joined, releasable6 joined
Nicholas good *able6, #moarvm 08:53
08:58 nebuchadnezzar left
lizmat :-) 09:12
09:23 committable6 joined 09:25 nativecallable6 joined, shareable6 joined 09:26 benchable6 joined, evalable6 joined 09:51 bloatable6 joined 10:48 notable6 joined 11:12 Altai-man joined
jnthnwrthngtn o/ 11:14
lizmat jnthnwrthngtn o/ 11:17
lizmat is feeling a lot less under the weather than yesterday
Nicholas \o 11:24
11:25 statisfiable6 joined 11:26 tellable6 joined, sourceable6 joined
jnthnwrthngtn Stomach better, brain still mushy. 11:36
nine Well, progress 11:40
lizmat m: class A { has uint32 $!foo = 0x0ffffffff; method bar() { say $!foo } }; A.new.bar # meh 11:43
camelia -1
lizmat seems like native uint attributes lose their unsignedness 11:44
m: class A { has uint8 $!foo = 0x0ff; method bar() { say $!foo } }; A.new.bar # shorter
camelia -1
jnthnwrthngtn lizmat: Yeah, there's an issue for that 11:45
Just got this:
MoarVM oops: MVM_str_hash_entry_size called with a stale hashtable pointer
at gen/moar/Metamodel.nqp:4834 (/home/jnthn/dev/MoarVM/install/share/perl6/lib/Perl6/Metamodel.moarvm:enum_from_value)
from SETTING::src/core.c/Enumeration.pm6:54 (/home/jnthn/dev/MoarVM/install/share/perl6/runtime/CORE.c.setting.moarvm:FROM-VALUE)
And I think I saw a Rakudo PR recently about this?
Hah, yes! github.com/rakudo/rakudo/pull/4634 11:46
11:49 Altai-man left 12:04 reportable6 joined
jnthnwrthngtn I'm so very glad to see all the QAST-y bits go away in NativeCall in github.com/rakudo/rakudo/pull/4629 12:06
I was looking at it and thinking "oh no, this could be an annoying thing to have to migrate in RakuAST" and now we won't have do :) 12:07
12:10 psydroid left, AlexDaniel left
jnthnwrthngtn OK, all new-disp nativecall PRs reviewed; nine++ 12:21
12:27 AlexDaniel joined
nine Big thank you! Will probably fix the issues you pointed out tomorrow. 12:33
12:33 psydroid joined
jnthnwrthngtn Ah, github.com/MoarVM/MoarVM/pull/1581 is still to merge 12:35
12:35 Kaipi left
jnthnwrthngtn I'd really like to see it go in a week or so before the release 12:35
12:36 Kaipi joined 12:50 psydroid left 12:51 AlexDaniel left
jnthnwrthngtn An approve \o/ 12:54
Geth MoarVM/master: 19 commits pushed by (Jonathan Worthington)++
review: github.com/MoarVM/MoarVM/compare/f...addda15faa
jnthnwrthngtn And in it goes. :)
inb4: yes, this is a good time for a bump :)
nine As anticipated, having spent significant time on this PR when we were looking for those strange errors on CI has made reviewing it much quicker
jnthnwrthngtn :) 12:55
lizmat jnthnwrthngtn: do we need to merge something in NQP as well ?
nine ? ^^ ? 12:56
nine lizmat: no 12:58
lizmat and not in rakudo either then, I assume
hmm... so what got merged into MoarVM just now then? 12:59
#1581 I guess ? 13:00
jnthnwrthngtn lizmat: Yes 13:03
It re-works how we handle returning and stack unwinding to full take advantage of the new callstack introduced in new-disp 13:04
*fully 13:05
Which allows various simplifications and thus a speedup
13:05 Altai-man joined
jnthnwrthngtn Also things using special return mechanism get to avoid malloc/free and just have state on the callstack instead, so there's a small win there also 13:05
nine And this stuff becomes easier to understand as well. Instead of special cases and branches all over the frame handling code, the callstack tells the story of what should happen when. In a sense the callstack becomes its own program. 13:09
13:24 linkable6 joined
lizmat bumped 13:24
fwiw, I got a wrong dependency messages just again 13:26
nuked the lib/.precomp and it went away 13:27
wonder whether we should provide a utility script to nuke all .precomp dirs
also, no noticeable improvement of test-t on my machine 13:28
nine thinks what we need is fixes, not better workarounds 13:29
lizmat last time I did a full .precomp nuke, it cleared about 1G in files 13:30
so there's use of such a script in other cases as well :-)
nine Same happens here. But then, we're probably recompiling rakudo more often than others recompile their raku programs 13:31
lizmat indeed :-) 13:32
jnthnwrthngtn lizmat: It's worth ~5% on a recursive fib benchmark (where the recursion implies loads of frame creation); ~2% or so is more likely on more typical applications. 13:39
And on micro-benchmarks where we overwhelmingly inline stuff, it's worth nearly nothing 13:40
lizmat yeah, I think the test-t benchmark is already pretty good at inlining
jnthnwrthngtn I saw a slight spectest time improvement from it also 13:41
lizmat makes mental note to run one tonight 13:45
13:48 Kaipi left, Kaipi joined
lizmat m: my $a = "42"; for ^1000000 { my int $b = $a.Int }; say now - INIT now 13:56
camelia 0.381197921
lizmat m: my $a = "42"; for ^1000000 { my int $b = my str $ = $a }; say now - INIT now
camelia 0.061885142
lizmat quite a difference eh?
jnthnwrthngtn I'm not even sure the second of those should compile...
m: my $a = "4.6"; say $a.Int; say (my int $ = my str $ = $a); 13:58
camelia 4
4
lizmat m: my $a = "4.6e0"; say $a.Int; say (my int $ = my str $ = $a); 13:59
camelia 4
4
jnthnwrthngtn m: my $a = ""; say $a.Int; say (my int $ = my str $ = $a); 14:00
camelia 0
0
jnthnwrthngtn m: my $a = " "; say $a.Int; say (my int $ = my str $ = $a); 14:01
camelia 0
0
14:01 frost left
jnthnwrthngtn m: my $a = "?5"; say $a.Int; say (my int $ = my str $ = $a); 14:02
camelia Cannot convert string to number: base-10 number must begin with valid digits or '.' in '3ā5?5' (indicated by ā)
in block <unit> at <tmp> line 1
jnthnwrthngtn m: my $a = chr(8722) ~ "5"; say $a.Int; say (my int $ = my str $ = $a);
camelia -5
Error encoding ASCII string: could not encode codepoint 8722
in block <unit> at <tmp> line 1
jnthnwrthngtn Ah, there's a difference :)
14:25 unicodable6 joined
timo i did not expect moarvm to become based on ROP, return-oriented programming :) 16:23
16:51 linkable6 left 16:53 linkable6 joined
dogbert17 MoarVM panic: Memory allocation failed; could not allocate 14391929568 bytes # hmm 17:41
have a suspicion that this is somehow GC-related. Here's the gist gist.github.com/dogbert17/93fc8512...ce49522baa 17:54
18:02 reportable6 left
jnthnwrthngtn #4 0x00007ffff7924e5f in MVM_spesh_alloc (tc=0x555555623ac0, g=0x7ffff3b491d0, bytes=16195990944) at src/spesh/graph.c:41 18:03
#5 0x00007ffff793f20d in analyze_phi (tc=0x555555623ac0, g=0x7ffff3b491d0, ins=0x7ffff2cf374e) at src/spesh/optimize.c:2021
That's a big phi...
I'm guessing something accidentally goes negative or similar... 18:04
dogbert17 it's relatively easy to repro by setting the nursery size to ~50k and running: while MVM_SPESH_NODELAY=1 ./rakudo-m -Ilib t/spec/S32-num/complex.t; do :; done 18:07
sometimes it fails with 'MoarVM panic: Invalid owner in item added to GC worklist' 18:08
18:23 Altai-man left
dogbert17 it's the kind of stuff Nine eats for breakfast :) 18:38
18:38 CaCode- left 18:39 CaCode- joined 18:41 CaCode- left 18:42 CaCode- joined, CaCode- is now known as CaCode 19:38 CaCode left 20:16 nebuchadnezzar joined 21:05 reportable6 joined 21:47 TempIRCLogger joined 21:49 colemanx joined 21:52 colemanx left 22:17 MasterDuke92 joined
MasterDuke92 is it just me, or is github.com/MoarVM/MoarVM/blob/mast...#L136-L205 not really taking a substring like i would expect? 22:18
i.e., it doesn't start the string `start` num of graphemes in 22:19
looks like it happened here github.com/MoarVM/MoarVM/commit/6e...b7e4a27b37 22:23
jnthnwrthngtn: ^^^ 22:24
timo i don't think it skipped the beginning before that either? 22:41
oh 22:42
there it is
do we actually ever use the function with a nonzero start value? 22:43
MasterDuke92 github.com/MoarVM/MoarVM/blob/mast...ps.c#L1759 22:46
and i came across it because i'm just trying something that passes a value for `start` to MVM_string_ascii_encode_substr and noticed it didn't seem to be doing anything 22:49