 |
lua-l archive |
|
|
||
|
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)