A user of the OS X version of Lisp-in-a-Box sent me mail about a problem running Peter Seibel's CD database example: y-or-n-p has a little trouble in SLIME and OpenMCL (the effect is easy to see if you try using the CD example: SLIME seems to feed extra line-ends to OpenMCL).
The effect occurs with OpenMCL and SLIME, whether in Lisp-in-a-Box or in my regular Emacs installation, but not using the same SLIME and, say, CMUCL or SBCL.
Any suggestions where to look to track down the source of the problem?
mikel mikel@evins.net writes:
Any suggestions where to look to track down the source of the problem?
You can set swank:*log-events* to true to see what was written to the socket. The log output should appear in the *inferior-lisp* buffer. On the Emacs side you can see the log in the *slime-events* buffer. The relevant messages for this problem are :read-string and :emacs-return-string. Emacs sends something like
(:emacs-return-string 0 1 "y\n")
if you type "y RET". I think that correct.
y-or-n-p will eventually call stream-read-char in swank-gray.lisp and (funcall input-fn) in that sends a :read-string message to Emacs.
It's also possible that y-or-n-p in OpenMCL is implemented differently as in CMUCL, e.g. by reading character by character and not by reading a line in as in CMUCL. That could be a problem if OpenMCL stops reading after the 'y' and doesn't consume the newline.
I think there are also some "read-tests" in the test suite in slime.el. You can run the them with `M-x slime-run-tests'; not sure how useful that is for OpenMCL though.
Helmut.
-
Helmut Eller -
mikel