Lua libraries

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

Re: Lua libraries

Ignacio Castaño
Nick Trout wrote:
> > 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?

That seems like a good idea, I will look for libraries in LUA_PATH, but also
in LUA_LIBPATH in case someone wants to put libraries in a different
directory.

I've uploaded here a first version of the addon here:
http://talika.fie.us.es/~titan/lua/

Feel free to criticise. It has not been extensively tested, tomorrow I will
try to write a simple library and some examples of its use.

The platform dependant code is isolated in a few macros and definitions, so
that if someone wants to port it to a different platform only has to touch a
few lines of code.


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

Steve Dekorte-4
In reply to this post by Nick Trout-4

On Wednesday, January 30, 2002, at 02:59  AM, Nick Trout wrote:
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?)

(I'm guessing you meant Perl and Python) - They don't cope with it. They require the user to set an environment to a fixed path where all the shared libs are. Those languages weren't designed for embedding in consumer apps. They assume the user is a developer or sysadmin.

Steve



Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Thatcher Ulrich
On Jan 30, 2002 at 12:43 -0800, Steve Dekorte wrote:
> 
> On Wednesday, January 30, 2002, at 02:59  AM, Nick Trout wrote:
> > 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?)
> 
> (I'm guessing you meant Perl and Python) - They don't cope with it. They 
> require the user to set an environment to a fixed path where all the 
> shared libs are. Those languages weren't designed for embedding in 
> consumer apps. They assume the user is a developer or sysadmin.

No -- Perl has a "use lib 'path/to/libs'" facility, and you can access
the @INC list as well.

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

Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Steve Dekorte-4

On Wednesday, January 30, 2002, at 01:06  PM, Thatcher Ulrich wrote:
No -- Perl has a "use lib 'path/to/libs'" facility, and you can access
the @INC list as well.

So a perl app, the perl vm and shared libs can all be in a directory that can be moved by the user and the app will still run without modifying anything?

Steve



Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Thatcher Ulrich
On Jan 30, 2002 at 01:10 -0800, Steve Dekorte wrote:
> 
> On Wednesday, January 30, 2002, at 01:06  PM, Thatcher Ulrich wrote:
> > No -- Perl has a "use lib 'path/to/libs'" facility, and you can access
> > the @INC list as well.
> 
> So a perl app, the perl vm and shared libs can all be in a directory 
> that can be moved by the user and the app will still run without 
> modifying anything?

I believe so, provided the right paths are pointed to.  Personally
I've only ever used @INC and 'use lib' to get at locally installed
modules, not to install Perl itself.

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

Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Jim Mathies-2
In reply to this post by Ignacio Castaño
Seems a system like this assumes a couple things:

- for WIN32, the Lua vm is also a DLL and the dynamically loaded
'interface DLL' is linked to it's stub. (otherwise, how does the interface
DLL gain access to the lua vm functional interface?)

- the vm is unmodified, including through the use of 4.1's
LUA_USERSTATE. Which, makes programming context based
interfaces tough, since you can't inject anything into the Lua
state structure.

yes, or am I missing something?

Regards,
Jim

That seems like a good idea, I will look for libraries in LUA_PATH, but also
in LUA_LIBPATH in case someone wants to put libraries in a different
directory.

I've uploaded here a first version of the addon here:
http://talika.fie.us.es/~titan/lua/

Feel free to criticise. It has not been extensively tested, tomorrow I will
try to write a simple library and some examples of its use.

The platform dependant code is isolated in a few macros and definitions, so
that if someone wants to port it to a different platform only has to touch a
few lines of code.


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

RLak
In reply to this post by Ignacio Castaño
David Jeske escribió:

> 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 hope that is true.

> I believe that any attempt to make a widespread set of standard
> libraries for Lua will probably be kludgy.

I personally think that any attempt to make a widespread set of
standard libraries for any programming language tends to be kludgy.
However, that doesn't make them unuseful. It can make them hard
to integrate with each other. This is particularly true for standard
object libraries IMHO: while I won't claim to be an expert, from what
I've seen, object libraries do not tend to realise the promise of
reusable code to the extent that we might have dreamed about.

> 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.

I wouldn't have put it that way. The fact that Lua does not come with
much in the way of standards makes it difficult to package standards.
This is not at all related to prototypes. One has only to look at the
standard
"libraries" (or templates) which come/came with NewtonScript (another
prototype-object language) to see the possibilities. Personally, if I had
the time and hardware available, I would love to reimplement the
NewtonScript
display model in Lua. Walter Smith is quite eloquent about the advantages
that
prototyping gives in producing graphical applications, but I suspect that
one
has to experience the difference to appreciate it.

