November 2003 - slime-devel - mailman3.common-lisp.net

[slime-devel] SLIME on a local socket
by Daniel Barlow 06 Dec '03

06 Dec '03

Hacked up this afternoon, not quite ready for commital but would appreciate feedback: slime on a local (a.k.a unix domain) socket using half of the attachtty/detachtty utility as a socket shim. Why? Two reasons: (1) access control can be done by setting appropriate filesystem permissions on the directory containing the socket (or in Linux but not portably, on the socket itself) - so, a safe way to run slime on shared hosts that doesn't involve cooking up an authentication protocol (2) attachtty can connect across a network using ssh, so you can control a remote lisp this way as well. How to use it: Server-site, create-swank-server has a new keyword argument :af, which defaults to :inet, and can also be :local * (swank:create-inet-server "/home/dan/.swank/socket" :af :local) Client-side, slime-connect is renamed to slime-connect/inet, and there's a new function (slime-connect/local pathname) M-x slime-connect /home/dan/.swank/socket RET or from another machine M-x slime-connect me@lisp.example.com:/home/dan/.swank/socket RET Opinions? You can get attachtty as part of detachtty, in Debian, FreeBSD ports, or from http://www.cliki.net/detachtty -dan -- http://web.metacircles.com/ - Open Source software development and support

8 14

Re: [slime-devel] Daily ChangeLog diff
by Sean O'Rourke 01 Dec '03

01 Dec '03

Sean O'Rourke <sorourke(a)cs.ucsd.edu> writes: > Luke Gorrie <lgorrie(a)common-lisp.net> writes: >> + (slime-autodoc-mode): New command. > > I think we're losing here by rolling our own instead of using eldoc. > For example, today I noticed that slime-autodoc continues to echo > during an isearch; eldoc has been made to avoid doing this. Sorry, slip-of-the-finger plus Gnus' send-without-confirm behavior led me to send the incomplete message above. To continue... In slime-autodoc's favor, it _is_ much simpler, particularly when you consider having to use an advice to take advantage of eldoc in pre-21.3 Emacs. But I suspect that there will be other cases of unforseen gotchas and minor behavioral differences in the future, and can't help but think that maintaining a parallel implementation of eldoc is more trouble than necessary. /s

3 4

[slime-devel] Re: [Ilisp-devel] SLIME
by Bill Clementson 01 Dec '03

01 Dec '03

> Nicolas Neuss <Nicolas.Neuss(a)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/

4 9

Re: [slime-devel] SLIME and Lispworks?
by Helmut Eller 01 Dec '03

01 Dec '03

Alain.Picard(a)memetrics.com writes: > Eerily enough, this is one of the first bugs I ever > fixed in ILISP as well. I must be the only person using > logical pathnames... :-) Fixed in CVS. Thanks! Are you a pathname expert? Is it better to use translate-logical-pathname or truename? Helmut.

3 3

Re: [slime-devel] Re: [Ilisp-devel] SLIME
by Bill Clementson 30 Nov '03

30 Nov '03

>> 3. Flesh out SLIME with the functionality that is available today in ILISP >> and ELI. This is the "clean slate" option. It would allow for a new Emacs >> CL mode to be developed utilizing the best ideas from ILISP & ELI. It also >> requires the greatest amount of effort. >s/effort/fun/ :-) Yes, that's a valid reason. However, if I do a wc of the elisp files in the different packages, I get the following results (lines/words/chars): SLIME: 4345/14463/161611 ILISP: 15466/63798/565273 ELI: 19801/77244/743786 According to these figures, you've still got a lot of fun ahead of you to get feature parity with ILISP/ELI :-) >This is firmly the path we've taken, except that we're primarily >stealing ideas from Emacs Lisp's development environment. And some of the stuff that I've seen come out of SLIME looks pretty neat. So far, I've only been able to drool over screen shots as I primarily use MS Windows. >> 4. Integrate SLIME and ILISP. This would add multiprocessing support to >> ILISP and would allow SLIME to take advantage of the rich functionality >> already built into ILISP. >As Dan mentioned, we don't do any multiprocessing yet, though we hope >our infrastructure will permit it with minimal rewriting. >If you guys are interested in using TCP for your connection, the >socket code is pretty easy. I don't think merging with SLIME would be >a practical way to do it though. I'm not advocating adding TCP socket code to ILISP or merging ILISP and SLIME. I just consider that another option. As I said, it could be a "win-win option" but it might also be a "Frankenstein". Since ILISP was built on top of comint mode, it would probably be too much effort to retrofit socket communication support as an alternative. In any case, good luck with SLIME. I look forward to seeing what further developments you make in improving Emacs<->CL development environments. Cheers, Bill __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

