[ANN] Lua 5.3.0 (beta) now available

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

[ANN] Lua 5.3.0 (beta) now available

Luiz Henrique de Figueiredo
Lua 5.3.0 (beta) is now available for testing at
        http://www.lua.org/work/lua-5.3.0-beta.tar.gz

MD5 e46b91de3d22a308d3350a14b242e2c7  -
SHA1 0fa2b527611fe3a1b083359ce15e91f27b108eec  -

This is a beta version. A few details may change in the final version.

The main change in Lua 5.3.0 is the introduction of integers. See also
        http://www.lua.org/work/doc/#changes

Another change, new in beta, is the introduction of string.pack and
string.unpack, which replace and extend string.dump* and string.undump*.

The complete diffs are available at
        http://www.lua.org/work/diffs-lua-5.3.0-alpha-beta.txt

A test suite is available at
        http://www.lua.org/work/lua-5.3.beta-tests.tar.gz

All feedback welcome. Thanks.
--lhf


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (beta) now available

Paige DePol
On Oct 23, 2014, at 6:13 AM, Luiz Henrique de Figueiredo <[hidden email]> wrote:

> Lua 5.3.0 (beta) is now available for testing at
> http://www.lua.org/work/lua-5.3.0-beta.tar.gz
>
> MD5 e46b91de3d22a308d3350a14b242e2c7  -
> SHA1 0fa2b527611fe3a1b083359ce15e91f27b108eec  -
>
> This is a beta version. A few details may change in the final version.
>
> The main change in Lua 5.3.0 is the introduction of integers. See also
> http://www.lua.org/work/doc/#changes
>
> Another change, new in beta, is the introduction of string.pack and
> string.unpack, which replace and extend string.dump* and string.undump*.
>
> The complete diffs are available at
> http://www.lua.org/work/diffs-lua-5.3.0-alpha-beta.txt
>
> A test suite is available at
> http://www.lua.org/work/lua-5.3.beta-tests.tar.gz
>
> All feedback welcome. Thanks.
> --lhf

Thank you for this latest update, Luiz. After this beta will the next release be the final version?

Sadly, I have had very little time for Lua hacking over the past three months as my partner has had some serious medical issues. The good news is that things have stabilised and I once again have time to devote to hacking Lua!

I look forward to the final release of 5.3.0, in the meantime it seems that I have a bunch of patching to do!

~pmd




Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (beta) now available

Dirk Laurie-2
2014-10-23 14:39 GMT+02:00 Paige DePol <[hidden email]>:
> On Oct 23, 2014, at 6:13 AM, Luiz Henrique de Figueiredo <[hidden email]> wrote:
>
>> Lua 5.3.0 (beta) is now available for testing at
>>       http://www.lua.org/work/lua-5.3.0-beta.tar.gz
> Thank you for this latest update, Luiz. After this beta will the next release be the final version?

We had lua-5.2.1 all the way up to rc4 :-)

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (beta) now available

Roberto Ierusalimschy
> 2014-10-23 14:39 GMT+02:00 Paige DePol <[hidden email]>:
> > On Oct 23, 2014, at 6:13 AM, Luiz Henrique de Figueiredo <[hidden email]> wrote:
> >
> >> Lua 5.3.0 (beta) is now available for testing at
> >>       http://www.lua.org/work/lua-5.3.0-beta.tar.gz
> > Thank you for this latest update, Luiz. After this beta will the next release be the final version?
>
> We had lua-5.2.1 all the way up to rc4 :-)

This was a sad consequence of people paying too little attention to
alpha and beta versions. Most issues that appeared in that long
sequence of release candidates were already present in the alpha
and/or beta versions, but nobody cared to complain (probably because
they did not care to try those versions) before the final version.

It would be very helpful if people really tried this beta version...

BTW, these are the main changes from alpha to beta:

* 'dumpint' and co. replaced by 'string.pack'/'string.unpack'
* new functions 'lua_geti'/'lua_seti'
* 'ipairs' stops at first 'nil'
* 'lua_Ctx' renamed to 'lua_Kcontext'
* %U gets a long (instead of int)
* deprecated 'luaL_checkint'/'luaL_optint'/'luaL_checklong'/'luaL_optlong'
* 'luaL_getmetafield' returns field type
* 'table.copy' -> 'table.move' (plus change in order of parameters)
* 'debug.Csize' removed (subsumed by 'string.pack')
* 'lua_strtonum' -> 'lua_stringtonum'
* change in handling of non-string error messages in lua.c
* ANSI mode turns off 64 bits (as 'long long' is not ANSI)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (beta) now available

