|
00:19
japhb left
00:35
japhb joined
00:37
MasterDuke joined
|
|||
| MasterDuke | i have a branch where i added libffi as a 3rdparty submodule, build it, mostly removed dyncall, built moarvm using the 3rdparty libffi (i believe), and rakudo passes a `make m-test` and `make m-spectest` | 00:40 | |
| but what i'm not particularly looking forward to is trying to get moarvm to build libffi, especially in CI (since that involves macos and windows) | 00:41 | ||
|
00:57
japhb left
01:23
japhb joined
01:36
japhb left
01:41
japhb joined
01:42
MasterDuke left
01:47
japhb left
02:12
japhb joined
|
|||
| patrickb | MasterDuke: That's impressive! I'm willing to help. Which are you less fond of? Windows or MacOS? | 05:52 | |
| tellable6 | patrickb, I'll pass your message to MasterDuke | ||
|
06:14
timo2 left
06:17
timo2 joined
09:47
woodi joined
09:48
woodi left
09:50
woodi joined
|
|||
| patrickb | I'm still hunting why NativeCall callsites have one arg too many. | 14:07 | |
| I observe this with a vanilla moar as well. | 14:08 | ||
| What's the easiest way to introspect the byte code? I'd like to see if the callsite in the byte code has the correct arg count. | 14:11 | ||
| timo2 | if you have a .moarvm file, you can moar --dump it, if you have a frame on the stack and you're in gdb or lldb or so, you can call MVM_dump_bytecode(tc) or one of the other similarly named functions | 14:35 | |
| if it gets speshed at any point, setting MVM_SPESH_LOG=blabla.speshlog.txt gives you a file with boatloads of information, including the bytecode in unspecialized and specialized forms, which also has a little bit of information for callsites | 14:36 | ||
| patrickb: LMK if you need more | |||
| lizmat | patrickb: there's also raku.land/zef:lizmat/MoarVM::Bytecode which may be helpful? | 15:10 | |