[ANN] Lua 5.3.0 (work2) now available

classic Classic list List threaded Threaded
261 messages Options
1234567 ... 14
Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
> 5.2.2 does not say "they are not primitively equal", but the code
> shows it. 5.3.work2 does not say "have the same type", but
> implies it by the word "both" and saying "tables" rather than
> "a table". The point could be made more strongly by a small
> change in the wording:
>
> Lua will try a metamethod only when the values being compared are
> either both tables or both full userdata, both have the same
> metamethod, and they are not primitively equal.

Many thanks for the suggestion.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
In reply to this post by Coroutines
> This is sort of the reason why I wish Lua's core had a library
> specifically for buffers, something where you can create userdata
> buffers and fill it with lua values rawly, and then convert it into a
> immutable, pooled Lua string if you wish.

The traditional method is this:

  local buffer = {}  -- create a buffer
 
  buffer[#buffer + 1] = x    -- add values
 
  s = table.concat(buffer)    -- convert it into a immutable Lua string

Yes, I know, it would be faster with specific support. Mostly everything
in Lua (or any other interpreter) would be faster with specific support.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Enrico Colombini
In reply to this post by Roberto Ierusalimschy
On 23/03/2014 14.27, Roberto Ierusalimschy wrote:
> It is not difficult to implement bit32 in pure Lua 5.3. (The test file
> 'bitwise.lua' has such an implementation.) It is easy to provide that
> (or a C equivalent) as an external library.

Yes, of course. It is more of an easthetical doubt: I would have liked
to publish it in pure Lua 5.3, but praticality dictates otherwise :-)

>> By the way, Roberto said something about the (hypotetical,
>> approximate) release time for 5.3, but I didn't take notes and I
>> have not been able to find it in the archives...
>
> I do not remember saying anything about that (and I did not take notes,
> either :).

I take note ;-)

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

RE: [ANN] Lua 5.3.0 (work2) now available

Thijs Schreijer
In reply to this post by Luiz Henrique de Figueiredo
> Lua 5.3.0 (work2) is now available for testing at
> http://www.lua.org/work/lua-5.3.0-work2.tar.gz
>


C:\Temp\lua-5.3.0-work2\src>lua
Lua 5.3.0 (work2)  Copyright (C) 1994-2014 Lua.org, PUC-Rio
> 0x10 ~ 0x01    -- xor
17
> ~0x01          -- not
-2
> ~0x0e          -- not
-15
>

I find it confusing that the operator '~' is used for both 'xor' and 'unary not'. I would rather see '!' as the 'unary not'.

I don't use them a lot, but are the last two results to be expected? (negative results?)

Thijs

Reply | Threaded
Open this post in threaded view
|

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

Luiz Henrique de Figueiredo
In reply to this post by Philipp Janda
> The index in the manual still contains an entry for `math.isfloat`
> (leading nowhere).

Thanks for the report.

Reply | Threaded
Open this post in threaded view
|

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

Luiz Henrique de Figueiredo
In reply to this post by Thijs Schreijer
> are the last two results to be expected? (negative results?)

Lua 5.3 has integers but not unsigned integers. If you want to see unsigned
integers, try string.format("%x",~1).

Reply | Threaded
Open this post in threaded view
|

RE: [ANN] Lua 5.3.0 (work2) now available

Thijs Schreijer
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Luiz Henrique de Figueiredo
> Sent: zondag 23 maart 2014 16:09
> To: Lua mailing list
> Subject: Re: [ANN] Lua 5.3.0 (work2) now available
>
> > are the last two results to be expected? (negative results?)
>
> Lua 5.3 has integers but not unsigned integers. If you want to see unsigned
> integers, try string.format("%x",~1).

Yes, figured that out by now. Just wondering what the consequences of this are for simple bitmask operations. I guess they require a final 'and' operation before emitting the results.

> ("%x"):format( ~0xf & 255)
f0
>

Thijs




Reply | Threaded
Open this post in threaded view
|

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

Sean Bolton-2
In reply to this post by Luiz Henrique de Figueiredo
This is shaping up to be a really exciting release! I've been playing
with the utf8 library:

$ lua-5.3.0-work2/src/lua
Lua 5.3.0 (work2)  Copyright (C) 1994-2014 Lua.org, PUC-Rio
> utf8.len('')
stdin:1: bad argument #1 to 'len' (initial position out of string)
stack traceback:
        [C]: in function 'len'
        stdin:1: in main chunk
        [C]: in ?

That's certainly a surprise. Is it intentional that this raises an
error, instead of returning 0 for the empty string like string.len?

> utf8.offset('a', 0, 3)
stdin:1: bad argument #3 to 'offset' (position out of range)
stack traceback:
        [C]: in function 'offset'
        stdin:1: in main chunk
        [C]: in ?
> utf8.offset('a', 0, 2)
2

I expect start offsets of 2 and 3 would both raise errors.

There is a typo in the manual for utf8.len: 'sufix' should be 'suffix'.

As an exercise, I tried to write a function using the new utf8 library
that would scan a string and replace any invalid UTF-8 sequences with a
substitution character.  I failed to come up with any solution that did
not either create many small strings (one for each codepoint in the
target string) or involve scanning the string byte-by-byte (which could
as easily be done with Lua 5.2). How much easier it would be if
utf8.len, upon encountering invalid UTF-8, returned nil plus the
byte offset of the offending sequence!

-Sean

Reply | Threaded
Open this post in threaded view
|

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

Dirk Laurie-2
In reply to this post by Luiz Henrique de Figueiredo
In §3.1 of the manual, under
"The following strings denote other tokens:"
the new bit operators are not included.

2014-03-21 22:44 GMT+02:00 Luiz Henrique de Figueiredo <[hidden email]>:

> Lua 5.3.0 (work2) is now available for testing at
>         http://www.lua.org/work/lua-5.3.0-work2.tar.gz
>
> MD5     52bd13d0b40f637bc388a133b9bb8771  -
> SHA1    e52ea0acf4b2d7bf042f48bd01dddc149d517184  -
>
> This is a work version. An updated reference manual is included but
> all details may change in the final version. See
>         http://www.lua.org/work/doc/readme.html
>
> The main change in Lua 5.3.0 is the introduction of integers.
> For other changes, see
>         http://www.lua.org/work/doc/readme.html#changes
>
> The complete diffs from work1 are at
>         http://www.lua.org/work/diffs-lua-5.3.0-work1-work2.txt
>
> Enjoy. All feedback welcome. Thanks.
> --lhf
>
>

Reply | Threaded
Open this post in threaded view
|

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

Coroutines
In reply to this post by Roberto Ierusalimschy
On Sun, Mar 23, 2014 at 6:50 AM, Roberto Ierusalimschy
<[hidden email]> wrote:

>> This is sort of the reason why I wish Lua's core had a library
>> specifically for buffers, something where you can create userdata
>> buffers and fill it with lua values rawly, and then convert it into a
>> immutable, pooled Lua string if you wish.
>
> The traditional method is this:
>
>   local buffer = {}  -- create a buffer
>
>   buffer[#buffer + 1] = x    -- add values
>
>   s = table.concat(buffer)    -- convert it into a immutable Lua string
>
> Yes, I know, it would be faster with specific support. Mostly everything
> in Lua (or any other interpreter) would be faster with specific support.
>
> -- Roberto
>

I know what you're getting at, Mr. Roberto. :-)  It just seems like a
fair number of people do implement a buffer object type in third-party
projects.  What gets me is how many people forgo using the perfectly
adequate luaL_Buffer (maybe it gets overlooked?).  I thought luasocket
had a need to roll its own because it needed a persistent buffer
between recv()'s, but it looks a bit sketchy-large.  Furthermore
having a standard buffer library would remove the large possibility of
people creating incorrect/leaky buffer libraries.  Really you only
need a library that can create luaL_Buffer and has these functions
exposed (in a friendlier form): luaL_buffinit*(), luaL_add*(),
luaL_prep*(), luaL_push*().  To Lua it'd just be userdata (as always).
 It would also need support for iterating over buffers byte-by-byte
(pushing lua_Number's like string.byte()).  You could also iterate in
lua_Integer strides up to the remaining bytes (and then copy the
fragment into the final luaL_Number) for a faster form.  I really
don't think this would be asking for a lot the facility is there, but
i'm a loon so ~

(I'll give you a puppy?  His name is Benedict Cumberbatch and he likes
to lick faces.)

Reply | Threaded
Open this post in threaded view
|

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

Dirk Laurie-2
In reply to this post by Thijs Schreijer
2014-03-23 16:58 GMT+02:00 Thijs Schreijer <[hidden email]>:

> I find it confusing that the operator '~' is used for both 'xor' and 'unary not'.

Think of it this way. Prefix `-` is related to infix `-` by the identity

   -x == 0-x

Prefix `~`, as your examples so clearly demonstrate, is related to infix `~` by

   ~x == (-1)~x

since -1 == 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

Reply | Threaded
Open this post in threaded view
|

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

Are Leistad
In reply to this post by Roberto Ierusalimschy
Regarding the specifiaction of the base for numeric constants, some tools
I've used in the past had the following, quite clean and readable, notation:

<base>_<number>

e.g. 2_10101010 , 16_A9 etc.

Perhaps something worth considering for the 'number oriented' 5.3?

Are
--


---
Denne e-posten er fri for virus og uønsket programvare fordi avast! Antivirusbeskyttelse er aktiv.
http://www.avast.com


Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
In reply to this post by Dirk Laurie-2
> In §3.1 of the manual, under
> "The following strings denote other tokens:"
> the new bit operators are not included.

Many thanks. (They are missing in the complete grammar, too.)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
In reply to this post by Sean Bolton-2
> > utf8.len('')
> stdin:1: bad argument #1 to 'len' (initial position out of string)

This is a (surprising) bug. Thanks for the report. (How did we not have
a test for that case??)


> > utf8.offset('a', 0, 3)
> stdin:1: bad argument #3 to 'offset' (position out of range)
> [...]
> > utf8.offset('a', 0, 2)
> 2
>
> I expect start offsets of 2 and 3 would both raise errors.

Position 2 is exaclty *after* the 'a'; it seems useful to allow
that position as valid.


> There is a typo in the manual for utf8.len: 'sufix' should be 'suffix'.

Thanks.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

mniip
In reply to this post by Are Leistad
On 03/23/2014 10:53 PM, Are Leistad wrote:

> Regarding the specifiaction of the base for numeric constants, some
> tools I've used in the past had the following, quite clean and
> readable, notation:
>
> <base>_<number>
>
> e.g. 2_10101010 , 16_A9 etc.
>
> Perhaps something worth considering for the 'number oriented' 5.3?
>
> Are

That's not really readable. Also what happens if you specify a base
higher than 36?

IMO we are fine with just decimals and hexadecimals. I don't really
think binary literals are that much of a need, as it's trivial to
translate hexadecimal to binary and back. Even C with their binary flags
all over the place don't use any binary literals. Arbitrary base
literals would be an overkill of useless-ness.

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
In reply to this post by Andrew Starks
> I'd like to suggest that the timing for changes to coercion is in this
> release.
>
> You introduced int 64 and language support for bits, plus changes to number
> formatting. 5.3 looks to be shaping up to be a "number" release.
> Eliminating string->number fits this.

I am afraid elimination of this conversion is a much deeper disruption
than it seems; I would love to be proved wrong.

I think it is really easy to disable this coercion in Lua; all it takes
is a simple change in lvm.c (see below). It would be very helpful if
people try that in the wild and report their experiences here in the
list.


Lua 5.1 and Lua 5.2:
@@ -35,10 +35,6 @@
 const TValue *luaV_tonumber (const TValue *obj, TValue *n) {
   lua_Number num;
   if (ttisnumber(obj)) return obj;
-  if (ttisstring(obj) && luaO_str2d(svalue(obj), &num)) {
-    setnvalue(n, num);
-    return n;
-  }
   else
     return NULL;
 }

Lua 5.3:
@@ -44,7 +44,7 @@
     return 1;
   }
   else
-    return (ttisstring(obj) && luaO_str2d(svalue(obj), tsvalue(obj)->len, n));
+    return 0;
 }


