Lua libraries

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

Re: Lua libraries

Jay Carlson

On Tuesday, January 29, 2002, at 09:54 AM, Luiz Henrique de Figueiredo wrote:

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.

Yeah, I know there's no Lua 4.0.1, and it would be a bad idea to call it that. I'm just calling it that in my head for now.

Anyway, after applying the patches, what do I call the resulting libraries and binaries? I'm shipping binaries, so the user won't see the patch file.

The shared library liblua40-patched-with-loadbuffer.so.1.1 is completely compatible with all current uses of liblua40.so.1.0; that is a sufficient condition for it to share the same soname ("liblua40.so.1"). That doesn't mean they *should* share an soname, but it does at least seem reasonable.

There's a separate issue of whether the shipped lua.h should include definitions for lua_loadbuffer. My inclination would be "no", because it would force people to stick with the lua-4.0.tar.gz interface unless they explicitly declared lua_loadbuffer.

What do I do with the accumulated bug fix patches from lua-l? Can I patch them into /usr/lib/lua40.so.1 and /usr/bin/lua40, or do I need to get a new name for that?

I think it would be useful to have an official Lua 4.0.1 with lua_loadbuffer and bug fixes. The charter would be "no third party code", "no significant new features" (lua_loadbuffer just being an existing function exposed), "completely backwards compatible". I think that means "no lua 4.1 /usr/bin/lua".

I'm willing to do the legwork for putting together such a patch/distribution. I believe it would maintain the "no third party code" standard, as it's just tecgraf people's patches that are being applied.

Jay


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 10:30 AM, Daniel Silverstone wrote:

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.

http://www.place.org/~nop/lua/debian/ is current status for potato. I haven't shipped woody packages because the ones I have are just hacked together enough to work. I need to review the packaging standards.

Known screwups: a silly source file name (liblua4.0-loadlib2-1.0_1.0-1.dsc) and a complete lack of Build-Depends. I'll spin the crank on these packages again tonight for potato, and then forward-port them to woody. (Largely re-yada'ing.)

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)

I'm stuck with 4.0 until tolua catches up. Been considering porting it to 4.1 myself.

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?

Yes, quite. I'm interested in making your life easier, and I'm more than willing to take advice and suggestions. I'm not a Real Debian Developer, so you know more than I do about what's good and proper.

Jay


Reply | Threaded
Open this post in threaded view
|

unsubscribe

Carlos Souza
In reply to this post by Daniel Silverstone
----- Original Message ----- 
From: "Daniel Silverstone" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Tuesday, January 29, 2002 1:30 PM
Subject: Re: Lua libraries




Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Thomas Wrensch-2
In reply to this post by Daniel Silverstone

On Tue, 29 Jan 2002, Daniel Silverstone wrote:

> 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

These load ideas sound wonderful, and I would be quite happy with a simple
one that requires a bit of extra work to load if it means it comes
sooner. However, I have much the same problem as M. Silverstone as I've
switched all work over to 4.1-work3.

While it may seem unsafe to use a work verion for production work, it
seems as if the work3 verison is at least as solid as any production
software I've every used. 

The "problem" is that the changes is 4.1 are so useful that I can't make
myself switch back to 4.0 or in some cases to 3.2 to get access to some of
the add-ons. Having the loadlib work for 4.1-work3 would make me a happy
person. Optionally making it work for the final 4.1, if it came out
relatively soon, would make me pretty happy.

I know how much work finalizing a version is in terms of documentation and
such, so I'm not saying it should be completed right away. I guess I'm
just impatient.

  - Tom Wrensch


Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Steve Dekorte-4
In reply to this post by Luiz Henrique de Figueiredo

On Monday, January 28, 2002, at 04: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.

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

Which is a big problem because dynamic libs work differently on each platform and create a bunch of problems for use when distributing user-level apps. (not everyone can or wants to write a bunch of files to their system directories just to run a user level app).

How about creating a lua distribution that's designed for easily adding (static) add-ons without mucking with lua source - just have a config file that the Makefile looks at for info on what to link and the functions to call to open/close the lib.

