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.
jnthnwrthngtn m: say "/foo/bar/baz".IO.relative("/foo") 14:32
camelia bar/baz
MasterDuke timo: did you find anything new with the `($_ = "a: " until .Str) andthen .Str ` segv? 15:06
i think the segv is a bug, but is the infinite recursion a bug also? 15:07
or is that the expected/correct behavior from rakudo?
m: ($_ = "a: " until .Str); .say 15:11
camelia Use of uninitialized value $_ of type Any in string context.
Methods .^name, .raku, .gist, or .say can be used to stringify it to something meaningful.
a:
in block <unit> at <tmp> line 1
MasterDuke m: ($_ = "a: " until True); .say 15:13
camelia (Any)
MasterDuke m: say "a: " until True 15:14
camelia ( no output )
MasterDuke i guess that's correct? `until` is not the same as a `do while`? 15:17
lizmat until foo is the same as while !foo ? 15:21
MasterDuke i'm blanking, what's our `do while`? 15:25
i.e., unconditionally run body once, then check conditional for whether to run again 15:26
doh, `repeat` 15:28
m: repeat { say "a: " } until True 15:29
camelia a:
MasterDuke m: (repeat { $_ = "a: " } until .Str) andthen .Str 15:32
camelia Cannot assign to an immutable value
in block at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat m: my $a; say do while ++$a < 10 { $a } 15:38
camelia (1 2 3 4 5 6 7 8 9)
lizmat it basically turns the while loop into a .map
m: my $a; say do while ++$a < 10 { chr($a + 64) } 15:39
camelia (A B C D E F G H I)
MasterDuke you've been working on looping and iteration and such, any opinion on whether the infinite recursion is a bug or correct? 15:41
lizmat feels like a bug to me
probably in codegen 15:42
MasterDuke so two bugs then. the rakudo infinite recursion and the moarvm segv
MasterDuke is `0x20000` a valid value for `tc->cur_frame`? 16:22
Geth MoarVM/new-disp: c7796fdc83 | (Jonathan Worthington)++ | 4 files
Provide for extracting args from an MVMCapture

Which is useful when we need to convert it into a Raku Capture for the sake of error reporting.
16:35
jnthnwrthngtn MasterDuke: no 16:36
tellable6 jnthnwrthngtn, I'll pass your message to MasterDuke
jnthnwrthngtn The latest reason `use Test` fails with new-disp is because I didn't do multi dispatch Junction failover yet, and we actually depend on that in the module loading code :) 16:38
lizmat ah? 16:46
isn't that, eh... "expensive" ? 16:47
jnthnwrthngtn I dunno how hot it is, tbh 16:48
lizmat well, we're talking about Rakudo, right, as NQP doesn't have junctions 16:54
jnthnwrthngtn Yes 17:02
tbrowder howdy. does MoarVM get a Coverity or other similar scan periodically? 17:07
timo coverity yes, but not periodically 17:10
jnthnwrthngtn Alrighty, junction auto-threading failover for multi dispatch done in the new dispatcher. The next blowup is from me not having killed of smart stringify / smart numify in MoarVM in favor of the dispatcher. 17:28
*off
More special-case ops go bye bye. But for now it's hometime.
timo you can have your very own hometimo if you like! 17:30
MasterDuke . 18:04
tellable6 2021-07-12T16:36:04Z #moarvm <jnthnwrthngtn> MasterDuke: no
MasterDuke jnthnwrthngtn: thanks
MasterDuke so in the example from above, the first write to tc->curframe is 0x0, then 0x20000, then 0x0 18:06
it gets set to 0x20000 by `val->cur_info = info;` at read_op (val=0x7ffc7876cab0) at src/core/validation.c:171 18:07
and since cur_info is a MVMOpInfo, that seems horribly wrong 18:15
(rr) p *info 18:19
$10 = {opcode = 597, name = 0x7f6f21eecb10 "const_i64_16", num_operands = 2, pure = 1 '\001', deopt_point = 0 '\000', may_cause_deopt = 0 '\000', logged = 0 '\000', no_inline = 0 '\000', jittivity = 0 '\000', 18:20
uses_hll = 0 '\000', specializable = 0 '\000', operands = "\"\020\000\000\000\000\000"}
so i assume 0x20000 comes from the info->operands
so tc->cur_frame is 0x0, somehow it gets overwritten when a Validator is created and its fields are set 18:22
i'm going to blame being on vacation if this next question is nonsensical, but does this mean there's a missing MVMROOT of tc->cur_frame somewhere and the gc moved it when it shouldn't have? 18:25
hm, but this is also somehow related to spesh inlining, because disabling that fixes the segv
lizmat And another Rakudo Weekly News hits the Net: rakudoweekly.blog/2021/07/12/2021-...splitting/ 18:50
MasterDuke lizmat++ i always find out there's more stuff going on than i'd realized 19:26