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