github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2018/12/24/...ars-later/ 00:11
AlexDaniel please, #moarvm, take a look at github.com/rakudo/rakudo/issues/2564 00:36
AlexDaniel looks up 00:37
oh :)
nine timotimo: that's exactly what I have done ;) But I'm no longer sure its result is valid... 09:21
timotimo say, are those int attributes 64bit sized inside the Match object? 09:45
but if !cursor_fail is broken, it would have exploded way earlier 09:46
so yeah, no clue what's up with that
nine I guess the only way to find out is to disable spesh optimizations until the error goes away. But that will take longer than I have before going to my parents' for Christmas 09:57
I've already tried disabling the getattr/bindattr optimizations in P6Opaque. That's why I suspect the bisect to be misleading 09:59
timotimo a patch to make that would probably be a single line to main.c :) 10:03
nine Err....I meant disabling optimizations one by one until we find the broken one
timotimo oh 10:04
yeah that'd take a bit longer
AFKBBL
brrt \o 13:12
nine++ # debugging
timotimo i'm sure the bytecode compiler could be loads faster if it didn't calculate 3*4 every insert_bytecode call :P 13:51
hm, how do we get an int from inside a BOOTInt in nqp code? 13:56
nqp-m: my $foo := nqp::list; nqp::push($foo, 1); my int $foo := nqp::shift($foo); say($foo) 13:57
camelia Redeclaration of symbol $foo at line 2, near "; say($foo"
at gen/moar/stage2/NQPHLL.nqp:819 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/NQPHLL.moarvm:panic)
from gen/moar/stage2/NQP.nqp:2903 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/nqp.moarvm:vari…
timotimo nqp-m: my $foo := nqp::list; nqp::push($foo, 1); my int $bar := nqp::shift($foo); say($bar)
camelia 1
timotimo nqp-m: my $foo := nqp::list; nqp::push($foo, 1); my int $bar := nqp::unbox_i(nqp::shift($foo)); say($bar)
camelia 1
timotimo elems, coerce_in, const_n64, div_n, coerce_in, coerce_iu, trunc_u16 14:09
amazing
timotimo smrt_numify may want to be one of the things that counts as an unbox 14:17
could put an nqp::unbox_i around basically every method call in write_frame. that would be pretty terrible :\ 14:27
because at the moment it's numifying the integer objects that these methods return, and then coerces that resulting num to an int 14:33
but tbh i haven't measured the performance yet 14:34
so it could very well be wasted time :) :)