[ANNOUNCE] Lua 5.0 (beta) now available

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

[ANNOUNCE] Lua 5.0 (beta) now available

Luiz Henrique de Figueiredo
Lua 5.0 (beta) is now available for downloading at
	http://www.lua.org/ftp/lua-5.0-beta.tar.gz
	ftp://ftp.lua.org/lua-5.0-beta.tar.gz
The mirror sites will be updated automatically by their own robots soon.

For the record, Lua is freely available for both academic and commercial
purposes under the terms of the MIT license: http://www.lua.org/license.html .

Note that this is an *beta* release, not a work or alpha release. This means
that Lua 5.0 final is expected to be *identical* to it, unless serious flaws
are found. You can start porting your programs now; no incompatibilities are
expected to be introduced in Lua 5.0 final.

The tarball contains complete documentation in HTML, including an updated
reference manual. Printable versions of the manual are available at
	http://www.lua.org/ftp/refman-5.0-beta.ps.gz
	http://www.lua.org/ftp/refman-5.0-beta.pdf
and soon at the mirror sites.

Here is a brief summary of the changes (see HISTORY for a complete list):
  + lexical scoping.
  + Lua coroutines and support for external multithreading and coroutines.
  + standard libraries now packaged in tables.
  + tags replaced by metatables and tag methods replaced by metamethods.
  + each function can have its own global table, which can be shared.
  + new boolean type.
  + introduced lightweight userdata.
  + proper tail calls.
  + new, faster, register-based virtual machine.
  + support to user extensions in lua.c.
  + safe garbage-collector metamethods.
  + new error handling protocol.
  and much more...

Please report any problems to [hidden email].

If all goes well, we expect to release Lua 5.0 (final) by the end of January.

Enjoy.
--lhf

Reply | Threaded
Open this post in threaded view
|

RE: [ANNOUNCE] Lua 5.0 (beta) now available

Joshua Jensen
> Lua 5.0 (beta) is now available for downloading at

My first critique of this codebase is pretty simple.  Why would you want
to decrease the readability of the code, particularly the public API, by
using cryptic identifiers such as:

sz (size)
lvl (level)
tp (type... I thought it was top)
idx (index)

And I'm sure there are more I haven't discovered yet.

?

Josh


Reply | Threaded
Open this post in threaded view
|

RE: [ANNOUNCE] Lua 5.0 (beta) now available

Joshua Jensen
In reply to this post by Luiz Henrique de Figueiredo
> > Lua 5.0 (beta) is now available for downloading at
> 
> My first critique of this codebase is pretty simple.  Why 
> would you want to decrease the readability of the code, 
> particularly the public API, by using cryptic identifiers such as:
> 
> sz (size)
> lvl (level)
> tp (type... I thought it was top)
> idx (index)

And a couple more... all of these are just in lua.h:

dt (data)
l (len)

-Josh


Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 5.0 (beta) now available

Roberto Ierusalimschy
> Why would you want to decrease the readability of the code,
> particularly the public API, by using cryptic identifiers

Because, unfortunately, several compilers use those common names (such
as "size", "level", "index") for different purposes in their own include
files, and those uses generate warnings (and sometimes errors) when
mixed with lua.h.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

RE: [ANNOUNCE] Lua 5.0 (beta) now available

Joshua Jensen
> > Why would you want to decrease the readability of the code, 
> > particularly the public API, by using cryptic identifiers
> 
> Because, unfortunately, several compilers use those common 
> names (such as "size", "level", "index") for different 
> purposes in their own include files, and those uses generate 
> warnings (and sometimes errors) when mixed with lua.h.

That makes sense.  I should have thought of that.

Josh


Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 5.0 (beta) now available

Peter Loveday-2
In reply to this post by Luiz Henrique de Figueiredo
Excellent!

Is there a list of changes from 5.0 alpha to 5.0 beta?  Or are they only
bugfixes?

Thanks!

- Peter Loveday


Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 5.0 (beta) now available

Roberto Ierusalimschy
> Is there a list of changes from 5.0 alpha to 5.0 beta?  Or are they only
> bugfixes?

