[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Summer of Code 2009
From: |
Robin Lee Powell |
Subject: |
Re: Summer of Code 2009 |
Date: |
Sun, 17 May 2009 22:32:09 -0700 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
On Tue, May 12, 2009 at 02:07:41PM +0000, Rui Guo wrote:
> On Mon, 2009-05-11 at 23:56 -0700, Robin Lee Powell wrote:
> > I'd love to be able to use it basically as a replacement for
> > Expect. Being able to actually *see* what was going one whilst
> > driving a full-screen application with a script would be
> > *really* nice.
> >
>
> A great idea. We can definitely achieve similar functionality with
> little difficulty. The problem is how to make it easy to use,
> since this will not be the only use pattern. I'm not an expert of
> Expect, but I think the core of it are the 'expect' and 'send'
> commands.
Yep.
> The second can be done even without scripting support, and thus
> should not be a problem. The second is in fact an pattern matching
> event, which is already in the schedule. However, the expect
> command is kind of a special one-off version, which seems more
> handy in such a context.
I'd be fine with most any form of pattern matching and decision
making based on it. Something like "wait until the window is
quiscent for X time, and look for this pattern; if it exists do
thus" would be fine.
> However, there will be still some different with the original
> Expect. By default, you can not tell which application is
> currently active in screen. This means that there may be no
> process handling support built in.
I don't think I follow that.
> One will need to use the mechanism provided by the embedded
> scripting language (does LUA provide this functionality?) after
> spawning a new application in a new window. Also, I currently have
> no clear idea of how to support debugging. Can I assume it's less
> important?
I debug with "print". :)
-Robin