[ANN] Lua 5.3.0 (work2) now available

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

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

Andrew Starks


On Saturday, March 22, 2014, Roberto Ierusalimschy <[hidden email]> wrote:
> >> There is no direct conversion from strings to integers:
> >> If a string is provided where an integer is needed,
> >> Lua converts the string to a float and then the float to an integer.
> Does it mean the following:
> assert('100000000000000001'%2 == 0)

Yes.


> It looks unnaturally for a language having 64-bit integers as native
> datatype.

Coercion from strings to numbers are considered a bad thing, and can
(should?) be removed in future versions. It did not seem worth to extend
to the new integer stuff something already outdate. (Ideally it should
raise an error, but that would create all sorts of incompatibilities.)

In other words, it is unnatural, but the whole coercion stuff is unnatural.

-- Roberto


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. 

There are new operators, which makes this release especially significant, already. As is, I believe that these works have will prove to compel people to upgrade.  Even if someone agrees with the change in coercion, often a business case is needed, in order to do the hard work of checking for new bugs. Since I believe that you have that here, it may be good to take advantage. 

It's easier to take medicine when it's washed down with something you like eating.

That's my perspective, anyway. 

Thank you for giving us this release!



-Andrew
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 Sat, Mar 22, 2014 at 11:49 AM, Roberto Ierusalimschy
<[hidden email]> wrote:

