Show HN: Run Python, Ruby, Node.js, C++, Lua in the Browser via x86 to WASM JIT

[badsectoracula]

This is neat. I actually managed to run Bash and a custom executable (a 32bit compiled version of my LIL interpreter - that i compiled under 86box running Caldera OpenLinux from 1999, which i guess also shows how you can be backwards compatible if you pay attention to it :-P):

    $ /usr/bin/python3  
    Python 3.7.3 (default, Jan 22 2021, 20:04:44) 
    [GCC 8.3.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import os,sys,base64
    >>> os.system("/bin/bash")
    bash: cannot set terminal process group (-1): Bad file descriptor
    bash: no job control in this shell
    user@:/$ exit
    exit
    0
    >>> with open("/usr/lil", "wb") as f:
    ...     f.write(base64.decodebytes(b'...base64 encoded binary goes here...'))
    ... 
    53448
    >>> os.system("/bin/bash")
    bash: cannot set terminal process group (-1): Bad file descriptor
    bash: no job control in this shell
    user@:/$ cd /usr
    user@:/usr$ ls
    bin  foo  games  include  lib  lib64  libx32  lil  local  sbin  share  src
    user@:/usr$ ./lil
    Little Interpreted Language Interactive Shell
    # print [reflect version]
    0.1
    # 

Though it was kinda slow and hanged a few times during my attempts (my initial attempt was actually to try and put the entire Free Pascal installer there but pasting the base64 encoded string in there caused Firefox to eat all of the 32GB of RAM for some reason and made by system unresponsive :-P).

I did notice that reloading the page keeps some files around which makes me wonder, where are these stored? Local storage? I notice that there is 25MB of data stored for the site.

[apignotti]

Any disk block which is used or modified is stored locally into an IndexedDB instance. You can find more info in the accompanying blog post: https://medium.com/leaningtech/cheerpx-using-webassembly-to-... ("Data Storage" section)

[eatonphil]

This is awesome! Thanks for providing more details (was a bit hard to notice your medium post at first) [0].

For folks here interested in doing this kind of thing (one example is for building web-available IDEs) the other way to run languages in the browser is to find implementations of the language in JavaScript like Brython for Python and there are a few Schemes that come to mind. I wrote a bit about this here [1]. Some people have taken this even further [2, 3] than I did.

And specifically both this OP post and all the links I'm talking about work differently than repl.it does because repl.it has a server where your code runs. Everything I'm talking about runs solely in your browser. Which makes compute free, with a bunch of limitations (io, basically).

[0] https://medium.com/leaningtech/cheerpx-using-webassembly-to-...

[1] https://datastation.multiprocess.io/blog/2021-06-16-language...

[2] https://github.com/fiugd/plugins/tree/main/.templates

[3] https://github.com/viebel/klipse

[sere_lt]

Thanks!

The cool thing about Cheerpx is that it's not limited to interpreters at all, it's a more general framework that can be used to run many Linux tools out of the box - we are currently experimenting with bash and some common commands, for example.

[bruce343434]

This is cool! But this suffers from multiple translations:

actual_cpu(browser_sandbox(wasm(x86_emulator(python_interpret(python source)))))

Is there some way to do a more direct JIT in wasm? Or maybe just a normal python interpreter written in wasm? Or would that not be faster?

[apignotti]

The point of this technology is generality. It is theoretically possible, given enough work, run Python directly in Wasm. The effort would be, though, Python specific and you would need to start from scratch for every single language.

CheerpX allows running unmodified X86 programs, it does not matter if it's Python or something else. It does not even have to be a REPL, for that matter. We use this tech in production to run the legacy Flash plugin, for example: https://leaningtech.com/cheerpx-for-flash/

[syrusakbary]

This is quite impressive.

I would love to see if we can have something similar that doesn't require JS at all, so we can execute x86 programs server-side just using Wasm translation (hi Wasmer).

Here's another interesting project I found recently that I think fits as well on the asm2wasm translation mechanism: https://github.com/copy/v86/

[apignotti]

The technology can certainly be adapted to non-browser & js-less VMs, but our current focus is the browser use case.

It seems to us that in server-side scenarios it is most usually possible to execute apps natively anyway.

[dec0dedab0de]

I would love to see if we can have something similar that doesn't require JS at all, so we can execute x86 programs server-side just using Wasm translation (hi Wasmer).

Running user input on a server would definitely be a security risk, but might be nice when everyone is trusted anyway.

Though, if it's server side what would be the benefit of using WASM instead of just running it in the actual languages? I'm always on board for doing weird things just to see if they can be done, so if that's what you mean, I get it. I don't know much about WASM though, so I honestly don't know if there would be any practical benefits of running it server side.

[lbhdc]

This isn't working for me in firefox. The tab hangs, then crashes.

[the_duke]

It loads fine for me, but has severe rendering issues. There is no text, just weird, colored diagonal lines.

[dec0dedab0de]

If anyone else was confused and was too embarrassed to say it out loud, I was stubbornly typing exit() to try the other languages before I actually read the menu. You have to click on the different REPL names to switch between them. And this link automatically starts you in python3.

This is really great though. Are you planning on adding any other languages? or alternative REPLs? For Python, the option to run bpython or ipython would be fantastic. As far as other languages, I could see this as being a savior when I have to fix something written in PERL or PHP once every 3-5 years, and I need to relearn the syntax. Being able to choose arbitrary older versions of languages would be good for that use case too.

I was going to ask more questions, but then I looked around the site a bit. Is it fair to say this is essentially a demo for the CheerpX emulator? Which started as a proprietary way to run legacy flash applications on modern browsers? If so, then my next question is if there is any chance of some or part of this becoming open source?

[apignotti]

CheerpX is really not just limited to REPLs, this demo was intended to showcase the technology and to measure the public interest for this specific use case. We don't plan to make this a product in itself, but we are happy to partner with a third party interested in doing so.

The next demo we are planning is actually more ambitious, we will drop users into a bash shell and give them control of the machine. The experience will be something like having your own zero-cost cloud machine always available and with total data privacy.

At this time we don't plan to make CheerpX open source, although this might change in the future. We are still working to figure out exactly what use cases we should bring to market first, so we prefer to keep our options open.

[EMM_386]

Very impressive stuff. Even after 20 years of developing, I still have trouble wrapping my mind about the complexities involved here.

If anyone hasn't read the blog post about this, it's a great read:

https://medium.com/@apignotti?p=3306e1b68f06

[throwawayninja]

I would like to register the security issue: "import os; os.system('cat /etc/shadow')" demonstrates that without a kernel to check permissions (and without a user ID to be checked against), all filesystem safety guarantees go out the window. </joke>

[apignotti]

Oh no! You have pwned a non-existing cloud VM :-)

