[ANN] Lua 5.3.0 (rc2) now available

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[ANN] Lua 5.3.0 (rc2) now available

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

MD5 61726271cf342794909a1752ea0c0aae  -
SHA1 457be7b889f7825c3b9c8b9a4b95b85c0c0b434d  -

This is a release candidate for the final release of Lua 5.3.0.

A few things have changed since beta that we'd like to test in the wild.
In particular, we made some changes in luaconf.h and in the Makefile
that we'd like to test. Please try compiling the current code in as many
platforms as possible. We expect the compilation will go smoothly as usual
but please report any warnings or other glitches.

We'd also like feedback on the documentation:
        http://www.lua.org/work/doc/readme.html
        http://www.lua.org/work/doc/contents.html
        http://www.lua.org/work/doc/manual.html

Finally, for those of you into this, please test luac -l -l on your
scripts, just to make sure we haven't missed anything with the new
VM instructions etc.

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

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

An updated test suite is available at
        http://www.lua.org/work/lua-5.3.0-rc2-tests.tar.gz

All feedback welcome. Thanks.
--lhf


Reply | Threaded
Open this post in threaded view
|

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

Ignacio Burgueño-2
Using Thijs's build script (winmake), it compiles without warnings with VS 2008, VS 2010, VS 2012 and VS 2013 (all of them as 32 bits), with vanilla luaconf.h

Reply | Threaded
Open this post in threaded view
|

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

Ignacio Burgueño-2
Also ran lua -e"_U=true" all.lua on all variations. All tests passed.

On Mon, Dec 22, 2014 at 12:47 PM, Ignacio Burgueño <[hidden email]> wrote:
Using Thijs's build script (winmake), it compiles without warnings with VS 2008, VS 2010, VS 2012 and VS 2013 (all of them as 32 bits), with vanilla luaconf.h


Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
> Also ran lua -e"_U=true" all.lua on all variations. All tests passed.
>
> On Mon, Dec 22, 2014 at 12:47 PM, Ignacio Burgueño <[hidden email]>
> wrote:
>
> > Using Thijs's build script (winmake), it compiles without warnings with VS
> > 2008, VS 2010, VS 2012 and VS 2013 (all of them as 32 bits), with vanilla
> > luaconf.h

Many thanks!

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

ForthCAD
In reply to this post by Luiz Henrique de Figueiredo
I compiled and tested with 64 bits executable (VC2010).
There are no more problems here.
Also, Luac seems to work (and '-l -l' displays a nice listing).

Charles
-----Message d'origine-----
De : [hidden email] [mailto:[hidden email]] De la
part de Luiz Henrique de Figueiredo
Envoyé : lundi 22 décembre 2014 15:35
À : [hidden email]
Objet : [ANN] Lua 5.3.0 (rc2) now available

Lua 5.3.0 (rc2) is now available for testing at
        http://www.lua.org/work/lua-5.3.0-rc2.tar.gz

MD5 61726271cf342794909a1752ea0c0aae  -
SHA1 457be7b889f7825c3b9c8b9a4b95b85c0c0b434d  -

This is a release candidate for the final release of Lua 5.3.0.

A few things have changed since beta that we'd like to test in the wild.
In particular, we made some changes in luaconf.h and in the Makefile
that we'd like to test. Please try compiling the current code in as many
platforms as possible. We expect the compilation will go smoothly as usual
but please report any warnings or other glitches.

We'd also like feedback on the documentation:
        http://www.lua.org/work/doc/readme.html
        http://www.lua.org/work/doc/contents.html
        http://www.lua.org/work/doc/manual.html

Finally, for those of you into this, please test luac -l -l on your
scripts, just to make sure we haven't missed anything with the new
VM instructions etc.

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

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

An updated test suite is available at
        http://www.lua.org/work/lua-5.3.0-rc2-tests.tar.gz

All feedback welcome. Thanks.
--lhf



Reply | Threaded
Open this post in threaded view
|

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

ardente
In reply to this post by Luiz Henrique de Figueiredo
Warnings from vs 2013 community eidtion with amost all warnings turned on. Compiled source from lua-5.3.0-rc2.tar.gz

