|
01:36
ggoebel115 joined
01:40
TimToady joined
01:48
ilbot3 joined
04:14
mtj_ joined
06:01
domidumont joined
06:07
domidumont joined
06:26
lizmat joined
|
|||
| dalek | arVM: d0243ee | (Jimmy Zhuo)++ | src/6model/serialization.c: Update more serialization from int32 to varint. This reduces rakudo core setting size about 33KB. |
06:34 | |
|
08:20
Ven joined
09:50
zakharyas joined
|
|||
| dalek | arVM/serialization_int: 35a4f35 | (Jimmy Zhuo)++ | src/6model/serialization.c: Update more serialization from int32 to varint. This reduces rakudo core setting size about 512 KB. |
11:02 | |
| arVM/serialization_int: 32b9ffe | (Jimmy Zhuo)++ | src/6model/serialization.c: Update more serialization from int32 to varint. This reduces rakudo core setting size about 512 KB. |
11:06 | ||
| arVM/serialization_int: 225719f | (Jimmy Zhuo)++ | src/6model/serialization.c: Update more serialization from int32 to varint. This reduces rakudo core setting size about 512 KB. |
11:44 | ||
| arVM: cd5dfcf | (Jimmy Zhuo)++ | src/6model/serialization.c: Update more serialization from int32 to varint. This reduces rakudo core setting size about 512 KB. |
12:01 | ||
| arVM: 89d185e | (Jimmy Zhuo)++ | src/6model/serialization.c: rename a function name, so it's easy to find |
12:36 | ||
|
13:00
Ven joined
|
|||
| timotimo | the heap profiler needs a bit of work related to reframe, i think. it seems to reliably stumble over pointers that make no sense | 14:49 | |
| huh. even with moar and rakudo checked out to a pre-reframe commit, i get a frame that's 0x0 in process_workitems | 15:04 | ||
| well, an item with its .target set to 0x0 | |||
| timotimo doesn't have brane today, like, at all | 15:08 | ||
|
16:08
cognominal joined
|
|||
| jnthn | timotimo: No brane here either, alas, but I'll see if I can figure it tomorrow... :) | 16:38 | |
|
18:16
domidumont joined
19:45
dalek joined
19:46
dalek joined
19:47
dalek joined
19:48
dalek joined
19:55
ilbot3 joined
|
|||
| timotimo | i'll pepper a few aggressive checks into worklist_add or something, and see where the data comes from | 20:25 | |
|
20:38
cognominal joined
|
|||
| timotimo | 925 | 21:48 | |
| NULL REPR in item added to GC worklist | |||
| there we go | |||
| it's gc_mark of MVMCode, it seems like | 21:53 | ||
| gist.github.com/timo/9eae73b3f6330...6caa5d4274 - so the frame (in outer) is a heap-promoted frame, yet its st and everything is nulled out. that's what the heap snapshot taking code is stumbling over | 21:58 | ||
| so it could either be we're missing an extra case in the heap snapshot thing for MVM_CF_FRAME, or something isn't setting the st on the frame object when promoting or something | 22:02 | ||
| i'm expecting it'd be the former. on the other hand, i did checkout a moar before reframe and it also segfaulted on the code i wanted to profile ... :\ | |||
| cool, i threw out the diagnostic panic and it runs to completion apparently | 22:07 | ||
| but in another program it segfaults ... | 22:08 | ||
| same problem again, too | 22:09 | ||
| so ... was i barking up the wrong tree perhaps? :\ | |||