[ANN] Lua 5.3.0 (work2) now available

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

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

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)
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

Reply | Threaded
Open this post in threaded view
|

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

Enrico Colombini
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

Reply | Threaded
Open this post in threaded view
|

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

Gavin Wraith
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

Reply | Threaded
Open this post in threaded view
|

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

Enrico Colombini
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

Reply | Threaded
Open this post in threaded view
|

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

Enrico Colombini
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.gz

I 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

Reply | Threaded
Open this post in threaded view
|

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

Enrico Colombini
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

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3.0 tests

Enrico Colombini
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

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3.0 tests

Enrico Colombini
Lastly, how do I enable the API tests? Should I recompile the
interpreter including ltests.c?

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
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

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3.0 tests

Roberto Ierusalimschy
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

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
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

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
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 <stdio.h>

int main (void) {
  double d = -0.0;
  printf("%.14g\n", d);
  return 0;
}

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
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

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
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

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3.0 tests

Enrico Colombini
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

Reply | Threaded
Open this post in threaded view
|

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

Enrico Colombini
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 <stdio.h>
>
> 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

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
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

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
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

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
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 <stdio.h>
> >
> >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

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
In reply to this post by Jay Carlson
> string.format uses a little language for constructing strings out of
> numbers and other strings, primarily in variable-length decimal encoding. I
> think a very similar language could be designed for constructing strings
> out of numbers and other strings in the domain of fixed-size binary
> encoding.
>
> Aside from symmetry, my motivation is premature optimization. string.pack
> written in Lua would have the same problems as string.format written in
> Lua: as formatting is executed, short strings will be created, pushed on a
> Lua-side concat table, then turned into garbage. Easier and faster to do
> this at the C level where string building is cheaper.

You still can use external libraries for that (e.g., struct and lpack).
We thought that this basic functionallity was a good trade-off beween
usefuleness and simplicity for the standard library. (Thanks to
Daurnimator for the suggestion.)

-- Roberto

12345 ... 14