[ANN] Lua 5.3.0 (rc1) now available

classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|

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

Tomás Guisasola-2
  Hi Roberto

> That certainly would help, but an essential point is to understand how
> you *want* to round these values.
  This is a good question.
  Since 2.7 "has no integer representation", I could think that
'2' also hasn't.  But that is not what happens:

Lua 5.3.0  Copyright (C) 1994-2014 Lua.org, PUC-Rio
> return string.format("%d", '2.7')
stdin:1: bad argument #2 to 'format' (number has no integer representation)
stack traceback:
  [C]: in function 'string.format'
  stdin:1: in main chunk
  [C]: in ?
> return string.format("%d", '2')
2
> return string.format("%d", '2.0')
2

  What is the rationale? Are you considering a change on automatic
coercion?  It will probably produce a great compatibility problem but
it may be worth it...

  Regards,
  Tomás
Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
In reply to this post by Daurnimator
> > As this point has come up several times, I have a quick quiz for this
> > list. Without running the code, what are the results of the following
> > expressions in Lua 5.2?
> >
> >   string.rep("a", 2.7)
> >   string.format("%d", 2.7)
> >   string.rep("a", 2.3)
> >   string.format("%d", 2.3)
> >

> Undefined, Undefined, Undefined, Undefined, or with GCC, "aaa", "3",
> "aa", "2" (pretty sure GCC rounds properly? I may be wrong)
> (Soni)

> About the quiz, in version 5.2, I believe that all values are considered
> equal to 2.
> (Charles)

> IIRC, in practice, lua always rounds down. so:
> aa
> 2
> aa
> 2
(Daurnimator)

"Undefined" is correct according to the manual, but (unlike 5.3) the
implementation thinks otherwise. And none of these answers match what my
machine (an ordinary Pentium/Linux) does.  Anyone else want to try an
answer?

-- Roberto


-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
In reply to this post by Tomás Guisasola-2
> Since 2.7 "has no integer representation", I could think that
> '2' also hasn't.  But that is not what happens:
>
> Lua 5.3.0  Copyright (C) 1994-2014 Lua.org, PUC-Rio
> >return string.format("%d", '2.7')
> stdin:1: bad argument #2 to 'format' (number has no integer representation)
> stack traceback:
> [C]: in function 'string.format'
> stdin:1: in main chunk
> [C]: in ?
> >return string.format("%d", '2')
> 2
> >return string.format("%d", '2.0')
> 2
>
> What is the rationale? Are you considering a change on automatic
> coercion?  It will probably produce a great compatibility problem but
> it may be worth it...

The main difference here is that, unlike the coercion from floats to
integers---which was always undefined and, as my quiz shows, nobody
really knows how it works---the coercion from strings to numbers has
always been well defined and mostly everybody knows how it works.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Enrico Colombini
In reply to this post by Roberto Ierusalimschy
On 18/12/2014 13.40, Roberto Ierusalimschy wrote:
> Anyone else want to try an answer?

Wild, wild guesses:

   string.rep("a", 2.7)
   -->  "aa"

   string.format("%d", 2.7)
   --> the IEEE format for 2.7 interpreted as (int)

   string.rep("a", 2.3)
   -->  "aa"

   string.format("%d", 2.3)
   --> the IEEE format for 2.3 interpreted as (int)

Let's see if I managed to get all 4 wrong :-)

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
In reply to this post by Roberto Ierusalimschy
BTW, Lua 5.3 has two macros that allow you to disable those automatic
coercions, if you want to try.

-DLUA_NOCVTN2S  to disable conversion from numbers to strings
-DLUA_NOCVTS2N  to disable conversion from strings to numbers

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Alexey Melnichuk-2
In reply to this post by Roberto Ierusalimschy
Здравствуйте, Roberto.

Вы писали 18 декабря 2014 г., 16:40:23:

>> > As this point has come up several times, I have a quick quiz for this
>> > list. Without running the code, what are the results of the following
>> > expressions in Lua 5.2?
>> >
>> >   string.rep("a", 2.7)
>> >   string.format("%d", 2.7)
>> >   string.rep("a", 2.3)
>> >   string.format("%d", 2.3)
>> >

>> Undefined, Undefined, Undefined, Undefined, or with GCC, "aaa", "3",
>> "aa", "2" (pretty sure GCC rounds properly? I may be wrong)
>> (Soni)

>> About the quiz, in version 5.2, I believe that all values are considered
>> equal to 2.
>> (Charles)

>> IIRC, in practice, lua always rounds down. so:
>> aa
>> 2
>> aa
>> 2
> (Daurnimator)

> "Undefined" is correct according to the manual, but (unlike 5.3) the
> implementation thinks otherwise. And none of these answers match what my
> machine (an ordinary Pentium/Linux) does.  Anyone else want to try an
> answer?

WinXP/MSVC 2010

Lua 5.1/5.2
aaa
2
aa
2

LuaJIT 2.1.0-alpha
aa
2
aa
2

LuaJIT 2.0.1
aaa
3
aa
2





--
С уважением,
 Alexeymelnichuck                          mailto:[hidden email]


---
Это сообщение проверено на вирусы антивирусом Avast.
http://www.avast.com


Reply | Threaded
Open this post in threaded view
|

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

Douglas Davenport
In reply to this post by Roberto Ierusalimschy

On Dec 18, 2014, at 7:40 AM, Roberto Ierusalimschy <[hidden email]> wrote:

>>> As this point has come up several times, I have a quick quiz for this
>>> list. Without running the code, what are the results of the following
>>> expressions in Lua 5.2?
>>>
>>>  string.rep("a", 2.7)
>>>  string.format("%d", 2.7)
>>>  string.rep("a", 2.3)
>>>  string.format("%d", 2.3)
>>>
>
>> Undefined, Undefined, Undefined, Undefined, or with GCC, "aaa", "3",
>> "aa", "2" (pretty sure GCC rounds properly? I may be wrong)
>> (Soni)
>
>> About the quiz, in version 5.2, I believe that all values are considered
>> equal to 2.
>> (Charles)
>
>> IIRC, in practice, lua always rounds down. so:
>> aa
>> 2
>> aa
>> 2
> (Daurnimator)
>
> "Undefined" is correct according to the manual, but (unlike 5.3) the
> implementation thinks otherwise. And none of these answers match what my
> machine (an ordinary Pentium/Linux) does.  Anyone else want to try an
> answer?
>
> -- Roberto
>
>
> -- Roberto
>

I also thought the answer Daurnimator posted was correct. I tried it with 5.1, 5.2 and 5.3 (beta). With 5.1 and 5.2 I get the result I expected:
  aa
  2
  aa
  2
And, as expected on 5.3 (beta), I got the error "(number has no integer representation)” on all four expressions.

I am running on OS X 10.9, in case is make a difference to someone.

