| MasterDuke | jnthn: do you have any suggestions for debugging? should things like numbers of fates match up exactly with the moarvm backend? | 02:00 | |
|
09:08
sena_kun joined
|
|||
| lizmat | MasterDuke: where would I find the logic for reading actualy bytecode needed from a file set up with nqp::loadbytecode ? | 12:19 | |
| this re: github.com/rakudo/rakudo/issues/5551 | |||
| jnthn | MasterDuke: Don't know for sure but I think the number of fates should be consistent, since those depend on the number of alternations or number of protoregexes | 12:39 | |
| Although we have a bunch of #?if moar stuff that in principle could be in the grammar | |||
| Geth | MoarVM/main: ebcbee7354 | (Elizabeth Mattijsen)++ | src/6model/serialization.c Don't allow lazy deserialization |
12:56 | |
| MoarVM/main: 73ec511c68 | (Elizabeth Mattijsen)++ | src/6model/serialization.c Revert "Don't allow lazy deserialization" This reverts commit ebcbee73546b2574b24bd00d1dd8fb95b491dc05. Eager serialization appears to have bitrotted |
15:58 | ||
| MasterDuke | jnthn: thanks. i was worried about `#?if moar`, but there are far fewer in nqp, and it looks like no relevant ones in the grammar, so hopefully i can get a decent comparison | 17:01 | |
| lizmat | github.com/MoarVM/MoarVM/blob/main...2780-L2796 feels like it describes what I'm seeing | 18:15 | |
| "stub the NQPClassHOW object, add deserialization request to work list, release lock and return the stub | 18:16 | ||
| but then again, I'm really out of my depth here :-( | 18:17 | ||
| Q: do we have any MoarVM bytecode inspection tool ? | 19:03 | ||
|
23:27
sena_kun left
|
|||
| MasterDuke | lizmat: i'm not aware of anything particularly targeting bytecode. there's --dump of course if you just want to see what itis | 23:33 | |
| jnthn, nine, or timo1 might know of something | 23:46 | ||