[slime-devel] Re: SLIME+Allegro on Windows
Bill Clementson
billclem at gmail.com
Sun Mar 5 22:33:46 UTC 2006
Hi Peter,
On 3/5/06, Peter Seibel <peter at gigamonkeys.com> wrote:
> Stephen Compall <s11 at member.fsf.org> writes:
>
> > On Sun, 2006-03-05 at 10:06 -0800, Peter Seibel wrote:
> >> a console app. But why the need to use inferior-lisp--SLIME
> >> communicates the port via a temp file, right. Is there some other
> >> communication that happens via the *inferior-lisp* channel?
> >
> > Yes -- SLIME uses the inferior-lisp pty to send a form containing
> > (load "path/to/swank-loader.lisp").
>
> So, don't most (all?) Lisp's have some way to accept the name of a
> file to load as a command line argument? I understand that in the
> early days it was good to just use the *inferior-lisp* machinary
> because it was there and, when SLIME was in early development, it gave
> you a way to talk to Lisp when all else failed. Maybe the time has
> come to break free of the *inferior-lisp* legacy? Assuming I figure
> out a clean way to have SLIME pass the file-to-load-on-startup info to
> the spawned Lisp, is there anything else that would be lost by
> abandoning *inferior-lisp*?
Others probably know a lot more than I do about this; however, I think
there were a number of different reasons for keeping the
*inferior-lisp* approach. I asked about this a while back and I think
these were the primary reasons I was given:
1. In the early days, it was convenient to have an alternative route
into Lisp when you were hacking "on slime" (as opposed to "with
slime"). In some situations today, this may still be convenient.
2. Although all 'normal' lisp output is redirected in slime, it used
to be the case that slime didn't trap anything in the lisp that
bypassed the streams layer (e.g. foreign code printing to file
descriptors) so that winds up in *inferior-lisp* as well.
> I ask because it would be nice for me, as maintainer of Lispbox, if
> SLIME worked the same on all the OS/implementation combos--at the
> moment, the Allegro on Windows has to be handled different. It's also
> a bit irksome that the Windows workarounds folks suggest require
> hard-wiring the port.
The alternatives that were suggested required using a .slime.lisp file
to fire off the necessary lisp commands to start swank and the example
file had (swank::create-swank-server 4005) with the port hard-coded.
An alternative would be to call "alisp -e" passing it forms to execute
(which could be programatically generated by elisp) with the requested
port since there aren't many forms that need to be in the .slime.lisp
file. Another alternative might be to temporarily store the port
number and retrieve it in the .slime.lisp code (avoiding the need to
hard-code it).
I've played around with setting up a number of different lisps with
slime on win32 in the past and I never found the acl setup to be that
difficult. It was much more difficult getting lispworks-personal
working with slime! However, I can sympathize with your desire to
maintain a common lispbox setup across multiple OS'es and CL
implementations.
Cheers,
Bill
More information about the slime-devel
mailing list