[slime-devel] Re: [Ilisp-devel] SLIME
Nicolas Neuss <Nicolas.Neuss@iwr.uni-heidelberg.de> writes:
I would have preferred the option of LEP being supported by the free Lisp implementations (CMUCL, SBCL, CLISP, GCL).
David Lichteblau is working on this for SBCL. He shares code with SLIME, since Dan is factoring all the SBCL-deep-magic code into the SB-INTROSPECT library that we both use.
His LEP-for-SBCL is at http://www.lichteblau.com/src.html
Is LEP too complicated or otherwise bad, so that SLIME became necessary?
Absolutely not.
Interesting, I wasn't aware that there was any sharing going on between the SLIME and ELI-SBCL efforts. Since you are obviously talking to each other and aware of what the other is doing, how do you see the two efforts evolving? Do you think they will continue to be two separate efforts? If so, what segment of the SBCL developer community do you feel would gravitate towards SLIME as opposed to ELI-SBCL and why? In other words, why would an SBCL developer prefer SLIME over ELI-SBCL (or vice versa)? Cheers, Bill __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
Bill Clementson <bill_clementson@yahoo.com> writes:
Interesting, I wasn't aware that there was any sharing going on between the SLIME and ELI-SBCL efforts.
That's all Dan's doing with SB-INTROSPECT. I think he's got it exactly right - the best way for us to all share code is for the Lisp implementations to make supported interfaces for the functionality that we need (e.g. finding definitions). We should be able to do good sharing with ILISP this way too. The main barrier for you guys, as I understand it, is that you're more sympathetic to people who don't want to use the very latest of everything, and won't have e.g. an SBCL with SB-INTROSPECT. Ultimately though we should be able to share all the hairy-scary non-portable code this way. Dan and Christophe from SBCL are leading the charge admirably. We SLIME'ers haven't really engaged other implementors, but do hope to work with the good folks doing CMUCL, OpenMCL, LispWorks, and any other Lisps we end up supporting.
Since you are obviously talking to each other and aware of what the other is doing, how do you see the two efforts evolving?
I for one am not big on planning the future, I've always found it harmful in hobby-hacking. I think we'll all follow our noses, try to write good code, and see where we end up. As our common ancestor puts it: Don't think; hack. (*) But at the very least we'll ask David to help us avoid fudging up our multithreading support. Cheers, Luke (*) This probably explains why loading inf-lisp hijacks all my lisp-mode key bindings, instead of being nice and using a minor-mode.
--- Luke Gorrie <luke@bluetail.com> wrote:
(*) This probably explains why loading inf-lisp hijacks all my lisp-mode key bindings, instead of being nice and using a minor-mode.
I found this comment curious as I thought that you used only a TCP socket to communicate between emacs and cl. I had a look at the source and you do require inferior lisp mode (ILM) and comint mode. What is the rationale for using both inferior lisp mode and a TCP socket? Is your intention to entirely replace ILM with socket communication or will you continue to use ILM for some things and sockets for others? -- Bill Clementson __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
Bill Clementson <bill_clementson@yahoo.com> writes:
I found this comment curious as I thought that you used only a TCP socket to communicate between emacs and cl. I had a look at the source and you do require inferior lisp mode (ILM) and comint mode. What is the rationale for using both inferior lisp mode and a TCP socket? Is your intention to entirely replace ILM with socket communication or will you continue to use ILM for some things and sockets for others?
"Require" may be a bit of a strong word: it is possible to run SLIME with only the TCP connection (e.g. to a lisp on another machine) but you need to (swank:create-swank-server) on the CL by hand before running slime-connect. That said, yes, if you run the default M-x slime it does use inferior-lisp to start up a lisp implementation. I think the plan is to make inferior-lisp largely unnecessary, but in the meantime for purposes of hacking slime itself it's damned handy to have an alternate route into Lisp when things get wedged. (There's also the problem that although we can redirect all 'normal' lisp output, we don't currently trap anything in the lisp that bypasses the streams layer (e.g. foreign code printing to file descriptors) so that winds up in *inferior-lisp* as well. I'm sure we can solve this some other way, but thus far we haven't) -dan -- http://web.metacircles.com/support - SBCL custom development and support
--- Daniel Barlow <dan@telent.net> wrote:
Bill Clementson <bill_clementson@yahoo.com> writes:
I found this comment curious as I thought that you used only a TCP socket to communicate between emacs and cl. I had a look at the source and you do require inferior lisp mode (ILM) and comint mode. What is the rationale for using both inferior lisp mode and a TCP socket? Is your intention to entirely replace ILM with socket communication or will you continue to use ILM for some things and sockets for others?
"Require" may be a bit of a strong word: it is possible to run SLIME with only the TCP connection (e.g. to a lisp on another machine) but you need to (swank:create-swank-server) on the CL by hand before running slime-connect.
That said, yes, if you run the default M-x slime it does use inferior-lisp to start up a lisp implementation. I think the plan is to make inferior-lisp largely unnecessary, but in the meantime for purposes of hacking slime itself it's damned handy to have an alternate route into Lisp when things get wedged.
(There's also the problem that although we can redirect all 'normal' lisp output, we don't currently trap anything in the lisp that bypasses the streams layer (e.g. foreign code printing to file descriptors) so that winds up in *inferior-lisp* as well. I'm sure we can solve this some other way, but thus far we haven't)
Thanks for the clarification. Incidentally, what was the rationale for using inferior lisp mode instead of ilisp to "boot-strap" development? ILISP has some of the same "negatives" as ILM (since both were built on comint mode) however it has a lot more functionality than ILM. It seems like (at least to me) it would have made more sense creating SLIME extensions on top of ILISP rather than ILM since there is so much more functionality in ILISP than there is in ILM. Even if the eventual goal is to replace all the functionality that is provided by ILM/ILISP, ILISP would provide more "short-term" benefits for the SLIME CL developer than ILM would. - Bill __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
Bill Clementson <bill_clementson@yahoo.com> writes:
Thanks for the clarification. Incidentally, what was the rationale for using inferior lisp mode instead of ilisp to "boot-strap" development? ILISP has some of the same "negatives" as ILM (since both were built on comint mode) however it has a lot more functionality than ILM. It seems like (at least to me) it would have made more sense creating SLIME extensions on top of ILISP rather than ILM since there is so much more functionality in ILISP than there is in ILM. Even if the eventual goal is to replace all the functionality that is provided by ILM/ILISP, ILISP would provide more "short-term" benefits for the SLIME CL developer than ILM would.
I think the reason is that Eric Marsden, the author of SLIME's initial version (at that time called SLIM) uses inf-lisp and not ILISP. I don't know what Luke used before SLIME, but I too used inf-lisp. SLIME is now good enough for developing SLIME and at this stage it simpler to add any missing functionality to SLIME itself than to make it work with ILISP. The advantage of inf-lisp over ILISP is that inf-lisp is simpler and more robust. Since we use inf-lisp primarily as fallback when everything else fails, inf-lisp seems to be preferable. Helmut.
--- Helmut Eller <e9626484@stud3.tuwien.ac.at> wrote:
Bill Clementson <bill_clementson@yahoo.com> writes:
Thanks for the clarification. Incidentally, what was the rationale for using inferior lisp mode instead of ilisp to "boot-strap" development? [snip] I think the reason is that Eric Marsden, the author of SLIME's initial version (at that time called SLIM) uses inf-lisp and not ILISP. I don't know what Luke used before SLIME, but I too used inf-lisp.
SLIME is now good enough for developing SLIME and at this stage it simpler to add any missing functionality to SLIME itself than to make it work with ILISP. The advantage of inf-lisp over ILISP is that inf-lisp is simpler and more robust. Since we use inf-lisp primarily as fallback when everything else fails, inf-lisp seems to be preferable.
Fair enough. But, could you elaborate on where you feel inf-lisp is more robust than ILISP? I know that there were a lot of quality issues a while ago; however, I believe that most of those have been addressed in the last couple of releases. I would have thought that ILISP today would be no less robust than inf-lisp. - Bill __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
Bill Clementson <bill_clementson@yahoo.com> writes:
Fair enough. But, could you elaborate on where you feel inf-lisp is more robust than ILISP? I know that there were a lot of quality issues a while ago; however, I believe that most of those have been addressed in the last couple of releases. I would have thought that ILISP today would be no less robust than inf-lisp.
I haven't used ILISP for some time and things may have changed in the meantime, but I think ILISP needs a way to detect the prompt of the Lisp to work properly. I think ILISP hangs or breaks if the prompt regexp is not set correctly. AFAIK inf-lisp also uses a such a regexp, but doesn't break if the regexp is wrong. So in this sense inf-lisp is more robust. Helmut.
Helmut Eller <e9626484@stud3.tuwien.ac.at> writes:
I haven't used ILISP for some time and things may have changed in the meantime, but I think ILISP needs a way to detect the prompt of the Lisp to work properly. I think ILISP hangs or breaks if the prompt regexp is not set correctly. AFAIK inf-lisp also uses a such a regexp, but doesn't break if the regexp is wrong. So in this sense inf-lisp is more robust.
FWIW, I always used ILISP before, and this was the big problem for me. It seemed very common when Lisp was asynchronously printing messages, then it would get wedged when e.g. trying to fetch an arglist. Sometimes combinations of C-g and `M-x repair-ilisp' would unwedge it, but other times I'd need to restart Lisp. Also, I really wished that printed output from Lisp would be inserted before the prompt. That may even fix the problem above by keeping the prompt in the right place. Cheers, Luke
Bill Clementson <bill_clementson@yahoo.com> writes:
Even if the eventual goal is to replace all the functionality that is provided by ILM/ILISP, ILISP would provide more "short-term" benefits for the SLIME CL developer than ILM would.
That would have been one way, but we went the clean-room approach. We only use ILM to start Lisp and compile our server, and *inferior-lisp* as a debugging fallback. We've covered all the major features now, although there's plenty of hacking left to do to get all the details right and support everyone's favourite add-ons. Starting from scratch means more work/fun, but it also gives us a fresh codebase. To an outsider, some of the code in ILISP is slightly terrifying :-), as in any program with such a long history. We also wanted to do most things differently and to have an environment more like the elisp one, so it would only give us a head-start in the short-term. ELI really doesn't appeal to my hackstincts. From the web I can't even tell who wrote it, and most questions on groups.google.com seem to go without definitive answers. I downloaded my copy from Neil van Dyke's website, which says "Please do not pester Franz to support this packaging, lest they regret GPL'ing." It looks like Franz did the least necessary to be allowed to link with Emacs under the GPL, and would be unlikely to let a dozen random hackers into their CVS tree :-) so that is a potential dead-end. So I think our approach is pretty reasonable. We'll see how it goes. I'm even hoping we can tempt some of you fine hackers to have a play around on the dark side ;-) And of course my views do not necessarily reflect those of the other SLIME hackers, but I hope this answers this thread's main question. Note however that this is almost entirely after-the-fact rationalization. Really, it was just too addictive to stop. ;-) Cheers, Luke
participants (4)
-
Bill Clementson -
Daniel Barlow -
Helmut Eller -
Luke Gorrie