albertjan

What @meredydd means is, leaving the compiler written in javascript but emitting wasm, so compiling python into wasm with javascript. Too many compilers! :P

We're back up! :)

Oh nooo, I'll try and track down the person that has the creds to fix this :) ...

Thanks for this succinct explanation! I've opened an issue on the skulpt repo. https://github.com/skulpt/skulpt/issues/731

Skulpt strings are javascript strings internally, wether or not you add u in front of a string doesn't actually change it's internal representation. We always strive to be as close to cpython as we can, but in this instance we chose to use javascript strings internally, very likely with the mentality that we would come back to this if and when it would be a requirement for one of us. :) Which it hasn't been I think.

We are working on python3 support and skulpt does have a python3 mode which emulates the biggest differences between py2 and py3. (like from __future__ import).

But it doesn't understand any of the new syntax added by python3 yet.

(Contributor to skulpt and pypy.js here)

That is a difficult question to ask and I think the original developer of pypy.js Ryan Kelly is most suited to answer it. There are some people that have tried feeding the asm.js from pypy.js to the asm.js -> wasm compiler.

Which with a lot of fiddling may work for the non-jitted version. But if you want all the pypy speed you'll want to jit wasm to the browser.

I would love to know if you can do synchronous calls in wasm.