Re: LuaJIT without the JIT?

["Robert G. Jakabosky" <bobby@...>]

On Friday 24, HyperHacker wrote:
> On Fri, Jun 24, 2011 at 01:29, steve donovan <steve.j.donovan@gmail.com> 
wrote:
> > On Fri, Jun 24, 2011 at 9:16 AM, HyperHacker <hyperhacker@gmail.com>
> > wrote: Is it an important problem?  People interested in serious
> > performance use LuaJIT, and it isn't hard to write portable C
> > extensions. There is still interesting scope for next-generation C
> > binding generators, which would take a LuaJIT FFI spec and make up some
> > C.
> 
> It's not really a problem at all :) I was just interested in the
> possibility of doing everything in Lua and remaining as portable as
> possible.
> 
> I've also been playing with writing a preprocessor that turns the C
> source into something resembling more of a C/Lua hybrid, e.g.:
> @function $(lib_name).create(integer n, string s) {
> automatically sets up and exports a function, with local variables n
> and s that it reads using luaL_checkinteger and luaL_checkstring. But
> this approach still involves a lot of C, and some might argue it's
> even worse since now you have to know this new hybrid-language.

The syntax is different but this is basically what my LuaNativeObjects [1] 
bindings generator does.  It generates both C & FFI based bindings which are 
compiled into a single .so shared object.  The hybrid native module will use 
the FFI code when loaded in LuaJIT 2 or fallback to the standard Lua C API 
code when the FFI interface can't be used.  Also note that it doesn't embed 
any part of the LuaJIT into the generated module, the FFI based bindings is 
just a block of Lua code (in plain text not bytecode) embed in the module.

This gives you the speed of FFI in LuaJIT and compatibility with the standard 
Lua VM in a single module.

1. https://github.com/Neopallium/LuaNativeObjects

-- 
Robert G. Jakabosky