Modifies the Emscripten build script to allow for caching of dependencies, and
for automated installation of new EMSDK versions.
Co-authored-by: Russell Keith-Magee <russell@keith-magee.com>
Modifies the Emscripten build script to allow for custom cross-build directory
names, and to only clean Emscripten-specific paths (optionally including the
build python).
Co-authored-by: Russell Keith-Magee <russell@keith-magee.com>
Adds an `--emsdk-cache` argument to the Emscripten build script and an
emscripten_version.txt file. If the `--emsdk-cache` argument is passed, the build script
will look in `emscripten_version.txt` to get the expected emsdk version is installed in
a folder called e.g., 4.0.12 in the directory indicated by the `--emsdk-cache` argument,
and run the build with that Emscripten tooling activated.
Along the way, leave a deprecated Tools/wasm/wasi/__main__.py behind for backwards-compatibility.
Co-authored-by: Zachary Ware <zachary.ware@gmail.com>
It should make it easier when you need to rebuild just the e.g. host Python, but it requires ./configure to run.
Co-authored-by: Emma Smith <emma@emmatyping.dev>
This introduces a Wasmtime configuration file to get some CLI options out of the code for easier manipulation. It also allows for easier tweaking after the Makefile is generated.
As well, cut back on the flexibility of specifying HOSTRUNNER for simpler code. The flexibility was never used and so it didn't make sense to keep it around.
This commit updates CI and configuration from wasi-sdk-25 to wasi-sdk-29
which was released recently. This notably includes stubs for pthreads
which all return errors, so some adjustment in logic is necessary to
retain knowledge that WASI cannot yet spawn threads for example.
This additionally increases the wasm stack allowance to 32MiB from 16MiB
to accomodate the `test_recursive_pickle` test in the
`test_functools.py` file. It looks like the Clang/LLVM update that
happened in wasi-sdk-29 relative to wasi-sdk-25 is likely the cause of
this where presumably functions have more locals than before and/or a
slightly adjusted stack space requirement which overflows the stack.
With https://github.com/llvm/llvm-project/pull/150201 being merged, there is
now a better way to generate the Emscripten trampoline, instead of including
hand-generated binary WASM content. Requires Emscripten 4.0.12.
Basic support for pyrepl in Emscripten. Limitations:
* requires JSPI
* no signal handling implemented
As followup work, it would be nice to implement a webworker variant
for when JSPI is not available and proper signal handling.
Because it requires JSPI, it doesn't work in Safari. Firefox requires
setting an experimental flag. All the Chromiums have full support since
May. Until we make it work without JSPI, let's keep the original web_example
around.
Co-authored-by: Łukasz Langa <lukasz@langa.pl>
Co-authored-by: Éric <merwok@netwok.org>
This is useful for implementing proper `input()`. It requires the
JavaScript engine to support the wasm JSPI spec which is now stage 4.
It is supported on Chrome since version 137 and on Firefox and node
behind a flag.
We override the `__wasi_fd_read()` syscall with our own variant that
checks for a readAsync operation. If it has it, we use our own async
variant of `fd_read()`, otherwise we use the original `fd_read()`.
We also add a variant of `FS.createDevice()` called
`FS.createAsyncInputDevice()`.
Finally, if JSPI is available, we wrap the `main()` symbol with
`WebAssembly.promising()` so that we can stack switch from `fd_read()`.
If JSPI is not available, attempting to read from an AsyncInputDevice
will raise an `OSError`.
Modifies the behavior of the interpreter on crash under Emscripten:
1. No Python traceback shown on segfault/trap
2. The JavaScript source line is shown
The JavaScript source line is super long and completely unenlightening,
whereas the Python traceback is very helpful.
