[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lua-l
Subject:    Re: Quick hack: loadlib on Lua 4.0
From:       Jean-Claude Wippler <jcw () equi4 ! com>
Date:       2001-02-26 5:33:19
Message-ID: 20010226053319.5140 () smtp ! telus ! net
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]