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