See http://lua-users.org/lists/lua-l/2002-11/msg00152.html  and
    http://lua-users.org/lists/lua-l/2002-11/msg00153.html

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 5.0 (beta) now available

Russell Y. Webb
In reply to this post by Joshua Jensen
Still some would argue for even more verbose naming in public APIs:

lua_size
lua_level
lua_type
lua_index

Not that it's worth a discussion. The Lua authors should be free to use any coding style they wish. I'm just happy that Lua 5 is making progress --- Thanks!

Russ

On Tuesday, December 17, 2002, at 10:38 AM, Joshua Jensen wrote:

Why would you want to decrease the readability of the code,
particularly the public API, by using cryptic identifiers

Because, unfortunately, several compilers use those common
names (such as "size", "level", "index") for different
purposes in their own include files, and those uses generate
warnings (and sometimes errors) when mixed with lua.h.

That makes sense.  I should have thought of that.

Josh



Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 5.0 (beta) now available

Adam D. Moss
In reply to this post by Luiz Henrique de Figueiredo
Luiz Henrique de Figueiredo wrote:
> Lua 5.0 (beta) is now available for downloading at
>         http://www.lua.org/ftp/lua-5.0-beta.tar.gz

Excellent, I just upgraded from 5.0-alpha and the transition
was fairly smooth.

The renaming of luaL_check_* to luaL_check* tripped me a little
as did the new parameter to (the undocumented) luaL_openlib but
these were no-brainers really.  Same with lua's setmode() going
away (easily implemented in a compatability function if need be,
but I thought I may as well just change the source).

For footprint-watchers, here's 5.0-alpha's on-disk footprint:
(gcc31 -Os, stripped)

-rw-r--r--   1 root        50112 Dec 17 19:27 liblua.a
-rw-r--r--   1 root        28640 Dec 17 19:27 liblualib.a

... and here's 5.0-beta's:
(gcc31 -Os, stripped)

-rw-r--r--   1 root        51848 Dec 17 19:27 liblua.a
-rw-r--r--   1 root        30624 Dec 17 19:27 liblualib.a

Thanks to the lua maintainers for their hard work.

--Adam
-- 
Adam D. Moss   . ,,^^   [hidden email]   http://www.foxbox.org/   co:3

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 5.0 (beta) now available

Jay Carlson
On Tue, 17 Dec 2002, Adam D. Moss wrote:

> For footprint-watchers, here's 5.0-alpha's on-disk footprint:
> (gcc31 -Os, stripped)
>
> -rw-r--r--   1 root        50112 Dec 17 19:27 liblua.a
> -rw-r--r--   1 root        28640 Dec 17 19:27 liblualib.a
>
> ... and here's 5.0-beta's:
> (gcc31 -Os, stripped)
>
> -rw-r--r--   1 root        51848 Dec 17 19:27 liblua.a
> -rw-r--r--   1 root        30624 Dec 17 19:27 liblualib.a

The best way to measure code size of libraries is with partial
linking:

$ ld -r -o /tmp/liblua4.0-partial --whole-archive liblua.a
etc

On Debian/SPARC 3.0, (gcc-2.95.4, default flags plus popen)

nop@slothrop:~$ size /tmp/libl*
   text    data     bss     dec     hex filename
  52464       0       0   52464    ccf0 /tmp/liblua4.0-partial
  62080       0       0   62080    f280 /tmp/liblua5.0-partial
  28192       0       2   28194    6e22 /tmp/liblualib4.0-partial
  37348       0       0   37348    91e4 /tmp/liblualib5.0-partial

Just for laughs:

 458620   27064    1184  486868   76dd4 /tmp/libtcl8.3-partial

Jay


Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 5.0 (beta) now available

Luiz Henrique de Figueiredo
In reply to this post by Luiz Henrique de Figueiredo
>I'm just happy that Lua 5 is making progress

So are we. And like I said in the announcement, Lua 5.0 is very close to
becoming the official Lua version; this should happen by the end of January,
if everything goes well.
--lhf

Reply | Threaded
Open this post in threaded view
|

RE: [ANNOUNCE] Lua 5.0 (beta) now available