Compilation for win32 dll.
Command line options:
/GS /GL /analyze- /Wall /wd"4711" /wd"4820" /Gy /Zc:wchar_t /Gm- /Ox /Ob2 /Fd"C:\work\lua\int\luadll\Release\x86\vc120.pdb" /fp:precise /D "LUA_COMPAT_ALL" /D "_CRT_SECURE_NO_WARNINGS" /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_USRDLL" /D "LUA_BUILD_AS_DLL" /D "_WINDLL" /D "_MBCS" /errorReport:prompt /WX- /Zc:forScope /Gd /Oy /Oi /MD /Fa"C:\work\lua\int\luadll\Release\x86\" /EHsc /nologo /Fo"C:\work\lua\int\luadll\Release\x86\" /Ot /Fp"C:\work\lua\int\luadll\Release\x86\lua53.pch"

Warnigns:
lapi.c(863): warning C4242: '=' : conversion from 'const int' to 'lu_byte', possible loss of data
lapi.c(1052): warning C4242: '=' : conversion from 'int' to 'lu_byte', possible loss of data
lauxlib.c(614): warning C4242: '=' : conversion from 'int' to 'char', possible loss of data
lauxlib.c(664): warning C4242: '=' : conversion from 'int' to 'char', possible loss of data
lcode.c(298): warning C4242: '+=' : conversion from 'int' to 'lu_byte', possible loss of data
lcode.c(752): warning C4242: '=' : conversion from 'int' to 'lu_byte', possible loss of data
lcode.c(753): warning C4242: '=' : conversion from 'int' to 'short', possible loss of data
lcode.c(765): warning C4127: conditional expression is constant
lcode.c(966): warning C4244: '=' : conversion from 'int' to 'lu_byte', possible loss of data
ldo.c(328): warning C4242: '=' : conversion from 'int' to 'short', possible loss of data
ldo.c(359): warning C4242: '=' : conversion from 'int' to 'short', possible loss of data
ldo.c(594): warning C4242: '=' : conversion from 'int' to 'unsigned short', possible loss of data
lgc.c(202): warning C4242: '=' : conversion from 'int' to 'lu_byte', possible loss of data
lgc.c(806): warning C4242: '=' : conversion from 'int' to 'lu_byte', possible loss of data
lgc.c(1021): warning C4242: '=' : conversion from 'int' to 'lu_byte', possible loss of data
liolib.c(385): warning C4242: '=' : conversion from 'int' to 'char', possible loss of data
liolib.c(474): warning C4242: '=' : conversion from 'int' to 'char', possible loss of data
liolib.c(481): warning C4242: '=' : conversion from 'int' to 'char', possible loss of data
llex.c(60): warning C4310: cast truncates constant value
lparser.c(437): warning C4242: '=' : conversion from 'int' to 'short', possible loss of data
lparser.c(438): warning C4242: '=' : conversion from 'int' to 'short', possible loss of data
lparser.c(657): warning C4242: '=' : conversion from 'int' to 'lu_byte', possible loss of data
lparser.c(851): warning C4244: '=' : conversion from 'int' to 'lu_byte', possible loss of data
lparser.c(1123): warning C4242: '=' : conversion from 'int' to 'lu_byte', possible loss of data
lparser.c(1128): warning C4242: '=' : conversion from 'int' to 'short', possible loss of data
lparser.c(1161): warning C4244: '-=' : conversion from 'int' to 'lu_byte', possible loss of data
lstring.c(155): warning C4310: cast truncates constant value
lstring.c(173): warning C4310: cast truncates constant value
lstring.c(179): warning C4242: '=' : conversion from 'const int' to 'lu_byte', possible loss of data
lstrlib.c(98): warning C4242: '=' : conversion from 'int' to 'char', possible loss of data
lstrlib.c(111): warning C4242: '=' : conversion from 'int' to 'char', possible loss of data
lstrlib.c(1155): warning C4310: cast truncates constant value
lvm.c(381): warning C4310: cast truncates constant value
lapi.c(1090): warning C4702: unreachable code
loslib.c(222): warning C4702: unreachable code

