[ANN] Lua 5.2.0 (alpha) now available

classic Classic list List threaded Threaded
107 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

[ANN] Lua 5.2.0 (alpha) now available

Luiz Henrique de Figueiredo
Lua 5.2.0 (alpha) is now available at
        http://www.lua.org/work/lua-5.2.0-alpha-rc1.tar.gz

MD5 525bfa6daec8b0773845989c4886b668  -
SHA1 b63703993ebaa3e361ede3fd1058c593bdc47034  -

This is an alpha version. Some details may change in the final version.

The main changes since Lua 5.1 are:
- yieldable pcall and metamethods
- new __ENV scheme
- ephemeron tables
- new library for bitwise operations
- light C functions
- emergency garbage collector
The other changes are listed in
        http://www.lua.org/work/doc/#changes

The complete diffs are available at
        http://www.lua.org/work/diffs-lua-5.2.0-work5-alpha-rc1.txt

This release candidate will be the alpha version if no glitches are found
in the next 10 days or so.

All feedback welcome. Thanks.
--lhf


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (alpha) now available

Pavel Holejsovsky-2
On 11/16/2010 2:15 PM, Luiz Henrique de Figueiredo wrote:
> Lua 5.2.0 (alpha) is now available at
>
> This is an alpha version. Some details may change in the final version.
>
> All feedback welcome. Thanks.

I see that luaL_typeerror() was removed completely (after rename from
luaL_typerror() in previous work releases).  Is it intentional?  What
was wrong with it?

thanks,
Pavel


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (alpha) now available

Patrick Donnelly
In reply to this post by Luiz Henrique de Figueiredo
On Tue, Nov 16, 2010 at 8:15 AM, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
> All feedback welcome. Thanks.

o luaL_prepbuffsize, luaL_pushresultsize, luaL_buffinitsize,
luaL_pushmodule, luaL_openlib, luaL_newlibtable, luaL_findtable
undocumented.
o Undocumented and unknown purpose at the end of lauxlib.h:

/* compatibility with ref system */

/* pre-defined references */
#define LUA_NOREF       (-2)
#define LUA_REFNIL      (-1)

#define lua_ref(L,lock) ((lock) ? luaL_ref(L, LUA_REGISTRYINDEX) : \
      (lua_pushstring(L, "unlocked references are obsolete"), lua_error(L), 0))

#define lua_unref(L,ref)        luaL_unref(L, LUA_REGISTRYINDEX, (ref))

#define lua_getref(L,ref)       lua_rawgeti(L, LUA_REGISTRYINDEX, (ref))


#define luaL_reg    luaL_Reg

--
- Patrick Donnelly

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (alpha) now available

Ted Unangst
In reply to this post by Luiz Henrique de Figueiredo
On Tue, Nov 16, 2010 at 8:15 AM, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
> Lua 5.2.0 (alpha) is now available at
>        http://www.lua.org/work/lua-5.2.0-alpha-rc1.tar.gz

Consider the following code.  I expect it to print "bad" once, but it
does so many times.  The manual is a little unclear, but seems to
imply that xpcall(f, err) only puts f in protected mode.  It shouldn't
catch errors in err.  Does that make sense?  This may be a semantic
change from 5.1, but is it still fixable in 5.2?

function t()
        error("oops")
end

function c()
        print("bad")
        error("again")
end

xpcall(t, c)

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (alpha) now available

Peter Cawley
In reply to this post by Luiz Henrique de Figueiredo
On Tue, Nov 16, 2010 at 1:15 PM, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
> This release candidate will be the alpha version if no glitches are found
> in the next 10 days or so.
>
> All feedback welcome. Thanks.

It would seem that the string library doesn't yet completely like
embedded null characters in patterns. In particular, the following
code doesn't give the expected result:

Lua 5.2.0 (alpha)  Copyright (C) 1994-2010 Lua.org, PUC-Rio
> return string.find("\0\0","\0.")
nil

I believe that this is caused by the following line in lstrlib.c,
which causes patterns with no special characters prior to the first
embedded null character to be treated as plaintext.

strpbrk(p, SPECIALS) == NULL)) {  /* or no special characters? */

Regards,
Peter

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (alpha) now available

Roberto Ierusalimschy
In reply to this post by Ted Unangst
> Consider the following code.  I expect it to print "bad" once, but it
> does so many times.  The manual is a little unclear, but seems to
> imply that xpcall(f, err) only puts f in protected mode.  It shouldn't
> catch errors in err.  Does that make sense? [...]

It may make sense for the particular case of xpcall, but this behavior
comes from the more primitive lua_pcall, and it is difficult to change
one without changing the other.

For lua_pcall, this behavior seems better than the alternative (to
raise errors from 'err'). It ensures that lua_pcall never raises
an error.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (alpha) now available

Valerio
Hello,
is there any performance gains in this release (pure raw speed, less
memory consuming - not that the current one has, just to to know - ) ?

thanks,
valerio

On Tue, Nov 16, 2010 at 5:01 PM, Roberto Ierusalimschy
<[hidden email]> wrote:

>> Consider the following code.  I expect it to print "bad" once, but it
>> does so many times.  The manual is a little unclear, but seems to
>> imply that xpcall(f, err) only puts f in protected mode.  It shouldn't
>> catch errors in err.  Does that make sense? [...]
>
> It may make sense for the particular case of xpcall, but this behavior
> comes from the more primitive lua_pcall, and it is difficult to change
> one without changing the other.
>
> For lua_pcall, this behavior seems better than the alternative (to
> raise errors from 'err'). It ensures that lua_pcall never raises
> an error.
>
> -- Roberto
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (alpha) now available

Roberto Ierusalimschy
In reply to this post by Pavel Holejsovsky-2
> I see that luaL_typeerror() was removed completely (after rename
> from luaL_typerror() in previous work releases).  Is it intentional?
> What was wrong with it?

It is a quite specific function, with a strange interface (one type came
as a tag, the other as a name), easily written by the user if needed.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (alpha) now available

Roberto Ierusalimschy
In reply to this post by Patrick Donnelly
> o luaL_prepbuffsize, luaL_pushresultsize, luaL_buffinitsize,
> luaL_pushmodule, luaL_openlib, luaL_newlibtable, luaL_findtable
> undocumented.

auxlib has two different roles: it offers facilities for the "general
public", but it also has some facilities used by the standard libraries
that do not seem worth to become "oficial", documented functions. (See
what happened to luaL_typeerror.) Some of the above functions really
should (and will) be documented, but not all of them.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (alpha) now available

Roberto Ierusalimschy
In reply to this post by Valerio
> is there any performance gains in this release (pure raw speed, less
> memory consuming - not that the current one has, just to to know - ) ?

Nothing relevant.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (alpha) now available

Lorenzo Donati-2
In reply to this post by Luiz Henrique de Figueiredo
Hi all!
I really would have asked this some time ago, but this quick switch from
  work5 to alpha was quite a surprise (for me - my bad :-) ), so I hope
my question/curiosity/(request?) isn't too late.

I noticed that Lua's build is quite customizable through luaconf.h, so I
wonder how a script can detect the different options used to compile the
Lua interpreter under it is running.

Somehow I would expect that an highly dynamic language like Lua would
have some way to know (say) the value of LUAL_BUFFERSIZE or some other
constants defined in luaconf.h.

I realize that not all constants in there may be meaningful at runtime,
but I think memory limits or whether the 'number' type is implemented as
a double or a an int could really be useful. That could allow to write
scripts that are more cross-platform or cross-implementation and
implement at least some meaningful message to the user about why they
cannot run in the current environment.

Couldn't some of those defines (or even some other parameters not found
in luaconf.h, like max number of item that can be unpacked) be made
available as "constants" in a table, or maybe through a function like
the following:
debug.limits 'number-type' --> 'double'
debug.limits 'number-size-bits' --> 64
debug.limits 'buffersize-bytes' --> 123456
debug.limits 'max-unpack-table-size' --> 8000

Am I missing something why Lua doesn't provide such informations? Isn't
that so useful as I think?

On a related note (I remember this has been asked before, but it never
got answered by Lua team) why the strange format of package.config
content? It seems very unreadable. I suspect many people will parse
package.config and assign the relevant characters to separate variables
for readability and convenience.
Wouldn't a table with keys like DIR_SEPARATOR or a function like
package.config 'dir-separator' be more readable? Would that add so much
more 'weight' to Lua?

Thanks

-- Lorenzo




Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (alpha) now available

Luiz Henrique de Figueiredo
> this quick switch from work5 to alpha was quite a surprise (for me - my bad

http://lua-users.org/lists/lua-l/2010-10/msg00834.html said that we were
getting close to an alpha version. Note that we're still at alpha-rc1.

> I noticed that Lua's build is quite customizable through luaconf.h, so I
> wonder how a script can detect the different options used to compile the
> Lua interpreter under it is running.

Try this:

  gcc -E -P - -I. <<EOF
  #include "lua.h"
  VALUE_OF_LUAL_BUFFERSIZE = LUAL_BUFFERSIZE
  EOF

But I understand that this is not from inside running a Lua interpreter.

> Couldn't some of those defines (or even some other parameters not found
> in luaconf.h, like max number of item that can be unpacked) be made
> available as "constants" in a table, or maybe through a function

You can do that yourself, using the technique above.

> Am I missing something why Lua doesn't provide such informations? Isn't
> that so useful as I think?

It's probably not that useful. Plus it encourages complicated programming.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (alpha) now available

Lorenzo Donati-2
Thank you very much for the prompt reply!

Luiz Henrique de Figueiredo wrote:
>> this quick switch from work5 to alpha was quite a surprise (for me - my bad
>
> http://lua-users.org/lists/lua-l/2010-10/msg00834.html said that we were
> getting close to an alpha version. Note that we're still at alpha-rc1.

As I said: "my bad" :-)
I read that message but I didn't really realize that we were _so_ close :-)
I once stumbled upon the timeline of Lua evolution and was really struck
- positively I mean - by the negation of the principle "release early,
release often" ("release crap" - I would sometimes add to that :-) ).
That trend has somehow stuck in my mind, so ... :-)

>
>> I noticed that Lua's build is quite customizable through luaconf.h, so I
>> wonder how a script can detect the different options used to compile the
>> Lua interpreter under it is running.
>
> Try this:
>
>   gcc -E -P - -I. <<EOF
>   #include "lua.h"
>   VALUE_OF_LUAL_BUFFERSIZE = LUAL_BUFFERSIZE
>   EOF
>
> But I understand that this is not from inside running a Lua interpreter.
>
Thanks! But that is some sort of "C-compiler magic" that I'm not very
accustomed to! I understand that many experienced Lua programmers are
also C Wizards, but I feel always a bit uneasy at C (and don't know gcc
so well :-( )
Last time I used C in a more serious ways was back around 1992 with
turbo C! :-)


>> Couldn't some of those defines (or even some other parameters not found
>> in luaconf.h, like max number of item that can be unpacked) be made
>> available as "constants" in a table, or maybe through a function
>
> You can do that yourself, using the technique above.
>
Ok.
>> Am I missing something why Lua doesn't provide such informations? Isn't
>> that so useful as I think?
>
> It's probably not that useful. Plus it encourages complicated programming.
>
Oh. I see.
But I wonder whether it is safe, for example, not to know (officially -
It is not written in the reference manual) that the limit for unpacking
a table is far lower than the memory limit.
This way a novice programmer (not knowledgeable of the C inner workings
of Lua) could think that unpacking a 10,000 items array should be
doable, and instead get an error (maybe in production code). At least it
should be mentioned in the manual that unpack has some limit and is not
intended for large array operations.
Moreover the manual itself could be misleading. From Lua's 5.1.4 refman
- unpack description:
"...except that the above code can be written only for a fixed number of
elements"
This could lead one to think that unpack is designed to handle tables of
arbitrary length (at least in the limit of the available memory).

Sorry for focusing on "unpack", but it is just an example to make my
point as clear as possible.

I remember reading something on sqlite3 documentation where the authors
regretted that in early versions of sqlite there were no documented
limits (by design - they thought a good idea to omit that information)
and this led to very subtle bugs (http://www.sqlite.org/limits.html).

Maybe in Lua there are statistically no significants threats in this
area, but still I feel some more information (carefully selected,
possibly) either at runtime or in the docs (at the very least a pointer
to the relevant section of lua.h or luaconf.h) should be added.
Maybe a table generated from the trick above in an automatic way should
be an integral part of the refman of stock Lua, so a non-C programmer
could have a general idea of what stock Lua can handle (and that to
alter those limits one has to poke around with C).

Thanks a lot.

-- Lorenzo

P.S.: still curious about the funny format of package.config :-)



Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (alpha) now available

