20 May 2022
camelia 18446744073709551615 20:29
lizmat m: class A { has uint $.a = 18446744073709551615 }
camelia ===SORRY!=== Error while compiling <tmp>
Cannot unbox 64 bit wide bigint into native integer
at <tmp>:1
lizmat m: class A { has uint $.a; method b() { $!a = 18446744073709551615 } }; say A.new.b 20:31
camelia -1
MasterDuke hm, my understanding is that directly assigning too-big values is supposed to not be allowed, but doing math that wraps around is allowed 20:33
lizmat but that's the point: the value is *not* too big for a uint 20:34
21 May 2022
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
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
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
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
22 May 2022
lizmat updated the BUILDPLAN helper module, looks like the BUILDPLAN is not the source of the problem 09:45
m: class A { has uint $.a; method b { use nqp; nqp::bindattr_u(self,A,q/$!a/,9223372036854775808) } }; dd A.new.b 10:01
camelia -9223372036854775808
lizmat nine: looks like at least nqp::bindattr_u is not doing the right thing 10:02
tracing this back to NQP, looks like something's amiss with that in MoarVM ? 10:03
I just noticed that MoarVM doesn't have a MVM_nativeref_read_lex_u ? 10:06
specifically at: github.com/MoarVM/MoarVM/blob/mast...ers.c#L729 10:07
and then it really becomes above my pay grade :-) 10:09
or maybe it's just nqp::getattr_u that's to blame 11:11
the ContainerDescriptor also looks ok 12:12
lizmat gives up for now 12:16
nine I'm not sure we'd need a MVM_nativeref_read_lex_u 20:20