lua-users home
lua-l archive

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


I will probably add support for ffi bindings along with regular ones in dub [1] (it should not be too hard since I have the full C/C++ introspection at hand) iff :

=> The ffi based bindings provide the same interface as the regular bindings.

We must not lose sight that Lua is *not* dynamic C. It offers many powerful tools that C-like bindings cannot reflect such as varying arguments, multiple return values, callbacks, variable scoping, memory management, metamethods, tables, etc. All these features can (and should) be used to write bindings that make bound libraries easier to use, more powerful and easier to interface with one another.

Lua is not just about not ending lines with ";".

Gaspard


[1] http://lubyk.org/en/project311.html

On Tue, Feb 22, 2011 at 11:16 AM, T T <t34www@googlemail.com> wrote:
On 22 February 2011 09:34, Miles Bader <miles@gnu.org> wrote:
> Wesley Smith <wesley.hoke@gmail.com> writes:
>>> My guess has been that this would entail using FFI's parser to
>>> automatically produce C-code for a traditional Lua-C interface library,
>>> but use dynamic FFI interfaces for LuaJIT.  Build-time configuration
>>> could detect whether LuaJIT was available or not, and arrange for the
>>> appropriate method to be used.
>>
>> Given the properly generated C code, it could be compiled a runtime
>> using luaclang.  It doesn't come cheap (Clang/LLVM is a big project),
>> but it does compile C-code on the fly quickly.  luaclang can be easily
>> ripped out of LuaAV simply by grabbing a handful of header files along
>> with it.
>
> I suspect for a lot of projects, that would be wayyyy overkill and
> compile-time generated thunks would be a better method.  Using LLVM
> would dramatically increase the size and number of a program's
> dependencies, and wouldn't offer any significant speed advantage.

There is also LuaTCC, which could be used in place of LLVM.

Cheers,

Tomek