[ANN] Lua 5.2.0 (work2) now available

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

[ANN] Lua 5.2.0 (work2) now available

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

MD5 b246c52fa669db8bb16d6b34c2b35e2d  -
SHA1 fcac8efce7b6cf1768ae7e01f9921b04086f159b  -

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

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

The work area now has an HTML interface:
        http://www.lua.org/work/

Thanks to everyone for the reports.

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

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

Duncan Cross
On Thu, Jan 14, 2010 at 1:52 AM, Luiz Henrique de Figueiredo
<[hidden email]> wrote:

> Lua 5.2.0 (work2) is now available at
>        http://www.lua.org/work/lua-5.2.0-work2.tar.gz
>
> MD5     b246c52fa669db8bb16d6b34c2b35e2d  -
> SHA1    fcac8efce7b6cf1768ae7e01f9921b04086f159b  -
>
> This is a work version. All details may change in the final version.
>
> The manual has been updated and most glitches reported in work1 have been
> fixed. The complete diffs are available at
>        http://www.lua.org/work/diffs-lua-5.2.0-work1-work2.txt
>
> The work area now has an HTML interface:
>        http://www.lua.org/work/
>
> Thanks to everyone for the reports.
>
> All feedback welcome. Thanks.
> --lhf
>

A snippet of code in the description for bit.brotate() refers to
"bit.rotate(...)" (i.e. missing the "b").

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

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

Sean Bolton
In reply to this post by Luiz Henrique de Figueiredo
On Jan 13, 2010, at 5:52 PM, Luiz Henrique de Figueiredo wrote:
> Lua 5.2.0 (work2) is now available at
> http://www.lua.org/work/lua-5.2.0-work2.tar.gz

Yeah! New toy!

I don't believe the macro definition in src/luaconf.h for
lua_number2uint() added for the Microsoft compiler case is
going to work correctly:

  /* On a Microsoft compiler, use assembler */
  #if defined(_MSC_VER)

  #define lua_number2int(i,d)   { __asm fld d   __asm fistp i }
  #define lua_number2integer(i,n)         lua_number2int(i, n)
+#define lua_number2uint(i,n)            lua_number2int(i, n)

The problem is FISTP stores a signed integer, and if the double
to be converted is out of range of what the signed int can hold,
it stores 0x80000000.

I don't have a Microsoft compiler, but if I change my luaconf.h
and Makefile to cause gcc to use the assembler version, I get:

Lua 5.2.0 (work2)  Copyright (C) 1994-2010 Lua.org, PUC-Rio
 > print(string.format("%08x", bit.bor(0x7fffffff, 0)))
7fffffff
 > print(string.format("%08x", bit.bor(0x80000000, 0)))
80000000
 > print(string.format("%08x", bit.bor(0x80000001, 0)))
80000000
 > print(string.format("%08x", bit.bor(0xffffffff, 0)))
80000000

The following gives the correct conversion under gcc:

#define lua_number2uint(i,d)  { long long q; { __asm fld d  __asm  
fistp q } i = (unsigned LUA_INT32)q; }

but I don't know what a Microsoft compiler will think of that....

BTW, I'd love to know which architectures this comment further
down in luaconf.h is referring to:

/* on several machines, coercion from unsigned to double is too slow,
    so avoid that if possible */

Anyone?

-Sean

Reply | Threaded
Open this post in threaded view
|

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

Enrico Colombini
In reply to this post by Luiz Henrique de Figueiredo
Luiz Henrique de Figueiredo wrote:
> Lua 5.2.0 (work2) is now available at
> http://www.lua.org/work/lua-5.2.0-work2.tar.gz

Compilation both in C and C++ mode now seems to be OK with no warnings
in Dev-C++ 4.9.9.2 (mingw32), Windows XP.

   Enrico
Reply | Threaded
Open this post in threaded view
|

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

Jerome Vuarand
In reply to this post by Luiz Henrique de Figueiredo
2010/1/14 Luiz Henrique de Figueiredo <[hidden email]>:

> Lua 5.2.0 (work2) is now available at
>        http://www.lua.org/work/lua-5.2.0-work2.tar.gz
>
> MD5     b246c52fa669db8bb16d6b34c2b35e2d  -
> SHA1    fcac8efce7b6cf1768ae7e01f9921b04086f159b  -
>
> This is a work version. All details may change in the final version.
>
> The manual has been updated and most glitches reported in work1 have been
> fixed. The complete diffs are available at
>        http://www.lua.org/work/diffs-lua-5.2.0-work1-work2.txt
>
> The work area now has an HTML interface:
>        http://www.lua.org/work/
>
> Thanks to everyone for the reports.
>
> All feedback welcome. Thanks.

It compiles out of the box with Visual C++ 2008 command line 32bits
compiler and a custom build tool (no warning with my current options,
which are not very strict though).
Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
In reply to this post by Sean Bolton
> BTW, I'd love to know which architectures this comment further
> down in luaconf.h is referring to:
>
> /* on several machines, coercion from unsigned to double is too slow,
>    so avoid that if possible */

As far as I know, Pentium does not have an istruction for such
conversion. So, it zero-extends the unsigned int to a 64-bit integer
and reads it with 'fildll'. (Maybe that is not "too slow", but some
tests suggested the conditional was faster.)

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

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

Ignacio Burgueño
In reply to this post by Enrico Colombini
On 14/01/2010 06:25, Enrico Colombini wrote:
> Luiz Henrique de Figueiredo wrote:
>> Lua 5.2.0 (work2) is now available at
>> http://www.lua.org/work/lua-5.2.0-work2.tar.gz
>
> Compilation both in C and C++ mode now seems to be OK with no warnings
> in Dev-C++ 4.9.9.2 (mingw32), Windows XP.
>

Also under VC6 compiled fine (just one warning, detailed below).
I've uploaded the resulting binaries (exe and dll) here:

http://www.mediafire.com/file/mz5jdmt0rtq/lua-5.2.0-work2.vc6.msvcrt.zip

The warning is this:
lua-5.2.0-work2\src\ldo.c(412) : warning C4244: '=' : conversion from
'long ' to 'unsigned char ', possible loss of data

Regards,
Ignacio


Reply | Threaded
Open this post in threaded view
|

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

liam mail


2010/1/14 Ignacio Burgueño <[hidden email]>
On 14/01/2010 06:25, Enrico Colombini wrote:
Luiz Henrique de Figueiredo wrote:
Lua 5.2.0 (work2) is now available at
http://www.lua.org/work/lua-5.2.0-work2.tar.gz

OK I compiled under mac osx 10.6 and there were no errors for a local install this time.

What does concern me is that I ran ALL.lua to find a couple of errors because at least some of the scripts have not been updated and used removed functions, another hits an assert, table.lua requires a user to look at the code to see how to exit the loop etc.
It would be nice if the tests told you if they passed or failed rather than a user having to look at them and figure out what would be considered a pass and what is a failure. Is not the point of them to see if Lua is built correctly?

Liam
Reply | Threaded
Open this post in threaded view
|

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

Ignacio Burgueño
In reply to this post by Luiz Henrique de Figueiredo
On 13/01/2010 23:52, Luiz Henrique de Figueiredo wrote:
> Lua 5.2.0 (work2) is now available at
> http://www.lua.org/work/lua-5.2.0-work2.tar.gz
>
> MD5 b246c52fa669db8bb16d6b34c2b35e2d  -
> SHA1 fcac8efce7b6cf1768ae7e01f9921b04086f159b  -
>
> This is a work version. All details may change in the final version.
>

Thanks! package.searchpath now works fine. That would be really useful
for me.

__len is still able to return non number values. What is the position
about that? Is that the desired behaviour?

Regards,
Ignacio Burgueño


Reply | Threaded
Open this post in threaded view
|

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

Mike Pall-11
Ignacio Burgueño wrote:
> __len is still able to return non number values. What is the position  
> about that? Is that the desired behaviour?

