landman%hanami@Sun.COM (Howard A. Landman) (04/27/88)
One of the most severe problems with the Mac is that every program assumes it is interacting with a human being. It is virtually impossible to get two programs to communicate or cooperate in a significant way, an ability that every UNIX-hacker takes for granted. There is no facility in Mac-land that has anything like the power and notational convenience of a pipe, or the flexibility of shell programming. A concrete example: I play the game of Go. I have several Mac programs which play Go. I have a database of game records in ASCII format. Both of the following are desirable, and neither is possible without extremely convoluted (probably assembly language) hacking: 1. Have two programs play each other. 2. Have a program take a list of files of incomplete games, one at a time, read a file in, play both sides to completion, save the result in another file, and then process the next incomplete game, until all games are done. The basic problem is the use of the mouse as the primary input device, as opposed to a keyboard. This makes "shell scripts" unnatural. I can do the above things AS LONG AS I AM SITTING THERE DOING THE CLICKING, but there is no way to have them happen automatically. HOWEVER, I think there is a way out of this problem, one which would add immense power and flexibility to the Mac, and could be neatly grafted onto HyperCard. It is simply this: under MultiFinder (or perhaps AUX, have a way for HyperCard to launch one or more applications and KEEP RUNNING, CONTROLLING THE MOUSE AND OTHER INPUT DEVICES VIA HYPERTALK. Thus it would be easy to write a script that launched Dragon 2.10 (a Go program), told it to play Black, launched the Infinity Go program, told it to play White, and then looped communicating moves from one program to the other. HyperCard could then become to the Mac what shells are to UNIX: a convenient (if slightly slow) way to build useful functions from programs that already exist, and to mimic the effects of human input. (The UNIX "yes" program gives strong evidence that this is worthwhile.) CAVEAT: I don't have MultiFinder. For all I know, HyperCard might already work this way under it. But somehow I doubt it. If you think about this for 30 seconds or so, I think you'll begin to get as excited about it as I did when it first came to me. ANY MASTER PROGRAM WHICH INTENDS TO CONTROL MAC APPLICATIONS MUST BE ABLE TO MIMIC ALL FORMS OF INPUT. HyperCard already does this - the commands just need to be made to work on sublaunched programs. In other words, the syntax and semantics of HyperTalk need change only slightly, and in a logical way. It would probably be best to maintain the present behavior for existing scripts. I propose the new keyword "slave" be used to distinguish the new kind of open, as in: open slave "MacWrite" In the absence of MultiFinder and AUX, this command fails. If either is running, then MacWrite is opened and HyperCard continues to run, but BEHIND MacWrite, so that HyperTalk Commands are executed only when MacWrite is idle (otherwise the script might outrun the program). If the script says "click at theLoc", then MacWrite, not HyperCard, receives and interprets the simulated mouse click. Handling of tools (say, in MacPaint) could probably not be made as transparent and convenient as it is in HyperCard, because HyperCard would have to understand all the applications's tools. In other words, the "choose" command becomes useless in this context. But tools could be selected with "click" or "drag", if you knew where they were. Any comments (besides "Why didn't *I* think of that?")? Howard A. Landman landman@hanami.sun.com UUCP: sun!hanami!landman
jellinghaus-robert@CS.YALE.EDU (Rob Jellinghaus) (04/27/88)
You're way behind Apple. What you're describing is called IPC (for
Inter-Process Communication), and Apple has been working on it for a
while now. Apple is currently involved in a complete rewrite of their
System, and when it's done it should be a sight. I only hope they do
it RIGHT this time...
Rob Jellinghaus | "If I had a heart attack RIGHT NOW, I couldn't
jellinghaus-robert@CS.Yale.EDU | be a more FORTUNATE MAN! I would like to
ROBERTJ@{yalecs,yalevm}.BITNET | DARE a heart attack to happen RIGHT NOW! I
{y'all}!ihnp4!hsi!yale!robertj | COULDN'T be MORE FORTUNATE!" -- Zippy on Icejwhitnel@csi.UUCP (Jerry Whitnell) (04/28/88)
In article <50949@sun.uucp> landman@sun.UUCP (Howard A. Landman) writes: >One of the most severe problems with the Mac is that every program >assumes it is interacting with a human being. [...] > >A concrete example: I play the game of Go. I have several Mac programs >which play Go. I have a database of game records in ASCII format. Both >of the following are desirable, and neither is possible without extremely >convoluted (probably assembly language) hacking: > >1. Have two programs play each other. >2. Have a program take a list of files of incomplete games, one at a time, > read a file in, play both sides to completion, save the result in another > file, and then process the next incomplete game, until all games are done. > >The basic problem is the use of the mouse as the primary input device, >as opposed to a keyboard. This makes "shell scripts" unnatural. >I can do the above things AS LONG AS I AM SITTING THERE DOING THE >CLICKING, but there is no way to have them happen automatically. Actually, the input side is not that difficult. One could write extensions to hyperard that would drive the input side of another program by feeding events to it. There are a few problems involved like finding the partition holding the program and getting the events in the queue, but nothing a good hacker couldn't figure out. QuickKeys is a very good example of what you want from the input side, in that it modifies the event queue to expand the macro and so provides automatic control of a program. The real problem is the output side of the program. The reason pipes work so well in UNIX is that all output from a program is a stream of bytes, usually text, that can be passed around at will. However the output of a Mac program is much more complicated and includes not only text but also graphics of all sorts. In your example of Go programs, Dragon doesn't keep a text list of its moves, it only draws them on the board using (I assume) FillOval. For a Hypercard script to drive two programs playing each other, it would have to recognize the FillOval command, detirmine from the rectangle and color which side moved and where the move was and then generate the equivalent muse movements to pass the move to the other program. (BTW, try to get two UNIX go programs to play each other. Not as easy as one might hope for :-). This "shell" can take over all these calls and pass the information to the Hypercard application, but then you'd have to reverse engineer each program to see how it generated each of its displays, so that your program can read it and respond in the appropiate fashion. Hypercard applications can be written to support this, however. This would be more difficult to implement that it needs to be because Hypercard doesn't support IPC (Inter- Process Communication), so you'd have to hack your own together. There are some existing tools that may make this easier. Both QuickKeys from CE Software and Tempo II from ? provide input macro capability. I've heard that Tempo II also has a programming interface that could be used for this purpose. > ... >Any comments (besides "Why didn't *I* think of that?")? The general idea has existed for awhile (Andy Hertzfeld wanted to put something like it in Servent, but I think Servant is dead), but your the first to suggest using HyperCard as the driver. > > Howard A. Landman Jerry Whitnell Been through Hell? Communication Solutions, Inc. What did you bring back for me? - A. Brilliant
landman%hanami@Sun.COM (Howard A. Landman) (04/28/88)
In article <27980@yale-celray.yale.UUCP> jellinghaus-robert@yale.UUCP writes: >You're way behind Apple. What you're describing is called IPC (for >Inter-Process Communication), and Apple has been working on it for a >while now. Unless Apple uses IPC to mean something completely different from what it means in the UNIX world, it is only slightly related to what I proposed. IPC is a useful *underlying* capability which is normally accessed through system calls in compiled programs. I'm proposing an *overlying* (i.e., directly visible to every user) capability that would be accessed through HyperTalk. The closest equivalent to the problem that I've seen in the non-graphics UNIX world is that some programs check to see whether their input is really a terminal. Such programs may refuse to run if their input is redirected from a file or pipe. This once made it extremely painful to do things like write an automatic rogue-playing program. When pseudo-ttys and rsh became available, the problem vanished, because you could run your program under an rsh and pipe into that. Will Apple's IPC allow you (for example) to control a program that throws up a modal dialog? If not, it isn't powerful enough to replace what I proposed. Will it require the user to make system calls? If so, it's too low-level for most people. Howard A. Landman landman@hanami.sun.com UUCP: sun!hanami!landman
landman%hanami@Sun.COM (Howard A. Landman) (05/03/88)
In article <1488@csib.csi.UUCP> jwhitnel@csib.UUCP (Jerry Whitnell) writes: >Actually, the input side is not that difficult. One could write extensions >to hyperard that would drive the input side of another program by feeding >events to it. There are a few problems involved like finding the partition >holding the program and getting the events in the queue, but nothing a >good hacker couldn't figure out. I'm proposing a more limited ability in a sense. All I desire is that HyperCard be able to communicate with a program that has been opened *under* HyperCard, so finding it is not a problem (for the user). >The real problem is the output side of the program. The reason pipes >work so well in UNIX is that all output from a program is a stream of >bytes, usually text, that can be passed around at will. However the >output of a Mac program is much more complicated and includes not >only text but also graphics of all sorts. Actually this isn't entirely true - consider a UNIX program that has a full-screen interface. In theory, any program could interpret the bytestream, but that essentially means writing a complete terminal emulation package inside your program. You'd really prefer to be able to query certain screen locations; sort of "curses" in reverse. The Mac's graphics capability does make things more complicated than that, but even just being able to query pixel values would provide some help. Even better would be routines that could be given a font, style, and screen location, and return the text there (I know this is harder, but I don't think it's impossible). >In your example of Go programs, Dragon doesn't keep a text list of its >moves, it only draws them on the board using (I assume) FillOval. Actually it also prints the move in alphabetic ("Korschelt") notation, but for programs in general you can't count on that. >For a Hypercard script to drive two programs >playing each other, it would have to recognize the FillOval command, detirmine >from the rectangle and color which side moved and where the move was and then >generate the equivalent muse movements to pass the move to the other program. Well, not necessarily recognize FillOval, although having some way to trap certain calls by the slave program would certainly be useful to the serious programmer. It would be possible to figure out what had happened from examining screen (or window) pixels. While this would be somewhat slow, in my case it would be adequate since the programs themselves are rather slow (couple of minutes per move). >(BTW, try to get two UNIX go programs to play each other. Not as easy as >one might hope for :-). Too true. It would be nice if everyone conformed to some kind of standard protocol (like the USENIX protocol, but with more features) which allowed Go programs to be piped together. >the Hypercard application, but then you'd have to reverse engineer each >program to see how it generated each of its displays, so that your program >can read it and respond in the appropiate fashion. Hypercard applications >can be written to support this, however. Exactly. I'm willing to do the reverse engineering work, because it's much less than the manual work of running the programs by hand; but right now, I don't have the choice, >I've heard that Tempo II also has a programming interface that could >be used for this purpose. I'll be checking into Tempo II for the "playing out partial games" driver. I'll report back when I know whether it can handle that. The tricky part will probably be recognizing that the game has ended. >The general idea has existed for awhile (Andy Hertzfeld wanted to put >something like it in Servent, but I think Servant is dead), but your >the first to suggest using HyperCard as the driver. This is a natural suggestion because HyperTalk already has syntax for many of the things you want to do. It's also very widely understood and used. Howard A. Landman landman@hanami.sun.com UUCP: sun!hanami!landman
PEPKE%FSU.MFENET@NMFECC.ARPA (05/04/88)
> One of the most severe problems with the Mac is that every program > assumes it is interacting with a human being. It is virtually > impossible to get two programs to communicate or cooperate in a > significant way, an ability that every UNIX-hacker takes for granted. > There is no facility in Mac-land that has anything like the power and > notational convenience of a pipe, or the flexibility of shell > programming. Paul Haeberli of Silicon Graphics did some work in this area. He put out a paper called "A Data Flow Manager for Interactive Somethingorother" or something like that. What he basically had was a way of linking windows on the screen of an IRIS workstation to each other, where the linking had a visual paradigm that looked like diagrams and menus laid over the windows on the desktop. The example application was fairly simple: a program that displayed a picture from a geometry file. Into this one package he linked a color editor, a transformation control panel, and a simple animation controller that could record a series of transformations and play them back into the window. He also had a renderer which would take the geometry from one window and a pattern from another and do the rendering. The approach he used involved having the processes communicate with each other through a mutually agreed upon protocol. This is obviously the hard part: to design the protocol to be complete enough that it does everything that needs doing. Eric Pepke pepke%fsu.mfenet@nmfecc.arpa Supercomputer Computations pepke%scri.hepnet@lbl-csa2.arpa Research Institute pepke%fsu.bitnet@wiscvm.wisc.edu Florida State University "You're living in your own private Idaho Tallahassee, FL 32306-4052 On the ground like a wild potato." Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.
PEPKE%FSU.MFENET@NMFECC.ARPA (05/05/88)
The paper which I described is really called, "A Data-flow Manager for Interactive Graphics." It appeared in the Fall 1987 issue of IRIS Universe, an IRIS SIG magazine published by Silicon Graphics. One of the editors is Zsuzsanna Molnar. Her address, etc. are Zsuzsanna Molnar Silicon Graphics Inc. 2011 Stierlin Road Mountain View, CA 94043 (415) 962-3320 zsuzsa@sgi.com.arpa Eric Pepke pepke%fsu.mfenet@nmfecc.arpa Supercomputer Computations pepke%scri.hepnet@lbl-csa2.arpa Research Institute pepke%fsu.bitnet@wiscvm.wisc.edu Florida State University "You're living in your own private Idaho Tallahassee, FL 32306-4052 On the ground like a wild potato." Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.