Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-06-18

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

All times shown according to UTC.

Time Nick Message
00:07 lue joined #moarvm
00:31 benabik joined #moarvm
00:43 cognominal joined #moarvm
01:18 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:20 japhb *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:21 japhb 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:23 japhb 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:47 ilbot3 joined #moarvm
01:47 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
06:23 oetiker joined #moarvm
06:26 woolfy left #moarvm
06:38 zakharyas joined #moarvm
06:56 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:57 FROGGS joined #moarvm
06:58 jnthn japhb: So, not really sure what's going on there...
06:58 jnthn japhb: Where's the script in question?
08:59 nwc10 jnthn: business as usual - ASAN only unhappy with t/spec/S17-lowlevel/lock.rakudo.moar
09:07 Util joined #moarvm
09:31 FROGGS that is the real error for lwp-simple:
09:31 FROGGS Program received signal SIGSEGV, Segmentation fault.
09:31 FROGGS 0x00007ffff79dcfa4 in MVM_6model_try_cache_type_check () from /home/froggs/dev/star/work-m/rakudo-star-2014.05/install/lib/libmoar.so
09:32 FROGGS optimize_bb is in the bt
09:33 FROGGS (gdb) p *obj
09:33 FROGGS $1 = {header = {owner = 44763016, flags = 0, size = 0, sc_forward_u = {forwarder = 0x2856c78, sc = {sc_idx = 42298488, idx = 0}, st = 0x2856c78}}, st = 0x0}
09:34 FROGGS from:
09:34 FROGGS 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
09:34 FROGGS 280        MVMuint16 i, elems = STABLE(obj)->type_check_cache_length;
09:50 FROGGS okay, it definitely is a spesh bug
09:51 FROGGS optimize_istype sometimes gets garbage
09:52 timotimo oh crap
09:52 timotimo didnt i make that?
09:53 FROGGS timotimo: the thing in optimize_istype already is messed up
09:53 FROGGS err
09:53 FROGGS in MVM_spesh_get_facts(tc, g, ins->operands[1])
09:53 timotimo oh, huh
10:12 jnthn yes, that's a garbage address
10:13 jnthn Can you dump the facts?
10:13 jnthn (what get_facts returns)
11:55 FROGGS (gdb) p *MVM_spesh_get_facts(tc, (MVMSpeshGraph *)0x6632470, ((MVMSpeshIns *)0x6ecdd90)->operands[1])
11:55 FROGGS $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}}
11:55 FROGGS (gdb) p *MVM_spesh_get_facts(tc, (MVMSpeshGraph *)0x6632470, ((MVMSpeshIns *)0x6ecdd90)->operands[2])
11:55 FROGGS $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,
11:55 FROGGS n64 = 2,0900494588748753e-316, s = 0x2857e60}}
11:57 jnthn hm, that type pointer in the first one looks bogus...
12:01 FROGGS (gdb) p *0x7ffff678c6f8
12:01 FROGGS $3 = 95801272
12:01 FROGGS whatever that means
12:01 FROGGS (gdb) p *0x2857e60
12:01 FROGGS $4 = 1
12:29 donaldh joined #moarvm
12:45 timotimo hmm, we didn't end up fixing the string performance for this month's release
12:50 moritz there's still another release next month :-)
12:50 timotimo aye
12:56 jnthn That's the nice thing about monthly releases :)
12:58 timotimo somehow i'm not really blown away by these benchmarks; at least by the one-year-progress aspect of it
13:03 jnthn Remember it's a log graph
13:03 jnthn The improvements to Rakudo are fairly notable.
13:10 jnthn (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:13 tadzik :)
13:14 FROGGS joined #moarvm
13:17 timotimo troo
13:17 timotimo log-log is counterintuitive :(
13:18 timotimo perl5 is still a long way away for our rakudo's
13:21 timotimo the difference in start-up-time and memory usage for mostly empty programs is quite gigantic, too
13:21 timotimo still hoping someone gets around to making chunks of the core setting loaded on-demand
13:23 FROGGS that would be premature atm I think
13:24 timotimo how so?
13:28 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 FROGGS are*
14:07 btyler joined #moarvm
15:11 jnap joined #moarvm
16:55 zakharyas joined #moarvm
17:25 FROGGS jnthn: I was not able to hunt that bug any further, so I checked out the older version of MIME::Base64
17:25 FROGGS jnthn: and will run module tests with latest vm/compiler versions now
17:59 jnthn FROGGS: How do I recreate that bug?
18:00 jnthn 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
18:00 FROGGS jnthn: I can, just need to switch back to newer versions of the modules
18:02 jnap joined #moarvm
18:07 FROGGS jnthn: I hope I put enough stamps on it :o)
18:11 btyler joined #moarvm
18:19 jnthn FROGGS: Thanks; dinner now, will look in a bit.
18:20 FROGGS k
18:56 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
18:56 timotimo OK fair enough
18:58 timotimo https://github.com/MoarVM/MoarVM/issues/104
19:08 jnthn Reproduced it.
19:09 FROGGS hmmm, my r-m* fails with the same version [Coke]++ has (and his passes)
19:19 raiph joined #moarvm
19:30 dalek MoarVM: 98ced1e | jnthn++ | src/spesh/ (7 files):
19:30 dalek MoarVM: Fix frame handler end move in instruction deletion
19:30 dalek MoarVM:
19:30 dalek MoarVM: Closes #104.
19:30 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/98ced1ef54
19:32 donaldh joined #moarvm
19:33 jnthn timotimo: One bug squishd. :)
19:38 brrt joined #moarvm
19:39 brrt \o #moarvm
19:39 jnthn o/ brrt
19:39 brrt how's today been :-)
19:39 FROGGS hi brrt
19:40 FROGGS my today was okay :o)
19:40 brrt hi froggs, jntnh :-)
19:40 jnthn tiring, but the week's teaching is done.
19:40 jnthn The week's traveling is yet to come.
19:41 brrt oh, yes, exciting :-)
19:41 brrt mine has been ... tiring as well. first moment i get some time to think today
19:42 brrt oh, by the way,i was wrong about the move node (again)
19:42 brrt i forgot the register-by-register combinatoions, which are at least 4x4, so that gives us 16*6 = 96 ? combinations
19:43 brrt and that is severely restricting the number of registers we could use
19:44 brrt anyway, i already have a better idea for now :-)
19:46 brrt hoelzro - i saw it in my mail too (the dynasm tutorial / reference)
19:47 brrt it's a good resource i think
19:48 brrt something i did not see but which is really really handy
19:48 brrt you can end dynasm statements with a semicolon
19:49 brrt and that makes automatic c-mode indentation and coloring work :-)
19:56 zakharyas joined #moarvm
19:56 carlin joined #moarvm
19:59 jnthn FROGGS: Seeing if I can reproduce the issue now
20:00 brrt /join #polari
20:00 brrt huh, that doesn't work in empathy?
20:00 jnthn fail :)
20:00 jnthn Did you accidentally a space before it?
20:00 brrt perhaps
20:00 brrt likely
20:01 brrt :-)
20:01 jnthn At least it wasn't /join #phpfanclub :P
20:02 FROGGS jnthn: if you need more infos or tests, I have the shell still open
20:02 FROGGS jnthn: #phpfanclub is empty :(
20:03 FROGGS but in #php are 652 ppl
20:05 jnthn FROGGS: binary-and-long-line.t failed a test...is that same for you?
20:05 FROGGS no
20:06 FROGGS that's mine: modules/perl6-lwp-simple/t/get-w3-latin1-utf8.t
20:07 FROGGS modules/Perl6-MIME-Base64/t/binary-and-long-line.t always passes here
20:08 jnthn may be a windows line ending issue
20:09 jnthn --notests it
20:09 jnthn URI installed
20:09 jnthn t/get-perl6-org.t and t/get-unsized.t both SEGV for me.
20:09 FROGGS O.o
20:10 FROGGS hopefully the very same bug :o)
20:10 jnthn argh...how do I get Panda not to trash the .work after the fail...
20:10 FROGGS wow, #php is not very nice :o)
20:11 FROGGS jnthn: remove the rm_RF calls?
20:11 jnthn or ^C at an opportune point :)
20:11 FROGGS hehe
20:11 FROGGS grep for rm_rf if you arn't lucky
20:13 brrt i didn't add the space that time jntnh :-p
20:15 FROGGS brrt: but now you spelled him wrong, twice :P
20:15 brrt :-( not my day
20:16 FROGGS ahh, np, just make no typos in your code :o)
20:16 timotimo FROGGS: how did you find out?
20:17 FROGGS timotimo: find out what?
20:18 timotimo that #php isn't nice
20:18 FROGGS timotimo: well, I'm in there
20:19 FROGGS 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
20:20 FROGGS <cythrawll> you're using mysql_* functions how much crazier can it get?
20:20 FROGGS <javalover> oh gawd
20:20 FROGGS * diegoholiveira hat die Verbindung getrennt (Quit: My iMac has gone to sleep. ZZZzzz…)
20:20 FROGGS <javalover> i can't take this you racist people
20:20 FROGGS as I said...
20:21 * brrt kind of has to see for himself
20:22 brrt left #moarvm
20:22 brrt joined #moarvm
20:22 timotimo er ... wow.
20:23 brrt that stuff is pretty nasty, it seems
20:27 brrt FROGGS - fwiw, i think this is a 'PHP should be OOP' kind of discussion
20:29 FROGGS they could just try to explain better, instead of denying answers... but that is enough OT here :o)
20:32 jnthn FROGGS: Yes, it's in optimize_istype
20:32 FROGGS cool!
20:32 FROGGS but I guess the problems sits somewhere way earlier
20:41 jnthn yeah
20:44 dalek MoarVM: 9ebdc64 | jnthn++ | src/spesh/graph.c:
20:44 dalek MoarVM: Fix copy-pasto in spesh graph GC marking.
20:44 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9ebdc64af5
20:45 FROGGS is that related?
20:46 jnthn That's it.
20:46 FROGGS uhhh
20:46 vendethiel joined #moarvm
20:46 jnthn Thus why the pointer was garbage.
20:46 FROGGS I've already pulled, made the dummy release and configured :o)
20:46 FROGGS let's see
20:47 jnthn I did notice another issue in that code that I'll address now too
20:47 FROGGS jnthn++
20:47 timotimo i need to run that single benchmark again :3
20:47 timotimo now that it will no longer crash
20:47 jnthn One rather less likely to actually manifest itself.
20:47 FROGGS awesome!
20:48 jnthn But want to fix it too before I forget it :)
20:48 jnthn Anyway, above commit should nail the issue with LWP
20:58 dalek MoarVM: 21e548c | jnthn++ | src/spesh/graph.c:
20:58 dalek MoarVM: Add missing marking of known value facts.
20:58 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/21e548cf61
20:59 dalek MoarVM: e68d0ea | jnthn++ | docs/ChangeLog:
20:59 dalek MoarVM: Two more ChangeLog notes.
20:59 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e68d0ea88d
21:00 jnthn So, I'm traveling tomorrow, so will cut the MoarVM release this evening.
21:04 btyler_ joined #moarvm
21:05 dalek MoarVM: d253acc | jnthn++ | README.markdown:
21:05 dalek MoarVM: README tweaks.
21:05 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d253acc4e1
21:05 nwc10 jnthn: ASAN is looking happy at 9ebdc64af5
21:05 FROGGS jnthn++ # confirmed, it works!
21:05 nwc10 but I don't think I can get you an answer for anything later before tomorow morning, so too late
21:07 nwc10 t/spec/S32-io/IO-Socket-Async.t not reliable
21:07 nwc10 t/spec/S17-lowlevel/lock.rakudo.moar the usual.
21:07 jnthn yeah
21:07 jnthn I plan to look at those two in the next release cycle
21:08 jnthn 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
21:08 nwc10 bit like my pizza at lunchtime
21:08 jnthn Well, and it's not all the way there yet, but the really hard stuff is done.
21:08 nwc10 (except that I got to nom it)
21:08 nwc10 I guess stuff like "don't inline if it uses extops" was punting, not "never"
21:08 jnthn Right
21:09 jnthn Same with frame handlers.
21:09 jnthn The deopt was the really tricky piece, tbh.
21:09 jnthn The graph merge was more tedious and fiddly than hard.
21:18 vendethiel joined #moarvm
21:19 brrt hmm, moar-jit can't build nqp it seems
21:19 brrt thats weird
21:21 FROGGS merge in MoarVM/master?
21:22 jnthn Check the jit log? :)
21:22 brrt no, its a jit bug
21:22 brrt doing that
21:22 brrt code looks good, though
21:22 FROGGS jitterbug
21:22 brrt its weirder
21:22 brrt apparantly its' trying to enter a NULL jitcode
21:22 brrt it is
21:22 brrt and that is being caught
21:23 brrt but how is it possible at all, is what i'm wondering
21:23 nwc10 ask valgrind what valgrind thinks?
21:23 brrt that is a great idea
21:25 japhb_ joined #moarvm
21:26 brrt no, its weirder
21:26 brrt but i probably know why
21:27 brrt hmm
21:27 brrt or not
21:29 brrt here's the thing
21:29 brrt nqp throws the 'try to enter NULL jitcode', whcih is what happens with the sp_jit_enter opcode and the jitcode pointer is null
21:29 brrt i.e. unintiialized
21:30 brrt so i try to throw an exception before that is assigned to null
21:30 brrt nope, doesn't happen
21:32 * brrt just had another awesome idea wrt to return-value-handling
21:33 brrt 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:36 nwc10 jnthn: same result for d253acc4e1d350 and I should go to bed
21:38 jnthn nwc10: Thanks for testing; sleep well :)
21:45 donaldh joined #moarvm
22:02 dalek MoarVM: 1dc4118 | jnthn++ | VERSION:
22:02 dalek MoarVM: Bump VERSION.
22:02 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1dc4118df3
22:04 brrt oh, i see
22:04 brrt (i'm just talking to myself, nothing to see here :-))
22:04 jnthn :)
22:10 brrt hmmmm
22:11 brrt what seems to happen is that some codes calls the MVM_OP_sp_enter_jit opcode, but there is no jitcode set
22:11 brrt i.e. no compiled function
22:13 brrt and... that should be impossible, really
22:13 brrt i.e.
22:13 brrt it should be caught before that
22:14 jnthn hmmm
22:14 brrt that, or the spesh cand is replaced but its bytecode is not?
22:14 brrt i can't believe that, though
22:15 jnthn deopt does that but...I don't think you're doing anything that could trigger that
22:16 jnthn oh, and it does replace bytecode
22:16 jnthn So not even then.
22:16 brrt what are things that can trigger deopt? sp_guard*, right?
22:18 jnthn yeah, well, and there's deopt_all, but you have to be deeper in the stack for that.
22:18 jnthn And you aren't.
22:18 jnthn Because iiuc, you can't compile invoke yet?
22:19 brrt nope
22:20 jnthn Can always dump the backtrace each time you enter JIT code and see if there's anything intersting to see
22:22 brrt that may be a good idea
22:32 dalek MoarVM: bb37476 | jnthn++ | src/6model/reprs/MVMMultiCache.c:
22:32 dalek MoarVM: Don't look "inside" container type objects.
22:32 dalek MoarVM:
22:32 dalek MoarVM: Fixes various multi-cache related SEGVs when talking about Scalar.
22:32 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/bb37476709
22:35 brrt i.. don't think i'm going to find the bug today :-(
22:40 jnthn Well, sometimes sleeping on it helps a lot :)
22:48 brrt true
22:48 brrt my current best guess is that spesh and jit claim the same opcode number
22:48 brrt although that'd be weird
22:49 brrt but possible, i guess
22:49 brrt hmm, now i'm a bit of stuck
22:51 brrt (make -j is awesome, though)
22:51 nebuchad` joined #moarvm
22:54 brrt ok, i'm going to sleep
22:54 * brrt off
23:08 dalek moarvm.org: fd21c48 | jnthn++ | / (3 files):
23:08 dalek moarvm.org: Update site for 2014.06 release.
23:08 dalek moarvm.org: review: https://github.com/MoarVM/moarvm.org/commit/fd21c48e31
23:08 jnthn http://www.moarvm.org/ # 2014.06 is out :)
23:12 jnthn And I'm off. 'night
23:17 timotimo Gnite  jnthn
23:23 bcode_ joined #moarvm
23:45 japhb joined #moarvm

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