|
|
12
|
|
A new snapshot of Lua 4.1 (work) is now available at
http://www.tecgraf.puc-rio.br/lua/work/lua-4.1-work4.tar.gz
This version contains several changes mentioned in the list: core co-routines
(aka, the yield patch), dynamic stacks, new generalized "for" statement
("for k,v in f do .. end" calls to return k and v if f is a function),
simplified syntax for table constructors (you can freely mix items in the
"list part" with item in the "table part", as in {1,x=10,2,y=20}; ';' are gone,
but still accepted for compatibility), eventtable has been renamed metatable,
lua.c supports incomplete statements, and probably more that I forget now ;-)
The manual has been partially updated is available at
http://www.tecgraf.puc-rio.br/lua/work/refman-4.1-work4.pdf
http://www.tecgraf.puc-rio.br/lua/work/refman-4.1-work4.ps.gz
It does not mention co-routines yet but it does describe the new for and
the new syntax for table constructors.
Of course, none of these changes is definitive. This is simply a work version
that is being made available so that you can experiment with it and send us
your feedback.
Enjoy.
--lhf
|
|
|
lhf wrote:
new generalized "for" statement
("for k,v in f do .. end" calls to return k and v if f is a function)
Hmmm I had just added that to my warts list, which is almost exhausted.
Lua used to be easy to pick on, but now it's getting more challenging.
I'm about ready to give up :-).
|
|
|
In reply to this post by Luiz Henrique de Figueiredo
> This version contains several changes mentioned in the list: core
co-routines
> (aka, the yield patch), dynamic stacks, new generalized "for" statement
> ("for k,v in f do .. end" calls to return k and v if f is a function),
Ooooh, this is so *almost* what I want. Can't we please, please have a next
tagmethod to go with it? It would be soooo simple... (Yes, I know I can
write for k, v in metatable(object).next do ..., but that means that I need
to either write that always or know whether or not object is a regular
table; that is not good for code maintainability.)
> simplified syntax for table constructors (you can freely mix items in the
> "list part" with item in the "table part", as in {1,x=10,2,y=20}; ';' are
gone,
> but still accepted for compatibility), eventtable has been renamed
metatable,
> lua.c supports incomplete statements, and probably more that I forget now
;-)
Also very cool! Thanks, guys.
Rici
|
|
|
On Friday, February 15, 2002, at 07:34 AM, [hidden email] wrote:
Ooooh, this is so *almost* what I want. Can't we please, please have a
next
tagmethod to go with it? It would be soooo simple... (Yes, I know I can
write for k, v in metatable(object).next do ..., but that means that I
need
to either write that always or know whether or not object is a regular
table; that is not good for code maintainability.)
A getn() tagmethod would be really nice too. Basically, it would be nice
to have userdata capable of replacing any value in Lua(particularly a
table value). This way userdata for a database (like tdbm) can replace
a table or a userdata that handles arbitrary length numbers could
replace a number, etc.
Steve
|
|
|
Steve,
If you like, it's easy enough to modify Lua to allow a getn tag
method. Here's a Lua implementation:
_getn = getn -- Save old getn function
getn = function(obj)
local mt = metatable(obj)
if mt~=nil then
local f=mt.getn
if f~=nil then
return f(obj)
end
end
return _getn(obj)
end
(Note that the above can be made shorter by using the "or" idiom.)
Now you can use it just like there was a built-in "getn" tag:
MyMetaTable = {}
MyMetaTable.get = function(obj) return 1 end -- always n=1
t = {}
print(getn(t)) -- prints 0
metatable(t,MyMetaTable)
print(getn(t)) -- prints 1
Note that this works fine with userdata too, since the modified
getn function does not check to make sure its argument is a
table.
A C implementation would be faster of course.
Hope that helps.
- Tom Wrensch
On Fri, 15 Feb 2002, Steve Dekorte wrote:
>
> On Friday, February 15, 2002, at 07:34 AM, [hidden email] wrote:
> > Ooooh, this is so *almost* what I want. Can't we please, please have a
> > next
> > tagmethod to go with it? It would be soooo simple... (Yes, I know I can
> > write for k, v in metatable(object).next do ..., but that means that I
> > need
> > to either write that always or know whether or not object is a regular
> > table; that is not good for code maintainability.)
>
> A getn() tagmethod would be really nice too. Basically, it would be nice
> to have userdata capable of replacing any value in Lua(particularly a
> table value). This way userdata for a database (like tdbm) can replace
> a table or a userdata that handles arbitrary length numbers could
> replace a number, etc.
>
> Steve
>
>
>
|
|
|
On Saturday, February 16, 2002, at 03:50 PM, Tom Wrensch wrote:
If you like, it's easy enough to modify Lua to allow a getn tag
method. Here's a Lua implementation:
Thanks, this is a good idea and I considered it. Unfortunately there's a
problem when it come to sharing. For example, if I implemented a getn()
as above for the tdbm binding and someone else implemented their own
getn() for another binding and you tried to use both libs at the same
time, one would over write the other, breaking it. Likewise with next().
Steve
|
|
|
In reply to this post by Luiz Henrique de Figueiredo
The Lua 4.1 (work4) source distribution fails to use conventions for
makefiles and configuration used by the open source community. Please
embrace this community by using autoconf to generate your config
script, and create a makefile than follows the usual conventions for
the all, clean, install, and uninstall targets. Make it so that the
INSTALL document is nothing other than the file included by all
applications that follow the conventions. Please make it easy to
install your program.
> http://www.tecgraf.puc-rio.br/lua/work/refman-4.1-work4.pdf
This document cannot be displayed xpdf on RedHat Linux 7.1 due to the
use of Type 3 fonts.
John
--
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
|
|
|
On Mon, Feb 18, 2002 at 07:45:45AM -0500, John D. Ramsdell wrote:
> The Lua 4.1 (work4) source distribution fails to use conventions for
> makefiles and configuration used by the open source community. Please
> embrace this community by using autoconf to generate your config
> script, and create a makefile than follows the usual conventions for
> the all, clean, install, and uninstall targets. Make it so that the
> INSTALL document is nothing other than the file included by all
> applications that follow the conventions. Please make it easy to
> install your program.
Unfortunately the "Open Source Community" fails to accept that sometimes
people just plain don't like autoconf etc.
For example: I was able to automatically build lua (with the makefile
supplied, almost unchanged) on several architectures which are not UNIXes
Perhaps you would like to explain to us how autoconf helps portability to
these platforms.
Autoconf is designed to help programs cope with portability between slightly
posix systems -- since Lua is entirely ANSI C -- this kinda becomes
irrelevant.
Altering the makefiles to provide all, clean, install and uninstall targets
might be worthwhile, but in the end anyone who wants to use Lua will use it
in whatever way they see fit.
For most people, Lua will be installed via a package manager if they are
unable to cope with downloading it and installing it themselves.
Try looking at some of the reasons for why Lua chose simple Makefiles before
jumping into an attack on those choices.
Lua /is/ easy to install, perhaps not for people who don't know what they're
doing when they install software which isn't pre-packaged, but then again,
is that such a bad thing?
Regards,
Daniel Silverstone -- Packager in charge of Debian GNU/Linux Lua packages
--
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
Always leave room to add an explanation if it doesn't work out.
|
|
|
----- Original Message -----
> > The Lua 4.1 (work4) source distribution fails to use conventions for
> > makefiles and configuration used by the open source community. Please
Hmm... So the "Open source community" is just Unix/Posix ? I dont think so
...
But the main problem is still, that Lua is two different things to different
people. We have the script guys who just want to download/install/use, and
then we have the embedded people (including my self) who embeds Lua into all
sort of different thing and we dont care about makefiles cause we need it to
be part of our own build system, so we are most more interested in keeping
Lua 100% ANSI-C without tons of preprocessor defines that would collide with
the application that we embed Lua into.
I still think that Lua should be splitted up into two things, a library and
a script engine. And maybe the script engine should be maintained outside
tecgraf. Remember that the current LUA.C started out as a example of a lua
application.
/Erik
|
|
|
Daniel Silverstone <[hidden email]> writes:
> Lua /is/ easy to install, perhaps not for people who don't know what they're
> doing when they install software which isn't pre-packaged, but then again,
> is that such a bad thing?
This is false. Lua is not easy to install. For autoconfig'ed
systems, one simply types:
$ ./configure
$ make
$ make install
There are no instructions to read, and the process can be automated.
This is what it means for software to be easily installed.
The current Lua install method requires that one edit it's makefile.
The makefile has it's own conventions that are different from every
other package. It's a waste of time to ask programmers to go through
this process.
Autoconf solved this problem a long time ago. It's well tested
software that is accepted by the community. There is a reason so many
people use it.
John
|
|
|
[hidden email] (Erik Hougaard) writes:
> But the main problem is still, that Lua is two different things to different
> people. We have the script guys who just want to download/install/use, and
> then we have the embedded people (including my self) who embeds Lua into all
> sort of different thing and we dont care about makefiles cause we need it to
> be part of our own build system, so we are most more interested in keeping
> Lua 100% ANSI-C without tons of preprocessor defines that would collide with
> the application that we embed Lua into.
For embedded people, shouldn't it be possible that a Lua header file
and a shared library are placed in some appropriate public places.
Embedded usages of Lua compile source files using the interface
declared by the public header file, and then link in the shared
library at runtime. In this model, the script engine is just another
consumer of the shared library. It is compiled by including the
public header file, and it links to the shared library at run time.
It's no different than any other embedded user of the library.
In any event, the use of autoconf could be easily used to create this
setup. Building and installing shared libaries is well supported.
There should be no conflict between embedded and scripting Lua users.
Embedded poeple should be able to use Lua as a shared library if that
best suits their needs. Or they may simply want to copy the sources
into there source tree. Whatever works...
John
|
|
|
In reply to this post by Luiz Henrique de Figueiredo
>This is false. Lua is not easy to install. For autoconfig'ed
>systems, one simply types:
>
>$ ./configure
>$ make
>$ make install
In Lua, in a Unix system that has gcc, you simply type "make install"!
>The current Lua install method requires that one edit it's makefile.
Only if you want to do something other than the default. And it's a config file,
not the Makefile. As far as I can tell, the Makefile is pretty standard.
If not, I welcome suggestion on making the Makefiles more standard and portable.
Lua is 100% ANSI C. You only need an ANSI C compiler to build it.
There's no need for Autoconf because it does not depend on the OS.
--lhf
|
|
|
(Answering via groups.yahoo.com, since I seems to miss the latest
messages. Mmm, it is just slow, I received Daniel's response to the
original message of John before the first message of this thread...)
--- In lua-l@y..., ramsdell@l... (John D. Ramsdell) wrote:
> Daniel Silverstone <dsilvers@d...> writes:
>
> > Lua /is/ easy to install, perhaps not for people who don't know
what they're
> > doing when they install software which isn't pre-packaged, but
then again,
> > is that such a bad thing?
>
> This is false. Lua is not easy to install. For autoconfig'ed
> systems, one simply types:
>
> $ ./configure
> $ make
> $ make install
>
> There are no instructions to read, and the process can be automated.
> This is what it means for software to be easily installed.
As you say: "For autoconfig'ed systems". I am no specialist, but I
think that for systems that doesn't have /bin/sh (Windows, perhaps
others like BeOS or MacOS), it doesn't work.
And from what I see in the libraries I downloaded (eg. cURL,
ImageMagick, PCRE), configure files sum up to hundred of KBs! For
ImageMagick, configure file alone = 420KB! That's quite big for such
a result.
> The current Lua install method requires that one edit it's makefile.
> The makefile has it's own conventions that are different from every
> other package. It's a waste of time to ask programmers to go
through
> this process.
>
> Autoconf solved this problem a long time ago. It's well tested
> software that is accepted by the community. There is a reason so
many
> people use it.
>
> John
Well, the makefile of Lua is quite stable, so why don't you create
and distribute separately an autoconf package for Lua? It makes a
double download, but at least it won't bloat the official
distribution for those which don't need/cannot use these files.
Regards.
|
|
|
On Mon, Feb 18, 2002 at 08:39:26AM -0500, John D. Ramsdell wrote:
> Daniel Silverstone <[hidden email]> writes:
>
> > Lua /is/ easy to install, perhaps not for people who don't know what they're
> > doing when they install software which isn't pre-packaged, but then again,
> > is that such a bad thing?
>
> This is false. Lua is not easy to install. For autoconfig'ed
> systems, one simply types:
>
> $ ./configure
> $ make
> $ make install
autoconf makes things easier to install on Unix based systems only.
autoconf becomes a complete pain the *instant* you want to do anything with
an application under something that isn't supported by autoconf. For
example, success with Windows and RISC OS is extremly limited.
<snip>
> The current Lua install method requires that one edit it's makefile.
> The makefile has it's own conventions that are different from every
> other package. It's a waste of time to ask programmers to go through
> this process.
Considering lua is written in 100% ANSI C, asking programmers to fudge
around the uglyness that autoconf involves to run it on something other than
a Unix (such as Windows, RISC OS, embedded OSes) is far more work that
tweaking a Makefile.
> Autoconf solved this problem a long time ago. It's well tested
> software that is accepted by the community. There is a reason so many
> people use it.
I'm yet to see any problem solved by autoconf other than making it slightly
easier for people to compile programs on a Unix or similar OS. It doesn't
aid the majority of users in this world from compiling or installing it at
all, in fact it hinders it. One of the reasons I fell in love with Lua so
quickly is that you don't have to faff around with autoconf.
(autoconf also has lots of small problems even working on real Unices, such
as RISC iX, for the simple reason that the OS' name has a space in it...)
--
Rob Kendrick - http://www.digital-scurf.org/
You will hear good news from one you thought unfriendly to you.
|
|
|
Quoting John D. Ramsdell ([hidden email]):
> Daniel Silverstone <[hidden email]> writes:
>
> > Lua /is/ easy to install, perhaps not for people who don't know what they're
> > doing when they install software which isn't pre-packaged, but then again,
> > is that such a bad thing?
>
> This is false. Lua is not easy to install. For autoconfig'ed
> systems, one simply types:
>
> $ ./configure
> $ make
> $ make install
>
> There are no instructions to read, and the process can be automated.
> This is what it means for software to be easily installed.
>
> The current Lua install method requires that one edit it's makefile.
> The makefile has it's own conventions that are different from every
> other package. It's a waste of time to ask programmers to go through
> this process.
>
> Autoconf solved this problem a long time ago. It's well tested
> software that is accepted by the community. There is a reason so many
> people use it.
The reason so many use it, is that so many use it :) It doesn't mean its good.
Actually, most people I talk to think its total crap system to support alot
of broken unix'es, but they still use it since its "standard".
- Kenneth
|
|
|
In reply to this post by Luiz Henrique de Figueiredo
Could I suggest that you reconsider your approach here
to be less confrontational. As a number of people have
(politely) pointed out there are a number of good
reasons why the build/install system is setup as it is
- most people seem happy with this (or the packaged
alternatives for most major OSs).
As has been stated autoconf is by no means a panacea
given the non-UNIX usage of Lua (and ignoring the fact
that even on UNIX autoconf is a braindead nightmare).
Continuing to demand that Lua be changed to suit your
preferences seems rude and ungrateful - particularly
as nobody is forcing you to use Lua or has any stake
in you doing so.
If you want to create an autoconf script for your own
use and make this available I am sure that nobody
would object however.
DS
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
|
|
|
In reply to this post by Luiz Henrique de Figueiredo
On Monday, February 18, 2002, at 09:26 AM, Luiz Henrique de Figueiredo
wrote:
[moved to top]
> Lua is 100% ANSI C. You only need an ANSI C compiler to build it.
> There's no need for Autoconf because it does not depend on the OS.
Lua is not 100% ANSI C. It's configurable to build that way, but the
use of popen and the support for readline allow minor extensions at the
cost of being 99.44% ANSI C. :-) But the 100% ANSI option is the
default, and I agree with it.
Also, autoconf is not just about discovering the runtime environment
(which is 99.44% ANSI in Lua's case.) autoconf is also about
discovering the build-time environment---what compiler should I use,
what arguments do I need to use to link in the libraries for this
function, and so on.
That being said, I think the "read, understand, edit-by-hand" config
file should not go away. There are enough non-POSIX build systems out
there that "autoconf or die" is a silly idea. Yes, I use cygwin, but
sometimes I use Visual C++ too, and autoconf won't help me at all there.
fltk is an example of a package that supports both configuration styles;
autoconf for systems that support it, hand-edit for those that don't.
This is false. Lua is not easy to install. For autoconfig'ed
systems, one simply types:
$ ./configure
$ make
$ make install
In Lua, in a Unix system that has gcc, you simply type "make install"!
The current Lua install method requires that one edit it's makefile.
Only if you want to do something other than the default. And it's a
config file,
not the Makefile. As far as I can tell, the Makefile is pretty standard.
If not, I welcome suggestion on making the Makefiles more standard and
portable.
The Makefile looks good; it moves its configuration options to config,
which is a good practice, but it's still part of the configuration.
Lemme enumerate what config does. I'll flag those that autoconf would
assist with.
Chooses number format. Not something people do lightly.
Chooses whether to build popen into liblualib. (Incidentally, popen is
defined in -D_POSIX_C_SOURCE=2, so if you want full warningless
compiles, you should set that instead of _POSIX_SOURCE if you have popen
on. But it's only one function prototype.) [autoconf would detect
popen, and could try flags to get the prototype.]
Sets compiler explicitly. Is there a good reason not to use make's
builtin CC definition? [autoconf picks up the CC definition from either
the environment or the site config.]
...oh, and sets warning options, which are compiler dependent. So if
you didn't need compiler-dependent warnings you could avoid setting CC.
[autoconf would allow supplying the proper options to CC if CC is known,
otherwise falling back on the empty string.]
Sets optimization options. In theory, compiler-dependent, but most
every compiler supports -O2. [Again, autoconf can probe for the
availability of particular optimization options.]
Sets LDFLAGS.
Sets _POSIX_SOURCE. Note that this has two functions. First, it tells
the system to provide function prototypes defined by POSIX (above what
you get with ANSI); second, it turns on an internal prototype in lua.c.
[Slam dunk for autoconf.]
Lists libraries needed to link lua.c and luac.c. [autoconf can determine
what libraries are needed to get a successful link given a list of
functions.]
Allows configuration of readline support in lua.c. Defines what
libraries need to be linked in that case. [Obvious use of autoconf; if
the user asks for this with --enable-readline, autoconf can detect
whether readline is actually available and what libraries need to be
linked.
Defines AR, RANLIB, and STRIP. [autoconf does this for you as well.]
Defines multiple variables to control installation destination. (Note
that for man pages, /share/man is more correct on many systems than
/man.) [autoconf has excellent support for configuring installation.]
Sets the tool used to install data and binaries. [Most people use
autoconf's "look for BSD install, fall back to cp" rules.]
autoconf makes the life of people doing cross compiles much easier, as
well as those who have standard configuration options site-wide.
Jay
|
|
|
In reply to this post by Luiz Henrique de Figueiredo
My request to employ autoconf in Lua was simply just that, a request.
I am hoping that the lua developers will embrace accepted open source
practice. It sounds like the answer is no, but before I drop the
issue, please let me add just one more point to the discussion.
Luiz Henrique de Figueiredo <[hidden email]> writes:
> In Lua, in a Unix system that has gcc, you simply type "make install"!
>
> >The current Lua install method requires that one edit it's makefile.
>
> Only if you want to do something other than the default. And it's a
> config file, not the Makefile. As far as I can tell, the Makefile is
> pretty standard. If not, I welcome suggestion on making the
> Makefiles more standard and portable.
The point of using autoconf is that it can be used to automatically
generate the content of the config file. There is no need to ask that
humans edit the config file. Let autoconf probe the environment and
then write the config file.
> Lua is 100% ANSI C. You only need an ANSI C compiler to build it.
> There's no need for Autoconf because it does not depend on the OS.
Just because Lua is 100% ANSI C does not imply its build process is
does not depend on the OS. This is the reason you have a config file.
John
|
|
|
> > Lua is 100% ANSI C. You only need an ANSI C compiler to build it.
> > There's no need for Autoconf because it does not depend on the OS.
>
> Just because Lua is 100% ANSI C does not imply its build process is
> does not depend on the OS. This is the reason you have a config file.
To be precise, it depends on the environment (build tools &c.), not so
much the OS (the one or two non-ANSI functions).
The fact that it's very nearly 100% ANSI does mean that one should look
with suspicion on using a definitely non-portable tool like autoconf (make
is not much better, admittedly).
To my mind, an autoconf script is something that should go in a "Lua
distribution" of the sort I've been discussing recently, rather than
vanilla Lua.
Talking about "embracing open source standards" is missing the point: it's
open source, they're giving it away, they can do what they like. Not using
autoconf does not make the Lua team even quixotic, let alone bad. Other
programs with similar goals don't use autoconf, e.g. bzip2, which
nonetheless is widely used in open source-based systems.
--
http://sc3d.org/rrt/ | competent, a. underpromoted
|
|
|
Steve,
A very good point. If that's a problem (and it will be for many
people) then maybe this is something that could be moved to the "standard
user library" that seems to be slowly being developed. That would provide
a reasonable level of standardization for handling new "tags" implemented
this way, allowing the Lua masters time to decide which tags are most
appropriate to move into the language.
- Tom Wrensch
On Sat, 16 Feb 2002, Steve Dekorte wrote:
>
> On Saturday, February 16, 2002, at 03:50 PM, Tom Wrensch wrote:
> > If you like, it's easy enough to modify Lua to allow a getn tag
> > method. Here's a Lua implementation:
>
> Thanks, this is a good idea and I considered it. Unfortunately there's a
> problem when it come to sharing. For example, if I implemented a getn()
> as above for the tdbm binding and someone else implemented their own
> getn() for another binding and you tried to use both libs at the same
> time, one would over write the other, breaking it. Likewise with next().
>
> Steve
>
>
>
|
12
|
Locked
