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

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

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

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

The checksums are
        MD5 d49d30b394794b96ffad53513ac647a5  -
        SHA1 cf3559dc43cad35463740c6fbedeb1ea501e5e23  -

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 alpha-rc1 to alpha-rc2 are available at
        http://www.lua.org/work/diffs-lua-5.4.0-alpha-rc1-rc2.html
        http://www.lua.org/work/diffu-lua-5.4.0-alpha-rc1-rc2.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.
We welcome feedback on this, which is new, especially more uname targets
with explicit rules and fixes for existing ones.

We also welcome feedback on the listings output by luac -l -l, because
luac has been rewritten to account for the new VM instructions.

All feedback welcome. Thanks.
--lhf

Reply | Threaded
Open this post in threaded view
|

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

phlnc8
On Thu, Jun 6, 2019 at 11:34 PM Luiz Henrique de Figueiredo
<[hidden email]> wrote:
>
> Lua 5.4.0 (alpha-rc2) is now available for testing at
>         http://www.lua.org/work/lua-5.4.0-alpha-rc2.tar.gz

Thanks for the rc2.

Looking at the executable sizes, I noticed a size increase compared to
Lua-5.3.5:

dynamically linked with glibc, stripped

  lua-5.3.5  219,912
  lua-5.4.0-alpha-rc2  248,584
    +28,672 bytes (~ +13%)

statically linked with musl libc and linenoise(*), stripped

  lua-5.3.5  219,016
  lua-5.4.0-alpha-rc2  247,688
    +28,672 (~ +13%)

This is  compiled with gcc 5.5 on linux x86_64
(*) linoise is a nice lightweight replacement for readline.

Out of curiosity, what is the main factor in the size increase?  the
new gc?  or is it some debug/test code that will go away?

Phil

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
> Looking at the executable sizes, I noticed a size increase compared to
> Lua-5.3.5:
>
> [...]
>
> Out of curiosity, what is the main factor in the size increase?  the
> new gc?  or is it some debug/test code that will go away?

Of course the new gc adds code, as does to-be-closed variables. But I
think the larger increase comes from the new specialized opcodes. (Lua
5.3 has ~47 opcodes, Lua 5.4 has ~84.)

Checking the size of the .o files, these are the main increases:

- gc alone accounts for ~5 KB.
- the interpreter loop gets more 8 ~KB.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Luiz Henrique de Figueiredo
In reply to this post by Luiz Henrique de Figueiredo
Lua 5.4.0 (alpha-rc2) remains available for testing at http://www.lua.org/work

Lua 5.4.0 (alpha) will be frozen very soon. Now is the time to report any glitches.

All feedback welcome. Thanks.
--lhf
Reply | Threaded
Open this post in threaded view
|

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

Daurnimator
On Tue, 11 Jun 2019 at 23:11, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
> Lua 5.4.0 (alpha) will be frozen very soon.
>
> All feedback welcome. Thanks.

I've stayed quiet so far as I've been waiting for the new syntax to grow on me.
However... I can't say it has yet.

  - local <const> feels awkward for what should almost be the default
variable type
    I see myself wanting to have const variables far more than plain
locals, which
    suggests that a *shorter* syntax would be preferable. Several
other languages
    have gone with simply `const` (which would replace "local" when
you want to make
    a modifiable varible; rather than as a qualifier/attribute)

do
    const x = 1
    local y = 2
    x = "something else" -- error: attempt to assign to const variable
end

  - Similarly other languages have `defer` as a similar concept to
"toclose": to try and
    shoehorn it into lua: a defer block could run when the current
lexical scope finishes:

local contents
do
    local f = io.open("myfile")
    defer f:close() end
    contents = f:read()
end

  - To response to Hisham's suggestion of variable annotations, I do
like the idea;
     however I don't think that const nor toclose match what I expect
from annotations.

  - I'm unsatisfied with the response to Andrew Gierth's comment about
ensuring that
    errors are propagated to the embedder: I think it's crucial to
lua's use as an
    embeddable language
    I *think* the solution should be that an error in a <toclose>
should be immediately rethrown
    and that other <toclose> statements don't get to run.

  - Now that lua_gc is a vararg, perhaps LUA_GCCOUNTB could be deprecated?
    (instead have a single COUNT opcode that receives two out-args?)

  - Could we add a shared library target to the Makefile? I think this
is a reasonable patch:
    https://git.archlinux.org/svntogit/packages.git/tree/trunk/liblua.so.patch?h=packages/lua

Reply | Threaded
Open this post in threaded view
|

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

Coda Highland

On Tue, Jun 11, 2019 at 11:15 AM Daurnimator <[hidden email]> wrote:
  - I'm unsatisfied with the response to Andrew Gierth's comment about
