Return-Path: <@glinda.oz.cs.cmu.edu:stark%saturn@sdsu.edu>
Received: from glinda.oz.cs.cmu.edu by A.GP.CS.CMU.EDU id aa00705;
          28 May 92 21:40:52 EDT
Received: from sdsu.edu by GLINDA.OZ.CS.CMU.EDU id aa15539;
          28 May 92 21:40:24 EDT
Received: from saturn.sdsu.edu by sdsu.edu; id AA02165
	sendmail 5.64/SDSU-GW-1.11 via SMTP
	Thu, 28 May 92 18:15:23 -0700 for mkant@glinda.oz.cs.cmu.edu
Received: by saturn.SDSU.EDU (4.1/SDSU-CLIENT)
	id AA23544 for delivery to mkant@glinda.oz.cs.cmu.edu; Thu, 28 May 92 18:15:22 PDT
Date: Thu, 28 May 92 18:15:22 PDT
From: "Brian D. Stark" <stark%saturn@sdsu.edu>
Message-Id: <9205290115.AA23544@saturn.SDSU.EDU>
To: mkant@GLINDA.OZ.CS.CMU.EDU
Subject: read me first

The mail messages you are recieving from contain all the responses
that I recieved, they are ordered by the date I recieved them. 
I also have the solution we ended up using, it was written by
Vince Baker, a fellow graduate student.  I left all the messages
intact as I recieved them, this may be somewhat confusing at first,
but I didn't want to leave any relevent information out and whats
relevent to me may not be to you and visa versa.

In case anyone is interested, RSHELL mentioned in our solution, is
the robotic environment my system is communicating with.

Hope this helps you all out,

brian

Return-Path: <@glinda.oz.cs.cmu.edu:stark%saturn@sdsu.edu>
Received: from glinda.oz.cs.cmu.edu by A.GP.CS.CMU.EDU id ad00543;
          28 May 92 21:17:20 EDT
Received: from sdsu.edu by GLINDA.OZ.CS.CMU.EDU id aa15533;
          28 May 92 21:17:04 EDT
Received: from saturn.sdsu.edu by sdsu.edu; id AA02188
	sendmail 5.64/SDSU-GW-1.11 via SMTP
	Thu, 28 May 92 18:16:56 -0700 for mkant@glinda.oz.cs.cmu.edu
Received: by saturn.SDSU.EDU (4.1/SDSU-CLIENT)
	id AA23561 for delivery to mkant@glinda.oz.cs.cmu.edu; Thu, 28 May 92 18:16:55 PDT
Date: Thu, 28 May 92 18:16:55 PDT
From: "Brian D. Stark" <stark%saturn@sdsu.edu>
Message-Id: <9205290116.AA23561@saturn.SDSU.EDU>
To: mkant@GLINDA.OZ.CS.CMU.EDU
Subject: May 26

From arul@hercules Tue May 26 10:25:44 1992
Received: from hercules.SDSU.EDU by saturn.SDSU.EDU (4.1/SDSU-CLIENT)
	id AA25927 for delivery to stark; Tue, 26 May 92 10:25:43 PDT
Received: by hercules.SDSU.EDU (4.1/SDSU-CLIENT)
	id AA04787 for delivery to stark@saturn; Tue, 26 May 92 10:25:42 PDT
Date: Tue, 26 May 92 10:25:42 PDT
From: arul@hercules (Arul Ananthanarayanan)
Message-Id: <9205261725.AA04787@hercules.SDSU.EDU>
To: stark@saturn
Subject: sock
Status: R

>From owens@cs.uchicago.edu Tue May 19 10:43:21 1992
Received: from tartarus.uchicago.edu by saturn.SDSU.EDU (4.1/SDSU-CLIENT)
	id AA25010 for delivery to stark; Tue, 19 May 92 10:43:20 PDT
From: owens@cs.uchicago.edu
Return-Path: <owens@cs.uchicago.edu>
Received:  by tartarus.uchicago.edu (4.1/UofC4.2x)
	id AA02381; Tue, 19 May 92 12:43:18 CDT
Date: Tue, 19 May 92 12:43:18 CDT
Message-Id: <9205191743.AA02381@tartarus.uchicago.edu>
To: stark@saturn.sdsu.edu
Subject: Re: LISP i/o with unix sockets
Newsgroups: comp.lang.lisp
References: <1992May19.014326.3605@newshub.sdsu.edu>
Status: R


