Re: Stack state before running a script

[Daurnimator <quae@...>]

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)