[ANN] Lua 5.2.0 (beta-rc5) now available

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[ANN] Lua 5.2.0 (beta-rc5) now available

Luiz Henrique de Figueiredo
Lua 5.2.0 (beta-rc5) is now available at
        http://www.lua.org/work/lua-5.2.0-beta-rc5.tar.gz

MD5 401c467b6697a477cb9de6362720d962  -
SHA1 0f1f371683307f5c9d074f759b0045f702434d45  -

This is a beta version. Some details may change in the final version.

The main changes from rc4 to rc5 are:
        - 'table.pack' returns 'n' too
        - clarifications between 'deprecated' and 'removed'
        - fixed compilation error in 'luai_apicheck' with LUA_USE_APICHECK
        - removed wrong assert in lparser.c
        - reordering of some defines in lua.h

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

The complete diffs are available at
        http://www.lua.org/work/diffs-lua-5.2.0-beta-rc4-beta-rc5.txt

A test suite is available at
        http://www.lua.org/tests/5.2.0/

This release candidate will be the beta version if no glitches are found
in the next 10 days or so. We thank everyone for their feedback till now.

All feedback welcome. Thanks.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc5) now available

David Manura
On Mon, Jul 4, 2011 at 3:40 PM, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
> Lua 5.2.0 (beta-rc5) is now available [...]
>        - clarifications between 'deprecated' and 'removed'

This way of removing functions might not be ideal:

  $ make ansi
  $ ./src/lua
  Lua 5.2.0 (beta)  Copyright (C) 1994-2011 Lua.org, PUC-Rio
  > io.popen'ls'
  stdin:1: 'popen' not supported
  stack traceback:
  [C]: in function 'popen'
  stdin:1: in main chunk
  [C]: in ?
  > setfenv(function()end, {})
  stdin:1: deprecated function
  stack traceback:
  [C]: in function 'setfenv'
  stdin:1: in main chunk
  [C]: in ?

The reason is that to test whether a function exists, it is not as simple as

  if io.popen then ..... end

Rather, you need to wrap it in a pcall, and in the case of popen you
need to pass some suitable argument that probably will always work
(e.g. "echo").

Alternately, you could test versions (e.g. _VERSION).  However, the
experience with JavaScript has been that capability detection is
preferred over version detection.  For example, Opera traditionally
lied and said it was Internet Explorer to avoid false negatives, but
when you really did want to differentiate them then it got confusing
[1].

The recent discussion about whether string.foo should raise an error
[2] is related to this.

[1] http://www.sitepoint.com/why-browser-sniffing-stinks/
[2] http://lua-users.org/lists/lua-l/2011-06/msg01382.html

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc5) now available

Lorenzo Donati-2
On 04/07/2011 22.19, David Manura wrote:
> On Mon, Jul 4, 2011 at 3:40 PM, Luiz Henrique de Figueiredo
> <[hidden email]>  wrote:
>> Lua 5.2.0 (beta-rc5) is now available [...]
>>         - clarifications between 'deprecated' and 'removed'
>
> This way of removing functions might not be ideal:

I totally agree.

[...]

>
> The reason is that to test whether a function exists, it is not as simple as
>
>    if io.popen then ..... end
>
> Rather, you need to wrap it in a pcall, and in the case of popen you
> need to pass some suitable argument that probably will always work
> (e.g. "echo").
>
> Alternately, you could test versions (e.g. _VERSION).
[...]

I understand that Lua team maybe intended to warn the user that his
version of Lua doesn't support io.popen on his platform, but this seems
too much hand-holding to me.

Maybe a stronger emphasis in the manual on checking the existence of
popen before using it could be added instead.

For example (emphasis on new text):


"This function is *highly* system dependent and is not available on all
platforms. *If you are not sure whether your system supports popen,
check its existence explicitly in advance.*"

And if more hand-holding is deemed useful, add a snippet:

if io.popen then
  -- do something
end


> The recent discussion about whether string.foo should raise an error
> [2] is related to this.
>
> [1] http://www.sitepoint.com/why-browser-sniffing-stinks/
> [2] http://lua-users.org/lists/lua-l/2011-06/msg01382.html
>
>
>

-- Lorenzo

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc5) now available

