lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


I haven't implemented anything yet, but I intend to if that hasn't already been done.
----- Original Message -----
Sent: Thursday, November 06, 2003 9:45 AM
Subject: Re: Re: Stateless debugger


Hi,

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

Im a quite similar problem. I have several lua interpreters running

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 du 06/11/03 00:53
De : Ando Sonenblick
A : Lua list
Copie à :
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