[ANN] Lua 5.2.0 (work3) now available

classic Classic list List threaded Threaded
72 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

[ANN] Lua 5.2.0 (work3) now available

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

MD5 fa529ad323d261f27c12b04e3fef96a7  -
SHA1 5065a02a373500f62c7b87a89e5574d63dfa53e9  -

This is a work version. All details may change in the final version.

Here are the main changes since the previous work version:
- new _ENV proposal
- generational collector (very experimental)
- light C functions
- order tag methods follow the same rules of other binary operators
- lua_absindex
- \0 in patterns
- empty statement
- options in io.lines

The manual has been updated and most glitches reported in work2 have been fixed.
The complete diffs are available at
        http://www.lua.org/work/diffs-lua-5.2.0-work2-work3.txt

(This is a very large diff because the manual has been rearranged.)

All work versions are available at
        http://www.lua.org/work/

All feedback welcome. Thanks.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (work3) now available

Petite Abeille

On May 18, 2010, at 8:51 PM, Luiz Henrique de Figueiredo wrote:

> This is a work version. All details may change in the final version.

Nice :)

>
> Here are the main changes since the previous work version:

Hmmm... ipairs? deprecated? ouch.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (work3) now available

Enrico Colombini
In reply to this post by Luiz Henrique de Figueiredo
Luiz Henrique de Figueiredo wrote:
> - light C functions

Are these just optimized C functions with no stack frame (and no C
closure) as I infer from the (work) 5.2 manual, or is there any other
difference?

I'm asking because I found Mike Pall's old suggestion
(http://lua-users.org/lists/lua-l/2006-09/msg01011.html):
"Add a kind of "light" C functions. This avoids building up a call frame
for every function call. These functions are a bit more restricted (like
no callbacks into Lua)"

But I see that lua_pushcfunction is just a macro for lua_pushcclosure:
   #define lua_pushcfunction(L,f)  lua_pushcclosure(L,f,0)

and lua_pushcclosure(L,f,0) creates a light C function, so I guess Lua
callbacks from light C functions are allowed. Is this so?

   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (work3) now available

Enrico Colombini
In reply to this post by Petite Abeille
Petite Abeille wrote:
> Hmmm... ipairs? deprecated? ouch.

Uh, I missed this. I suppose it's to avoid the usual beginner's
confusion between pairs and ipairs?

   Enrico
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (work3) now available

Peter Cawley
In reply to this post by Luiz Henrique de Figueiredo
In section 8.3 of the manual, the following two (adjacent) lines seem
rather contradictory:
# Pseudoindex LUA_ENVIRONINDEX was removed. C functions do not have
environments any more. Use an upvalue with a shared table if you need
to keep shared state among several C functions. (You may use
luaL_openlib  to open a C library with all functions sharing a common
upvalue.)
# Macros lua_getglobal, lua_setglobal, and lua_register now operate
over the function environment instead of the global environment. (This
is more consistent with how Lua manipulates global variables.)

As far as I can tell, the second of these lines is incorrect - those
three functions all use LUA_RIDX_GLOBALS, which is the global
environment.

On Tue, May 18, 2010 at 7:51 PM, Luiz Henrique de Figueiredo
<[hidden email]> wrote:

> Lua 5.2.0 (work3) is now available at
>        http://www.lua.org/work/lua-5.2.0-work3.tar.gz
>
> MD5     fa529ad323d261f27c12b04e3fef96a7  -
> SHA1    5065a02a373500f62c7b87a89e5574d63dfa53e9  -
>
> This is a work version. All details may change in the final version.
>
> Here are the main changes since the previous work version:
> - new _ENV proposal
> - generational collector (very experimental)
> - light C functions
> - order tag methods follow the same rules of other binary operators
> - lua_absindex
> - \0 in patterns
> - empty statement
> - options in io.lines
>
> The manual has been updated and most glitches reported in work2 have been fixed.
> The complete diffs are available at
>        http://www.lua.org/work/diffs-lua-5.2.0-work2-work3.txt
>
> (This is a very large diff because the manual has been rearranged.)
>
> All work versions are available at
>        http://www.lua.org/work/
>
> All feedback welcome. Thanks.
> --lhf
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (work3) now available

Duncan Cross
In reply to this post by Petite Abeille
On Tue, May 18, 2010 at 8:12 PM, Petite Abeille
<[hidden email]> wrote:
> Hmmm... ipairs? deprecated? ouch.

Wow, yeah. Pretty bold. I notice that the readme still refers to it:
"ipairs now goes until #t" (i.e. respecting __len metamethods) - and
that change (as far as I understand it) must have meant either
changing what ipairs returns into a closure, or else calculating #t
every iteration - both of which would have been a bit costlier than
what the old one did. So I can see why it would have been recommended
to move to using numeric loop instead.

-Duncan
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (work3) now available

Luiz Henrique de Figueiredo
In reply to this post by Enrico Colombini
> But I see that lua_pushcfunction is just a macro for lua_pushcclosure:
>    #define lua_pushcfunction(L,f)  lua_pushcclosure(L,f,0)
>
> and lua_pushcclosure(L,f,0) creates a light C function, so I guess Lua
> callbacks from light C functions are allowed. Is this so?

Yes. Light C functions are exactly like current C functions except that they
don't have upvalues. It's an implementation optimization and one that has
shown to save a good amount of memory. Moreover, light C functions can be
sent to Lua without fearing memory allocation errors.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (work3) now available

Duncan Cross
On Tue, May 18, 2010 at 9:12 PM, Luiz Henrique de Figueiredo
<[hidden email]> wrote:

>> But I see that lua_pushcfunction is just a macro for lua_pushcclosure:
>>    #define lua_pushcfunction(L,f)  lua_pushcclosure(L,f,0)
>>
>> and lua_pushcclosure(L,f,0) creates a light C function, so I guess Lua
>> callbacks from light C functions are allowed. Is this so?
>
> Yes. Light C functions are exactly like current C functions except that they
> don't have upvalues. It's an implementation optimization and one that has
> shown to save a good amount of memory. Moreover, light C functions can be
> sent to Lua without fearing memory allocation errors.
>


Excellent. So, presumably, that means...


Lua 5.2.0 (work2)  Copyright (C) 1994-2010 Lua.org, PUC-Rio
> =pairs({}) == next
false
>


Lua 5.2.0 (work3)  Copyright (C) 1994-2010 Lua.org, PUC-Rio
> =pairs({}) == next
true
>


...Cool. :)

 (Maybe only to me, though...)

