[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

François Perrad


Le jeu. 30 mai 2019 à 02:38, Luiz Henrique de Figueiredo <[hidden email]> a écrit :
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.

find in attachment some fixes for minor issues (found with a linter).

François

 
--lhf


0001-missing-static.patch (618 bytes) Download Attachment
0003-fix-indentation.patch (722 bytes) Download Attachment
0002-fallthrough-comment.patch (504 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Rob Kendrick-2
In reply to this post by Ryan Ford-2
On Thu, May 30, 2019 at 04:29:32PM +0800, Ryan Ford wrote:

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

I'm going to be controversial here and say I like this syntax.  It has a
few pleasing properties: does not introduce new keywords, does not break
existing code, extensible to other decorations in future (perhaps even
at runtime).

My only wish is that they could be applied to function arguments, too.

B.

Reply | Threaded
Open this post in threaded view
|

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

Ryan Ford-2
On Fri, 31 May 2019 08:48:03 +0100
Rob Kendrick <[hidden email]> wrote:

> It has a few pleasing properties: does not introduce new keywords, does not break
> existing code, extensible to other decorations in future

I agree adding new keywords is probably not a great idea. But maybe we can agree that the syntax feels "foreign" to the existing syntax.

In PiL 16.4 about Privacy in OOP it says "If you do not want to access something inside and object, just *do not do it*." I think the same could be said about changing the values of constants. We already have ways of creating read only variables with metatables and proxies, or enclosed variables which seems a much more idiomatic solution than the new syntax. Yes I realize both methods have overhead.

Reply | Threaded
Open this post in threaded view
|

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

Gavin Wraith
In message <[hidden email]>
          Ryan Ford <[hidden email]> wrote:
> But maybe we can agree that the syntax feels "foreign" to the existing syntax.

Surely that is only because we are not used to it. I certainly think

function (myfile)
   local <toclose> f = io.open (myfile, "r")
   return f:read "*all"
   end

is snappier than

function (myfile)
   local f = io.open (myfile, "r")
   local s = f:read "*all"
   f:close ( )
   return s
   end

The __close event seems to me a logical extension of Lua's reflexive
capabilities.

--
Gavin Wraith ([hidden email])
Home page: http://www.wra1th.plus.com/

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 Vinicius Jarina
> 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).

We had no warnings in clang; it depends on the version of clang you are
using :-)

Most of these warnings shows a problem in clang, not in Lua. A trivial
flow analysis would convince it that, where it claims "variable
'X' may be uninitialized", it can't. If I do the correction it
suggests, a compiler with a good flow analysis could complain that the
initialization value is never used. And a not-so-good compiler
would generate extra code to be executed for nothing. (If the compiler
is good enough to realize that the extra suggested '= 0.0' is dead
code, it should be equally able to realize that the variable cannot be
used uninitialized in the original code.)

I really don't know how to satisfy this clang.

-- 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 François Perrad
> find in attachment some fixes for minor issues (found with a linter).

Many thanks,

-- 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 Rob Kendrick-2
> My only wish is that they could be applied to function arguments, too.

There are at least two problems with <toclose> applied to function
arguments:

- it is strange that a function must close something it did not open;

- there may be a "long" distance between the time the argument is
created and the time the function actually starts running (the
computation of extra arguments, stack allocation, etc.). Any error
during that period would not close the value.

For <const> I already commented in another post.

-- 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 Roberto Ierusalimschy
> 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).

If I understood correctly, you compiled with a lot of extra "-W*" options.
We certainly prefer no warnings on clang, but not no warnings for all
"-W*" options. After all, they are not part of '-Wall' for a reason.
What was your criteria for choosing those options?

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Andrew Gierth
In reply to this post by Ryan Ford-2
>>>>> "Ryan" == Ryan Ford <[hidden email]> writes:

 Ryan> I want to say first I like the feature list, mostly. I'm a little
 Ryan> confused about the need/usecase for warn() over print or
 Ryan> protected calls etc.

So I'm guessing that the warning system was added primarily to have a
way to report errors in GC rather than throwing them out to a random
caller, and that providing a warn() function at Lua level is more out of
completeness than anything else.

I would like to suggest that the Lua-level warn() function should not
expose the second argument at all, and should be changed to just be
warn(message). The message continuation stuff is obviously there to
allow messages to be generated in parts without allocating memory,
but in my environment I would need to reassemble the message anyway,
and exposing a warn() function that relies on the user correctly
indicating the end of a message would be a problem.

That said, why have the "tocont" argument rather than doing it
printf-style? i.e. make the signature of the user-supplied warning
function take a va_list, a la vfprintf.

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

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

Matthew Wild
On Fri, 31 May 2019 at 14:08, Andrew Gierth <[hidden email]> wrote:
>

> I would like to suggest that the Lua-level warn() function should not
> expose the second argument at all, and should be changed to just be
> warn(message). The message continuation stuff is obviously there to
> allow messages to be generated in parts without allocating memory,
> but in my environment I would need to reassemble the message anyway,
> and exposing a warn() function that relies on the user correctly
> indicating the end of a message would be a problem.

I agree that `tocont` is a bit annoying (for the warn handler). In our
case we would probably want to collect into a single string and emit
it as a single log message. I am happy to trust that Lua itself would
always do a final call without tocont, but I would worry about an
accidental mistake in a script (ranging from an error occuring before
a call without tocont, to someone forgetting string.gsub's second
result - tocont happily accepts numbers).

Regards,
Matthew

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 Roberto Ierusalimschy
This is the default of Apple for iOS, tvOS and watchOS projects. I've just created a new embedded framework project and dropped the Lua source code. :-)
Maybe Apple is being too pedantic with the warning flags?

On Fri, May 31, 2019 at 8:59 AM Roberto Ierusalimschy <[hidden email]> wrote:
> 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).

If I understood correctly, you compiled with a lot of extra "-W*" options.
We certainly prefer no warnings on clang, but not no warnings for all
"-W*" options. After all, they are not part of '-Wall' for a reason.
What was your criteria for choosing those options?

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

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

 Andrew> So I'm guessing that the warning system was added primarily to
 Andrew> have a way to report errors in GC rather than throwing them out
 Andrew> to a random caller,

Ugh, and I've just realized that this is ANOTHER thing that breaks my
error handling, because it means that if, for example, closing a
database cursor (in its __gc method) causes an error, that error will be
caught in the GC and not propagated, and there's no way out.

I understand that handling errors in GC is tricky, but having a place
where errors are caught and then ignored is a complete showstopper in an
environment where errors MUST be propagated up to a point where they can
be safely handled (and no, this can't be done inside the __gc method
itself).

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

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

Gé Weijers

On Fri, May 31, 2019 at 8:37 AM Andrew Gierth <[hidden email]> wrote:
I understand that handling errors in GC is tricky, but having a place
where errors are caught and then ignored is a complete showstopper in an
environment where errors MUST be propagated up to a point where they can
be safely handled (and no, this can't be done inside the __gc method
itself).


The problem is that there's no 'up' to propagate to. If the GC would throw an error it lands in a random block of code, which means that your code would have to be able to handle any error in any location, and using third-party libraries would be very risky.

This problem is not limited to Lua, in C# the 'Dispose' method of an object may be called from a thread unrelated to your program, which is owned by the GC, and handling an error there is even trickier.

Code called from __gc should only release resources and such, and handle its own errors. The new generational GC may delay the call to __gc for a *long* time, so if you can use the new __close metamethod you probably should use that instead.


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 Andrew Gierth
> That said, why have the "tocont" argument rather than doing it
> printf-style? i.e. make the signature of the user-supplied warning
> function take a va_list, a la vfprintf.

Any suggestion about how to export that to Lua? That is, how to
implementt a "warn(msg1, msg2, ..., msgN)" for Lua with a single
call to such a lua_warn?

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Andrew Gierth
In reply to this post by Gé Weijers
>>>>> "Gé" == Gé Weijers <[hidden email]> writes:

 >> I understand that handling errors in GC is tricky, but having a
 >> place where errors are caught and then ignored is a complete
 >> showstopper in an environment where errors MUST be propagated up to
 >> a point where they can be safely handled (and no, this can't be done
 >> inside the __gc method itself).

 Gé> The problem is that there's no 'up' to propagate to. If the GC
 Gé> would throw an error it lands in a random block of code, which
 Gé> means that your code would have to be able to handle any error in
 Gé> any location, and using third-party libraries would be very risky.

But from the perspective of Lua code, errors _can_ be thrown in any
location - consider "out of memory" as an example - and they propagate
up to a well-defined place, i.e. the nearest enclosing pcall.

 Gé> This problem is not limited to Lua,

I could not care less about other languages.

 Gé> Code called from __gc should only release resources and such, and
 Gé> handle its own errors.

