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.
Nicholas good *, * 07:12
timo good -> $a, $b { $a, $b } 09:53
moon-child good { $^a, $^b } 09:55
lizmat good *,* ? 10:26
meh
japhb lizmat: Kinda looks like an owl face 15:28
lizmat :-)
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2021/11/29/2021-...sdem-2022/ 18:33
lizmat m: my str $a; BEGIN { $a = "foo" } # is this a known issue ? 19:14
camelia 5===SORRY!5=== Error while compiling <tmp>
An exception occurred while evaluating a BEGIN
at <tmp>:1
Exception details:
5===SORRY!5=== Error while compiling
Lexical with name '$a' has wrong type. real type 8 wanted type 7
at…
lizmat m: BEGIN my str $a = "foo" # golf 19:15
camelia 5===SORRY!5=== Error while compiling <tmp>
An exception occurred while evaluating a BEGIN
at <tmp>:1
Exception details:
5===SORRY!5=== Error while compiling
Lexical with name '$a' has wrong type. real type 8 wanted type 7
at…
lizmat m: my str constant $a = "foo"; dd $a # this appears ok
camelia "foo"
lizmat also strange: 19:34
m: my %h := BEGIN { my %m is Map = a => 42, b => 666 }; BEGIN { dd %h.keys }; dd %h
camelia ().Seq
Map.new((:a(42),:b(666)))
lizmat so one BEGIN time is not another ?
ugexe i was thinking it would have to be `BEGIN my %h := ...` but that doesn't do what i expect either 19:50
m: BEGIN my %h = my %m is Map = a => 42, b => 666; BEGIN { dd %h.keys }; dd %h.keys 19:55
camelia ("a", "b").Seq
("a", "b").Seq
ugexe assignment worked though 19:56
lizmat yeah, but that just makes %h a Hash
mutable and all
jnthnwrthngtn lizmat: BEGIN-time bindings aren't preserved, only assignments (and native assignment is effectively binding, or more to the point, there's no container) 22:09
japhb jnthnwrthngtn: Why aren't BEGIN-time bindings preserved? 22:11
jnthnwrthngtn The lexical scope surrounding the BEGIN isn't compiled at the time the BEGIN block is, so we have to fake it up, and we don't cheat hard enough to preserve bindings, just hard enough that the "prototype" container is preserved 22:28
japhb Ah interesting 22:30
jnthnwrthngtn I suspect RakuAST will take a different approach to all of this
japhb Is PEA or RakuAST first on your agenda for the new year? 22:31
jnthnwrthngtn I don't think it's impossible to make it work (and don't doubt it ideally would work), just wouldn't fancy doing it on the current compiler architecture :)
japhb Gotcah
*Gotcha
(Gattica?)
jnthnwrthngtn Probably a bit of both, though I suspect PEA will be the one that finishes first :)
Plan to do the re-work of LEAVE-time ahead of either of those (though hoping to do that in December) 22:32
japhb What will that rework gain us? 22:34
jnthnwrthngtn Much cheaper LEAVE handling, removal of some icky scope hackery, and hopefully a fix for a long-standing bug where return values get messed up sometimes when using LEAVE blocks 22:44
While one may not directly use LEAVE very much, it is used in Lock and Lock::Async, for example 22:45
japhb Oh, and that's definitely going to end up used a lot in concurrent code (often implicitly, I suspect). 23:18

Powered by Cro and the Raku® Programming Language.

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

Thank you!