Hacker News Reader

Comment by williamstein | Hacker News Reader

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

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)?

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 for me

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?

Yes, porting 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/) already as part of 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.

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.

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.

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.

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)?

CoWasm supports WASI right now via this library 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, 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/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).

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

Reply on news.ycombinator.com