[ANN] Lua 5.4.0 (alpha-rc1) now available

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

Re: [ANN] Lua 5.4.0 (alpha-rc1) now available

phlnc8
Hi Luiz,

Regarding the linux target, I still have to add '-lncurses' to SYSLIBS
in the src makefile.

I understand it is a distribution issue (Slackware 14.2 here), but I
was wondering how many other distros have the same issue.  Adding
'-lncurses' would help for these distros and wouldn't hurt for
other/more mainstream distros  (ncurses is certainly available
wherever readline is)

This is not a big deal. I am used to patch the src makefile for all
releases since Lua 5.2 (IIRC)

Thanks,

Phil

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc1) now available

Jonathan Goble
In reply to this post by Luiz Henrique de Figueiredo
On Thu, May 30, 2019 at 12:04 PM Luiz Henrique de Figueiredo
<[hidden email]> wrote:
>
> > If your platform is a common Unix-like platform, just do
> >         make guess
> > The Makefile will guess your platform using uname and build Lua for it.
>
> We welcome feedback on this, which is new. More uname targets with
> explicit rules and fixes for existing ones. Thanks.

Why not make "guess" the default target, fall back to listing the
options if it fails, and document the additional options (like
linux-readline) in a little more detail in the readme? Then building
Lua on those common platforms becomes a simple "make && sudo make
install", in line with most open source Unix software.

I've always thought that Lua was a bit oddball for requiring an
explicit target with the "make" command. I suppose that requirement
has come with the lack of a "configure" script, but the "guess" target
is a nice step toward standardization. Making it the default would be
another nice step in that direction.

Also, would it be possible for "guess" on a Linux system to check
whether the readline headers are present, and build the
"linux-readline" target if found? Or is that a bad idea?

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc1) now available

Jim-2
In reply to this post by phlnc8
30.05.2019, 18:32, "phlnc8" <[hidden email]>:
> Regarding the linux target, I still have to add '-lncurses' to SYSLIBS
> in the src makefile.
>
> I understand it is a distribution issue
> (Slackware 14.2 here),

:D

> but I was wondering how many other distros have the same issue.
> Adding '-lncurses' would help for these distros and wouldn't hurt
> for other/more mainstream distros (ncurses is certainly available
> wherever readline is)
>
> This is not a big deal. I am used to patch the src makefile for all
> releases since Lua 5.2 (IIRC)

i would suggest to use 2 different linux targets:
linux and linux-readline where only the latter should link against
the ncurses lib.
(btw: does readline always use ncurses or can it be linked against
other curses libs ?)


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc1) now available

Luiz Henrique de Figueiredo
In reply to this post by Jonathan Goble
> Why not make "guess" the default target

This can be considered if the "guess" target works for most people.
Hence the request for feedback.

> Also, would it be possible for "guess" on a Linux system to check
> whether the readline headers are present, and build the
> "linux-readline" target if found? Or is that a bad idea?

That's a can of worms and not pretty to do in a Makefile. But it'd be nice, yes.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc1) now available

Luiz Henrique de Figueiredo
In reply to this post by Jim-2
> i would suggest to use 2 different linux targets:
> linux and linux-readline where only the latter should link against
> the ncurses lib.

That's essentially what we have now:

Linux linux: linux-noreadline

linux-noreadline:
  $(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX" SYSLIBS="-Wl,-E -ldl"

linux-readline:
  $(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX -DLUA_USE_READLINE"
SYSLIBS="-Wl,-E -ldl -lreadline"

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc1) now available

Roberto Ierusalimschy
In reply to this post by phlnc8
> Test with two errors:
>
>     > do local <toclose> x='XX'; local <toclose> y='YY'  end
>
>     stdin:1: err closing XX
>
> No stack traceback. Is it normal?

I could not reproduce this. I get a traceback.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc1) now available

Jonathan Goble
On Thu, May 30, 2019 at 2:31 PM Roberto Ierusalimschy
<[hidden email]> wrote:

>
> > Test with two errors:
> >
> >     > do local <toclose> x='XX'; local <toclose> y='YY'  end
> >
> >     stdin:1: err closing XX
> >
> > No stack traceback. Is it normal?
>
> I could not reproduce this. I get a traceback.
>
> -- Roberto

I also get a traceback (Ubuntu 18.04):

<0> jonathan@JONATHAN-DESKTOP Thu May 30 12:19 PM ~/src/lua-5.4.0-alpha
(!541) $ ./src/lua
Lua 5.4.0  Copyright (C) 1994-2019 Lua.org, PUC-Rio
> do local <toclose> x='XX'; local <toclose> y='YY'  end
stdin:1: attempt to close non-closable variable 'y'
stack traceback:
        stdin:1: in main chunk
        [C]: in ?

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc1) now available

Roberto Ierusalimschy
In reply to this post by Xavier Wang
> the most way to use "const" in C is use it as function parameter qualifier.
> So does Lua plan to support it?

More often than not, we use "const" in C for a parameter qualifier as a
way to tell the caller that the function does not change something; in
particular, we use "const type*" and not "const type".  All these only
works with static typing.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc1) now available

Egor Skriptunoff-2
In reply to this post by Luiz Henrique de Figueiredo
On Thu, May 30, 2019 at 3:38 AM Luiz Henrique de Figueiredo wrote:
Lua 5.4.0 (alpha-rc1) is now available for testing

All feedback welcome.



1)
Two warning generated by VisualStudio 2010
lobject.c(463) : warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data
lobject.c(478) : warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data

2)
The bug with wrong S2N conversion has been reported for previous "work versions", but still not fixed:
for i = "2", 3 do print(math.type(i)) end  --> float float
According to the manual, the value must be integer.

3)
The new manual (in the "For Statement" section) says the following:
   "You should not change the value of the control variable during the loop."
Does it mean that the following code may stop working correctly in the nearest future?
   for i = 1, 10 do i = tostring(i); .... end
The possibility to assign to a loop variable is so nice, please don't remove it from Lua.
Probably, the phrase in the manual should be replaced with more correct one:
   "A loop's behavior will not be affected by changing the value of its control variable."

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc1) now available

dyngeccetor8
In reply to this post by Luiz Henrique de Figueiredo
On 30/05/2019 03.38, Luiz Henrique de Figueiredo wrote:
> Lua 5.4.0 (alpha-rc1) is now available for testing at
> An updated reference manual is included and also available at
> http://www.lua.org/work/doc

Section "9 – The Complete Syntax of Lua" misses some of
new syntax changes.
       
  stat ::=  local ‘<’ Name ‘>’ Name ‘=’ exp


Also in section "3.3.8 – To-be-closed Variables",

  stat ::=  local ‘<’ toclose ‘>’ Name ‘=’ exp

"toclose" displayed in normal type. Shouldn't it
be bold?


-- Martin

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc1) now available

Roberto Ierusalimschy
In reply to this post by Egor Skriptunoff-2
> 1)
> Two warning generated by VisualStudio 2010
> lobject.c(463) : warning C4267: '+=' : conversion from 'size_t' to 'int',
> possible loss of data
> lobject.c(478) : warning C4267: '+=' : conversion from 'size_t' to 'int',
> possible loss of data

Thanks.


> 2)
> The bug with wrong S2N conversion has been reported for previous "work
> versions", but still not fixed:
> for i = "2", 3 do print(math.type(i)) end  --> float float
> According to the manual, the value must be integer.

The manual says this about a numerical for:

  The loop starts by evaluating once the three control expressions;
  they must all result in numbers.

So, I would say that |for i = "2", 3| is unspecified in the manual.


> 3)
> The new manual (in the "For Statement" section) says the following:
>    *"You should not change the value of the control variable during the
> loop."*
> Does it mean that the following code may stop working correctly in the
> nearest future?
>    for i = 1, 10 do i = tostring(i); .... end

Yes. Ideally, 'i' should be 'const'. (It would allow a slightly more
efficient implementation.)  It was kept as it is only for compatibility.


> The possibility to assign to a loop variable is so nice, please don't
> remove it from Lua.

Is it too painful to create another variable?

-    for i = 1, 10 do i = tostring(i); .... end
+    for i = 1, 10 do local i = tostring(i); .... end

(The later is even slightly more efficient.)

-- Roberto


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc1) now available

phlnc8
In reply to this post by Roberto Ierusalimschy
On Thu, May 30, 2019 at 6:31 PM Roberto Ierusalimschy
<[hidden email]> wrote:
> ...
> I could not reproduce this. I get a traceback.

