On 8 February 2017 at 12:44, chris beck <beck.ct@gmail.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.
Can you explain this in greater detail? If you require the javascript end to
explicitly make calls to "release",
then it will work, so what is the dead end?
That is the dead end: requiring the javascript end to explicitly
'release' means you have to know the lifetime.
It also means you can't interact with the DOM in a general manner: and
hence will be less powerful than javascript code.
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 they also expose a C api to javascript code, via the cross compiler.
They might not have javascript actually talking to lua directly,
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
going on.
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
application
I worked on.
It might be that you are mainly interested in making an off-the-shelf
javascript library that encapsulates a lua VM, and then JS developers take
it
from there -- I can see that that might be very difficult to do in a
satisfactory way.
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
that way.
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
javascript, but still have access to all APIs exposed by a browser.
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
which
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
output by
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.
The ability to use a language that isn't javascript in the browser is
a major acheivement.
Especially when you have lua's coroutines instead of dealing with the
weird async-ness of javascript.
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
'production' websites/webapps).
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)
