Lua is a cool language, and it would be great to run it on the web. It isn't easy to do that though, see this answer (and the thread around it),
lua.vm.js is a project I started over the last week that does just that, here is a benchmark page and here is a REPL for it.
The Lua VM compiles out of the box using Emscripten, with only a few minor Makefile tweaks. It's straightforward to then create a REPL where you tell the VM to run some code. lua.vm.js does more than that though, as you can see in the example on the REPL page, you can interact with the page using Lua,
print("you haz " ..
.. " pixels")
local document = js.global.document
print("this window has title '" ..
local window = js.global
window.alert("hello from lua!")
print('hello from lua callback')
Since this uses the full Lua VM, it means you get the full Lua language, and it took just a few days since all the work that went into that VM is reused. That includes an incremental GC and everything else.
At this point you might be wondering if this isn't a crazy idea - a VM in a VM? There is definitely a lot of skepticism about that going around, but we won't know if the skepticism is justified or not if we don't try, hence this project.
The first specific concern is about size. It turns out that the entire compiled Lua VM fits in 200K when gzipped. That's too much for some use cases, but certainly acceptable for others (especially with proper caching).
Another concern is performance. That's what the benchmark page is for. As mentioned there, the Lua VM compiled into asm.js can have similar performance to other real-world codebases, around half the speed of native execution. Again, that is too much for some uses cases, but certainly acceptable for others. In particular, remember that the Lua VM is often significantly faster than other dynamic languages like Python and Ruby. These languages are useful in many cases even if they are not super-fast.
- Security is built in, since the new VM runs inside one that has already been heavily tested and hardened. The attack surface is not increased at all.
Maybe we wouldn't care? ;)
In the meantime, if you love Lua, check out lua.vm.js. Feedback and contributions are welcome!
I'd like to point something at what B. Eich said recently at the conference. He said, that "maybe" the max asm.js speed could get to 1.5x native? Well, if this is the case, then you might want to have more time looking at improving the performance of emscripten, because PNaCl is comming at 1.15x. And yes, I'd prefer asm.js to take the lead, that's why I think you should focus more on performance at this stage.
One other thing to look at would be the comming Nashorn project, with 100% compatible JS engine, aiming to run node.js applications at even better speeds than the current ones. (check the recent videos on the project)
Main target of course should be C compatibility, but performance is also something worth looking more at it.
Performance is definitely being looked at very carefully, I fully agree it's important.Delete
Firefox's asm.js optimizations can do even better than 1.5x, it will take work though, but in principle there is nothing PNaCl can do that it cannot. And note that already on some benchmarks it does better than 1.5x, for example Box2D is just 33% slower than native.
The 1.15x number for PNaCl is also probably an average of various benchmarks, I am sure they do better on some and worse on others. Note though that AFAIK they generally ignore compilation time in their results, and the asm.js benchmarkj don't, so the results are not necessarily directly comparable.
I already write SVG pages in Postscript (Ps)ReplyDelete
run through Ghostscript.
Firefox has PDF.js. PDF includes Ps.
So, how does one run Ps through Firefox?
Is it possible to include it in a website as a single .js file? As in can you just do script src="lua.vm.js" and then its good to go, or is there more to it?ReplyDelete
Also, whats the calling convention? Do you just write a lua code inside script type="text/lua" or do you call a js function etc
This is possible with empydom: https://github.com/bkase/empydom/blob/master/srv/script-tag-example.htmlDelete
Thanks! I'll take a look at how they do that.Delete
Overall the project is very new, thoughts on what the API should look like are welcome. I like the idea of using script tags.
These are good news!ReplyDelete
I've played around with lua.js, and, unfortunately, it seems to have a few disadvantages:
* it does not support several Lua features (coroutines, for example, and maybe something else);
* and it seems to require objects marshalling and unmarshalling (not a trivial problem in this case, imo, or I missed in lua.js too much re-implemented cyclic graphs objects traversing to marshall JS objects to lua.js and vice versa).
My questions are:
- Is it possible to disable js.global object access?
- Does this implementation come with all features from the Lua standard library?
Thank you very much in advance!
Can you perhaps give an example for the things you found to not work? I'm not a lua expert so I'm not sure how to test those things just by their names.Delete
The only pitfall I am aware of is the cross-VM GC issue I mention in the post. But very possibly there are other issues we will run into.
You can disable js.global of course, perhaps I should add a nice API call to make it even easier.
This should already include all the standard libraries, I think - I followed the embedding examples as best I could. But I didn't test. Of course, what they can do is limited by the browser - you can't read files on the user's machine due to web security.
Thank you very much for the reply. Actually speaking, I'm not a Lua expert as well, however the author of lua.js described known issues in his implementations. Please see here: https://github.com/mherkender/lua.js#known-issuesDelete
If you disabled js.global, it won't be accessible in any way. That's the only way to reach out of the Lua VM.Delete
Ok, understood. Thank you very much. :)Delete