Compilation for win64 dll.
Command line options:
/GS /GL /Wall /wd"4711" /wd"4820" /Gy /Zc:wchar_t /Gm- /Ox /Ob2 /Fd"C:\work\lua\int\luadll\Release\x64\vc120.pdb" /fp:precise /D "LUA_COMPAT_ALL" /D "LUA_BUILD_AS_DLL" /D "_CRT_SECURE_NO_WARNINGS" /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_USRDLL" /D "LUADLL_EXPORTS" /D "_WINDLL" /D "_MBCS" /errorReport:prompt /WX- /Zc:forScope /Gd /Oy /Oi /MD /Fa"C:\work\lua\int\luadll\Release\x64\" /EHsc /nologo /Fo"C:\work\lua\int\luadll\Release\x64\" /Ot /Fp"C:\work\lua\int\luadll\Release\x64\lua53.pch" 

Warnings:
lapi.c(863): warning C4242: '=' : conversion from 'const int' to 'lu_byte', possible loss of data
lapi.c(1052): warning C4242: '=' : conversion from 'int' to 'lu_byte', possible loss of data
lauxlib.c(614): warning C4242: '=' : conversion from 'int' to 'char', possible loss of data
lauxlib.c(664): warning C4242: '=' : conversion from 'int' to 'char', possible loss of data
lcode.c(298): warning C4242: '+=' : conversion from 'int' to 'lu_byte', possible loss of data
lcode.c(752): warning C4242: '=' : conversion from 'int' to 'lu_byte', possible loss of data
lcode.c(753): warning C4242: '=' : conversion from 'int' to 'short', possible loss of data
lcode.c(765): warning C4127: conditional expression is constant
lcode.c(966): warning C4244: '=' : conversion from 'int' to 'lu_byte', possible loss of data
ldo.c(328): warning C4242: '=' : conversion from 'int' to 'short', possible loss of data
ldo.c(359): warning C4242: '=' : conversion from 'int' to 'short', possible loss of data
ldo.c(594): warning C4242: '=' : conversion from 'int' to 'unsigned short', possible loss of data
lgc.c(202): warning C4242: '=' : conversion from 'int' to 'lu_byte', possible loss of data
lgc.c(806): warning C4242: '=' : conversion from 'int' to 'lu_byte', possible loss of data
lgc.c(1021): warning C4242: '=' : conversion from 'int' to 'lu_byte', possible loss of data
liolib.c(385): warning C4242: '=' : conversion from 'int' to 'char', possible loss of data
liolib.c(474): warning C4242: '=' : conversion from 'int' to 'char', possible loss of data
liolib.c(481): warning C4242: '=' : conversion from 'int' to 'char', possible loss of data
lparser.c(437): warning C4242: '=' : conversion from 'int' to 'short', possible loss of data
lparser.c(438): warning C4242: '=' : conversion from 'int' to 'short', possible loss of data
lparser.c(657): warning C4242: '=' : conversion from 'int' to 'lu_byte', possible loss of data
lparser.c(851): warning C4244: '=' : conversion from 'int' to 'lu_byte', possible loss of data
lparser.c(1123): warning C4242: '=' : conversion from 'int' to 'lu_byte', possible loss of data
lparser.c(1128): warning C4242: '=' : conversion from 'int' to 'short', possible loss of data
lparser.c(1161): warning C4244: '-=' : conversion from 'int' to 'lu_byte', possible loss of data
lstring.c(179): warning C4242: '=' : conversion from 'const int' to 'lu_byte', possible loss of data
lstrlib.c(98): warning C4242: '=' : conversion from 'int' to 'char', possible loss of data
lstrlib.c(111): warning C4242: '=' : conversion from 'int' to 'char', possible loss of data
lstrlib.c(1155): warning C4310: cast truncates constant value
lapi.c(1090): warning C4702: unreachable code
loslib.c(222): warning C4702: unreachable code


Warnings from Borland C++ 5.5.1 for Windows:

Warning W8004 lapi.c 679: 'mt' is assigned a value that is never used in function lua_getmetatable
Warning W8008 lcode.c 765: Condition is always false in function validop
Warning W8066 lcode.c 765: Unreachable code in function validop
Warning W8057 lobject.c 113: Parameter 'L' is never used in function numarith
Warning W8004 lobject.c 192: 'neg' is assigned a value that is never used in function lua_strx2number
Warning W8072 lstrlib.c 73: Suspicious pointer arithmetic in function str_sub
Warning W8072 lstrlib.c 157: Suspicious pointer arithmetic in function str_byte
Warning W8072 lstrlib.c 599: Suspicious pointer arithmetic in function str_find_aux
Warning W8072 lstrlib.c 608: Suspicious pointer arithmetic in function str_find_aux
Warning W8072 ltable.c 500: Suspicious pointer arithmetic in function luaH_getint
Warning W8065 lua.c 584: Call to function '_isatty' with no prototype in function pmain
Warning W8012 lundump.c 225: Comparing signed and unsigned values in function fchecksize
Warning W8072 lutf8lib.c 81: Suspicious pointer arithmetic in function utflen
Warning W8072 lutf8lib.c 114: Suspicious pointer arithmetic in function codepoint
Warning W8072 lutf8lib.c 115: Suspicious pointer arithmetic in function codepoint
Warning W8072 lutf8lib.c 169: Suspicious pointer arithmetic in function byteoffset
Warning W8072 lutf8lib.c 172: Suspicious pointer arithmetic in function byteoffset
Warning W8072 lutf8lib.c 178: Suspicious pointer arithmetic in function byteoffset
Warning W8072 lutf8lib.c 187: Suspicious pointer arithmetic in function byteoffset
Warning W8072 lutf8lib.c 208: Suspicious pointer arithmetic in function iter_aux
Warning W8072 lutf8lib.c 214: Suspicious pointer arithmetic in function iter_aux

---
wbr, ps
Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
> Warnings from vs 2013 community eidtion with amost all warnings turned on.
> Compiled source from lua-5.3.0-rc2.tar.gz

Thanks for the report. We do not even try to correct most of these
warnings; they are too picky. (A few will be corrected, but maybe not
now.)  This is a nightmare; some warnings here are caused by code that
intend to avoid warnings in even dumber compilers ;-)

BTW, "Suspicious pointer arithmetic" opens a whole new world for dumb
compilers pretending to be smart :-)

PS: despite my whining, please do not refrain from sending us these
reports!

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Liam Devine
In reply to this post by Luiz Henrique de Figueiredo
On 22/12/14 14:34, Luiz Henrique de Figueiredo wrote:
>

> Finally, for those of you into this, please test luac -l -l on your
> scripts, just to make sure we haven't missed anything with the new
> VM instructions etc.
>
> All feedback welcome. Thanks.
> --lhf
>
>

The floor division operator is still using the name OP_IDIV, is this
going to be changed to reflect the new behaviour? Also constants in the
luac output, that are floating points yet have an integer
representation, do not show they are floating point numbers.

:~$ luac53 -l -l ./idiv.lua

main <./idiv.lua:0,0> (5 instructions at 0xfa7590)
0+ params, 3 slots, 1 upvalue, 2 locals, 2 constants, 0 functions
        1 [1] LOADK     0 -1 ; 3
        2 [1] LOADK     1 -2 ; 2
        3 [2] IDIV     2 0 1
        4 [2] RETURN   2 2
        5 [2] RETURN   0 1
constants (2) for 0xfa7590:
        1 3
        2 2
locals (2) for 0xfa7590:
        0 i 3 6
        1 j 3 6
upvalues (1) for 0xfa7590:
        0 _ENV 1 0
:~$ cat ./idiv.lua
local i, j = 3., 2.
return i//j

--
Liam


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

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

Roberto Ierusalimschy
> The floor division operator is still using the name OP_IDIV, is this
> going to be changed to reflect the new behaviour?

The new operator is called "floor division", but FDIV looks more like
"float division"... I hope we can live with "integer division" as a
nickname :-)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Soni "They/Them" L.

On 23/12/14 06:19 PM, Roberto Ierusalimschy wrote:
>> The floor division operator is still using the name OP_IDIV, is this
>> going to be changed to reflect the new behaviour?
> The new operator is called "floor division", but FDIV looks more like
> "float division"... I hope we can live with "integer division" as a
> nickname :-)
>
> -- Roberto
>
How about integral(?) division? (returns an integral, which may or may
not be an integer)

