FW: External modules was Re: Ideas for implementing commercial su pport for Lua

[Asko Kauppi <Asko.Kauppi@...>]

Fine - I'm glad you as the authors are taking some sides here.

But...

Just calling one function in the C dll/so from Lua is not enough. Have you
got plans on how the C code will actually interact with the Lua engine
(where it's being called from). 

If you plan to pass on a 'lua_State*' pointer, you are counting on the
module to directly tamper with the internal data structures of the Engine.
This won't work across different Lua versions. Do all the modules being used
need to match the Engine using them?

Or do you plan on providing a limited set of features that are supposed to
remain binary compatible (in the Engine) also in the future?

-ak


> -----Original Message-----
> From:	Roberto Ierusalimschy [SMTP:roberto@inf.puc-rio.br]
> Sent:	Monday, November 18, 2002 11:35 AM
> To:	Multiple recipients of list
> Subject:	Re: External modules was Re: Ideas for implementing
> commercial support for Lua 
> 
> > Luiz, it would be nice if the loadlib code were platform independant
> > from the lua side, that is, in unix it would look like:
> 
> Currently, our idea is to put the minimum in C, and everything else in
> Lua. Typically, each module in C would have a companion file in Lua:
> this Lua file could be very small, more or less like this:
> 
>     -- Lua file for module Xuxu: xuxu.lua
>     -- Config part; set to your system
>     local libdir = "/usr/local/lua/"
>     local modname = "xuxu.so"
>   
>     local f = loadlib(libdir..modname, "xuxuopen")
>     if not f then error (...) end
>     f()   -- open module
> 
> You put xuxu.so anywhere, adjust xuxu.lua, and put xuxu.lua in a
> directory on your LUA_PATH; than you use it as
> 
>     require "xuxu"
> 
> For the user, it doesn't matter whether this is a C module or a Lua
> module (or a mixed one).
> 
> -- Roberto
###########################################
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.