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.
nine vrurg: two chained method calls requires resumption in new-disp. There are examples starting at github.com/Raku/nqp/blob/master/t/...tch.t#L341 07:14
Nicholas good *, * 07:15
Geth MoarVM/submodule-default-shallow-clone: 6ad88ac6af | (Nicholas Clark)++ | .gitmodules
Change .gitmodules to default submodules to a shallow clone.

The git documentation implies that this is the "right" way to do this, but as best I can tell from experimenting this *only* affects
  `git clone --recursive`
  `git clone` followed by `git submodule update --init --recommend-shallow`
... (6 more lines)		 12:15
MoarVM/submodule-default-shallow-clone: 6f749f3ac0 | (Nicholas Clark)++ | tools/update-submodules.pl
Run `git submodule --quiet update --depth 1` if git is new enough.

This reduces .git by about 32M at little cost, as most folks aren't looking at submodule history. If you need the history, it's easy to get back with:
git submodule foreach git fetch --unshallow
lizmat nine: now that new-disp has landed, would it make sense to re-investigate the "in process" pre-compilation work ? 12:41
jnthnwrthngtn I'm not sure how far new-disp would help with that, tbh 12:59
Trying to do it as part of the new RakuAST-baesd compiler frontend might be more fruitful 13:00
lizmat the thing is: I was thinking on how to solve "default auth / ver / api" for loading modules without specific ver / auth / api 13:04
and thought: well, a dynamic variable keeping the default ver/auth/api info might just do the trick
until I realized: meh, separate processes
nine Well the method cache was one large source of problems. That's gone now. 13:19
lizmat right! 13:25
Geth MoarVM: 2883ba7547 | (Stefan Seifert)++ | src/spesh/deopt.c
Fix possible access to fromspace after deopt materialization

We stored the newly allocated objects we create during materialization in an array, for future reference so we could store the same objects into multiple target registers if required. Allocating these objects however could trigger a GC run which then missed the pointers in the materialized array. This would then lead to such outdated pointers getting written to frame registers. ... (7 more lines)		 13:26
MoarVM: 3ef0c229d2 | niner++ (committed using GitHub Web editor) | src/spesh/deopt.c
Merge pull request #1630 from MoarVM/fix_gc_issue_in_materialization

Fix possible access to fromspace after deopt materialization
vrurg nine: I thought of resumption, but it requires initiation on the callee side. That's not possible in case of .ACCEPTS.Bool. Not to mention if there be any performance gain at all then. 14:22
jnthnwrthngtn vrurg: Have the dispatch program evaluate to calling something that in turn calls the two methods? I figure something so small as to do two method calls will neatly inline if it's hot 14:24
vrurg jnthnwrthngtn: thanks, that's was my next question, actually. :) 14:25
Though would there be a way to inline explicitly, without delegating to a frame, that'd be even better. But it seems there is no way to compile a non-block root QAST node anyway. 14:29
jnthnwrthngtn No, frames (QAST::Block) are the smallest unit you can give to the VM to execute 14:38
Given inlining is *already* really complex, I don't think we want to have to support two kinds of it :-) 14:39
Geth MoarVM/submodule-default-shallow-clone: 0c45973a58 | (Nicholas Clark)++ | 2 files
Run `git submodule --quiet update --depth 1` if git is new enough.

This reduces .git by about 32M at little cost, as most folks aren't looking at submodule history. If you need the history, it's easy to get back with:
git submodule foreach git fetch --unshallow		 14:54
vrurg Does existence of a lexical $_ in a frame affects its inlinability? 16:10
lizmat doesn't every frame have a $_ ?
and ergo, the answer is no? 16:11
vrurg On many occasions it is lowered to a local. 16:12
I wonder what if it stays lexical.
vrurg is considering if it worth replacing locallifetime op with a dispatch delegating to a block. 16:13
afk for a couple of hours. 16:15
jnthnwrthngtn No, lexicals don't prevent MoarVM from doing inlining. Lowering to locals makes some other optimizations possible. 16:20
But inlining isn't blocked by it
locallifetime is a code-gen hint; I don't think it should introduce a scope
s/scope/blcok/ 16:21
It should have no semantic effects, it just allows for better register re-use
Geth MoarVM/fix_unsigned_for_merge: 6 commits pushed by (Stefan Seifert)++ 17:50
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2022/01/10/2022-...-perching/ 18:46
nine What a busy week in the Core. lizmat++ for the write up! 18:50
lizmat well, actually 2 weeks :-) 18:56
sena_kun lizmat++ 18:58
MasterDuke m: sub a(|c(Int $b, Str $c? = "bar")) { b(|c) }; sub b(*@v) { .say for @v }; a(1, "bc"); a(2)   # any way to get "bar" to be printed the second time a() is called? or is that just not possible? 21:13
camelia 1
bc
2
jnthnwrthngtn MasterDuke: Not possible; c is the original incoming argument capture, which you unpack; unpacking the capture does not, however, mutate it 21:19
MasterDuke could that be a warning or error? 21:25
jnthnwrthngtn No 21:29
Well, it could be, but given it might be exactly what was wanted, it shouldn't be
MasterDuke m: sub a(|c(Int $b, Str $c? = "bar")) { my $z = (|c).Array; $z.push($c) if c.elems == 1; b(|$z) }; sub b(*@v) { .say for @v }; a(1, "bc"); a(2)    # yeah, this works as a workaround, maybe a warning is a little aggresive 21:30
camelia 1
bc
2
bar
jnthnwrthngtn Why the capture in the first place? 21:44
I mean, I'd just write sub a(Int $b, Str $c = "bar" { b($b, $c) } 21:45
uh, with the ) that I missed
MasterDuke the request was to not have to repeat the list of arguments 21:46
the capture+subsignature made it so you could constrain the parameters, but not have to repeat them when passing them on 21:47

Powered by Cro and the Raku® Programming Language.

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

Thank you!