--
Disclaimer: these emails are public and can be accessed from <TODO: get a non-DHCP IP and put it here>. If you do not agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

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

Luiz Henrique de Figueiredo
In reply to this post by Liam Devine
> constants in the luac output, that are floating points yet have an
> integer representation, do not show they are floating point numbers.

Thanks for the report.

Reply | Threaded
Open this post in threaded view
|

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

Steven Degutis
In reply to this post by Luiz Henrique de Figueiredo
Quoth lhf:

> Lua 5.3.0 (rc2) is now available for testing at
>         http://www.lua.org/work/lua-5.3.0-rc2.tar.gz
>
> MD5     61726271cf342794909a1752ea0c0aae  -
> SHA1    457be7b889f7825c3b9c8b9a4b95b85c0c0b434d  -
>
> This is a release candidate for the final release of Lua 5.3.0.
>
> A few things have changed since beta that we'd like to test in the wild.
> In particular, we made some changes in luaconf.h and in the Makefile
> that we'd like to test. Please try compiling the current code in as many
> platforms as possible. We expect the compilation will go smoothly as usual
> but please report any warnings or other glitches.
>
> We'd also like feedback on the documentation:
>         http://www.lua.org/work/doc/readme.html
>         http://www.lua.org/work/doc/contents.html
>         http://www.lua.org/work/doc/manual.html
>
> Finally, for those of you into this, please test luac -l -l on your
> scripts, just to make sure we haven't missed anything with the new
> VM instructions etc.
>
> The main change in Lua 5.3.0 is the introduction of integers. See also
>         http://www.lua.org/work/doc/#changes
>
> The complete diffs are available at
>         http://www.lua.org/work/diffs-lua-5.3.0-rc1-rc2.txt
>
> An updated test suite is available at
>         http://www.lua.org/work/lua-5.3.0-rc2-tests.tar.gz
>
> All feedback welcome. Thanks.

The documentation doesn't seem to explain the __name metatable field
in the same place as the other valid metatable fields.

Reply | Threaded
Open this post in threaded view
|

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

Edward Berner
In reply to this post by Luiz Henrique de Figueiredo
On 12/22/2014 6:34 AM, Luiz Henrique de Figueiredo wrote:
> Lua 5.3.0 (rc2) is now available for testing at
> http://www.lua.org/work/lua-5.3.0-rc2.tar.gz
>
> [...]
> We'd also like feedback on the documentation:
> http://www.lua.org/work/doc/readme.html
> http://www.lua.org/work/doc/contents.html
> http://www.lua.org/work/doc/manual.html

A couple documentation comments:

1. I was reading section 3.4.1 on Arithmetic Operators looking for
information about the behavior of integers and floats, etc.  Not knowing
at the time that exponentiation was always float, the phrase "with the
exception of float division and exponentiation..." was slightly
unclear.  I wasn't sure if it should be parsed as "(float division) and
(exponentiation)" or "float (division and exponentiation)" with the
latter possibly implying the existence of an integer exponentiation
operator.  Anyway, its a minor thing but it might be a little clearer to
change the order and say "exponentiation and float division".

2. Also in section 3.4.1, I was scanning the text looking for
information about exponentiation and almost missed some of the
information because it is combined in a paragraph talking about float
division.  So, I'd propose splitting the paragraph that starts with
"Float division (/) and exponentiation always..." into two paragraphs,
one talking about float division and one about exponentiation, just so
its a bit clearer when quickly scanning the text.

--
Edward Berner


Reply | Threaded
Open this post in threaded view
|

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

Daurnimator
In reply to this post by Steven Degutis
On 24 December 2014 at 14:40, Steven Degutis <[hidden email]> wrote:
> The documentation doesn't seem to explain the __name metatable field
> in the same place as the other valid metatable fields.

The new respect for the __name metafield by argument checking is
actually a bigger change I didn't even know about until you mentioned
it on IRC today.
The feature can bring about some potentially confusing error messages.
As discovered by xyzzy__:

> math.sin(setmetatable({},{__name = 'number'}))
sandbox:1: bad argument #1 to 'sin' (number expected, got number)
stack traceback:
 [C]: in function 'math.sin'
sandbox:1: in main chunk

