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

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

Luiz Henrique de Figueiredo
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

Reply | Threaded
Open this post in threaded view
|

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

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

Sorry for the noise.

Reply | Threaded
Open this post in threaded view
|

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

Rodrigo Azevedo
teste.lua

local teste0 = 'stringteste0'
local <const> teste1 = 'stringteste1'
local teste2 = 'stringteste2'
local <toclose> teste3 = 'stringteste3'
local teste4 = 'stringteste4'

lua teste.lua
lua: teste.lua:5: attempt to close non-closable variable 'teste4'
stack traceback:
    teste.lua:5: in main chunk
    [C]: in ?

Should it be 'teste3' instead of 'teste4'? Am I missing something?

Em qua, 29 de mai de 2019 às 21:41, Luiz Henrique de Figueiredo
<[hidden email]> escreveu:
>
> The complete diffs from work2 to alpha are available at
>        http://www.lua.org/work/diffs-lua-5.4.0-work2-alpha-rc1.html
>        http://www.lua.org/work/diffu-lua-5.4.0-work2-alpha-rc1.html
>
> Sorry for the noise.
>


--
Rodrigo Azevedo Moreira da Silva

Reply | Threaded
Open this post in threaded view
|

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

Ryan Ford-2
In reply to this post by Luiz Henrique de Figueiredo
On Wed, 29 May 2019 21:38:13 -0300
Luiz Henrique de Figueiredo <[hidden email]> wrote:

> Lua 5.4.0 (alpha-rc1) is now available for testing
> This is an alpha version. Some details may change in the final version.

I want to say first I like the feature list, mostly. I'm a little confused about the need/usecase for warn() over print or protected calls etc. Secondly - I'm a big fan of how smooth and beautiful Lua's syntax is and I think the `local <const> lang = 'Lua'` syntax is not very aesthetic or smooth. I like the idea we'll be getting constants, but I hope the syntax can be looked at a bit more. If <const> is only an attribute on local variables, would it be better to just add a new const keyword. JS has let and const that would be similar to local and const in Lua. I'm sure adding keywords can be a slippery slope though.

Just my input in some minimal testing. Appreciate all the effort that went in and congrats on moving to an RC

Reply | Threaded
Open this post in threaded view
|

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

Tony Papadimitriou
I second that! This <const> format is just plain ugly to me!  Then again,
beauty is in the eyes of the ... Lua team! :)

-----Original Message-----
From: Ryan Ford
Sent: Thursday, May 30, 2019 11:29 AM
To: [hidden email]
Subject: Re: [ANN] Lua 5.4.0 (alpha-rc1) now available

On Wed, 29 May 2019 21:38:13 -0300
Luiz Henrique de Figueiredo <[hidden email]> wrote:

> Lua 5.4.0 (alpha-rc1) is now available for testing
> This is an alpha version. Some details may change in the final version.

I want to say first I like the feature list, mostly. I'm a little confused
about the need/usecase for warn() over print or protected calls etc.
Secondly - I'm a big fan of how smooth and beautiful Lua's syntax is and I
think the `local <const> lang = 'Lua'` syntax is not very aesthetic or
smooth. I like the idea we'll be getting constants, but I hope the syntax
can be looked at a bit more. If <const> is only an attribute on local
variables, would it be better to just add a new const keyword. JS has let
and const that would be similar to local and const in Lua. I'm sure adding
keywords can be a slippery slope though.

Just my input in some minimal testing. Appreciate all the effort that went
in and congrats on moving to an RC


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 Luiz Henrique de Figueiredo
Manual @ http://www.lua.org/work/doc/manual.html#3.3.7

Typo: wich declares  =>  which declares


> On 30 May 2019, at 02:38, 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
>


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 Luiz Henrique de Figueiredo


> On 30 May 2019, at 02:38, 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

From the what I read about “to-be-closed” [1], the difference with an “__gc” method is that is doesn’t wait for the GC cycle to kick in, but it is invoked immediately when the variable goes out-of-scope. So it has deterministic timing over “__gc”.

If this is the case (please correct me if I’m wrong). Then why isn’t it just a flag on a meta-table? The meta table must be there already (since a requirement is to have an __gc method). One could even consider extending “__mode” to carry an extra character; "__mode = ‘kvc’ “.


Thijs

[1] http://www.lua.org/work/doc/manual.html#3.3.8
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 Luiz Henrique de Figueiredo


> On 30 May 2019, at 02:38, 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
>

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.

Also what would be the order? Say 2 to-be-closed ones in such a coroutine that gets garbage collected, will the order be __close, __close, __gc, __gc, or would it be __close, __gc, __close, __gc ?

Thijs

Reply | Threaded
Open this post in threaded view
|

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

Rodrigo Azevedo
In reply to this post by Luiz Henrique de Figueiredo
The performance (GC) is excellent again, thank you very much!

Just one question about a local <toclose>

I) it is a <const> : cannot be changed;
II) it is predictable: if out of scope;
III) it is ordered: it is closed in the reversed order of declaration;

Is <toclose> essentially an hypothetical '<gc>' with those three main
characteristics above?