Maybe my description was not clear:  With the following  zz.lua file:

    smt = getmetatable('a')
    function smt.__close(s) error("err closing ".. s) end
    do local <toclose> x='XX'; local <toclose> y='YY'  end

./lua zz.lua  outputs:

    ./lua: zz.lua:2: err closing XX

No traceback.

if the 3rd line is replaced with

    do local <toclose> x='XX' end

then "./lua zz.lua" output is

    ./lua: zz.lua:2: err closing XX
    stack traceback:
        [C]: in function 'error'
        zz.lua:2: in function <zz.lua:2>
        zz.lua:3: in main chunk
        [C]: in ?

Do you get the same result?

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc1) now available

Roberto Ierusalimschy
In reply to this post by dyngeccetor8
> Section "9 – The Complete Syntax of Lua" misses some of
> new syntax changes.
>
>   stat ::=  local ‘<’ Name ‘>’ Name ‘=’ exp

I see that line in my copy:

        stat ::=  ‘;’ |
           [...]
                 function funcname funcbody |
                 local function Name funcbody |
                 local namelist [‘=’ explist] |
                 local ‘<’ Name ‘>’ Name ‘=’ exp

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc1) now available

dyngeccetor8
On 30/05/2019 22.20, Roberto Ierusalimschy wrote:

>> Section "9 – The Complete Syntax of Lua" misses some of
>> new syntax changes.
>>
>>   stat ::=  local ‘<’ Name ‘>’ Name ‘=’ exp
>
> I see that line in my copy:
>
> stat ::=  ‘;’ |
>            [...]
> function funcname funcbody |
> local function Name funcbody |
> local namelist [‘=’ explist] |
> local ‘<’ Name ‘>’ Name ‘=’ exp
>
> -- Roberto
>

My bad.

-- Martin

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc1) now available

Thijs Schreijer
In reply to this post by Roberto Ierusalimschy


> On 30 May 2019, at 17:45, Roberto Ierusalimschy <[hidden email]> wrote:
>
>> The manual states: "If a coroutine yields inside a block and is never resumed again, the variables visible at that block will never go out of scope, and therefore they will not be closed.”
>>
>> Since this is quite explicitly mentioned, I’m confused as to what will happen when I let go of a suspended coroutine and it gets garbage collected? Will the __close handlers be called or not in that case? Maybe some clarification would be justified here.
>>
>
> The manual says "they will not be closed". Why isn't that clear?
>
> -- Roberto
>

"If a coroutine yields inside a block and is never resumed again, ”

I’d make it more specific with

"If a coroutine yields inside a block and is never resumed again (even if the coroutine is garbage collected), “

Thijs
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc1) now available

Egor Skriptunoff-2
In reply to this post by Roberto Ierusalimschy
On Thu, May 30, 2019 at 10:16 PM Roberto Ierusalimschy wrote:
> 2)
> The bug with wrong S2N conversion has been reported for previous "work
> versions", but still not fixed:
> for i = "2", 3 do print(math.type(i)) end  --> float float
> According to the manual, the value must be integer.

The manual says this about a numerical for:

  The loop starts by evaluating once the three control expressions;
  they must all result in numbers.

So, I would say that |for i = "2", 3| is unspecified in the manual.


There is another part of the manual which describes how "they result in numbers":

> Several places in Lua coerce strings to numbers when necessary.
> A string is converted to an integer or a float following its syntax and the rules of the Lua lexer.

If a string argument is prohibited in numeric for-loop then an error should be raised.
Otherwise, the conversion should comply with usual rule for S2N conversion.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc1) now available

Soni "They/Them" L.
In reply to this post by Xavier Wang


On 2019-05-30 1:15 p.m., Xavier Wang wrote:

>
>
> Luiz Henrique de Figueiredo <[hidden email]
> <mailto:[hidden email]>> 于2019年5月30日周四 上午8:38写道:
>
>     Lua 5.4.0 (alpha-rc1) is now available for testing at
>     http://www.lua.org/work/lua-5.4.0-alpha-rc1.tar.gz
>     All feedback welcome. Thanks.
>     --lhf
>
>
> Hi Luiz, is there any plans to support <toclose> and <const> (i.e. the
> annotation syntax) on the function parameters?
>
> e.g.
>
> function foo(<tobeclose> f, <const> cfg)
>   -- use f and cfg
> end -- the f will be close and cfg can not modify in the function body
>
> the most way to use "const" in C is use it as function parameter
> qualifier. So does Lua plan to support it?
>