-Duncan
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (work3) now available

Geoff Leyland
In reply to this post by Luiz Henrique de Figueiredo
On 19/05/2010, at 6:51 AM, Luiz Henrique de Figueiredo wrote:

> - order tag methods follow the same rules of other binary operators

Thank you.  I see that the results of the relational metamethods are still coerced to boolean, and that "==" hasn't had the same treatment.  Would it be possible for all three relational operators to work like the other binary operators? (comparing mixed types as lt and le now do, and not coercing return values to boolean)

I know Roberto had good reasons to not go further last time I asked, but I figure it can't hurt to keep trying!

Cheers,
Geoff
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (work3) now available

Vincent Torri-2
In reply to this post by Luiz Henrique de Figueiredo


On Tue, May 18, 2010 at 8:51 PM, Luiz Henrique de Figueiredo <[hidden email]> wrote:
Lua 5.2.0 (work3) is now available at
       http://www.lua.org/work/lua-5.2.0-work3.tar.gz

MD5     fa529ad323d261f27c12b04e3fef96a7  -
SHA1    5065a02a373500f62c7b87a89e5574d63dfa53e9  -

This is a work version. All details may change in the final version.

Here are the main changes since the previous work version:
- new _ENV proposal
- generational collector (very experimental)
- light C functions
- order tag methods follow the same rules of other binary operators
- lua_absindex
- \0 in patterns
- empty statement
- options in io.lines

The manual has been updated and most glitches reported in work2 have been fixed.
The complete diffs are available at
       http://www.lua.org/work/diffs-lua-5.2.0-work2-work3.txt

(This is a very large diff because the manual has been rearranged.)

All work versions are available at
       http://www.lua.org/work/

All feedback welcome. Thanks.


The .pc file is still missing. I know that lua developpers mentioned the uber-stupid argument "we remove all the files that we consider as not needed in the tarball". But more importantly, you are breaking the build of *all* the libraries / programs that use lua and the .pc file. Doing so means that you absolutely don't care about the lua *users*.

