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

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

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

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

MD5 bb8ab764a0b4918a9df088159bbff430  -
SHA1 419da611f01940fc52ef896440da4aa1842ae2b8  -

This is an alpha version. Some details may change in the final version.

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

The complete diffs from the previous rc are available at
        http://www.lua.org/work/diffs-lua-5.2.0-alpha-rc1-alpha-rc2.txt

This release candidate will be the alpha version if no glitches are found
in the next 10 days or so.

All feedback welcome. Thanks.
--lhf


Reply | Threaded
Open this post in threaded view
|

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

Nick Gammon

On 18/11/2010, at 4:02 AM, Luiz Henrique de Figueiredo wrote:

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


The documentation for Lua 5.2

at this page: http://www.lua.org/work/doc/manual.html

says:

> _VERSION
>
> A global variable (not a function) that holds a string containing the current interpreter version. The current contents of this variable is "Lua 5.1".
>

Shouldn't that be Lua 5.2?
Reply | Threaded
Open this post in threaded view
|

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

David Manura
In reply to this post by Luiz Henrique de Figueiredo
On Wed, Nov 17, 2010 at 12:02 PM, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
> Lua 5.2.0 (alpha-rc2) is now available at... All feedback welcome.

When reading

  "bit32.TEST (···) -- Returns a boolean signaling whether the bitwise
and of its operands is different from zero."

I first parsed that as <<"the bitwise" and "of its operands">> before
finally realizing it meant "bitwise and".

The function does seem fairly trivial to include since bit32.TEST(...)
== (bit32.AND(...) ~= 0).

Reply | Threaded
Open this post in threaded view
|

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

dcharno
In reply to this post by Luiz Henrique de Figueiredo
On 11/17/2010 12:02 PM, Luiz Henrique de Figueiredo wrote:
> Lua 5.2.0 (alpha-rc2) is now available at
> http://www.lua.org/work/lua-5.2.0-alpha-rc2.tar.gz
>
> All feedback welcome. Thanks.

What is the motivation for the ALL CAPS function names in the bit library?

Reply | Threaded
Open this post in threaded view
|

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

Nick Gammon
In reply to this post by David Manura

On 19/11/2010, at 2:00 PM, David Manura wrote:

> The function does seem fairly trivial to include since bit32.TEST(...)
> == (bit32.AND(...) ~= 0).
>

Trivial perhaps, but quite a few times I have fallen for this:

if bit.band (x, 0x10) then
  -- blah
end -- if

This 'if' always evaluates to true, which can catch people who are used to C.

For me, the "test" function is a welcome way of avoiding this (of course, you need to remember to use it).
Reply | Threaded
Open this post in threaded view
|

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

Nick Gammon
In reply to this post by dcharno

On 19/11/2010, at 2:14 PM, dcharno wrote:

> What is the motivation for the ALL CAPS function names in the bit library?


My guess it is to avoid the use of the reserved words "and" and "or".

However it does look UGLY.

Reply | Threaded
Open this post in threaded view
|

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

Miles Bader-2
Nick Gammon <[hidden email]> writes:
>> What is the motivation for the ALL CAPS function names in the bit library?
>
> My guess it is to avoid the use of the reserved words "and" and "or".
>
> However it does look UGLY.

Yeah; "band", "bor" etc are hardly _pretty_, but they're at least
somewhat familiar and normal-looking.  AND, OR, etc, just stand out
absurdly in code, and scream for attention.

When something is written in uppercase, one's instincts say "something
must be weird/special about this" -- but in the case of the bit
library, that's just not true, they're perfectly normal functions.  So
there ends up being this funny mismatch between instinct and reality,
and that's disconcerting.  It's like a car that happens to have a
rotating "cop-light" operating on top, but is in fact, simply a normal
and random car...