>> string.format uses a little language for constructing strings out of
>> numbers and other strings, primarily in variable-length decimal encoding. I
>> think a very similar language could be designed for constructing strings
>> out of numbers and other strings in the domain of fixed-size binary
>> encoding.
>>
>> Aside from symmetry, my motivation is premature optimization. string.pack
>> written in Lua would have the same problems as string.format written in
>> Lua: as formatting is executed, short strings will be created, pushed on a
>> Lua-side concat table, then turned into garbage. Easier and faster to do
>> this at the C level where string building is cheaper.
>
> You still can use external libraries for that (e.g., struct and lpack).
> We thought that this basic functionallity was a good trade-off beween
> usefuleness and simplicity for the standard library. (Thanks to
> Daurnimator for the suggestion.)
>
> -- Roberto
>

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.  (I know there are modules
for this, I just wish there were a core facility for doing so -- but
you could also just make bindings to the Lua C API and then write a
module over that.  I'm not sure which path I like more.)

Reply | Threaded
Open this post in threaded view
|

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

Coroutines
In reply to this post by Andrew Starks
On Sat, Mar 22, 2014 at 1:34 PM, Andrew Starks <[hidden email]> wrote:

>
>
> On Saturday, March 22, 2014, Roberto Ierusalimschy <[hidden email]>
> wrote:
>>
>> > >> There is no direct conversion from strings to integers:
>> > >> If a string is provided where an integer is needed,
>> > >> Lua converts the string to a float and then the float to an integer.
>> > Does it mean the following:
>> > assert('100000000000000001'%2 == 0)
>>
>> Yes.
>>
>>
>> > It looks unnaturally for a language having 64-bit integers as native
>> > datatype.
>>
>> Coercion from strings to numbers are considered a bad thing, and can
>> (should?) be removed in future versions. It did not seem worth to extend
>> to the new integer stuff something already outdate. (Ideally it should
>> raise an error, but that would create all sorts of incompatibilities.)
>>
>> In other words, it is unnatural, but the whole coercion stuff is
>> unnatural.
>>
>> -- Roberto
>>
>
> 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.
>
> There are new operators, which makes this release especially significant,
> already. As is, I believe that these works have will prove to compel people
> to upgrade.  Even if someone agrees with the change in coercion, often a
> business case is needed, in order to do the hard work of checking for new
> bugs. Since I believe that you have that here, it may be good to take
> advantage.
>
> It's easier to take medicine when it's washed down with something you like
> eating.
>
> That's my perspective, anyway.
>
> Thank you for giving us this release!
>
>
>
> -Andrew

I actually wish there were a __tonumber metamethod and that the
underlying C for numbers and strings to coerce between them were
exposed through metatables.  So if you don't like coercion you could
turn it off with the debug library: debug.getmetatable(0).__tostring =
nil

I would expose more than that, sonny :ppp

Reply | Threaded
Open this post in threaded view
|

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

Lorenzo Donati-3
In reply to this post by Luiz Henrique de Figueiredo
On 21/03/2014 21:44, Luiz Henrique de Figueiredo wrote:

> 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
>
>
>
Cool feature enhancements!

A couple of features I'd like to see implemented would be:

1. Binary literals, such as 0b100101101, or something like that.

2. A not significant digit separator for better readability of long numbers:

1111_222_333_4444 would be parsed (lexed?) as 1111222333444,
of course banning the underscore from the beginning and the end.

Cheers!
-- Lorenzo

--
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Reply | Threaded
Open this post in threaded view
|

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

Coroutines
On Sat, Mar 22, 2014 at 3:38 PM, Lorenzo Donati
<[hidden email]> wrote:

> On 21/03/2014 21:44, Luiz Henrique de Figueiredo wrote:
>> 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
>>
>>
>>
> Cool feature enhancements!
>
> A couple of features I'd like to see implemented would be:
>
> 1. Binary literals, such as 0b100101101, or something like that.
>
> 2. A not significant digit separator for better readability of long numbers:
>
> 1111_222_333_4444 would be parsed (lexed?) as 1111222333444,
> of course banning the underscore from the beginning and the end.
>
> Cheers!
> -- Lorenzo
>
> --
> ()  ascii ribbon campaign - against html e-mail
> /\  www.asciiribbon.org   - against proprietary attachments
>

I would like a %Q in string.format() for single-quoting strings :x
(it would also be nice if you could use format specifiers with %q/%Q,
as in: string.format([[ this is a string: %-16Q ]], "hello world!") ->
" this is a string: 'hello world!'  "

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
I note with gratification that the bit32 library is now
deprecated.

<http://lua-users.org/lists/lua-l/2010-12/msg01363.html>

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

Craig Barnes
On 23 March 2014 04:24, Dirk Laurie <[hidden email]> wrote:
> I note with gratification that the bit32 library is now
> deprecated.

+1. The new bitwise operators are a very welcome addition. I just did
a quick 'luac -l -p' comparison on some bit twiddling code, and the
bytecode for some functions shrank by 50% or more (including some
constant folding, it seems). Really looking forward to using the final
release.

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
This compiles fine on Windows 8.1 under minGW 4.8.1. Worked with a few
tiny modifications to my custom makefile for Lua 5.2.3; the makefile
distributed with 5.3.0 (work2) should work fine for standard build setups.

I give it  +1 (at least) for the new features! And none of my 5.2 stuff
has broken so far when recompiled for 5.3: not even my 5.2 bindings for
C/Invoke, which are still being tested.

I think now would be a good time to deprecate automatic conversion of
strings to numbers:  we aren't even at 5.3.0 alpha yet, so plenty of
time to try it out.

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.

Thanks again for the great work,

Mike

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
The 5.2.2 manual spell out the details of metamethods in pseudo-Lua.
The 5.3-work2 manual only does so in English, which is usually rather
different from the English of the 5.2.2 manual — understandably so,
since some things from the pseudo-Lua code now need to be said.

The description of metamethods therefore demands very careful
reading. So far I've found one subtle linguistic imprecision
in the new version, the description of __eq.

5.2.2: A metamethod is selected only when both values being compared
have the same type and the same metamethod for the selected operation,
and the values are either tables or full userdata.

5.3.work2: Lua will try a metamethod only when the values being
compared are both either tables or full userdata, both have the same
metamethod, and they are not primitively equal.

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.


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

steve donovan
In reply to this post by Lorenzo Donati-3
On Sun, Mar 23, 2014 at 12:38 AM, Lorenzo Donati
<[hidden email]> wrote:
> 1. Binary literals, such as 0b100101101, or something like that.

Easy enough to write:

> function B(b) return tonumber(b,2) end
> B'1010'
10

But it's true these are not literals and involve a function call.  I
don't know of the general usefullness; mostly binary is used for
training and then people move over to the more compact hex.

> 2. A not significant digit separator for better readability of long numbers:

It would be nice - I find myself counting zeros....

Reply | Threaded
Open this post in threaded view
|

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

Coroutines
On Sat, Mar 22, 2014 at 10:58 PM, steve donovan
<[hidden email]> wrote:

> On Sun, Mar 23, 2014 at 12:38 AM, Lorenzo Donati
> <[hidden email]> wrote:
>> 1. Binary literals, such as 0b100101101, or something like that.
>
> Easy enough to write:
>
>> function B(b) return tonumber(b,2) end
>> B'1010'
> 10
>
> But it's true these are not literals and involve a function call.  I
> don't know of the general usefullness; mostly binary is used for
> training and then people move over to the more compact hex.
>
>> 2. A not significant digit separator for better readability of long numbers:
>
> It would be nice - I find myself counting zeros....
>

I could see binary literals potentially being used in a config file,
where function calls of any kind would be disallowed :>

Reply | Threaded
Open this post in threaded view
|

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

Jeremy Ong
In reply to this post by steve donovan
Many binary protocols are more easily expressible with raw binary than
hex. This is because, to save space, single bits are often used to
represent something (possibly a continuation bit), thus allowing a
tighter packing.

This is used, for example, in websocket code to indicate continuation
frames or signal the existence of an extension. It's also useful when
implementing protocol buffers (variable width integers in particular).
Unicode is, of course, the canonical example.

On Sat, Mar 22, 2014 at 10:58 PM, steve donovan
<[hidden email]> wrote:

> On Sun, Mar 23, 2014 at 12:38 AM, Lorenzo Donati
> <[hidden email]> wrote:
>> 1. Binary literals, such as 0b100101101, or something like that.
>
> Easy enough to write:
>
>> function B(b) return tonumber(b,2) end
>> B'1010'
> 10
>
> But it's true these are not literals and involve a function call.  I
> don't know of the general usefullness; mostly binary is used for
> training and then people move over to the more compact hex.
>
>> 2. A not significant digit separator for better readability of long numbers:
>
> It would be nice - I find myself counting zeros....
>

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 Dirk Laurie-2
5.2.2: For the unary - and # operators, the metamethod is called with
a dummy second argument.

5.3.0-work2: For the unary minus and the bitwise not operators, the
metamethod is computed and called with a dummy second operand, equal
to the first one.

The length operator has been omitted (but it still is called with a
dummy second argument).

In both cases: This extra argument is only to simplify Lua's
internals; it may be removed in future versions. (For most uses this
extra argument is irrelevant.)

I'd like to argue in favour of changing the policy statement here to:

| This extra argument simplifies Lua's internals, and is irrelevant for
| most uses, but may be exploited by writers of metamethods.

I.e. no threat of its being removed, please!


2014-03-23 7:50 GMT+02:00 Dirk Laurie <[hidden email]>:

> The 5.2.2 manual spell out the details of metamethods in pseudo-Lua.
> The 5.3-work2 manual only does so in English, which is usually rather
> different from the English of the 5.2.2 manual — understandably so,
> since some things from the pseudo-Lua code now need to be said.
>
> The description of metamethods therefore demands very careful
> reading. So far I've found one subtle linguistic imprecision
> in the new version, the description of __eq.
>
> 5.2.2: A metamethod is selected only when both values being compared
> have the same type and the same metamethod for the selected operation,
> and the values are either tables or full userdata.
>
> 5.3.work2: Lua will try a metamethod only when the values being
> compared are both either tables or full userdata, both have the same
> metamethod, and they are not primitively equal.
>
> 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.
>
>
> 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

Enrico Colombini
In reply to this post by Roberto Ierusalimschy
On 22/03/2014 19.30, Roberto Ierusalimschy wrote:
> Can someone suggest a reasonable way to "fix" it without making the code
> uglier and/or generating useless code?

Rewriting Lua in C# and using "out" parameters? ;-)

I too like zero-warning compilation, but in this case I would just put a
comment in the code (as others seem to have done).

(I have just seen avr-gcc with -O3 'de-optimize' my code by adding extra
jmp instructions, so I am not in a mood to like that optimization level)

--
   Enrico

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 Dirk Laurie-2
On 23/03/2014 5.24, Dirk Laurie wrote:
> I note with gratification that the bit32 library is now
> deprecated.

Uh oh... I'd better read carefully the manual! I just wrote a music
compiler that uses bit32 heavily in the code generation module.

I am definitely not complaining, the native bitwise operators are very
welcome. Thanks to the Lua team for the great work!

In a near future I will have to decide: publish my program as it is (for
5.2 only), make it work with both 5.2 and 5.3 by adding a few
compatibility functions to emulate bitlib, or jump directly to 5.3 only?

This being a new program and part of an educational work, I would
greatly prefer the latter solution (5.3 only), not least to avoid having
to fully re-test it with 5.3 integers at a later time.
That could however pose a problem with naive users in Linux
distributions, that will probably not offer 5.3 for some time (my Lua
program is just a tool in a larger project).

I'll have to think about it (I guess I am not alone with this sort of
doubts).

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

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

Justin Cormack


On Mar 23, 2014 9:50 AM, "Enrico Colombini" <[hidden email]> wrote:
>
> On 23/03/2014 5.24, Dirk Laurie wrote:
>>
>> I note with gratification that the bit32 library is now
>> deprecated.
>
>
> Uh oh... I'd better read carefully the manual! I just wrote a music compiler that uses bit32 heavily in the code generation module.
>
> I am definitely not complaining, the native bitwise operators are very welcome. Thanks to the Lua team for the great work!
>
> In a near future I will have to decide: publish my program as it is (for 5.2 only), make it work with both 5.2 and 5.3 by adding a few compatibility functions to emulate bitlib, or jump directly to 5.3 only?
>
> This being a new program and part of an educational work, I would greatly prefer the latter solution (5.3 only), not least to avoid having to fully re-test it with 5.3 integers at a later time.
> That could however pose a problem with naive users in Linux distributions, that will probably not offer 5.3 for some time (my Lua program is just a tool in a larger project).
>
> I'll have to think about it (I guess I am not alone with this sort of doubts).
>

Deprecated means it will be available in 5.3 but not in the next release I think.

But the integer support will be very helpful for many programs using bitops so there is a dilemma still.

Justin

Reply | Threaded
Open this post in threaded view
|

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

Enrico Colombini
On 23/03/2014 10.59, Justin Cormack wrote:
> Deprecated means it will be available in 5.3 but not in the next release I
> think.

Possibly, but I do not feel comfortable using a feature that was not
there in the previous version and will not be there in the next one.

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...

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
> Possibly, but I do not feel comfortable using a feature that was not
> there in the previous version and will not be there in the next one.

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. In 5.2, require'bit32'
will automatically use the internal version.


> 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 :).

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Philipp Janda
In reply to this post by Luiz Henrique de Figueiredo
Am 21.03.2014 21:44 schröbte 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
>
> 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 index in the manual still contains an entry for `math.isfloat`
(leading nowhere).

>
> Enjoy. All feedback welcome. Thanks.
> --lhf
>

Philipp



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 Mike Nelson
> 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

123456 ... 14