00:07 lue joined 00:31 benabik joined 00:43 cognominal joined
japhb Something weird is going on with nqp-m when outputting from rc-forest-fire. If I run 'nqp-m nqp/rc-forest-fire 16 16 100' then perhaps half the time, instead of ending the run with a normal looking frame, the output is corrupted -- some rows twice as wide, the frame number in the corner wrong or in the wrong spot, the shell prompt invisible and somewhere in the middle of the printed frame. 01:18
*But* this doesn't occur if I put an nqp::sleep(0.01) after the '$f.step;' line. Higher sleep times work too; too much shorter and the output is corrupted again. 01:20
I've confirmed at a straight shell, in a screen, and in a screen over ssh, and the behavior is the same in all cases, so I don't think it's a problem with how the output is being rendered. 01:21
I have a sneaking suspicion that really fixing this (whatever it is) could make I/O on Moar much more stable, but it's just a hunch. The problem just happens to trigger a pattern match somewhere in my brain. 01:23
01:47 ilbot3 joined 06:23 oetiker joined 06:26 woolfy left 06:38 zakharyas joined
jnthn japhb: I've not encountered a situation where I/O (at least, aside from the async socket stuff which is still a WIP) was unstable. 06:56
06:57 FROGGS joined
jnthn japhb: So, not really sure what's going on there... 06:58
japhb: Where's the script in question?
nwc10 jnthn: business as usual - ASAN only unhappy with t/spec/S17-lowlevel/lock.rakudo.moar 08:59
09:07 Util joined
FROGGS that is the real error for lwp-simple: 09:31
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff79dcfa4 in MVM_6model_try_cache_type_check () from /home/froggs/dev/star/work-m/rakudo-star-2014.05/install/lib/libmoar.so
optimize_bb is in the bt 09:32
(gdb) p *obj 09:33
$1 = {header = {owner = 44763016, flags = 0, size = 0, sc_forward_u = {forwarder = 0x2856c78, sc = {sc_idx = 42298488, idx = 0}, st = 0x2856c78}}, st = 0x0}
from: 09:34
0x00007ffff79dcfa4 in MVM_6model_try_cache_type_check (tc=tc@entry=0x6035e0, obj=0x7ffff678bde8, type=0x2857e60, result=result@entry=0x7fffffffd640) at src/6model/6model.c:280
280 MVMuint16 i, elems = STABLE(obj)->type_check_cache_length;
okay, it definitely is a spesh bug 09:50
optimize_istype sometimes gets garbage 09:51
timotimo oh crap 09:52
didnt i make that?
FROGGS timotimo: the thing in optimize_istype already is messed up 09:53
err
in MVM_spesh_get_facts(tc, g, ins->operands[1])
timotimo oh, huh
jnthn yes, that's a garbage address 10:12
Can you dump the facts? 10:13
(what get_facts returns)
FROGGS (gdb) p *MVM_spesh_get_facts(tc, (MVMSpeshGraph *)0x6632470, ((MVMSpeshIns *)0x6ecdd90)->operands[1]) 11:55
$1 = {flags = 13, usages = 1, type = 0x7ffff678c6f8, decont_type = 0x0, value = {o = 0x0, i64 = 0, i32 = 0, i16 = 0, i8 = 0 '\000', n32 = 0, n64 = 0, s = 0x0}}
(gdb) p *MVM_spesh_get_facts(tc, (MVMSpeshGraph *)0x6632470, ((MVMSpeshIns *)0x6ecdd90)->operands[2])
$2 = {flags = 23, usages = 1, type = 0x2857e60, decont_type = 0x0, value = {o = 0x2857e60, i64 = 42303072, i32 = 42303072, i16 = 32352, i8 = 96 '`', n32 = 1,96151293e-37,
n64 = 2,0900494588748753e-316, s = 0x2857e60}}
jnthn hm, that type pointer in the first one looks bogus... 11:57
FROGGS (gdb) p *0x7ffff678c6f8 12:01
$3 = 95801272
whatever that means
(gdb) p *0x2857e60
$4 = 1
12:29 donaldh joined
timotimo hmm, we didn't end up fixing the string performance for this month's release 12:45
moritz there's still another release next month :-) 12:50
timotimo aye
jnthn That's the nice thing about monthly releases :) 12:56
timotimo somehow i'm not really blown away by these benchmarks; at least by the one-year-progress aspect of it 12:58
jnthn Remember it's a log graph 13:03
The improvements to Rakudo are fairly notable.
(A factor of 5 difference is the difference between a 50fps game and a 10fps one - which is a "can I even use Perl 6 for X" difference) 13:10
tadzik :) 13:13
13:14 FROGGS joined
timotimo troo 13:17
log-log is counterintuitive :(
perl5 is still a long way away for our rakudo's 13:18
the difference in start-up-time and memory usage for mostly empty programs is quite gigantic, too 13:21
still hoping someone gets around to making chunks of the core setting loaded on-demand
FROGGS that would be premature atm I think 13:23
timotimo how so? 13:24
FROGGS I'd say there a holes in the spec and in the implementation that are like 1000 times more important than using 98MB less mem for a one-liner 13:28
are*
14:07 btyler joined 15:11 jnap joined 16:55 zakharyas joined
FROGGS jnthn: I was not able to hunt that bug any further, so I checked out the older version of MIME::Base64 17:25
jnthn: and will run module tests with latest vm/compiler versions now
jnthn FROGGS: How do I recreate that bug? 17:59
FROGGS: Or can you set MVM_SPESH_LOG=spesh_log and run the thing that SEGVs and send me it? 18:00
FROGGS jnthn: you should get it by installing latest MIME::Base64 and LWP::Simple
jnthn: I can, just need to switch back to newer versions of the modules
18:02 jnap joined
FROGGS jnthn: I hope I put enough stamps on it :o) 18:07
18:11 btyler joined
jnthn FROGGS: Thanks; dinner now, will look in a bit. 18:19
FROGGS k 18:20
timotimo jnthn: should i still paste that for loop thingie that gives the fixup handlers error into a github issue? 18:56
jnthn timotimo: yeah, please...I'll take a look at that now, though
timotimo OK fair enough
github.com/MoarVM/MoarVM/issues/104 18:58
jnthn Reproduced it. 19:08
FROGGS hmmm, my r-m* fails with the same version [Coke]++ has (and his passes) 19:09
19:19 raiph joined
dalek arVM: 98ced1e | jnthn++ | src/spesh/ (7 files):
Fix frame handler end move in instruction deletion

