Yep! I definitely want to build on and learn from existing patched versions of Python running in the web. Do you know what you folks do for synchronous I/O calls?
Of course. It will be nice to have the upcoming Python 3 version of Ren'Py based on the main branch, so we don't have to maintain patches.
Right now, most of the I/O is synchronous - the files are downloaded to the browser before a game starts, so all of the calls are fast, so far as I can tell, as they're happening within the browser.
Output is through SDL, and there's a call into a cython-defined function that calls __emscripten_sleep, with the path of calls to it listed in the ASYNCIFY_WHITELIST. That's the only place we block. (It's a bit late, so I might be misremembering the exact emscripten function.)
Yes, currently input goes into a propmpt() and it doesn't output anything unless you hit "Cancel" on the prompt, definitely a bad time.
Python allows you to reach in and replace the core interpreter loop, so this may be an avenue to have our own asyncify-like function pop out to JS land and restore state correctly (which we can be smart about since we are the interpreter).
This is definitely the hardest part of getting Python to work. Well, hardest after the hardest part of building a compiler toolchain like Emscripten :)
In WebAssembly.sh (https://github.com/wasmerio/webassembly.sh) they run WASM binaries in a Web Worker and then use `SharedArrayBuffer` to block the WebWorker while the main thread does some work (e.g. collect input). You could use a similar solution.
When building Runno (https://runno.dev) I forked off that project and did a bunch of other things on top to get blocking to work in Safari and non-cross-origin-isolated contexts.
Ultimately I think it's JavaScript's (or whichever host language) responsibility to block when the binary calls out (if that is the expected semantics).
Does the SharedArrayBuffer approach offer any way to tell the OS scheduler to wait? Because the only waiting method I know of is busy waiting, aka wasting cycles at 100% of a CPU core. In normal processes you can call a sleep function, which saves CPU cycles, but there is no synchronous method for that available in javascript.
WASM can already access the DOM by calling out into Javascript. AFAIK interface types wouldn't change that approach much, except that the mapping between numeric ids and Javascript object references doesn't need to be handled by the JS shim anymore.
So the answer to the question "Can WASM access the DOM?" is both yes and no, always has been, and probably always will be ;)
Brython is a complete re-implementation of Python, thus it doesn't support some features/libraries (at least, it didn't when I tried it last), and is not compatible with C extensions.
The demo I put in the tweet is the same code as when you type `python3` in the terminal, just running in the browser. So it is much more compatible and is mostly [1] feature complete.
[1] minus whatever libraries are likely never to be used that we ripped out
It is definitely too early for benchmarks, this is a "I got it working!" update.
The original data file with all of the standard library was a bit over 200MB. Slashing what isn't going to be run in the browser (e.g. tkinter) and zipping the standard library got it down to about 20MB. There is probably more that could be removed, and there are modules we don't need to build that we currently do. There are other things we can do like set the less frequently used modules to be loaded asynchronously.
While I doubt this will be production ready "soon", I do hope to keep working on fixing bugs and such.
