[Openmcl-devel] SLIME and ccl on win32

[Gary Byers]

The win32 port of CCL seems to be far enough along to run under SLIME.
(It's actually been able to run under SLIME for a week or so; quitting
reliably when running under SLIME is a relatively recent development ...)
Some notes:

- I've tried this with a relatively recent CVS SLIME (the version I've
been using announces itself as "SLIME 2008-10-10".)

- There are several different versions of [X]Emacs for Windows;they
may or may not differ in functionality (socket/subprocess support).
I was able to get things working with the official FSF binaries
from ftp.gnu.org (currently or very recently available as 
'emacs-22.2-bin-i386.zip'.  I have no idea why that Emacs wants
to make its initial window (er, 'frame') taller than my monitor.
It's probably quite a bit harder to get a Cygwin version of Emacs
or XEmacs to work; Cygwin programs tend to have different view
of the filesystem than that seen by native programs, and this can
cause confusion.

That particular Emacs considers the user's home directory to be
"c:/Documents and Settings/<user>/Application Data/" on XP and
"c:/Users/<usr>/AppData/Roaming/" on Vista.  (Don't look at 
me ...)  There doesn't seem to be a need to customize things
in your .emacs file beyond:

(add-to-list 'load-path "/path/to/slime/")  ; your SLIME directory
(setq inferior-lisp-program "/path/to/wx86cl.exe")
(require 'slime)
(slime-setup)

e.g., the minimum suggested by the SLIME documentation.

- When invoked via M-x slime, a lisp running under SLIME writes
a Secret Port Number to a file in /tmp.  (This is one case where
it's important that the lisp and Emacs agree on what #p"/tmp/"
means.)  Both Emacs and CCL will generally agree that this is
"c:/tmp"; I don't know if this directory exists out-of-the-box
on Windows or if any special permissions are required to create
or access it.

- That's about it; I don't use SLIME regurlarly and don't use much
of its functionality when I use it at all, but the basic stuff that
I tried seemed to work.

- There are new Windows (and everything else ...) binaries in svn;
among other bugfixes and changes, the lisp no longer checks for an
obscure CPU feature (the presence of "clflush" instructions)  that
it doesn't actually use.  (Someone reported that this feature is
reported as not being present under some version of Parallels.)