Re: Lightweight IPC for scripting

On 9/6/03 21:25, in article
[email protected], "Pascal J.Bourguignon"
<[email protected]> wrote:

> What  a  strange  idea,  given  emacs,  gimp,  autocad,  the  NeXTSTEP
> Distributed Objects (re-implemented in GNUstep), guile and a google of
> embedable  scripting languages  ranging from  Common-Lisp to  TCL thru
> Scheme, and not counting classical unix "applications" like that email
> programm I don't remember the name  right now, but also big CASE tools
> that  are actually a  group of  tools wholly  scriptable with  bash or
> whatever is your prefered scripting language...

And these mishmash and often toy-language scripting systems offer neither
uniformity or the ability to script multiple programs from one script. Check
out what AppleScript / AppleEvents can do on MacOS for an example of this.

> Pure X  applications may make heavy use  of the X way  to identify the
> windows  and  their  widgets, but  I  would  bet  that in  most  other
> toolkits,  there is  only one  X window  and every  button,  field and
> subview inside it is entirely drawn and managed by the toolkit. Have a
> look at GNUstep for example.  You won't go far trying to find a button
> with X  primitive in a  GNUstep application running  in a X  window (a
> GNUstep application could run also with different non-X backends).

I didn't see anything about "button" in his post. Care to explain where you
started to connect this to the presentation (view) layer instead of the
model layer?

If this statement made no sense to you then you are probably unqualified to
comment on anything related to GUI programming.

> 
> So  to be  general, it  would be  better to  develo an  AI  that would
> analyse the screen bitmap,  recognize the buttons, and other controls,
> the data fields,  OCR and "see" them (hopefully we  can get 100% here,
> since there's  not much noise,  only some anti-aliasing...),  and then
> you could try to drive the mouse and click and drag around.

I think I can phrase a bit more specifically what you're asking for, given
that I've worked for a little while in this weird "AI" field. Let's assume
that the user of the application uses some decision procedure to interact
with the program, and that this decision procedure is given inputs, called
"goals", and uses some existing data, called "knowledge", to figure out how
to translate these inputs into actions. Now further suppose that programs
are designed to facilitate this translation procedure by presenting
information in a way that coherently adds "knowledge" which is designed to
be processed by this procedure. Thus we only need to discern the operation
of this function as it is implemented by humans, and we can generally
perform such translation from the presentation of knowledge to the effects,
and work in the reverse direction.

Congratulations! That's brilliant! I'll let you know then when I can perform
reliable, correct goal->action translation, and then you can modify it to
perform knowledge->effect inference.

On second thought, let's not.

> Perhaps ambitious, but one can drean!

I'm sorry, but my simply AI program written in Lisp (which I used just
because of Norvig's book) has no knowledge of what "drean" means. Perhaps I
should start using Python like he is now, and then it will be able to learn
these words.
-- 
Brian Mastenbrook
[email protected]
http://www.cs.indiana.edu/~bmastenb/
Can destructuring-bind my brain and pick out all the interesting stuff?