You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Does the current spec allow for things like ioctl and termios? #42
I opened this issue on my project: torch2424/wasm-matrix#1 . Which Essentially comes down to, I can't figure out how to get the terminal size using the current available Wasi bindings.
I think what I would need from Wasi is someway to use a the underlying effect of C's ioctl or termios. Is this something you can do with the current WASI bindings? If so, how? If not, is this planned to be done at some point? I understand that Wasm / Wasi are super young, so no worries if it is planned, not looking for an ETA or anything.
These assume your program's stdout is connected to an ANSI-style terminal. However, the kind of portability we're aiming for with WASI extends beyond platforms like Unix which tend to have ANSI-style terminal emulation. So while this is a neat program with a unique visual effect, enabling programs that only work on one kind of platform isn't the goal we're really aiming for here.
With WASI, we're really looking at the long term. Enthusiasm and cool demos in the short term are fun, but to make progress towards our ultimate goals we must also distinguish between things which show off what WASI can actually do, and things which reach outside of what WASI can do and give false impressions, and potentially distract from the work needed to reach our goals.
It is likely that in the future WASI will add ways to do color output, cursor positioning, and then also terminal size detection, and so on, and it could conceivably do so in a way that's compatible with ANSI escape codes. If someone is interested in starting a proposal to spell out what functionality would be required, and what the interfaces should be, that'd be a great place to start!
I’d have to look at their code to be sure, but looking at how JetBrains IDEs or Atom or VSCode handle terminals could show us how to make OS neutral terminal APIs since they all have MacOS, Linux, and Windows support.
I’d have to look at their code to be sure, but looking at how JetBrains IDEs or Atom or VSCode handle terminals could show us how to make OS neutral terminal APIs since they all have MacOS, Linux, and Windows support.
I've worked on an IDE plugin for Atom as an end-of-study project.
To spawn an integrated terminal, we used nuclide-prebuilt-libs/pty, which is a precompiled binary of node-pty, which is also what VS-code uses.
As far a compatibility goes, it looks like node-pty is based on the POSIX function forkpty, with bindings to ConPTY for Windows compatibility. I have no idea whether any of this is relevant to WASI.
Activity
sunfishcode commentedon May 23, 2019
The short answer is no, this isn't possible within the current WASI API.
Beyond that, there are several things which are unportable about the code, for example:
These assume your program's stdout is connected to an ANSI-style terminal. However, the kind of portability we're aiming for with WASI extends beyond platforms like Unix which tend to have ANSI-style terminal emulation. So while this is a neat program with a unique visual effect, enabling programs that only work on one kind of platform isn't the goal we're really aiming for here.
With WASI, we're really looking at the long term. Enthusiasm and cool demos in the short term are fun, but to make progress towards our ultimate goals we must also distinguish between things which show off what WASI can actually do, and things which reach outside of what WASI can do and give false impressions, and potentially distract from the work needed to reach our goals.
It is likely that in the future WASI will add ways to do color output, cursor positioning, and then also terminal size detection, and so on, and it could conceivably do so in a way that's compatible with ANSI escape codes. If someone is interested in starting a proposal to spell out what functionality would be required, and what the interfaces should be, that'd be a great place to start!
KronicDeth commentedon May 23, 2019
I’d have to look at their code to be sure, but looking at how JetBrains IDEs or Atom or VSCode handle terminals could show us how to make OS neutral terminal APIs since they all have MacOS, Linux, and Windows support.
dumblob commentedon May 24, 2019
@leonerd could you maybe sketch your view on this? Especially in accordance to the last paragraph in the comment of @sunfishcode above.
PoignardAzur commentedon Jun 30, 2019
I've worked on an IDE plugin for Atom as an end-of-study project.
To spawn an integrated terminal, we used
nuclide-prebuilt-libs/pty, which is a precompiled binary of node-pty, which is also what VS-code uses.As far a compatibility goes, it looks like node-pty is based on the POSIX function
forkpty, with bindings toConPTYfor Windows compatibility. I have no idea whether any of this is relevant to WASI.sunfishcode commentedon Sep 26, 2019
The original question has been answered here. If anyone has any further questions, feel free to file new issues!
FF WASI submodule and update the machinery (WebAssembly#42)
Change repr of char8 from char to u8 (WebAssembly#43)
chore: update example-world to imports (WebAssembly#42)
Change the clocks API from pseudo-handles to link-time authority (Web…
Merge pull request WebAssembly#42 from WebAssembly/fix-new-fields
Support building for WASM