But I am working in an environment - embedding Lua into an existing
large and complex program, namely the PostgreSQL backend - which has its
own rules about error handling that simply do not allow this. In
particular, I can't guarantee that closing a database cursor won't throw
an error, and if it does, then I can't allow execution of arbitrary Lua
code until after the subtransaction has been cleaned up (which requires
propagating the error).

 Gé> The new generational GC may delay the call to __gc for a *long*
 Gé> time,

This doesn't matter to me.

 Gé> so if you can use the new __close metamethod you probably should
 Gé> use that instead.

There is no "instead". __gc and __close serve very different purposes.

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

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

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

 >> That said, why have the "tocont" argument rather than doing it
 >> printf-style? i.e. make the signature of the user-supplied warning
 >> function take a va_list, a la vfprintf.

 Roberto> Any suggestion about how to export that to Lua? That is, how
 Roberto> to implementt a "warn(msg1, msg2, ..., msgN)" for Lua with a
 Roberto> single call to such a lua_warn?

Do you need to?

I don't see any strong reason why the Lua warn() should take multiple
parameters, since the caller can always construct their own warning
string.

--
Andrew.

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 Andrew Gierth
> But I am working in an environment - embedding Lua into an existing
> large and complex program, namely the PostgreSQL backend - which has its
> own rules about error handling that simply do not allow this. In
> particular, I can't guarantee that closing a database cursor won't throw
> an error, and if it does, then I can't allow execution of arbitrary Lua
> code until after the subtransaction has been cleaned up (which requires
> propagating the error).

I fully agree that finalizers should not throw errors. If closing a
database cursor must throw an error and you can't allow execution of
arbitrary Lua code etc., then probably you shouldn't close cursors
during finalizers. Instead, for instance, the finalizer would
only prepare some data indicating that the cursor must be closed.
Periodically (e.g., when creating new cursors?), your program should
consult this data and close cursors if needed.

As Gé pointed out, propagating a finalizer error is pointless. You
are interrupting code that has nothing to do with the error, and
cannot know how to handle it.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Sean Conner
In reply to this post by Andrew Gierth
It was thus said that the Great Andrew Gierth once stated:

> >>>>> "Roberto" == Roberto Ierusalimschy <[hidden email]> writes:
>
>  >> That said, why have the "tocont" argument rather than doing it
>  >> printf-style? i.e. make the signature of the user-supplied warning
>  >> function take a va_list, a la vfprintf.
>
>  Roberto> Any suggestion about how to export that to Lua? That is, how
>  Roberto> to implementt a "warn(msg1, msg2, ..., msgN)" for Lua with a
>  Roberto> single call to such a lua_warn?
>
> Do you need to?
>
> I don't see any strong reason why the Lua warn() should take multiple
> parameters, since the caller can always construct their own warning
> string.

  I would prefer:

        warn("The %s is at %d blahs, we're about to blow!",foo,level)

instead of:

        warn(string.format("The %s is at %d blahs, we're about to blow!",foo,level))

And I know I can always do:

        do
          local syswarn = warn
          function warn(fmt,...)
            return syswarn(string.format(fmt,...))
          end
        end

but to me, that's sub-optimal.

  -spc


Reply | Threaded
Open this post in threaded view
|

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

Sean Conner
In reply to this post by Roberto Ierusalimschy
It was thus said that the Great Roberto Ierusalimschy once stated:
> > 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).
>
> If I understood correctly, you compiled with a lot of extra "-W*" options.
> We certainly prefer no warnings on clang, but not no warnings for all
> "-W*" options. After all, they are not part of '-Wall' for a reason.
> What was your criteria for choosing those options?

  What Roberto said.  

  I've tried compiling code with "clang -Weverything" and it's rather
amusing.  One of the "warnings" was that padding bytes were being added to a
structure, yet if I turned off padding, I got a warning about the lack of
padding bytes!

  -spc

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 Rodrigo Azevedo
On 30/05/2019 15.53, Rodrigo Azevedo wrote:
> The performance (GC) is excellent again, thank you very much!

Can confirm, garbage collector performance is good:

    /tmp/lua-5.3.5/src $ time ./lua gc_benchmark.lua
    Lua 5.3

    real  0m44.687s
    user  0m42.724s
    sys  0m1.964s

    /tmp/lua-5.4.0-alpha/src $ time ./lua gc_benchmark.lua
    Lua 5.4

    real  0m42.717s
    user  0m40.920s
    sys  0m1.800s

-- gc_bechmark.lua (
local num_iterations = 1e8
local table_width = 1e8

print(_VERSION)

math.randomseed(os.time())
-- collectgarbage('stop')

local t = {}
for i = 1, num_iterations do
  t[math.random(table_width)] = {}
end
-- )

-- Martin

12345