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:08 reportable6 left 00:25 frost joined 00:37 frost left 00:49 Kaiepi joined 00:50 frost joined 00:54 Kaiepi left 01:04 linkable6 left 01:08 reportable6 joined 01:18 frost left 02:04 frost joined 02:29 frost left 02:37 frost joined 02:50 frost left 02:54 frost joined 03:24 frost left 03:41 Kaiepi joined 04:29 shinto joined 05:06 linkable6 joined 05:26 shinto left 06:07 reportable6 left 06:09 reportable6 joined
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
07:36 frost joined 08:02 frost left 08:09 Kaiepi left, [Coke] left, japhb left, sena_kun left, MasterDuke left 08:10 TempIRCLogger__ joined 08:11 RakuIRCLogger left, RakuIRCLogger joined 08:12 TempIRCLogger left 08:14 TempIRCLogger__ left 08:20 TempIRCLogger joined, Kaiepi joined, [Coke] joined, japhb joined, sena_kun joined, Techcable joined, MasterDuke joined, camelia joined, nine joined, Geth joined, bartolin joined, leedo joined, ugexe joined, moon-child joined, SmokeMachine joined, nebuchadnezzar joined, leont joined, jnthnwrthngtn joined, rba joined 08:23 RakuIRCLogger left, RakuIRCLogger joined 08:27 RakuIRCLogger left, RakuIRCLogger joined 08:53 frost joined 09:49 frost left 11:00 frost joined 11:25 frost left 11:41 Altai-man joined 11:43 Altai-man left 11:55 Altai-man joined 12:08 reportable6 left 12:09 reportable6 joined
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
15:15 Altai-man left
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
18:08 reportable6 left 18:09 reportable6 joined
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
19:12 linkable6 left, evalable6 left 20:13 linkable6 joined, evalable6 joined
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
21:16 Guest1244 joined
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
21:58 Guest1244 left 23:34 CaCode 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!