Roberto Ierusalimschy
In reply to this post by David Manura
> This way of removing functions might not be ideal:
>
>   [...]
>   > setfenv(function()end, {})
>   stdin:1: deprecated function
>   stack traceback:
>   [C]: in function 'setfenv'
>   stdin:1: in main chunk
>   [C]: in ?
>
> The reason is that to test whether a function exists, it is not as simple as
>
>   if io.popen then ..... end
>
> [...]

On the other hand, I guess this message may be very useful for people
changing from 5.1 to 5.2. (Not people from the list, who has been
discussing the changes for a long time, but many (most?) programmers
not aware of all changes...)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc5) now available

Lorenzo Donati-2
On 04/07/2011 22.41, Roberto Ierusalimschy wrote:

>> This way of removing functions might not be ideal:
>>
>>    [...]
>>    >  setfenv(function()end, {})
>>    stdin:1: deprecated function
>>    stack traceback:
>>     [C]: in function 'setfenv'
>>     stdin:1: in main chunk
>>     [C]: in ?
>>
>> The reason is that to test whether a function exists, it is not as simple as
>>
>>    if io.popen then ..... end
>>
>> [...]
>
> On the other hand, I guess this message may be very useful for people
> changing from 5.1 to 5.2. (Not people from the list, who has been
> discussing the changes for a long time, but many (most?) programmers
> not aware of all changes...)
>
> -- Roberto
>
>
>
I see, but wouldn't it be better a detailed feature changelog, i.e., not
a plain diff, but an annotated list with likely gotchas?

I understand that this would be an added documentation burden for you,
but on the other hand it will contribute to clean up Lua codebase from
less useful tests (IMHO) (and, in perspective, will save you to remove
those tests in a future 5.3 release).

-- Lorenzo

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc5) now available

Pierre-Yves Gérardy
In reply to this post by Roberto Ierusalimschy
On Mon, Jul 4, 2011 at 22:41, Roberto Ierusalimschy
<[hidden email]> wrote:

>> This way of removing functions might not be ideal:
>>
>>   [...]
>>   > setfenv(function()end, {})
>>   stdin:1: deprecated function
>>   stack traceback:
>>       [C]: in function 'setfenv'
>>       stdin:1: in main chunk
>>       [C]: in ?
>>
>> The reason is that to test whether a function exists, it is not as simple as
>>
>>   if io.popen then ..... end
>>
>> [...]
>
> On the other hand, I guess this message may be very useful for people
> changing from 5.1 to 5.2. (Not people from the list, who has been
> discussing the changes for a long time, but many (most?) programmers
> not aware of all changes...)
>
> -- Roberto
>
>

That functionality would better be implemented as a small library that
would be loaded only during the porting effort.

-- Pierre-Yves

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc5) now available

David Manura
In reply to this post by David Manura
On Mon, Jul 4, 2011 at 4:19 PM, David Manura <[hidden email]> wrote:
>  > setfenv(function()end, {})
>  stdin:1: deprecated function

Correction: 5.2.0-beta-rc5 now prints "removed function" here because
setfenv is a removed (not deprecated).  However, for a function that
is deprecated, we get this:

> =module"foo"
table: 0x934b440

and if we disable LUA_COMPAT_ALL, then is does this:

> =module"foo"
stdin:1: deprecated function
stack traceback:
        [C]: in function 'module'
        stdin:1: in main chunk
        [C]: in ?

which I found a bit odd that the message about a function being
deprecated is an error rather than a warning (contrast to other
languages [1-3]).

[1] http://www.effectiveperlprogramming.com/blog/463
[2] http://download.oracle.com/javase/1.5.0/docs/guide/javadoc/deprecation/deprecation.html
[3] http://stackoverflow.com/questions/295120/c-mark-as-deprecated

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc5) now available

Roberto Ierusalimschy
> which I found a bit odd that the message about a function being
> deprecated is an error rather than a warning (contrast to other
> languages [1-3]).

Lua does not have warnings. Note that to add warnings to Lua is not
to add some 'printf's; we need some way to return warnings from 'load'.
(Multiple returns?) I do not think it is worth the complexity...

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc5) now available

Alexander Gladysh
In reply to this post by David Manura
On Tue, Jul 5, 2011 at 00:19, David Manura <[hidden email]> wrote:
> On Mon, Jul 4, 2011 at 3:40 PM, Luiz Henrique de Figueiredo
> <[hidden email]> wrote:
>> Lua 5.2.0 (beta-rc5) is now available [...]
>>        - clarifications between 'deprecated' and 'removed'

> This way of removing functions might not be ideal:

I second this.