ensuring that
    errors are propagated to the embedder: I think it's crucial to
lua's use as an
    embeddable language
    I *think* the solution should be that an error in a <toclose>
should be immediately rethrown
    and that other <toclose> statements don't get to run.

I STRONGLY disagree. The contract is that <toclose> runs no matter how the function exits, as long as it does in fact exit.

/s/ Adam
Reply | Threaded
Open this post in threaded view
|

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

Luiz Henrique de Figueiredo
In reply to this post by Daurnimator
>   - Could we add a shared library target to the Makefile? I think this
> is a reasonable patch:
>     https://git.archlinux.org/svntogit/packages.git/tree/trunk/liblua.so.patch?h=packages/lua

This patch is for Linux only, right? In this case, it may need to
recompile the sources with -fPIC.
The recipe for shared libraries for macOS is different: it uses
"-bundle -undefined dynamic_lookup" instead of "-shared" and doesn't
need  -fPIC.

Reply | Threaded
Open this post in threaded view
|

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

Andrew Gierth
In reply to this post by Coda Highland
>>>>> "Coda" == Coda Highland <[hidden email]> writes:

 >> - I'm unsatisfied with the response to Andrew Gierth's comment about
 >> ensuring that errors are propagated to the embedder: I think it's
 >> crucial to lua's use as an embeddable language

 >> I *think* the solution should be that an error in a <toclose> should
 >> be immediately rethrown and that other <toclose> statements don't
 >> get to run.

 Coda> I STRONGLY disagree. The contract is that <toclose> runs no
 Coda> matter how the function exits, as long as it does in fact exit.

I also disagree with Daurnimator's solution. I can, just about, work
with the current <toclose> definition by ensuring that the user-supplied
code can't ever create objects with __close metamethods. This is
obviously a serious restriction, but it ensures that the user can't put
arbitrary code into the error recovery path, which is all I need.

What I can't handle is the ignoring of errors in GC.

One solution I'm wondering about (as I hinted at earlier) is whether it
would be sufficient to allow the environment to supply some kind of
function that would be used as a handler for all __gc calls (and maybe
also for __close calls whose errors would otherwise be ignored). (Since
such errors should be rare, the environment might decide to treat them
as fatal, a better option than crashing or corrupting the database.)

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

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

Coda Highland


On Tue, Jun 11, 2019 at 12:05 PM Andrew Gierth <[hidden email]> wrote:
>>>>> "Coda" == Coda Highland <[hidden email]> writes:

 >> - I'm unsatisfied with the response to Andrew Gierth's comment about
 >> ensuring that errors are propagated to the embedder: I think it's
 >> crucial to lua's use as an embeddable language

 >> I *think* the solution should be that an error in a <toclose> should
 >> be immediately rethrown and that other <toclose> statements don't
 >> get to run.

 Coda> I STRONGLY disagree. The contract is that <toclose> runs no
 Coda> matter how the function exits, as long as it does in fact exit.

I also disagree with Daurnimator's solution. I can, just about, work
with the current <toclose> definition by ensuring that the user-supplied
code can't ever create objects with __close metamethods. This is
obviously a serious restriction, but it ensures that the user can't put
arbitrary code into the error recovery path, which is all I need.

What I can't handle is the ignoring of errors in GC.

One solution I'm wondering about (as I hinted at earlier) is whether it
would be sufficient to allow the environment to supply some kind of
function that would be used as a handler for all __gc calls (and maybe
also for __close calls whose errors would otherwise be ignored). (Since
such errors should be rare, the environment might decide to treat them
as fatal, a better option than crashing or corrupting the database.)

--
Andrew.


I think I like that. You can already define a panic handler for errors thrown in an unprotected call. Defining a handler for errors thrown in uncatchable areas would be a good counterpart.

/s/ Adam
Reply | Threaded
Open this post in threaded view
|

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

Doug Currie
On Tue, Jun 11, 2019 at 11:15 AM Daurnimator <[hidden email]> wrote: 
local contents
do
    local f = io.open("myfile")
    defer f:close() end
    contents = f:read()
end

If we're adding keywords...

local contents
local f = io.open("myfile")
do
    contents = f:read()
finally
    f:close()
end

 This obviates the need for __close handling, and makes all the discussion about panic handlers and __gc moot since we would have control over the order of "closing"  and the handling of errors with nested do... finally... end and pcall.

e


On Tue, Jun 11, 2019 at 1:14 PM Coda Highland <[hidden email]> wrote:


On Tue, Jun 11, 2019 at 12:05 PM Andrew Gierth <[hidden email]> wrote:
>>>>> "Coda" == Coda Highland <[hidden email]> writes:

 >> - I'm unsatisfied with the response to Andrew Gierth's comment about
 >> ensuring that errors are propagated to the embedder: I think it's
 >> crucial to lua's use as an embeddable language

 >> I *think* the solution should be that an error in a <toclose> should
 >> be immediately rethrown and that other <toclose> statements don't
 >> get to run.

 Coda> I STRONGLY disagree. The contract is that <toclose> runs no
 Coda> matter how the function exits, as long as it does in fact exit.

