Plans for version 5.0?

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

Plans for version 5.0?

rael er
Hi, 
  i'm considering using Lua for a new project I will be involved in 
and I'm in doubt on using the good old version 4 or the newer 5.

 Is there any plan for releasing a non-beta 5 version?

 Thanks.
                           Remo


Reply | Threaded
Open this post in threaded view
|

Re: Plans for version 5.0?

Luiz Henrique de Figueiredo
>  i'm considering using Lua for a new project I will be involved in 
>and I'm in doubt on using the good old version 4 or the newer 5.
>
> Is there any plan for releasing a non-beta 5 version?

Lua 5.0 is still in alpha. Lua 5.0 beta will be out by the end of the year and
Lua 5.0 final by Feb 2003.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Plans for version 5.0?

mnicolet
Which are the ´suspicious´ points of 5.0a ?
In other words: what are you, the authors, expecting to
find from our feedback before beta or final release ?
I am in the middle. I prefer 5.x because userdata support is more clean ( to
me, at least ), also, I am ready to put
5.0a to ´production state´. My tests performed ok, but the beta and final
release dates from lhf communication
are a little bothering ...
----- Original Message -----
From: "Luiz Henrique de Figueiredo" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Tuesday, October 22, 2002 7:24 AM
Subject: Re: Plans for version 5.0?


> >  i'm considering using Lua for a new project I will be involved in
> >and I'm in doubt on using the good old version 4 or the newer 5.
> >
> > Is there any plan for releasing a non-beta 5 version?
>
> Lua 5.0 is still in alpha. Lua 5.0 beta will be out by the end of the year
and
> Lua 5.0 final by Feb 2003.
> --lhf


Reply | Threaded
Open this post in threaded view
|

Re: Plans for version 5.0?

Luiz Henrique de Figueiredo
In reply to this post by rael er
>Which are the ´suspicious´ points of 5.0a ?

There are a few details about coroutines (eg. garbage collection) that we
need to understand. But mostly the manual needs to be fully written and this
takes a lot of time.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Plans for version 5.0?

Roberto Ierusalimschy
In reply to this post by mnicolet
> Which are the ´suspicious´ points of 5.0a ?

