[ANN] Lua 5.3.0 (work1) now available

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

[ANN] Lua 5.3.0 (work1) now available

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

MD5 d4053ee55741eab5ecd7061326577586  -
SHA1 ce71e80a24d1232f42d3afbdc1b034b0877f532b  -

This is a work version. An updated reference manual is included but
all details may change in the final version.

The main change in Lua 5.3.0 is support for integers.

The complete diffs from Lua 5.2 are too extensive to show.

All feedback welcome. Thanks.
--lhf

Reply | Threaded
Open this post in threaded view
|

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

Craig Barnes
Here's a convenient diff against 5.2.2 for anyone who may find it useful:

  https://github.com/lua/lua/commit/950db94fc42fd6fa9186c0aa9410a0f721504112

Reply | Threaded
Open this post in threaded view
|

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

D Burgess-4
In reply to this post by Luiz Henrique de Figueiredo
On 32 bit ARM, 64bit int is v. slow.

#define LUA_INTSIZE 1
#define LUA_FLOATSIZE 2

Has this been tried?

Reply | Threaded
Open this post in threaded view
|

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

Miles Bader-2
In reply to this post by Luiz Henrique de Figueiredo
Luiz Henrique de Figueiredo <[hidden email]> writes:
> The main change in Lua 5.3.0 is support for integers.

Does the integer representation require something special to use, or is
used automatically for any number that happens to be an integer?

Also, does the integer support need any special build-time flag/option
to enable?

Thanks,

-miles

--
Опять нет повода не выпить

Reply | Threaded
Open this post in threaded view
|

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

Miles Bader-2
In reply to this post by Luiz Henrique de Figueiredo
btw, LPeg (version 0.11) doesn't seem to compile with Lua 5.3 work 1...

I get errors like:

   $ gcc -DHAVE_CONFIG_H -I.  -I/usr/include/libpng12 -Wall   -pthread -I/usr/include/OpenEXR      -I/usr/local/src/lua-5.3.0-work1/src  -O3 -fomit-frame-pointer -flto -ffast-math -march=native -mfpmath=sse -g  -fno-finite-math-only -ftrapping-math -fno-associative-math -ffunction-sections -pthread  -MT lptree.o -MD -MP -MF .deps/lptree.Tpo -c -o lptree.o lptree.c
   lptree.c: In function ‘getsize’:
   lptree.c:156:3: warning: implicit declaration of function ‘lua_objlen’ [-Wimplicit-function-declaration]
      return (lua_objlen(L, idx) - sizeof(Pattern)) / sizeof(TTree) + 1;
      ^
   lptree.c: In function ‘addtoktable’:
   lptree.c:216:5: warning: implicit declaration of function ‘lua_getfenv’ [-Wimplicit-function-declaration]
        lua_getfenv(L, -1);  /* get ktable from pattern */
        ^
   ...etc...
   lptree.c:328: error: undefined reference to 'lua_objlen'
   lptree.c:328: error: undefined reference to 'lua_objlen'
   lptree.c:1033: error: undefined reference to 'lua_getfenv'
   lptree.c:1223: error: undefined reference to 'luaL_register'
   lptree.c:1224: error: undefined reference to 'luaL_register'
   lptree.c:216: error: undefined reference to 'lua_getfenv'
   lptree.c:217: error: undefined reference to 'lua_objlen'
   lptree.c:224: error: undefined reference to 'lua_setfenv'
   ...etc...

Thanks,

-miles

--
Politeness, n. The most acceptable hypocrisy.

Reply | Threaded
Open this post in threaded view
|

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

D Burgess-4
In reply to this post by Luiz Henrique de Figueiredo
Compiling with no changes on 32bit Debian armhf gives:

gcc -O2 -Wall -Wextra -DLUA_COMPAT_ALL -DLUA_USE_LINUX -c -o luac.o luac.c
luac.c: In function 'PrintConstant':
luac.c:265:2: warning: format '%g' expects argument of type 'double',
but argument 2 has type 'int' [-Wformat]

On Sat, Jul 6, 2013 at 12:22 PM, Luiz Henrique de Figueiredo
<[hidden email]> wrote:

> Lua 5.3.0 (work1) is now available for testing at
>         http://www.lua.org/work/lua-5.3.0-work1.tar.gz
>
> MD5     d4053ee55741eab5ecd7061326577586  -
> SHA1    ce71e80a24d1232f42d3afbdc1b034b0877f532b  -
>
> This is a work version. An updated reference manual is included but
> all details may change in the final version.
>
> The main change in Lua 5.3.0 is support for integers.
>
> The complete diffs from Lua 5.2 are too extensive to show.
>
> All feedback welcome. Thanks.
> --lhf
>



--
David Burgess

Reply | Threaded
Open this post in threaded view
|

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

liam mail
In reply to this post by Luiz Henrique de Figueiredo



On 6 July 2013 03:22, Luiz Henrique de Figueiredo <[hidden email]> wrote:
Lua 5.3.0 (work1) is now available for testing at
        http://www.lua.org/work/lua-5.3.0-work1.tar.gz

MD5     d4053ee55741eab5ecd7061326577586  -
SHA1    ce71e80a24d1232f42d3afbdc1b034b0877f532b  -

This is a work version. An updated reference manual is included but
all details may change in the final version.

The main change in Lua 5.3.0 is support for integers.

The complete diffs from Lua 5.2 are too extensive to show.

All feedback welcome. Thanks.
--lhf





"In case of overflows in integer arithmetic, all operations wrap around, according to the usual rules of two-complement arithmetic." 

Usual rules of two complement arithmetic? Would some care to explain as in C signed ints do not wrap.

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

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

Rob Hoelz-2
In reply to this post by Luiz Henrique de Figueiredo
On Fri, 5 Jul 2013 23:22:15 -0300
Luiz Henrique de Figueiredo <[hidden email]> wrote:

> Lua 5.3.0 (work1) is now available for testing at
> http://www.lua.org/work/lua-5.3.0-work1.tar.gz
>
> MD5 d4053ee55741eab5ecd7061326577586  -
> SHA1 ce71e80a24d1232f42d3afbdc1b034b0877f532b  -
>
> This is a work version. An updated reference manual is included but
> all details may change in the final version.
>
> The main change in Lua 5.3.0 is support for integers.
>
> The complete diffs from Lua 5.2 are too extensive to show.
>
> All feedback welcome. Thanks.
> --lhf
>
This is minor, but the Changes section in readme.html says "Changes
since Lua 5.1" rather than 5.2.

-Rob

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Miles Bader-2
In reply to this post by liam mail
liam mail <[hidden email]> writes:
> "In case of overflows in integer arithmetic, all operations wrap around,
> according to the usual rules of two-complement arithmetic."
>
> Usual rules of two complement arithmetic? Would some care to explain as in
> C signed ints do not wrap.

Well to be fair, it doesn't say "C signed ints," and the behavior of
twos-complement signed values are clear enough...

-miles

--
People who are more than casually interested in computers should have at
least some idea of what the underlying hardware is like.  Otherwise the
programs they write will be pretty weird.  -- Donald Knuth

Reply | Threaded
Open this post in threaded view
|

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

liam mail



On 6 July 2013 09:38, Miles Bader <[hidden email]> wrote:
liam mail <[hidden email]> writes:
> "In case of overflows in integer arithmetic, all operations wrap around,
> according to the usual rules of two-complement arithmetic."
>
> Usual rules of two complement arithmetic? Would some care to explain as in
> C signed ints do not wrap.

Well to be fair, it doesn't say "C signed ints," and the behavior of
twos-complement signed values are clear enough...

-miles

--
People who are more than casually interested in computers should have at
least some idea of what the underlying hardware is like.  Otherwise the
programs they write will be pretty weird.  -- Donald Knuth


Erm thanks Miles.
The code is written in C so this is why I am asking what the usual rules are as that specific operation in C is undefined, hence it is not normal. So if you would not mind explaining what the normal operation is and point me to where Lua's C code detects this illegal overflow and prevents it before the undefined behaviour happens that would be so kind and more constructive.

--Liam



Reply | Threaded
Open this post in threaded view
|

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

Miles Bader-2
liam mail <[hidden email]> writes:
> The code is written in C so this is why I am asking what the usual rules
> are as that specific operation in C is undefined, hence it is not normal.