Also, in case you didn't remark, we are in 2010. Even the embedded devices can deal with a tarball of 223.1KB instead of 223KB.

So, please, add again that **small** .pc file.

Vincent Torri
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (work3) now available

Roberto Ierusalimschy
In reply to this post by Duncan Cross
> On Tue, May 18, 2010 at 8:12 PM, Petite Abeille
> <[hidden email]> wrote:
> > Hmmm... ipairs? deprecated? ouch.
>
> Wow, yeah. Pretty bold. I notice that the readme still refers to it:
> "ipairs now goes until #t" (i.e. respecting __len metamethods) - and
> that change (as far as I understand it) must have meant either
> changing what ipairs returns into a closure, or else calculating #t
> every iteration - both of which would have been a bit costlier than
> what the old one did.

Not really. It only needs to calculate #t when the value is nil.


> So I can see why it would have been recommended to move to using
> numeric loop instead.

The point is that it does exactly the same that a numeric loop, so
there was no point in keeping it.

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (work3) now available

Roberto Ierusalimschy
In reply to this post by Peter Cawley
> In section 8.3 of the manual, the following two (adjacent) lines seem
> rather contradictory:
> # Pseudoindex LUA_ENVIRONINDEX was removed. C functions do not have
> environments any more. Use an upvalue with a shared table if you need
> to keep shared state among several C functions. (You may use
> luaL_openlib  to open a C library with all functions sharing a common
> upvalue.)
> # Macros lua_getglobal, lua_setglobal, and lua_register now operate
> over the function environment instead of the global environment. (This
> is more consistent with how Lua manipulates global variables.)
>
> As far as I can tell, the second of these lines is incorrect - those
> three functions all use LUA_RIDX_GLOBALS, which is the global
> environment.

Right. Many thanks for the correction.

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (work3) now available

Geoff Leyland
In reply to this post by Luiz Henrique de Figueiredo
On 19/05/2010, at 6:51 AM, Luiz Henrique de Figueiredo wrote:

> Lua 5.2.0 (work3) is now available at
> http://www.lua.org/work/lua-5.2.0-work3.tar.gz

What's going on with luaL_register?  I thought that luaL_openlib was deprecated and that we should use luaL_register instead, but in work3's luaxlib.h there's:

#define luaL_register(L,n,l) (luaL_openlib(L,(n),(l),0))

This means that luaL_register isn't visible to the dynamic linker (and luaL_openlib is).  Which in turn causes:

$ ~/lua-5.2.0-work3/src/lua rima-test.lua
.../lua-5.2.0-work3/src/lua: error loading module 'lfs' from file '/opt/local/lib/lua/5.1/lfs.so':
        dlopen(/opt/local/lib/lua/5.1/lfs.so, 2): Symbol not found: _luaL_register
  Referenced from: /opt/local/lib/lua/5.1/lfs.so
  Expected in: flat namespace
 in /opt/local/lib/lua/5.1/lfs.so

I looked through the archives, and it seems like Steve Donovan had exactly the opposite problem with work1.  I'm confused.  Can anyone spot my obvious mistake?

Cheers,
Geoff
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (work3) now available

Mike Pall-15
In reply to this post by Roberto Ierusalimschy
Roberto Ierusalimschy wrote:
> [... ipairs() deprecated ...]
> The point is that it does exactly the same that a numeric loop, so
> there was no point in keeping it.

But then the compatibility-mode ipairs() should preserve the 5.1
semantics. It doesn't make sense to add new behavior and deprecate
it at the same time.

BTW: the lua_cpcall compatibility macro in luaconf.h is defunct.

--Mike
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (work3) now available

Duncan Cross
In reply to this post by Roberto Ierusalimschy
On Tue, May 18, 2010 at 10:35 PM, Roberto Ierusalimschy
<[hidden email]> wrote:

>> On Tue, May 18, 2010 at 8:12 PM, Petite Abeille
>> <[hidden email]> wrote:
>> > Hmmm... ipairs? deprecated? ouch.
>>
>> Wow, yeah. Pretty bold. I notice that the readme still refers to it:
>> "ipairs now goes until #t" (i.e. respecting __len metamethods) - and
>> that change (as far as I understand it) must have meant either
>> changing what ipairs returns into a closure, or else calculating #t
>> every iteration - both of which would have been a bit costlier than
>> what the old one did.
>
> Not really. It only needs to calculate #t when the value is nil.
>

