Re: Stateless debugger

["Chris Mumford" <cmumford@...>]

As soon as I have something implemented I will post it as a patch back to
the Lua community. I'm still doing my research at the moment.

----- Original Message ----- 
From: "Ivano Coltellacci" <ivano.coltellacci@wanadoo.fr>
To: "Lua list" <lua@bazar2.conectiva.com.br>
Sent: Friday, November 07, 2003 1:51 AM
Subject: RE: Stateless debugger


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