Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-05-31

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:32 FROGGS_ joined #moarvm
03:46 vendethiel joined #moarvm
03:52 JimmyZ joined #moarvm
09:40 JimmyZ_ joined #moarvm
13:03 jnap joined #moarvm
13:05 brrt joined #moarvm
13:07 brrt hi #moarvm
13:09 moritz \o brrt
13:09 brrt hi moritz
13:10 brrt long time no chat i guess? :-)
13:11 * moritz chats dayly, but can't always remember with whom
13:12 brrt :-)
13:12 brrt how's life now?
13:12 * brrt is already wondering if dynasm can be used for purposes of nativecall
13:58 oetiker joined #moarvm
14:31 FROGGS joined #moarvm
14:32 FROGGS o/
14:53 brrt joined #moarvm
15:00 zakharyas joined #moarvm
15:05 zakharyas1 joined #moarvm
16:31 brrt joined #moarvm
17:06 jnap joined #moarvm
18:46 FROGGS I know some details about this bug:
18:46 FROGGS yes 1 | head -20 | perl6-m
18:46 FROGGS # like 13 lines of output
18:46 FROGGS Spesh: failed to fix up handlers (-1, 114, 114)
18:46 timotimo good to know. FROGGS -v
18:46 FROGGS it is caused by optimize_can_op()
18:46 timotimo oh no!
18:46 timotimo that's my work :(
18:46 FROGGS ha!
18:46 FROGGS *g*
18:46 timotimo so no terribly big surprise it can break ;)
18:47 FROGGS :P
18:49 timotimo so i guess the MVM_6model_can_method_cache_only function isn't always safe?
18:56 timotimo can you tell more exactly where that error is happening?
18:56 timotimo because i see nothing in optimize_can_op or MVM_6model_can_method_cache_only that could cause that error
18:59 FROGGS I am spectesting rakudo right now
18:59 brrt joined #moarvm
18:59 timotimo oke
18:59 FROGGS I can do more perhaps in a few minutes
19:05 zakharyas joined #moarvm
19:09 FROGGS timotimo: it seems to be optimize_iffy in combination with optimize_can_op
19:10 FROGGS because I only have turned on these two, and there error is still there
19:10 FROGGS (and vanishes when I disable one of them)
19:11 timotimo ah, so it's not the method itself that's exploding, but the resulting bytecode is bogus?
19:14 FROGGS I guess so
19:14 FROGGS open the repl, and just type 13 times 1 and enter
19:14 timotimo we should be able to find out more using the spesh log
19:57 masak (also see http://irclog.perlgeek.de/perl6/2014-05-31#i_8800771 where I check what does and does not trigger it)
20:01 lizmat m: EVAL "1\n" for ^100   # no problem, oddly enough
20:01 camelia rakudo-moar 7d6acc: ( no output )
20:02 lizmat so I would assume it's something around the repl
20:25 timotimo it could be that the "1\n" gets compiled to a new code object each time
20:25 timotimo and perhaps that doesn't trigger the spesh
20:25 timotimo 10 runs is when spesh inserts the logging bytecodes, 3 runs later it tries to specialize based on the seen information
20:31 lizmat timotimo: do you know where the --stagestats code lives ?
20:31 lizmat I want to kill "Stage start", as it's non-info nowadays
20:45 FROGGS it is in HLL::Compiler or so
20:46 FROGGS just grep for usage of nqp::sprintf in nqp

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary