[ANNOUNCE] Lua 5.0 (alpha) now available

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

[ANNOUNCE] Lua 5.0 (alpha) now available

Luiz Henrique de Figueiredo
Lua 5.0 (alpha) is now available for downloading at
	http://www.lua.org/ftp/lua-5.0-alpha.tar.gz
	ftp://ftp.lua.org/lua-5.0-alpha.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 *alpha* release, not a work release. This means that
Lua 5.0 final is expected to be very close to it, unless serious flaws are
found. Small improvements are expected, specially in the implementation, but
no visible changes to programmers. In particular, if you're interested, you can
start porting your programs now; we don't expect to introduce incompatibilities
in Lua 5.0 final.

The tarball contains complete documentation in HTML, including an updated
reference manual and a new logo to celebrate recent sport events :-).
Printable versions of the manual in PS and PDF are available at
	http://www.lua.org/ftp/refman-5.0-alpha.ps.gz
	http://www.lua.org/ftp/refman-5.0-alpha.pdf
and soon at the mirror sites.

Please take some time to read the manual, as this is a major new release.
The manual still needs work: it is incomplete in parts but hopefully
it does not says false things.

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

Enjoy.
--lhf

Reply | Threaded
Open this post in threaded view
|

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

Vincent Penquerc'h-4
Title: RE: [ANNOUNCE] Lua 5.0 (alpha) now available

> The tarball contains complete documentation in HTML,

Thank you for that!

>   + new, faster, register-based virtual machine.

But where will you stop! ;)

--
Vincent Penquerc'h

Reply | Threaded
Open this post in threaded view
|

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

benjamin sunshine-hill
In reply to this post by Luiz Henrique de Figueiredo
I've only looked at the manual so far, but I really like what I see. When will 
more information about coroutines be available? How similar will they be 
to the operation of the yield() patch in 4.x?

Oh, and in section 4.2 of the manual, you refer to "tag 
methods"...shouldn't this be "metamethods"?


Reply | Threaded
Open this post in threaded view
|

Globals in 5.0 Alpha

Peter Loveday-2
Firstly, thanks for 5.0 alpha - this is perfect timing for our
schedule.

So, how does one use the new 'local global table' stuff ?


Love, Light and Peace,

- Peter Loveday
Director of Development, eyeon Software



Reply | Threaded
Open this post in threaded view
|

Re: Globals in 5.0 Alpha

Luiz Henrique de Figueiredo
>So, how does one use the new 'local global table' stuff ?

See test/readonly.lua. It sets the current global table to a proxy to the
"real" global table and this setup is restricted to that chunk.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Globals in 5.0 Alpha

Eric Tetz-2
Does anybody have a Vim syntax for Lua 5? I couldn't find anything for *any* version of Lua on the
official site or the user's site. I remember it being there, but it seems to have vanished.

By the way: I just discovered the searchable archive of this list at lua-users.org. Awesome guys!
Thanks.


__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

Reply | Threaded
Open this post in threaded view
|

luasocket port to Lua 5.0 alpha

Kurt Jung-2
Will there be an official port of the luasocket library (written by Diego Nehab) to Lua 5.0?

In attempting to port it myself I am running into the inevitable issues regarding tags and metatables. The library tags server sockets, client sockets, udp sockets and also the table which itself contains these tags. The "gc" tag method is used with server socket userdata. This clearly will be placed in a metatable. Apparently, all other instances use tags simply as a type-checking mechanism. 

Is there a Lua 5 construction that allows userdata to be "typed" more simply than with metatables? If not, then is the most appropriate solution to put a numeric identifier in each object's metatable?

Quick aside: the new documentation for "lua_error" shows the old style prototype with string parameter.

Suggestion: I would like to see "lua_getn" made public again. It seems to me that many C programs use this, not just ltablib.c.

Kurt Jung
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: luasocket port to Lua 5.0 alpha

Diego Nehab-3
> Will there be an official port of the luasocket library (written by Diego Nehab) to Lua 5.0?

Hi,

Yes, there will be a port to Lua 5.0.


Best regards,
Diego.


Reply | Threaded
Open this post in threaded view
|

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

D Burgess
In reply to this post by Luiz Henrique de Figueiredo
Are we going to document lua_boxpointer?


Reply | Threaded
Open this post in threaded view
|

Re: Globals in 5.0 Alpha

Luiz Henrique de Figueiredo
In reply to this post by Luiz Henrique de Figueiredo
>Does anybody have a Vim syntax for Lua 5?

Try http://www.tecgraf.puc-rio.br/~cmendes/vim/syntax/ .
It should work for Lua 5, if it worked for Lua 4, except that I recall that it
had problems with long strings [[...]] and so now will also have problems with
block comments --[[...]]. I think the author intended to look into it, but
probably lacked the time (like us all).

>By the way: I just discovered the searchable archive of this list at lua-users.org. Awesome guys!

Yes, many thanks are due to John Belmonte!
There's also the newgroup interface at Gname:
	http://news.gmane.org/thread.php?group=gmane.comp.lang.lua.general
but it does not contain the complete lua-l archive.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: luasocket port to Lua 5.0 alpha

Luiz Henrique de Figueiredo
In reply to this post by Kurt Jung-2
>Is there a Lua 5 construction that allows userdata to be "typed" more simply than with metatables? If not, then is the most appropriate solution to put a numeric identifier in each object's metatable?

If you're using light userdata, then you can try to add an entry in the registry
or any other table whose key is the pointer and whose value is your notion of
type, say a simple numeric id. For ordinary user data, the metatable itself
identifies objects of the same "class".

>Quick aside: the new documentation for "lua_error" shows the old style prototype with string parameter.

Thanks. Will be fixed.

>Suggestion: I would like to see "lua_getn" made public again. It seems to me that many C programs use this, not just ltablib.c.

The n is no longer stored in tables (but can be): it's stored in a separate
table, indexed by the tables. This is an implementation decision of the table
library; it does not belong in the core of Lua. You can always call "getn"
using lua_call...
--lhf

Reply | Threaded
Open this post in threaded view
|

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

Luiz Henrique de Figueiredo
In reply to this post by Luiz Henrique de Figueiredo
>Are we going to document lua_boxpointer?

In Lua 5.0 we cleaned up the confusion of what a userdata is and how it is
created: userdata are Lua objects created with lua_newuserdata:

	LUA_API void *lua_newuserdata (lua_State *L, size_t size);

lua_newuserdata creates an object that has an attached buffer of the given
size; this buffer is returned to the host program and can be written to.
Lua never looks inside the buffer, but userdata objects, like all other objects,
are subject to garbage collection. In other words, lua_newuserdata gives
you a buffer that you don't have to worry about mallocing or freeing, but
which you can used to store whatever you want, even dynamically changing its
contents.

lua_boxpointer covers the common case of wanting to store a pointer in this
buffer. lua_unboxpointer gets the pointer from the buffer of the given Lua
object. A typical use is to store the pointer of a C struct that has to be
exported to Lua so that it can have a metatable. Only userdata created with
lua_newuserdata can have metatables. Note also that lua_boxpointer will
return a different Lua object each time it is called, even if the same pointer
is used.

Lua 5.0 also introduced "light" userdata, which are pointers treated as values,
not as objects. Light userdata is more like numbers: no memory is allocated,
except the Lua value struct where all Lua values reside. On the other hand,
"light" userdata cannot have metatables. Two "light" userdata values are the
same iff their pointers are the same.

We think this scheme is clear and makes userdata both flexible and fast.
--lhf

Reply | Threaded
Open this post in threaded view
|

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

D Burgess
Many thanks. What sort of speed improvement are we looking at?
DB

> >Are we going to document lua_boxpointer?
>
> In Lua 5.0 we cleaned up the confusion of what a userdata is and how it is
> created: userdata are Lua objects created with lua_newuserdata:
>
> LUA_API void *lua_newuserdata (lua_State *L, size_t size);
>
> lua_newuserdata creates an object that has an attached buffer of the given
> size; this buffer is returned to the host program and can be written to.
> Lua never looks inside the buffer, but userdata objects, like all other
objects,
> are subject to garbage collection. In other words, lua_newuserdata gives
> you a buffer that you don't have to worry about mallocing or freeing, but
> which you can used to store whatever you want, even dynamically changing
its
> contents.
>
> lua_boxpointer covers the common case of wanting to store a pointer in
this
> buffer. lua_unboxpointer gets the pointer from the buffer of the given Lua
> object. A typical use is to store the pointer of a C struct that has to be
> exported to Lua so that it can have a metatable. Only userdata created
with
> lua_newuserdata can have metatables. Note also that lua_boxpointer will
> return a different Lua object each time it is called, even if the same
pointer
> is used.
>
> Lua 5.0 also introduced "light" userdata, which are pointers treated as
values,
> not as objects. Light userdata is more like numbers: no memory is
allocated,
> except the Lua value struct where all Lua values reside. On the other
hand,
> "light" userdata cannot have metatables. Two "light" userdata values are
the
> same iff their pointers are the same.
>
> We think this scheme is clear and makes userdata both flexible and fast.
> --lhf
>


Reply | Threaded
Open this post in threaded view
|

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

Björn De Meyer
In reply to this post by Luiz Henrique de Figueiredo
Luiz Henrique de Figueiredo wrote:
> 
> >Are we going to document lua_boxpointer?
> 
> In Lua 5.0 we cleaned up the confusion of what a userdata is and how it is
> created: userdata are Lua objects created with lua_newuserdata:
> 
>         LUA_API void *lua_newuserdata (lua_State *L, size_t size);
> 
> lua_newuserdata creates an object that has an attached buffer of the given
> size; this buffer is returned to the host program and can be written to.
> Lua never looks inside the buffer, but userdata objects, like all other objects,
> are subject to garbage collection. In other words, lua_newuserdata gives
> you a buffer that you don't have to worry about mallocing or freeing, but
> which you can used to store whatever you want, even dynamically changing its
> contents.