>  stdin:1: 'popen' not supported
>  stack traceback:
>        [C]: in function 'popen'
>        stdin:1: in main chunk
>        [C]: in ?

While this one *may* be justified...

>  > setfenv(function()end, {})
>  stdin:1: deprecated function
>  stack traceback:
>        [C]: in function 'setfenv'
>        stdin:1: in main chunk
>        [C]: in ?

...This one, IMO, makes no sense. If it is deprecated, it must work.
Otherwise it is removed (and replaced with nonsense stub).

My opinion is that there must be a clear way to programmatically
determine a capability list of the given Lua interpreter. The best way
to do this — is to actually *remove* removed functions.

Uninitiated Lua 5.2 users would google up the "setfenv, attempted to
call a nil value" (or whatever) error message, and would get the
reason why this happens and what to do on the first hit. (One way to
guarantee this — is to create a quality set question+answer pairs on
the subject on StackOverflow.)

My 2c,
Alexander.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc5) now available

David Manura
In reply to this post by Roberto Ierusalimschy
On Mon, Jul 4, 2011 at 5:50 PM, Roberto Ierusalimschy
<[hidden email]> wrote:
> Lua does not have warnings. Note that to add warnings to Lua is not
> to add some 'printf's; we need some way to return warnings from 'load'.
> (Multiple returns?) I do not think it is worth the complexity...

Pierre-Yves suggestion along the printf approach might work--i.e.
writing warnings globally either to stderr or perhaps something like
print() since print is for debugging and can be more safely overridden
to redirect warning output to some other location.  I don't know if we
need informational warnings to be uniquely associated with each load
(as errors are).

2011/7/4 Pierre-Yves Gérardy <[hidden email]>:
> That functionality would better be implemented as a small library that
> would be loaded only during the porting effort.

-- warnings.lua
local debug = require 'debug'
local env = {}
for k,v in pairs(_G) do env[k] = v end
env.module = function(...)
  io.stderr:write('WARNING: module function is deprecated\n',
debug.traceback(), '\n')
  return module(...) -- [*] problem
end
return env

-- test.lua
_ENV = require "warnings"
module "test"  -- displays warning; does not raise error
print 'ok'

Although in this case of functions like module that query stack
levels, Lua has a forwarding problem [1-2], so this code won't work
entirely as advertised.

[1] http://lua-users.org/lists/lua-l/2010-01/msg01255.html
[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc5) now available

David Manura
In reply to this post by Alexander Gladysh
On Mon, Jul 4, 2011 at 5:58 PM, Alexander Gladysh <[hidden email]> wrote:
> ...This one, IMO, makes no sense.
My mistake (see correction posted above).

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc5) now available

Sam Roberts
In reply to this post by Lorenzo Donati-2
On Mon, Jul 4, 2011 at 1:34 PM, Lorenzo Donati
<[hidden email]> wrote:

> On 04/07/2011 22.19, David Manura wrote:
>>
>> On Mon, Jul 4, 2011 at 3:40 PM, Luiz Henrique de Figueiredo
>> <[hidden email]>  wrote:
>>>
>>> Lua 5.2.0 (beta-rc5) is now available [...]
>>>        - clarifications between 'deprecated' and 'removed'
>>
>> This way of removing functions might not be ideal:
>
> I totally agree.

I agree, implementing something that doesn't exist, only to report its
non-existence seems confusing.

Checking for existence with an if io.popen is easier, and asserting a
dependency on its existence is easy, too, with

assert(io.popen)

Cheers,
Sam

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc5) now available

liam mail
In reply to this post by Pierre-Yves Gérardy
On Monday, 4 July 2011, Pierre-Yves Gérardy <[hidden email]> wrote:
&gt; On Mon, Jul 4, 2011 at 22:41, Roberto Ierusalimschy
&gt; &lt;[hidden email]&gt; wrote:
&gt;&gt;&gt; This way of removing functions might not be ideal:
&gt;&gt;&gt;
&gt;&gt;&gt;   [...]
&gt;&gt;&gt;   &gt; setfenv(function()end, {})
&gt;&gt;&gt;   stdin:1: deprecated function
&gt;&gt;&gt;   stack traceback:
&gt;&gt;&gt;       [C]: in function 'setfenv'
&gt;&gt;&gt;       stdin:1: in main chunk
&gt;&gt;&gt;       [C]: in ?
&gt;&gt;&gt;
&gt;&gt;&gt; The reason is that to test whether a function exists, it
is not as simple as
&gt;&gt;&gt;
&gt;&gt;&gt;   if io.popen then ..... end
&gt;&gt;&gt;
&gt;&gt;&gt; [...]
&gt;&gt;
&gt;&gt; On the other hand, I guess this message may be very useful for people
&gt;&gt; changing from 5.1 to 5.2. (Not people from the list, who has been
&gt;&gt; discussing the changes for a long time, but many (most?) programmers
&gt;&gt; not aware of all changes...)
&gt;&gt;
&gt;&gt; -- Roberto
&gt;&gt;
&gt;&gt;
&gt;
&gt; That functionality would better be implemented as a small library that
&gt; would be loaded only during the porting effort.
&gt;
&gt; -- Pierre-Yves
&gt;
&gt;