Luiz Henrique de Figueiredo
In reply to this post by Paige DePol
> After this beta will the next release be the final version?

Yes. But it will go through a cycle of release candidates to remove any
remaining glitches.

Now is the time to remind us of any glitches you have found in Lua 5.2
or to report new ones in both 5.2 and 5.3. In particular, problems in
the Makefiles and in the documentation.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (beta) now available

Timm S. Mueller
In reply to this post by Luiz Henrique de Figueiredo
On Thu, 23 Oct 2014 09:13:59 -0200
Luiz Henrique de Figueiredo <[hidden email]> wrote:

> Lua 5.3.0 (beta) is now available for testing at
> http://www.lua.org/work/lua-5.3.0-beta.tar.gz
>
> [..]
>
> All feedback welcome. Thanks.

Not having followed discussions and development of 5.3, but I find it
counterintuitive that %f has to be used in format() where previously %d
and %x would perform the needed conversion of numbers of any type to an
integer. Similarly, luaL_checkinteger() bails out if a numerical value
is not an integer. Is there a rationale to and can someone provide
links to previous discussions of this behavior? Thanks.

My first impression was that both cases needlessly break compatibility,
in both cases the caller is fully aware of the possibility to lose
information, and the convenience of the auxlib function is forfeit. For
me as a caller it would be obvious to distinguish between checking for
a type and to receiving an integer (or representation of such) as the
closest approximation of a number.

- Timm

--
Timm S. Mueller <[hidden email]>
Schulze & Mueller GbR, Jungstr. 2, 10247 Berlin,
Gesellschafter: Franciska Schulze, Timm S. Mueller,
Tel. +49 30 85610000, http://www.schulze-mueller.de/

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (beta) now available

Philipp Janda
In reply to this post by Luiz Henrique de Figueiredo
Am 23.10.2014 um 15:47 schröbte Luiz Henrique de Figueiredo:
>> After this beta will the next release be the final version?
>
> Yes. But it will go through a cycle of release candidates to remove any
> remaining glitches.
>
> Now is the time to remind us of any glitches you have found in Lua 5.2
> or to report new ones in both 5.2 and 5.3. In particular, problems in
> the Makefiles and in the documentation.

Found three typos in the manual:
- "enconding" in `manual.html`
- `lua_strtonum` in `readme.html`
- `table.copy` in `readme.html`

Philipp




Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (beta) now available

Dirk Laurie-2
In reply to this post by Roberto Ierusalimschy
2014-10-23 15:09 GMT+02:00 Roberto Ierusalimschy <[hidden email]>:
>
> BTW, these are the main changes from alpha to beta:

> * 'dumpint' and co. replaced by 'string.pack'/'string.unpack'
This is all of 'struct'. Bravo!

> * 'ipairs' stops at first 'nil'
> * 'luaL_getmetafield' returns field type
Both very welcome.

> * 'table.copy' -> 'table.move' (plus change in order of parameters)
I like that. But ... could we maybe also have table.reverse?

> * change in handling of non-string error messages in lua.c
It now says:
lua: (error object is a nil value)
stack traceback:
    [C]: in function 'error'
    err.lua:2: in function 'replace'
    err.lua:10: in main chunk
    [C]: in ?
Andrew will whoop with joy. So do I.

However, if "__tostring" has been defined, no traceback is added.
Are you willing to share the reasoning behind this with us?

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (beta) now available

Daurnimator
On 23 October 2014 11:41, Dirk Laurie <[hidden email]> wrote:
However, if "__tostring" has been defined, no traceback is added.
Are you willing to share the reasoning behind this with us?

The idea is that the object would be an 'error object', who's __tostring() might be a detailed stack trace.
This means that you can forge useful tracebacks from otherwise weird code (e.g. a stack of callbacks).

Throwing random objects as errors doesn't make a lot of sense in the first place.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (beta) now available