Steve



Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Ignacio Castaño
In reply to this post by Ignacio Castaño
It seems that we are talking about two different things here. I was
proposing a standard way of defining lua libraries, that should be portable
acrooss multiple platforms, and should for this reason abstract details
about the operating system, like the path of the library and
prefixes/sufixes.

As Philippe Lhoste mentioned there could be namespace issues, but that can
be easily solved using prefixes or storing the functions in a table, for
example. We could also agree a standard way of exporting data to avoid
namespace clases, but that's not the topic neither.

I just want a simple way to load multiple libraries, but only lua libraries,
that is, modules that have a been designed for lua and have agreed to share
a common interface.

It seems that the 'loadlib' name has already been used, so using that name
would probably confuse many people. There are many other posibilities out
there: 'openlib', loadmodule, 'use', 'uselib', 'loadlibrary', 'loadlualib'
etc.

If nobody minds, I will be writting a lua addon for windows, linux and
solaris (the platforms I have available) in a few days with the
requierements I have in mind. Any suggestion will be welcomed.

By the way, I like the word 'use', like in perl (requiere/use), but in perl
modules are not dynamically linked, and for this reason there is not a
'stopusing' lib counterpart.


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

Ignacio Castaño
Ignacio Castaño wrote:
> namespace clases, but that's not the topic neither.

I meant clashes or collisions ;-)


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

Ignacio Castaño
In reply to this post by Thatcher Ulrich
Thatcher Ulrich wrote:
> 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.

I agree with you that establishing some conventions for making modules would
be a great step forward ;-)

The problem of loadlib is that even if it works on multiple platforms the
behaviour on them is different. Since lua has adopted the 'requiere' term to
load requiered lua files once, probably inspired by perl's 'require'. We
could adopt the 'use' term to load requiered libraries. The difference,
however, is that perl loads modules statically and lua does it dynamically.

What I'm not really sure is, if there should be a mechanism to explicitely
unload modules. Libraries should be kept in a table to avoid double loading
them, so closing the lua state would remove the libraries and with tag
methods you can prevent leaks, so that's not a problem. I just want to know
if it's necessary or if it's a good idea to unload a module, and remove the
functions it has exported.



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

Thatcher Ulrich
On Jan 29, 2002 at 10:06 +0100, Ignacio Castaño wrote:
> 
> What I'm not really sure is, if there should be a mechanism to explicitely
> unload modules. Libraries should be kept in a table to avoid double loading
> them, so closing the lua state would remove the libraries and with tag
> methods you can prevent leaks, so that's not a problem. I just want to know
> if it's necessary or if it's a good idea to unload a module, and remove the
> functions it has exported.

IMO, this is a nice feature, but in the "bells and whistles" category.
It might be good to have it eventually, but I personally don't have an
immediate use for it.  I use Perl's "use" all the time, and never
really thought about unloading a module.  I guess the issue is
determining how/whether library instances get shared.

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

Reply | Threaded
Open this post in threaded view
|

RE: Lua libraries

Nick Trout-4
In reply to this post by Ignacio Castaño
> It seems that we are talking about two different things here. I was
> proposing a standard way of defining lua libraries, that 
> should be portable
> acrooss multiple platforms, 

I think this is the way to go. I cant really can't see the point of writing
a config file to build a static exe. Thats whats done already. It means that
the executable needs to contain all libraries available to Lua and if you
merely want to try something out you have to build a new version etc. It
doesnt solve the problem.

> and should for this reason 
> abstract details
> about the operating system, like the path of the library and
> prefixes/sufixes.

This would be nice. I think the DLLs just need to be in your path to be
loaded but it would be nice to add the functionality to search a "lua path"
for scripts and libraries. As Roberto points out require can be used to load
both if the DLL has a wrapper script. There are other benefits to having a
wrapper rather than just for loading.

It would be nice if Lua had something similar to Pythons os and os.path
modules so you can stick paths together and manipulate them cross platform.
*STD library people?*

> It seems that the 'loadlib' name has already been used, so 
> using that name
> would probably confuse many people. There are many other 
> posibilities out
> there: 'openlib', loadmodule, 'use', 'uselib', 'loadlibrary', 
> 'loadlualib'

It can be used again as "require" can be used to load a script. use etc are
not needed.

> If nobody minds, I will be writting a lua addon for windows, linux and
> solaris (the platforms I have available) in a few days with the
> requierements I have in mind. Any suggestion will be welcomed.