I also disagree with Daurnimator's solution. I can, just about, work
with the current <toclose> definition by ensuring that the user-supplied
code can't ever create objects with __close metamethods. This is
obviously a serious restriction, but it ensures that the user can't put
arbitrary code into the error recovery path, which is all I need.

What I can't handle is the ignoring of errors in GC.

One solution I'm wondering about (as I hinted at earlier) is whether it
would be sufficient to allow the environment to supply some kind of
function that would be used as a handler for all __gc calls (and maybe
also for __close calls whose errors would otherwise be ignored). (Since
such errors should be rare, the environment might decide to treat them
as fatal, a better option than crashing or corrupting the database.)

--
Andrew.


I think I like that. You can already define a panic handler for errors thrown in an unprotected call. Defining a handler for errors thrown in uncatchable areas would be a good counterpart.

/s/ Adam
Reply | Threaded
Open this post in threaded view
|

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

Andrew Gierth
>>>>> "Doug" == Doug Currie <[hidden email]> writes:

 Doug> If we're adding keywords...

 Doug> local contents
 Doug> local f = io.open("myfile")
 Doug> do
 Doug>     contents = f:read()
 Doug> finally
 Doug>     f:close()
 Doug> end

 Doug> This obviates the need for __close handling, and makes all the
 Doug> discussion about panic handlers and __gc moot

Only in the sense that my objections would go away because you had made
it impossible for me to even think about using your proposed lua version
in my application.

 Doug> since we would have control

The _lua code_ would have control, which is exactly the wrong thing in a
sandbox environment - the SANDBOX must be in control, not the
user-supplied (and therefore untrusted) code.

I raised this point back when the <toclose> proposal allowed the
provision of a function value (and therefore arbitrary lua code).

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

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

Tony Papadimitriou
In reply to this post by Doug Currie
Any why not reuse a keyword?
 
do
...
then
...
end
 
local contents
local f = io.open("myfile")
do
    contents = f:read()
finally
    f:close()
end
 
This obviates the need for __close handling, and makes all the discussion about panic handlers and __gc moot since we would have control over the order of "closing"  and the handling of errors with nested do... finally... end and pcall.
 
Reply | Threaded
Open this post in threaded view
|

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

pocomane
In reply to this post by Doug Currie


Il mar 11 giu 2019, 20:14 Doug Currie <[hidden email]> ha scritto:
On Tue, Jun 11, 2019 at 11:15 AM Daurnimator <[hidden email]> wrote: 
local contents
do
    local f = io.open("myfile")
    defer f:close() end
    contents = f:read()
end

I was going to post something like this multiple times in the past months. I thought that I was going to use <toclose> to build a wrapper for a Go-like defer in the 99% of my code.

But then I realized that I was missing the point. The <toclose> mechanism let you to do actual RAII returning objects that are able to close themself, you only have to decide when. E.g.:

local <toclose> x = my_complex_object_factory()

VS

local x = my_complex_object_factory()
...
return x

Right now, my only complain with the <toclose> is the term "close" that I found a bit vague and over-loaded (conceptually).

Well... And the error handling things that arised in other threads of this mailing list.


If we're adding keywords...

local contents
local f = io.open("myfile")
do
    contents = f:read()
finally
    f:close()
end

Imho this miss the point even more since the closing stuff is very distant from the initialization. What is the difference with just calling "close" at end of the scope?

Reply | Threaded
Open this post in threaded view
|

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

Soni "They/Them" L.
In reply to this post by Andrew Gierth


On 2019-06-11 2:05 p.m., Andrew Gierth wrote:

> >>>>> "Coda" == Coda Highland <[hidden email]> writes:
>
>   >> - I'm unsatisfied with the response to Andrew Gierth's comment about
>   >> ensuring that errors are propagated to the embedder: I think it's
>   >> crucial to lua's use as an embeddable language
>
>   >> I *think* the solution should be that an error in a <toclose> should
>   >> be immediately rethrown and that other <toclose> statements don't
>   >> get to run.
>
>   Coda> I STRONGLY disagree. The contract is that <toclose> runs no
>   Coda> matter how the function exits, as long as it does in fact exit.
>
> I also disagree with Daurnimator's solution. I can, just about, work
> with the current <toclose> definition by ensuring that the user-supplied
> code can't ever create objects with __close metamethods. This is
> obviously a serious restriction, but it ensures that the user can't put
> arbitrary code into the error recovery path, which is all I need.
>
> What I can't handle is the ignoring of errors in GC.
>
> One solution I'm wondering about (as I hinted at earlier) is whether it
> would be sufficient to allow the environment to supply some kind of
> function that would be used as a handler for all __gc calls (and maybe
> also for __close calls whose errors would otherwise be ignored). (Since
> such errors should be rare, the environment might decide to treat them
> as fatal, a better option than crashing or corrupting the database.)
>

