Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!bionet!apple!brutus.cs.uiuc.edu!wuarchive!wugate!uunet!philmtl!philabs!linus!mbunix!bds
From: bds@mbunix.mitre.org (Barry D Smith)
Newsgroups: comp.lang.lisp
Subject: Re: Lucid to Oracle connection
Message-ID: <65580@linus.UUCP>
Date: 25 Aug 89 17:08:11 GMT
References: <64385@linus.UUCP> <1940@papaya.bbn.com>
Sender: news@linus.UUCP
Reply-To: bds@mbunix (Smith)
Organization: The MITRE Corporation, Bedford, Mass.
Lines: 39

In article <1940@papaya.bbn.com> barr@pineapple.bbn.com (Hunter Barr) writes:
>In article <64385@linus.UUCP> bds@mbunix (Smith) writes:
>>
>>If anyone has developed a Lucid to Oracle interface, I wonder if you
>>would be willing to share some of your discoveries with us.  We've
>>been working on this for a while now, and although we can make it
>>work, the solution is very kludgy.  Neither Lucid nor Oracle are much
>>help in this.
>
>... Lisp/C interfaces and Unix kludges, too painful to repeat...
>
>Have you tried the Symbolics co-processor in your Suns?  The Symbolics
>TCP/IP implementation is, of course, very straightforward to use from
>Lisp.  If you are tied to Lucid, well... you have my sympathy-- I
>support a Lucid implementation of my stuff too.
>                            ______
>                            HUNTER

I received a solution to our problem from John Cowan
(cowan@marob.masa.com).  He said the problem seemed like a typical
problem of making two unix programs talk to each other using pipes.
In order to make it happen, you have to force the system to send the
data in each direction.  This means using (force-output stream) at the
Lisp end and fflush(stream) at the C end.  The stream at the Lisp end
is the stream returned by run-program, while at the C end the stream
is standard output.  It works.

The use of a Symbolics board for this application is intriguing.
Oracle only supports interfaces to C, Fortran, and Pascal, and this
code must be run through a preprocessor.  The output is still C code,
though much larger and more complicated, so we could then use the
Symbolics C compiler to generate Lisp code which would run on the
Symbolics board.  However, the Symbolics board doesn't support color
right now (or at least didn't a month or so ago), and this system is
very color dependent.  When there is a cad buffer for the Symbolics
board, I think we will be very interested.  Until then, it's Lucid 3.0
for its color support, and SPE 1.1 for a development environment.

Barry Smith