-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Andrew Starks
I would be happy to try this. I'll upgrade to the latest and apply this change first thing tomorrow. 

On Sunday, March 23, 2014, Roberto Ierusalimschy <[hidden email]> wrote:
> I'd like to suggest that the timing for changes to coercion is in this
> release.
>
> You introduced int 64 and language support for bits, plus changes to number
> formatting. 5.3 looks to be shaping up to be a "number" release.
> Eliminating string->number fits this.

I am afraid elimination of this conversion is a much deeper disruption
than it seems; I would love to be proved wrong.

I think it is really easy to disable this coercion in Lua; all it takes
is a simple change in lvm.c (see below). It would be very helpful if
people try that in the wild and report their experiences here in the
list.


Lua 5.1 and Lua 5.2:
@@ -35,10 +35,6 @@
 const TValue *luaV_tonumber (const TValue *obj, TValue *n) {
   lua_Number num;
   if (ttisnumber(obj)) return obj;
-  if (ttisstring(obj) && luaO_str2d(svalue(obj), &num)) {
-    setnvalue(n, num);
-    return n;
-  }
   else
     return NULL;
 }

Lua 5.3:
@@ -44,7 +44,7 @@
     return 1;
   }
   else
-    return (ttisstring(obj) && luaO_str2d(svalue(obj), tsvalue(obj)->len, n));
+    return 0;
 }


-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Ico Doornekamp
In reply to this post by Roberto Ierusalimschy
* On 2014-03-23 20:40:24 +0100, Roberto Ierusalimschy wrote:
 

> I think it is really easy to disable this coercion in Lua; all it takes
> is a simple change in lvm.c (see below). It would be very helpful if
> people try that in the wild and report their experiences here in the
> list.
>
> Lua 5.1 and Lua 5.2:
> @@ -35,10 +35,6 @@
>  const TValue *luaV_tonumber (const TValue *obj, TValue *n) {
>    lua_Number num;
>    if (ttisnumber(obj)) return obj;
> -  if (ttisstring(obj) && luaO_str2d(svalue(obj), &num)) {
> -    setnvalue(n, num);
> -    return n;
> -  }
>    else
>      return NULL;
>  }

I guess an explicit conversion from string to number is still supposed
to work? With the above patch on 5.2:

=tonumber("3")
nil

--
:wq
^X^Cy^K^X^C^C^C^C

Reply | Threaded
Open this post in threaded view
|

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

Mike Nelson
In reply to this post by Roberto Ierusalimschy
On 3/23/2014 6:36 AM, Roberto Ierusalimschy wrote:
>> A feature I would love to see is a good FFI built in to Lua 5.3--a
>> real boon to us who use Lua mainly as an extendible language.
> Unfortunately, there is no way to implement that in ANSI C.
>
> -- Roberto
>
I should have thought of that. There are some useful libraries out
there, but I'm not having luck finding a currently maintained one. Any
library writers out there are welcome to prove me wrong (and showcase
their libs!)


-- Mike

Reply | Threaded
Open this post in threaded view
|

RE: [ANN] Lua 5.3.0 (work2) now available

Thijs Schreijer
In reply to this post by Dirk Laurie-2
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Dirk Laurie
> Sent: zondag 23 maart 2014 18:46
> To: Lua mailing list
> Subject: Re: [ANN] Lua 5.3.0 (work2) now available
>
> 2014-03-23 16:58 GMT+02:00 Thijs Schreijer <[hidden email]>:
>
> > I find it confusing that the operator '~' is used for both 'xor' and
> 'unary not'.
>
> Think of it this way. Prefix `-` is related to infix `-` by the identity
>
>    -x == 0-x
>
> Prefix `~`, as your examples so clearly demonstrate, is related to infix `~`
> by
>
>    ~x == (-1)~x
>
> since -1 == 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

Thx. I understand the logic. But still would find '!' clearer for a unary not.
Thijs
1234567 ... 14