On Wed Mar 23 04:40:54 2016, [email protected] wrote: > Commit 93d597f unveiled the following inconsistency between nqp-j and > nqp-m: > > 11:36 <psch> nqp-m: say(nqp::elems(nqp::what(nqp::list_s))) > 11:36 <camelia> nqp-moarvm: OUTPUT«-4294967287» > > $ ./nqp-j -e'say(nqp::elems(nqp::what(nqp::list_s)))' > org.perl6.nqp.sixmodel.TypeObject$AggregateRTE: Cannot do aggregate > operation on a type object > in <mainline> (-e:1) > in eval (gen/jvm/stage2/NQPHLL.nqp:1198) > in (gen/jvm/stage2/NQPHLL.nqp:1288) > in command_eval (gen/jvm/stage2/NQPHLL.nqp:1285) > in command_line (gen/jvm/stage2/NQPHLL.nqp:1269) > in MAIN (gen/jvm/stage2/NQP.nqp:4131) > in <mainline> (gen/jvm/stage2/NQP.nqp:4127) > in (gen/jvm/stage2/NQP.nqp) > > Note that the specific Exception thrown is a debugging aid I added > locally. > > Digging into Moar shows that we simply dereference a pointer for > elems, while nqp-j calls sixmodel.TypeObject.elems(), which throws. > > I don't know whether having moar do validity checks for > TypeObject.elems is worth the performance trade off, but having nqp-j > return an invalid number there seems unwise.
RT is intended for Rakudo Perl 6 issues. I've opened a copy of this ticket in nqp's queue, here: https://github.com/perl6/nqp/issues/299 Please follow the progress on that ticket. Regards. -- Will "Coke" Coleda
