42 ms·

I started this project and can answer any questions about CoWasm.

bobuk 4y ago
no questions, but please keep working on that. I'm very impressed with how smoothly the current cowasm implementation is working. For the future do your have a plans to support WASI and other modern WebAssembly stuff (like WebAssembly Component Model support f.e)?
- williamstein 4y ago
  CoWasm supports WASI right now via this library https://www.npmjs.com/package/wasi-js https://www.npmjs.com/package/wasi-js, which I actually develop as part of CoWasm . One unusually thing I did, which goes beyond what emscripten does, is I implemented a quite a bit of posix functionality, often by writing extension code to nodejs and calling it from Javascript, because there's a lot of POSIX that Node.js doesn't expose. This only works on Mac and Linux and is also available standalone in this library https://www.npmjs.com/package/posix-node https://www.npmjs.com/package/posix-node, which is implemented in Zig. You can get a sense of the scope of POSIX functionality that goes beyond what WASI defines here: https://github.com/sagemathinc/cowasm/tree/main/packages/kernel/src/wasm/posix https://github.com/sagemathinc/cowasm/tree/main/packages/ker... One motivation for doing this is to try to get the full Python test suite to pass, including all the functionality that involves subprocesses, posix calls, etc. I've only got to about 85% at this point. It can be a ton of tedious work, but at least Zig helps impose some discipline (e.g, it doesn't let you ignore handling errors until later), and makes it easy to test compilation for all supported targets on every change (due to excellent cross compilation support).
boothby 4y ago
This is really cool, William! A lifetime ago, we were pondering what it would take to get Sage running in the browser from a static server. It feels like you're nearly there. Is that in the plans?
- williamstein 4y ago
  Yes, porting https://SageMath.org https://SageMath.org to the browser is part of the plan, and this is a key foundation for that. I ported some of the components of Sage (e.g., https://libntl.org/ https://libntl.org/) already as part of https://github.com/sagemathinc/jsage https://github.com/sagemathinc/jsage, and I don't see any fundamental obstruction to porting all of Sage, except time. It would be great if once CoWasm is more stable, I can get some help porting some components to WASM.
mdaniel 4y ago
That's just incredibly cool, my congratulations! Foremost, my apologies if this is a nonsensical question. I haven't been soaking in the WASM ecosystem enough to know how much WASM is "just" JS versus ... something else. Caveat aside, I saw one of the commits mention jython, which notoriously has ancient (and probably incredibly incomplete) python 2.x support; do you know if python-wasm would run on top of GraalJS (https://github.com/oracle/graaljs#nodejs-support https://github.com/oracle/graaljs#nodejs-support)? Separately, do you want issues related to zython.org in the cowasm issue tracker? It returns 405 (method not allowed) over and over on POST https://zython.org/python-wasm-sw/read-signal https://zython.org/python-wasm-sw/read-signal for me
emmelaich 4y ago
It feels really fast and responsive. Have you done any benchmarks to compare against other Pythons-in-the-browser? Or 'normal' Python for that matter.
- xanthine 4y ago
  With regards to differences with 'normal' Python, depending on WASM also means that despite having the same sys.get_int_max_str_digits() = 4300, my local Python can print out (2222*5555 + 5555*2222) in its entirety, while the browser based one can't. Values that can be set via maxdigits in sys.set_int_max_str_digits(maxdigits) are also limited to size of int in C.
- williamstein 4y ago
  It’s basically the same speed as Pyodide for cpu bound work. It is overall about twice as slow as native Python on the exact same machine. There is a benchmarks folder in the CoWasm git repo with a several dozen benchmarks.
moomin 4y ago
What pain points with emscriptem do you want to address? What are the trade-offs you’re considering?

no questions, but please keep working on that. I'm very impressed with how smoothly the current cowasm implementation is working. For the future do your have a plans to support WASI and other modern WebAssembly stuff (like WebAssembly Component Model support f.e)?

williamstein 4y ago
CoWasm supports WASI right now via this library https://www.npmjs.com/package/wasi-js https://www.npmjs.com/package/wasi-js, which I actually develop as part of CoWasm . One unusually thing I did, which goes beyond what emscripten does, is I implemented a quite a bit of posix functionality, often by writing extension code to nodejs and calling it from Javascript, because there's a lot of POSIX that Node.js doesn't expose. This only works on Mac and Linux and is also available standalone in this library https://www.npmjs.com/package/posix-node https://www.npmjs.com/package/posix-node, which is implemented in Zig. You can get a sense of the scope of POSIX functionality that goes beyond what WASI defines here: https://github.com/sagemathinc/cowasm/tree/main/packages/kernel/src/wasm/posix https://github.com/sagemathinc/cowasm/tree/main/packages/ker... One motivation for doing this is to try to get the full Python test suite to pass, including all the functionality that involves subprocesses, posix calls, etc. I've only got to about 85% at this point. It can be a ton of tedious work, but at least Zig helps impose some discipline (e.g, it doesn't let you ignore handling errors until later), and makes it easy to test compilation for all supported targets on every change (due to excellent cross compilation support).

boothby 4y ago

This is really cool, William! A lifetime ago, we were pondering what it would take to get Sage running in the browser from a static server. It feels like you're nearly there. Is that in the plans?

williamstein 4y ago
Yes, porting https://SageMath.org https://SageMath.org to the browser is part of the plan, and this is a key foundation for that. I ported some of the components of Sage (e.g., https://libntl.org/ https://libntl.org/) already as part of https://github.com/sagemathinc/jsage https://github.com/sagemathinc/jsage, and I don't see any fundamental obstruction to porting all of Sage, except time. It would be great if once CoWasm is more stable, I can get some help porting some components to WASM.

mdaniel 4y ago

That's just incredibly cool, my congratulations! Foremost, my apologies if this is a nonsensical question. I haven't been soaking in the WASM ecosystem enough to know how much WASM is "just" JS versus ... something else. Caveat aside, I saw one of the commits mention jython, which notoriously has ancient (and probably incredibly incomplete) python 2.x support; do you know if python-wasm would run on top of GraalJS (https://github.com/oracle/graaljs#nodejs-support https://github.com/oracle/graaljs#nodejs-support)? Separately, do you want issues related to zython.org in the cowasm issue tracker? It returns 405 (method not allowed) over and over on POST https://zython.org/python-wasm-sw/read-signal https://zython.org/python-wasm-sw/read-signal for me

emmelaich 4y ago

It feels really fast and responsive. Have you done any benchmarks to compare against other Pythons-in-the-browser? Or 'normal' Python for that matter.

xanthine 4y ago
With regards to differences with 'normal' Python, depending on WASM also means that despite having the same sys.get_int_max_str_digits() = 4300, my local Python can print out (2222*5555 + 5555*2222) in its entirety, while the browser based one can't. Values that can be set via maxdigits in sys.set_int_max_str_digits(maxdigits) are also limited to size of int in C.
williamstein 4y ago
It’s basically the same speed as Pyodide for cpu bound work. It is overall about twice as slow as native Python on the exact same machine. There is a benchmarks folder in the CoWasm git repo with a several dozen benchmarks.

moomin 4y ago

What pain points with emscriptem do you want to address? What are the trade-offs you’re considering?