Of course, NewtonScript is/was a tad more structured (but just a tad :-)

Prototypes are good at building components. Components are arguably a
higher-level construct than objects, although the distinction may not
be very precise. Templated components do seem to be reusable and
integratable;
however, they certainly restrict flexibility. This is not always a bad
thing.

> 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.

That is a very harsh judgement, no? But there may be a grain of truth to
it. :-)

I would like to hope that the discussion proceeds with a view to retaining
that
which is special about Lua, and not with a view to making Lua into Python
or
Perl. Lua is not Python; I'm sure that both have their place. There is,
dare I
say it, a certain Zen to any programming language and getting your head
into
it is critical to making your life simpler. Or if not, using a programming
language that suits your way of thinking, or your particular problem
domain.

As far as "talk of adding exceptions to Lua", or "one class-ish model",
neither
of these really appeal to me. I think that Lua has adequate mechanisms for
doing what I want it to do with object-ish things. It is maybe slightly
lacking
in control structures, but I personally would like to see a building block
at a
slightly lower level than exceptions. (Non-local exits as first-class
functional
objects, to be precise.) So now I've contributed to the "talk" :-)

My S/0.02...





Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Ignacio Castaño
In reply to this post by Jim Mathies-2
<[hidden email]> wrote:
> Seems a system like this assumes a couple things:
>
> - for WIN32, the Lua vm is also a DLL and the dynamically loaded
> 'interface DLL' is linked to it's stub. (otherwise, how does the interface
> DLL gain access to the lua vm functional interface?)

doesn't have to. The lua library can be statically linked with lua.

That brings some problems to my mind. What if the library is built with a
different lua version? A possible solution would be to add another
entrypoint in the library to obtain the lua version, and check that before
loading it.


> - the vm is unmodified, including through the use of 4.1's
> LUA_USERSTATE. Which, makes programming context based
> interfaces tough, since you can't inject anything into the Lua
> state structure.

yes, but you can always rebuild the libraries with your own lua flabor.


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: Variable declaration

Luiz Henrique de Figueiredo
In reply to this post by Chris Percival
>Is there a quick and easy way of making a lua script require variable
>declarations.

For globals, see FAQ 3.1.
--lhf

Reply | Threaded
Open this post in threaded view
|

RE: Variable declaration

Chris Percival
I am aware of this section of the FAQ, however I cannot get this to work.
>From my understanding of this code, adding this code to the begining of a
script should be all I need?

eg?

function safe_getglobal(x)
  local v=rawgetglobal(x)
  if v then return v else error("undefined global variable "..x) end
end

settagmethod(tag(nil),"getglobal",safe_getglobal)

x = 10


This should cause the function safe_getglobal to be run, because of the
assignment to global x?  It doesn't seem to run for me?  What am I doing
wrong?  Also I would like this code to be done in C and not from within the
script.

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

> -----Original Message-----
> From: [hidden email]
> [[hidden email] Behalf Of Luiz Henrique de
> Figueiredo
> Sent: 31 January 2002 12:01
> To: Multiple recipients of list
> Subject: Re: Variable declaration
>
>
> >Is there a quick and easy way of making a lua script require variable
> >declarations.
>
> For globals, see FAQ 3.1.
> --lhf


Reply | Threaded
Open this post in threaded view
|

RE: Variable declaration

Luiz Henrique de Figueiredo
In reply to this post by Chris Percival
>From my understanding of this code, adding this code to the begining of a
>script should be all I need?

Yes. Except that
	rawgetglobal(x)
should now be
	rawget(globals(),x)

(Sorry, the FAQ needs updating...)

>x = 10
>
>This should cause the function safe_getglobal to be run, because of the
>assignment to global x?

No.  It's "get" not "set". Try "print(x)" instead.

For a different technique, see '"Global" keyword' in
	http://lua-users.org/wiki/NamespacesAndModules
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Ignacio Castaño
In reply to this post by Jim Mathies-2
jim wrote:
> Seems a system like this assumes a couple things:
>
> - for WIN32, the Lua vm is also a DLL and the dynamically loaded
> 'interface DLL' is linked to it's stub. (otherwise, how does the interface
> DLL gain access to the lua vm functional interface?)

sorry, you were right, if lua is statically linked to the library, then
there will
be allocation conflicts. Does it happens the same in other platforms or it's
a win32 issue only?


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: Variable declaration

Philippe Lhoste
In reply to this post by Chris Percival
> >Is there a quick and easy way of making a lua script require variable
> >declarations.
> 
> For globals, see FAQ 3.1.
> --lhf