3 4

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 30 Nov '03

30 Nov '03

Index: slime/ChangeLog diff -u slime/ChangeLog:1.120 slime/ChangeLog:1.123 --- slime/ChangeLog:1.120 Fri Nov 28 18:29:02 2003 +++ slime/ChangeLog Sat Nov 29 18:31:43 2003 @@ -1,3 +1,50 @@ +2003-11-29 Daniel Barlow <dan(a)telent.net> + + * swank-sbcl.lisp (source-location-for-emacs): + sb-debug::print-description-to-string takes only two args, not + three. Now 'v' command works in sldb :-) + + * slime.el (slime-idle-state): added :debug as a valid transition + + * swank.lisp (slime-debugger-function): New. Returns a function + suitable for use as the value of *DEBUGGER-HOOK* to install the + SLIME debugger globally. Must be run from the *slime-repl* buffer + or somewhere else that the slime streams are visible so that it + can capture them. e.g. for Araneida: + PKG> (setf araneida:*restart-on-handler-errors* + (swank:slime-debugger-fucntion)) + +2003-11-29 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * slime.el: Some tweaking to the REPL. slime-repl-input-end-mark + is now always left inserting and slime-mark-input-end + "deactivates" the end mark by moving it to the beginning of the + buffer. + (slime-goto-source-location): Next try for more uniform + source-locations. A source-location is now a structure with a + "buffer-designator" and "position-designator". The buffer-designator + open the file or buffer and the position-designator moves point to the + right position. + (slime-autodoc-mode): New command. + (slime-find-fdefinitions): Experimental support for generic functions + with methods. + (slime-show-xrefs, slime-insert-xrefs, slime-goto-xref): Rewritten to + work with more general source locations. + + * swank.lisp: Structure definitions for source-locations. + (alistify, location-position<, group-xrefs): Utilities for xref + support. + + * swank-cmucl.lisp (code-location-source-location): Renamed from + safe-source-location-for-emacs. + (code-location-from-source-location): Renamed from + source-location-for-emacs. + (find-fdefinitions, function-source-locations): New functions. + (safe-definition-finding): New macro. + + * swank-lispworks.lisp: Xref support. + (make-dspec-location): Updated for the new source-location format. + 2003-11-29 Luke Gorrie <luke(a)bluetail.com> * slime.el (complete-symbol, arglist): Updated test cases for new @@ -113,7 +160,7 @@ 2003-11-25 Daniel Barlow <dan(a)telent.net> - * swank-sbcl.lisp: delete big chunk of leftover commented-out + * swank-sbcl.lisp: delete big chunk of leftover commented-out code * slime.el: arglist command to use slime-read-symbol-name,

1 0

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 29 Nov '03

29 Nov '03

