[ANN] Lua 5.3.0 (alpha) now available

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

[ANN] Lua 5.3.0 (alpha) now available

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

MD5 2922a0c3b64c8a2f678d2510b7a5a336  -
SHA1 b2f86c16a38310c9e240c70216618308097444f6  -

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

The main change in Lua 5.3.0 is the introduction of integers. See also
        http://www.lua.org/work/doc/#changes

The complete diffs are available at
        http://www.lua.org/work/diffs-lua-5.3.0-work3-alpha.txt

All feedback welcome. Thanks.
--lhf


Reply | Threaded
Open this post in threaded view
|

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

Andrew Starks



On Thu, Jul 31, 2014 at 1:30 PM, Luiz Henrique de Figueiredo <[hidden email]> wrote:
Lua 5.3.0 (alpha) is now available for testing at
        http://www.lua.org/work/lua-5.3.0-alpha.tar.gz

MD5     2922a0c3b64c8a2f678d2510b7a5a336  -
SHA1    b2f86c16a38310c9e240c70216618308097444f6  -

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

The main change in Lua 5.3.0 is the introduction of integers. See also
        http://www.lua.org/work/doc/#changes

The complete diffs are available at
        http://www.lua.org/work/diffs-lua-5.3.0-work3-alpha.txt

All feedback welcome. Thanks.
--lhf




Yay!

I read through the definition of "table.copy" and I don't grasp it. I assume that the updated reference isn't complete. The definition is:

table.copy (a1, f, e, [a2,] t)

Reading the text, I think that:

a1 is source
a2 is target. if a2 is missing then a1 is used.
t is the target index's start, such that the first index to be copied. (shouldn't this default to 1 or f?)
f is "first"?
e is "end"?

so:

table.copy(source, 1, 10, destination, 5)

would copy index 1 ... 10 into the table 'destination', starting at index 5

Is that correct? Is this interface mimicking some pattern that I haven't seen before? I didn't find this easy to read or understand.

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

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

Coroutines
On Thu, Jul 31, 2014 at 11:48 AM, Andrew Starks <[hidden email]> wrote:

>
>
>
> On Thu, Jul 31, 2014 at 1:30 PM, Luiz Henrique de Figueiredo
> <[hidden email]> wrote:
>>
>> Lua 5.3.0 (alpha) is now available for testing at
>>         http://www.lua.org/work/lua-5.3.0-alpha.tar.gz
>>
>> MD5     2922a0c3b64c8a2f678d2510b7a5a336  -
>> SHA1    b2f86c16a38310c9e240c70216618308097444f6  -
>>
>> This is an alpha version. Some details may change in the final version.
>>
>> The main change in Lua 5.3.0 is the introduction of integers. See also
>>         http://www.lua.org/work/doc/#changes
>>
>> The complete diffs are available at
>>         http://www.lua.org/work/diffs-lua-5.3.0-work3-alpha.txt
>>
>> All feedback welcome. Thanks.
>> --lhf
>>
>>
>
>
> Yay!
>
> I read through the definition of "table.copy" and I don't grasp it. I assume
> that the updated reference isn't complete. The definition is:
>
> table.copy (a1, f, e, [a2,] t)
>
> Reading the text, I think that:
>
> a1 is source
> a2 is target. if a2 is missing then a1 is used.
> t is the target index's start, such that the first index to be copied.
> (shouldn't this default to 1 or f?)
> f is "first"?
> e is "end"?
>
> so:
>
> table.copy(source, 1, 10, destination, 5)
>
> would copy index 1 ... 10 into the table 'destination', starting at index 5
>
> Is that correct? Is this interface mimicking some pattern that I haven't
> seen before? I didn't find this easy to read or understand.
>
> -Andrew

See I thought the reverse -- if you plan to use the 'table' library
for your own supertype of tables, you'd want the first argument to be
the destination, so you can do: some_table:copy(source, ...) --
some_table being the destination, the table copied into

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
In reply to this post by Andrew Starks
> I read through the definition of "table.copy" and I don't grasp it. I
> assume that the updated reference isn't complete. The definition is:
>
> table.copy (a1, f, e, [a2,] t)
>
> Reading the text, I think that:
>
> a1 is source
> a2 is target. if a2 is missing then a1 is used.
> t is the target index's start, such that the first index to be copied.
> (shouldn't this default to 1 or f?)
> f is "first"?
> e is "end"?

Yes.


> so:
>
> table.copy(source, 1, 10, destination, 5)
>
> would copy index 1 ... 10 into the table 'destination', starting at index 5
>
> Is that correct?

Yes.


> Is this interface mimicking some pattern that I haven't seen before?

Not that we know. Do you suggest something else?


> I didn't find this easy to read or understand.

:(  (Well, in the end you did understand it all, correctly :)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

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

Coda Highland
In reply to this post by Coroutines
On Thu, Jul 31, 2014 at 12:00 PM, Coroutines <[hidden email]> wrote:
> See I thought the reverse -- if you plan to use the 'table' library
> for your own supertype of tables, you'd want the first argument to be
> the destination, so you can do: some_table:copy(source, ...) --
> some_table being the destination, the table copied into

Here, we disagree: If you didn't pass any parameters, you would expect
some_table:copy() to return a copy of some_table -- that is to say,
some_table is the source. I would find the behavior unintuitive if it
were otherwise.

Essentially, I read "copy" in this context as "copy_into". A
"pull"-type operation would be... I don't know, "fill" or something.
Maybe "copy_from". Not an unadorned "copy" for sure.

That said, the syntax of table.copy here... I'll have to agree that
it's not exactly intuitive. I'm not sure how to improve it, except
that I think perhaps "move" might be a better name overall if it's
possible for (source, first, end, target) to have target be between
first and end. (c.f. memmove())

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

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

Rena
In reply to this post by Roberto Ierusalimschy
On Thu, Jul 31, 2014 at 3:08 PM, Roberto Ierusalimschy
<[hidden email]> wrote:

>> I read through the definition of "table.copy" and I don't grasp it. I
>> assume that the updated reference isn't complete. The definition is:
>>
>> table.copy (a1, f, e, [a2,] t)
>>
>> Reading the text, I think that:
>>
>> a1 is source
>> a2 is target. if a2 is missing then a1 is used.
>> t is the target index's start, such that the first index to be copied.
>> (shouldn't this default to 1 or f?)
>> f is "first"?
>> e is "end"?
>
> Yes.
>
>
>> so:
>>
>> table.copy(source, 1, 10, destination, 5)
>>
>> would copy index 1 ... 10 into the table 'destination', starting at index 5
>>
>> Is that correct?
>
> Yes.
>
>
>> Is this interface mimicking some pattern that I haven't seen before?
>
> Not that we know. Do you suggest something else?
>
>
>> I didn't find this easy to read or understand.
>
> :(  (Well, in the end you did understand it all, correctly :)
>
> -- Roberto
>

The implementation I often see is:
table.clone = function(table)
  local res = {}
  for k,v in pairs(table) do
    res[k]=v
  end
  return res
end

i.e. given a table, return a shallow copy of it. While this isn't
quite the same operation, I do think table.copy should return a2 (or
a1, if a2 isn't provided) for simplicity's sake, and the defaults for
f, e, t ought to be 1, #a1, 1. Then you would be able to write:
myCopy = table.copy(myTable, {}) --copy into an empty table and return it

though, now we're getting kind of ugly with optional parameters in
strange places...

As an aside, I've been really looking forward to the bitwise
operators, UTF-8 library, and a few of these other changes. :D
--
Sent from my Game Boy.

Reply | Threaded
Open this post in threaded view
|

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

Xavier Wang
In reply to this post by Luiz Henrique de Figueiredo
> All feedback welcome. Thanks.
> --lhf

Very happy to see alpha version is released :)

Now we can use Lua as a calculator, So how about move a little forward?

I mean, if you input a expression instead of a statement, lua can
print it directly, so why not assign it to a global variable
(defaultly "It") and print as this:

> 123
lt = 123

then you can use lt for farther process? just like this:

> function(...) print(">> ", ...)
lt = function: .....
> lt "Hello"
lt = Hello

notice that a function call can also a expression, so it assign it to
"It", also.

--
regards,
Xavier Wang.

Reply | Threaded
Open this post in threaded view
|

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

Andrew Starks
In reply to this post by Roberto Ierusalimschy



On Thu, Jul 31, 2014 at 2:08 PM, Roberto Ierusalimschy <[hidden email]> wrote:
> I read through the definition of "table.copy" and I don't grasp it. I
> assume that the updated reference isn't complete. The definition is:
>
> table.copy (a1, f, e, [a2,] t)
>
> Reading the text, I think that:
>
> a1 is source
> a2 is target. if a2 is missing then a1 is used.
> t is the target index's start, such that the first index to be copied.
> (shouldn't this default to 1 or f?)
> f is "first"?
> e is "end"?

Yes.


> so:
>
> table.copy(source, 1, 10, destination, 5)
>
> would copy index 1 ... 10 into the table 'destination', starting at index 5
>
> Is that correct?

Yes.


> Is this interface mimicking some pattern that I haven't seen before?

Not that we know. Do you suggest something else?


> I didn't find this easy to read or understand.

:(  (Well, in the end you did understand it all, correctly :)

-- Roberto

 

All of the information efficiently presented and present...

Original:
`Copies elements from table a1 to table a2. This function performs the equivalent to the following multiple assignment: a2[t],··· = a1[f],···,a1[e]. The default for a2 is a1. The destination range can overlap with the source range. Index f must be positive.`

The second sentence is a bit difficult for me to parse. It may have been clearer to me with something like:

"`f` and `e` define the beginning and end indexes to copy, while `t` defines the starting target index for a2."

I'm not sure that a different syntax is needed, but having to define the start, end and target index seems surprisingly verbose, when defaults would be assumed to be common (1, #a1, 1)

If that's the case:

table.copy(a1,[a2],[f], [e],[t])

But my suggestion is clouded by a lack of context. What are the envisioned use cases for it / where does this come up? Is it faster than a for loop?

I also agree that "table.copy" seems to suggest "any key value". Obviously its definition clears that up. "table.icopy" seems to fit "pairs" and "ipairs", but I don't mean to nitpick. 

It was mentioned that "table.clear" (or similar) was likely. Was it decided that it would not be useful?

-Andrew

Reply | Threaded
Open this post in threaded view
|

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

Xavier Wang
> It was mentioned that "table.clear" (or similar) was likely. Was it decided
> that it would not be useful?
>
+1 for table.clear :)


--
regards,
Xavier Wang.

Reply | Threaded
Open this post in threaded view
|

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

Dirk Laurie-2
In reply to this post by Luiz Henrique de Figueiredo
---
table.copy (a1, f, e, [a2,] t)

Copies elements from table a1 to table a2. This function performs the
equivalent to the following multiple assignment: a2[t],··· =
a1[f],···,a1[e]. The default for a2 is a1. The destination range can
overlap with the source range. Index f must be positive.
---

I have mixed feelings about this. Last year [1] John Hind and I
wrote a module called "xtable" containing a function block.move
such that when e>=f,
   block.move(a1,f,e,t)
does exactly what the above definition of
   table.copy(a1,f,e,t)
does. So I should be very pleased. However, I am not delighted
by an optional argument preceding a non-optional one. It violates
my sense of conceptual integrity.

[1] <http://lua-users.org/lists/lua-l/2013-04/msg00016.html>



2014-07-31 20:30 GMT+02:00 Luiz Henrique de Figueiredo <[hidden email]>:

> Lua 5.3.0 (alpha) is now available for testing at
>         http://www.lua.org/work/lua-5.3.0-alpha.tar.gz
>
> MD5     2922a0c3b64c8a2f678d2510b7a5a336  -
> SHA1    b2f86c16a38310c9e240c70216618308097444f6  -
>
> This is an alpha version. Some details may change in the final version.
>
> The main change in Lua 5.3.0 is the introduction of integers. See also
>         http://www.lua.org/work/doc/#changes
>
> The complete diffs are available at
>         http://www.lua.org/work/diffs-lua-5.3.0-work3-alpha.txt
>
> All feedback welcome. Thanks.
> --lhf
>
>

Reply | Threaded
Open this post in threaded view
|

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

Coda Highland
On Thu, Jul 31, 2014 at 1:39 PM, Dirk Laurie <[hidden email]> wrote:

> ---
> table.copy (a1, f, e, [a2,] t)
>
> Copies elements from table a1 to table a2. This function performs the
> equivalent to the following multiple assignment: a2[t],··· =
> a1[f],···,a1[e]. The default for a2 is a1. The destination range can
> overlap with the source range. Index f must be positive.
> ---
>
> I have mixed feelings about this. Last year [1] John Hind and I
> wrote a module called "xtable" containing a function block.move
> such that when e>=f,
>    block.move(a1,f,e,t)
> does exactly what the above definition of
>    table.copy(a1,f,e,t)
> does. So I should be very pleased. However, I am not delighted
> by an optional argument preceding a non-optional one. It violates
> my sense of conceptual integrity.
>
> [1] <http://lua-users.org/lists/lua-l/2013-04/msg00016.html>
>

You know, maybe the resolution is to define separate move() and copy()
functions, where move() doesn't accept a destination, and copy()
requires one.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

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

Andrew Starks



On Thu, Jul 31, 2014 at 3:46 PM, Coda Highland <[hidden email]> wrote:
On Thu, Jul 31, 2014 at 1:39 PM, Dirk Laurie <[hidden email]> wrote:
> ---
> table.copy (a1, f, e, [a2,] t)
>
> Copies elements from table a1 to table a2. This function performs the
> equivalent to the following multiple assignment: a2[t],··· =
> a1[f],···,a1[e]. The default for a2 is a1. The destination range can
> overlap with the source range. Index f must be positive.
> ---
>
> I have mixed feelings about this. Last year [1] John Hind and I
> wrote a module called "xtable" containing a function block.move
> such that when e>=f,
>    block.move(a1,f,e,t)
> does exactly what the above definition of
>    table.copy(a1,f,e,t)
> does. So I should be very pleased. However, I am not delighted
> by an optional argument preceding a non-optional one. It violates
> my sense of conceptual integrity.
>
> [1] <http://lua-users.org/lists/lua-l/2013-04/msg00016.html>
>

You know, maybe the resolution is to define separate move() and copy()
functions, where move() doesn't accept a destination, and copy()
requires one.

/s/ Adam


But my read of the documentation tells me that the original values remain. Is that not the case? If it is, then move is more confusing, to me. 

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

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

Coda Highland
On Thu, Jul 31, 2014 at 1:48 PM, Andrew Starks <[hidden email]> wrote:

>
>
>
> On Thu, Jul 31, 2014 at 3:46 PM, Coda Highland <[hidden email]> wrote:
>>
>> On Thu, Jul 31, 2014 at 1:39 PM, Dirk Laurie <[hidden email]>
>> wrote:
>> > ---
>> > table.copy (a1, f, e, [a2,] t)
>> >
>> > Copies elements from table a1 to table a2. This function performs the
>> > equivalent to the following multiple assignment: a2[t],··· =
>> > a1[f],···,a1[e]. The default for a2 is a1. The destination range can
>> > overlap with the source range. Index f must be positive.
>> > ---
>> >
>> > I have mixed feelings about this. Last year [1] John Hind and I
>> > wrote a module called "xtable" containing a function block.move
>> > such that when e>=f,
>> >    block.move(a1,f,e,t)
>> > does exactly what the above definition of
>> >    table.copy(a1,f,e,t)
>> > does. So I should be very pleased. However, I am not delighted
>> > by an optional argument preceding a non-optional one. It violates
>> > my sense of conceptual integrity.
>> >
>> > [1] <http://lua-users.org/lists/lua-l/2013-04/msg00016.html>
>> >
>>
>> You know, maybe the resolution is to define separate move() and copy()
>> functions, where move() doesn't accept a destination, and copy()
>> requires one.
>>
>> /s/ Adam
>>
>
> But my read of the documentation tells me that the original values remain.
> Is that not the case? If it is, then move is more confusing, to me.
>
> -Andrew

If the destination range overlaps the source range, you'll see why
it's a "move" operation.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

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

Andrew Starks



On Thu, Jul 31, 2014 at 3:56 PM, Coda Highland <[hidden email]> wrote:
On Thu, Jul 31, 2014 at 1:48 PM, Andrew Starks <[hidden email]> wrote:
>
>
>
> On Thu, Jul 31, 2014 at 3:46 PM, Coda Highland <[hidden email]> wrote:
>>
>> On Thu, Jul 31, 2014 at 1:39 PM, Dirk Laurie <[hidden email]>
>> wrote:
>> > ---
>> > table.copy (a1, f, e, [a2,] t)
>> >
>> > Copies elements from table a1 to table a2. This function performs the
>> > equivalent to the following multiple assignment: a2[t],··· =
>> > a1[f],···,a1[e]. The default for a2 is a1. The destination range can
>> > overlap with the source range. Index f must be positive.
>> > ---
>> >
>> > I have mixed feelings about this. Last year [1] John Hind and I
>> > wrote a module called "xtable" containing a function block.move
>> > such that when e>=f,
>> >    block.move(a1,f,e,t)
>> > does exactly what the above definition of
>> >    table.copy(a1,f,e,t)
>> > does. So I should be very pleased. However, I am not delighted
>> > by an optional argument preceding a non-optional one. It violates
>> > my sense of conceptual integrity.
>> >
>> > [1] <http://lua-users.org/lists/lua-l/2013-04/msg00016.html>
>> >
>>
>> You know, maybe the resolution is to define separate move() and copy()
>> functions, where move() doesn't accept a destination, and copy()
>> requires one.
>>
>> /s/ Adam
>>
>
> But my read of the documentation tells me that the original values remain.
> Is that not the case? If it is, then move is more confusing, to me.
>
> -Andrew

If the destination range overlaps the source range, you'll see why
it's a "move" operation.

/s/ Adam


yes, but I didn't read that the non-overlapping values will be removed. Assuming that a2 is absent:


a1[2], a1[3], a1[4] = a1[1], a1[2], a1[3]

I believe that a1[1] is still present, no? If it is, do you still think "move" is more appropriate? 


--Andrew

Reply | Threaded
Open this post in threaded view
|

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

Coda Highland
On Thu, Jul 31, 2014 at 2:09 PM, Andrew Starks <[hidden email]> wrote:

>
>
>
> On Thu, Jul 31, 2014 at 3:56 PM, Coda Highland <[hidden email]> wrote:
>>
>> On Thu, Jul 31, 2014 at 1:48 PM, Andrew Starks <[hidden email]>
>> wrote:
>> >
>> >
>> >
>> > On Thu, Jul 31, 2014 at 3:46 PM, Coda Highland <[hidden email]>
>> > wrote:
>> >>
>> >> On Thu, Jul 31, 2014 at 1:39 PM, Dirk Laurie <[hidden email]>
>> >> wrote:
>> >> > ---
>> >> > table.copy (a1, f, e, [a2,] t)
>> >> >
>> >> > Copies elements from table a1 to table a2. This function performs the
>> >> > equivalent to the following multiple assignment: a2[t],··· =
>> >> > a1[f],···,a1[e]. The default for a2 is a1. The destination range can
>> >> > overlap with the source range. Index f must be positive.
>> >> > ---
>> >> >
>> >> > I have mixed feelings about this. Last year [1] John Hind and I
>> >> > wrote a module called "xtable" containing a function block.move
>> >> > such that when e>=f,
>> >> >    block.move(a1,f,e,t)
>> >> > does exactly what the above definition of
>> >> >    table.copy(a1,f,e,t)
>> >> > does. So I should be very pleased. However, I am not delighted
>> >> > by an optional argument preceding a non-optional one. It violates
>> >> > my sense of conceptual integrity.
>> >> >
>> >> > [1] <http://lua-users.org/lists/lua-l/2013-04/msg00016.html>
>> >> >
>> >>
>> >> You know, maybe the resolution is to define separate move() and copy()
>> >> functions, where move() doesn't accept a destination, and copy()
>> >> requires one.
>> >>
>> >> /s/ Adam
>> >>
>> >
>> > But my read of the documentation tells me that the original values
>> > remain.
>> > Is that not the case? If it is, then move is more confusing, to me.
>> >
>> > -Andrew
>>
>> If the destination range overlaps the source range, you'll see why
>> it's a "move" operation.
>>
>> /s/ Adam
>>
>
> yes, but I didn't read that the non-overlapping values will be removed.
> Assuming that a2 is absent:
>
>
> a1[2], a1[3], a1[4] = a1[1], a1[2], a1[3]
>
> I believe that a1[1] is still present, no? If it is, do you still think
> "move" is more appropriate?
>
>
> --Andrew
>

I acknowledge it's not perfect, but it does have precedent in the
programming world, going way, way back -- x86 assembly language, for
example, calls a register-to-register copy "MOV", and the operation
mimicks the POSIX memmove() function.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

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

Andrew Starks



On Thu, Jul 31, 2014 at 4:12 PM, Coda Highland <[hidden email]> wrote:
On Thu, Jul 31, 2014 at 2:09 PM, Andrew Starks <[hidden email]> wrote:
>
>
>
> On Thu, Jul 31, 2014 at 3:56 PM, Coda Highland <[hidden email]> wrote:
>>
>> On Thu, Jul 31, 2014 at 1:48 PM, Andrew Starks <[hidden email]>
>> wrote:
>> >
>> >
>> >
>> > On Thu, Jul 31, 2014 at 3:46 PM, Coda Highland <[hidden email]>
>> > wrote:
>> >>
>> >> On Thu, Jul 31, 2014 at 1:39 PM, Dirk Laurie <[hidden email]>
>> >> wrote:
>> >> > ---
>> >> > table.copy (a1, f, e, [a2,] t)
>> >> >
>> >> > Copies elements from table a1 to table a2. This function performs the
>> >> > equivalent to the following multiple assignment: a2[t],··· =
>> >> > a1[f],···,a1[e]. The default for a2 is a1. The destination range can
>> >> > overlap with the source range. Index f must be positive.
>> >> > ---
>> >> >
>> >> > I have mixed feelings about this. Last year [1] John Hind and I
>> >> > wrote a module called "xtable" containing a function block.move
>> >> > such that when e>=f,
>> >> >    block.move(a1,f,e,t)
>> >> > does exactly what the above definition of
>> >> >    table.copy(a1,f,e,t)
>> >> > does. So I should be very pleased. However, I am not delighted
>> >> > by an optional argument preceding a non-optional one. It violates
>> >> > my sense of conceptual integrity.
>> >> >
>> >> > [1] <http://lua-users.org/lists/lua-l/2013-04/msg00016.html>
>> >> >
>> >>
>> >> You know, maybe the resolution is to define separate move() and copy()
>> >> functions, where move() doesn't accept a destination, and copy()
>> >> requires one.
>> >>
>> >> /s/ Adam
>> >>
>> >
>> > But my read of the documentation tells me that the original values
>> > remain.
>> > Is that not the case? If it is, then move is more confusing, to me.
>> >
>> > -Andrew
>>
>> If the destination range overlaps the source range, you'll see why
>> it's a "move" operation.
>>
>> /s/ Adam
>>
>
> yes, but I didn't read that the non-overlapping values will be removed.
> Assuming that a2 is absent:
>
>
> a1[2], a1[3], a1[4] = a1[1], a1[2], a1[3]
>
> I believe that a1[1] is still present, no? If it is, do you still think
> "move" is more appropriate?
>
>
> --Andrew
>

I acknowledge it's not perfect, but it does have precedent in the
programming world, going way, way back -- x86 assembly language, for
example, calls a register-to-register copy "MOV", and the operation
mimicks the POSIX memmove() function.

/s/ Adam



That's a great reason. Then I guess it would depend on the imagined user's context.

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

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

Thijs Schreijer
In reply to this post by Luiz Henrique de Figueiredo
The 'debug.Csize' naming is an anomaly because of its capitalization. I'd prefer an all lower case naming for consistency.

Thijs




2014-07-31 20:30 GMT+02:00 Luiz Henrique de Figueiredo <[hidden email]>:
> Lua 5.3.0 (alpha) is now available for testing at
>         http://www.lua.org/work/lua-5.3.0-alpha.tar.gz
>
> MD5     2922a0c3b64c8a2f678d2510b7a5a336  -
> SHA1    b2f86c16a38310c9e240c70216618308097444f6  -
>
> This is an alpha version. Some details may change in the final version.
>
> The main change in Lua 5.3.0 is the introduction of integers. See also
>         http://www.lua.org/work/doc/#changes
>
> The complete diffs are available at
>         http://www.lua.org/work/diffs-lua-5.3.0-work3-alpha.txt
>
> All feedback welcome. Thanks.
> --lhf
>
>

Reply | Threaded
Open this post in threaded view
|

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

Xavier Wang

yes, i prefer debug.sizeof()

2014年8月1日 上午5:38于 "Thijs Schreijer" <[hidden email]>写道:
The 'debug.Csize' naming is an anomaly because of its capitalization. I'd prefer an all lower case naming for consistency.

Thijs




2014-07-31 20:30 GMT+02:00 Luiz Henrique de Figueiredo <[hidden email]>:
> Lua 5.3.0 (alpha) is now available for testing at
>         http://www.lua.org/work/lua-5.3.0-alpha.tar.gz
>
> MD5     2922a0c3b64c8a2f678d2510b7a5a336  -
> SHA1    b2f86c16a38310c9e240c70216618308097444f6  -
>
> This is an alpha version. Some details may change in the final version.
>
> The main change in Lua 5.3.0 is the introduction of integers. See also
>         http://www.lua.org/work/doc/#changes
>
> The complete diffs are available at
>         http://www.lua.org/work/diffs-lua-5.3.0-work3-alpha.txt
>
> All feedback welcome. Thanks.
> --lhf
>
>

Reply | Threaded
Open this post in threaded view
|

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

Soni "They/Them" L.
In reply to this post by Luiz Henrique de Figueiredo

On 31/07/14 03:30 PM, Luiz Henrique de Figueiredo wrote:

> Lua 5.3.0 (alpha) is now available for testing at
> http://www.lua.org/work/lua-5.3.0-alpha.tar.gz
>
> MD5 2922a0c3b64c8a2f678d2510b7a5a336  -
> SHA1 b2f86c16a38310c9e240c70216618308097444f6  -
>
> This is an alpha version. Some details may change in the final version.
>
> The main change in Lua 5.3.0 is the introduction of integers. See also
> http://www.lua.org/work/doc/#changes
>
> The complete diffs are available at
> http://www.lua.org/work/diffs-lua-5.3.0-work3-alpha.txt
>
> All feedback welcome. Thanks.
> --lhf
>
>
Is this intended?

Lua 5.3.0 (alpha)  Copyright (C) 1994-2014 Lua.org, PUC-Rio
 > error()
(error object is not a string)

Reply | Threaded
Open this post in threaded view
|

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

Tim Hill
In reply to this post by Rena

On Jul 31, 2014, at 12:30 PM, Rena <[hidden email]> wrote:

> On Thu, Jul 31, 2014 at 3:08 PM, Roberto Ierusalimschy
> <[hidden email]> wrote:
>
> i.e. given a table, return a shallow copy of it. While this isn't
> quite the same operation, I do think table.copy should return a2 (or
> a1, if a2 isn't provided) for simplicity's sake, and the defaults for
> f, e, t ought to be 1, #a1, 1. Then you would be able to write:
> myCopy = table.copy(myTable, {}) --copy into an empty table and return it
>

Pretty easy to create a tiny wrapper function that does this.

—Tim



1234 ... 7