Hacker News Re-Imagined

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

  • 144 points
  • 13 hours ago

  • @apignotti
  • Created a post
  • • 30 comments

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


@miohtama 9 hours

Replying to @apignotti 🎙

Hopefully Safari will support this on one day.

Reply


@EMM_386 4 hours

Replying to @apignotti 🎙

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

Reply


@badsectoracula 5 hours

Replying to @apignotti 🎙

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.

Reply


@lbhdc 11 hours

Replying to @apignotti 🎙

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

Reply


@ntauthority 3 hours

Replying to @apignotti 🎙

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.

Reply


@kzrdude 9 hours

Replying to @apignotti 🎙

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

Reply


@eatonphil 12 hours

Replying to @apignotti 🎙

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

Reply


@laserlight 3 hours

Replying to @apignotti 🎙

Obligatory reference [0].

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

Reply


@throwawayninja 6 hours

Replying to @apignotti 🎙

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>

Reply


@bruce343434 10 hours

Replying to @apignotti 🎙

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?

Reply


@dec0dedab0de 10 hours

Replying to @apignotti 🎙

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?

Reply


@syrusakbary 11 hours

Replying to @apignotti 🎙

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/

Reply


About Us

site design / logo © 2021 Box Piper