+1

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc5) now available

liam mail


On 5 July 2011 00:12, liam mail <[hidden email]> wrote:
&gt;
previous_email_sent_via_iphone:gsub('&gt;','>')


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc5) now available

Rena
In reply to this post by Alexander Gladysh
On Mon, Jul 4, 2011 at 15:58, Alexander Gladysh <[hidden email]> wrote:

> On Tue, Jul 5, 2011 at 00:19, David Manura <[hidden email]> wrote:
>> On Mon, Jul 4, 2011 at 3:40 PM, Luiz Henrique de Figueiredo
>> <[hidden email]> wrote:
>>> Lua 5.2.0 (beta-rc5) is now available [...]
>>>        - clarifications between 'deprecated' and 'removed'
>
>> This way of removing functions might not be ideal:
>
> I second this.
>
>>  stdin:1: 'popen' not supported
>>  stack traceback:
>>        [C]: in function 'popen'
>>        stdin:1: in main chunk
>>        [C]: in ?
>
> While this one *may* be justified...
>
>>  > setfenv(function()end, {})
>>  stdin:1: deprecated function
>>  stack traceback:
>>        [C]: in function 'setfenv'
>>        stdin:1: in main chunk
>>        [C]: in ?
>
> ...This one, IMO, makes no sense. If it is deprecated, it must work.
> Otherwise it is removed (and replaced with nonsense stub).
>
> My opinion is that there must be a clear way to programmatically
> determine a capability list of the given Lua interpreter. The best way
> to do this — is to actually *remove* removed functions.
>
> Uninitiated Lua 5.2 users would google up the "setfenv, attempted to
> call a nil value" (or whatever) error message, and would get the
> reason why this happens and what to do on the first hit. (One way to
> guarantee this — is to create a quality set question+answer pairs on
> the subject on StackOverflow.)
>
> My 2c,
> Alexander.
>
>

Hm, I was thinking of something like this:
local deleted = setmetatable({}, {
__call = function() error("This function no longer exists") end,
__eq = function(self, other) return not other end,
})

That would allow you to test if the function exists, and still get a
"removed" error if you call it. However it seems __eq doesn't trigger
when comparing to nil...
Of course, you can do "if somefunc == deleted" instead...

--
Sent from my toaster.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc5) now available

Josh Simmons
On Tue, Jul 5, 2011 at 12:00 PM, HyperHacker <[hidden email]> wrote:

> On Mon, Jul 4, 2011 at 15:58, Alexander Gladysh <[hidden email]> wrote:
>> On Tue, Jul 5, 2011 at 00:19, David Manura <[hidden email]> wrote:
>>> On Mon, Jul 4, 2011 at 3:40 PM, Luiz Henrique de Figueiredo
>>> <[hidden email]> wrote:
>>>> Lua 5.2.0 (beta-rc5) is now available [...]
>>>>        - clarifications between 'deprecated' and 'removed'
>>
>>> This way of removing functions might not be ideal:
>>
>> I second this.
>>
>>>  stdin:1: 'popen' not supported
>>>  stack traceback:
>>>        [C]: in function 'popen'
>>>        stdin:1: in main chunk
>>>        [C]: in ?
>>
>> While this one *may* be justified...
>>
>>>  > setfenv(function()end, {})
>>>  stdin:1: deprecated function
>>>  stack traceback:
>>>        [C]: in function 'setfenv'
>>>        stdin:1: in main chunk
>>>        [C]: in ?
>>
>> ...This one, IMO, makes no sense. If it is deprecated, it must work.
>> Otherwise it is removed (and replaced with nonsense stub).
>>
>> My opinion is that there must be a clear way to programmatically
>> determine a capability list of the given Lua interpreter. The best way
>> to do this — is to actually *remove* removed functions.
>>
>> Uninitiated Lua 5.2 users would google up the "setfenv, attempted to
>> call a nil value" (or whatever) error message, and would get the
>> reason why this happens and what to do on the first hit. (One way to
>> guarantee this — is to create a quality set question+answer pairs on
>> the subject on StackOverflow.)
>>
>> My 2c,
>> Alexander.
>>
>>
>
> Hm, I was thinking of something like this:
> local deleted = setmetatable({}, {
> __call = function() error("This function no longer exists") end,
> __eq = function(self, other) return not other end,
> })
>
> That would allow you to test if the function exists, and still get a
> "removed" error if you call it. However it seems __eq doesn't trigger
> when comparing to nil...
> Of course, you can do "if somefunc == deleted" instead...
>
> --
> Sent from my toaster.
>
>

