[00:01] *** squashable6 joined [00:24] *** lucasb left [00:30] *** Kaiepi joined [00:31] *** Kaiepi left [01:00] *** Kaiepi joined [01:34] *** ZzZombo_ joined [01:36] *** squashable6 left [01:36] *** ZzZombo left [01:36] *** ZzZombo_ is now known as ZzZombo [01:38] *** squashable6 joined [02:54] *** ZzZombo_ joined [02:58] *** ZzZombo left [02:58] *** ZzZombo_ is now known as ZzZombo [03:12] ¦ MoarVM: vrurg++ created pull request #1203: [WIP] Sample code for stringification and printing of internal structures [03:12] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1203 [03:14] *** Geth joined [03:47] *** squashable6 left [03:48] *** squashable6 joined [05:09] *** evalable6 joined [06:18] *** domidumont joined [06:36] *** domidumont left [06:41] .tell vrurg do you know about DEBUG_HELPERS, MVM_dump_p6opaque and MVM_dump_bytecode? [06:41] nine, I'll pass your message to vrurg [06:49] *** sena_kun joined [07:14] *** MasterDuke joined [08:13] *** sena_kun left [09:34] *** domidumont joined [09:44] *** domidumont left [09:45] *** domidumont joined [10:04] *** Guest13443 joined [10:43] *** sena_kun joined [11:20] *** AlexDaniel left [11:20] *** AlexDaniel joined [11:20] *** AlexDaniel left [11:20] *** AlexDaniel joined [11:23] *** vrurg left [12:07] *** AlexDaniel left [12:10] *** lucasb joined [13:10] *** AlexDaniel joined [13:10] *** AlexDaniel left [13:10] *** AlexDaniel joined [13:12] *** hankache joined [13:16] *** AlexDaniel left [13:22] *** vrurg joined [13:30] . [13:30] 2019-10-23T06:41:38Z #moarvm vrurg do you know about DEBUG_HELPERS, MVM_dump_p6opaque and MVM_dump_bytecode? [13:34] .tell nine I didn't know about those. Overlooked DEBUG_HELPERS while was grepping for DEBUG. Will look into these, thanks! [13:34] vrurg, I'll pass your message to nine [13:57] vrurg: there's also the stuff in the debugserver that turns objects into messagepack structures [13:57] if there's a little python plugin in gdb, it could most probably turn that back into human-readable immediately [14:02] timotimo: I know about the python plugin but it's rather limited. The debug server is for debugging NQP/Raku but there is little for debugging moar itself. Not for tracing mode. Two dump functions mentioned by nine is basically everything. [14:05] Besides, I'm trying to make it unified and centralized. I.e. have stringifiers which just produce list of strings. Where and how they're to be used it up to a dev. Plus the possibility in the future to sync tracing with higher level code by turning debug flag on/off when needed. And currently fprintf often mess up with say/note output. [14:07] Just came to my mind that stringifiers could produce hashes instead of strings. [14:08] keep in mind that that will allocate [14:11] you mean memory consumption? [14:12] it will run the GC [14:12] if the user is supposed to run that as an nqp:: command, that's fine [14:12] but if you're expected to call it from gdb, or insert it in random places in the code, there'll have to be rooting considerations [14:15] In code – yes, I understand this. Use from gdb should be possible if it's just something like `call dump_MVMObject(tc, obj)` [14:16] But that will also alter the GC's state which will make them much less useful for debugging GC issues [14:16] 2019-10-23T13:34:49Z #moarvm nine I didn't know about those. Overlooked DEBUG_HELPERS while was grepping for DEBUG. Will look into these, thanks! [14:17] Also they can fail spectacularily when called in the middle of a GC run - which is often the case with the mentioned GC issues [14:22] Then it makes sense to turn to simper structure. And I should use neither MVMArray nor MVMString too. [14:25] *** hankache left [14:27] a GDB plugin can do memory accesses without causing crashes in the user program [14:30] But it's limited in functionality. :( Perhaps I wouldn't start this if there'd be other way to introspect structures. Especially MVMStrings. [14:31] what do you mean "it's limited in functionality"? [14:34] It only supports MVMObjects and I did't manage to get it working with MVMString a while ago. [14:34] that's not a limitation of gdb plugins [14:35] i'm not saying "use the gdb python plugin", i'm saying "we could add to the gdb python plugin" [14:35] Sorry, I meant exactly what you're saying. :) [14:35] gdb python plugins can do everything gdb can do [14:36] Unfortunately, I don't know python and not gonna learn it just for a plugin. [14:36] yeah, the gdb python interface is also *enormously* annoying to use [14:37] not to mention slow [14:37] well, slow-ish [14:37] it's not fast enough to go through the entire nursery and check all objects for their type and some values in less than like half a minute [14:39] So, maybe it makes sense then to provide means for faster introspection? Less handy though. [14:40] I'm still in doubt if it makes sense to continue the work or just use it for my current task and then stash somewhere for personal use. [14:40] in my experience, calling functions from gdb can completely destabilize a running session [14:40] not to speak of rr replay [14:41] This I know well. Last time I tried dumping MVMStrings and it was ending up with total lockup. [14:42] To dump strings I just use "call MVM_string_utf8_encode_C_string(tc, thestring)" [14:42] doesn't that malloc? [14:43] It does. But that's usually ok [14:43] mhh [14:43] nine: How would you dump lexical names in a frame? [14:44] It's a hash, if I'm not mistaken. [14:45] Ok, unfortunately, I need to run. Will follow later. Thanks! [15:11] *** domidumont left [15:43] *** domidumont joined [15:44] *** Guest13443 left [16:01] *** mtj_ left [16:16] *** Altai-man_ joined [16:17] *** Altai-man_ left [16:18] *** Kaiepi left [16:19] *** sena_kun left [16:33] *** AlexDaniel joined [16:33] *** AlexDaniel left [16:33] *** AlexDaniel joined [17:00] *** domidumont left [17:17] *** domidumont joined [18:20] *** domidumont left [18:25] *** Kaiepi joined [20:21] *** MasterDuke left [22:12] *** ggoebel left