[09:57] i guess there is no shortage of different ways to apply instrumentation at the moarvm bytecode level [10:02] instrumenting reprops could be interesting for the debugger so that you can break on modifications to specific objects, at a performance cost [16:06] well, if you really need that remote access then maybe call it `bind-insecure-remote-debug` and have the format be mutable over time [16:08] so you can support multiple formats, like `ipv4:wg0:0.0.0.0:8080` or `192.168.34.42:8080` or maybe `host=0,port=80,iface=enp0s1` [16:10] the last form I like the most because it's non-magical, but won't introduce 100 new options [16:11] and since it's for debugging, it can be kinda slow [16:14] you know, if you're debugging moarvm, you probably have a rakudo right there, so why not ship a little bridging tool with rakudo that does the forwarding including maybe some light access control [16:15] then we don't have to build parsing and socket setup and what-not in C inside moar [16:22] practically I'd attempt something like `socat TCP-LISTEN:8080,bind=0.0.0.0,so-bindtodevice=enp0s1,reuseaddr,fork TCP:127.0.0.1:8080` [16:29] yeah socat will support basically every single situation you could come up with