Closes #104.		 19:30
19:32 donaldh joined
jnthn timotimo: One bug squishd. :) 19:33
19:38 brrt joined
brrt \o #moarvm 19:39
jnthn o/ brrt
brrt how's today been :-)
FROGGS hi brrt
my today was okay :o) 19:40
brrt hi froggs, jntnh :-)
jnthn tiring, but the week's teaching is done.
The week's traveling is yet to come.
brrt oh, yes, exciting :-) 19:41
mine has been ... tiring as well. first moment i get some time to think today
oh, by the way,i was wrong about the move node (again) 19:42
i forgot the register-by-register combinatoions, which are at least 4x4, so that gives us 16*6 = 96 ? combinations
and that is severely restricting the number of registers we could use 19:43
anyway, i already have a better idea for now :-) 19:44
hoelzro - i saw it in my mail too (the dynasm tutorial / reference) 19:46
it's a good resource i think 19:47
something i did not see but which is really really handy 19:48
you can end dynasm statements with a semicolon
and that makes automatic c-mode indentation and coloring work :-) 19:49
19:56 zakharyas joined, carlin joined
jnthn FROGGS: Seeing if I can reproduce the issue now 19:59
brrt /join #polari 20:00
huh, that doesn't work in empathy?
jnthn fail :)
Did you accidentally a space before it?
brrt perhaps
likely
:-) 20:01
jnthn At least it wasn't /join #phpfanclub :P
FROGGS jnthn: if you need more infos or tests, I have the shell still open 20:02
jnthn: #phpfanclub is empty :(
but in #php are 652 ppl 20:03
jnthn FROGGS: binary-and-long-line.t failed a test...is that same for you? 20:05
FROGGS no
that's mine: modules/perl6-lwp-simple/t/get-w3-latin1-utf8.t 20:06
modules/Perl6-MIME-Base64/t/binary-and-long-line.t always passes here 20:07
jnthn may be a windows line ending issue 20:08
--notests it 20:09
URI installed
t/get-perl6-org.t and t/get-unsized.t both SEGV for me.
FROGGS O.o
hopefully the very same bug :o) 20:10
jnthn argh...how do I get Panda not to trash the .work after the fail...
FROGGS wow, #php is not very nice :o)
jnthn: remove the rm_RF calls? 20:11
jnthn or ^C at an opportune point :)
FROGGS hehe
grep for rm_rf if you arn't lucky
brrt i didn't add the space that time jntnh :-p 20:13
FROGGS brrt: but now you spelled him wrong, twice :P 20:15
brrt :-( not my day
FROGGS ahh, np, just make no typos in your code :o) 20:16
timotimo FROGGS: how did you find out?
FROGGS timotimo: find out what? 20:17
timotimo that #php isn't nice 20:18
FROGGS timotimo: well, I'm in there
and one is asking a question and like five ppl say him that they do not want to answer, and he wasn't trolling 20:19
timotimo o_O
FROGGS <cythrawll> you're using mysql_* functions how much crazier can it get? 20:20
<javalover> oh gawd
* diegoholiveira hat die Verbindung getrennt (Quit: My iMac has gone to sleep. ZZZzzz…)
<javalover> i can't take this you racist people
as I said...
brrt kind of has to see for himself 20:21
20:22 brrt left, brrt joined
timotimo er ... wow. 20:22
brrt that stuff is pretty nasty, it seems 20:23
FROGGS - fwiw, i think this is a 'PHP should be OOP' kind of discussion 20:27
FROGGS they could just try to explain better, instead of denying answers... but that is enough OT here :o) 20:29
jnthn FROGGS: Yes, it's in optimize_istype 20:32
FROGGS cool!
but I guess the problems sits somewhere way earlier
jnthn yeah 20:41
dalek arVM: 9ebdc64 | jnthn++ | src/spesh/graph.c:
Fix copy-pasto in spesh graph GC marking.
 20:44
