|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:00
moon-child joined
00:06
dogbert2 joined
00:08
dogbert17 left
00:20
sivoais left
00:21
sivoais joined
03:07
squashable6 left
03:09
squashable6 joined
08:19
domidumont joined
08:28
MasterDuke joined
|
|||
| MasterDuke | . | 08:47 | |
| tellable6 | 2021-01-19T23:27:21Z #moarvm <jnthn> MasterDuke Sorry, was afk/distracted for quite a while. Yes, sounds reasonable. | ||
| MasterDuke | jnthn: no worries, i'd gone ahead with doing that | 08:53 | |
| hm. in stat.c i added `case MVM_SPESH_LOG_DEOPT: { if (e->deopt.spesh_cand->body.deopt_count++ > 100) MVM_repr_push_o(tc, sf_updated, (MVMObject *)e->entry.sf); break; }`. but in plan.c where it's looping over the updated_static_frames, i won't have the spesh candidate | 09:01 | ||
|
09:19
mst joined,
ChanServ sets mode: +o mst
09:31
zakharyas joined
|
|||
| jnthn | MasterDuke: No, but you can walk over the candidates to see which of them are over the limit? | 10:03 | |
| e.g. for each frame, look at its candidates and see if any are good for removal? | |||
| MasterDuke | oh, right. they all are attached to the static frame | ||
|
10:08
domidumont1 joined
10:10
domidumont left
10:26
MasterDuke left
|
|||
| nine | geth down? | 11:22 | |
| github.com/MoarVM/MoarVM/commit/79...c918b5674d | |||
| Fix size calculation of VMArray's (read|write)_buf when elem_size > 1 | |||
|
11:59
travis-ci joined
|
|||
| travis-ci | MoarVM build passed. Stefan Seifert 'Fix size calculation of VMArray's (read|write)_buf when elem_size > 1 | 11:59 | |
| travis-ci.org/MoarVM/MoarVM/builds/755334225 github.com/MoarVM/MoarVM/compare/2...d0e3749ac2 | |||
|
11:59
travis-ci left
12:26
zakharyas left
12:42
MasterDuke joined
|
|||
| MasterDuke | heh. in worker.c `/* Implement the plan and then discard it. */ <...> for (i = 0; i < n; i++) { MVM_spesh_candidate_add(tc, &(tc->instance->spesh_plan->planned[i])); GC_SYNC_POINT(tc); }` that's the opposite of what i want to do! | 12:46 | |
| jnthn | Yup, prior to now plans only specified things to add :) | 12:48 | |
| nine | the plan giveth, the plan taketh away... | 13:25 | |
|
13:32
zakharyas joined
14:03
MasterDuke left
14:36
MasterDuke joined
|
|||
| MasterDuke | this is a new one: `MoarVM panic: Spesh arg guard: expected 1 candidate but got 2` | 14:58 | |
| jnthn | With luck, an internal sanity check that will save some even more tedious debugging... | 15:15 | |
| The arg guard is much less terrifying than it used to be | |||
| I used to try and tweak it in place | |||
| Once I got to doing derived specialations I realized I wasn't smart enough to implement that, and just regenerated it from the candidates. | 15:16 | ||
| Well, it wasn't exactly in place, but it was "a cheap memcpy and then update the copy" | |||
| MasterDuke | i sort of remember you making that change. of course i have no idea why that's happening. the code calling regenerate hasn't really had any change to the number of candidates called with at that point (i think) | 15:18 | |
|
17:20
sena_kun joined
17:37
domidumont1 left
17:54
japhb left
17:58
MasterDuke left
18:23
japhb joined
19:07
sena_kun left
19:34
zakharyas left
20:10
patrickb joined
20:26
MasterDuke joined
21:02
MasterDuke left
21:59
patrickb left
|
|||