Could this be changed to something like:
"bad argument #%d to '%s' (%s (%s) expected, got %s (%s))"
where each first %s is the base type (as returned by lua_typename),
and the %s in parenthesis is the __name metafield?

Reply | Threaded
Open this post in threaded view
|

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

Edward Berner
In reply to this post by Luiz Henrique de Figueiredo
On 12/22/2014 6:34 AM, Luiz Henrique de Figueiredo wrote:

> Lua 5.3.0 (rc2) is now available for testing at
> http://www.lua.org/work/lua-5.3.0-rc2.tar.gz
>
> MD5 61726271cf342794909a1752ea0c0aae  -
> SHA1 457be7b889f7825c3b9c8b9a4b95b85c0c0b434d  -
>
> This is a release candidate for the final release of Lua 5.3.0.
>
> A few things have changed since beta that we'd like to test in the wild.
> In particular, we made some changes in luaconf.h and in the Makefile
> that we'd like to test. Please try compiling the current code in as many
> platforms as possible. We expect the compilation will go smoothly as usual
> but please report any warnings or other glitches.
>

Solaris is being a bit of a pain.

(I'm testing this with Solaris 10 on both sparc and amd64.  Haven't
tested other versions.)

None of the makefile targets will build.  They get the following error:

$ make solaris
make all SYSCFLAGS="-DLUA_USE_POSIX -DLUA_USE_DLOPEN -D_REENTRANT"
SYSLIBS="-ldl"
gcc -O2 -Wall -Wextra -DLUA_COMPAT_5_2 -DLUA_USE_POSIX -DLUA_USE_DLOPEN
-D_REENTRANT   -c  lapi.c
In file included from /usr/include/iso/stdarg_c99.h:34,
                  from /usr/include/stdarg.h:33,
                  from lapi.c:13:
/usr/include/sys/feature_tests.h:341:2: #error "Compiler or options
invalid; UNIX 03 and POSIX.1-2001 applications      require the use of c99"

The relevant comment from /usr/include/sys/feature_tests.h is:

/*
  * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application
  * using c99.  The same is true for POSIX.1-1990, POSIX.2-1992, POSIX.1b,
  * and POSIX.1c applications. Likewise, it is invalid to compile an XPG6
  * or a POSIX.1-2001 application with anything other than a c99 or later
  * compiler.  Therefore, we force an error in both cases.
  */

This seems to be triggered by the fact that lprefix.h sets _XOPEN_SOURCE
to 600.

At this point in the release cycle I think the best fix is probably to
add "-std=gnu99" to SYSCFLAGS in the solaris target of the makefile.  
Alternatively one could add "-D_XOPEN_SOURCE=500" to the SYSCFLAGS, but
maybe it was set to 600 for a reason and I'm not sure what the
implications are of changing it to 500.

Pedantically, one wonders if lprefix.h should refrain from setting
_XOPEN_SOURCE if LUA_USE_C89 is set, or perhaps set _XOPEN_SOURCE to 500
when LUA_USE_C89 is set.  But it is quite possible that real world
convenience should trump pedantic correctness here.

It does compile okay after changing to a c99 compiler.  The "c99"
compiler from Solaris Studio 12.3 compiles with no warnings.  The
bundled gcc (version 3.4.3 plus patches) produces some warnings but in
my experience that is not unexpected from an older gcc.  Using a locally
built gcc 4.8.1 produces only one warning, listed below, which may be an
artifact of compiling in c99 mode.

lcode.c: In function 'constfolding':
lcode.c:791:5: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
      if (luai_numisnan(n) || isminuszero(n))
      ^

I haven't spent enough time yet with the test suite on Solaris to say
whether there are any issues worth reporting.

--
Edward Berner


Reply | Threaded
Open this post in threaded view
|

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

Dirk Laurie-2
In reply to this post by Daurnimator
2014-12-25 1:05 GMT+02:00 Daurnimator <[hidden email]>:

> The new respect for the __name metafield by argument checking is
> actually a bigger change I didn't even know about until you mentioned
> it on IRC today.

At this stage it is an implementation detail: all that the manual says
about it is in the description of API function `luaL_newmetatable`,
not where it will be used.

