This allows you to send stdout/stderr back to the 3dslink invocation, which will probably be really nice for graphical applications where you need both screens, etc. We might also consider putting it in the test runner (maybe as a feature flag or CLI arg?)
I'm not 100% sure about this API, maybe it would make sense to have separate redirect_stdout() and redirect_stderr() functions instead of just the one? I also wasn't sure it should be on Soc, but you have to initialize Soc before you can use this so it seemed like a somewhat reasonable place to have it.
Next up, I would probably like to add cargo-3ds support for this so you could do cargo 3ds run --server or something like that, instead of manually invoking it like I have done here.
Also, I fixed a broken thread-info compilation which was a small change.
@Meziu @AzureMarker
This allows you to send stdout/stderr back to the
3dslinkinvocation, which will probably be really nice for graphical applications where you need both screens, etc. We might also consider putting it in the test runner (maybe as a feature flag or CLI arg?)I'm not 100% sure about this API, maybe it would make sense to have separate
redirect_stdout()andredirect_stderr()functions instead of just the one? I also wasn't sure it should be onSoc, but you have to initializeSocbefore you can use this so it seemed like a somewhat reasonable place to have it.Next up, I would probably like to add
cargo-3dssupport for this so you could docargo 3ds run --serveror something like that, instead of manually invoking it like I have done here.Also, I fixed a broken thread-info compilation which was a small change.