Luiz Henrique de Figueiredo
> This way a novice programmer (not knowledgeable of the C inner workings
> of Lua) could think that unpacking a 10,000 items array should be
> doable, and instead get an error (maybe in production code).

In Lua 5.2 the limit seems to be 1,000,00.

> At least it should be mentioned in the manual that unpack has some
> limit and is not intended for large array operations.

Probably, yes.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (alpha) now available

Lorenzo Donati-2
Luiz Henrique de Figueiredo wrote:
>> This way a novice programmer (not knowledgeable of the C inner workings
>> of Lua) could think that unpacking a 10,000 items array should be
>> doable, and instead get an error (maybe in production code).
>
> In Lua 5.2 the limit seems to be 1,000,00.

Good news! (I suppose it is a typo and you meant 1,000,000).
I did not test 5.2 (just skimmed over the refman and peeked around in
the source).
I did all the test in 5.1.4 (sorry I forgot to mention that) and in a
'real' (no test) script I really hit that 8,000 limit.


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (alpha) now available

Alexander Gladysh
In reply to this post by Luiz Henrique de Figueiredo
On Tue, Nov 16, 2010 at 16:15, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
> Lua 5.2.0 (alpha) is now available at
>        http://www.lua.org/work/lua-5.2.0-alpha-rc1.tar.gz
>
> MD5     525bfa6daec8b0773845989c4886b668  -
> SHA1    b63703993ebaa3e361ede3fd1058c593bdc47034  -
>
> This is an alpha version. Some details may change in the final version.

Hurray!

A quick note: http://www.lua.org/work/doc/manual.html#8 contains bogus
"&lsquo" words.

Alexander.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (alpha) now available

Tony Finch
On Wed, 17 Nov 2010, Alexander Gladysh wrote:
>
> A quick note: http://www.lua.org/work/doc/manual.html#8 contains bogus
> "&lsquo" words.

HTML entities do not need a trailing semicolon immediately before a tag or
a newline. (XML and XHTML require the semicolon.) See the second note in
section 5.3 of the HTML spec:
http://www.w3.org/TR/html401/charset.html#entities

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (alpha) now available

Thomas Harning Jr.
In reply to this post by Luiz Henrique de Figueiredo
Any thoughts about adding a version specifier to the library/executable/headers?
The current setup precludes a clean inclusion in Linux without
mangling makefiles for Lua and messing with the "lua" executable's
name.

On 11/16/10, Luiz Henrique de Figueiredo <[hidden email]> wrote:

> Lua 5.2.0 (alpha) is now available at
> http://www.lua.org/work/lua-5.2.0-alpha-rc1.tar.gz
>
> MD5 525bfa6daec8b0773845989c4886b668  -
> SHA1 b63703993ebaa3e361ede3fd1058c593bdc47034  -
>
> This is an alpha version. Some details may change in the final version.
>
> The main changes since Lua 5.1 are:
> - yieldable pcall and metamethods
> - new __ENV scheme
> - ephemeron tables
> - new library for bitwise operations
> - light C functions
> - emergency garbage collector
> The other changes are listed in
> http://www.lua.org/work/doc/#changes
>
> The complete diffs are available at
> http://www.lua.org/work/diffs-lua-5.2.0-work5-alpha-rc1.txt
>
> This release candidate will be the alpha version if no glitches are found
> in the next 10 days or so.
>
> All feedback welcome. Thanks.
> --lhf
>
>
>


--
Thomas Harning Jr.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (alpha) now available

Alexandre Erwin Ittner
In reply to this post by Luiz Henrique de Figueiredo
Luiz Henrique de Figueiredo <[hidden email]> wrote

> This release candidate will be the alpha version if no glitches are found
> in the next 10 days or so.

So, is the pkg-config metadata file gone forever? I understand that
keeping the number of files in the package is good, but providing a
standard, core-dev blessed, library settings is good too.


--
Alexandre Erwin Ittner - [hidden email]
OpenPGP pubkey 0x0041A1FB @ http://pgp.mit.edu

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (alpha) now available

Luiz Henrique de Figueiredo
In reply to this post by Thomas Harning Jr.
> Any thoughts about adding a version specifier to the library/executable/headers?
> The current setup precludes a clean inclusion in Linux without
> mangling makefiles for Lua and messing with the "lua" executable's
> name.

This is a job for downstream packagers.

1234 ... 6