I forgot this, I must admit.
But the VB's Option Explicit I mentioned also works for local variables.
Mmm, but of course, for a variable to be local, it must be declared, so
there is no problem again.

Just wondering: is there a big performance cost with this method? Since this
is a Lua function called each time we use a global variable.

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: Variable declaration

Luiz Henrique de Figueiredo
In reply to this post by Chris Percival
>Just wondering: is there a big performance cost with this method? Since this
>is a Lua function called each time we use a global variable.

No, the function is only called for variables with value nil, ie undefined
variables.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Thatcher Ulrich
In reply to this post by Ignacio Castaño
On Jan 30, 2002 at 09:43 +0100, Ignacio Castaño wrote:
> 
> I've uploaded here a first version of the addon here:
> http://talika.fie.us.es/~titan/lua/

I couldn't wait to start hacking on this... I made some binaries to
demonstrate the module concept, using my existing luaSDL binding.  You
can get them here:

http://tulrich.com/geekstuff/files/luaSDL.zip

That .zip includes both Linux and Win32 binaries, and a little sample
SDL game written in Lua.  I'm including the README from that zip file
below.

Thanks for the code Ignacio!

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



------- README-lm.txt -------
Lua Module experimentation

I've hacked together some binaries and a sample module using Ignacio
Castaño's prototype luselib code.  I've made Windows and Linux
versions that seem to work.  There is:

* a "luse" executable, which is a very basic Lua 4.0 toplevel (no
  command-line niceties), that provides the use() Lua function to load
  a Lua module DLL.

* lua.dll for Win32, which is used by luse.exe (includes both core
  Lua, and the libraries).

* (drumroll) a sample Lua Module that provides an SDL binding!
  Comprised of SDL.lm (Lua code), libluaSDL.so (for Linux) and
  luaSDL.dll (for Win32).  Lua programs that want SDL just need to do 

* liblua.so and liblualib.so, used by the Linux 'luse' executable.

All files for both platforms are just jumbled together in the same
directory.  

WIN32:

To run the sample, just unzip, change to the directory, and type "luse
meteor_shower.lua", or "go.bat".

LINUX:

Unzip the files somewhere.  Move liblua.so, liblualib.so, and
libluaSDL.so to somewhere in your library path.  For example, I put
them in ~/lib , and then do "export LD_LIBRARY_PATH=$HOME/lib".  Leave
everything else in the luaSDL/ directory.  Change to luaSDL/, and do
"./luse meteor_shower.lua" to run the sample.

BOTH PLATFORMS:

You can also run 'luse' interactively -- just don't give any
command-line args.  It's vanilla Lua 4.0, plus the use() function.

NOTES:

* I had to comment out the part of Ignacio's code which registers some
  library info in a Lua table -- it was causing crashes on both
  platforms.  So use()'ing a library more than once may create
  problems!

* My build process includes manual steps, so you probably won't be
  able to reproduce what I did from source.  This is just an
  experiment at this point.

* My SDL module does not yet use the excellent recommendations from
  Roberto's LTN7 (the core idea being, put all module symbols in a
  table, to prevent namespace problems).

* This is very cool!  Once we nail down some standards and get the
  kinks worked out, I'm looking forward to using people's modules!
  We'll all be writing portable Lua code that combines SDL with
  OpenGL, GUI toolkits, db access, CGI and whatever, without touching
  a C compiler!

Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Ignacio Castaño
Thatcher Ulrich wrote:
> > I've uploaded here a first version of the addon here:
> > http://talika.fie.us.es/~titan/lua/
>
> I couldn't wait to start hacking on this... I made some binaries to
> demonstrate the module concept, using my existing luaSDL binding.  You
> can get them here:
>
> http://tulrich.com/geekstuff/files/luaSDL.zip

Hey, that's really nice!

I was going to write a simpler example, but with my exams was not having
enough time to do so. I've seen you have separated the lua vm and the lua
executable to avoid memory allocation conflicts. Is that also necesary on
*nix or only in win32?

> * I had to comment out the part of Ignacio's code which registers some
>   library info in a Lua table -- it was causing crashes on both
>   platforms.  So use()'ing a library more than once may create
>   problems!

I think you are using an old version, I updated it in a short time after the
first release, but accidentally replaced it again with the older version.
Now the right version is up, and I think the problems are gone, please tell
me if I'm wrong.

I'm also going to write a template project to facilitate binding the
libraries with the lua library. Usually libraries are just .lib or .a files,
so the template only has to bind lua dynamically, and to call the
initialization functions of the libraries, that can be specified through
macros. The template would bind the original library, and produce a dynamic
library to use with lua 'use' addon. I think that should facilitate porting
libraries to the new system.


