Add WASM support

[cowboyd]

I'm trying to build a high-level TUI framework for JavaScript using Clay that ideally would not require any native compilation or FFI. Currently, I am compiling to wasm, and this allows it to trivially run on Node, Deno, and Bun without any headaches, but it means that I have to write my renderer by hand in JavaScript. I learned recently though that there is already a termbox2 renderer for Clay which would be amazing to be able to use. However, it does require compiling Termbox2 to WASM-WASI which I haven't had so much luck with.

The rub is that WASI has limited support for signals and no support for termios.h at all and so I'm wondering if there is a way forward.

Node, Deno and Bun do support signal handling as well as setting streams into raw mode from JavaScript, so would it be possible to allow somehow allowing for inverting control and delegating configuration of the terminal to the host environment?

Here is an example repository I have set up demonstrating the issue. https://github.com/cowboyd/termbox2-wasm-test

Any thoughts on if this would be possible?

[adsr]

Interesting, I saw your latest commits on the repo. Is WASIX solving your problem?

I posted a PR for Windows support this evening. It's relevant because Windows also lacks termios.h. Earlier PRs for Windows support were ifdef-based, which added bloat and harmed readability. The trade-off didn't seem worth it for a niche use case. So this time I wrote a shell script that does the necessary surgery on termbox2.h to produce a Windows-compatible version. It's a handful of sed/awk commands that should remain fairly stable over time. I prefer it over ifdef-hell. We could do something similar for WASM.

[cowboyd]

Well, the upshot was that I was able to compile it against WASIX, but when I actually tried to run the resulting executable with wasmer, It just exited immediately without actually waiting for the two keypress, so not really sure what's going on there.

I filed an issue here wasmerio/wasmer#5859 so we'll see if anybody can shed any light on it.

In the mean time: yes, maybe we could do something similar for WASM? That sounds amazing!

[adsr]

I tried running through termbox2-wasm-test and got different output, including a segfault if I ran it with the v8 runtime. I tried stepping through the coredump with wasmgdb following an article I found but that also failed. I guess due to version mismatches.

[cowboyd]

If you're compiling against WASIX, then the only runtime you can use is wasmer, so you either need to use the wasmer CLI, or if you're loading it into a javascript runtime like v8, then I think you need to use@wasmer/sdk to properly link at runtime.

[adsr]

I'd like to invest some time learning about WASM and JS runtimes before I pick this up again. In the mean-time I'm subscribed to wasmerio/wasmer#5859 and here. Feel free to ping again when we get to the point where we know the cut points we need as you described here. I'll hold off merging the Windows PR for a bit in case it can be generalized.

[cowboyd]

After playing around with WASI and WASIX, it would be better to target WASI rather than WASIX since most runtimes seem to have reasonable support for it, WebKit, Deno, Node, Bun, etc... and then have extension points for signal and terminal handling.

[adsr]

Good to know. I noticed the current draft for WASI 0.3 includes a terminal interface:

https://github.com/WebAssembly/WASI/blob/main/proposals/cli/wit-0.3.0-draft/terminal.wit

There are some "in the future" comments that sound like what we'd want.

[cowboyd]

The "future" comments do seem to be exactly what we want, but the timeline is opaque. Given the rate that they move it could be weeks, or it could be years before it arrives.

One option to have it now would be to have a platform abstraction around the terminal interaction which is kind what's happening in #123 If there is a finite set of abstract tb_ functions that term box uses for terminal so that we don't have to include termios.h, then we can link implementations of those functions from from NodeJS or the Browser when we load the WASM module.