I haven't looked at the implementation, but I suppose it may simply
use C unsigned values to represent integers, or when doing arithmetic
on them ...

-miles

--
「寒いね」と話しかければ「寒いね」と答える人のいるあったかさ [俵万智]
Reply | Threaded
Open this post in threaded view
|

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

Ico Doornekamp
In reply to this post by Luiz Henrique de Figueiredo
* On Sat Jul 06 04:22:15 +0200 2013, Luiz Henrique de Figueiredo wrote:
 
> Lua 5.3.0 (work1) is now available for testing at
>     http://www.lua.org/work/lua-5.3.0-work1.tar.gz
>
> All feedback welcome. Thanks.

compiling to mingw on debian:

$ make generic CC=i586-mingw32msvc-gcc
[...]
i586-mingw32msvc-gcc -O2 -Wall -Wextra -DLUA_COMPAT_ALL     -c -o lvm.o lvm.c
lvm.c: In function ‘luaV_tostring’:
lvm.c:57:7: warning: unknown conversion type character ‘l’ in format [-Wformat]
lvm.c:57:7: warning: too many arguments for format [-Wformat-extra-args]
[...]
i586-mingw32msvc-gcc -O2 -Wall -Wextra -DLUA_COMPAT_ALL     -c -o liolib.o liolib.c
liolib.c: In function ‘read_integer’:
liolib.c:352:3: warning: unknown conversion type character ‘l’ in format [-Wformat]
liolib.c:352:3: warning: too many arguments for format [-Wformat-extra-args]
liolib.c: In function ‘g_write’:
liolib.c:537:17: warning: unknown conversion type character ‘l’ in format [-Wformat]
liolib.c:537:17: warning: too many arguments for format [-Wformat-extra-args]

--
:wq
^X^Cy^K^X^C^C^C^C

Reply | Threaded
Open this post in threaded view
|

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

Luiz Henrique de Figueiredo
In reply to this post by D Burgess-4
> gcc -O2 -Wall -Wextra -DLUA_COMPAT_ALL -DLUA_USE_LINUX -c -o luac.o luac.c
> luac.c: In function 'PrintConstant':
> luac.c:265:2: warning: format '%g' expects argument of type 'double',
> but argument 2 has type 'int' [-Wformat]

luac is not ready yet. Sorry about that.  string.dump should work fine.

Reply | Threaded
Open this post in threaded view
|

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

Luiz Henrique de Figueiredo
In reply to this post by Rob Hoelz-2
> This is minor, but the Changes section in readme.html says "Changes
> since Lua 5.1" rather than 5.2.

This section and the one on incompatibilities in the manual still need
to be updated. Sorry about that.

Reply | Threaded
Open this post in threaded view
|

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

Luiz Henrique de Figueiredo
In reply to this post by Miles Bader-2
> btw, LPeg (version 0.11) doesn't seem to compile with Lua 5.3 work 1...

I've tried LPeg 0.12 (which is the last one) and only had to change this
line:

lptypes.h:
< #if (LUA_VERSION_NUM == 502)
> #if (LUA_VERSION_NUM >= 502)

Reply | Threaded
Open this post in threaded view
|

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

Luiz Henrique de Figueiredo
In reply to this post by Miles Bader-2
> Does the integer representation require something special to use, or is
> used automatically for any number that happens to be an integer?

The lexer decides which type of number a numeric value is.
So 123 is an integer and 123.0 is a real.

All operations on values of the same type give values of that type,
except that division always gives a real. There is a new integer
division operation, denoted by //.

So 13/4 gives 3.25 and 13//4 gives 3. Also, 12/4 gives 3.0 and 12//4 gives 3.

> Also, does the integer support need any special build-time flag/option
> to enable?

No. And it cannot be disabled either.

Reply | Threaded
Open this post in threaded view
|

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

D Burgess-4
I have tried 32 bit  int and double. No bugs found (yet).

On Sat, Jul 6, 2013 at 11:10 PM, Luiz Henrique de Figueiredo
<[hidden email]> wrote:

>> Does the integer representation require something special to use, or is
>> used automatically for any number that happens to be an integer?
>
> The lexer decides which type of number a numeric value is.
> So 123 is an integer and 123.0 is a real.
>
> All operations on values of the same type give values of that type,
> except that division always gives a real. There is a new integer
> division operation, denoted by //.
>
> So 13/4 gives 3.25 and 13//4 gives 3. Also, 12/4 gives 3.0 and 12//4 gives 3.
>
>> Also, does the integer support need any special build-time flag/option
>> to enable?
>
> No. And it cannot be disabled either.
>



--
David Burgess

Reply | Threaded
Open this post in threaded view
|

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

Mark Gabby
In reply to this post by Luiz Henrique de Figueiredo

> Luiz Henrique de Figueiredo wrote:
> Lua 5.3.0 (work1) is now available for testing

Builds fine on Gentoo x64.

Integers work transparently and elegantly, just what I'd expect from Lua.

Thanks for building Lua and continuing to improve it! Still my favorite programming language.

Reply | Threaded
Open this post in threaded view
|

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

Enrico Colombini
In reply to this post by Luiz Henrique de Figueiredo
On 06/07/2013 15.10, Luiz Henrique de Figueiredo wrote:
> So 13/4 gives 3.25 and 13//4 gives 3. Also, 12/4 gives 3.0 and 12//4 gives 3.
>
>> >Also, does the integer support need any special build-time flag/option
>> >to enable?
> No. And it cannot be disabled either.

So, for best efficiency, I guess programmers will have to be careful to
avoid unnecessary int -> fp conversions (assuming they are slow on
64-bit machines... I'm not really up to date).

Suppose I read a large number of values (some integer, some not) from a
text file into a table and then perform extensive computations on them.
Should I multiply each value by 1.0 (or add 0.0), to pre-convert all of
them to fp, to avoid slowing down the following computations compared to
Lua 5.2?

A doubt: does math.floor return an fp value or an integer?
(the manual could be interpreted as the latter)

Lastly, I see no bit64 ops in the manual; will they come?

[I may have missed most of the discussion leading to integer support; I
apologize if this has already been discussed]

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

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

Jay Carlson
In reply to this post by liam mail
On Jul 6, 2013, at 4:59 AM, liam mail wrote:

> On 6 July 2013 09:38, Miles Bader <[hidden email]> wrote:
> liam mail <[hidden email]> writes:
> > "In case of overflows in integer arithmetic, all operations wrap around,
> > according to the usual rules of two-complement arithmetic."
> >
> > Usual rules of two complement arithmetic? Would some care to explain as in
> > C signed ints do not wrap.

Worse: signed int overflow results in undefined behavior, and ever since the Morris Worm we are all-too-familiar with how broad C's "undefined behavior" is.

> Well to be fair, it doesn't say "C signed ints," and the behavior of
> twos-complement signed values are clear enough...
>
> People who are more than casually interested in computers should have at
> least some idea of what the underlying hardware is like.  Otherwise the
> programs they write will be pretty weird.  -- Donald Knuth

They should have at least some knowledge of what the compiler is like too. In this case, the compiler has license to assume programs do not overflow and the compiler may produce optimizations with that knowledge.

I don't think gcc will "mis-compile" the core Lua VM in this case; the examples I know of involve partial evaluation.

> The code is written in C so this is why I am asking what the usual rules are as that specific operation in C is undefined, hence it is not normal. So if you would not mind explaining what the normal operation is and point me to where Lua's C code detects this illegal overflow and prevents it before the undefined behaviour happens that would be so kind and more constructive.

Let's back up a minute. Who actually *wants* the two's-complement overflow behavior? There are some bit-twiddling algorithms which depend on it, but Lua bit-twiddling is shunted off into a separate module.

At the assembly level, there is pressure for addition of MAX_INT and 1 to result in *some* deterministic bit pattern in the destination register. But we're about three layers of abstraction up from that. On target hardware without hardware floating point, going from softfp to some kind of int is a huge speedup, and explicit int overflow checks are likely to be tiny in comparison. My intuition is that VM costs will swamp the cost of checks (certainly on MIPS). If the cost of detecting signed integer overflow is acceptable, we can choose the behavior we want. And "wraps to negative" just seems much worse for Lua programs than "cast to nearest double" or exception-raising.

Jay
1234 ... 11