Here's what we did here.  It doesn't squarely address your problem,
but it may be vaguely informative.

The robot connects to the rest of the world via a wireless rs232 link
to the SIO port on the back of a SparcStation that is on the net.

We wrote a short daemon program that runs on the Sparcstation and
listens for connect requests on a socket.  When one is received, it
establishes two-way communication between the requestor and the robot.

That way, any machine on the network can be running a planner, or
perceptual routines, or whatever, and can talk to the robot simply by
opening a TCP stream to the aforementioned socket on the Sparcstation.
We've got it set up so that only one process can talk to the robot at
a time -- subsequent connect requests are automagically  queued until
the current requestor hangs up.

I'll send you the C code if you would find it useful.

But I think your question is:  "How do you open a stream to a TCP
socket from within KCL and hold it open?"

I don't use KCL.  Can you call arbitrary C code from within KCL?  If
so, can you call the  C code that returns a global (LISP) variable
containing the socket stream object and then do subsequent (LISP) I/O
to that stream?







>From bouma@cs.purdue.edu Tue May 19 11:52:05 1992
Received: from arthur.cs.purdue.edu by saturn.SDSU.EDU (4.1/SDSU-CLIENT)
	id AA26016 for delivery to stark; Tue, 19 May 92 11:52:03 PDT
Received: from melange.cs.purdue.edu by arthur.cs.purdue.edu (5.65c/PURDUE_CS-1.2)
	id <AA08032@arthur.cs.purdue.edu>; Tue, 19 May 1992 13:52:01 -0500
Received: from localhost by melange.cs.purdue.edu (5.65c/PURDUE_CS-1.2)
	id <AA02389@melange.cs.purdue.edu>; Tue, 19 May 1992 13:52:00 -0500
Message-Id: <199205191852.AA02389@melange.cs.purdue.edu>
To: stark@saturn.sdsu.edu
Subject: Re: LISP i/o with unix sockets
Newsgroups: comp.lang.lisp
In-Reply-To: <1992May19.014326.3605@newshub.sdsu.edu>
Organization: Department of Computer Science, Purdue University
Date: Tue, 19 May 92 13:52:00 EST
From: bouma@cs.purdue.edu
Status: R

I routinely do such things in Lucid, but it should be possible in KCL.
KCL has a foreign function interface.  You write C code that opens a
socket and returns the descriptor.  The problem is you need some internal
function to turn any descriptor into a stream.  There must be one, but it
may not be documented.  Perhaps you could ask one of the KCL authors or
the net to find it out.  Alternatively if you are willing to give up one
of the stdio streams you can dup2 the open socket descriptor over it and
use the stream already attatched to it as your communication channel.


>From @advanced-robotics-research-centre.salford.ac.uk,@subnode.arrc.salf.ac.uk:rsa@advanced-robotics-research-centre.salford.ac.uk Wed May 20 07:29:02 1992
Received: from sun2.nsfnet-relay.ac.uk by saturn.SDSU.EDU (4.1/SDSU-CLIENT)
	id AA04403 for delivery to stark; Wed, 20 May 92 07:28:57 PDT
Via: advanced-robotics-research-centre.salford.ac.uk;
     Wed, 20 May 1992 15:28:30 +0100
From: Ruth Aylett <rsa@advanced-robotics-research-centre.salford.ac.uk>
Via: subnode.arrc.salf.ac.uk (sparc4); Wed, 20 May 92 15:28:48 BST
Date: Wed, 20 May 92 15:28:47 BST
Message-Id: <6504.9205201428@subnode.arrc.salf.ac.uk>
To: stark@saturn.sdsu.edu
Subject: Re: LISP i/o with unix sockets
Newsgroups: comp.lang.lisp
In-Reply-To: <1992May19.014326.3605@newshub.sdsu.edu>
Organization: Advanced Robotics Research Centre, Salford, UK.
Cc: 
Status: R

In article <1992May19.014326.3605@newshub.sdsu.edu> you write:
>I am currently developing a planning system that I wish to communicate
>with a remote system using a series of commands that make up the
>plan.
>