Well, my thought was that it's possible you might have (something
like) a table used as a stack that just alters its "length" field
(that the __len metamethod refers to) when elements are popped,
leaving garbage values past the end. But it's probably not very likely
people would do that in practice.

-Duncan
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (work3) now available

Petite Abeille
In reply to this post by Geoff Leyland

On May 18, 2010, at 11:45 PM, Geoff Leyland wrote:

> I looked through the archives, and it seems like Steve Donovan had exactly the opposite problem with work1.  I'm confused.  Can anyone spot my obvious mistake?

Make sure to recompile.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (work3) now available

Geoff Leyland
On 19/05/2010, at 9:52 AM, Petite Abeille wrote:

> On May 18, 2010, at 11:45 PM, Geoff Leyland wrote:
>
>> I looked through the archives, and it seems like Steve Donovan had exactly the opposite problem with work1.  I'm confused.  Can anyone spot my obvious mistake?
>
> Make sure to recompile.

I understand that binary compatibility is not guaranteed, and that if I recompiled lfs it would work, and there's no problem with that.  I'm just surprised that
 - luaL_register is implemented in terms of luaL_openlib
 - luaL_openlib, which apparently disappeared in work1, seems to have returned in work3

Cheers,
Geoff

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (work3) now available

Luiz Henrique de Figueiredo
In reply to this post by Geoff Leyland
> This means that luaL_register isn't visible to the dynamic linker (and luaL_openlib is).  Which in turn causes:
>
> $ ~/lua-5.2.0-work3/src/lua rima-test.lua
> .../lua-5.2.0-work3/src/lua: error loading module 'lfs' from file '/opt/local/lib/lua/5.1/lfs.so':

There's no ABI compatibility between 5.1 and 5.2. So you need to recompile
your C modules.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (work3) now available

Luiz Henrique de Figueiredo
In reply to this post by Geoff Leyland
> I'm just surprised that
>  - luaL_register is implemented in terms of luaL_openlib
>  - luaL_openlib, which apparently disappeared in work1, seems to have returned in work3

Like we said, everything may change in the final version. :-)
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (work3) now available

Duncan Cross
In reply to this post by Luiz Henrique de Figueiredo
On Tue, May 18, 2010 at 7:51 PM, Luiz Henrique de Figueiredo
<[hidden email]> wrote:

> Lua 5.2.0 (work3) is now available at
>        http://www.lua.org/work/lua-5.2.0-work3.tar.gz
>
> MD5     fa529ad323d261f27c12b04e3fef96a7  -
> SHA1    5065a02a373500f62c7b87a89e5574d63dfa53e9  -
>
> This is a work version. All details may change in the final version.
>
> Here are the main changes since the previous work version:
> - new _ENV proposal
> - generational collector (very experimental)
> - light C functions
> - order tag methods follow the same rules of other binary operators
> - lua_absindex
> - \0 in patterns
> - empty statement
> - options in io.lines
>
> The manual has been updated and most glitches reported in work2 have been fixed.
> The complete diffs are available at
>        http://www.lua.org/work/diffs-lua-5.2.0-work2-work3.txt
>
> (This is a very large diff because the manual has been rearranged.)
>
> All work versions are available at
>        http://www.lua.org/work/
>
> All feedback welcome. Thanks.
> --lhf
>
>

Following on from what Roberto said a few weeks ago about a change in
attitude towards using the "debug" module in real code [1], I'd like
to request it be renamed to something like "internal" or "lowlevel" or
"luacore" to reflect that. require("debug") should probably still
work, but it would just be an alias kept around for back
compatibility. The idea is that when new code uses this name, that
would be a clear message that this is code intended for Lua 5.2 and
above, where the library-previously-known-as-"debug" is now considered
generally acceptable to use, not only in the context of debugging.

I know this might seem like a petty, bike-shed-colour kind of a thing
to try to get changed - but I do think that this is a significant
paradigm shift, one that is worth intentionally making clear and
obvious to people.

[1] http://lua-users.org/lists/lua-l/2010-05/msg00078.html

-Duncan
1234