FROGGS is that related? 20:45
jnthn That's it. 20:46
FROGGS uhhh
20:46 vendethiel joined
jnthn Thus why the pointer was garbage. 20:46
FROGGS I've already pulled, made the dummy release and configured :o)
let's see
jnthn I did notice another issue in that code that I'll address now too 20:47
FROGGS jnthn++
timotimo i need to run that single benchmark again :3
now that it will no longer crash
jnthn One rather less likely to actually manifest itself.
FROGGS awesome!
jnthn But want to fix it too before I forget it :) 20:48
Anyway, above commit should nail the issue with LWP
dalek arVM: 21e548c | jnthn++ | src/spesh/graph.c:
Add missing marking of known value facts.
 20:58
arVM: e68d0ea | jnthn++ | docs/ChangeLog:
Two more ChangeLog notes.
 20:59
jnthn So, I'm traveling tomorrow, so will cut the MoarVM release this evening. 21:00
21:04 btyler_ joined
dalek arVM: d253acc | jnthn++ | README.markdown:
README tweaks.
 21:05
nwc10 jnthn: ASAN is looking happy at 9ebdc64af5
FROGGS jnthn++ # confirmed, it works!
nwc10 but I don't think I can get you an answer for anything later before tomorow morning, so too late
t/spec/S32-io/IO-Socket-Async.t not reliable 21:07
t/spec/S17-lowlevel/lock.rakudo.moar the usual.
jnthn yeah
I plan to look at those two in the next release cycle
I was rather short on good concentration time in the last month, and inlining was hard enough to nom it all 21:08
nwc10 oh my, yes, inlining looked big
bit like my pizza at lunchtime
jnthn Well, and it's not all the way there yet, but the really hard stuff is done.
nwc10 (except that I got to nom it)
I guess stuff like "don't inline if it uses extops" was punting, not "never"
jnthn Right
Same with frame handlers. 21:09
The deopt was the really tricky piece, tbh.
The graph merge was more tedious and fiddly than hard.
21:18 vendethiel joined
brrt hmm, moar-jit can't build nqp it seems 21:19
thats weird
FROGGS merge in MoarVM/master? 21:21
jnthn Check the jit log? :) 21:22
brrt no, its a jit bug
doing that
code looks good, though
FROGGS jitterbug
brrt its weirder
apparantly its' trying to enter a NULL jitcode
it is
and that is being caught
but how is it possible at all, is what i'm wondering 21:23
nwc10 ask valgrind what valgrind thinks?
brrt that is a great idea
21:25 japhb_ joined
brrt no, its weirder 21:26
but i probably know why
hmm 21:27
or not
here's the thing 21:29
nqp throws the 'try to enter NULL jitcode', whcih is what happens with the sp_jit_enter opcode and the jitcode pointer is null
i.e. unintiialized
so i try to throw an exception before that is assigned to null 21:30
nope, doesn't happen
brrt just had another awesome idea wrt to return-value-handling 21:32
why not allocate an extra register, and put the return-value pointer there? then, the graph constructor can insert any extra 'work' ops after using that register 21:33
nwc10 jnthn: same result for d253acc4e1d350 and I should go to bed 21:36
jnthn nwc10: Thanks for testing; sleep well :) 21:38
21:45 donaldh joined
dalek arVM: 1dc4118 | jnthn++ | VERSION:
Bump VERSION.
 22:02
