Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-03-12

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

All times shown according to UTC.

Time Nick Message
02:56 vendethiel joined #moarvm
03:36 allbery joined #moarvm
03:36 geekosaur joined #moarvm
04:02 ggoebel16 joined #moarvm
05:49 geekosaur joined #moarvm
05:56 geekosaur joined #moarvm
06:40 mojca joined #moarvm
07:39 domidumont joined #moarvm
07:44 domidumont joined #moarvm
07:56 FROGGS[mobile] joined #moarvm
07:58 vendethiel joined #moarvm
08:38 FROGGS joined #moarvm
09:05 FROGGS joined #moarvm
09:31 FROGGS joined #moarvm
10:02 mojca joined #moarvm
12:33 timotimo i think i'll go ahead with the "set debug name" thing for the STable
12:34 timotimo then we'll also have better naming for the guards in spesh candidates
12:35 timotimo i expect it'll be more useful to have that as a char* rather than an MVMString
12:36 jnthn timotimo: Yeah, that was by plan
12:37 jnthn nqp::setdebugtypename($obj_o, $name_s) (evalutes to $obj_o)
12:37 jnthn Where we attach it to the STABLE($obj_o)
12:37 jnthn I'll be heap snapshot hacking a little later today, all being well :)
12:38 timotimo fantastic :)
12:42 timotimo is nqp::getdebugname necessary?
12:48 jnthn Don't immediately see a need
12:48 jnthn You can .^name in Perl 6 space
12:48 jnthn Or NQP
12:48 timotimo right
12:54 timotimo hmpf. if we want to use that in nqp itself, we'll be bumping the stage0 again
12:54 jnthn Let's just in Rakudo for now :)
12:54 jnthn But yeah, you're right
12:58 timotimo the clever of the day: not incrementing cur_op before goto NEXT
12:58 jnthn such smart
12:58 jnthn very brain
12:58 jnthn wow
12:58 mst hah
12:59 mst I had basically that overnight, had a 'first op to resume from' special pointer for a sort of continuation-ish thing
12:59 mst then forgot to clear it so it just kept re-running the first op forever
12:59 * jnthn goes to nom lunch :)
13:05 timotimo good nom!
13:06 timotimo 2 argument guards
13:06 timotimo type(0, 0x81ff10)H<8B>v^XH^O<BF>F^Bf<83><F8><FF>t/H<8B>^QE^O<B7><C9>H<85><D2>H^OD<D1>H<8B>N^X^O<B7>^DAH<8B>^T^BH<8B>r^PH<8D>J^XH<8B>F^PH<8B><80><B8>
13:06 timotimo ^- seems like i might want to null that slot :)
13:11 timotimo well, i am nulling the debug_name, but it's still giving me garbage in the debug output there. huh.
13:12 timotimo oh, heh, that may want to be serialized :)
13:27 timotimo huh. i don't see a serialization/deserialization pair for char * data
13:28 timotimo so it'd have to go through the string heap? :\
13:38 nine ('META6.json', 'META.info').map({$.prefix.parent.child($_)}).first($_.f)
13:55 timotimo i notice i'm not very thoroughly good at serialization code
13:56 timotimo ah, seems like i +='d the cur_write_offset, rather than the *cur_write_offset
13:59 jnthn timotimo: I'd expect that you could add write_cstring and read_cstring APIs
13:59 jnthn To the serializer
13:59 timotimo aye
13:59 jnthn That use strlen on write
13:59 timotimo i've done just that
14:00 jnthn Then just make sure on read you do the correct stuff with ensure_can_read or so to not let a corrupt serialization blob cause out of bounds access
14:00 timotimo aye
14:02 jnthn So...how is heap snapshotter formed...
14:04 timotimo pro tip: return the string buffer from the "read a cstring function"
14:18 timotimo seems like --asan is busted
14:18 timotimo ==1350==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
14:21 timotimo outputting c strings with %d for fprintf is a pretty great idea
14:33 jnthn https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcSSv5SZMJEZYIWxJ_Jpt9QmVOtBpwWCy9V7UEYGaXWd9fnvXU4m4w
14:35 timotimo very
14:38 FROGGS[mobile] joined #moarvm
14:40 timotimo i don't know why i still get mostly binary garbage :|
14:44 timotimo am i forgetting to set the debug_name pointer somewhere? must be something like that
14:44 timotimo or maybe this is about lazy deserialization?
14:45 timotimo out of nowhere (as far as i can tell) the value 0x7f87837613c0 comes into existance in that slot
14:46 jnthn Odd...I'd think we zero the STable
14:46 jnthn Where did you add the new value? At the end?
14:47 timotimo before deserialize_repr_data
14:47 timotimo let me push to a branch
14:47 FROGGS[mobile] .oO( master is a branch too )
14:47 jnthn If you don't put it at the end, and you didn't recompile Rakudo's ext ops, you could land up in trouble.
14:49 timotimo i'll remove some debug spam first, though
14:52 dalek MoarVM/setdebugtypename: 0f7ea20 | timotimo++ | tools/moar-gdb.py:
14:52 dalek MoarVM/setdebugtypename: Merge branch 'moar-gdb.py-python3'
14:52 dalek MoarVM/setdebugtypename:
14:52 dalek MoarVM/setdebugtypename: This ports moar-gdb.py to python 3, which is what the latest GDB
14:52 dalek MoarVM/setdebugtypename: versions ship with. There's still some strange behaviours, but there's
14:52 dalek MoarVM/setdebugtypename: no good reason to keep this in a branch at this point.
14:52 dalek MoarVM/setdebugtypename: review: https://github.com/MoarVM/MoarVM/commit/0f7ea20ee6
14:52 dalek MoarVM/setdebugtypename: 4c01c3a | timotimo++ | / (9 files):
14:52 dalek MoarVM/setdebugtypename: add "debug_name" field to STable struct and setdebugtypename
14:52 dalek MoarVM/setdebugtypename: review: https://github.com/MoarVM/MoarVM/commit/4c01c3ad7c
14:52 timotimo oops
14:53 timotimo that first commit was supposed to be on the main branch already
14:53 timotimo but it seems like it didn't end up there yet
14:57 timotimo i wouldn't put it past me to just completely have forgotten how even to C for this commit
14:58 timotimo but i do get the values out of the serialized blob correctly, at least the values get debug-printed on the read_cstr end
15:10 * timotimo is blocking
15:12 * jnthn runs timotimo on node.js
15:12 * timotimo asynchronlizes
15:14 jnthn +    } else { +        st->debug_name = 0; +    }
15:14 jnthn Would be better as NULL there
15:15 jnthn +        st->debug_name    = NULL;
15:15 jnthn That shouldn't be needed as we allocate zeroed memory
15:15 jnthn I can't see anything else wrong...
15:16 timotimo hmm
15:17 timotimo so why would these values end up in the STable? :\
15:17 timotimo those are obviously kind-of-valid pointers
15:17 timotimo 0x7f1092a7a170, 0x7f1092a5ddc0, 0x7f1092a693b0 ...
15:17 timotimo and reading from all those addresses also works fine, because it doesn't segfault
15:18 timotimo it's just bogus data, and in a totally different region from what malloc gives me when i allocate the buffers to hold these strings
15:18 timotimo i've also got SERIALIZATION_LAZY set to 0 locally and that doesn't change a thing
15:19 jnthn timotimo: You did rebuild Rakudo after changing the STable structure, yes?
15:19 jnthn So it's not extops etc.?
15:20 timotimo aye
15:20 timotimo i'll do it again
15:22 timotimo does it give bad output for you when you have a spesh dump active?
15:22 jnthn I didn't try building it, sorry
15:22 jnthn (a bunch of local diffs and stuff with profiler)
15:23 timotimo ah, ok
15:23 timotimo that's fine
15:23 jnthn Just read the diff
15:23 timotimo i'm glad it looks sane
15:23 jnthn Yeah...if you don't store the string you get back at all when deserializing, do they still end up with junk?
15:24 timotimo not at all, or store 0 instead?
15:25 jnthn Not at all
15:25 jnthn STable memroy should be all zero at initialization
15:26 pyrimidi_ joined #moarvm
15:27 timotimo but guard->match is supposed to be a type object that has a STABLE we can introspect, right?
15:28 jnthn Uh, I think guard->match is directly pointing to an STable?
15:30 timotimo still junk
15:30 timotimo oh, it is?
15:30 timotimo let's see.
15:30 jnthn It may well we, to avoid a deference on every match
15:31 timotimo i see
15:31 jnthn *be
15:33 timotimo YES!
15:33 timotimo you're my saviour of the day! :)
15:35 timotimo i've decided to not use the version of assignment to the stable that would cause repossession
15:35 timotimo is that fine?
15:35 timotimo i mean, for setting the debug typename
15:35 jnthn timotimo: Yeah, I think so
15:36 jnthn timotimo: 'cus I suspect we'll put the name in place really early
15:36 dalek MoarVM/heap-profiler: 39e9841 | jnthn++ | src/ (5 files):
15:36 dalek MoarVM/heap-profiler: Refactor to prepare for multiple profilers.
15:36 dalek MoarVM/heap-profiler:
15:36 dalek MoarVM/heap-profiler: Move most of the logic in profile.c over to instrument.c, which is now
15:36 dalek MoarVM/heap-profiler: the overall implementation of the instrumenting profiler. profile.c
15:36 dalek MoarVM/heap-profiler: will become the thing that dispatches to the various other profilers.
15:36 dalek MoarVM/heap-profiler: review: https://github.com/MoarVM/MoarVM/commit/39e98417dd
15:36 dalek MoarVM/heap-profiler: 5251c98 | jnthn++ | src/ (4 files):
15:36 dalek MoarVM/heap-profiler: Test for kind of profiling to do.
15:36 dalek MoarVM/heap-profiler: review: https://github.com/MoarVM/MoarVM/commit/5251c9887d
15:37 timotimo i'm not sure, though, why it doesn't actually show up in the spesh log anywhere
15:37 timotimo maybe i'm not looking hard enough, though
15:39 timotimo ah, it does show up in some places
15:39 timotimo very good!
15:41 timotimo hm. it never shows any of them for type guards, though
15:41 timotimo i wonder if those types we're guarding against never have the debug name set, or if it's a brokenness
15:43 timotimo ah! it does show up in some places
15:43 timotimo very, very good.
15:44 dalek MoarVM/setdebugtypename: 14ae31e | timotimo++ | src/ (3 files):
15:44 dalek MoarVM/setdebugtypename: setdebugtypename now works properly, also in the spesh log.
15:44 dalek MoarVM/setdebugtypename: review: https://github.com/MoarVM/MoarVM/commit/14ae31e3f1
15:44 timotimo i'll run a spectest with this
15:44 jnthn timotimo++
15:54 timotimo spec tests pass, unsurprisingly, so i think i'll merge
15:55 timotimo unless you have something against that, that is
15:55 jnthn Go for it
15:55 timotimo excellent
15:55 jnthn Remember to bump MOAR_REVISION before pimping out NQP with setdebugname
15:55 jnthn And similar before doing Rakudo
15:56 jnthn This will be really cool for our spesh logs as well as the heap profiler! :D
15:56 dalek MoarVM: 6e5f50a | timotimo++ | tools/moar-gdb.py:
15:56 dalek MoarVM: a whole bunch of changes and debug spam for moar-gdb.py
15:56 dalek MoarVM:
15:56 dalek MoarVM: currently can't analyze the gen2 :(
15:56 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6e5f50a7ab
15:56 dalek MoarVM: 4263b71 | timotimo++ | tools/moar-gdb.py:
15:56 dalek MoarVM: [moar-gdb.py] fix up lots of more stuff for py3 and such
15:56 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4263b71422
15:56 dalek MoarVM: 6df338e | timotimo++ | tools/moar-gdb.py:
15:56 dalek MoarVM: [moar-gdb.py] throw out "reached" crutch
15:56 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6df338e287
15:56 dalek MoarVM: 0f7ea20 | timotimo++ | tools/moar-gdb.py:
15:56 timotimo oh
15:56 timotimo yes, yes.
15:58 timotimo all done
15:58 moritz timotimo++
15:58 timotimo \o/
15:59 jnthn Nice
15:59 timotimo the profiler will want to know about this, as well, then.
16:00 timotimo at least i suspect so
16:06 timotimo see you in ~2.5h, i'll drive home now
16:10 jnthn Safe drive o/
16:13 mtj_ joined #moarvm
16:16 FROGGS joined #moarvm
16:26 dalek MoarVM/heap-profiler: 8b45f42 | jnthn++ | src/ (5 files):
16:26 dalek MoarVM/heap-profiler: Stub in various heap profiler API functions.
16:26 dalek MoarVM/heap-profiler:
16:26 dalek MoarVM/heap-profiler: This wires up the snapshot taking to the GC, and gets us starting and
16:26 dalek MoarVM/heap-profiler: ending the heap profiling. Not collecting any interesting data yet.
16:26 dalek MoarVM/heap-profiler: review: https://github.com/MoarVM/MoarVM/commit/8b45f4212b
16:30 FROGGS uhh, No registered operation handler for 'setdebugtypename'
16:31 jnthn FROGGS: There was an NQP_REVISION bump; did you miss rebuilding?
16:31 FROGGS ohh, indeed
16:41 FROGGS[mobile] joined #moarvm
17:05 dalek MoarVM/heap-profiler: e8fc9e3 | jnthn++ | src/ (13 files):
17:05 dalek MoarVM/heap-profiler: Register all perm roots with a description.
17:05 dalek MoarVM/heap-profiler:
17:05 dalek MoarVM/heap-profiler: This will be used by the heap profiler, but may also be useful when
17:05 dalek MoarVM/heap-profiler: debugging.
17:05 dalek MoarVM/heap-profiler: review: https://github.com/MoarVM/MoarVM/commit/e8fc9e363b
17:12 dalek MoarVM/heap-profiler: 40f536f | jnthn++ | src/profiler/heapsnapshot.h:
17:12 dalek MoarVM/heap-profiler: We'll need some more node types for roots.
17:12 dalek MoarVM/heap-profiler: review: https://github.com/MoarVM/MoarVM/commit/40f536fca0
17:16 jnthn Well, there's the groundwork done. I guess The Hard Bit comes next... :-)
17:19 jnthn But, enough for today, I think :)
17:24 zakharyas joined #moarvm
19:56 timotimo drive was strenuous but okay
20:06 moritz \o
20:21 FROGGS[tab] joined #moarvm

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