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 | |
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 | |
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 |