Index: slime/ChangeLog diff -u slime/ChangeLog:1.116 slime/ChangeLog:1.120 --- slime/ChangeLog:1.116 Wed Nov 26 20:24:51 2003 +++ slime/ChangeLog Fri Nov 28 18:29:02 2003 @@ -1,3 +1,52 @@ +2003-11-29 Luke Gorrie <luke(a)bluetail.com> + + * slime.el (complete-symbol, arglist): Updated test cases for new + completion interface. + +2003-11-28 Luke Gorrie <luke(a)bluetail.com> + + * slime.el (slime-complete-symbol): Use the new completion + support from the Lisp side. Don't obscure minibuffer input with + completion messages. + + * completer.el: Dead and buried! Replaced by half a page of Common + Lisp. Thanks Bill Clementson for a motivational and well-deserved + taunt. + + * swank.lisp (longest-completion): Compute the best partial + completion for Emacs. + + * slime.el (slime-swank-port-file): Try (temp-directory), + temporary-file-directory, or "/tmp/", depending on what + is (f)bound. + +2003-11-28 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * swank-lispworks.lisp (make-dspec-location): Handle logical + pathnames. Reported by Alain Picard. + + * swank-sbcl.lisp, swank-cmucl.lisp: Support for output + redirection to an Emacs buffer via a dedicated network stream. + Can be enabled with *use-dedicated-output-stream*. + + * swank.lisp (slime-read-string, eval-string): Flush *emacs-io*. + (eval-in-emacs): New function. + + * slime.el: Support for output from a dedicated socket. + (slime-open-stream-to-lisp, slime-output-filter): New functions. + Reorganized REPL code a bit. + (slime-input-complete-p): Use vanilla forward-sexp, because + slime-forward-sexp sometimes caused endless loops. + (slime-disconnect): Close the output-stream-connection if present. + (slime-handle-oob): A new :%apply event. Executes arbitrary code; + useful for bootstrapping. + (slime-flush-output): New function. + (slime-symbol-end-pos): Didn't work at all in Emacs20. Just use + point until someone commits a proper fix. + Various uses of display-buffer: The second argument is different in + XEmacs. + (interrupt-bubbling-idiot): Reduce the timeout to 5 seconds. + 2003-11-27 Luke Gorrie <luke(a)bluetail.com> * slime.el (slime-swank-port-file): Use `temporary-file-directory'

1 0

Re: [slime-devel] Re: [Ilisp-devel] SLIME
by Bill Clementson 28 Nov '03

28 Nov '03

bmastenb(a)cs.indiana.edu wrote: > On Nov 27, 2003, at 1:31 AM, Bill_Clementson(a)peoplesoft.com wrote: >> 2. Effort is put into creating more complete LEP implementations for >> different CL's so that ELI can be used effectively on multiple CL >> implementations. The benefit of this option is that ELI is very >> full-featured as it is and just the port of the underlying >> communication >> layer would need to be done. Also, since the largest commercial CL >> vendor >> supports ELI and actively enhances it, we can take advantage of both >> commercial and open source development efforts. > As far as I understand it, LEP won't work on non-threaded lisps, which > means there will always be room for a solution that doesn't require > threading. Of course taking advantage of it where present is great, but > right now SBCL lacks threads on anything but x86. I may be wrong, but my understanding was that: 1. ELI uses a socket for communicating between Emacs and CL. 2. The CL implementation, on getting a message on the socket, launches a thread to service the request. This allows multiple request to be submitted to the underlying CL implementation. On a non-threaded lisp, this (of course) would not be possible since the CL implementation couldn't spawn off multiple threads. Instead, it would block until able to complete the request and return the result to Emacs. This would be equivalent to what happens under comint mode (and, presumably, SLIME). However, if my understanding of how LEP functions is correct, this wouldn't mean that you couldn't port ELI to a non-threaded CL, just that you wouldn't realize the benefits of threads. > If you want to help > out, I'm sure that we'd take any code patches towards getting gencgc > working on PowerPC - it's not a trivial matter though, My development environment is MS Windows. > and in the > meantime I enjoy having a development environment that works on SBCL/OS > X. Sure. I enjoy having a development environment too. -- Bill Clementson __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

1 0

[slime-devel] Faster output
by Helmut Eller 28 Nov '03

28 Nov '03

Hi, I've added some code to send the output for *slime-output* across a dedicated network stream. This is quite a bit faster, but the main advantage is that Emacs remains more responsive if we get a lot of output from the Lisp. This was particularly problematic with XEmacs. The drawback is that this scheme bypasses the state machine and the added complexity for the second channel. Also, this isn't a true solution but only hides the problem. The new scheme is currently only available for CMUCL and SBCL. The old scheme can still be used, selectable with *use-dedicated-output-stream*. Comments? Helmut.

2 3

[slime-devel] Re: [Ilisp-devel] SLIME
by Bill_Clementson＠peoplesoft.com 28 Nov '03

28 Nov '03

Hi Luke, I've been following "SLIME" with some interest. Historically, the three main Emacs modes that people have used for CL development were Inferior Lisp Mode (ILM), ILISP and ELI (developed by Franz). ILM & ILISP worked with most CL implementations but were constrained by having been built on top of comint mode (This sometimes results in lock-ups. Also, since comint mode has a single line of communication between Emacs and the CL implementation, it is not possible to take advantage of multiprocessing if the CL implementation supports MP). ELI doesn't have the comint heritage of ILM and ILISP. It (like SLIME) uses a TCP socket to talk to CL and you can have multiple threads of communication open to the CL implementation. Although ELI was developed by Franz, it was released under the GPL and some people have done some work towards porting it to CMUCL and SBCL. I think that the approach taken by ELI and SLIME is the preferable approach; however, ILISP and ILM are both widely used simply because they are the only option available with many CL implementations (for people who want to use Emacs) . I think there are a number of different possible scenarios that might develop: 1. Status quo: ILM, ILISP, ELI and SLIME all coexist. Having multiple Emacs CL modes is in some ways a benefit as it gives people choice; however, it also means that multiple people are all working on divergent efforts to achieve a similar result. 2. Effort is put into creating more complete LEP implementations for different CL's so that ELI can be used effectively on multiple CL implementations. The benefit of this option is that ELI is very full-featured as it is and just the port of the underlying communication layer would need to be done. Also, since the largest commercial CL vendor supports ELI and actively enhances it, we can take advantage of both commercial and open source development efforts. 3. Flesh out SLIME with the functionality that is available today in ILISP and ELI. This is the "clean slate" option. It would allow for a new Emacs CL mode to be developed utilizing the best ideas from ILISP & ELI. It also requires the greatest amount of effort. 4. Integrate SLIME and ILISP. This would add multiprocessing support to ILISP and would allow SLIME to take advantage of the rich functionality already built into ILISP. Perhaps comint mode support could be retained and the SLIME TCP socket communication protocol is provided as just another option (not all CL's support multiprocessing and ILISP also supports a lot of Scheme implementations that don't support multiprocessing so not everyone would benefit from ILISP moving away from comint mode). This might be a win-win option. It might also be a "Frankenstein" approach that could hurt both. I would be interested in hearing what others think about these different scenarios. In all probability, scenario #1 will prevail; however, I would like to hear what others think about the different options (as well as options that I haven't thought of). Bill Clementson "Luke Gorrie" <luke(a)bluetail.com> To: ilisp-devel(a)lists.sourceforge.net Sent by: cc: slime-devel(a)common-lisp.net ilisp-devel-admin(a)lists.sour Subject: [Ilisp-devel] SLIME ceforge.net 11/26/2003 05:55 PM G'day ILISP hackers, I should've written earlier to introduce our project called "SLIME" to you guys. It's similar to ILISP, the main differences are that we use a TCP socket to talk to Lisp and we generally try to imitate the Emacs Lisp programming interface. It started out a few months ago as a hack by Eric Marsden for highlighting CMUCL's compiler warnings in Emacs buffers, but other people started playing with it and now it's snowballed. The main page is on Cliki at http://www.cliki.net/SLIME if you want to know more. I'm not sure how all this relates to ILISP exactly, but I just wanted to shoot you a note to say hello and invite you to play around with it! Cheers, Luke ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Ilisp-devel mailing list Ilisp-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ilisp-devel

4 4