Sean Conner
In reply to this post by Roberto Ierusalimschy
It was thus said that the Great Roberto Ierusalimschy once stated:
>
> * ANSI mode turns off 64 bits (as 'long long' is not ANSI)

  Give in to the Dark Side!  Renounce Microsoft and embrase C99!

  Seriously!  C99 is 15 years old now!  C89 didn't take this long to be
accepted.

  -spc (Just say no to Microsoft)



Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (beta) now available

Javier Guerra Giraldez
On Thu, Oct 23, 2014 at 11:06 AM, Sean Conner <[hidden email]> wrote:
> It was thus said that the Great Roberto Ierusalimschy once stated:
>>
>> * ANSI mode turns off 64 bits (as 'long long' is not ANSI)
>
>   Give in to the Dark Side!  Renounce Microsoft and embrase C99!

there are still compilers for embedded platforms that are ANSI and not
C99; therefore, it makes sense not to depend on any non-ANSI feature
when targeting ANSI.

AFAICT, this has nothing to do with MS

--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (beta) now available

Roberto Ierusalimschy
> On Thu, Oct 23, 2014 at 11:06 AM, Sean Conner <[hidden email]> wrote:
> > It was thus said that the Great Roberto Ierusalimschy once stated:
> >>
> >> * ANSI mode turns off 64 bits (as 'long long' is not ANSI)
> >
> >   Give in to the Dark Side!  Renounce Microsoft and embrase C99!
>
> there are still compilers for embedded platforms that are ANSI and not
> C99; therefore, it makes sense not to depend on any non-ANSI feature
> when targeting ANSI.
>
> AFAICT, this has nothing to do with MS

Exactly. It is easy to detect MS, and MS supports 'long long' in
the form of __int64 (and so does Lua). The problem are embedded
(and old) platforms.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (beta) now available

Roberto Ierusalimschy
In reply to this post by Daurnimator
> On 23 October 2014 11:41, Dirk Laurie <[hidden email]> wrote:
>
> > However, if "__tostring" has been defined, no traceback is added.
> > Are you willing to share the reasoning behind this with us?
> >
>
> The idea is that the object would be an 'error object', who's __tostring()
> might be a detailed stack trace.
> This means that you can forge useful tracebacks from otherwise weird code
> (e.g. a stack of callbacks).

Exactly. Once you want to control the error message, you better have
full control.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (beta) now available

Roberto Ierusalimschy
In reply to this post by Timm S. Mueller
> Not having followed discussions and development of 5.3, but I find it
> counterintuitive that %f has to be used in format() where previously %d
> and %x would perform the needed conversion of numbers of any type to an
> integer. Similarly, luaL_checkinteger() bails out if a numerical value
> is not an integer. Is there a rationale to and can someone provide
> links to previous discussions of this behavior? Thanks.
>
> My first impression was that both cases needlessly break compatibility,
> in both cases the caller is fully aware of the possibility to lose
> information, and the convenience of the auxlib function is forfeit. For
> me as a caller it would be obvious to distinguish between checking for
> a type and to receiving an integer (or representation of such) as the
> closest approximation of a number.

Previous versions of Lua never specified *how* numbers were rounded in
the C API. So, if you called something like "string.sub(s,3.6)", you
could receive a string with either 3 or 4 bytes. This does not sound
like a behavior worth keeping.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (beta) now available

Roberto Ierusalimschy
In reply to this post by Philipp Janda
> Found three typos in the manual:
> - "enconding" in `manual.html`
> - `lua_strtonum` in `readme.html`
> - `table.copy` in `readme.html`

Many thanks.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (beta) now available

Andrew Starks
In reply to this post by Roberto Ierusalimschy


On Thu, Oct 23, 2014 at 12:02 PM, Roberto Ierusalimschy <[hidden email]> wrote:
> On 23 October 2014 11:41, Dirk Laurie <[hidden email]> wrote:
>
> > However, if "__tostring" has been defined, no traceback is added.
> > Are you willing to share the reasoning behind this with us?
> >
>
> The idea is that the object would be an 'error object', who's __tostring()
> might be a detailed stack trace.
> This means that you can forge useful tracebacks from otherwise weird code
> (e.g. a stack of callbacks).

