Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-02-26

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

All times shown according to UTC.

Time Nick Message
02:03 retupmoca joined #moarvm
02:47 ilbot3 joined #moarvm
02:47 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:16 xiaomiao joined #moarvm
03:30 khagan joined #moarvm
03:44 vendethiel joined #moarvm
07:28 vendethiel joined #moarvm
07:41 FROGGS joined #moarvm
07:58 Ven joined #moarvm
07:59 Ven joined #moarvm
08:01 Ven_ joined #moarvm
08:04 xiaomiao left #moarvm
08:23 vendethiel joined #moarvm
08:28 nwc10 nine: No idea if this is interesting: http://morepypy.blogspot.co.at/2016/02/c-api-support-update.html
08:29 zakharyas joined #moarvm
08:39 nine nwc10: thanks! Definitely interesting. I wonder why they used to have 4 dictionaries. I seem to get by just fine with a single array
09:16 vendethiel joined #moarvm
09:20 Redaa joined #moarvm
09:32 Ven joined #moarvm
10:18 brrt joined #moarvm
10:45 domidumont joined #moarvm
11:08 vendethiel joined #moarvm
11:29 Ven joined #moarvm
11:55 vendethiel joined #moarvm
12:04 dalek MoarVM: 24b3867 | (Gerd Pokorra)++ | src/ (3 files):
12:04 dalek MoarVM: Fix the build when not bundling libtommath.
12:04 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/24b386728c
12:25 brrt hey #moarvm
12:26 nwc10 hi brrt
12:26 brrt i was looking this morning at reinstatint the little 'affordances' in the expr jit that used to be in th per-node compilation code, and that are now partially in the tile-list generation code
12:26 brrt reinstating
12:27 brrt anyway, i came across COPY, which is basically a register-forcing op
12:27 jnthn o/ brrt
12:27 brrt \o jnthn
12:27 moritz \o *
12:28 brrt the thing is,COPY is ultimately a hint to the register allocator
12:28 brrt but, the register allocator, is currently still inline
12:28 brrt ok, that answers stuff
12:28 brrt it does not belong in the tiling
12:28 brrt or rather, it belongs as a 'marker' pseudotile
12:28 brrt not as a 'doing' pseudotile
12:29 brrt ugh, not well thought out
12:32 brrt not enough brainspace :-(
12:53 Ven_ joined #moarvm
13:15 Ven joined #moarvm
13:30 Ven joined #moarvm
13:47 brrt joined #moarvm
13:51 vendethiel joined #moarvm
14:12 timotimo oh, what, that's gerd!
14:12 timotimo or is that not_gerd?
14:12 timotimo great to see them commit again in any case!
14:18 FROGGS timotimo: not_gerd is gerdr on github
14:19 timotimo ah, so it's gerd rather than not_gerd
14:19 timotimo thanks
14:20 jnthn Yeah, patch arrived in my mail this morning :)
14:20 FROGGS I still wonder what happened to not_gerd
14:21 timotimo me, too
14:23 * jnthn three, don't know anything there :(
14:24 timotimo also, zoffix seems to be sick or something, and has been gone for many moons
14:24 jnthn Yeah...sounds very un-fun
14:27 moritz timotimo: I think he moved, and will regain Internet connection at home in early March
14:27 moritz and yes, sick before that
14:29 jnthn Ah, so maybe not still sick now...
14:29 jnthn Fingers crossed :)
14:29 timotimo oh
14:29 timotimo OK
14:32 Ven joined #moarvm
14:36 FROGGS he popped in yesterday or the day before that
14:50 vendethiel joined #moarvm
14:56 Ven joined #moarvm
15:08 kjs_ joined #moarvm
15:32 vendethiel joined #moarvm
17:09 vendethiel joined #moarvm
17:29 ilbot3 joined #moarvm
17:29 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
17:56 flussence .oO( there's so many awesome people here that at any given time we're always upset one or another isn't around... #perlworldproblems )
18:08 domidumont joined #moarvm
18:48 FROGGS joined #moarvm
18:48 FROGGS o/
20:03 vendethiel joined #moarvm
20:08 FROGGS jnthn: I think my CArray-in-CPPStruct bug is triggered by a gc run
20:10 timotimo ah, so potentially need for a "copy_to" to exist, or be fixed?
20:13 FROGGS copy_to would throw here...
20:13 FROGGS why would I need it?
20:14 timotimo i don't know
20:14 timotimo isn't that what the gc uses to move stuff around?
20:15 timotimo i could be wrong, of course
20:17 FROGGS MVM_exception_throw_adhoc(tc, "cloning a CPPStruct is NYI");
20:18 timotimo OK
20:18 FROGGS I believe copy_to copies the data to another container
20:18 timotimo it's important to be wrong every now and again
20:18 FROGGS hehe
20:18 timotimo so that people don't rely on everything you blurt out as "accurate"
20:18 FROGGS hmmm, what about jnthn then?
20:19 FROGGS he's probably the only entity thats never wrong on the internet :o)
20:45 timotimo don't forget TimToady's rules
20:46 FROGGS troo
20:55 jnthn FROGGS: Yeah, copy_to isn't used for copying done by the GC...
20:55 jnthn FROGGS: What symptoms?
20:56 jnthn The copy is done purely based on the size field in the object header.
20:57 FROGGS things in body->child_objs vanish when I call a C++ method that mutates the C++ mem
20:57 jnthn Which *could* be being got wrong, but it's unlikey you'd not see the issue until a GC run then, because you'd have an over-short object.
20:57 jnthn So it'd be scribbled on by the next allocation.
20:57 jnthn More common is gc_mark fails to tell the GC about stuff
20:57 FROGGS m: use nqp; nqp::forcegc();
20:57 camelia rakudo-moar 531495: OUTPUT«===SORRY!===␤No registered operation handler for 'forcegc'␤»
20:58 FROGGS jnthn: I dont see gc_mark being called at all
20:58 FROGGS m: use nqp; nqp::force_gc();
20:58 camelia rakudo-moar 531495: ( no output )
20:58 FROGGS will try that instead of the method call
20:59 FROGGS nice: *** Error in `/home/froggs/dev/nqp/install/bin/moar': free(): invalid pointer: 0x0000000005497808 ***
20:59 FROGGS now gc_mark is called btw
20:59 timotimo whoops, that looks ungood :)
21:00 timotimo probably something wrote over the thing that you were trying to free there
21:00 FROGGS in MVM_gc_collect_free_nursery_uncopied
21:00 FROGGS #8  gc_free (tc=<optimized out>, obj=0x7ffff67a1078) at src/6model/reprs/CArray.c:132
21:03 timotimo yeah, that'll be the part that tries to free the object when it's no longer needed
21:04 timotimo i.e. free every pointer that would have been mallocd at some point
21:05 FROGGS but it should not free a CArray at that point, since both CArrays that exist are referenced by the enclosing CPPStruct
21:07 jnthn What keeps them alive?
21:08 FROGGS this? https://gist.github.com/FROGGS/94c223c9d26c2e12a52b#file-inlined_carray-diff-L99
21:10 jnthn MVM_gc_root_temp_push(tc, (MVMCollectable **)&body);
21:10 jnthn That looks dubious
21:10 jnthn What is body?
21:10 FROGGS MVMCPPStructBody *body
21:10 jnthn Ah
21:10 FROGGS yeah, I thought about that already
21:10 jnthn You can't do that.
21:11 jnthn You can only root the collectable object iself.
21:11 FROGGS does it actually hurt?
21:11 jnthn *itself
21:11 jnthn Yes
21:11 FROGGS ohh
21:11 jnthn It'll cause the GC to look at junk memory
21:11 jnthn And, also, to not update the pointer ;)
21:11 FROGGS okay, I removed it but that wasnt it
21:12 jnthn Yeah, but you're right body will be an issue
21:12 jnthn It will become out of date.
21:12 jnthn (If you allocate)
21:12 jnthn Should must be updated
21:12 jnthn So as not to be hated
21:12 jnthn ...OK, the last line as just to keep rhyming
21:13 FROGGS *g*
21:13 jnthn But yeah, body will need to be recalculated from the pointer that is rooted.
21:13 FROGGS same for repr_data I guess
21:13 jnthn No, because repr_data is just a malloc'd piece of memory
21:13 jnthn Whereas body is a pointer into the middle of a piece of GC-managed memory
21:14 jnthn If you're seeing stuff being zeroed that's very likely it
21:14 jnthn Because the old body pointer will be in the middle of a cleared out nursery, most likely
21:14 FROGGS I mean this: MVM_gc_root_temp_push(tc, (MVMCollectable **)&repr_data);
21:14 FROGGS that's still wrong, no?
21:14 jnthn That looks really wrong too :)
21:14 FROGGS k :o)
21:15 jnthn Speicherabzug!!
21:15 FROGGS \m/
21:15 jnthn Makes "Segmentation fault" sound really boring :P
21:18 FROGGS yes, German is slightly less boring than English :o)
21:18 * jnthn wonders what it'd be in Czech... :)
21:19 FROGGS sadly the behaviour does not change
21:21 jnthn What did you change to update body?
21:21 FROGGS body                       = OBJECT_BODY(root);
21:21 jnthn Yeah, should be enough
21:22 jnthn root is in an MVMROOT equivalent, yes?
21:22 FROGGS root is from: static void initialize(MVMThreadContext *tc, MVMSTable *st, MVMObject *root, void *data) {
21:22 FROGGS and I temp_root_push it
21:31 jnthn Yeah, that should be sufficient...
21:31 jnthn hmm
21:35 FROGGS is an STable collectable?
21:35 jnthn Yes
21:47 FROGGS gnight

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