> That .zip includes both Linux and Win32 binaries, and a little sample
> SDL game written in Lua.  I'm including the README from that zip file
> below.

However, the linux binary is missing.


> Thanks for the code Ignacio!

And thanks for the sample!


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 Feb 04, 2002 at 08:59 +0100, Ignacio Castaño wrote:
> Thatcher Ulrich wrote:
> > > I've uploaded here a first version of the addon here:
> > > http://talika.fie.us.es/~titan/lua/
> >
> > I couldn't wait to start hacking on this... I made some binaries to
> > demonstrate the module concept, using my existing luaSDL binding.  You
> > can get them here:
> >
> > http://tulrich.com/geekstuff/files/luaSDL.zip
> 
> Hey, that's really nice!

Thanks!

> I was going to write a simpler example, but with my exams was not having
> enough time to do so. I've seen you have separated the lua vm and the lua
> executable to avoid memory allocation conflicts. Is that also necesary on
> *nix or only in win32?

Not sure -- I started on Linux, and ran into core dumps, and flailed
around trying to fix it, but only later commented out the Lua API
calls to register the library handle.  So possibly it's not necessary?

On Win32, I don't think the issue is memory allocation (as long as you
use the MSVCRT C library, which is thread and DLL aware I think).  The
issue is that DLL's that call the Lua API won't be able to see the Lua
code in the core .exe, but they will see it if it's a DLL.

> > * I had to comment out the part of Ignacio's code which registers some
> >   library info in a Lua table -- it was causing crashes on both
> >   platforms.  So use()'ing a library more than once may create
> >   problems!
> 
> I think you are using an old version, I updated it in a short time after the
> first release, but accidentally replaced it again with the older version.
> Now the right version is up, and I think the problems are gone, please tell
> me if I'm wrong.

I used the old version (I think) on Linux, and the new version on
Win32, and ran into seg faults in both versions.  I didn't dig into
the problem to find out why; I was just trying to get something up
quickly, so it could have been any number of other problems.

> I'm also going to write a template project to facilitate binding the
> libraries with the lua library. Usually libraries are just .lib or .a files,
> so the template only has to bind lua dynamically, and to call the
> initialization functions of the libraries, that can be specified through
> macros. The template would bind the original library, and produce a dynamic
> library to use with lua 'use' addon. I think that should facilitate porting
> libraries to the new system.

Yeah, that sounds good.

> > That .zip includes both Linux and Win32 binaries, and a little sample
> > SDL game written in Lua.  I'm including the README from that zip file
> > below.
> 
> However, the linux binary is missing.

Drat!  I just updated it.

Another observation: the Lua core makefiles are *almost*
nmake-compatible; all they really need is the definition of macros to
change the file extension conventions (use .obj instead of .o, .lib
instead of .a, etc).  One approach to a "more universal" core Lua
distribution would be to add those macros, and then have a
"config.win32" or instructions for Win32 folks, so they could compile
with "nmake".  I guess this could be a PowerPatch.

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

Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Ignacio Castaño
Thatcher Ulrich wrote:
> > I was going to write a simpler example, but with my exams was not having
> > enough time to do so. I've seen you have separated the lua vm and the
lua
> > executable to avoid memory allocation conflicts. Is that also necesary
on
> > *nix or only in win32?
>
> Not sure -- I started on Linux, and ran into core dumps, and flailed
> around trying to fix it, but only later commented out the Lua API
> calls to register the library handle.  So possibly it's not necessary?

hmm... maybe not, I'm testing it on win32 and it works right. I will try to
test it on linux and solaris tomorrow at the university. Note that if you
don't register the library handle, the gc tag method won't be called, and
the library won't be released, producing a resource leak. Anyway, I will
study that code in detail to see if there's something wrong.


> On Win32, I don't think the issue is memory allocation (as long as you
> use the MSVCRT C library, which is thread and DLL aware I think).  The
> issue is that DLL's that call the Lua API won't be able to see the Lua
> code in the core .exe, but they will see it if it's a DLL.

woah, I didn't know that! using MSVCRT solved all the allocation problems
:-)
Anyway the dll approach is still cleaner and does not repeat the code twice.


> Another observation: the Lua core makefiles are *almost*
> nmake-compatible; all they really need is the definition of macros to
> change the file extension conventions (use .obj instead of .o, .lib
> instead of .a, etc).  One approach to a "more universal" core Lua
> distribution would be to add those macros, and then have a
> "config.win32" or instructions for Win32 folks, so they could compile
> with "nmake".  I guess this could be a PowerPatch.

Personaly, I've never used "nmake", but that seems like a good idea.


Ignacio Castaño
[hidden email]



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


123