Lua libraries

classic Classic list List threaded Threaded
58 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Lua libraries

Ignacio Castaño
Hi,
I'm anoyed with the amount lua extensions out there. With lua extensions I
mean lua binaries that are linked with different libraries. The problem with
this approach is that you cannot use lua with two different libraries at the
same time. The only solution is to build your own lua, and that's only
possible if the source code of the libraries is publically available.
To solve that I would like to see a standard mechanism to write dinamic
libraries for lua. The requierements of that mechanism are very simple:

- A single entrypoint in the library: (i.e. Register(lua_State *) ) where
all the lua functions are exported.
- A new function in iolib (i.e. loadlib )

so you could do:

> loadlib "wxlua"

and that would load the library, call the Register function, and add the
library to a table of loaded libraries, so that multiple calls to loadlib do
not load the library multiple times.

- A tag method to unload the library.
- Alternatively the library can also export an 'Unregister' function to
remove the exported functions from lua.


Is there a mechanism like this in lua?
I would like to hear others opinions about this proposal, specially about
how would it interact with multiple lua states.

Thanks in advance,

Ignacio Castaño
[hidden email]



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Luiz Henrique de Figueiredo
> loadlib "wxlua"

loadlib already exists (as an addon) and defines a simple protocol for
loading and unloading a library. It's a good start.

loadlib must be an addon because it cannot be written in ANSI C.
--lhf

Reply | Threaded
Open this post in threaded view
|

RE: Lua libraries

Nick Trout-4
> I'm anoyed with the amount lua extensions out there. With lua 
> extensions I
> mean lua binaries that are linked with different libraries. 

I do agree this is an issue that I was going to resolve in Doris by having a
base executable and use loadlib to load extensions. In time perhaps I would
seperate out the GL, GLUT and GLUI code from Doris and provide this as a
library as well.

> - A single entrypoint in the library: (i.e. 
> Register(lua_State *) ) where
> all the lua functions are exported.
> - A new function in iolib (i.e. loadlib )
> - loadlib "wxlua"
> - A tag method to unload the library.
> - Alternatively the library can also export an 'Unregister' 
> function to remove the exported functions from lua.

I agree this would be sensible. It would be nice if loadlib were adopted by
the Lua community and modifed into a framework for writing standard modules.
eg. skeleton code, examples and docs. With maybe something similar to ppm in
time.

> how would it interact with multiple lua states.

I'll leave this one to the experts.

Regards,
Nick

Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

CRIBBSJ
In reply to this post by Ignacio Castaño
Ignacio Castaño wrote:

Hi,
I'm anoyed with the amount lua extensions out there. With lua extensions I
mean lua binaries that are linked with different libraries. The problem with
this approach is that you cannot use lua with two different libraries at the
same time. The only solution is to build your own lua, and that's only
possible if the source code of the libraries is publically available.
To solve that I would like to see a standard mechanism to write dinamic
libraries for lua. The requierements of that mechanism are very simple:

- A single entrypoint in the library: (i.e. Register(lua_State *) ) where
all the lua functions are exported.
- A new function in iolib (i.e. loadlib )

so you could do:

loadlib "wxlua"


and that would load the library, call the Register function, and add the
library to a table of loaded libraries, so that multiple calls to loadlib do
not load the library multiple times.

I was thinking about the exact same thing last night. I was surfing the web and I noticed that the author of SQL-Lite had a dynamic library that you could call from Tcl to access his dbms. I started thinking about all of the libraries that are available for Tcl and how easy it is to use them (just type "load mylib.dll"). I wish Lua had this.