Please do. I had a little play around as well. Will post what I have when a
little more complete.

Regards,
Nick


Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Steve Dekorte-4

On Wednesday, January 30, 2002, at 02:03  AM, Nick Trout wrote:
It seems that we are talking about two different things here. I was
proposing a standard way of defining lua libraries, that
should be portable across multiple platforms,

I think this is the way to go. I cant really can't see the point of writing
a config file to build a static exe. Thats whats done already.

Not in any of the code I've seen. What's done now is each ad-on comes with code for it's own lua executable. Essentially, Lua is added on the "libs" instead of the other way around.

It means that
the executable needs to contain all libraries available to Lua and if you
merely want to try something out you have to build a new version etc. It
doesnt solve the problem.

It depends on which problem you are trying to solve. It does solve the problem of being able to easily combine libs.

and should for this reason
abstract details
about the operating system, like the path of the library and
prefixes/sufixes.

This would be nice. I think the DLLs just need to be in your path to be
loaded but it would be nice to add the functionality to search a "lua path"
for scripts and libraries.

Don't some platforms require the executable to know the absolute path to the shared lib while not providing the app with info about the path the executable?(Linux?) So the shared libs are essentially required to be in system folders and therefore seriously complicate user-level applications - admin access is required to install the libs & whose shared lib gets installed if two apps have a shared lib with the same name? It's dangerous to make the assumption that everyone that will want to be able to run a lua app is also a sysadmin.

Making shared libs the standard for lua-addons would make lua both platform dependent and sysadmin dependent.

Steve



Reply | Threaded
Open this post in threaded view
|

RE: Lua libraries

Nick Trout-4
In reply to this post by Ignacio Castaño
> Don't some platforms require the executable to know the 
> absolute path to 
> the shared lib while not providing the app with info about 
> the path the 
> executable?(Linux?) So the shared libs are essentially 
> required to be in 
> system folders and therefore seriously complicate user-level 
> applications - admin access is required to install the libs & whose 
> shared lib gets installed if two apps have a shared lib with the same 
> name? It's dangerous to make the assumption that everyone 
> that will want 
> to be able to run a lua app is also a sysadmin.
> 
> Making shared libs the standard for lua-addons would make lua both 
> platform dependent and sysadmin dependent.


How do Lua and Python cope with this? I dont think you need admin privileges
to install new modules on Python on any platform? (could someone please
inform me otherwise?)

So far as I know this would be very simple cross platform, you could just
have a directory/s which you dump your libs into, make sure its in LUA_PATH
and require the module.

Just because a standardised framework exists to do this doesnt mean that you
cant do it the current way. You should still be able to combine any
libraries with your app and build a single executable if you so require as
Lua may be embedded too. The flexibility of use of Lua still needs to be
there.

Nick


Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Reuben Thomas
In reply to this post by Steve Dekorte-4
> Don't some platforms require the executable to know the absolute path to
> the shared lib while not providing the app with info about the path the
> executable?(Linux?)

Nah, you can set LD_PRELOAD_PATH on Linux.

> Making shared libs the standard for lua-addons would make lua both
> platform dependent and sysadmin dependent.

This however is a problem. A better way of easily adding libs to a
standard build (preferably without having to edit any source) would be a
big win. Even something as low-tech as a file containing calls to init
functions that was then #included into lua.c.

-- 
http://sc3d.org/rrt/ | habit, n.  a shackle for the free (Bierce)


Reply | Threaded
Open this post in threaded view
|

RE: Lua libraries

Nick Trout-4
In reply to this post by Ignacio Castaño
> > Making shared libs the standard for lua-addons would make lua both
> > platform dependent and sysadmin dependent.
> 
> This however is a problem. A better way of easily adding libs to a
> standard build (preferably without having to edit any source) 
> would be a
> big win. Even something as low-tech as a file containing calls to init
> functions that was then #included into lua.c.

What if any module distribution contains a static and dynamic library for
linking either way? 

And how about the same script which you "require" to load a dynamic module
also contains information to add a call to the init library function and
include a header between some predetermined comments or macros. 

eg.

lib_foo wrapper inserts: libfooopen(L);

