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:00 linkable6 left, evalable6 left 00:01 evalable6 joined, linkable6 joined 00:02 reportable6 left 00:03 reportable6 joined 01:03 linkable6 left 01:05 linkable6 joined 01:14 Voldenet left 01:19 Voldenet joined 02:15 Voldenet left 02:21 Voldenet joined 05:06 rba left 05:07 rba_ joined, rba_ is now known as rba 05:11 leont left 05:12 leont joined 06:02 reportable6 left 06:04 reportable6 joined 07:10 patrickb joined 07:23 Geth left, Geth joined 07:32 patrickb left 07:33 patrickb joined 09:30 Kaiepi left 10:24 Kaiepi joined 10:29 sena_kun joined 10:55 RakuIRCLogger left, RakuIRCLogger joined 11:12 frost joined 12:02 reportable6 left 12:03 reportable6 joined 12:37 frost left 13:27 sena_kun left 13:44 sena_kun joined
jnthnwrthngtn m: say "/foo/bar/baz".IO.relative("/foo") 14:32
camelia bar/baz
15:04 MasterDuke joined
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
16:04 linkable6 left, evalable6 left 16:05 evalable6 joined 16:06 linkable6 joined
MasterDuke is `0x20000` a valid value for `tc->cur_frame`? 16:22
16:33 MasterDuke left
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
17:33 linkable6 left, evalable6 left 17:35 evalable6 joined 17:36 linkable6 joined 17:38 sena_kun left 18:02 reportable6 left 18:04 MasterDuke joined
MasterDuke . 18:04
tellable6 2021-07-12T16:36:04Z #moarvm <jnthnwrthngtn> MasterDuke: no
MasterDuke jnthnwrthngtn: thanks
18:05 reportable6 joined
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
19:18 evalable6 left, linkable6 left, evalable6 joined 19:20 linkable6 joined
MasterDuke lizmat++ i always find out there's more stuff going on than i'd realized 19:26
19:36 patrickb left 20:23 Altai-man left 20:25 Altai-man joined 21:07 MasterDuke left 22:07 evalable6 left, linkable6 left 22:08 linkable6 joined 22:09 evalable6 joined 23:09 linkable6 left, evalable6 left 23:10 linkable6 joined 23:12 evalable6 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!