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

["John K. Peterson" <john@kolob.byu.edu>]

On Tue, 20 Feb 1996, 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.
>
> [...]
> 
> Matthias

I think a simple change to the way 'send data' works would provide the 
functionality that we (at least Hans and I) want.

When processing a 'send data' event, instead of replying immediately,
MacPerl would optionally wait to send the reply until it blocked for more
input.  This would facilitate processing some input and getting output in
the reply.  Perhaps an example would explain it better: 

Start a remote controlled script, for example:

while (<STDIN>) {
    print "$.: $_";
}

Then a send data with:

a line

as the direct object would return:

1: a line


In my processing my proposed 'send data' event, <STDIN> first returns 'a
line\n'.  The print statement puts '1: a line' in the output buffer.  When
<STDIN> is evaluated again at the top of the while loop, it blocks, since
there is no more input.  This then triggers the reply to the 'send 
data' event containing '1: a line'. 

A parameter passed to 'send data' could control whether it waited in this 
fashion or not.

Would that work?

John Peterson -- University Networking Services -- Brigham Young University
Internet: John_Peterson@byu.edu                       Phone: (801) 378-5007