|
00:38
Unavowed joined
01:00
lizmat joined
03:05
mojca joined
03:09
FROGGS joined
03:21
colomon joined
04:37
vendethiel joined
05:04
leedo joined
07:00
domidumont joined
07:04
domidumont joined
07:07
mojca joined
07:14
domidumont joined
07:47
FROGGS joined
07:52
domidumont joined
|
|||
| dalek | arVM/heap-profiler: 09a807b | timotimo++ | src/profiler/heapsnapshot.c: make strings in heap snapshot easier to parse by dropping the trailing semicolon |
07:58 | |
| timotimo | having to put a "next unless" in my parser annoyed me, so i decided to drop the trailing semicolon long before output | ||
| strange. i see a bunch of collectables here that have a non-zero index into the references list, but claim they have 0 references | 08:05 | ||
| that's either a bug, where we're losing references, or it's an opportunity to save a few bytes in the output by dropping the index, too | 08:06 | ||
| i created a new API function for adding a permanent root with a description and changed all occurences in moarvm | 08:19 | ||
| dalek | arVM/heap-profiler: 2e60416 | timotimo++ | src/ (12 files): root_add_permanent was API, so _desc gets a new function. without description, it'll just put a <??> into the description field |
08:21 | |
| arVM/heap-profiler: 9d871d4 | timotimo++ | src/profiler/heapsnapshot.c: we always set the refs_start, even if num_refs is 0 so we can drop a few bytes of output by resetting it to 0 if there are no refs at all. |
|||
| timotimo | there's those things | ||
|
08:24
mojca joined
08:41
zakharyas joined
|
|||
| jnthn | timotimo: The index is where the references would be | 09:26 | |
| 0 is a valid index too so it's no less confusing that way... :) | |||
| Smaller though :) | |||
|
10:18
lizmat joined
10:24
TimToady joined
10:35
vendethiel joined
11:32
vendethiel joined
|
|||
| timotimo | jnthn: feel very free to dump (haha) my commit that dumps the heap data and push your own dump code over it | 14:07 | |
|
14:21
colomon_ joined
14:29
mojca joined
14:51
mojca joined
|
|||
| jnthn figures he'll spend that last bit of the working week on the profiler :) | 16:16 | ||
| Well, heap dumper | |||
| timotimo | wow, holy crap, did you see this. Feathers 2.0 is a real-time javascript framework | 16:25 | |
| i really didn't expect this would be possible at all | |||
| or could it be they are just saying "real-time" and not understanding what that means, like, at all? | 16:29 | ||
| jnthn | "real time web"? | 16:31 | |
| Which is nothing to do with real time | |||
| timotimo | "A minimalist real-time framework for tomorrow’s apps" | 16:33 | |
| is "real time web" something that actually means something? | |||
| jnthn | Well, I think mojo calls itself a real time web framework... | ||
| It'd be better named pushy web | 16:34 | ||
| timotimo | comety web :) | ||
| jnthn | As it seems to largely revolve around applications to push stuff out to the browser :) | ||
| timotimo | comet me, bro | ||
| jnthn | :D | ||
| The terminology was probably coined in JavaScript land though :P | |||
| timotimo | OK, i wouldn't expect javascript engineers to be acutely aware of what "real-time" means | 16:35 | |
| jnthn | aye :) | ||
| timotimo | it's out of reach to them. and also not useful to them at all | ||
| when will perl6 allow for real-time stuff? :) | |||
| jnthn | Technically I suspect you could do hard real-time programming in JavaScript. But...probably not on v8 :) | ||
| timotimo | actually, i haven't a clue what that actually entails | ||
| jnthn | Since you'd likely depend on a real time GC for starters | ||
| timotimo | yeah, that's one of the hard parts | ||
| jnthn | I only ever worked at one place doing hard realtime stuff | 16:36 | |
| timotimo | though, of course real-time GC is easy to do if you're allowed to use infinitely much ram :D | ||
| jnthn | (Of the "if we miss the deadlines people can die" kind) | ||
| timotimo | aye | ||
| i shouldn't allow myself to get so worked up over terminology | 16:38 | ||
| jnthn | :) | 16:39 | |
| timotimo | just like when i see someone show off their latest "speed painting" ... and then it turns out it's a timelapse of slow/regular-speed painting | ||
| jnthn grins at the union with members ric and erized | 16:41 | ||
| timotimo | unionric and unionerized? huh? | ||
| jnthn | st->paramet.erized.parametric_type, st->paramet.ric.lookup, etc. :) | 16:42 | |
| timotimo | oooh | 16:43 | |
| dalek | arVM/heap-profiler: fd54ad0 | jnthn++ | src/profiler/heapsnapshot.c: Include all STable data into heap snapshot. |
16:50 | |
| arVM/heap-profiler: 15569ad | jnthn++ | src/profiler/heapsnapshot.c: Add missing snapshot collection cleanup. |
16:54 | ||
| jnthn | I think that just leaves call frames, in order to actually cover all the data on the heap | 16:55 | |
|
17:08
FROGGS joined
17:17
mojca joined
|
|||
| dalek | arVM/heap-profiler: 5ead72d | jnthn++ | src/profiler/heapsnapshot. (2 files): Build up static frames info table. So we'll be able to understand where call frames in the heap come from. |
17:25 | |
| jnthn | Enough for now :) | ||
| timotimo | i already wondered if we want to output a stack trace for each of the heap snapshots, too | 17:38 | |
| but i suppose that's more or less what we'll get now | |||
| jnthn: could you also push your dumping code into a branch or something? so that i don't duplicate your work (in an inferior manner, probably) again? ;) | |||
|
17:40
mojca joined
|
|||
| timotimo | jnthn: do you want me to go ahead and build some kind of output stuff for the static frames? i don't see them get output'd anywhere yet | 17:41 | |
|
18:01
domidumont joined
18:15
colomon joined
18:51
mojca joined
19:27
mojca joined
19:52
cognominal joined
20:47
zakharyas joined
20:59
vendethiel joined
21:16
zakharyas joined
21:22
pochi joined
21:25
btyler joined,
mst joined
21:26
diakopter joined
22:52
colomon joined
|
|||