Lua libraries workshop scheduled for Feb 19

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

Lua libraries workshop scheduled for Feb 19

Norman Ramsey-2
                         One-Day Workshop on
                     Design of Libraries for Lua
                     (with Roberto Ierusalimschy)

                         Tuesday, February 19
                          Harvard University


The design of the embedded programming language Lua (http://www.lua.org)
shows the results of almost ten years' worth of careful thought and
attention from the designers.  The standard library that accompanies
Lua, however, has not received comparable attention.  As users of the
language, we have an interest in improving the library.  We are
therefore holding a (short) one-day workshop to develop suggestions
for improvements in the library.  Backwards compatibility is not a
requirement; we are free to scrap everything and start over if we
want!  (We will stick to the current language definition,
however---only the library is up for grabs.)  We will be fortunate
enough to have with us Roberto Ierusalimschy, one of Lua's chief
designers.

We anticipate working from about 10 to 4, with a short break for
lunch.  This is intended to be a working meeting, not a day of talks
and panels, and we hope to emerge with very concrete, specific
suggestions for the Lua team.  For that reason, enrollment will be
limited to about 20 people.

Please let us know if you would like to participate in this workshop.
Send email to Christian Lindig <[hidden email]> or reply to
this message.  We would like to hear from you by Friday, February 8.



Norman Ramsey

Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries workshop scheduled for Feb 19

Peter Loveday-2
>                          One-Day Workshop on
>                      Design of Libraries for Lua
>                      (with Roberto Ierusalimschy)


While I would love to attend this, unfortunately it would involve
travelling several thousand km to the USA for the day, which I can't
really justify right now. :(

Could I request that any suggestions, designs etc formulated at this
workshop be posted either to the group, or on a website so that those
of us not able to attend can have some input on this important issue
also?

Love, Light and Peace,
- Peter Loveday
eyeon Software



Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries workshop scheduled for Feb 19

Norman Ramsey-2
 > >                          One-Day Workshop on
 > >                      Design of Libraries for Lua
 > >                      (with Roberto Ierusalimschy)
 > 
 > 
 > While I would love to attend this, unfortunately it would involve
 > travelling several thousand km to the USA for the day, which I can't
 > really justify right now. :(

Yes, Roberto suggested posting to lua-l even though the vast majority
of subscribers won't be able to attend.

 > Could I request that any suggestions, designs etc formulated at this
 > workshop be posted either to the group, or on a website so that those
 > of us not able to attend can have some input on this important issue
 > also?

Perhaps the Lua users' Wiki would like to allocate a page for this
workshop, and then we can simply point participants at the page?


Norman

Reply | Threaded
Open this post in threaded view
|

RE: Lua libraries workshop scheduled for Feb 19

Eric Ries
> Perhaps the Lua users' Wiki would like to allocate a page for this
> workshop, and then we can simply point participants at the page?

That would be great, as it would allow lua-l member the opportunity to raise
issues that the workshop could address when they meet.


Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries workshop scheduled for Feb 19

Reuben Thomas
In reply to this post by Norman Ramsey-2
As another non-attender, here are some initial thoughts:

There are two main reasons to write Lua libraries in C: efficiency (mostly
speed, perhaps also memory usage from time to time) or functionality
(accessing existing C functionality that would be impractical or
uneconomic to replicate in Lua).

As far as the standard libraries go, the requirement of pure ANSIness
means that only ANSI C functionality can be provided. I would suggest that
unless there are good efficiency reasons to do otherwise, it's best just
to expose the C API to Lua as directly as possible (as the current
libraries tend to); further layers of abstraction can then be added in
Lua. In other words, there's not a lot wrong with the math, I/O or system
libraries.

The basic and debug libraries are also about adding functionality, but
here in a different way: they primarily reflect the functionality of the
Lua C API back into the language. The same rule as above should apply:
unless there are good (probably efficiency) reasons, they should do no
more than mirror the C API into Lua. This is pretty much what happens at
present.

The string library is different: it does provide functionality, but a
large part of its utility is in its pattern matching, which gives much
better performance than anything that could be written in Lua. Experience
has shown it to be extremely effective; even the omission of alternation,
which might seem a glaring flaw to the regexp enthusiast, is largely
offset by the ability to pass a function argument to gsub for
replacements.

In the light of this, here's what I'd look at:

1. Is it possible to expose more of Lua's internals as libraries?

In particular, it'd be really nice to be able to get at the internals of
the compilation process, e.g. to be able to manipulate code as data
(rather than resorting to string mangling as at present). Similarly, see
my past proposals on the list about being able to plug in a different
regexp engine or (more controversially) garbage collector.

2. What about reimplementing some of the standard libraries in Lua?

Some functions, like assert, could easily be implemented in Lua, and
implementing them in C gives little or no advantage. In addition, there
are functions written in Lua that it is most useful to add pre-loaded to
the interpreter, e.g. require (to 4.0). Having a framework to build Lua
libraries into the executable would be easy (bin2c already does the work)
and useful. Reducing the amount of code written in C would improve
usability and reduce maintenance.

3. What else is needed?

As far as the standard libraries go, this reduces to the small question of
whether there are any missing bits of the ANSI C libraries that can
usefully be exposed to Lua, and the rather bigger question of whether
there are any techniques that, like pattern matching, would both benefit
from a C implementation and be widely used. The only (pure ANSI)
functionality I've ever needed to add has been bitwise logical operations
(my library for this is widely packaged, so others seem to agree).

Finally, an obvious next step if you accept the argument that as little as
possible should be written in C is:

4. What about Lua standard libraries written in Lua?

I'll say only that this is a can of worms worth opening.

-- 
http://sc3d.org/rrt/
L'art des vers est de transformer en beautés les faiblesses (Aragon)



Reply | Threaded
Open this post in threaded view
|

RE: Lua libraries workshop scheduled for Feb 19

Nick Trout-4
In reply to this post by Norman Ramsey-2
>                          One-Day Workshop on
>                      Design of Libraries for Lua

It looks like Norman has been heavily influenced by Lua (the moon). :-)

http://www.eecs.harvard.edu/~nr/

It just goes to prove there is no silver bullet etc etc...


Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries workshop scheduled for Feb 19

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

On Wednesday, January 30, 2002, at 04:37  AM, Reuben Thomas wrote:
1. Is it possible to expose more of Lua's internals as libraries?

In particular, it'd be really nice to be able to get at the internals of
the compilation process, e.g. to be able to manipulate code as data
(rather than resorting to string mangling as at present). Similarly, see
my past proposals on the list about being able to plug in a different
regexp engine or (more controversially) garbage collector.

I'd love to see this.

Also, I think the most important standard library needed is a small one for dealing with file system directories.(getting lists of/attributes of files, etc).

Steve



Reply | Threaded
Open this post in threaded view
|

Re: Lua Libraries workshop scheduled for Feb 19

Ashish Ranjan-2
In reply to this post by Norman Ramsey-2
Hello,
  though i will not be able to go there just for
attending the meeting from india, i will like to say
that following should be taken note in the meeting:

 1. there should be one SMALL standard CORE library,
which is just enough for most of the users need, and
which is in fully ANSI C ( i mean portable ). These
include dealing with file system directories ( as
getting system attributes ) as in java. This core
library along with the interpreter should be
considered with the core standard language.it must be
named as LFL ( Lua Foundation Library ) or LCL ( Lua
core Library ).

*2. MOST IMPORTANT, we should also decide for an
EXTENDED library set. This we can name as LXL ( Lua
Extended Library ) on the pattern of MFC of Visual
C++. Actually u can think of it as analogous to javax
library.
 It will have the classes or functions libraries which
are needed for lua as some more powerful scripting
tool. for example u can put socket functions library
in this LXL. so if one wants to script some networking
code in lua, then he will have to install LXL, and
wherever one wants to run that person's scripts, he
can just install standard LXL. and say, the users who
want to develop their own socket functions will try to
maintain atleast calling parameter and function names
matching. (i am not saying that socket functions are
needed by everyone, i am just giving them for examples
.the actual functions to be put inthere can be decided
by majority's consent.)so there will be some
homogeneity in function names across all the thousand
custom lua ( extended ) interpreter's maintained by
everyone for himself. don't get me wrong, that i am
against everyone's own libraries, infact that is what
which has made lua achieve so much appreciation. what
i want to say that, just collect all the Usually
common functions and classes etc. across all thousands
of these libraries and put them in a standard extended
library, if they can not be put in standard core
library  because of the purpose of keeping lua
standard core library small.


bye :-)
Ashish
Postscript: waiting for the comment from esp. from the
lua language designers, that what's ur stand about
this standard EXTENDED lua library, which will be
apart from the standard CORE lua library.

__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions! 
http://auctions.yahoo.com

Reply | Threaded
Open this post in threaded view
|

Re: Lua Libraries workshop scheduled for Feb 19

Jim Mathies-2
|  1. there should be one SMALL standard CORE library,
| which is just enough for most of the users need, and
| which is in fully ANSI C ( i mean portable ). These
| include dealing with file system directories ( as

Why must we force Lua into the genre of a console 
based scripting language? Or a language tied 
to a conventional filesystem? I really love the fact that Lua
is independent of this method of use. I _really_
love it. The Lua language is the standard, not the 
extension libs. Thier use should be app specific
so people don't 'expect' something other than the 
language's semantics. I really don't like the 'standard
fileio interface'. I wrote a custom version for Yindo 
specific to our product's needs. People might ask, 
"where's 'execute'? where's 'setlocale'" . huh? 
these are not functions of the Lua language.

| These
| include dealing with file system directories ( as
| getting system attributes ) as in Java. 

Some projects don't treat the fileio as a standard 
filesystem... some projects don't have a filesystem. Personally 
I'd prefer the Lua aux fileio lib stay the way it is, 'just
another (optional) interface lib'. Nothing 'standard'
about it.

| *2. MOST IMPORTANT, we should also decide for an
| EXTENDED library set. This we can name as LXL ( Lua

Choosing one extension lib over another - deciding on a 
standard set of libraries. bad idea imho. Create a 
web page listing them all and let people choose what 
they want to compile into Lua based on their use.

2C

Regards,
Jim


----- Original Message ----- 
From: "Ashish Ranjan" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Wednesday, January 30, 2002 11:31 PM
Subject: Re: Lua Libraries workshop scheduled for Feb 19


| Hello,
|   though i will not be able to go there just for
| attending the meeting from india, i will like to say
| that following should be taken note in the meeting:
| 
|  1. there should be one SMALL standard CORE library,
| which is just enough for most of the users need, and
| which is in fully ANSI C ( i mean portable ). These
| include dealing with file system directories ( as
| getting system attributes ) as in java. This core
| library along with the interpreter should be
| considered with the core standard language.it must be
| named as LFL ( Lua Foundation Library ) or LCL ( Lua
| core Library ).
| 
| *2. MOST IMPORTANT, we should also decide for an
| EXTENDED library set. This we can name as LXL ( Lua
| Extended Library ) on the pattern of MFC of Visual
| C++. Actually u can think of it as analogous to javax
| library.
|  It will have the classes or functions libraries which
| are needed for lua as some more powerful scripting
| tool. for example u can put socket functions library
| in this LXL. so if one wants to script some networking
| code in lua, then he will have to install LXL, and
| wherever one wants to run that person's scripts, he
| can just install standard LXL. and say, the users who
| want to develop their own socket functions will try to
| maintain atleast calling parameter and function names
| matching. (i am not saying that socket functions are
| needed by everyone, i am just giving them for examples
| .the actual functions to be put inthere can be decided
| by majority's consent.)so there will be some
| homogeneity in function names across all the thousand
| custom lua ( extended ) interpreter's maintained by
| everyone for himself. don't get me wrong, that i am
| against everyone's own libraries, infact that is what
| which has made lua achieve so much appreciation. what
| i want to say that, just collect all the Usually
| common functions and classes etc. across all thousands
| of these libraries and put them in a standard extended
| library, if they can not be put in standard core
| library  because of the purpose of keeping lua
| standard core library small.
| 
| 
| bye :-)
| Ashish
| Postscript: waiting for the comment from esp. from the
| lua language designers, that what's ur stand about
| this standard EXTENDED lua library, which will be
| apart from the standard CORE lua library.
| 
| __________________________________________________
| Do You Yahoo!?
| Great stuff seeking new owners in Yahoo! Auctions! 
| http://auctions.yahoo.com
| 
| 


Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries workshop scheduled for Feb 19

Reuben Thomas
In reply to this post by Steve Dekorte-4
> Also, I think the most important standard library needed is a small one
> for dealing with file system directories.(getting lists of/attributes of
> files, etc).

But this can't be done with ANSI C. I really wouldn't like to see
ANSI-ness broken in the core Lua dist, though I'd be quite happy to see
this as part of a "standard libraries" project.

-- 
http://sc3d.org/rrt/
Kleineken: refreshes the dimensions other beers cannot reach


Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Everett L.
In reply to this post by Nick Trout-4

I've been observing this discussion of lua libraries and
transportability, static versus dynamic, etc. For lua
libs to be portable both statically, and dynamically, two
things are necessary.

1. Some means of concatenating libraries to the lua executable
   that can be detected by the lua executable, allowing it to
   process and make available to lua programs those concatenated
   libs. This gets around all the linkers and compilers necessary
   for any of the other schemes that I have seen.

2. A specific library concatenatable under option 1 above for each
   platform that lua uses that will allow loadlib to work
   tranparently on that platform. Alternately, this library could
   be linked into the lua base binary for each platform.

Everett L.(Rett) Williams
[hidden email]






Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Markus Huber
> David Jeske wrote:

> 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 was in hope that Lua is an alternative to (cryptical, hard to read)
Perl and (stupid indent based) Python. After one year programming in php
(old bugs, new version with new bugs, incorrect manual, stupid
functions, old code is incompatible to newer versions, ...) I am
searching for an alternative with all the stuff needed for html
based internet applications.

I feel very happy about the language design of Lua (also the impression
of an well formated Lua script). I like it also to write my own
libraries (in Lua - not in C).

> ...
> and at the end we'd have something which was basically like Perl or
> Python with 1/10 of the available modules.

For me the language design itself is a the most important argument. I
don't accept any language for my daily work.

> Anyhow, that's my $0.02.

  Anyhow, that's my $0.02.
  ------------------------
                    $0.00. ;-)


Markus


Reply | Threaded
Open this post in threaded view
|

RE: Lua libraries

Nick Trout-4
In reply to this post by Everett L.
> - 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?)

I think DLLs can be linked statically and dynamically in win32 so you
wouldnt necessarily need a library for the extension DLL to link with but I
dont think you can call from a DLL to the exe as its the DLL that supplies
the functionality for being able to call it dynamically. So you would have
to make the Lua VM a DLL if the extension DLL needed to call it. Since you
cant really assume that all extension DLLs will not contain any Lua code
both should really be DLLs.

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

This is a problem which I am not really familiar with since I am still using
4.0 (waiting for toLua 4.1 and need a static codebase for the game). I can
see your point however. Mmmmm.

But this problem doesnt just affect libraries as DLLs, trying to link static
DLLs would have the same problem. All I can suggest from looking at the
problem briefly is that LUA_USERSTATE is a pointer to the head of a list of
library data structures and each library can attach its own data to the
list. The data cannot be compiled it, it will have to be runtime.

Regards,
Nick


Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Luiz Henrique de Figueiredo
In reply to this post by Everett L.
>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.

Starting in 4.1, lua.c contains a macro LUA_USERINIT that can be redefined
to do whatever initialization is desired.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Lua libraries

Reuben Thomas
> Starting in 4.1, lua.c contains a macro LUA_USERINIT that can be redefined
> to do whatever initialization is desired.

Yes, LUA_USERINIT could be used, but that's just begging the question,
"how"? Given a library implemented in the normal way (a single C file that
provides a function to initialise the library), it'd be nice just to be
able to add the name of the library (or something) to a single file, and
have it built into the Lua executable. At the moment it's easy enough to
add a single library, but tedious for multiple libraries or users with
little experience in using compilers, make &c.

LUA_USERINIT is probably a bad mechanism to use for this, because it's
there for *non-standard* *per-project* extensions; I was suggesting that a
little extra help for easily building libraries in should be part of the
standard build system.

-- 
http://sc3d.org/rrt/ | romantic, n.  one who puts ideas before people


Reply | Threaded
Open this post in threaded view
|

RE: Lua libraries

Nick Trout-4
In reply to this post by Everett L.
> I was 
> suggesting that a
> little extra help for easily building libraries in should be 
> part of the
> standard build system.

What about a Lua script that emulates all the *nix autoconfig stuff and
builds your project? The Lua script could even replace a makefile is you
could get timestamp and file info from somewhere (std libs?). So you choose
your platform and fill in the libs in a "config.lua" file and "lua
make.lua"? You could centralise all of the config stuff into one file and
the script could modify appropriate Defs and header files accordingly for
the build. You could have multiple config.lua files for different projects
and uses. So for a new library, a config.lua patch could be supplied that
would make it integrate with your settings? The problem is that Lua is
beautifully flexible and should remain so.

Regards,
Nick


Reply | Threaded
Open this post in threaded view
|

RE: Lua libraries

Reuben Thomas
> > I was
> > suggesting that a
> > little extra help for easily building libraries in should be
> > part of the
> > standard build system.
>
> What about a Lua script that emulates all the *nix autoconfig stuff and
> builds your project?

Keep it simple! All that's needed is a way of including some extra
function calls into lua.c, and some extra .o files into the liblua. This
could be done with a Lua script (indeed, may well best be done so, to
prevent external dependencies), but at the moment, you don't need to build
Lua to build Lua.

But if, for example, you want to add Lua libraries to Lua itself by
default, this would be necessary anyway, and a two-stage Lua build, where
you first build mini-Lua (standard C libs only) and then can rebuild with
optional extras (using a supplied script) would be attractive.

No need to be autoconfly complex, though. I'm still suggesting something
that can go in the standard distribution with no platform dependencies; my
single goal is to make it simpler to add in optional libraries (something
that people have been complaining about recently, and rightly so).

-- 
http://sc3d.org/rrt/ | maxim, n.  wisdom for fools


Reply | Threaded
Open this post in threaded view
|

RE: Lua libraries

Nick Trout-4
In reply to this post by Everett L.
> but at the moment, you don't 
> need to build
> Lua to build Lua.

But if you want to have multiple lua executables containing different
libraries you're going to have this anyway arent you?

> No need to be autoconfly complex, though. I'm still 
> suggesting something
> that can go in the standard distribution with no platform 
> dependencies; my
> single goal is to make it simpler to add in optional 
> libraries (something
> that people have been complaining about recently, and rightly so).

I dont think its that complex and it could be a complete solution for
integrating libraries, checking versions are compatible, print warnings and
all compilers and platforms could be included. I've looked at autoconf
scripts and they look horrifically complex. I think something like this
could be done pretty simply in Lua.

eg. config.lua:

PLATFORM = "win32"
COMPILER = "msc"
BUILD = "debug"
LIBRS = { 
	{"wxlua","c:/wxluaproject" },		--name and installation
location (for lib config)
	{"sql","c:/databases/libs/sql"}
	}


uses distributed (and constantly updated) config script:

platforms = {
	win32 = { seperator="\" },
	unix = { seperator="/" },
	...
}

compilers = {
	msc = { compile="cl %(flags) %(files)", debugflag="/g",
linker="link32" }
	borland = { compiler="bcc %(flags) %(files)", linker... }
}

and make.lua: (pseudo botch code :-)

lualibsource = { "lua",

compiler = compilers[COMPILER]
for c in lualibsource do
	system( subst_args(compiler, args) )
end

linker... include objects and libs


Well anyway, its seems just as easy to update the above system as it does to
update an FAQ telling people how to build stuff and use different compilers?
Well just an idea. Maybe overly complex.

Nick





	

Reply | Threaded
Open this post in threaded view
|

RE: Lua libraries

Reuben Thomas
> > but at the moment, you don't
> > need to build
> > Lua to build Lua.
>
> But if you want to have multiple lua executables containing different
> libraries you're going to have this anyway arent you?

I was just thinking of the typical scenario: download the source dist plus
libraries you want, add the libraries to some config file, build. (i.e. a
single executable). Doesn't really matter if it builds a vanilla one first
in order to achieve this though.

> I dont think its that complex and it could be a complete solution for
> integrating libraries, checking versions are compatible, print warnings and
> all compilers and platforms could be included.

But this introduces platform dependencies, which the standard distribution
tries to avoid!

> Well anyway, its seems just as easy to update the above system as it does to
> update an FAQ telling people how to build stuff and use different compilers?

This is *not* a job for the standard distribution, though it could easily
become a job for an enhanced dist., with enhanced libs &c.

-- 
http://sc3d.org/rrt/ | impatience, n.  the urge to do nothing


Reply | Threaded
Open this post in threaded view
|

RE: Lua libraries

Nick Trout-4
In reply to this post by Everett L.
> Doesn't really matter if it builds a 
> vanilla one first

I assume you mean the most basic. Must be a term used by proper programmers
or big ice cream fans :-)

> But this introduces platform dependencies, which the standard 
> distribution
> tries to avoid!

The make system is platform dependent. Try nmake (MS make) on makefile in
Lua. I dont know if the make specification supposed to be standard? And all
the paths etc are for *nix.

> This is *not* a job for the standard distribution, though it 
> could easily
> become a job for an enhanced dist., with enhanced libs &c.

Probably not as it would need updating regularly to incorporate fixes etc.

Nick


123