[comp.lang.lisp] Is LISPcraft mistaken?

krowney@MATH.UCLA.EDU (02/03/88)

	I am having problems with the inter-process communication facilities 
running on Franz Lisp. I am running on a Vax under UNIX, and the following is
a script session:

1) lisp
Franz Lisp, Opus 38.92
-> ;Fire up and get ports to a "wc" process.
(setq ports (*process 'wc t t))
(%from-process %to-process 6550)

-> ;Feed the running "wc" some input
(mapc '(lambda (x) (print x (cadr ports))) '(a b c d))
(a b c d)

-> ;Read any results that might have come back
(read (car ports))
			.
			.
			.
			.
		<NO  RESPONSE>

On pages 265-266 of LISPcraft Wilensky claims the read command will return the
first column of wc's output; however the above read yields nothing and requires
a ^C to get the prompt back.  Does anyone know what is going awry here?
Before you respond please note that I don't care about the "exece" family
of commands in that I am not interested in running simple shell commands, but
rather I would like lisp to talk with a running C process and vice versa.
Also note that I have tried doing a (patom (ascii 4) (cadr ports)) [that is
tossing a ^D to the process in order to tell it the input is done] with the 
same results.  If you have any code to manage interprocess communication between
Franz and C ,all help would be greatly appreciated.

			Thanks

ags@j.cc.purdue.edu (Dave Seaman) (02/05/88)

In article <11022@shemp.UCLA.EDU> krowney@MATH.UCLA.EDU (Kevin Rowney) writes:
 [describing apparent problem with interprocess communication in Franz]

>1) lisp
>Franz Lisp, Opus 38.92
>-> ;Fire up and get ports to a "wc" process.
>(setq ports (*process 'wc t t))
>(%from-process %to-process 6550)

>-> ;Feed the running "wc" some input
>(mapc '(lambda (x) (print x (cadr ports))) '(a b c d))
>(a b c d)

So far, everything is correct.

>-> ;Read any results that might have come back
>(read (car ports))

This got no response because wc was still waiting for more input or for
an indication that the end of the standard input has been reached.
Therefore you need to

-> (close (cadr ports)) 

before attempting to read.  Note that this is special to ``wc''.  Not all
processes insist on reading all of their input before producing any
output.

>Also note that I have tried doing a (patom (ascii 4) (cadr ports)) [that is
>tossing a ^D to the process in order to tell it the input is done] with the 
>same results.  

Since the input to wc is not a terminal device, wc sees the ^D as an
ordinary ASCII character and obediently counts it.  You need to close the
pipe to indicate end of input.
-- 
Dave Seaman	  					
ags@j.cc.purdue.edu

jeff@aiva.ed.ac.uk (Jeff Dalton) (02/07/88)

In article <11022@shemp.UCLA.EDU> krowney@MATH.UCLA.EDU (Kevin Rowney) writes:
] 
] 	I am having problems with the inter-process communication facilities 
] running on Franz Lisp.

] -> ;Fire up and get ports to a "wc" process.
] (setq ports (*process 'wc t t))
] (%from-process %to-process 6550)
] 
] -> ;Feed the running "wc" some input
] (mapc '(lambda (x) (print x (cadr ports))) '(a b c d))
] (a b c d)
] 
] -> ;Read any results that might have come back
] (read (car ports))
] <NO  RESPONSE>

Perhaps for some reason this worked for Wilensky, but it doesn't for
me, and I can see why not.  Suppose you type 'wc' to a shell and then
type 'abcd' to it.  What is the response?  When I do it, there isn't
one.  Type a newline.  Still no response.  Finally type an end of
file.  Only then does wc produce any output.

So, trying the same thing (modulo the eof effect) in Lisp:

     Franz Lisp, Opus 38.91
     [Loading .lisprc]
     -> (setq ports (*process 'wc t t))
     (%from-process %to-process 1091)
     -> (print 'abc (cadr ports))
     nil
     -> (close (cadr ports)) ;really end input.
     t
     -> (read (car ports))
     0
     -> (read (car ports))
     1
     -> (read (car ports))
     3
     -> (close (car ports))
     t
     -> (wait)
     (1091 . 0)
     ->

WC therefore turns out to be a losing example.  Try something
interactive (like another Lisp), and the results will be more
interesting.  (Don't forget to send newlines with terpri.)

Jeff Dalton,                      JANET: J.Dalton@uk.ac.ed             
AI Applications Institute,        ARPA:  J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University.             UUCP:  ...!ukc!ed.ac.uk!J.Dalton