Subject: Re: Launching Prolog from Java (handling I/O)

From: Jan Wielemaker <[email-masked]>
Date: Fri, 17 Nov 2000 16:39:25 +0100

On Fri, 17 Nov 2000, Paul Singleton wrote:

>As co-guardian of JPL (with Fred Dushin its author), I'd like to be able to
>map SWI-Prolog streams into Java within JPL too, but I don't know how.
>Suggestions very welcome, especially if they only involve the published
>FLI (rather than delving into the sources).

I can only talk from the SWI-Prolog site.  Manipulation of I/O streams
in SWI-Prolog is not documented, but stable and rather simple. 
Basically you should start doing

#include <SWI-Stream.h>
#include <SWI-Prolog.h>

in this order: the presence of symbols from SWI-Stream.h makes
SWI-Prolog.h add some additional prototypes.  SWI-Prolog streams
are of type IOSTREAM (rather than FILE) and provide the same functions
as stdio, but with a capital S before them: Sfread, Sputc, etc., see the
prototypes for the full list.  The standard streams are available as
Sinput, Soutput and Serror

An IOSTREAM contains a pointer to a block with function pointers to do
the real work. To rebind a stream, replace this block.  The function
have the same functionality as the traditional POSIX read, write and
close functions.

Given a block of functions, you use Snew() to create a stream object,
which you can pass to Prolog-space using PL_open_stream().  There
are lots of examples in pl-stream.c for creating stream working on
files, resources, memory-buffers, etc.

Just rebinding Prolog standard input and output is defined in
pl-ntmain.c for redirecting it to the plwin.exe window: Write your
own read() and write() and replace the function pointers of Prolog.

>NB JPL starts SWI-Prolog "in-process", by dynamically linking the
libpl.dll >(or .so) shared library to the JVM, and provides a tight
coupling at the >Prolog "API" level (build terms, call non-determinate
goals, fetch bindings >etc.) rather than at the "teletype interface"
level. >
>This makes the JVM vulnerable to memory faults in Prolog or (more likely :-)
>in foreign libraries loaded by Prolog.
>
>With a suitable socket protocol, we could run Prolog in a separate process,
>yet support (effectively) the same tight coupling.

At a big performance price though.  Exactly for this reason we gave
up this idea in XPCE a long time ago.  In those days this boosted
transfer from about 75 to 3000 messages/second (today about 100000,
thanks to better design but mostly faster machines :-)

	Regards --- Jan