can't you just use coroutines? what's so special about __close that
makes you uncomfortable? does it break hooks just like __gc does? that
doesn't seem to make sense, as __close happens deterministically and
thus it makes sense to debug __close.

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
In reply to this post by pocomane
> Right now, my only complain with the <toclose> is the term "close" that I
> found a bit vague and over-loaded (conceptually).

Suggestions are welcome.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Dibyendu Majumdar
> > Right now, my only complain with the <toclose> is the term "close" that I
> > found a bit vague and over-loaded (conceptually).
>
> Suggestions are welcome.
>

In Java a class must implement AutoCloseable interface to ensure auto
closing in try/finally.
In C# I believe there is a similar interface IDisposable.
In Go, there is the defer statement that allows arbitrary code to be
run at scope exit.
In D I believe there are ScopeGuard statements 'scope(exit)' ,
'scope(success)' and 'scope(failure)' that basically get lowered to
try/finally and ensure code gets executed when scope is exited. D
allows the code to be executed conditionally (success/failure) or
unconditionally (exit).

If new keywords could be introduced, then one option might be:

with <var declarations> do
...
end

This could be syntactic sugar for:

do
   local <toclose> ....
end

Advantage of new keyword is that you avoid the ugly annotations.

I also like Daurnimator proposal of:

defer ... end

But I guess that doing this would mean changing the semantics to be
like Go, i.e. there will no longer be a __close metamethod, instead
one can run some code when scope terminates.


Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

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

Viacheslav Usov
In reply to this post by Roberto Ierusalimschy
On Wed, Jun 12, 2019 at 2:46 PM Roberto Ierusalimschy <[hidden email]> wrote:
> Right now, my only complain with the <toclose> is the term "close" that I
> found a bit vague and over-loaded (conceptually).

Suggestions are welcome.

If we must stick with modifiers of local, 'scoped" seems better to me.

I would also like to request comments for another modifier: alias', to be used as follows:

local <alias> foo = bar

where bar can be any Lua expression. Following this declaration, any use of foo would be (logically) replaced with bar. To clarify, the difference with

local foo = bar

is that in the latter foo captures the value of bar when the local statement executes, so it can neither refer to the value of bar after that point, nor be used to modify the value of bar (if the expression is modifiable). To illustrate the latter point, consider:

local bar = 1
local foo = bar
foo = 2
-- the value of bar is still 1

But

local bar = 1
local <alias> foo = bar
foo = 2
-- the value of bar is now 2

Another example is 

local <alias> foo = bar.baz
foo = 42
-- the value of bar.baz is now 42

In principle, 'alias' and 'const' could be combined, so that we could say something like:

local <alias, const> for = bar.baz -- combination syntax TBD

Again the difference with local foo = bar.baz is that the former foo references the value of bar.baz even if it changes after the declaration of foo.

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

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

Doug Currie
In reply to this post by pocomane
local contents
local f = io.open("myfile")
do
    contents = f:read()
finally
    f:close()
end

Imho this miss the point even more since the closing stuff is very distant from the initialization. What is the difference with just calling "close" at end of the scope?

The intent here is that the code in the `finally` section is called regardless of how the scope is exited: normal exit, exception, coroutine.close, etc.

It also supports doing things besides calling __close metamethods.

e
Reply | Threaded
Open this post in threaded view
|

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

Coda Highland
In reply to this post by Viacheslav Usov


On Wed, Jun 12, 2019 at 9:20 AM Viacheslav Usov <[hidden email]> wrote:
On Wed, Jun 12, 2019 at 2:46 PM Roberto Ierusalimschy <[hidden email]> wrote:
> Right now, my only complain with the <toclose> is the term "close" that I
> found a bit vague and over-loaded (conceptually).

Suggestions are welcome.

If we must stick with modifiers of local, 'scoped" seems better to me.

+1 to "scoped", that's the term used for this in C++.

/s/ Adam
Reply | Threaded
Open this post in threaded view
|

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

Sean Conner
In reply to this post by Roberto Ierusalimschy
It was thus said that the Great Roberto Ierusalimschy once stated:
> > Right now, my only complain with the <toclose> is the term "close" that I
> > found a bit vague and over-loaded (conceptually).
>
> Suggestions are welcome.

  How about <cleanup>?

        do
          local <cleanup> file = io.open("foobar.txt")
          -- ...
        end

  -spc

123