On 8 February 2017 at 12:44, chris beck <email@example.com> wrote:
lua.vm.js *does* have this function. but it's essentially unusable.
e.g. if you attach a expose a function as a callback, you generally
have no idea when the DOM will be done with it.
The whole scheme is a dead end.
explicitly make calls to "release",
then it will work, so what is the dead end?
'release' means you have to know the lifetime.
It also means you can't interact with the DOM in a general manner: and
The approach taken by Benoit is the *only* good way forward to get lua
working in in web browsers to full effect:
Hmm, well, that seems a bit overbroad. There are lots of applications that
use lua in a web browser to great effect via emscripten.
and both environments having references to eachothers objects, but who
really needs that anyways? If they both talk primarily to the C / C++
then there's no issue, and it's actually very performant in recent versions
of firefox and chrome, even though you have the "VM inside a VM" thing
Yes. But the issue is being unable to interact directly with the DOM.
Also FWIW emscripten supports longjmp, and to a lesser extent C++
exceptions, and lua coroutines seem to work great even in a large
I worked on.
It might be that you are mainly interested in making an off-the-shelf
from there -- I can see that that might be very difficult to do in a
But if you are doing a C or C++ project and want to target the web and use
lua, there are no real obstacles, and in my experience it all works great.
I didn't have any memory leaks or round-robin garbage collector issues, and
I think you will only have these problems if you structure your application
Correct. however if you're porting a C/C++ app you generally just want
a canvas that you write pixels to.
What many people want is to be able to write in Lua instead of
The other thing is, rewriting the lua VM in hand is likely to have much
worse performance than the cross-compiled version, unless you target ASM.js
will allow the browser to JIT compile it into native code. ASM.js is not
meant to be written by hand, and it's not easy to do so -- it's meant to be
their llvm-based backend. If you don't get the JIT stuff to happen in the
browser, it's like a 5x or 10x performance hit. So tbh I'm a bit skeptical
of the "rewrite the lua vm
in JS" approach, depending on what kinds of applications you have in mind.
Performance isn't much of an issue compared to correctness.
a major acheivement.
Especially when you have lua's coroutines instead of dealing with the
You can try it out today with lua.vm.js, however you might 'leak'
memory (which makes it useful for experiments/prototypes, but not for
That said, there's nothing to prevent performance increases from
coming later (and infact you can write a JIT into asm.js or
webassembly for some bits, which would be a interesting project once
the basics are complete and correct)