|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:42
moon-child joined
01:02
leont left
01:44
raku-bridge left
05:06
Kaiepi left,
Kaiepi joined
06:15
sena_kun joined
06:17
Kaiepi left,
Kaiepi joined
07:24
Altai-man joined
07:25
kawaii left
07:26
sena_kun left
|
|||
| nine | timotimo: in ye olden days the preprocessor was actually distinct from the compiler. Maybe one of gcc's gazillion switches makes it write out preprocessed C files (maybe even without expanding includes)? | 07:27 | |
|
07:28
kawaii joined
|
|||
| nwc10 | -E | 07:28 | |
| I don't think that you can avoid includes | |||
| good *, #moarvm | |||
| timotimo: does the debugging option -g3 enable you to single-step macros? | 07:29 | ||
| timotimo | nope, macro invocations are always considered "a single line" or whatever :( | 07:58 | |
|
08:13
mst left
|
|||
| timotimo | i wonder if the biggest problems i used to have were due to having to please the "initialization only at start of block" rule when rewriting mvmroot macros? | 08:48 | |
|
08:49
domidumont joined
|
|||
| MasterDuke | github.com/MoarVM/MoarVM/pull/1344 updated with all latest fixes. current situation is that nqp builds, but rakudo reliably panics or segfaults | 09:23 | |
| timotimo: have you tried the `macro` command in gdb? | 09:26 | ||
| timotimo | i have not! | 09:29 | |
| hm, that looks more like i can input a macro in gdb and have it tell me the expansion of a value i type in the command prompt | 09:30 | ||
|
09:48
MasterDuke left
11:19
leont joined
11:25
sena_kun joined
11:27
Altai-man left
11:31
MasterDuke joined
14:26
zakharyas joined
15:00
zakharyas left
15:04
zakharyas joined
15:24
Altai-man joined
15:26
sena_kun left
15:56
mst joined,
ChanServ sets mode: +o mst
|
|||
| MasterDuke | timotimo: btw, was this for something you're working on? or helping to debug my PR? | 16:06 | |
| timotimo | it was something i stumbled upon again in your PR | 16:08 | |
| but just in general | |||
| MasterDuke | ah. but speaking of, any further thoughts? | 16:10 | |
| timotimo | not yet | 16:11 | |
| you didn't post the entire results of the find missing roots script, did you? | |||
| MasterDuke | i can | 16:14 | |
| gist.github.com/MasterDuke17/618ff...b3da0afded | 16:16 | ||
|
18:27
brrt joined
19:03
zakharyas left
|
|||
| MasterDuke | does MVM_spesh_candidate_add still belong in the list of allocators in check-roots.py? | 19:09 | |
| timotimo | it does allocate, doesn't it? | ||
| MasterDuke | forget i asked that... | 19:10 | |
|
19:11
zakharyas joined
19:15
zakharyas left
|
|||
| MasterDuke | does github.com/MoarVM/MoarVM/blob/mast.../osr.c#L92 need to be an MVM_ASSIGN_REF? | 19:21 | |
|
19:24
sena_kun joined
19:26
Altai-man left
|
|||
| timotimo | that could be a good idea! | 19:28 | |
| that could explain why looking up dynamic lexicals breaks so often? because it goes via this pointer? | 19:29 | ||
| i finally got my desk chair back | 19:30 | ||
| MasterDuke | it had run off? | 19:31 | |
| timotimo | not quite | ||
| MasterDuke | still panics in the rakudo build | 19:32 | |
|
19:34
zakharyas joined
19:38
sena_kun left
|
|||
| MasterDuke | does this look correct? github.com/MoarVM/MoarVM/blob/mast...#L398-L406 the comment is worrying | 19:39 | |
| what about the couple places where `*->spesh_cand = NULL`? should it be marked before set to null? | 19:42 | ||
| timotimo | setting to null shouldn't need any specific handling | 19:53 | |
| i wonder if you've got a misconception about how the GC works when you say it should "be marked"? | 19:55 | ||
| MasterDuke | could be. how does it work? | 19:56 | |
| timotimo | marking is kind of a phase that in moar's gc happens all at once | 19:58 | |
| you wouldn't "mark an object" or "mark a pointer" at a random point in the code | |||
| when you root a pointer, we put it in a list of pointers that marking should start at | |||
| MasterDuke | MVM_gc_worklist_add puts something on the list to be collected, right? | 19:59 | |
| timotimo | and if the root is still in the list (remember, we pop things off all the time as well) when gc starts, it'll cause the target of the pointer to be marked, i.e. whatever lives at its end has its repr looked up and the gc_mark function called | 20:00 | |
| worklist_add is for use during marking, it's a simple datastructure that you can push stuff onto and pull stuff off of | |||
| and marking will pop stuff off the worklist until it's empty, and everything it pops off will again have its gc_mark invoked | 20:01 | ||
| whenever we have code that does worklist_add, we're in one spot responsible for one kind of datastructure and the GC wants us to tell it all pointers that it needs to care about | |||
| we have stuff like add_frame_roots and add_instance_roots because some of our objects aren't proper collectables; threadcontext and instance for one, but there's also frames that live on a "stack" where no headers exist, so they get marked differently, too | 20:03 | ||
| MasterDuke | good to know | 20:04 | |
| timotimo | i hope more clarity can help think about how the code should be more clearly? | 20:05 | |
| MasterDuke | let's hope | ||
| timotimo | also, explaining stuff also helps the explainer understand | 20:13 | |
| lizmat | that's why rubberducking works :-) | 20:17 | |
| timotimo | i can also ask for something and almost immediately find the solution myself | 20:18 | |
| don't have a good name for it, it'd be something like "shame-driven discovery"? | |||
|
20:36
domidumont left
21:00
brrt left
21:27
zakharyas left
|
|||
| timotimo | let's see if a 2 years past due bottle of blackberry cider is still okay | 21:51 | |
| it seems okay | 22:08 | ||
|
22:09
leont left
|
|||