[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: Stateless debugger
- From: "Ivano Coltellacci" <ivano.coltellacci@...>
- Date: Fri, 7 Nov 2003 08:51:19 +0100
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
De : email@example.com
[mailto:firstname.lastname@example.org]De la part de Ando
Envoye : jeudi 6 novembre 2003 00:53
A : Lua list
Objet : Re: Stateless debugger
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
I start with a basic event loop (OS, not LUA) Note, code is pseudo code:
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
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:
system:Wait(1000) -- wait for the sprite to move itself
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
This isn't quite what you're looking for, but as I mention, maybe it
inspires a thought that helps...
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
> 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
> 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
> 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
> 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