Re:some questions about lua

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

Re:some questions about lua

Philippe Lhoste
> I'm a newbie to lua. And there are some questions:
> 1. What is the pronunciation of 'lua'?   I want to use
> lua as the script of our game project and need to tell my teamate
> what is lua.

As a French, I pronounce lu-ah. With lu like in lucid (I checked with
Merriam-Webster, if you find I write horrible English, you don't have heard me :-)

> 2. I cannot surf  http://lua-users.org  Are there any mirror sites?

Mmm, works for me. Try http://www.lua-users.org which redirect to the above
site anyway. I doubt there is a mirror, which would be hard to maintain for a
Wiki (need very frequent updates).

> 3. Where can I find the specification of lua5.0?  Or work version?
> I cannot find it on www.lua.org

I think the authors are currently concentrating on the code rather than on
the documentation. There was an incomplete and now outdated (but better than
nothing :-) reference manual for Lua-4.1-work4. It was at
http://www.tecgraf.puc-rio.br/lua/work/refman-4.1-work4.pdf but it seems it has been removed,
probably for the reasons above...

> 4. Could I execute the lua script step by step? For example, I have
> the following script:
>   man_go_forward( 100, 100, 100 );
>   while( !button_pressed ){ man_wait() };
>   man_talk( "some words" );
>   man_fight();
> I need some control or some delay between lines of script. I need to
> execuate the script to some line, then engine code , then the script from
> the last position .....
>     Is it possible?

I am not expert on this field, but the debug library (ldblic.c & luadebug.h)
is probably what you are looking for. With it, you can create call or line
hooks, etc.
I think the 4.0 documentation is a good start for this.
There are some open source Lua debuggers (eg. Titmouse), they can be a good
start.

Regards.

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

GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net


Reply | Threaded
Open this post in threaded view
|

garbage collection (4.0.1)

D Burgess-2
Does anyone know -

Is there a document that describes what the 
Lua garbage collector collects?

How does it define "in use"?

Is it true that unreferenced userdata that has
a gc method always called during a collection cycle?

Does lua_close call the gc method for user data
regardless of whether it is  referenced?

D Burgess


Reply | Threaded
Open this post in threaded view
|

Re: garbage collection (4.0.1)

RLak

> Does anyone know -

> Is there a document that describes what the
> Lua garbage collector collects?

I don't know of one. However, a document is probably not necessary. It
collects anything that it can prove is not in use.

> How does it define "in use"?

It is the transitive closure of "references" starting with the globals
table, the stack, the reference table, and perhaps a few other things that
I have forgotten. In other words, if there is a reference to an object, it
is in use and so is everything that it references.

> Is it true that unreferenced userdata that has
> a gc method always called during a collection cycle?

I don't think you can count on that. It might be *logically* unreferenced,
but not actually garbage collectable yet (for example, it might be
referenced by a local on the stack which will never be used again, but the
garbage collector doesn't know that so it won't be garbage collected until
the stack slot is reused or the stack frame is cleared by the function
returning.)

However, if there is a gc method, it will be called before the object is
deleted.

> Does lua_close call the gc method for user data
> regardless of whether it is  referenced?

Yes. lua_close systematically deletes every allocated object, calling gc
methods if defined. However, in this case you cannot rely on the order of
collection to guarantee that gc methods will be called in the order you
think is logical. (The order is logical, but it might not accord with your
idea of your data, so it is unwise to count on this.) In particular, there
is no way to guarantee that objects will be garbage collected before
anything they reference has been garbage collected. There is no way to do
this because there might be circular references.




Reply | Threaded
Open this post in threaded view
|

Re: garbage collection (4.0.1)

D Burgess-2
Sincere thanks.

----- Original Message -----
From: <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Tuesday, July 09, 2002 1:22 AM
Subject: Re: garbage collection (4.0.1)


>
>
> > Does anyone know -
>
> > Is there a document that describes what the
> > Lua garbage collector collects?
>
> I don't know of one. However, a document is probably not necessary. It
> collects anything that it can prove is not in use.
>
> > How does it define "in use"?
>
> It is the transitive closure of "references" starting with the globals
> table, the stack, the reference table, and perhaps a few other things that
> I have forgotten. In other words, if there is a reference to an object, it
> is in use and so is everything that it references.
>
> > Is it true that unreferenced userdata that has
> > a gc method always called during a collection cycle?
>
> I don't think you can count on that. It might be *logically* unreferenced,
> but not actually garbage collectable yet (for example, it might be
> referenced by a local on the stack which will never be used again, but the
> garbage collector doesn't know that so it won't be garbage collected until
> the stack slot is reused or the stack frame is cleared by the function
> returning.)
>
> However, if there is a gc method, it will be called before the object is
> deleted.
>
> > Does lua_close call the gc method for user data
> > regardless of whether it is  referenced?
>
> Yes. lua_close systematically deletes every allocated object, calling gc
> methods if defined. However, in this case you cannot rely on the order of
> collection to guarantee that gc methods will be called in the order you
> think is logical. (The order is logical, but it might not accord with your
> idea of your data, so it is unwise to count on this.) In particular, there
> is no way to guarantee that objects will be garbage collected before
> anything they reference has been garbage collected. There is no way to do
> this because there might be circular references.
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: garbage collection (4.0.1)

Roberto Ierusalimschy
In reply to this post by RLak
> Yes. lua_close systematically deletes every allocated object, calling gc
> methods if defined. However, in this case you cannot rely on the order of
> collection to guarantee that gc methods will be called in the order you
> think is logical. (The order is logical, but it might not accord with your
> idea of your data, so it is unwise to count on this.) In particular, there
> is no way to guarantee that objects will be garbage collected before
> anything they reference has been garbage collected. There is no way to do
> this because there might be circular references.

A small correction: You can assume that, among udata being collected in
the same cycle, their GC metamethods are called in reverse order of
their creation. That is valid during lua_close, too.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: garbage collection (4.0.1)

RLak
In reply to this post by D Burgess-2
> A small correction: You can assume that, among udata being collected in
> the same cycle, their GC metamethods are called in reverse order of
> their creation. That is valid during lua_close, too.

Thanks. I thought they were garbage collected in order by tag in 4.0.1, but
I couldn't remember for sure.

Regardless, I wouldn't feel comfortable counting on the order of deletion
because it might change in some future version. This is a much-debated
theme about finalisation methods and the usual suggestion is that safe
coding requires making as few assumptions as possible. That is what I was
trying to communicate.

Rici.