Lua VM cross-compiled to JavaScript (1.4mb - takes a while to load) | Hacker News Reader

Lua VM cross-compiled to JavaScript (1.4mb - takes a while to load)

syntensity.com

58 pointspufuwozu17 comments

Wow. The backend, emscripten (http://code.google.com/p/emscripten/wiki/GettingStarted), seems really nice. Wonder how it will work out with Rubinius....

Edit: Guess i just found it out :( http://code.google.com/p/emscripten/issues/detail?id=1

In principle it should be possible to get Rubinius to work with Emscripten - I'd be excited to see that happen. In fact it should work better than compiling a language's VM (which is what happens in the Lua demo).

But it will be hard to do without help from someone that knows Rubinius well (I don't).

There is also a Lua frontend for the LLVM.

Lua code compiled to LLVM bytecode then to Javascript using Emscripten will most probably be faster than code interpreted on the fly in the browser, but I wonder by how much.

http://code.google.com/p/llvm-lua/

Thanks for the feedback in the comments here!

I made a few fixes to Emscripten, and the code that was mentioned that doesn't work, should now work in the demo, for example |for x = 1,10 do print(x) end|.

It breaks for input as simple as "for x = 1,10 do print(x) end". It's a shame I can't use Lua for browser scripting instead of JS.

I tried "for k,v in pairs(_G) do print("->", k,v) end" (I was curious what is and isn't sandboxed) and it just gave me an error.

There's no sandbox. This is the Lua virtual machine, compiled to LLVM bitcode with llvm-gcc/clang and then compiled to JavaScript with emscripten.

It's all client-side.

I don't think (s)he was implying it was using a plugin or anything.

An occasional feature of other languages-in-Javascript is some kind of sandboxing for security - eg the Valija Javascript subset that runs in the Caja sandbox (which in turn is implemented in Javascript): http://code.google.com/p/google-caja/wiki/SubsetRelationship...

Yes. Rather, I meant, which libraries were available. I figured that it'd at least have the core stdlib; that was just my first step exploring. It's a bad sign that the first statement I tried didn't work, though.

http://code.matthewwild.co.uk/ljs/

This is Lua's bytecode interpreter in pure javascript.

When I tried it a few weeks ago it lacked some bytecodes - but when I bolted the code to interpret them on I was able to run some compiled Lua code. Maybe you find it interesting.

I put up the demo after seeing that some simple stuff worked, like

x = 10 print(x+25)

etc., but I didn't test the compiled interpreter a lot more. Probably the statement you tried doesn't work because some stdlib function needs to be implemented. If people are really interested in getting this to work, we can probably figure it out, it will take some effort though.

another interpreted language running inside of an interpreted language... sweet. All we need now is to write a perl interpreter in Lua and then run it inside of the javascript Lua interpreter and we'll really see the scripts slow down to a crawl.

It would still run about as well as Tcl. [ducks]

Lets add an Io interpreter to the mix!

(For those who don't know: Io is very powerful, but also very slow.)

Steve Dekorte (creator of Io) has already been thinking about an Io implementation on top of Javascript.

ref: http://tech.groups.yahoo.com/group/iolanguage/message/12526

Should be a relatively good fit, with both languages having prototypal oo. I wonder how he would implement the metaprogramming parts of Io.

I see its actually more than just thinking because he has a repo called "Io port to Javascript (node.js)" on github: https://github.com/stevedekorte/oia

Reply on news.ycombinator.com