brrt oh, i see 22:04
(i'm just talking to myself, nothing to see here :-))
jnthn :)
brrt hmmmm 22:10
what seems to happen is that some codes calls the MVM_OP_sp_enter_jit opcode, but there is no jitcode set 22:11
i.e. no compiled function
and... that should be impossible, really 22:13
i.e.
it should be caught before that
jnthn hmmm 22:14
brrt that, or the spesh cand is replaced but its bytecode is not?
i can't believe that, though
jnthn deopt does that but...I don't think you're doing anything that could trigger that 22:15
oh, and it does replace bytecode 22:16
So not even then.
brrt what are things that can trigger deopt? sp_guard*, right?
jnthn yeah, well, and there's deopt_all, but you have to be deeper in the stack for that. 22:18
And you aren't.
Because iiuc, you can't compile invoke yet?
brrt nope 22:19
jnthn Can always dump the backtrace each time you enter JIT code and see if there's anything intersting to see 22:20
brrt that may be a good idea 22:22
dalek arVM: bb37476 | jnthn++ | src/6model/reprs/MVMMultiCache.c:
Don't look "inside" container type objects.

Fixes various multi-cache related SEGVs when talking about Scalar.		 22:32
brrt i.. don't think i'm going to find the bug today :-( 22:35
jnthn Well, sometimes sleeping on it helps a lot :) 22:40
brrt true 22:48
my current best guess is that spesh and jit claim the same opcode number
although that'd be weird
but possible, i guess 22:49
hmm, now i'm a bit of stuck
(make -j is awesome, though) 22:51
22:51 nebuchad` joined
brrt ok, i'm going to sleep 22:54
brrt off
dalek href="https://moarvm.org:">moarvm.org: fd21c48 | jnthn++ | / (3 files):
Update site for 2014.06 release.
 23:08
jnthn www.moarvm.org/ # 2014.06 is out :)
And I'm off. 'night 23:12
timotimo Gnite jnthn 23:17
23:23 bcode_ joined 23:45 japhb joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!