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 "into native integer" sounds like it's trying to write into a native _signed_ int. That's why it thinks the value is too large 06:58
nine 423! 08:17
I think commits like github.com/rakudo/rakudo/commit/ae...e9d6f8af2d why it's so much more joy to implement features in RakuAST than it was on the old compiler frontend. Good luck with even finding all the bits of sub-signature support in the latter. 08:18
nine LOL RakuAST does crazy things like sub signature declarations and auto generated protos, but then stumbles over a basic %h<foo>:exists. 12:08
Though to be fair, that looks far more innocent than it is.
lizmat indeed: I remember Larry telling that parsing that was really breaking "only parse once" rule 12:09
nine It's also one of the few features where I really don't understand what they are there for. Why go to all the trouble, complicating the compiler, when a simple %h.has-key('foo') would have been just as good and not introduce this weird special syntax for passing named args? 12:11
How many Raku programmers won't see %h<foo>:exist as anything but some special magic syntax? 12:12
lizmat %h.EXISTS-KEY("foo") 12:15
works
fwiw, I think the power of :adv only comes into play with slices
m: my %h = :42a, :666b; dd %h<a b>:p 12:16
camelia (:a(42), :b(666))
jnthn Ah, operator adverbs... They're parsed as fake infixes and then re-arranged, iirc. 13:00
Don't believe they violate one-pass parsing though 13:01
They're just an annoyance when constructing expression ASTs
lizmat well, I knew there was something tricky there, as I remember it taking Larry a long time to come up with that solution 13:15
Nicholas I've seen this SEGV twice now: gist.github.com/nwc10/797b7e49d17a...faa32dcd1e 13:30
can't reliably reproduce
nine Well, that wasn't so bad after all and brought us up to 432 passing! 13:31
MasterDuke lizmat's example is calling MVM_args_get_named_int instead of MVM_args_get_named_uint 19:02
from param_on_i, obviously should be param_on_u 19:03
looks like it's happening inside a QAST::IVal 19:06
do we need a QAST::UVal?
lizmat not sure 19:09
m: class A { has int $.a = 42 }; use BUILDPLAN A 19:10
camelia class A BUILDPLAN:
0: nqp::bindattr_i(obj,A,'$!a',:$a) if possible
1: Don't know how to handle: (401, A, "\$!a", 42)
lizmat m: class A { has uint $.a = 42 }; use BUILDPLAN A
camelia class A BUILDPLAN:
0: vivify nqp::getattr(obj,A,'$!a') if part of a mixin
1: Don't know how to handle: (410, A, "\$!a", 42)
lizmat the "nqp::getattr(obj,A,'$!a')" is wrong
that should be "nqp::bindattr_u(obj,A,'$!a',:$a) if possible" 19:11
I guess BUILDPLAN will also need some TLC
will look at that tomorrow
nine ++lizmat 19:17

Powered by Cro and the Raku® Programming Language.

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

Thank you!