lua-users home
lua-l archive

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


Eduardo Ochs <edrx@inx.com.br> wrote:

>>>So, yes we need a good way to add third party libraries to an existing Lua
>>>executable without having to recompile it.
>>
>>I think loadlib can help here: http://www.tecgraf.puc-rio.br/~rborges/
>loadlib/
>>--lhf
>
>But loadlib does not work with Lua 4.0... I tried to patch it a little
>to make it work with 4.0 but couldn't (it would be the first time I
>programmed a Lua extension in C, BTW), and I ended up reimplementing a
>much simpler "loadlib" function, whose bulk is just this
[...]

Funny, I recently went through the same process and ended up rewriting
too.  Tested on Linux and Windows, with some tentative code for Macintosh
(PPC), it's now part of a larger work-in-progress project at http://
www.equi4.com/lux/ - I could package it separately if anyone is interested.

One change, which I hope could be adopted in standard Lua, is that the
call signature of extension entry points become "int blah(lua_State*)"
instead of the current "void blah(lua_State*)".  With the same semantics
as all other C functions in Lua: returning the number of results left on
the stack.  That makes all sorts of packaging variations feasible,
including optional "delayed loading", i.e. not calling the lib init
routine itself, but a wrapper which registers the init routine as a Lua
function.  It can also simplify static vs. dynamic linking.

The big "gotcha" is that this change breaks existing extensions - so let
me add a <strong> plea to do this swiftly and get over the pain while
it's still bearable.

-jcw