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
> 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
> 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
> 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
> 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
> 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.
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)