# [ANN] Lua 5.3.0 (work2) now available

261 messages
12345 ... 14
Open this post in threaded view
|

## Re: [ANN] Lua 5.3.0 (work2) now available

 >> There is no direct conversion from strings to integers: >> If a string is provided where an integer is needed, >> Lua converts the string to a float and then the float to an integer. Does it mean the following:assert('100000000000000001'%2 == 0)It looks unnaturally for a language having 64-bit integers as native datatype.>> Integer division (//) converts its operands to integers Does it mean the following:assert(4.5//1.5 == 4)I was expecting 3 as the result of 4.5//1.5
Open this post in threaded view
|

## Re: [ANN] Lua 5.3.0 (work2) now available

 On 22/03/2014 14.09, Egor Skriptunoff wrote: > Does it mean the following: > assert(4.5//1.5 == 4) > I was expecting 3 as the result of 4.5//1.5 At first glance, yes. But that would be a fp division followed by rounding to the nearest integer, which would defeat the purpose of integer division. --    Enrico
Open this post in threaded view
|

## Re: [ANN] Lua 5.3.0 (work2) now available

 In message <[hidden email]>           Enrico Colombini <[hidden email]> wrote: > On 22/03/2014 14.09, Egor Skriptunoff wrote: >> Does it mean the following: >> assert(4.5//1.5 == 4) >> I was expecting 3 as the result of 4.5//1.5 > At first glance, yes. But that would be a fp division followed by > rounding to the nearest integer, which would defeat the purpose of > integer division. I still regard coercions between number types as evil. "O Lord give us strong typing, but not yet" seems to be the message. -- Gavin Wraith
Open this post in threaded view
|

## Re: [ANN] Lua 5.3.0 (work2) now available

 On 22/03/2014 15.38, Gavin Wraith wrote: > I still regard coercions between number types as evil. > "O Lord give us strong typing, but not yet" seems to be the > message. Perhaps so. I admit I have not given much thought to the new fp/int dualism. --    Enrico
Open this post in threaded view
|

## Re: [ANN] Lua 5.3.0 (work2) now available

 In reply to this post by Luiz Henrique de Figueiredo On 22/03/2014 4.44, Luiz Henrique de Figueiredo wrote: > Tests for this version are available at > http://www.lua.org/work/lua-5.3.w2-tests.tar.gzI compiled Lua 5.3w2 with a relatively old version of Code::Blocks (GCC) under Windows XP SP3 on a Pentium 4 HT. The interpreter seems to run fine; it doesn't seem to break any of my recent programs I tested. Out of curiosity, I tried running the 'pure Lua' tests (I'll try them under CentOS Linux later). Not all tests work under Windows, I presume by design (more on this after the Linux tests) but I suppose strings.lua should. It fails the assert at line 118:    assert(tostring(-0.0) == "-0.0") which, in fact, also fails in interactive mode (it also fails in Lua 5.1 and 5.2, in case it may be relevant). --    Enrico
Open this post in threaded view
|

## Lua 5.3.0 tests (was: [ANN] Lua 5.3.0 (work2) now available)

 Update:    assert(tostring(-0.0) == "-0.0") fails under Windows, passes under Linux (CentOS 6 in a VM). --- By the way, here is a problem in running some of the tests under Windows. I know they are not designed to be portable, but it could be useful to run as many as possible of them in future pre-release tests (perhaps with a 'make windows' option?): os.tmpname() cannot be used directly under Windows because the filename returned is of the type "\s160.", i.e. it is in the root directory instead of the %TEMP% directory of the current user. It works anyway if the user is administrator, which (thankfully!) is not usually the case with recent versions of Windows. (I first encountered this problem with a large perl program that behaved strangely; it took some time to root out the actual cause) --    Enrico
Open this post in threaded view
|

## Re: Lua 5.3.0 tests

 For completeness, the remaining errors of the 'pure lua' tests under my Windows: -------------------------------------  >Lua53w2.exe files.lua 'os.tmpname' file cannot be open; skipping file tests + ..\..\Lua53w2\bin\Debug\Lua53w2.exe: files.lua:590: bad argument #1 to 'date' (i nvalid conversion specifier '%Ex') stack traceback:          [C]: in function 'date'          files.lua:590: in main chunk          [C]: in ? [I guess date specifiers are incompatible] -------------------------------------  >Lua53w2.exe attrib.lua testing require package config: \|;|?|!|-| + ..\..\Lua53w2\bin\Debug\Lua53w2.exe: attrib.lua:103: assertion failed! stack traceback:          [C]: in function 'assert'          attrib.lua:103: in main chunk          [C]: in ? -------------------------------------  >Lua53w2.exe big.lua testing large tables ..\..\Lua53w2\bin\Debug\Lua53w2.exe: attempt to yield from outside a coroutine stack traceback:          [C]: in function 'yield'          big.lua:53: in main chunk          [C]: in ? ------------------------------------- (no unexpected errors under CentOS 6) --    Enrico
Open this post in threaded view
|

## Re: Lua 5.3.0 tests

 Lastly, how do I enable the API tests? Should I recompile the interpreter including ltests.c? --    Enrico
Open this post in threaded view
|

## Re: [ANN] Lua 5.3.0 (work2) now available

 In reply to this post by Xavier Wang > lua_get* and lua_rawget* functions has return values!!! thanks for that!! > > btw, the function lua_getfield and lua_getuservalue doesn't have return > value, yet. lua_getfield is the most useful function in my coding (though > maybe it's slow a bit), and now userdata can have any type of lua value for > its uservalue, so lua_getuservalue should return a type, either. lua_getfield does have a return value, like the others. It is the manual that was not updated. -- Roberto
Open this post in threaded view
|

## Re: Lua 5.3.0 tests

 In reply to this post by Enrico Colombini > Lastly, how do I enable the API tests? Should I recompile the > interpreter including ltests.c? Yes; have a look at [1]. Most of what is written there is valid for 5.3. (BTW, did your other problems when testing Lua in Windows was with _U=1?) [1] http://www.lua.org/tests/5.2/-- Roberto
Open this post in threaded view
|

## Re: [ANN] Lua 5.3.0 (work2) now available

 In reply to this post by Philipp Janda > The precedence of the new bitwise operators is not yet documented in 3.4.8. Thanks for the report; we will correct that. For the record, the precedence is this: or and <     >     <=    >=    ~=    == | ~ & <<    >> .. +     - *     /     //    % not   #     - (unary)  ~ (unary) ^ -- Roberto
Open this post in threaded view
|

## Re: [ANN] Lua 5.3.0 (work2) now available

 In reply to this post by Enrico Colombini > Not all tests work under Windows, I presume by design (more on this > after the Linux tests) but I suppose strings.lua should. It fails > the assert at line 118: > >   assert(tostring(-0.0) == "-0.0") It passed in "my Windows" (Windows 7-32, VS 2010).  This can be a bug in libc. Can you test it in C code? /* untested */ #include int main (void) {   double d = -0.0;   printf("%.14g\n", d);   return 0; } -- Roberto
Open this post in threaded view
|

## Re: Lua 5.3.0 tests (was: [ANN] Lua 5.3.0 (work2) now available)

 In reply to this post by Enrico Colombini > os.tmpname() cannot be used directly under Windows because the > filename returned is of the type "\s160.", i.e. it is in the root > directory instead of the %TEMP% directory of the current user. > It works anyway if the user is administrator, which (thankfully!) is > not usually the case with recent versions of Windows. Are you running the tests with the option -e _U=1 ? -- Roberto
Open this post in threaded view
|

## Re: [ANN] Lua 5.3.0 (work2) now available

 In reply to this post by Egor Skriptunoff-2 > >> There is no direct conversion from strings to integers: > >> If a string is provided where an integer is needed, > >> Lua converts the string to a float and then the float to an integer. > Does it mean the following: > assert('100000000000000001'%2 == 0) Yes. > It looks unnaturally for a language having 64-bit integers as native > datatype. Coercion from strings to numbers are considered a bad thing, and can (should?) be removed in future versions. It did not seem worth to extend to the new integer stuff something already outdate. (Ideally it should raise an error, but that would create all sorts of incompatibilities.) In other words, it is unnatural, but the whole coercion stuff is unnatural. -- Roberto
Open this post in threaded view
|

## Re: Lua 5.3.0 tests

 In reply to this post by Roberto Ierusalimschy On 22/03/2014 18.57, Roberto Ierusalimschy wrote: > Are you running the tests with the option -e _U=1 ? Now I am, most of the errors went away (sorry for the noise). I am still getting the assertion in string.lua:118, though: tostring(-0.0) gives "0.0" --    Enrico
Open this post in threaded view
|

## Re: [ANN] Lua 5.3.0 (work2) now available

 In reply to this post by Roberto Ierusalimschy On 22/03/2014 18.54, Roberto Ierusalimschy wrote: > It passed in "my Windows" (Windows 7-32, VS 2010).  This can be a bug in > libc. Can you test it in C code? > > /* untested */ > #include > > int main (void) { >    double d = -0.0; >    printf("%.14g\n", d); >    return 0; > } It prints 0, which I suppose it's wrong. This uses the old msvcrt.dll (I don't have a Microsoft C++ compiler installed). --    Enrico
Open this post in threaded view
|

## Re: [ANN] Lua 5.3.0 (work2) now available

 In reply to this post by Xavier Wang > build Lua 5.3.0 work2 with gcc -O3 -Wall produce this warning: > > gcc -O3 -Wall -Wextra -DLUA_COMPAT_ALL -DLUA_BUILD_AS_DLL    -c -o lvm.o > lvm.c > lvm.c: In function 'luaV_equalobj': > lvm.c:223:22: warning: 'n2' may be used uninitialized in this function > [-Wmaybe-uninitialized] >        lua_Number n1, n2; >                       ^ > In file included from lua.h:16:0, >                  from lvm.c:16: > luaconf.h:511:30: warning: 'n1' may be used uninitialized in this function > [-Wmaybe-uninitialized] >  #define luai_numeq(a,b)  ((a)==(b)) >                               ^ > lvm.c:223:18: note: 'n1' was declared here >        lua_Number n1, n2; >                   ^ > > Is that worth to fix? (-O3 is unsafe optimize?) I hate these compilers that try to be smart but are not smart enough. (OK, it would need a small theorem prover, but we people can see that 'n2' cannot be used uninitialized without much ado...) Can someone suggest a reasonable way to "fix" it without making the code uglier and/or generating useless code? (It seems to me that anything that makes the compiler believes that 'n2' will not be used uninitialized will make readers believe that it could be used uninitialized otherwise, which is wrong.) -- Roberto
Open this post in threaded view
|

## Re: [ANN] Lua 5.3.0 (work2) now available

 In reply to this post by Coroutines > I think I'll take the utf8.strip() proposal back -- it looks like this > utf8 library doesn't check that strings are valid utf8.  It makes sure > the byte sequence fits the form of a utf8 codepoint, but it doesn't > take into account things like unused codepoints or overlong encodings. Some functions do check for invalid encodings. See the documentation. -- Roberto
Open this post in threaded view
|

## Re: [ANN] Lua 5.3.0 (work2) now available

 In reply to this post by Enrico Colombini > On 22/03/2014 18.54, Roberto Ierusalimschy wrote: > >It passed in "my Windows" (Windows 7-32, VS 2010).  This can be a bug in > >libc. Can you test it in C code? > > > >/* untested */ > >#include > > > >int main (void) { > >   double d = -0.0; > >   printf("%.14g\n", d); > >   return 0; > >} > > It prints 0, which I suppose it's wrong. This uses the old > msvcrt.dll (I don't have a Microsoft C++ compiler installed). It is wrong. (That is the reason we do not distribute the tests together with Lua. It usually finds more bugs out of Lua than in Lua...) -- Roberto