Hi Peter,
On 3/5/06, Peter Seibel peter@gigamonkeys.com wrote:
Stephen Compall s11@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