Benoit Germain
In reply to this post by Luiz Henrique de Figueiredo
My use of coroutines and debugger makes necessary to obtain the lua_State
associated to a coroutine. The first option is to create a thread by hand,
but since what I want to do is reproduce the behaviour of what is obtained
with coroutine.wrap(), I would need to duplicate several pieces of code
found in lbaselib.c because these are static.
Another solution, much more straightforward, would be that LUA had something
equivalent to lua_pushupvalues() in its API, but instead of reading the
upvalues of the current call frame, being able to get the upvalues of a
cclosure at a given stack index.

Because I am a good person, here it is :-)

LUA_API int lua_getupvalues (lua_State *L, int index) {
  Closure *func;
  int n, i;
  StkId t;
  lua_lock(L);
  t = luaA_index(L, index);
  api_check(L, iscfunction(t));
	func = clvalue(t);
  n = func->c.nupvalues;
  luaD_checkstack(L, n + LUA_MINSTACK);
  for (i=0; i<n; i++) {
    setobj2s(L->top, &func->c.upvalue[i]);
    L->top++;
  }
  lua_unlock(L);
  return n;
}


maybe for 5.0 final ?

please please please :-)

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 5.0 (beta) now available

Roberto Ierusalimschy
> Another solution, much more straightforward, would be that LUA had
> something equivalent to lua_pushupvalues() in its API, but instead of
> reading the upvalues of the current call frame, being able to get the
> upvalues of a cclosure at a given stack index.

Lua 5.0 final will have functions to manipulate upvalues, as part of its
debug API:

LUA_API const char *lua_getupvalue (lua_State *L, int funcindex, int n);
LUA_API const char *lua_setupvalue (lua_State *L, int funcindex, int n);