More seriously though, you are right. The current implementation of the Linux syscalls interface does not enforce permissions and users. We plan to implement those correctly at some point.

This said, most use cases we are currently considering do not have any shared state and are mostly "throw away" execution environments. As such the missing access control checks do not seem to be a significant problem.

[ntauthority]

It's a shame that even the underlying compiler tech seems to be proprietary and intended to be commercially licensed once 'finished'. I feel like a lot of creativity (and optimization?) could be possible if tech like this were available to the commons rather than a years-long pre-announcement of a future commercial product.

[kzrdude]

Works fine in firefox. The backspace key doesn't work correctly, which is a fun throwback.

[sere_lt]

Hey, luajit is fun! It should be the only demo affected by the backspace issue (if it's not, please let us know). While all the other REPLs expect raw terminal input (with all the control characters, for example newline and backspace), luajit expects cooked - or line-edited - terminal input.

This means that we had to support keystroke echo and we had to remap ENTER to get the basic functionality, and that full line-editing support is needed to get complete functionality.

[laserlight]

Obligatory reference [0].

[0] The Birth & Death of JavaScript. https://www.destroyallsoftware.com/talks/the-birth-and-death...

[ngcc_hk]

No mobile version of chrome, Firefox etc though

[miohtama]

Hopefully Safari will support this on one day.

[apignotti]

The blocking feature is SharedArrayBuffer, but it should become available in the not-too-far future.