| timo | i guess there is no shortage of different ways to apply instrumentation at the moarvm bytecode level | 09:57 | |
| instrumenting reprops could be interesting for the debugger so that you can break on modifications to specific objects, at a performance cost | 10:02 | ||
| Voldenet | 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:06 | |
| 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:08 | ||
| the last form I like the most because it's non-magical, but won't introduce 100 new options | 16:10 | ||
| and since it's for debugging, it can be kinda slow | 16:11 | ||
| timo | 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:14 | |
| then we don't have to build parsing and socket setup and what-not in C inside moar | 16:15 | ||
| Voldenet | 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:22 | |
| timo | yeah socat will support basically every single situation you could come up with | 16:29 |