Lua is nice in that it supports shadowing. So you can just do:

function foo(f, cfg)
   local <tobeclose> f = f
   local <const> cfg = cfg
end

> P.S. the new syntax is ugly, indeed :-(
>
>
> --
> regards,
> Xavier Wang.


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc1) now available

Soni "They/Them" L.
In reply to this post by Luiz Henrique de Figueiredo


On 2019-05-29 9:38 p.m., Luiz Henrique de Figueiredo wrote:

> Lua 5.4.0 (alpha-rc1) is now available for testing at
> http://www.lua.org/work/lua-5.4.0-alpha-rc1.tar.gz
>
> The checksums are
> MD5 56f18a477f5a962eeca4d5bb0ccad34b  -
> SHA1 def2b1be4c0a4eaab8afd25c8ba87f6a42074f3b  -
>
> This is an alpha version. Some details may change in the final version.
>
> The main changes in Lua 5.4.0 are listed at
> http://www.lua.org/work/doc/#changes
>
> An updated reference manual is included and also available at
> http://www.lua.org/work/doc
>
> The complete diffs from work2 to alpha are available at
> http://www.lua.org/work/diffs-lua-5.4.0-work2-alpha.html
> http://www.lua.org/work/diffu-lua-5.4.0-work2-alpha.html
>
> If your platform is a common Unix-like platform, just do
> make guess
> The Makefile will guess your platform using uname and build Lua for it.
>
> All feedback welcome. Thanks.
> --lhf
>

I guess no more goto in loops since you need to provide your own locals now.

for i=1,10 do
::retry::
if foo(i) then
i = something -- :(
goto retry
end
end

I also wonder if this works:

::foo::
local <const> x = 1
goto foo

I'll test it another time, maybe

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc1) now available

Jim-2
In reply to this post by Luiz Henrique de Figueiredo
On Thu, May 30, 2019 at 01:59:07PM -0300, Luiz Henrique de Figueiredo wrote:
>> Also, would it be possible for "guess" on a Linux system to check
>> whether the readline headers are present, and build the
>> "linux-readline" target if found? Or is that a bad idea?
>
> That's a can of worms and not pretty to do in a Makefile.
> But it'd be nice, yes.

maybe a little "configure" (shell) script (not autotools generated)
would help with build configuration (save its results in "config.h" and
make related flags in "conf.mk" (later sourced from the main makefile)).
default values could be provided in - say - "defconfig.h" and
"defconf.mk" then.

although i would not use readline at all to be honest.
this eases building. similar functionality is also provided by
external utilities like "rlwrap" and libtecla's "enhance".
those could be used for line editing instead. this has the advantage
that users can use the line editing library of their choice
(eg readline, editline, tecla, linenoise).


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.4.0 (alpha-rc1) now available

Vinicius Jarina
In reply to this post by Luiz Henrique de Figueiredo
Congratulations releasing Lua 5.4.0

I've compiled the latest lua54-alpha-rc1 on clang, clang reported 38 warnings. Would be nice to double check just to be sure is not a source of problems. (also would be nice to have no warning on clang, since we have no warning on gcc and MSVC).

Here is the gist of clang output




On Wed, May 29, 2019 at 8:38 PM Luiz Henrique de Figueiredo <[hidden email]> wrote:
Lua 5.4.0 (alpha-rc1) is now available for testing at
        http://www.lua.org/work/lua-5.4.0-alpha-rc1.tar.gz

The checksums are
        MD5     56f18a477f5a962eeca4d5bb0ccad34b  -
        SHA1    def2b1be4c0a4eaab8afd25c8ba87f6a42074f3b  -

This is an alpha version. Some details may change in the final version.

The main changes in Lua 5.4.0 are listed at
        http://www.lua.org/work/doc/#changes

An updated reference manual is included and also available at
        http://www.lua.org/work/doc

The complete diffs from work2 to alpha are available at
        http://www.lua.org/work/diffs-lua-5.4.0-work2-alpha.html
        http://www.lua.org/work/diffu-lua-5.4.0-work2-alpha.html

If your platform is a common Unix-like platform, just do
        make guess
The Makefile will guess your platform using uname and build Lua for it.

All feedback welcome. Thanks.
--lhf

12345