[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: clisp with ilisp



[Forwarded from David Gadbois <gadbois@mcc.com>.]

    Date: Thu, 24 Feb 1994 05:29-0600
    From: Joachim Schrod <schrod@iti.informatik.th-darmstadt.de>

    Using CLISP via ILISP, that's a sad story. What's known here, on this
    mailing list:

	David Gadbois <gadbois@cs.utexas.edu> reported on 13 Jan 94 that
	he has an ``ILISP interface (mostly working)''. We haven't heard
	about that work later on this mailing list. (No pun intended,
	it's just five weeks ago. I assume he has real work, too.)
    
Right, I have been caught up in the real world.  I did send my "mostly
working" mod to the ILISP mailing list (if there is demand I will resend
it to clisp-list) in the hopes that someone would take it the last yard.

	Already at 12 Mar 93, Matthias Lindner
	<matthias@intellektik.informatik.th-darmstadt.de> reported a
	problem that I've got, too: ``I get an interactive clisp-buffer,
	but mode reamins :load forever.'' I mentioned at 19 Jan 1994
	that changing process-connection-type to t (in lisp-mod.el) has
	repaired it for me (at least for small examples, didn't try
	large ones due to the missing adaption of the rest), but for
	Steve Carney <carney@cern.enet.dec.com> this did not work [22
	Feb 94].

    Anybody with more information?

The problem is that SYS:READ-FORM decides whether or not to print a
prompt based on whether there is input available.  ILISP, during its
initialization phase, slings a bunch of forms down the pipe before
checking for output.  If things are timed wrong, clisp will not print a
prompt after evaluating the first of these, and so ILISP will hang
forever waiting for the prompt to be printed.  My workaround was to dike
out the test for input in SYS:READ-FORM.  Better still would be to add a
-ilisp or some such command line flag to clisp to control this behavior
and other things (like turning off GNU readline.)

--David Gadbois