Even __add can return non number values, which is useful behavior.
Why should __len get special treatment?

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

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

Luiz Henrique de Figueiredo
In reply to this post by Ignacio Burgueño
> __len is still able to return non number values. What is the position
> about that? Is that the desired behaviour?

__len can return any Lua value:

for k,v in ipairs({true,print,"hello",{},io.stdin}) do
        a=setmetatable({},{__len=function() return v end})
        print(k,v,#a)
end

1 true true
2 function: 0x9bbdfd0 function: 0x9bbdfd0
3 hello hello
4 table: 0x9bc2240 table: 0x9bc2240
5 file (0x2e5420) file (0x2e5420)
Reply | Threaded
Open this post in threaded view
|

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

Luiz Henrique de Figueiredo
In reply to this post by liam mail
> What does concern me is that I ran ALL.lua to find a couple of errors
> because at least some of the scripts have not been updated and used removed
> functions, another hits an assert, table.lua requires a user to look at the
> code to see how to exit the loop etc.

Sorry about that. The next work version will fix this (probably by removing
all tests except hello.lua :-) Starting at alpha the tests will include correct
meaningful code.
Reply | Threaded
Open this post in threaded view
|

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

Ignacio Burgueño
In reply to this post by Luiz Henrique de Figueiredo
On 14/01/2010 19:14, Luiz Henrique de Figueiredo wrote:

>> __len is still able to return non number values. What is the position
>> about that? Is that the desired behaviour?
>
> __len can return any Lua value:
>
> for k,v in ipairs({true,print,"hello",{},io.stdin}) do
> a=setmetatable({},{__len=function() return v end})
> print(k,v,#a)
> end
>
> 1 true true
> 2 function: 0x9bbdfd0 function: 0x9bbdfd0
> 3 hello hello
> 4 table: 0x9bc2240 table: 0x9bc2240
> 5 file (0x2e5420) file (0x2e5420)
>


Well, as Mike pointed out, __add can return non number values and that
is reasonable. For instance, a vector library so that v3 = v1 + v2 will
benefit from __add being able to return anything.
But I can't think of a case where the length of something is not a
numeric value.

For me, __len has clear semantics. The length of something is measurable
in 'n' units, with 'n' being a number.

Using __len for other uses seems like a case of operator overloading
abuse (C++).

Even the common idiom of "t[#t + 1] = something" will have to take care
of checking the type of #t before doing arithmetic with it.

And in a related note, if now there is lua_rawlen, shouldn't it have a
non-raw version, like gettable / rawget, etc?

Regards,
Ignacio


Reply | Threaded
Open this post in threaded view
|

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

Duncan Cross
2010/1/14 Ignacio Burgueño <[hidden email]>:
> But I can't think of a case where the length of something is not a numeric
> value.
>
> For me, __len has clear semantics. The length of something is measurable in
> 'n' units, with 'n' being a number.
>
> Using __len for other uses seems like a case of operator overloading abuse
> (C++).

I can think of a pretty high-profile example of this - Roberto's LPEG
library overloads the # operator for LPEG pattern objects for
something entirely unrelated to length (it "returns" a new pattern).

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

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

Miles Bader-2
In reply to this post by Ignacio Burgueño
Ignacio Burgueño <[hidden email]> writes:
> Even the common idiom of "t[#t + 1] = something" will have to take care
> of checking the type of #t before doing arithmetic with it.

No it won't.  It's perfectly fine for code to assume the that a length
is a number, and people will continue to do so.

If somebody abuses __len for weird uses, it's their responsibility to
deal with the fallout, not the language's; they'll just have to make
sure their funny object doesn't get used in a context where it will be
assumed to be a table or whatever.

You're worrying too much.

-Miles

--
Youth, n. The Period of Possibility, when Archimedes finds a fulcrum,
Cassandra has a following and seven cities compete for the honor of endowing a
living Homer.

Reply | Threaded
Open this post in threaded view
|

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

Luiz Henrique de Figueiredo
In reply to this post by Ignacio Burgueño
> And in a related note, if now there is lua_rawlen, shouldn't it have a
> non-raw version, like gettable / rawget, etc?

You've missed lua_len. See the manual.
Reply | Threaded
Open this post in threaded view
|

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

Ignacio Burgueño
In reply to this post by Duncan Cross
On 14/01/2010 20:03, Duncan Cross wrote:
> 2010/1/14 Ignacio Burgueño<[hidden email]>:

> I can think of a pretty high-profile example of this - Roberto's LPEG
> library overloads the # operator for LPEG pattern objects for
> something entirely unrelated to length (it "returns" a new pattern).
>

Yes, you're right. I was halfway writing the continuation of this rant
until I also saw Miles message. He's right, I'm worrying too much :D

Sorry for the noise.




Reply | Threaded
Open this post in threaded view
|

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

Ignacio Burgueño
In reply to this post by Luiz Henrique de Figueiredo
On 14/01/2010 20:11, Luiz Henrique de Figueiredo wrote:
>> And in a related note, if now there is lua_rawlen, shouldn't it have a
>> non-raw version, like gettable / rawget, etc?
>
> You've missed lua_len. See the manual.
>

Indeed. I didn't see it, thanks.

This leads me to another (unrelated maybe) question. Since lua_len,
lua_concat and lua_arith honors the corresponding metafield (__len,
__concat, etc), is there a way to iterate a value from C that has
__pairs? Will lua_next deal with that?

Regards,
Ignacio

p.s. yeah, today I'm in inquisitive mood :D


Reply | Threaded
Open this post in threaded view
|

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

liam mail
In reply to this post by Luiz Henrique de Figueiredo


2010/1/14 Luiz Henrique de Figueiredo <[hidden email]>
> What does concern me is that I ran ALL.lua to find a couple of errors
> because at least some of the scripts have not been updated and used removed
> functions, another hits an assert, table.lua requires a user to look at the
> code to see how to exit the loop etc.

Sorry about that. The next work version will fix this (probably by removing
all tests except hello.lua :-) Starting at alpha the tests will include correct
meaningful code.
Really?
I see the smiley but am I unsure if that is some kind of joke?

Is not the point of releasing these working revisions to gain feed back and to find what is working and what has problems?

The problem is no one has reported this as no one runs the tests, I feel this is for a couple of reasons:
Firstly it is not made nice and simple to run them, the library provides make test yet all this does is run a hello world example.
The test requires user input instead of testing against known inputs and therefore expected outputs.
The results give no feed back if the they pass or fail, just print pretty numbers and ascii art. I still do not know which tests passed.

From what I have seen people on the list devise there own tests to see if the library has compiled correct and doing what it should. Do you not think it is better to correct the tests now? People will then start to run them, giving feed back upon the results. When people come with a library related problem you could always ask, what is the result of the tests.

Personally I would write it so that make tests actually ran all the tests without any user input and with feedback on the result status of the tests.

Liam
Reply | Threaded
Open this post in threaded view
|

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

David Burgess-3
In reply to this post by Ignacio Burgueño
I think we should have lua_pairs() to match lua_next()

DB

On 15/1/2010 9:42 AM, Ignacio Burgueño wrote:

> On 14/01/2010 20:11, Luiz Henrique de Figueiredo wrote:
>>> And in a related note, if now there is lua_rawlen, shouldn't it have a
>>> non-raw version, like gettable / rawget, etc?
>>
>> You've missed lua_len. See the manual.
>>
>
> Indeed. I didn't see it, thanks.
>
> This leads me to another (unrelated maybe) question. Since lua_len,
> lua_concat and lua_arith honors the corresponding metafield (__len,
> __concat, etc), is there a way to iterate a value from C that has
> __pairs? Will lua_next deal with that?
>
> Regards,
> Ignacio
>
> p.s. yeah, today I'm in inquisitive mood :D
>
>

123