Reply | Threaded
Open this post in threaded view
|

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

Luiz Henrique de Figueiredo
In reply to this post by Daurnimator
> > math.sin(setmetatable({},{__name = 'number'}))
> sandbox:1: bad argument #1 to 'sin' (number expected, got number)

So, don't use the name of a basic type as the name of your type...

> Could this be changed to something like:
> "bad argument #%d to '%s' (%s (%s) expected, got %s (%s))"
> where each first %s is the base type (as returned by lua_typename),
> and the %s in parenthesis is the __name metafield?

And then get this?
        bad argument #1 to 'sin' (number (number) expected, got number (number))

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
In reply to this post by Edward Berner
> This seems to be triggered by the fact that lprefix.h sets
> _XOPEN_SOURCE to 600.
>
> At this point in the release cycle I think the best fix is probably
> to add "-std=gnu99" to SYSCFLAGS in the solaris target of the
> makefile.  Alternatively one could add "-D_XOPEN_SOURCE=500" to the
> SYSCFLAGS, but maybe it was set to 600 for a reason and I'm not sure
> what the implications are of changing it to 500.

Some POSIX functions that Lua uses are not available with
"-D_XOPEN_SOURCE=500" (at least in Linux).


> It does compile okay after changing to a c99 compiler.  The "c99"
> compiler from Solaris Studio 12.3 compiles with no warnings.  The
> bundled gcc (version 3.4.3 plus patches) produces some warnings but
> in my experience that is not unexpected from an older gcc.  Using a
> locally built gcc 4.8.1 produces only one warning, listed below,
> which may be an artifact of compiling in c99 mode.

Just to check: "The bundled gcc" means using Lua out of the package,
only adding "-std=gnu99" to SYSCFLAGS? Does "-std=c99" work too?

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Daurnimator
In reply to this post by Luiz Henrique de Figueiredo
On 25 December 2014 at 01:41, Dirk Laurie <[hidden email]> wrote:

> 2014-12-25 1:05 GMT+02:00 Daurnimator <[hidden email]>:
>
>> The new respect for the __name metafield by argument checking is
>> actually a bigger change I didn't even know about until you mentioned
>> it on IRC today.
>
> At this stage it is an implementation detail: all that the manual says
> about it is in the description of API function `luaL_newmetatable`,
> not where it will be used.
>

As it happens, we're on the cusp of releasing a new implementation;
Infact, it will probably be the reference implementation!
This would be a nice thing to get correct.

On 25 December 2014 at 07:58, Luiz Henrique de Figueiredo
<[hidden email]> wrote:

>> > math.sin(setmetatable({},{__name = 'number'}))
>> sandbox:1: bad argument #1 to 'sin' (number expected, got number)
>
> So, don't use the name of a basic type as the name of your type...
>
>> Could this be changed to something like:
>> "bad argument #%d to '%s' (%s (%s) expected, got %s (%s))"
>> where each first %s is the base type (as returned by lua_typename),
>> and the %s in parenthesis is the __name metafield?
>
> And then get this?
>         bad argument #1 to 'sin' (number (number) expected, got number (number))
>

I see two easy options:
1. don't have the parenthesised __name if the metafield does not exist
2. for numbers, we can have "float" vs "integer"

This would be a much more informative error message:

    bad argument #1 to 'sin' (number (float) expected, got userdata (number))

Reply | Threaded
Open this post in threaded view
|

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

Rena
In reply to this post by Luiz Henrique de Figueiredo

On Dec 25, 2014 7:59 AM, "Luiz Henrique de Figueiredo" <[hidden email]> wrote:
>
> > > math.sin(setmetatable({},{__name = 'number'}))
> > sandbox:1: bad argument #1 to 'sin' (number expected, got number)
>
> So, don't use the name of a basic type as the name of your type...
>
> > Could this be changed to something like:
> > "bad argument #%d to '%s' (%s (%s) expected, got %s (%s))"
> > where each first %s is the base type (as returned by lua_typename),
> > and the %s in parenthesis is the __name metafield?
>
> And then get this?
>         bad argument #1 to 'sin' (number (number) expected, got number (number))
>

I agree. The way it is now is perfect as long as you don't go naming things after existing types.

12