* As lhf pointed out, there is the problem with garbage collection of
coroutines (see http://lua-users.org/lists/lua-l/2002-09/msg00252.html).
Maybe we will have to create a new type in Lua, "threads". This in turn
may change the way threads are created and managed. (This should only
affect programs that use coroutines and/or multi-threading.)

* We are considering the option of each C function having its own
"global" table (like Lua functions already have). Again, this could
change only the way C libraries are loaded in programs that already
use the new facility of multiple global tables.

* We may change some names in lauxlib.h (but there will be `#defines' to
keep compatibility). We are considering the elimination of underscores
in those names, to follow the pattern in lua.h.


That's all. We are trying to release a beta version only after finished
all planned changes, and to change from beta to final only in case of
real bugs. That includes the documentation too, so we are planning to
release beta only with a "complete" manual.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Plans for version 5.0?

Basile STARYNKEVITCH
>>>>> "Roberto" == Roberto Ierusalimschy <[hidden email]> writes:

    >> Which are the "suspicious" points of 5.0a ?
    Roberto> * As lhf pointed out, there is the problem with garbage
    Roberto> collection of coroutines (see
    Roberto> http://lua-users.org/lists/lua-l/2002-09/msg00252.html).
    Roberto> Maybe we will have to create a new type in Lua,
    Roberto> "threads". This in turn may change the way threads are
    Roberto> created and managed. (This should only affect programs
    Roberto> that use coroutines and/or multi-threading.)

Perhaps Lua 5 might need string buffers (growable buffer of
characters), so that string manipulation becomes more efficient. I
read somewhere (but forgot the URL) that Lua performs very well (w.r.t
other scripting languages) except for string manipulation. But I may
be wrong!

More generally, I think that adding more builtin types is ok, as long
as the existing API is not broken.

    Roberto> * We are considering the option of each C function having
    Roberto> its own "global" table (like Lua functions already
    Roberto> have). Again, this could change only the way C libraries
    Roberto> are loaded in programs that already use the new facility
    Roberto> of multiple global tables.

    Roberto> * We may change some names in lauxlib.h (but there will
    Roberto> be `#defines' to keep compatibility). We are considering
    Roberto> the elimination of underscores in those names, to follow
    Roberto> the pattern in lua.h.


    Roberto> That's all. We are trying to release a beta version only
    Roberto> after finished all planned changes, and to change from
    Roberto> beta to final only in case of real bugs. That includes
    Roberto> the documentation too, so we are planning to release beta
    Roberto> only with a "complete" manual.

Great.

For what it is worth, the C-- compiler (coded in Ocaml) contains a Lua
interpreter (coded in Ocaml). See www.cminusminus.org for C-- and
www.ocaml.org for Ocaml.

Regards.

-- 

Basile STARYNKEVITCH         http://starynkevitch.net/Basile/ 
email: basile<at>starynkevitch<dot>net 
alias: basile<at>tunes<dot>org 
8, rue de la Faïencerie, 92340 Bourg La Reine, France

Reply | Threaded
Open this post in threaded view
|

Re: Plans for version 5.0?

Roberto Ierusalimschy
> Perhaps Lua 5 might need string buffers (growable buffer of
> characters), so that string manipulation becomes more efficient. I
> read somewhere (but forgot the URL) that Lua performs very well (w.r.t
> other scripting languages) except for string manipulation. But I may
> be wrong!

It is quite easy to implement a string buffer in Lua itself; see 
http://www.bagley.org/~doug/shootout/bench/strcat/strcat.lua

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Plans for version 5.0?

Luiz Henrique de Figueiredo
In reply to this post by rael er
>Perhaps Lua 5 might need string buffers (growable buffer of
>characters), so that string manipulation becomes more efficient.

As discussed before, Lua maintains unique strings and this kills modifiable
strings as a builtin type. Much of the speed in Lua (especially tables)
is due to the uniqueness of string: essentially, string comparisons become
pointer comparisons.

>I read somewhere (but forgot the URL) that Lua performs very well (w.r.t
>other scripting languages) except for string manipulation. But I may
>be wrong!

Possibly because those benchmarks build large strings incrementally,
with many steps. As discussed before here and in the wiki, there are
better ways to do both modifiable strings and incremental strings.

--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Plans for version 5.0?

mnicolet
In reply to this post by Luiz Henrique de Figueiredo
Thank you
Your answer is very welcomed.
----- Original Message -----
From: "Luiz Henrique de Figueiredo" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Tuesday, October 22, 2002 11:32 AM
Subject: Re: Plans for version 5.0?


> >Which are the ´suspicious´ points of 5.0a ?
>
> There are a few details about coroutines (eg. garbage collection) that we
> need to understand. But mostly the manual needs to be fully written and
this
> takes a lot of time.
> --lhf


Reply | Threaded
Open this post in threaded view
|

Re: Plans for version 5.0?

mnicolet
In reply to this post by Roberto Ierusalimschy
Tkank you also
Marcelo
----- Original Message -----
From: "Roberto Ierusalimschy" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Tuesday, October 22, 2002 1:09 PM
Subject: Re: Plans for version 5.0?


> Which are the ´suspicious´ points of 5.0a ?

* As lhf pointed out, there is the problem with garbage collection of
coroutines (see http://lua-users.org/lists/lua-l/2002-09/msg00252.html).
Maybe we will have to create a new type in Lua, "threads". This in turn
may change the way threads are created and managed. (This should only
affect programs that use coroutines and/or multi-threading.)

* We are considering the option of each C function having its own
"global" table (like Lua functions already have). Again, this could
change only the way C libraries are loaded in programs that already
use the new facility of multiple global tables.

* We may change some names in lauxlib.h (but there will be `#defines' to
keep compatibility). We are considering the elimination of underscores
in those names, to follow the pattern in lua.h.


That's all. We are trying to release a beta version only after finished
all planned changes, and to change from beta to final only in case of
real bugs. That includes the documentation too, so we are planning to
release beta only with a "complete" manual.

-- Roberto


Reply | Threaded
Open this post in threaded view
|

Re: Plans for version 5.0?

Philippe Lhoste
In reply to this post by Roberto Ierusalimschy
On 2002/10/22 18:45:19, Roberto Ierusalimschy <[hidden email]> 
wrote:

>> Perhaps Lua 5 might need string buffers (growable buffer of
>> characters), so that string manipulation becomes more efficient. I
>> read somewhere (but forgot the URL) that Lua performs very well (w.r.t
>> other scripting languages) except for string manipulation. But I may
>> be wrong!
> 
> It is quite easy to implement a string buffer in Lua itself; see 
> http://www.bagley.org/~doug/shootout/bench/strcat/strcat.lua

Interesting, it seems to be an implementation of the LTN9 
<http://www.lua.org/notes/ltn009.html>.
But I think Basile meant "efficient string buffers"...

Your implementation is good, of course, but still seems (if I understood 
the algorithm) to suffer (to a lesser extent) of some of the old problems: 
it is quite memory intensive as it uses a table to store parts of the 
buffer, and when closing it, we still have to concatenate the parts, 
generating garbage to collect.

Now, a string buffer library can be written quite easily and efficiently. 
The hard part may be to allow smooth integration with native strings. Or 
not?

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/



Reply | Threaded
Open this post in threaded view
|

RE: Plans for version 5.0?

Benoit Germain
In reply to this post by rael er
Hi,

> Maybe we will have to create a new type in Lua, "threads". 
> This in turn
> may change the way threads are created and managed. (This should only
> affect programs that use coroutines and/or multi-threading.)

This reminds me of a little problem I have:

I run several concurrent coroutines, that are essentially of the form

function f ( args )
	while true
	do
		<some stuff that may yield, or not>
		coroutine.yield()
	end
end

c = coroutine . create ( f , args )


once_per_frame_do = function ( )
	call_all_registered_such_coroutines()
end



What I want to achieve is this:
When f() yields somewhere inside <some stuff that may yield, or not> because
of an error that prevents normal processing, I want it to yield in a way
that causes it to resume as if newly created when c() is called again.
How is this achievable, apart from destroying the coroutine and creating a
new one (which is not practical, because those coroutines are referenced by
C++ objects and called from C++, so creating new ones means updating the
reference in the C++ object).
Since this yield may occur in functions called by this block, I suppose that
the stack needs to be unwound down to f()'s level. Is there some easy way of
doing this ?

Oh. maybe I could simply change to:

function g()
	<some stuff that may yield, or not>
end

function f ( args )
	while true
	do
		pcall (g,args)
		coroutine.yield()
	end
end

and have errors signalled by error()...


Regards,

Benoit.

Reply | Threaded
Open this post in threaded view
|

Re: Plans for version 5.0?

Roberto Ierusalimschy
In reply to this post by Philippe Lhoste
> Your implementation is good, of course, but still seems (if I understood 
> the algorithm) to suffer (to a lesser extent) of some of the old problems: 
> it is quite memory intensive as it uses a table to store parts of the 
> buffer,

I don't think so. The table is quite small: Typically around log2 of the
length of the final string, so for a string of 1M you will need only
20 entries. The strings inside it are parts of the final string, so
they use the same space that a buffer would use (but broken in several
parts).

> and when closing it, we still have to concatenate the parts, 
> generating garbage to collect.

That is true... But it is difficult to anticipate that this will be a
real problem in real applications. (And, in Lua 5, we can use
table.concat to close it more efficiently.)

-- Roberto