Re: Stack state before running a script

> 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?

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

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.

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.

On Tue, Feb 7, 2017 at 7:24 PM, Daurnimator <quae@daurnimator.com> wrote:

On 8 February 2017 at 09:27, chris beck <beck.ct@gmail.com> wrote:
> If JS doesn't have destructors, finalizers, RAII, or any other such built-in
> language feature for the clean up of objects, then I guess you can just add
> explicit "release" methods to your JS representation of a lua object?
> Which would call `luaL_unref`, and tell lua that it is now okay to garbage
> collect that object. I mean presumably this is idiomatic in JS as you also
> will have to call "close" explicitly on file handles and such?

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.

> Don't have much knowledge of JS myself but I never encountered a problem
> like this before -- I guess it should be workable somehow? JS is a very
> mature technology, and iiuc you'd have the same issue making
> bindings to any other garbage collected programming language.

No it's not fixable.
Weak-refs (https://github.com/tc39/proposal-weakrefs) will get us
*some* of the way: bringing collection callbacks to _javascript_.
However you still have the (unsolvable) problem of cycles across the
two garbage collectors.

The approach taken by Benoit is the *only* good way forward to get lua
working in in web browsers to full effect:
- You need to use native _javascript_ objects so that the _javascript_
garbage collector can do a full sweep
- You need to use a VM dispatch *in* _javascript_ (rather than a
source=>source transpiler) so that coroutines work correctly.