RE: Stateless debugger

["Ivano Coltellacci" <ivano.coltellacci@...>]

Hi ANdo, 

Im intersted for your implementation of the wait in the C side.

I have a quite similar problem. I have several lua interpreters running, 
they dont are running in threads but are activated sequentialy by my
scheduler and I need to implement system:wait() functions, to delay their
execution at some point on the future. Can you explain me your 
"wait" implementation? 

-----Message d'origine-----
De : lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br]De la part de Ando
Sonenblick
Envoye : jeudi 6 novembre 2003 00:53
A : Lua list
Objet : Re: Stateless debugger


Chris,

I'm not doing stuff quite as sophisticated as you (interprocess 
manipulation, etc) but I do use lua in a similar way - whereby lua is 
blocked in the middle of a script while other stuff goes on.

Maybe it'll spark an idea for your situation.  Here is basically what I 
have.

I start with a basic event loop (OS, not LUA) Note, code is pseudo code:

main()
{

     while (!done)
	ProcessNextEvent();
}

Inside ProcessNextEvent, normal stuff happens.  And some events (like a 
user clicking a button, say) will execute lua scripts.

Now, some of my scripts manipulate sprites.  But sometimes you want to 
do things, wait a bit (for the sprite to do its thing) then do another 
thing, etc.

This normally means a state machine, and using idle time or callbacks 
to monitor and queue up the next animation, etc.

Sure would be nice if I could just:


sprite:Move(...)
system:Wait(1000)   -- wait for the sprite to move itself
sprite:Flip()
system:Wait(200)   -- wait for the flip

and so on..

but one would normally think that Wait would freeze out other things.  
Not so in my case, as my Wait (as implemented in my C code) does the 
wait logic but it also calls ProcessNextEvent.  This way that one lua 
script does block, but the app continues running (events can occur 
other scripts can get executed, etc).

So basically my app is reentrant.  And fortunately so is lua, so this 
all works.

This isn't quite what you're looking for, but as I mention, maybe it 
inspires a thought that helps...

ando

On Wednesday, November 5, 2003, at 02:58 PM, Chris Mumford wrote:

> I'm brand new to the Lua community. I've read through the archive and
> documentation and haven't found this answer yet so I figure I'd ask the
> experts.
>
> I'm trying to use Lua on a single process machine (Palm) to sumulate a
> second process. This is for a test driver that I'm writing. My goal is 
> to be
> able to write a Lua script that does things like 1) Starts an 
> application,
> 2) selects a menu item, 3) enters text, 4) clicks a "done" button, 
> etc. My
> thinking was that I could drive the Lua interpreter much like a 
> debugger. I
> would occasionally (let's say on an idle event) do the equivalent of a
> "step" in the debugger.
>
> My problem is that Lua doesn't seem to be stateless. It drives the 
> debugger
> via hooks instead of the other way around. I've figured out how to use
> lua_sethook to specify my callback functions, but what I need to do 
> here is
> give control back to the OS and resume the interpreter later.
>
> The debuggers I see either spawn a debugger thread, or a separate 
> process.
> Is there a way to do all of this in a single thread? Have I asked the
> question intelligently?
>
> Thanks for any assistance. Regards,
>
> Chris Mumford
>
>
-----------------------
Ando Sonenblick
SpriTec Software
www.spritec.com