(Yes, I know I need to update my 5.3 to rc1...

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

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

Steven Degutis
In reply to this post by Roberto Ierusalimschy
Oh wow. I am totally enabling those in my new Lua 5.3 project! Thanks!!!

Quoth Roberto Ierusalimschy:
> BTW, Lua 5.3 has two macros that allow you to disable those automatic
> coercions, if you want to try.
>
> -DLUA_NOCVTN2S  to disable conversion from numbers to strings
> -DLUA_NOCVTS2N  to disable conversion from strings to numbers

Reply | Threaded
Open this post in threaded view
|

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

Luiz Henrique de Figueiredo
> > -DLUA_NOCVTN2S  to disable conversion from numbers to strings
> > -DLUA_NOCVTS2N  to disable conversion from strings to numbers

> Oh wow. I am totally enabling those in my new Lua 5.3 project!

Please report your experience running Lua with these enabled. Thanks.

Reply | Threaded
Open this post in threaded view
|

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

Edward Berner
In reply to this post by Luiz Henrique de Figueiredo
On 12/16/2014 9:29 AM, Luiz Henrique de Figueiredo wrote:
> Lua 5.3.0 (rc1) is now available for testing at
> http://www.lua.org/work/lua-5.3.0-rc1.tar.gz
> [...]
> All feedback welcome. Thanks.
>

(Since you asked for testing of various platforms and compilers...)

Compiling with Open Watcom 1.9 produces some warnings.  I have not
investigated any of the warnings.  I didn't use the makefile, I just
moved luac.c out of the way and compiled *.c.  For comparison, compiling
Lua 5.2.3 does not report any warnings.

$ owcc -Wall -Wextra -o lua *.c
lcode.c(766): Warning! W200: 'a' has been referenced but never assigned
a value
lcode.c(766): Warning! W200: 'b' has been referenced but never assigned
a value
ldo.c(709): Warning! W124: Comparison result always 0
lgc.c(762): Warning! W124: Comparison result always 0
llex.c(63): Warning! W124: Comparison result always 0
llex.c(176): Warning! W124: Comparison result always 0
lstate.c(246): Warning! W124: Comparison result always 0
lzio.c(73): Warning! W124: Comparison result always 0

--
Edward Berner


Reply | Threaded
Open this post in threaded view
|

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

Edward Berner
In reply to this post by Luiz Henrique de Figueiredo
On 12/16/2014 9:29 AM, Luiz Henrique de Figueiredo wrote:
> Lua 5.3.0 (rc1) is now available for testing at
> http://www.lua.org/work/lua-5.3.0-rc1.tar.gz
> [...]
> All feedback welcome. Thanks.
>

Regarding this section in llimits.h:

/*
** non-return type
*/
#if defined(__GNUC__)
#define l_noret        void __attribute__((noreturn))
#elif defined(_MSC_VER)
#define l_noret        void __declspec(noreturn)
#else
#define l_noret        void
#endif

By experimentation, it looks like __declspec(noreturn) support was added
in MSVC 6.  So the _MSC_VER line could be changed to the following:

#elif defined(_MSC_VER) && _MSC_VER >= 1200

Just to make things a little easier for anyone playing with older
Microsoft compilers.  (Also applies to Lua 5.2.)

--
Edward Berner


Reply | Threaded
Open this post in threaded view
|

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

Pierre Chapuis
In reply to this post by Roberto Ierusalimschy
> BTW, Lua 5.3 has two macros that allow you to disable those automatic
> coercions, if you want to try.
>
> -DLUA_NOCVTN2S  to disable conversion from numbers to strings
> -DLUA_NOCVTS2N  to disable conversion from strings to numbers

Nice! Would it be easy to make this a dynamic option
instead of a compile-time one?

--
Pierre Chapuis


Reply | Threaded
Open this post in threaded view
|

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

Dirk Laurie-2
2014-12-19 11:34 GMT+02:00 Pierre Chapuis <[hidden email]>:
>> BTW, Lua 5.3 has two macros that allow you to disable those automatic
>> coercions, if you want to try.
>>
>> -DLUA_NOCVTN2S  to disable conversion from numbers to strings
>> -DLUA_NOCVTS2N  to disable conversion from strings to numbers
>
> Nice! Would it be easy to make this a dynamic option
> instead of a compile-time one?

Each option affects the definition of a macro, which appears in the definition
of other macros, which appear ...

So I'd say: not easy, and even if possible, it will affect performance.

Reply | Threaded
Open this post in threaded view
|

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

Luiz Henrique de Figueiredo
In reply to this post by aryajur
> > lua -e "print(collectgarbage 'count')"
>
> Lua 5.2 shows a little more than 14K and Lua 5.3 shows more than 20K.

On a MacBook Air (2011) running Lion (10.7.5) I get these numbers:
        5.1.5 27k
        5.2.3 22k
        5.3.0 24k

On a 32-bit Linux I get this:
        5.1.5 17k
        5.2.3 13k
        5.3.0 18k
       
So, yes, I see an increase too, but nothing to be alarmed about.
I haven't dug deeper, though.

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
> > > lua -e "print(collectgarbage 'count')"
> >
> > Lua 5.2 shows a little more than 14K and Lua 5.3 shows more than 20K.
>
> On a MacBook Air (2011) running Lion (10.7.5) I get these numbers:
> 5.1.5 27k
> 5.2.3 22k
> 5.3.0 24k
>
> On a 32-bit Linux I get this:
> 5.1.5 17k
> 5.2.3 13k
> 5.3.0 18k
>
> So, yes, I see an increase too, but nothing to be alarmed about.
> I haven't dug deeper, though.

Probably the "NaN trick" in Lua 5.2 explains part of the difference
in 32-bit machines.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
In reply to this post by Edward Berner
> (Since you asked for testing of various platforms and compilers...)
>
> Compiling with Open Watcom 1.9 produces some warnings.  I have not
> investigated any of the warnings.  I didn't use the makefile, I just
> moved luac.c out of the way and compiled *.c.  For comparison,
> compiling Lua 5.2.3 does not report any warnings.
>
> $ owcc -Wall -Wextra -o lua *.c
> lcode.c(766): Warning! W200: 'a' has been referenced but never
> assigned a value
> lcode.c(766): Warning! W200: 'b' has been referenced but never
> assigned a value
> ldo.c(709): Warning! W124: Comparison result always 0
> lgc.c(762): Warning! W124: Comparison result always 0
> llex.c(63): Warning! W124: Comparison result always 0
> llex.c(176): Warning! W124: Comparison result always 0
> lstate.c(246): Warning! W124: Comparison result always 0
> lzio.c(73): Warning! W124: Comparison result always 0

Thanks for the feedback.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Negative table index (was Re: [ANN] Lua 5.3.0 (rc1) now available)

Tom N Harris
In reply to this post by Luiz Henrique de Figueiredo
table.move forbids a negative index on the source index, but not the
destination. Why the restriction? And why not restrict both source and
destination? There's a comment about overflow, but I don't see where it would
be a problem. Perhaps the statement 'n = e - f + 1' but isn't it possible to
detect overflow? And why not check for overflow on the destination too?

  > table.move({"a","b","c"},1,3, math.maxinteger*2+1,{})
  > table.move(t,1,math.maxinteger*2+1, -1,{})

(Pretend that the second one won't run out of memory.)
Not to mention overflow problems when the source index is close to the
maximum.

Some of the functions in the table library permit negative indexes even though
the documentation officially only works on sequences.

  > print(table.unpack({"a","b","c",[-1]="x"}, -1))
  x   nil a   b   c

Should the documentation state that some functions allow non-sequences? Should
out-of-bound indexes always be checked?

--
tom <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: Negative table index (was Re: [ANN] Lua 5.3.0 (rc1) now available)

Tom N Harris
It also occurs to me that table.move allows for a hackish map implementation.

function table.map(self, func)
    table.move(setmetatable({}, {
      __index = self,
      __newindex = function(t,k,v) self[k] = func(v) end
    }), 1,#self,1)
end

--
tom <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

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

ForthCAD
In reply to this post by Luiz Henrique de Figueiredo
Hi,

I adapted my programs to use this mode.

#define LUA_NOCVTN2S
#define LUA_NOCVTS2N

Only 6 small changes were needed in 100k of source code.
It works without problems.

-----Message d'origine-----
De : [hidden email] [mailto:[hidden email]] De la
part de Luiz Henrique de Figueiredo
Envoyé : jeudi 18 décembre 2014 19:24
À : Lua mailing list
Objet : Re: [ANN] Lua 5.3.0 (rc1) now available

> > -DLUA_NOCVTN2S  to disable conversion from numbers to strings
> > -DLUA_NOCVTS2N  to disable conversion from strings to numbers

> Oh wow. I am totally enabling those in my new Lua 5.3 project!

Please report your experience running Lua with these enabled. Thanks.


Reply | Threaded
Open this post in threaded view
|

Re: Negative table index

Roberto Ierusalimschy
In reply to this post by Tom N Harris
> table.move forbids a negative index on the source index, but not the
> destination. Why the restriction? And why not restrict both source and
> destination? There's a comment about overflow, but I don't see where it would
> be a problem. Perhaps the statement 'n = e - f + 1' but isn't it possible to
> detect overflow?

Consider the statement:

  table.move({}, math.mininteger, math.mininteger+20, math.maxinteger-5)

At first, it would move elements to the right, but after the destination
index wraps around, it would then move elements to the left. Because
source and destination overlap, the move might have to be performed in
two steps, to avoid moved elements overwriting elements still to be
moved. Surely we could do several different checks and avoid all
problems, but this trivial (and, in our view, harmless) test seems
simpler to explain, understand, and implement.


> And why not check for overflow on the destination too?
>
>   > table.move({"a","b","c"},1,3, math.maxinteger*2+1,{})
>   > table.move(t,1,math.maxinteger*2+1, -1,{})

The expression 'math.maxinteger*2+1' evaluates to -1 (by the rules
of arithmetic overflows) before the function is called. The calls
then become

  table.move({"a","b","c"},1,3, -1,{})
  table.move(t,1,-1, -1,{})

-- Roberto

123