I was thinkg along the same lines as Ignacio (but less technically, because I don't understand exactly how it all works). I know loadlib lets you call dlls. So if someone could maintain a compiled binary of "base" lua + loadlib, and then all of the extension authors could provide their library in the form of a dll that could be accessed through loadlib, this would give the lua community the same "ease of use" and functionality that Tcl now enjoys.

This would also satisfy a lot of the people, like me, who don't necessarily want to learn the ins and outs of C compiling. We just want a version of lua that has the libraries that we need.

Thanks, Ignacio, for bringing this up!

Jamey Cribbs

Reply | Threaded
Open this post in threaded view
|

RE: Lua libraries

Nick Trout-4
In reply to this post by Ignacio Castaño
> you could call from Tcl to access his dbms.  I started thinking about 
> all of the libraries that are available for Tcl and how easy it is to 
> use them (just type "load mylib.dll").  I wish Lua had this.

I think there are 2 ways of doing this, either runtime to preprocess.
Runtime, you could interrogate the DLL and find out what is available,
publish it and provide a mechanism to call it. eg.

*nix FFI: http://luagnome.free.fr/luaffi.php3
Perhaps this could be extended X-platform? A mechanism for doing this on
win32 was described a while back.

Or you could interogate the DLL and create a binding to Lua which again
could be a DLL. eg. to do type checking etc. This might be more appropriate
since you can add custom code for a particular module.

http://www.tecgraf.puc-rio.br/~rborges/loadlib/

 
> I was thinkg along the same lines as Ignacio (but less technically, 
> because I don't understand exactly how it all works).  I know loadlib 
> lets you call dlls.  So if someone could maintain a compiled 
> binary of 
> "base" lua + loadlib, and then all of the extension authors could 
> provide their library in the form of a dll that could be accessed 
> through loadlib, this would give the lua community the same "ease of 
> use" and functionality that Tcl now enjoys.

Apparently LuaYada contains loadlib: http://angg.twu.net/index.html#lua

Regards,
Nick

Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Daniel Silverstone
In reply to this post by CRIBBSJ
On Tue, Jan 29, 2002 at 08:23:49AM -0500, CRIBBSJ wrote:
> This would also satisfy a lot of the people, like me, who don't 
> necessarily want to learn the ins and outs of C compiling.  We just want 
> a version of lua that has the libraries that we need.

As the Debian maintainer of the Lua packages I have the following timeline:

1. Implement a lua40 package set and migrate the lua41 stuff to be called
lua41 instead of lua4

2. Implement a loadlibrary like thing (prolly use loadlib since it's there)

3. Make that the default lua for debian

4. Take as many extensions as I can find and add them to Debian as
loadlib'able extensions.

Unfortunately I don't know how much time I do/don't have to do it all in :(

Daniel

-- 
Daniel Silverstone                               http://www.digital-scurf.org/
Hostmaster, Webmaster, and Chief Code Wibbler          Digital-Scurf Unlimited
GPG Public key available from keyring.debian.org               KeyId: 20687895
philosophy:
	Unintelligible answers to insoluble problems.

Attachment: pgpwrwqgZFRfK.pgp
Description: PGP signature

Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Jay Carlson
In reply to this post by Luiz Henrique de Figueiredo

On Monday, January 28, 2002, at 07:59 PM, Luiz Henrique de Figueiredo wrote:

loadlib "wxlua"

loadlib already exists (as an addon) and defines a simple protocol for
loading and unloading a library. It's a good start.

Ah, but which loadlib? I know of at least three lua extensions by that name.

loadlib must be an addon because it cannot be written in ANSI C.

And it can't be written in POSIX C either. It's one of the harder things to get portable. I think we should seriously consider stealing the dynamic loading code from another tool, possibly Python, to avoid having to go through that headache ourselves.

Jay


Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

CRIBBSJ
In reply to this post by Daniel Silverstone
Daniel Silverstone wrote:

As the Debian maintainer of the Lua packages I have the following timeline:

1. Implement a lua40 package set and migrate the lua41 stuff to be called
lua41 instead of lua4

2. Implement a loadlibrary like thing (prolly use loadlib since it's there)

3. Make that the default lua for debian

4. Take as many extensions as I can find and add them to Debian as
loadlib'able extensions.

Unfortunately I don't know how much time I do/don't have to do it all in :(

I sure don't want to sound ungrateful to you Daniel, or to Nick Trout for your posts and the work you are doing, but I, for one, would really like to see this whole dynamic library thing available for the Windoze platform. Because of end-user demands, I find myself doing a lot of development on Windows. So implementing this functionality on Linux, while a great help, would still be just half the battle.

Jamey Cribbs

Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Philippe Lhoste
In reply to this post by Ignacio Castaño
Jamey Cribbs wrote:
> Ignacio Castaño wrote:
> 
> >I'm anoyed with the amount lua extensions out there. With lua extensions
I
> >mean lua binaries that are linked with different libraries. The problem
with
> >this approach is that you cannot use lua with two different libraries at
the
> >same time. The only solution is to build your own lua, and that's only
> >possible if the source code of the libraries is publically available.
> >To solve that I would like to see a standard mechanism to write dinamic
> >libraries for lua. The requierements of that mechanism are very simple:
> >
> >- A single entrypoint in the library: (i.e. Register(lua_State *) ) where
> >all the lua functions are exported.
> >- A new function in iolib (i.e. loadlib )
> >
> >so you could do:
> >
> >>loadlib "wxlua"
> >>
> >
> >and that would load the library, call the Register function, and add the
> >library to a table of loaded libraries, so that multiple calls to loadlib
do
> >not load the library multiple times.
> >
> I was thinking about the exact same thing last night. I was surfing the 
> web and I noticed that the author of SQL-Lite had a dynamic library that 
> you could call from Tcl to access his dbms. I started thinking about 
> all of the libraries that are available for Tcl and how easy it is to 
> use them (just type "load mylib.dll"). I wish Lua had this.
> 
> I was thinkg along the same lines as Ignacio (but less technically, 
> because I don't understand exactly how it all works). I know loadlib 
> lets you call dlls. So if someone could maintain a compiled binary of 
> "base" lua + loadlib, and then all of the extension authors could 
> provide their library in the form of a dll that could be accessed 
> through loadlib, this would give the lua community the same "ease of 
> use" and functionality that Tcl now enjoys.
> 
> This would also satisfy a lot of the people, like me, who don't 
> necessarily want to learn the ins and outs of C compiling. We just want 
> a version of lua that has the libraries that we need.
> 
> Thanks, Ignacio, for bringing this up!

Actually, this subject comes from time to time in this mailing list. It has
no interest for those using Lua embedded in their applications or in small
systems, but it is paramount for those using Lua as a system scripting tool.

Note that this is not as simple as just having loadlib available.
I imagine a socket library, a thread library, an OpenGL lib., etc., all can
have a function named sleep, for example.
So just blindly loading all these libraries at once will lead to an
undefined state.
As Nick mentioned:
> I agree this would be sensible. It would be nice if loadlib were adopted
by
> the Lua community and modifed into a framework for writing standard
modules.
> eg. skeleton code, examples and docs. With maybe something similar to ppm
in
> time.

we need to formalize a system like Perl's one (seems quite successful for
allowing quite a big number of libraries to exists) or Tcl one, etc., no
religion on this point.
A system allowing, of course, to load a library, but also formalizing a way
to specify the default path of such library (probably using an environment
variable), to specify namespace (perhaps Roberto's LTN can be used as such),
and to avoid other problems I will probably overlook.
Perferably, of course, all this must be portable, ie. should work in an
identical way in all systems, to avoid tweaking a plain Lua program to work on
our system.

Regards.

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--

Sent through GMX FreeMail - http://www.gmx.net


Reply | Threaded
Open this post in threaded view
|

RE: Lua libraries

Nick Trout-4
In reply to this post by Ignacio Castaño
> I sure don't want to sound ungrateful to you Daniel, or to Nick Trout 
> for your posts and the work you are doing, but I, for one, 
> would really 
> like to see this whole dynamic library thing available for 
> the Windoze 

>From loadlib that I am referring to
http://www.tecgraf.puc-rio.br/~rborges/loadlib/ :-

"It was tested on AIX 3/4, Linux, IRIX 5, SunOS 4/5, Windows 95/NT.
It was not tested for HP-UX and Next."

I use Win2k but all work I do for Lua I try hard to keep cross platform. The
authors have worked hard to maintain portability through ANSI compliance and
a lot of the libs are developed on *nix but fully portable.

Nick






Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Daniel Silverstone
In reply to this post by CRIBBSJ
On Tue, Jan 29, 2002 at 09:10:16AM -0500, CRIBBSJ wrote:
> I sure don't want to sound ungrateful to you Daniel, or to Nick Trout 
> for your posts and the work you are doing, but I, for one, would really 
> like to see this whole dynamic library thing available for the Windoze 
> platform.  Because of end-user demands, I find myself doing a lot of 
> development on Windows.  So implementing this functionality on Linux, 
> while a great help, would still be just half the battle.

There are several people working on win32 native things. Plus eventually you
could use Debian/w32 when we get around to getting it done :)

I'm sure there's at least one windows one with the loadlib stuff done, so
compiling up the loadlibbed versions I do for Debian native for win32
wouldn't be too hard.

Dan

-- 
Daniel Silverstone                               http://www.digital-scurf.org/
Hostmaster, Webmaster, and Chief Code Wibbler          Digital-Scurf Unlimited
GPG Public key available from keyring.debian.org               KeyId: 20687895
Just give Alice some pencils and she will stay busy for hours.

Attachment: pgpeNeOSe9rNc.pgp
Description: PGP signature

Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Jay Carlson
In reply to this post by Daniel Silverstone
On Tuesday, January 29, 2002, at 08:43 AM, Daniel Silverstone wrote:

On Tue, Jan 29, 2002 at 08:23:49AM -0500, CRIBBSJ wrote:
This would also satisfy a lot of the people, like me, who don't
necessarily want to learn the ins and outs of C compiling. We just want
a version of lua that has the libraries that we need.

As the Debian maintainer of the Lua packages I have the following timeline:

1. Implement a lua40 package set and migrate the lua41 stuff to be called
lua41 instead of lua4

Done, for potato.

The big question for me is whether to package pure Lua 4.0, or what I've been calling Lua 4.0.1: liblua40.so with lua_loadbuffer and lua_loadfile exposed, in order to support the new readline, line-spanning /usr/bin/lua.

2. Implement a loadlibrary like thing (prolly use loadlib since it's there)

I ended up using edrx's 2-argument loadlib:

  loadlib2(path_to_so, function_to_call)

The implementation is very simple, especially on systems like Linux and Solaris that have good dlopen() implementations. extensionname.so is explicitly linked against whatever shared libraries it needs, so that when you load lua_fltk.so, the dynamic loader will automatically bring in libfltk.so.1, libX11.so.1 etc. On platforms without ELF DT_NEEDED support in dlopen, the extension itself would have to do this. (All Debian platforms support this; the issue is with older/oddball systems like AIX and the Agenda snow library system.)

There are two annoyances I see in loadlib2:

a) You have to know both the name of the extension AND the name of its initialization function. Most other dynamic loading systems (Python's, for example) construct the name of the initialization function from the name of the extension. In the above example, loading "lua_fltk.so" would automatically call init_lua_fltk(S).

For debian packaging this isn't a big deal; just put loadlib2("lxp.so", "lua_initexpatlib") in /usr/share/lua40/lxp.lua, and have user code just require "lxp.lua" instead of having to know whether an extension is C or Lua code.

b) There's no way to close the library.

3. Make that the default lua for debian

Yeah, I was kinda unclear on whether I should do that. As you saw in my packages, I have a "purist" lua 4.0 installation, and then "dlua40" being the debianized, extensible version, with the usual alternatives dance.


4. Take as many extensions as I can find and add them to Debian as
loadlib'able extensions.

The process isn't too hard, but it does take a little time. Actually lua-fltk is problematic in that it currently needs a new lua.c to support the right select() goo to be able to interact with the interpreter while the fltk main loop is running.

Unfortunately I don't know how much time I do/don't have to do it all in :(

Would it help if I shipped woody source packages? I now have a couple of boxes tracking the testing distro, so it would be pretty easy.

Jay


Reply | Threaded
Open this post in threaded view
|

RE: Lua libraries

Nick Trout-4
In reply to this post by Ignacio Castaño
> we need to formalize a system like Perl's one (seems quite 
> successful for

To be honest I dont know that much about Perl, I just know its much easier
to use ppm than it is to try and download a module and install it yourself.
With Python you just unzip a package in the Python path and bingo it works.
People who use Linux will probably be more familiar with nice installation
software than us Windoze users.

I think what you'd need for each library - to keep it all simple is: the
library dll and a script which described:
 * the library API
 * wrapped in any extra Lua functionality ie. nice way of calling eg.
wxWindowCreate{name="foo"}
 * dependency info ie. Lua version, which other libs and versions we
require.
 * docs
 * authors, links to info etc.

Then you just unzip into the library path and require the appropriate script
wrapper which does the business for you.

Jay:
>> There are two annoyances I see in loadlib2:

loadlib has:

  static struct luaL_reg funcs[] = {
    {"loadlib",     loadlib},
    {"unloadlib",   unloadlib},
    {"callfromlib", callfromlib}

Nick

Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Luiz Henrique de Figueiredo
>The big question for me is whether to package pure Lua 4.0, or what I've 
>been calling Lua 4.0.1: liblua40.so with lua_loadbuffer and lua_loadfile 
>exposed, in order to support the new readline, line-spanning 
>/usr/bin/lua.

Please package pure Lua 4.0. There is no official 4.0.1 or such.
If you want, add the changes as patch file.

--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Victor Bogado da Silva Lins
In reply to this post by Jay Carlson
On Tue, 2002-01-29 at 12:41, Jay Carlson wrote:
> On Tuesday, January 29, 2002, at 08:43 AM, Daniel Silverstone wrote:
> 
> Done, for potato.
> 
> The big question for me is whether to package pure Lua 4.0, or what I've 
> been calling Lua 4.0.1: liblua40.so with lua_loadbuffer and lua_loadfile 
> exposed, in order to support the new readline, line-spanning 
> /usr/bin/lua.
> 
> > 2. Implement a loadlibrary like thing (prolly use loadlib since it's 
> > there)
> 
> I ended up using edrx's 2-argument loadlib:
> 
>    loadlib2(path_to_so, function_to_call)
> 
> The implementation is very simple, especially on systems like Linux and 
> Solaris that have good dlopen() implementations.  extensionname.so is 
> explicitly linked against whatever shared libraries it needs, so that 
> when you load lua_fltk.so, the dynamic loader will automatically bring 
> in libfltk.so.1, libX11.so.1 etc.  On platforms without ELF DT_NEEDED 
> support in dlopen, the extension itself would have to do this.  (All 
> Debian platforms support this; the issue is with older/oddball systems 
> like AIX and the Agenda snow library system.)
> 
> There are two annoyances I see in loadlib2:
> 
> a) You have to know both the name of the extension AND the name of its 
> initialization function.  Most other dynamic loading systems (Python's, 
> for example) construct the name of the initialization function from the 
> name of the extension.  In the above example, loading "lua_fltk.so" 
> would automatically call init_lua_fltk(S).
> 
> For debian packaging this isn't a big deal; just put loadlib2("lxp.so", 
> "lua_initexpatlib") in /usr/share/lua40/lxp.lua, and have user code just 
> require "lxp.lua" instead of having to know whether an extension is C or 
> Lua code.
> 
> b) There's no way to close the library.
> 
> > 3. Make that the default lua for debian
> 
> Yeah, I was kinda unclear on whether I should do that.  As you saw in my 
> packages, I have a "purist" lua 4.0 installation, and then "dlua40" 
> being the debianized, extensible version, with the usual alternatives 
> dance.
> 
> >
> > 4. Take as many extensions as I can find and add them to Debian as
> > loadlib'able extensions.
> 
> The process isn't too hard, but it does take a little time.  Actually 
> lua-fltk is problematic in that it currently needs a new lua.c to 
> support the right select() goo to be able to interact with the 
> interpreter while the fltk main loop is running.
> 
> > Unfortunately I don't know how much time I do/don't have to do it all 
> > in :(
> 
> Would it help if I shipped woody source packages?  I now have a couple 
> of boxes tracking the testing distro, so it would be pretty easy.
> 
> Jay

	I would add that the loadlib should receive a logical name, I mean it
should be 

	loadlib ("fltk")

		instead of 

	loadlib ("/xxx/yyy/liblua_fltk.so")

	The loading mechanism would transate the logical name "fltk" to the
path of the library needed it could be liblua_fltk.so in a unix
enviroment or lua_fltk.dll in windows or even something diferent like
loading a library in a palmos enviroment that does not have files at
all.

-- 
[]'s Victor Bogado da Silva Lins
[hidden email]




Reply | Threaded
Open this post in threaded view
|

RE: Lua libraries

Nick Trout-4
In reply to this post by Ignacio Castaño
> I think what you'd need for each library - to keep it all 
> simple is: the
> library dll and a script which described:
>  * the library API
>  * wrapped in any extra Lua functionality ie. nice way of calling eg.
> wxWindowCreate{name="foo"}
>  * dependency info ie. Lua version, which other libs and versions we
> require.
>  * docs
>  * authors, links to info etc.


 * and a parser which scanned in all the copyright notices, library
dependencies, modifications and code, and distribution notices and made sure
you weren't in breach of any of the them!

any volunteers?

:-D


Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Roberto Ierusalimschy-5
In reply to this post by Victor Bogado da Silva Lins
On 29 Jan 2002, Victor Bogado da Silva Lins wrote:

> 	I would add that the loadlib should receive a logical name, I mean it
> should be
>
> 	loadlib ("fltk")
>
> 		instead of
>
> 	loadlib ("/xxx/yyy/liblua_fltk.so")
>
> 	The loading mechanism would transate the logical name "fltk" to the
> path of the library needed it could be liblua_fltk.so in a unix
> enviroment or lua_fltk.dll in windows or even something diferent like
> loading a library in a palmos enviroment that does not have files at
> all.

Another approach is to "wrap" C libraries in Lua, and then use the new
"require" function to load them. In your program, you would always write

  require "libname"

without worring whether you are loading a Lua library or a C library.
For C libraries, we would put in the lib directory a Lua file like this:

  loadlib("/xxx/yyy/.../...")

or even

  loadlib("/xxx/yyy/.../...", "initfunc")

To adjust between diferent systems you only need to edit this small file.

Because loadlib is not portable, we should try to keep it as simple as
possible.

-- Roberto


Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Daniel Silverstone
In reply to this post by Jay Carlson
On Tue, Jan 29, 2002 at 09:41:34AM -0500, Jay Carlson wrote:
> Would it help if I shipped woody source packages?  I now have a couple 
> of boxes tracking the testing distro, so it would be pretty easy.

Punting the lua40 package over to me if you like would be nice.

I need to make sure that all the stuff I write is for 40 and 41 though :)

Unfortunately I am using 41 in all my new projects 'cos I can track 4.1
development with the -work releases fine (unless we're waiting about 9
months for 4.1 in which case I'll just have to freeze at 4.1-work3)

If the lua40 package is up to scratch for unstable/testing I'll put it in
and adapt my 41 packages to say 41 instead of 4

Sound okay?

Daniel

-- 
Daniel Silverstone                               http://www.digital-scurf.org/
Hostmaster, Webmaster, and Chief Code Wibbler          Digital-Scurf Unlimited
GPG Public key available from keyring.debian.org               KeyId: 20687895
You never gain something but that you lose something.
		-- Thoreau

Attachment: pgpjXDz8zGxi_.pgp
Description: PGP signature

Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Victor Bogado da Silva Lins
In reply to this post by Roberto Ierusalimschy-5
On Tue, 2002-01-29 at 13:10, Roberto Ierusalimschy wrote:
> On 29 Jan 2002, Victor Bogado da Silva Lins wrote:
> 
> Another approach is to "wrap" C libraries in Lua, and then use the new
> "require" function to load them. In your program, you would always write
> 
>   require "libname"
> 
> without worring whether you are loading a Lua library or a C library.
> For C libraries, we would put in the lib directory a Lua file like this:
> 
>   loadlib("/xxx/yyy/.../...")
> 
> or even
> 
>   loadlib("/xxx/yyy/.../...", "initfunc")
> 
> To adjust between diferent systems you only need to edit this small file.
> 
> Because loadlib is not portable, we should try to keep it as simple as
> possible.
> 

	I personaly don't like this solution, this would require a diferent
file for each plataform. I think it is cleaner to have a diferent lib
loader for each plataform and a single source for a library for all
plataforms. Perl works this way, and I think python too. 

	There is a multiplataform library loader in glib, maybe we should check
this.
 
-- 
[]'s Victor Bogado da Silva Lins
[hidden email]




Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Thatcher Ulrich
In reply to this post by Nick Trout-4
On Jan 29, 2002 at 02:46 -0000, Nick Trout wrote:
> 
> > we need to formalize a system like Perl's one (seems quite 
> > successful for
> 
> To be honest I dont know that much about Perl, I just know its much easier
> to use ppm than it is to try and download a module and install it yourself.

Actually, if you do "perl -MCPAN -e shell" (intuitive, I know :), you
get an interactive shell that finds the package, and does the
downloading and the unzipping for you (and the compiling in some
cases, and the dependency checking, etc).

The first time I used it, I was astonished.  Coming from a Windows
background I'd never seen anything so cool.  Easily impressed I guess.

I don't think Lua really should aspire to be a Perl replacement
though.  In the spirit of keeping things small and simple (which is
not the Perl spirit), I think if we can bless one of the loadlib's as
the preferred one, and establish some baseline conventions for making
packages get along with each other, and start producing our add-ons
within those conventions, then we don't need all the bells and
whistles right away.  We'll have taken a huge and welcome step
forward.

Having to download and unzip a package into a certain directory, and
possibly chase down dependencies, is A-OK in my book, if it means I
can take Lua packages for a test drive without futzing with a
compiler.  Being able to test drive more than one extension at a time
is a crucial feature too.  Also, I think this module effort will help
embedded people as well -- it provides an easy way to evaluate
packages you might want to incorporate in your system.  I for one
would certainly use it in a game engine, at least during development,
given that some of these packages will be things like OpenGL bindings.

-- 
Thatcher Ulrich <[hidden email]>
http://tulrich.com

123