[It's kind of a shame too -- I thought with the renaming of "bit" =>
"bit32", the whole bit-library controversy would be solved in a way
that pleased everybody .... oh well I guess a happy ending would be
too boring ... :( ]

-Miles

--
"Don't just question authority,
Don't forget to question me."
-- Jello Biafra

Reply | Threaded
Open this post in threaded view
|

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

David Manura
On Thu, Nov 18, 2010 at 11:23 PM, Miles Bader <[hidden email]> wrote:

> Nick Gammon <[hidden email]> writes:
>>> What is the motivation for the ALL CAPS function names in the bit library?
>>
>> My guess it is to avoid the use of the reserved words "and" and "or".
>>
>> However it does look UGLY.
>
> Yeah; "band", "bor" etc are hardly _pretty_, but they're at least
> somewhat familiar and normal-looking.  AND, OR, etc, just stand out
> absurdly in code, and scream for attention.

With code having lots of bitops, I'd probably do things like

  local OR = bit.bor or bit32.OR  -- prefer JIT-optimized ops
  local AND = bit.band or bit32.AND
  local NOT = bit.bnot or bit32.NOT
  ...
  if not t or NOT(OR(x,y)) == 1 and AND(z,w) == 0 then ... end

Reply | Threaded
Open this post in threaded view
|

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

Miles Bader-2
David Manura <[hidden email]> writes:

>> Yeah; "band", "bor" etc are hardly _pretty_, but they're at least
>> somewhat familiar and normal-looking.  AND, OR, etc, just stand out
>> absurdly in code, and scream for attention.
>
> With code having lots of bitops, I'd probably do things like
>
>   local OR = bit.bor or bit32.OR  -- prefer JIT-optimized ops
>   local AND = bit.band or bit32.AND
>   local NOT = bit.bnot or bit32.NOT
>   ...
>   if not t or NOT(OR(x,y)) == 1 and AND(z,w) == 0 then ... end

Hmmmm, the uppercase names seem not only equally ugly when used
without a package-prefix, but actually kind of confusing -- in such a
case, the only difference between "and" and "AND" is case and
position, and it's generally a poor idea to use names differentiated
only by case.  Just imagine a newbie reading this code....

Compare that to:

    local bor = bit.bor or bit32.bor  -- prefer JIT-optimized ops
    local band = bit.band or bit32.band
    local bnot = bit.bnot or bit32.bnot
    ...
    if not t or bnot(bor(x,y)) == 1 and band(z,w) == 0 then ... end
 
I think that's not only prettier, but much more clear as well:  the
"b" prefix makes the "bittiness" of the operations more obvious at a
glance.

[Of course one is free to rename things when assigning to local
variables, and I suspect many people will do that ... but it's a shame
the "official" names are so ugly.]

-Miles

--
Twice, adv. Once too often.

Reply | Threaded
Open this post in threaded view
|

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

Lorenzo Donati-2
In reply to this post by David Manura
David Manura wrote:

> On Thu, Nov 18, 2010 at 11:23 PM, Miles Bader <[hidden email]> wrote:
>> Nick Gammon <[hidden email]> writes:
>>>> What is the motivation for the ALL CAPS function names in the bit library?
>>> My guess it is to avoid the use of the reserved words "and" and "or".
>>>
>>> However it does look UGLY.
>> Yeah; "band", "bor" etc are hardly _pretty_, but they're at least
>> somewhat familiar and normal-looking.  AND, OR, etc, just stand out
>> absurdly in code, and scream for attention.
>
> With code having lots of bitops, I'd probably do things like
>
>   local OR = bit.bor or bit32.OR  -- prefer JIT-optimized ops
>   local AND = bit.band or bit32.AND
>   local NOT = bit.bnot or bit32.NOT
>   ...
>   if not t or NOT(OR(x,y)) == 1 and AND(z,w) == 0 then ... end
>
>
>
I wonder why no one has suggested bit32.And, bit32.Or ... etc.
Does that look less ugly? At least it doesn't call to mind constants (to
me at least).
But I must admit that, after all, you could always do that as
local And = bit32.AND

-- Lorenzo

Reply | Threaded
Open this post in threaded view
|

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

Lorenzo Donati-2
Sorry for answering my own post - did press the send key too early! :-)
Lorenzo Donati wrote:

> I wonder why no one has suggested bit32.And, bit32.Or ... etc.
> Does that look less ugly? At least it doesn't call to mind constants (to
> me at least).
> But I must admit that, after all, you could always do that as
> local And = bit32.AND
>
> -- Lorenzo
>
>
>

or maybe bit32.b_and ?
Not pretty, but far prettier than bit32.AND and clearer (browsing code)
than bit32.and.

-- Lorenzo

Reply | Threaded
Open this post in threaded view
|

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

Lorenzo Donati-2
Lorenzo Donati wrote:
> Not pretty, but far prettier than bit32.AND and clearer (browsing code)
> than bit32.and.
>
> -- Lorenzo
>
>
>

Ahem.. that was meant : "clearer than bit32.band"

Too early in the morning ... :-)

-- Lorenzo

Reply | Threaded
Open this post in threaded view
|

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

Enrico Colombini
In reply to this post by Miles Bader-2
On 19/11/2010 5.49, Miles Bader wrote:

> Compare that to:
>
>      local bor = bit.bor or bit32.bor  -- prefer JIT-optimized ops
>      local band = bit.band or bit32.band
>      local bnot = bit.bnot or bit32.bnot
>      ...
>      if not t or bnot(bor(x,y)) == 1 and band(z,w) == 0 then ... end
>
> I think that's not only prettier, but much more clear as well:  the
> "b" prefix makes the "bittiness" of the operations more obvious at a
> glance.

I heartily agree. Uppercase operands in Lua look weird (and confusing
too because "or" and "OR" are quite different beasts).

If "band" etc. do not sound well (not a problem for me), there are
always "bit.bitand" etc.

Finding good names is the hardest part of programming :-) Ah, the good
old days when we had sex (meaning "sign extend" in the 68000)...

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

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

Luiz Henrique de Figueiredo
In reply to this post by David Manura
> With code having lots of bitops, I'd probably do things like
>
>   local OR = bit.bor or bit32.OR  -- prefer JIT-optimized ops
>   local AND = bit.band or bit32.AND
>   local NOT = bit.bnot or bit32.NOT
>   ...
>   if not t or NOT(OR(x,y)) == 1 and AND(z,w) == 0 then ... end

For real code by Roberto, see http://lua-users.org/wiki/SecureHashAlgorithm

Reply | Threaded
Open this post in threaded view
|

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

dcharno
In reply to this post by Nick Gammon
On 11/18/2010 10:43 PM, Nick Gammon wrote:
>
> On 19/11/2010, at 2:14 PM, dcharno wrote:
>
>> What is the motivation for the ALL CAPS function names in the bit library?
>
>
> My guess it is to avoid the use of the reserved words "and" and "or".
>
> However it does look UGLY.

That was my guess too, but it would seem that band, bor, bxor are decent
alternatives.  It is UGLY.  If you look at the 5.2 reference index, the
first things you notice are _VERSION and bit32.XXXX.  Here's hoping this
will change before 5.2 is officially released.


Reply | Threaded
Open this post in threaded view
|

RE: [ANN] Lua 5.2.0 (alpha-rc2) now available

Cuero Bugot-2
>That was my guess too, but it would seem that band, bor, bxor are decent
>alternatives.  It is UGLY.  If you look at the 5.2 reference index, the
>first things you notice are _VERSION and bit32.XXXX.  Here's hoping this
>will change before 5.2 is officially released.

In the same topic, is the '32' (in bit32 library) really relevant ? What happens when somebody hacks/improves bit32 library to deals with 64 bits integers (something that has been done in this very list ;-) )





Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
> >That was my guess too, but it would seem that band, bor, bxor are decent
> >alternatives.  It is UGLY.  If you look at the 5.2 reference index, the
> >first things you notice are _VERSION and bit32.XXXX.  Here's hoping this
> >will change before 5.2 is officially released.
>
> In the same topic, is the '32' (in bit32 library) really relevant ? What happens when somebody hacks/improves bit32 library to deals with 64 bits integers (something that has been done in this very list ;-) )

Being "32 bit" is not a limitation, but a "feature". A library dealing
with 64-bit integers should be called "bit64", and probably be offered
together with bit32, not as a replacement.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Ralph Hempel-2
In reply to this post by Nick Gammon
Nick Gammon wrote:
> On 19/11/2010, at 2:14 PM, dcharno wrote:
>
>> What is the motivation for the ALL CAPS function names in the bit library?
>
>
> My guess it is to avoid the use of the reserved words "and" and "or".
>
> However it does look UGLY.

Mark me down as a "me too" as well. My implementation of Lua for
LEGO MINDSTORMS used to have a separate set of bit operations in
a table, with names like "band" "bor" "bxor" etc.

I was glad to see these names in the early 5.2-workX releases, and
was also glad that it worked just fine with my modified luaconf.h
that uses unsigned long as the Lua numeric type on ARM7

If you are at all flexible on the names, then I prefer bit.band over
bit.AND

Ralph

Reply | Threaded
Open this post in threaded view
|

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

Alexander Gladysh
On Fri, Nov 19, 2010 at 20:59, Ralph Hempel <[hidden email]> wrote:
> Nick Gammon wrote:
> If you are at all flexible on the names, then I prefer bit.band over
> bit.AND

If I remember correctly (perhaps I'm wrong), 5.2 bitlib semantics is
significantly different from established one.

This is the good reason to keep function names different.

Alexander.

Reply | Threaded
Open this post in threaded view
|

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

Patrick Rapin
In reply to this post by Lorenzo Donati-2
Yet one more variation to look for:

Maybe bit32._and, bit32._or would be better looking ?

1234 ... 7