# New Ticket Created by Pepe Schwarz # Please include the string: [perl #127771] # in the subject line of all future correspondence about this issue. # <URL: https://rt.perl.org/Ticket/Display.html?id=127771 >
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.