Both operate on the function `funcindex' (which may be a Lua function or
a C function). lua_getupvalue pushes the upvalue, lua_setupvalue pops
a value and updates the upvalue. Both return the name of the upvalue (for
Lua functions), "" for C functions, and NULL if the function does not
have a n-th upvalue.

-- Roberto


Reply | Threaded
Open this post in threaded view
|

RE: [ANNOUNCE] Lua 5.0 (beta) now available

Ignacio Castaño
In reply to this post by Benoit Germain
Benoit Germain wrote: 
> Another solution, much more straightforward, would be that LUA had
> something
> equivalent to lua_pushupvalues() in its API, but instead of reading the
> upvalues of the current call frame, being able to get the upvalues of a
> cclosure at a given stack index.

Some time ago I posted:

LUA_API void lua_getupvalue (lua_State *L, int index, int upvalue) {
  StkId o;
  lua_lock(L);
  o = luaA_indexAcceptable(L, index);
  if( o==NULL || !iscfunction(o) )
    setnilvalue(L->top);
  else {
    Closure *cl = clvalue(o);
    if( upvalue<0 || upvalue >= cl->c.nupvalues )
      setnilvalue(L->top);
 else
      setobj(L->top, &cl->c.upvalue[upvalue]);
  }
  api_incr_top(L);
  lua_unlock(L);
}


Ignacio Castaño
[hidden email]


___________________________________________________
Yahoo! Sorteos
Consulta si tu número ha sido premiado en
Yahoo! Sorteos http://loteria.yahoo.es

Reply | Threaded
Open this post in threaded view
|

RE: [ANNOUNCE] Lua 5.0 (beta) now available

Benoit Germain
In reply to this post by Luiz Henrique de Figueiredo
I just noticed that after a lua_open(), two fields remain uninitialized:
L->next and L->gclist. With allocators that fill memory with some non-zero
mark, this could cause problems.


Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCE] Lua 5.0 (beta) now available

Roberto Ierusalimschy
> I just noticed that after a lua_open(), two fields remain uninitialized:
> L->next and L->gclist. With allocators that fill memory with some non-zero
> mark, this could cause problems.

These fields are not used in the main thread (the one created by
lua_open), so there is no problem at all. (The testbed for Lua uses an
allocator that fills memory with non-zero marks. valgrind, another tool
we use to test Lua, warns if we try to use uninitialized values.) But we
will initialize them to avoid enventual warnings in other tools.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Lua5(beta) luaL_openlib

Eero Pajarre-3
In reply to this post by Luiz Henrique de Figueiredo
My thanks to the Lua team for this version, and for Lua in general.

And then to the bug (?) report ;-)

luaL_openlib seems to leave one item to the stack (the table
containing the library), and functions like lua_baselibopen,
lua_mathlibopen and lua_tablibopen leave the table
on stack. I think this did not happen with Lua5(alpha)?
I noticed this when my stack started to fill suspiciously.

An other thing I noticed while checking this:
The 5(alpha) did completely regenerate the table of the library
in loadlib, but 5(beta) reuses the table, and just
adds items to it. In some sense I find the alpha behaviour
cleaner.


		best regards,

			Eero






Reply | Threaded
Open this post in threaded view
|

Re: Lua5(beta) luaL_openlib

Luiz Henrique de Figueiredo
>luaL_openlib seems to leave one item to the stack (the table
>containing the library), and functions like lua_baselibopen,
>lua_mathlibopen and lua_tablibopen leave the table
>on stack.

This is an oversight. lua_*libopen should return 1, not 0.

>The 5(alpha) did completely regenerate the table of the library
>in loadlib, but 5(beta) reuses the table, and just
>adds items to it. In some sense I find the alpha behaviour
>cleaner.

This is to allow things like opening a library directly into the global table
or or library appending things to another (eg. system-dependent functions
to the "os" library).
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Lua5(beta) luaL_openlib

Eero Pajarre-3
Luiz Henrique de Figueiredo wrote:
luaL_openlib seems to leave one item to the stack (the table
containing the library), and functions like lua_baselibopen,
lua_mathlibopen and lua_tablibopen leave the table
on stack.


This is an oversight. lua_*libopen should return 1, not 0.



I guess documenting it is the most important thing, if the
current behaviour is kept. It sort of breaks compatibility
though. Or am I missing something on how the return value
should help? (I mean the return value works if the function
is called from lua, but if you are calling it from the
host program...)


		Eero



Reply | Threaded
Open this post in threaded view
|

Lua 5.0 (beta)

Ed Ferguson
In reply to this post by Luiz Henrique de Figueiredo
The definition of getbinhandler() in section 3.7 does not seem to
reflect what is actually implemented.  The current definition seems to
say that the lookup of an event in a metatable is an normal, not
rawget(), type of access and is thus subject to __index handling if
the event is not present.  The example below shows that this is not
the case.

It seems to me that the current behavior is less desirable than having
event processing subject to __index handling so metatables can be
chained to get inherited behavior.

Note in the example that I have defined __index in mt2 so it is
possible to retrieve methods such as sub() from the metatable of a
table.  Have you considered extending the behavior of the interpreter
so something like this is the default behavior for table accesses?
This might be useful for class-level variables.

Should "metatable" in section 3.7 be replaced by "getmetatable"?

Ed

======================================================================

mt1 = {
  add =
    function (self, a)
      print("add", self.v, a.v) 
      return self.v + a.v
    end
  ,
  __add =
    function (a, b)
      print("__add", a.v, b.v)
      return a.v + b.v
    end
}

mt2 = { 
  __parent = mt1
  ,
  __index = 
    function (table, key)
      local mt = getmetatable(table)
      return mt[key] or mt.__parent[key]
    end
  ,
  sub =
    function (self, a)
      print("sub", self.v, a.v)
      return self.v - a.v
    end
  ,
  __sub =
    function (a, b)
      print("__sub", a.v, b.v)
      return a.v - b.v
    end
}

a = { v = 1 } ; setmetatable(a, mt2)
b = { v = 2 } ; setmetatable(b, mt2)

print( a:sub(b) )
print( a - b    )
print( a:add(b) )
print( a + b    )

------------------------------------------------------

sub	1	2
-1
__sub	1	2
-1
add	1	2
3
lua: oo.lua:43: attempt to perform arithmetic on global `a' (a table value)
stack traceback:
	oo.lua:43: in main chunk
	[C]:[C]