-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use WASM commands running in webworker #15
Conversation
9fa2de9
to
c32a982
Compare
Thanks for looking into this!
Out of curiosity, what is the process for building these files? |
It is the classic UNIX |
OK thanks. Would it be possible to post the commands on this PR, to be able to more easily build the files locally if needed? |
Not yet, I need to do more on it before I am happy with it. |
This now connects to the file browser using a Screen.Recording.2024-06-25.at.11.33.08.movIt breaks some things such as |
Co-authored-by: Jeremy Tuloup <jeremy.tuloup@gmail.com>
593b1f6
to
0abc64f
Compare
1818f22
to
b66c7b6
Compare
I think this is ready now. After merging this there is lots of work to be done on cockle. |
This is an experiment using POSIX commands compiled to WebAssembly via emscripten instead of the current implementation which uses commands written in bespoke TypeScript. Here is an example:
Screen.Recording.2024-06-24.at.15.04.22.mov
It includes all of coreutils as a single JavaScript module with embedded WASM. The build system for that is based on the marvellous biowasm. It uses its own emscripten filesystem so is not yet integrated with the JupyterLite file browser contents (edit: it is now). There is no support for input or output redirection, pipes, or setting env vars, or many other things yet.
I have temporarily removed the
cockle
dependency and just put the JS files (fs.js
andcoreutils.js
) in this repo for demo purposes. Eventually they will be incockle
(or an equivalent) and we will need to use much of the existingcockle
functionality for command-line editing and so on. The actual JS/WASM files are built by hand at this stage but obviously that needs to be automated.Because of global state in each command, the code recreates a new instance of the
coreutils
module for each command. This takes about 30 ms the first time, and less that 20 ms thereafter on my dev system (see log messages in console). The separatefs.js
module is just for the emscripten filesystem which lasts the duration of the terminal and is proxied into each command just before they are run.This reuses the WebWorker code from PR #13.