lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Isn't it possible to just compile Lua with a C compiler targetting 

WebAssembly

?
It is more or less an hypervisor implemented in _javascript_ used to boot a Linux-like kernel, and already working across 4 major browsers (Firefox, Chrome/Chromium, Safari and IE) on Windows, MacOSX and Linux (with the builtin _javascript_ engines of these browsers) ?
Did someone try it ? Could Lua be successfully compiled with its toolchain (which includes the C compiler and most shell and dev tools from Linux) ?
I cannot be so bad in perfomance, given the demos including games made with Unity. The mini Linux kernel run by Webasembly boots really fast and applications made with it are also very small to download. Behind the scene, there's the LLVM engine, but we've seen Mozilla and Google working to boost WebAssembly. And soon Microsoft will abandon Edge to rebuild it from the Webkit/Chromium base, so it will hopefully support WebAssembly)


Le mar. 14 mai 2019 à 17:47, Francisco Olarte <folarte@peoplecall.com> a écrit :
I skipped the first message but:

On Tue, May 14, 2019 at 5:22 PM pocomane <pocomane_7a@pocomane.com> wrote:
> Il gio 9 mag 2019, 11:33 pocomane <pocomane_7a@pocomane.com> ha scritto:
>> The whole lua script is wrapped in a coroutine, and the browser resume it until it goes to the 'dead' state. Ideally I can wrap browser actions in some lua function that yields. On the _javascript_ side there will be something that parses the yielded values.
>> This does not works when the "Browser interaction api" is called from a sub-coroutine created in the lua code. Or, at least, I need to propagate the "Yielding" to the parent coroutine, and the "Resuming" to the child one [2].

Why do you need this? I did a similar thing, more or less:
- when you start the lua stuff, you create a corourine and start it.
- When lua code wants to call API it calls a routine published in the
interpreter which yields a special token ( a lightuserdata, or the
funcion per se ) plus the function it wants to call and the
parameters, control returns to C.
- C records the coroutine which yielded somewhere ( registry? ), and
calls the API.
- Api comes back, recover the suspended coroutine from where you
stored it and return it.

If API has created a coroutine, the main one is already "dormant", and
the child, which will be woken up on API return, is the responsible of
returning to it.

IIRC I also had to send API messages ( and call lua from message
handlers ), and what I did was to pass a "usertoken" in the message,
which was a pointer to a heap allocated pointer to the (main) lua
state and use it as a lightuserdata key in the registry to the
coroutine, so the api code, when invoked on message return, could
recover the state pointer, recover the coroutine from the registry,
free the usertoken and resume the correct coroutine.

I do not have the code handy, and it was tailored for the specific
host, but I do not remember having problems.

> I just want to fully stop the lua VM, to process some data outside lua, and then to restart the VM exactly where it did stop. To do this transparently with the proposed code, a lot of auxiliary code is required, e.g. to decide if perform a `nestresume` or a normal one, to handle errors, to wrap the standard coroutine functions, and so on.

I do not think you need to resume the main coroutine, just resume the
one calling the API.

Francisco Olarte.