lua-users home
lua-l archive

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


Hello Lua Community,

I am maintaining an existing C++ application that features, in a core library of it, an embedded C++ DSEL (written inlined in boost spirit) to execute user defined tasks. Those tasks call functions in the library itself. I would like to evaluate Lua as an optional alternative to the embedded DSEL, while keeping the architecture itself intact.

About this, I have a few questions:

1) Can Lua scripts call functions in the very same DLL that calls the interpreter?

For my experiments I have used LuaJit with FFI binding. Successful so far, but i noticed I have to load the DLL inside the Lua script specifically before I can use it. In my case, that would imply the DLL that executes the script would (via script) load itself and exist twice. Or indeed many times as there are lots of those scripts. This is what I have to avoid. I have a number of objects already present at the time the script gets executed and I would have to access those objects rather than create new ones. Is this possible, with LunaWrapper for example? Even a singleton would exist twice in that scenario.

2) When LunaWrapping existing classes, is there a standard pattern or best practice for doing so? Like, I have an object and want to call multiple scripts that use it. Do I create a wrapper class that derives from the existing class and somehow pass it into the scripts? Or is it better to modify the existing class with the LunaWrapping boilerplate?

3) Can multiple Lua States coexist nicely?

4) In a real world use case my users have many scripts in my DSEL that get executed at a frequency of about 30 Hz or more. Would I create a Lua state and execute the chunk every time or can I re-use the state after instantiating it once and excecute many times?

As you can see, I am a Lua newbie and just hope to get some answers in order to get a grip on the question if Lua is a suitable alternative for the DSEL scripts. Any hints are appreciated.

Thanks,
Moose