I am doing exactally the same thing as you (talking to a Puma 570) only
unfortunately my planner is in Prolog. But I don't understand why you
have to close the socket and reopen (my system administrator says this
isn't a good idea under Unix anyway as sockets may persist a while
before vanishing.)

As I understand the process:
	1. You open one end as a server (the planner in my case). Unless
	you fork, you will hang on the underlying 'accept' command until
	your client connects. (You fork if you have multiple clients.)

	2. Your client connects - it needs to know the hostname and port
	number to do this.

Now the connection is in being, you can read and write whenever you want
from either end.

True, if the program at either end terminates the conection will
terminate: but your planner carries on running from command to command
and so does the program at the other end, so this shouldn't be a
problem.

In my case, using a system called Poplog, which includes Prolog, Pop11
and Lisp within it, I can externally load the C routines which open
server or client sockets and carry out read or write operations:
presumably you do the same in AKCL, which should be easier since it is
C-based as I understand.

Apologies if this is all wide of the mark and I have misunderstood what
you are doing. Probably someone will have a fit if I send you our C
socket code, but if knowing what is in it would be at all helpful let me
know. I'd also be interested if others respond to hear what they say.

-- 
___________________________________________________________________
Ruth Aylett                     Advanced Robotics Research Centre
R.Aylett@arrc.salf.ac.uk        University Rd, Salford, M5 4PP, UK
rsa@arrc.uucp                   Tel: (44)-61-745-7384
___________________________________________________________________

>From karl@labyrinth.com Wed May 20 10:48:18 1992
Received: from csn.org by saturn.SDSU.EDU (4.1/SDSU-CLIENT)
	id AA05788 for delivery to stark; Wed, 20 May 92 10:48:16 PDT
Received: by csn.org with UUCP id AA10734
  (5.65c/IDA-1.4.4 for stark@saturn.sdsu.edu); Wed, 20 May 1992 11:48:13 -0600
Received: from localhost by amaze.labyrinth.com with SMTP id AA02572
  (5.65c/IDA-1.4.4 for <stark@saturn.sdsu.edu>); Wed, 20 May 1992 11:42:23 -0600