/* LUA_LIBS_BEGIN */
libfooopen(L);
/* LUA_LIBS_END */

You could run this script as part of your makefile and it could also check
and add dependencies? Is this overly complex?

Nick


Reply | Threaded
Open this post in threaded view
|

Variable declaration

Chris Percival
Is there a quick and easy way of making a lua script require variable
declarations.  I expect my program to have quite large lua scripts used with
it, and being able to just use a variable without declaring it first will
allow all sorts of problems to arise.  It reminds me of BASIC.. *shudder*.
This is all IMHO of course.  I saw somthing in the archives about using
getglobal and setglobal functions, although idealy the fact that lua has
been changed would be invisable from those writing lua scripts.  I am using
version 4.0 by the way.

Thanks.

Chris Percival
Software Engineer
Interaxis Computing Ltd.
DDI:  +44 (0)1249 700072
http://www.interaxis.co.uk/


Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

J. Perkins-2
In reply to this post by Steve Dekorte-4
Steve Dekorte wrote:

Don't some platforms require the executable to know the absolute path to the shared lib while not providing the app with info about the path the executable?(Linux?) So the shared libs are essentially required to be in system folders and therefore seriously complicate user-level applications


I've worked around this in my project using a very ugly but
effective hack. Since you need platform specific code to load
the libraries anyway it may not be a big deal.

In a nutshell:

- Grab argv[0], split off the path, and chdir() there

- getcwd() to get the full path back

- Use getenv()/putenv() to add the path to LD_LIBRARY_PATH
  (or wherever is appropriate for the system)

Here comes the ugly part:

- Call execve() to restart the process under the new environment

Shared libraries located in the same directory as the exec
will be found and loaded. Tested on Linux and BeOS (don't
need it for Win32 which has this behavior by default).

Jason


Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Ignacio Castaño
In reply to this post by Reuben Thomas
Steve Dekorte wrote:
> Don't some platforms require the executable to know the absolute path to
> the shared lib while not providing the app with info about the path the
> executable?(Linux?)

Linux uses the LD_LIBRARY_PATH var to store library search paths. But
anyway, i will add a key in lua named _LUALIBPATH to specify for example, a
custom path to look up for the lua libraries.


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

Nick Trout-4
In reply to this post by Ignacio Castaño
> Linux uses the LD_LIBRARY_PATH var to store library search paths. But
> anyway, i will add a key in lua named _LUALIBPATH to specify 
> for example, a
> custom path to look up for the lua libraries.

v4.1 has LUA_PATH defined for require. Why dont you use this?

Nick

Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

David Jeske-3
In reply to this post by Ignacio Castaño
In reading this thread, it seems to me like some people are talking
about "lua libraries and modules" in the interest of making Lua more
useful as a general purpose scripting language like Python and Perl. I
have a few thoughts on this I'd like to share.

My impression is that the "lua standard library workshop" is really
about just that, changes to the lua standard library. It's still going
to be built into lua, and lua is still going to be primarily an
embedded language.

I believe that any attempt to make a widespread set of standard
libraries for Lua will probably be kludgy. All the intersting
"prototyped objects" features which make Lua interesting for
exploratory embedded programming are a problem when it comes to
packaging up a bunch of code in a standard way. First, there would be
discussion about standardizing on one class-ish model, then there
would be talk of adding exceptions to Lua, and at the end we'd have
something which was basically like Perl or Python with 1/10 of the
available modules.

Anyhow, that's my $0.02.

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Steve Dekorte-4
In reply to this post by Reuben Thomas

On Wednesday, January 30, 2002, at 04:11  AM, Reuben Thomas wrote:
Don't some platforms require the executable to know the absolute path to
the shared lib while not providing the app with info about the path the
executable?(Linux?)

Nah, you can set LD_PRELOAD_PATH on Linux.

And how do you know what to set that to if the executable doesn't get info on which path it's in? Do you have to now have fixed install locations within the user's directory?

Making shared libs the standard for lua-addons would make lua both
platform dependent and sysadmin dependent.

This however is a problem. A better way of easily adding libs to a
standard build (preferably without having to edit any source) would be a
big win. Even something as low-tech as a file containing calls to init
functions that was then #included into lua.c.

I agree.

Steve



123