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

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!