That seems like over-designing a simple problem.

Removing the functions properly, and providing a compat / warning
library that re-defines the missing pieces seems much cleaner and more
useful to me.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc5) now available

Lorenzo Donati-2
On 05/07/2011 6.46, Josh Simmons wrote:

[...]

>
> That seems like over-designing a simple problem.
>
> Removing the functions properly, and providing a compat / warning
> library that re-defines the missing pieces seems much cleaner and more
> useful to me.
>
>
>

Yes.

Moreover throwing an error this way doesn't really help in error
management during the porting phase. In fact if the programmer is aware
of the changes, he will probably search for any occurrence of a missing
function and fix the call site anyway. If the application is large, he
may also devise some sort of automatic checking (like defining a global
setfenv which throws an error).

If he is not aware, then the program is broken and will eventually fail.
The check only allows the programmer to diagnose the cause of the
failure in a quicker way when the broken code is executed, but doesn't
help in discovering the error earlier. But any programmer upgrading from
5.1 to 5.2 *should* know what he is doing (asking him to read and
understand an annotated changelog shouldn't be too much).

The only "innocent victims" of the porting could be non-programmers
scripters who may be unaware of the change because it is made behind
their back (for example, WoW, I guess). But in this case it should be
the people forcing the porting that should create the necessary
infrastructure to catch the errors and warn the downstream scripters.

To summarize, IMHO these check unnecessarily litter the core, and still
aren't useful for every use case.

Maybe a better solution could be to ship a "checking module" (i.e.
"compat52-check.lua") with Lua and tell the programmer to "require" it
to enable some compatibility checks.

For functions that were removed without being deprecated in 5.1 (like
setfenv), it may be worth to add pointers to alternative solutions (Even
if partial). That will help the transition much more. For example, if
I'm unaware of missing setfenv and discover then my code is broken, it
doesn't help too much to have an error saying setfenv was removed. It
would help much more to know that for most use cases there is an
alternative (by Sergei Rhozenko:
http://lua-users.org/lists/lua-l/2010-06/msg00313.html).

-- Lorenzo


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc5) now available

Enrico Colombini
In reply to this post by Josh Simmons
On 05/07/2011 6.46, Josh Simmons wrote:
> Removing the functions properly, and providing a compat / warning
> library that re-defines the missing pieces seems much cleaner and more
> useful to me.

Yes. Being able to check with "if setfenv then..." is more robust than
having to branch on the version number (think n versions down the road).

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc5) now available

steve donovan
In reply to this post by Luiz Henrique de Figueiredo
On Mon, Jul 4, 2011 at 9:40 PM, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
> This release candidate will be the beta version if no glitches are found
> in the next 10 days or so. We thank everyone for their feedback till now.

A precompiled binary for Windows, mingw 32 bits, is available here,
together with a rebuilt lfs.dll:

http://stevedonovan.github.com/files/lua5.2beta5-mingw.zip

(lfs.c required one change luaL_reg --> luaL_Reg)

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc5) now available

Roberto Ierusalimschy
In reply to this post by Enrico Colombini
> Yes. Being able to check with "if setfenv then..." is more robust
> than having to branch on the version number (think n versions down
> the road).

It may be more robust, but it is a trick anyway. Several features
cannot be cheked that way, for instance whether string.format supports
'%a' or 'load' supports a mode or 'os.execute' returns new-style
results. Version numbers not always help, as some of these features
depend on the platform or compilation options.

-- Roberto

12