If true, then why not consider to default (mark) *all* 'local' to be
collected as soon as possible (when out of scope), at the given
reversed order, by the garbage collector (call __gc)? It is II) and
III) above compatible, and can be explicit '<const> '-ed with the only
difference (I think) being the wait of start a garbage collector
cycle, which can be easily triggered by 'collectgarbage'.

Thanks!


Em qua, 29 de mai de 2019 às 21:38, Luiz Henrique de Figueiredo
<[hidden email]> escreveu:

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


--
Rodrigo Azevedo Moreira da Silva

Reply | Threaded
Open this post in threaded view
|

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

Sergey Zakharchenko
In reply to this post by Luiz Henrique de Figueiredo
Hello list,

The documentation entry on lua_newthread still says: "There is no
explicit function to close or to destroy a thread.". Now, with
lua_resetthread, seems like there is, right?

While here: doesn't it make sense to make lua_resetthread /
coroutine.kill naming more consistent, possibly having 'close' in the
names to reflect functionality? Is it too late?

Best regards,

--
DoubleF

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 Luiz Henrique de Figueiredo
On Thu, May 30, 2019 at 12:38 AM 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

Thanks for the nice alpha!

Section "3.3.8 - To-be-closed Variables":  What happens when several
closing methods error?

For example: if x and y are declared <toclose>  (x is declared first
then y), y closing method is called and errors.

form the manual ("the other pending closing methods will still be
called"), x closing method will be called. If it also errors, what
error will be raised?

Is it the first or the last of the closing errors?

Maybe it could be specified in the manual after the "the other pending
closing methods will still be called" sentence.

Phil

Reply | Threaded
Open this post in threaded view
|

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

phlnc8
Still in section "3.3.8 - To-be-closed Variables", about several
closing method errors:

To quickly test in the Lua REPL, I did:

    > smt = getmetatable('a')
    > function function smt.__close(s) error("err closing ".. s) end

Test with one error:

    > do local <toclose> x='XX' end

    stdin:1: err closing XX
    stack traceback:
        [C]: in function 'error'
        stdin:1: in function <stdin:1>
        stdin:1: in main chunk
        [C]: in ?

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?

Phil

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 Rodrigo Azevedo
> teste.lua
>
> local teste0 = 'stringteste0'
> local <const> teste1 = 'stringteste1'
> local teste2 = 'stringteste2'
> local <toclose> teste3 = 'stringteste3'
> local teste4 = 'stringteste4'
>
> lua teste.lua
> lua: teste.lua:5: attempt to close non-closable variable 'teste4'
> stack traceback:
>     teste.lua:5: in main chunk
>     [C]: in ?
>
> Should it be 'teste3' instead of 'teste4'?

Yes.


> Am I missing something?

I don't think so. We will have a look into that.

Apparently, the problem is related to vararg functions. (A main block
is a vararg function.)

The following is wrong:

  function x (...)
    local <toclose> teste3 = 'stringteste3'
  end
 
  x()
  --> lua: temp:3: attempt to close non-closable variable '(temporary)'

The following is correct:

  function x (a)
    local <toclose> teste3 = 'stringteste3'
  end
 
  x()
  --> lua: temp:3: attempt to close non-closable variable 'teste3'

-- Roberto

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 Thijs Schreijer
>
>
> > On 30 May 2019, at 02:38, 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
>
> >From the what I read about “to-be-closed” [1], the difference with an “__gc” method is that is doesn’t wait for the GC cycle to kick in, but it is invoked immediately when the variable goes out-of-scope. So it has deterministic timing over “__gc”.
>
> If this is the case (please correct me if I’m wrong). Then why isn’t it just a flag on a meta-table? The meta table must be there already (since a requirement is to have an __gc method). One could even consider extending “__mode” to carry an extra character; "__mode = ‘kvc’ “.

What goes out of scope are variables, not values. What get metatables
are values, not variables.

-- Roberto

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 Thijs Schreijer
> 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

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 Rodrigo Azevedo
> If true, then why not consider to default (mark) *all* 'local' to be
> collected as soon as possible (when out of scope), at the given
> reversed order, by the garbage collector (call __gc)?

function newfile (name)
  local f = io.open(name)
  return f
end   -- oops; 'f' goes out of scope, file is closed.

Again, what goes out of scope are variables, not values.

-- Roberto

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 Sergey Zakharchenko
> The documentation entry on lua_newthread still says: "There is no
> explicit function to close or to destroy a thread.". Now, with
> lua_resetthread, seems like there is, right?

Yes, thanks.


> While here: doesn't it make sense to make lua_resetthread /
> coroutine.kill naming more consistent, possibly having 'close' in the
> names to reflect functionality? Is it too late?

Not too late at all. (This is a release *candidate* for *alpha*.)

-- Roberto

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
30.05.2019, 02:38, "Luiz Henrique de Figueiredo" <[hidden email]>:
> 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.

:D


Reply | Threaded
Open this post in threaded view
|

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

Luiz Henrique de Figueiredo
> 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.

Reply | Threaded
Open this post in threaded view
|

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

Xavier Wang
In reply to this post by Luiz Henrique de Figueiredo


Luiz Henrique de Figueiredo <[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?

P.S. the new syntax is ugly, indeed :-(


--
regards,
Xavier Wang.
12345