runno

Oh awesome!! I've just added Trealla to my issues list to add it to Runno. If you go into settings you can switch stdin echo on/off. I have stdio devices set up to return their file type as "Character Device" (see: https://github.com/taybenlor/runno/blob/main/packages/wasi-m...). It seems like some binaries handle this well and act like they are directly connected to the TTY (e.g. my quickjs example). Not sure how they determine that. I'm very much coming at this from a web-developer interested in WASI direction, and not from any experience with OSes or linux. Edit: btw my WASI runtime (@runno/wasi-motor) is very much in "I haven't even released it as an NPM package" state but you're welcome to copy the code and use it https://github.com/taybenlor/runno/tree/main/packages/wasi-m...

Good spotto! That's an old WASI runtime from wasmerjs (https://github.com/wasmerio/wasmer-js). That's not the WASI runtime being used in this playground. The one in this playground is @runno/wasi-motor (https://github.com/taybenlor/runno/tree/main/packages/wasi-m...). I haven't released it as an NPM package, but it's all MIT so feel free to copy it.

UPDATE: I found it; here's the very nice core of his new WASI implementation -- https://github.com/taybenlor/runno/blob/main/packages/wasi-m... Original comment below: > " I went through and implemented the whole standard in TypeScript" Isn't this file in your code a big part of the implementing the WASI standard? [1] https://github.com/taybenlor/runno/blob/main/packages/wasi/s... I ask because you didn't write that. I was excited that you said " I went through and implemented the whole standard in TypeScript" since I have been working on that same code [1] as the core of this npm package https://www.npmjs.com/package/wasi-js and I've found some subtle bugs in it. I was excited to find another implementation to compare, so maybe you also did something else? Thanks! This is a very exciting space and I greatly appreciate your work.

memfs is very cool, but the WASI runner in this demo doesn't use it. I implemented my own virtual filesystem (see: https://github.com/taybenlor/runno/blob/main/packages/wasi-m...). Will look at the FS spec. I would hope that it would be shaped in a way that makes sense for WASI (brief look seems like it is). I'd also love it to be something that makes sense from the JavaScript side as well.

Score another point for memfs, the in-memory node.js fe impl (which if Im reading this right underpins your wasi fs impl). https://github.com/streamich/memfs Edit: apologies... your reply says you have you own impl! Damn, awesome! Apologies, I'd seen memfs in a dependencies here: https://github.com/taybenlor/runno/blob/main/packages/runtim... WHATWG recently took up File System Access spec as their FS spec. It both looks semi promising, but they seem to only care about & are only building specs for specifically emscripten wasm users. Only sync apis, only usable from dedicated workers... there's some hopes for more latter but feels super weird to see the web finally get fs access & have it be fast... but for it to be extremely odd shaped hand tailored to a very narrow class of use. https://fs.spec.whatwg.org/

Thanks! What's super neat here is that I didn't have to build that. The WASI standard defines `fd_fdstat_get` which tells the binary the type of the file descriptor. For stdin/stdout/stderr I return that it is a "Character Device" (https://github.com/taybenlor/runno/blob/main/packages/wasi-m...). QuickJS understands that means it's running in a TTY and so it emits all the right characters to do colouring. XTerm.JS then interprets those characters and displays the appropriate colours.