Message-Id: <199205201742.AA02572@amaze.labyrinth.com>
To: stark@saturn.sdsu.edu (Brian D. Stark)
Subject: Re: LISP i/o with unix sockets
Reply-To: Karl.Sierka@Labyrinth.COM
Mailer: [Power User's Mail Tool (MH 6.7)]
In-Reply-To: stark@saturn.sdsu.edu's message of 19 May 92 01:43:26 GMT
Date: Wed, 20 May 92 11:42:23 -0600
From: karl.sierka@labyrinth.com
Status: R


   "Brian" == Brian D. Stark stark@saturn.sdsu.edu (Brian D. Stark) writes:
Brian> Originator: stark@saturn.sdsu.edu
Brian> Nntp-Posting-Host: saturn

Brian> I am currently developing a planning system that I wish to communicate
Brian> with a remote system using a series of commands that make up the
Brian> plan.  My Planner is run using Austin Kyote Common Lisp and runs
Brian> in the interpreter (not compiled).

Brian> The method that my associates and I have proposed involves
Brian> the use of unix sockets,  currently it appears as if I will have
Brian> to establish a connection for every command I send to the remote 
Brian> system, for example if I wish the send a command that tells 
Brian> a robot to grasp a cube I will have to establish the socket,
Brian> send the string representation of the command, accept the result
Brian> of the command, and close the socket.  While this may seem to be 
Brian> inefficient for every primitive (10 times for one move of a cube),
Brian> it still beats the old way.  The reason I can't simply establish
Brian> the socket once, is that it appears as if a process must be attached
Brian> to the socket at all times, otherwise the connection is dropped.
Brian> Since I have not found a way to establish a stream directly from
Brian> LISP to the socket, I am forced to use the SYSTEM command to call
Brian> a C function whenever communication between the two systems is
Brian> needed.  So I am essentially creating a short lived process every
Brian> time I communicate.  The most intuitive solution would be to 
Brian> establish a stream between LISP and the socket, but I haven't found
Brian> an obvious way of achieving this.  Please respond via email, if the
Brian> interest and/or response is great enough I will post results.

Brian> Thanks,

Brian> Brian D. Stark

Brian> email: stark@saturn.sdsu.edu
Brian> Voice: (619)296-5229
Brian> address:
Brian> 		5822 Lauretta St.
Brian> 		San Diego, CA 92110

	Grab the CLX code from export.lcs.mit.edu, and check out the
    socket.c, and sockcl files to see how they do the socket connection to
    the X windows server. You may be able to lift it right out and use it!

	Let me know if you found it workable.

Karl F. Sierka					L a b y r i n t h
=====================================================================
Senior Software Consultant			Computer Services
Karl.Sierka@Labyrinth.COM		 	   PO Box 4626
(303)441-8288					Boulder, CO 80306


From arul@hercules Tue May 26 10:28:01 1992
Received: from hercules.SDSU.EDU by saturn.SDSU.EDU (4.1/SDSU-CLIENT)
	id AA26008 for delivery to stark; Tue, 26 May 92 10:27:58 PDT
Received: by hercules.SDSU.EDU (4.1/SDSU-CLIENT)
	id AA04815 for delivery to stark@saturn; Tue, 26 May 92 10:27:57 PDT
Date: Tue, 26 May 92 10:27:57 PDT
From: arul@hercules (Arul Ananthanarayanan)
Message-Id: <9205261727.AA04815@hercules.SDSU.EDU>
To: stark@saturn
Subject: sock.src
Status: R

>From andreasg@sigi.cs.colorado.edu Tue May 19 09:55:32 1992
Received: from sigi.cs.colorado.edu by saturn.SDSU.EDU (4.1/SDSU-CLIENT)
	id AA24664 for delivery to stark; Tue, 19 May 92 09:55:29 PDT
Received: by sigi.cs.colorado.edu id AA11776
  (5.65c/IDA-1.4.4 for stark@saturn.sdsu.edu); Tue, 19 May 1992 10:55:26 -0600
Date: Tue, 19 May 1992 10:55:26 -0600
From: Andreas Girgensohn <andreasg@sigi.cs.colorado.edu>
Message-Id: <199205191655.AA11776@sigi.cs.colorado.edu>
To: stark@saturn.sdsu.edu
Subject: Re: LISP i/o with unix sockets
Newsgroups: comp.lang.lisp
In-Reply-To: <1992May19.014326.3605@newshub.sdsu.edu>
Organization: University of Colorado, Boulder, Department of Computer Science
Cc: andreasg@cs.colorado.edu
Status: R

I don't know how to make AKCL work with sockets but I can give you some hints.
I don't remember the details of KCL too well any more since it has been five
years since I last worked with it.  First, you can include C code in your Lisp
files by using the Clines macro.  If I remember correctly, the interface
between Lisp and C is fairly restricted so that it might not be easy or
possible at all to use sockets through that interface.  The second alternative
is to write C functions that look like the C functions the Lisp compiler would
produce.  These functions can be called from a Lisp program just like other
Lisp functions.  I append an example that I wrote in 1988 in order to use UNIX
termcap functions from KCL.  I don't think that I'll be able to answer any
questions since I don't remember any details.  The internal representation of
KCL (and AKCL) might have changed in the meantime so that it might not work
any more.  You might have to look at the output of the Lisp compiler in order
to determine changes (I think that there is an option for compile-file so that
it produces a C file and stops).

Good luck,

  Andreas Girgensohn

-------------------------------------------------------------------------------
>From scotth@sigi.cs.colorado.edu Wed May 20 14:00:06 1992
Received: from sigi.cs.colorado.edu by saturn.SDSU.EDU (4.1/SDSU-CLIENT)
	id AA07633 for delivery to stark; Wed, 20 May 92 14:00:05 PDT
Received: by sigi.cs.colorado.edu id AA05841
  (5.65c/IDA-1.4.4 for stark@saturn.sdsu.edu); Wed, 20 May 1992 15:00:02 -0600
Date: Wed, 20 May 1992 15:00:02 -0600
From: Scott Henninger <scotth@sigi.cs.colorado.edu>
Message-Id: <199205202100.AA05841@sigi.cs.colorado.edu>
To: stark@saturn.sdsu.edu
Subject: LISP i/o with unix sockets
Status: R


|   I am currently developing a planning system that I wish to communicate
|   with a remote system using a series of commands that make up the
|   plan.  My Planner is run using Austin Kyote Common Lisp and runs
|   in the interpreter (not compiled).
|
|   The method that my associates and I have proposed involves
|   the use of unix sockets,  currently it appears as if I will have
|   to establish a connection for every command I send to the remote 
|   system, for example if I wish the send a command that tells 
|   a robot to grasp a cube I will have to establish the socket,
|   send the string representation of the command, accept the result
|   of the command, and close the socket.  While this may seem to be 
|   inefficient for every primitive (10 times for one move of a cube),
|   it still beats the old way.  The reason I can't simply establish
|   the socket once, is that it appears as if a process must be attached
|   to the socket at all times, otherwise the connection is dropped.
|   Since I have not found a way to establish a stream directly from
|   LISP to the socket, I am forced to use the SYSTEM command to call
|   a C function whenever communication between the two systems is
|   needed.  So I am essentially creating a short lived process every
|   time I communicate.  The most intuitive solution would be to 
|   establish a stream between LISP and the socket, but I haven't found
|   an obvious way of achieving this.  Please respond via email, if the
|   interest and/or response is great enough I will post results.

I recently did just what you seem to be talking about.  The below code
is some test functions that I whipped up to make sure things were
working right.  On the unix side, this works with socket streams quite
nicely.  Note that I leave the Unix port open (essentially blocking on
listen) until I send it a 'q command.  If you need to look at how I set
things up on the unix side, I can send you some C code.

;; executes a list of commands.  Note that the stream is opened once
;;   and closed implicitly by with-open-stream
;; sigi is the name of the unix host
(defun test-comm (port commands)
  (with-open-stream (stream (tcp:open-tcp-stream 'sigi port nil))
    (let ((input-line nil))
      (dolist (cmd commands)
        (print cmd stream)
        (send stream :force-output)
        (when (equal 'r (first cmd))
          (setq input-line nil)
	  ;; assume input comes in pairs or 'q
 	  (do ((pos (read stream) (read stream)))
	      ((equal pos 'q))
            (setq input-line (push (list pos (read stream)) input-line )))
	  (dolist (line (reverse input-line))
            (format t "~S~%" line)))))))

;; opens port 2010
(defun test-remote ()
  (test-comm 2010 `((i 4) (m (1 0 1.0) (2 0 2.0))
			   (m (0 1 1.0)
			   (2 1 3.0)
			   (3 1 1.0)
			   (0 2 2.0))))
  (test-comm 2010 '((r 0.0 1 1 2)
	         (q))))


   Scott Henninger
   University of Colorado
   Dept. of Computer Science
   Campus Box 430
   Boulder, CO 80309-0430
   scotth@cs.colorado.edu
   fax #: (303) 492-2844


Return-Path: <@glinda.oz.cs.cmu.edu:stark%saturn@sdsu.edu>
Received: from glinda.oz.cs.cmu.edu by A.GP.CS.CMU.EDU id ac00543;
          28 May 92 21:17:18 EDT
Received: from sdsu.edu by GLINDA.OZ.CS.CMU.EDU id aa15531;
          28 May 92 21:16:38 EDT
Received: from saturn.sdsu.edu by sdsu.edu; id AA02184
	sendmail 5.64/SDSU-GW-1.11 via SMTP
	Thu, 28 May 92 18:16:30 -0700 for mkant@glinda.oz.cs.cmu.edu
Received: by saturn.SDSU.EDU (4.1/SDSU-CLIENT)
	id AA23557 for delivery to mkant@glinda.oz.cs.cmu.edu; Thu, 28 May 92 18:16:29 PDT
Date: Thu, 28 May 92 18:16:29 PDT
From: "Brian D. Stark" <stark%saturn@sdsu.edu>
Message-Id: <9205290116.AA23557@saturn.SDSU.EDU>
To: mkant@GLINDA.OZ.CS.CMU.EDU
Subject: May 25

From huub@cwi.nl Mon May 25 02:50:13 1992
Received: from charon.cwi.nl by saturn.SDSU.EDU (4.1/SDSU-CLIENT)
	id AA18763 for delivery to stark; Mon, 25 May 92 02:50:04 PDT
Received: from madelief.cwi.nl by charon.cwi.nl with SMTP
	id AA12053 (5.65b/2.10/CWI-Amsterdam); Mon, 25 May 1992 11:49:34 +0200
Received: by madelief.cwi.nl with SMTP; Mon, 25 May 1992 09:49:32 GMT
Message-Id: <9205250949.AA03115@madelief.cwi.nl>
To: stark@saturn.sdsu.edu
Subject: LISP i/o with unix sockets - comp.lang.lisp #4093
Date: Mon, 25 May 1992 11:49:30 +0200
From: Huub Bakker <huub@cwi.nl>
Status: R


|> Since I have not found a way to establish a stream directly from
|> LISP to the socket, I am forced to use the SYSTEM command to call
|> a C function whenever communication between the two systems is
|> needed.  So I am essentially creating a short lived process every
|> time I communicate.  The most intuitive solution would be to 
|> establish a stream between LISP and the socket, but I haven't found
|> an obvious way of achieving this.

I'm doing the same thing using LeLisp. In LeLisp it is possible to link ".o"
files (C object files) with the LeLisp interpreter. This object files contain
functionality to establish socket connections etc. With the LeLisp function
'defextern' it is possible to connect a C-function from the object file with a
LeLisp function. Both dynamic and static linking of object files is supported
by LeLisp. It works fine!

Greetings, Huub.

CWI, P.O. Box 4079 			Huub Bakker (huub@cwi.nl)
1009 AB Amsterdam
The Netherlands			   
Tel. 31 20 5924080

Return-Path: <@glinda.oz.cs.cmu.edu:stark%saturn@sdsu.edu>
Received: from glinda.oz.cs.cmu.edu by A.GP.CS.CMU.EDU id aa00543;
          28 May 92 21:17:14 EDT
Received: from sdsu.edu by GLINDA.OZ.CS.CMU.EDU id aa15529;
          28 May 92 21:16:32 EDT
Received: from saturn.sdsu.edu by sdsu.edu; id AA02179
	sendmail 5.64/SDSU-GW-1.11 via SMTP
	Thu, 28 May 92 18:16:13 -0700 for mkant@glinda.oz.cs.cmu.edu
Received: by saturn.SDSU.EDU (4.1/SDSU-CLIENT)
	id AA23553 for delivery to mkant@glinda.oz.cs.cmu.edu; Thu, 28 May 92 18:16:12 PDT
Date: Thu, 28 May 92 18:16:12 PDT
From: "Brian D. Stark" <stark%saturn@sdsu.edu>
Message-Id: <9205290116.AA23553@saturn.SDSU.EDU>
To: mkant@GLINDA.OZ.CS.CMU.EDU
Subject: May 24

From carroll@cs.uiuc.edu Sun May 24 12:42:14 1992
Received: from a.cs.uiuc.edu by saturn.SDSU.EDU (4.1/SDSU-CLIENT)
	id AA16090 for delivery to stark; Sun, 24 May 92 12:42:12 PDT
Received: from dogwood.cs.uiuc.edu by a.cs.uiuc.edu with SMTP id AA09390
  (5.64+/IDA-1.3.4 for stark@saturn.sdsu.edu); Sun, 24 May 92 14:42:08 -0500
Message-Id: <9205241942.AA09390@a.cs.uiuc.edu>
Received: by dogwood.cs.uiuc.edu with SMTP
	(5.64+/15.6) id AA00439; Sun, 24 May 92 14:44:48 -0500
To: stark@saturn.sdsu.edu (Brian D. Stark)
Subject: Re: LISP i/o with unix sockets
Date: Sun, 24 May 92 14:44:47 EDT
From: carroll@cs.uiuc.edu
Status: R

Run the lisp from the C program, instead of the other way around. The
C program establishes the socket connection, twiddles stdin / stdout,
and then forks or execs the lisp process. We used this technique for a
while with KCL before we switched to Allegro. Unfortunately, you lose
contact with the Lisp process from the terminal, but you can't have
everything.

I built this code as part of the ConversationBuilder project, which
uses a central Lisp process to communicate via a multi-casting message
passing socket server to other client programs, if you're interested
in something of that nature.

-- 
Alan M. Carroll          "Weren't there yams involved, too?" - J. Ockerbloom
Epoch Development Team   
Urbana Il.               "I hate shopping with the reality-impaired" - Susan



