Re: [MacPerl] availability of output in remote control mode

[schooley@ee.gatech.edu (David C. Schooley)]

At 9:24 AM 2/20/96, Matthias Ulrich Neeracher wrote:
>hmlehman@es.unizh.ch (Hans Martin Lehmann) writes:
>>>John_Peterson@byu.edu writes:
>>>>How does one become aware that output is available from a
>>>>remote-controlled MacPerl script.  Do you really just have to keep
>>>>polling?
>>>
>>>Yes, there currently is no mechanism to "push" data from Perl other than
>>>reading or the end of the script.
>
>>Well, I don't know whether this is feasible. What would really make my day
>>would be an option that allows me to send data directly to STDIN of a
>>running script and have the AppleScript component wait for an application
>>response with the data written to STDOUT from Perl. Vice versa Perl should
>>just wait till it receives a data event.
>>
>>What would I use it for?
>>
>>I have > 10 MB of data that I can only get at in chunks < 32k (blessed be
>>HyperCard's storage limits!). The data is linked to an index I need to
>>consult after every chunk. At the moment I use one Do Script event per 32k
>>chunk. With a Send Data event as described above I could avoid restarting
>>one and the same perl script each time I process a chunk (or gobbling up
>>processing power polling for the output).
>
>This is possible, if a little awkward, to acheive with the current mechanism,
>provided the calling application can receive, as well as send, Apple Events.
>The basic outline goes like this:
>

<Apple Event specifics deleted>

I implemented something similar to this when we worked out the new AE
support for Mac gnuplot. The goal was to be able to integrate an external
editor (Alpha) as the console.  The problem is similar to the MacPerl
problem in that data needed to be stuffed into stdin and retrieved from
stderr/stdin.  There are two approaches, depending on whether or not the
Thread Manager is present.  I am presenting these as ideas for MacPerl.

1) No Thread Manager. (Similar to Matthias' approach)
The handler for the "insert data into stdin" Apple event stuffs data into a
buffer and returns. The AE reply is empty.  The "core" code, i.e., gnuplot,
gets the data and does its thing. When finished, output is stored in a
buffer for later retrieval by another Apple event. When the client gets an
empty reply it immediately sends another event to retrieve the results of
the previous command. In the gnuplot case, the "retrieve data from last
command" event is the same as a command event but with an empty string.

2) Thread Manager.
This way is very slick and uses fewer AE's.  In this case, the AE handling
code and the "core" code run as separate threads. For gnuplot, the AE code
is part of the main thread and the gnuplot code is a secondary thread. When
an AE comes in with data for stdin, the handler stuffs the data into the
stdin buffer and then repeatedly yields to the gnuplot code until gnuplot
has something to report.  When gnuplot finishes, the results (stderr in
this case) get stuffed into the AE reply and the AE handler then returns.
This scheme cuts the number of AE's per transaction in half.  It should
also be possible to make the "core" code part of the main thread and then
handle the AE's in a secondary thread. This issue was addressed in
_Develop_ a while back, but I don't remember the details.


>BTW, the Mac::AppleEvents shared library for PowerPC compiled yesterday, so
>at least PowerPC users should be able to handle arbitrary AppleEvents around
>the end of this month.

This could be cool...

later,

---Dave---


========================================================================
David C. Schooley                         |
Ph.D. in progress                         |  "Be Sweet"
Georgia Tech Electric Power               |
email: schooley@ee.gatech.edu             |     --- Lewis Grizzard's mom
http://www.ee.gatech.edu/users/schooley/  |