Franz wants Peter Seibel's Lispbox to work with acl on Windows. The obstacle is that acl is not a console application on Windows, and doesn't provide a connection to standard input and standard output in the normal way. I've agreed to do a little legwork to find a way around this problem, and the first thing it occurred to me to do was to ask SLIME-devel what sort of connection support SLIME would need to connect to acl. Is it sufficient for the running acl to provide sockets, so that the lisp-side server can respond to the emacs-side SLIME protocol?
What issues am I not thinking of in my naive view of this problem?
When I used to work on Windows I always just launched ACL in a window and used slime-connect from emacs or xemacs. It's not as pretty as launching via M-x slime but I always work that way so I can restart emacs or my lisp separately (I have many long-running jobs). That's the quick & dirty answer to working on Windows.
Ian
mikel wrote:
Franz wants Peter Seibel's Lispbox to work with acl on Windows. The obstacle is that acl is not a console application on Windows, and doesn't provide a connection to standard input and standard output in the normal way. I've agreed to do a little legwork to find a way around this problem, and the first thing it occurred to me to do was to ask SLIME-devel what sort of connection support SLIME would need to connect to acl. Is it sufficient for the running acl to provide sockets, so that the lisp-side server can respond to the emacs-side SLIME protocol?
What issues am I not thinking of in my naive view of this problem?
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
On Thu, 23 Feb 2006 14:13:39 -0800, mikel mikel@evins.net wrote:
Franz wants Peter Seibel's Lispbox to work with acl on Windows. The obstacle is that acl is not a console application on Windows, and doesn't provide a connection to standard input and standard output in the normal way. I've agreed to do a little legwork to find a way around this problem, and the first thing it occurred to me to do was to ask SLIME-devel what sort of connection support SLIME would need to connect to acl. Is it sufficient for the running acl to provide sockets, so that the lisp-side server can respond to the emacs-side SLIME protocol?
What issues am I not thinking of in my naive view of this problem?
I have this in my ~/.emacs file (basically copying from and old suggestion by Luke Gorrie) and it seems to work fine:
(defun start-lisp-and-wait (command-string) (delete-other-windows) (shell-command command-string) (while (not (ignore-errors (slime-connect "localhost" 4005))) (sit-for 0.2)))
(defun alisp () (interactive) (start-lisp-and-wait "c:/PROGRA~1/acl80/alisp.exe +B +cm -L ~/.slime.lisp&"))
HTH, Edi.
Edi Weitz edi@agharta.de writes:
I have this in my ~/.emacs file (basically copying from and old suggestion by Luke Gorrie) and it seems to work fine:
These are some refinements I was using with Allegro CL 7 and XEmacs on Cygwin, but note that the allegro-ansi.exe program is not present in the Trial Edition. The function slime-connect signals a file-error, but there were other errors that were not to be ignored in such a loop.
(defun start-allegro () (interactive) (shell-command "/mnt/c/Program\ Files/Allegro\ Common\ Lisp\ 7/allegro-ansi.exe +B +cm -L "U:/start-slime.lisp" &" nil) (delete-other-windows) (loop repeat 5 do (condition-case c (progn (slime-connect "localhost" 4005) (return t)) (file-error (sit-for 0.2))) finally (message "Unable to connect to SLIME server.")))
The referenced file start-slime.lisp contained the following:
,----[ start-slime.lisp ] | (load "C:/Program Files/cygwin/usr/local/lib/common-lisp/slime-cvs/swank-loader.lisp") | ;(asdf:operate 'asdf:load-op :swank) | (swank:create-server :dont-close t) `----
Note that I had given up trying to get ASDF to work with Allegro, probably for lack of symlink support.
mikel mikel@evins.net writes:
Franz wants Peter Seibel's Lispbox to work with acl on Windows. The obstacle is that acl is not a console application on Windows, and doesn't provide a connection to standard input and standard output in the normal way. I've agreed to do a little legwork to find a way around this problem, and the first thing it occurred to me to do was to ask SLIME-devel what sort of connection support SLIME would need to connect to acl. Is it sufficient for the running acl to provide sockets, so that the lisp-side server can respond to the emacs-side SLIME protocol?
What issues am I not thinking of in my naive view of this problem?
I was talking to Kevin Layer at Franz about this same issue and I was trying to explain why it is that SLIME needs the Lisp to be runnable as a console app in order for M-x slime to work and discovered that I couldn't. My understanding, such as it is, is that it's because SLIME uses the old inferior-lisp mechanism to launch Lisp and that requires 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?
-Peter
I am by no means a slime, emacs or windows expert - but I have been looking at slime.el a bit lately. I'm guessing that slime-start-swank-server may be the reason. It calls comint-send-string, which I think is an Emacs function to send something to stdout? Anyhoo, code is (comint-send-string process (format "(swank:start-server %S :external-format %s)\n" file encoding)))) That is my suspicion.
Cheers Brad
On 3/5/06, Peter Seibel peter@gigamonkeys.com wrote:
mikel mikel@evins.net writes:
Franz wants Peter Seibel's Lispbox to work with acl on Windows. The obstacle is that acl is not a console application on Windows, and doesn't provide a connection to standard input and standard output in the normal way. I've agreed to do a little legwork to find a way around this problem, and the first thing it occurred to me to do was to ask SLIME-devel what sort of connection support SLIME would need to connect to acl. Is it sufficient for the running acl to provide sockets, so that the lisp-side server can respond to the emacs-side SLIME protocol?
What issues am I not thinking of in my naive view of this problem?
I was talking to Kevin Layer at Franz about this same issue and I was trying to explain why it is that SLIME needs the Lisp to be runnable as a console app in order for M-x slime to work and discovered that I couldn't. My understanding, such as it is, is that it's because SLIME uses the old inferior-lisp mechanism to launch Lisp and that requires 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?
-Peter
-- Peter Seibel * peter@gigamonkeys.com Gigamonkeys Consulting * http://www.gigamonkeys.com/ Practical Common Lisp * http://www.gigamonkeys.com/book/
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
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").
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*?
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.
-Peter
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
On Sun, Mar 05, 2006 at 01:58:15PM -0800, Peter Seibel wrote:
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*?
At least on Lispworks here, lots of threads' *standard-output* seem to go to the tty where Lisp was started, which means I see a lot of logging and tracing output there. It'd suck if that were going to go to the bit bucket instead.
Also, it's nice for when the Swank interface goes pear-shaped to have a backup way to interact with the underlying Lisp.
-bcd
* Peter Seibel [2006-03-05 22:58+0100] writes:
So, don't most (all?) Lisp's have some way to accept the name of a file to load as a command line argument?
Yes, but the details vary a lot. Also some people use shell scripts instead of the actual Lisp executable which complicates the issue.
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*?
It shouldn't be hard to offer both options to load and start swank: the traditional way which sends "(load swank)" to the inferior listener and a way to load swank via command line args.
Abandoning the *inferior-lisp* buffer is a somewhat different question and doesn't dependent very much on how we load swank. We could probably redirect the output that is currently sent to the *inferior-lisp* buffer to the *slime-repl* buffer. Redirecting input would be more difficult. It's a bigger step than changing the way how swank is started.
Helmut.
Helmut Eller heller@common-lisp.net writes:
- Peter Seibel [2006-03-05 22:58+0100] writes:
So, don't most (all?) Lisp's have some way to accept the name of a file to load as a command line argument?
Yes, but the details vary a lot. Also some people use shell scripts instead of the actual Lisp executable which complicates the issue.
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*?
It shouldn't be hard to offer both options to load and start swank: the traditional way which sends "(load swank)" to the inferior listener and a way to load swank via command line args.
Abandoning the *inferior-lisp* buffer is a somewhat different question and doesn't dependent very much on how we load swank. We could probably redirect the output that is currently sent to the *inferior-lisp* buffer to the *slime-repl* buffer. Redirecting input would be more difficult. It's a bigger step than changing the way how swank is started.
Yup. I was just wondering--if there were any uses of *inferior-lisp* that I was unaware of. Sounds like no. Which doesn't mean it's a good idea to get rid of it--just that it's not any worse than I already knew. Thanks. Just ruminating at this point anyway.
-Peter
-
bdowning＠lavos.net -
Bill Clementson -
Brad Beveridge -
Edi Weitz -
Helmut Eller -
Ian Eslick -
mikel -
Peter Seibel -
Stephen Compall -
Steven E. Harris