Exactly. Once you want to control the error message, you better have
full control.

-- Roberto


Thank you! 

These changes look excellent (WHOOP!). We skipped the last alpha (abi compatibility is a pain and we wanted to minimize having to update everything). We will update to this and begin using it at once.

The modification to error is very welcomed but I must say, the serialization features are perhaps most exciting.

For practice, I want to carve out some time to re-implement msgpack and JSON encode/decoding in pure Lua 5.3. I'm very curious about those benchmarks.

Again, thank you to everyone for your hard work.

-Andrew
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (beta) now available

Alexander Nasonov
In reply to this post by Roberto Ierusalimschy
Roberto Ierusalimschy wrote:
> Exactly. It is easy to detect MS, and MS supports 'long long' in
> the form of __int64 (and so does Lua). The problem are embedded
> (and old) platforms.

You already have a bunch of make targets. Would you accept one more
"c99" target?

--
Alex

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (beta) now available

Luiz Henrique de Figueiredo
> You already have a bunch of make targets. Would you accept one more
> "c99" target?

You can do it right now with
        make generic SYSCFLAGS="-LUA_USE_C99"
or
        make generic SYSCFLAGS="-LUA_USE_C99 -std=c99"

Reply | Threaded
Open this post in threaded view
|

RE: [ANN] Lua 5.3.0 (beta) now available

Newman, Edward (iLO Firmware)
In reply to this post by Luiz Henrique de Figueiredo
A few minor change requests are listed below.

luaconf.h, line 73.  Change:
   #define _CRT_SECURE_NO_WARNINGS  /* avoid warnings about ANSI C functions */
To:
   #if !defined(_CRT_SECURE_NO_WARNINGS)
   #define _CRT_SECURE_NO_WARNINGS  /* avoid warnings about ANSI C functions */
   #endif
Explanation:  With an older Microsoft compiler, if _CRT_SECURE_NO_WARNINGS is defined in the command line options, the compiler complains that _CRT_SECURE_NO_WARNINGS is redefined in luaconf.h.  If _CRT_SECURE_NO_WARNINGS is not defined on the command line, the compiler complains that 'getenv' is unsafe because it is referenced in stdlib.h which is included before luaconf.h.

lobject.c, line 321.  Change:
   buff[UTF8BUFFSZ - (n++)] = 0x80 | (x & 0x3f);  /* add continuation byte */
To:
   buff[UTF8BUFFSZ - (n++)] = (char)(0x80 | (x & 0x3f));  /* add continuation byte */
Explanation:  Prevents compiler warning about possible loss of data.

lstrlib.c, line 1139.  Change:
   buff[islittle ? i : size - 1 - i] = (n & MC);
To:
   buff[islittle ? i : size - 1 - i] = (char)(n & MC);
Explanation:  Prevents compiler warning about possible loss of data.

lstrlib.c, line 1142.  Change:
   buff[islittle ? i : size - 1 - i] = (n & MC);
To:
   buff[islittle ? i : size - 1 - i] = (char)(n & MC);
Explanation:  Prevents compiler warning about possible loss of data.

--EN

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Luiz Henrique de Figueiredo
Sent: Thursday, 23 October, 2014 08:47
To: Lua mailing list
Subject: Re: [ANN] Lua 5.3.0 (beta) now available

> After this beta will the next release be the final version?

Yes. But it will go through a cycle of release candidates to remove any remaining glitches.

Now is the time to remind us of any glitches you have found in Lua 5.2 or to report new ones in both 5.2 and 5.3. In particular, problems in the Makefiles and in the documentation.


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.3.0 (beta) now available

Alexander Nasonov
In reply to this post by Luiz Henrique de Figueiredo
Luiz Henrique de Figueiredo wrote:
> > You already have a bunch of make targets. Would you accept one more
> > "c99" target?
>
> You can do it right now with
> make generic SYSCFLAGS="-LUA_USE_C99"
> or
> make generic SYSCFLAGS="-LUA_USE_C99 -std=c99"

This works (because -L is a valid gcc option) but I think the correct
option is -DLUA_USE_C99.

  make generic SYSCFLAGS="-DLUA_USE_C99"
 or
  make generic SYSCFLAGS="-DLUA_USE_C99 -std=c99"

Alex

12345