That's good! But, what if you want to resize the data block pointed to?
Wouldn't a void * lua_resizeuserdata(lua_State *L, void *ptr, size_t
size)
come in handy then? Or is it already there?

-- 
"No one knows true heroes, for they speak not of their greatness." -- 
Daniel Remar.
Björn De Meyer 
[hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Luiz Henrique de Figueiredo
In reply to this post by Luiz Henrique de Figueiredo
>That's good! But, what if you want to resize the data block pointed to?

You'll have to manage it yourself: create a new userdata and copy the old
contents to the new buffer.

>Wouldn't a void * lua_resizeuserdata(lua_State *L, void *ptr, size_t size)
>come in handy then?

Perhaps, but it would have to be "int index" instead of "void *ptr", that is,
it would to receive a Lua object to resize, not a pointer. The pointer is
returned by lua_newuserdata just so you can fill the buffer, but the main
value is the whole userdata value that lua_newuserdata also leaves on the stack.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: luasocket port to Lua 5.0 alpha

Roberto Ierusalimschy
In reply to this post by Kurt Jung-2
> Is there a Lua 5 construction that allows userdata to be "typed" more
> simply tha n with metatables?

Lua itself uses two solutions: the first one is to consider the
metatable itself as the "type". You store it somewhere (upvalue of your
C functions, or in the registry), and then you compare the metatable of
your userdata against it. E.g.:

  lua_pushliteral(L, "MyTypeName");
  lua_rawget(L, LUA_REGISTRYINDEX);  /* get registry.MyTypeName */
  if (lua_getmetatable(L, udata)) {  /* udata has a metatable? */
    if (lua_rawequal(L, -1, -2)) {  /* and is the correct one? */
      ...

The other is to store the userdata as the index in a table of yours,
associated with any identification (If you have a table only for that
type, the presence of the userdata as an index is enough to ensure its
"autenticity"). It is important that such table has weak keys, otherwise
your userdata will never be collected.


> If not, then is the most appropriate solution to put a numeri c
> identifier in each object's metatable?

This is not very safe, as the Lua code can access the object metatable
and change that identifier. (Lua code cannot change the metatable of a
userdata, but by default it can access it, and change its contents.)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

John Belmonte-2
In reply to this post by Luiz Henrique de Figueiredo
Hi,

The alpha version looks great.  I have a few questions and suggestions:


* list generator

  I'd like to see a generator in the library for lists that doesn't
  include the index as ipairs does:

    for v in list(t) do ... end


* pushfstring/pushvfstring (4.7)

  Why the restricted custom implementation instead of building these
  using vsprintf?  Note that LUA_NUMBER_FMT can always be inserted into
  a static format using C string concatenation.


* what happens if a finalizer function leaves a reference to the given
  object? (3.7.1)


-John



--
http:// i      .   /


Reply | Threaded
Open this post in threaded view
|

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

Russell Y. Webb
Just out of curiosity, how many downloads of 5.0 (alpha) have there been so far?

It would be educational to hear a rough number just to get a sense for the community size (at least of active, early adopters).

Thanks,
Russ Webb


Reply | Threaded
Open this post in threaded view
|

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

John Passaniti-4
In reply to this post by John Belmonte-2
> * pushfstring/pushvfstring (4.7)
> 
>    Why the restricted custom implementation
>    instead of building these using vsprintf?  

If *printf is already linked in elsewhere by Lua, I guess I don't have a
big problem with this.  The cost of the format interpreter is already
there.  But if this is the only place where *printf is used, then I
would prefer that Lua *not* use *printf.

Those of us who work with embedded systems typically have memory
constraints we have to worry about, and the core routine that implements
the *printf family of functions can be a surprisingly huge-- both in
terms of code, and in some implementations stack and RAM usage.  For
those using Lua on desktop systems, with gobs of virtualized memory,
none of this matters.  For those who are trying to fit inside limited
address spaces, we cringe anytime anyone wants to link in something
large.  








Reply | Threaded
Open this post in threaded view
|

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

John Belmonte-2
So what you're suggesting is that every app or library you run on your embedded system create its own mini-printf as needed. If you have enough libraries doing that you'll go over the size of the standard C's implementation anyway. Plus there is the wasted human effort.

If you don't buy that, then consider that if your apps and libraries truly don't require the full printf, then all you need do is replace the standard C's implementation according to your constraints (and cover everything you run on your system in one swipe). With this, the person that needs the special case is the one that does the special work, and everyone else gets the generality afforded by the C library.

-John


John Passaniti wrote:
If *printf is already linked in elsewhere by Lua, I guess I don't have a
big problem with this.  The cost of the format interpreter is already
there.  But if this is the only place where *printf is used, then I
would prefer that Lua *not* use *printf.

Those of us who work with embedded systems typically have memory
constraints we have to worry about, and the core routine that implements
the *printf family of functions can be a surprisingly huge-- both in
terms of code, and in some implementations stack and RAM usage.  For
those using Lua on desktop systems, with gobs of virtualized memory,
none of this matters.  For those who are trying to fit inside limited
address spaces, we cringe anytime anyone wants to link in something
large.


--
http:// i      .   /


123