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

[slime-devel] SLIME and Lispworks?
by Alain.Picard＠memetrics.com 27 Nov '03

27 Nov '03

Dear SLIME developers (hi Luke!) Well, ILISP has been annoying me _SO_ much recently I figured it may finally be time to do something about it; then I stumbled on this project. I realize (from reading your sources so far) that you're focussing on CMUCL and SBCL; however, if the intent is to try to make the protocol sufficiently general/portable to other Lisps, I hereby volunteer my services as Lispworks user/tester/debugger (and even, initially) porter of whatever LW specific code needs to be written to get SLIME going on LW. I can't promise I have a lot of time to devote to this, so I'll be happy to pass the ball on to whoever wants to take this up next, but one is greater than zero, so I'm willing to give this a go, if the concensus of this list is that this is a) feasible b) a good idea So let me know your thoughts. (I won't be offended if you think such an effort is undesirable or premature, so feel free to speak your collective minds). yours, --Alain Picard

3 12

[slime-devel] REPL mode
by Helmut Eller 02 Nov '03

02 Nov '03

Hi, I've committed the beginnings of a comint-less REPL. Here are some thoughts. This is a proof of concept, to see if our own REPL is actually better than the (not-so-) inferior-lisp mode. The REPL is activated in the in idle-state and shares the buffer with the other (redirected) output. Some markers track the prompt, the user input, and the beginning of the output. The current design doesn't maintain any state on the Lisp side (we probably should do that, e.g., for things like *, **, *** etc.). Some not so nice things about the new REPL: - since I didn't use comint I had to implement the history management myself. - prompting is triggered by the activation event of the idle state. This means the prompt is printed before we can print the result and we have to go back and insert the result before the prompt. Also we have to check on every idle-state activation event, if we actually need insert a prompt (to avoid many unneeded prompts). - slime-space can produce output and cause a new prompt. This can happen when CMUCL emits warnings during the first coercion a symbol to a function. There is currently no good input handling, e.g, when the Lisp side calls read-char on the redirected input stream, Emacs just reads a line from the minibuffer. My plan was to switch the keymap in the repl buffer when the Lisp side request input. The other keymap doesn't behave like a repl, but send the input more or less uninterpreted to the Lisp side. Not sure how to implement this though. Since I'm not using the repl all that much I'm not sure if it is worth the trouble. There are also problems with output buffering, e.g., when you evaluate (labels ((foo () (foo) t)) (foo)) in the listener, CMUCL puts you in the (tty-) debugger, but you can't see it because the output is buffered somewhere. The nicest thing about this repl is the integration with our debugger. The ugliest thing is the complexity that is needed for better input redirection. Helmut.

2 2

[slime-devel] Automatically remove *Completions* buffer
by Paolo Amoroso 31 Oct '03

31 Oct '03

After doing symbol completion with M-TAB in *inferior-lisp*, the *Completions* buffer remains open if it had previously been activated. Is it possible to make *Completions* disappear as soon as a unique symbol is selected? Paolo -- Paolo Amoroso <amoroso(a)mclink.it>

3 4

[slime-devel] Does SLIME change editor features significantly?
by Martin Stone Davis 31 Oct '03

31 Oct '03

Total newbie here. I have ILISP and I understand that SLIME is for making it easier for Emacs to interact with 3rd party Lisp interpreters. But does/will it also improve on Emacs-Lisp mode? For example, here are some things I'm looking for: * automatic re-indentation (so that if I cut paste something it automatically adjusts the indentation) * "better" keyboard keyboard mappings for movement/selection Without getting into too much detail, I first just wanna know if the above is even within the scope of SLIME. Thanks, -Martin

2 1

[slime-devel] More SLIME wish items
by Raymond Toy 30 Oct '03

30 Oct '03

Since Luke has been very good about getting my wish items into slime, here, I think, is the last one that really prevents me from switching completely to slime from ilisp. In ilisp, if you're in the debugger, pressing C-d pops one level of the debugger. In slime, I press C-d all the time, but cmucl sees a literal C-d and thinks end-of-file. Fortunately, cmucl doesn't exit. And, since we're wishing right now, here's another feature from ilisp that I like and use once in a while. Comes in handy when you're testing different versions of cmucl, or comparing how different lisps behave. Ilisp allows several buffers running at the same time. Each buffer is running a different lisp instance. This can be the same lisp or a different lisp implementation altogether. Anyway, slime rocks! Ray

4 6

[slime-devel] slime-quit errors
by Paolo Amoroso 29 Oct '03

29 Oct '03

When I issue the `slime-quit' command (bound to C-c ESC g) from *inferior-lisp*, I usually get this error in the minibuffer: Symbol's function definition is void: pp-to-string One time I got this in *inferior-lisp*: * ;; Connection to Emacs lost. ;; [End-of-File on #<Stream for descriptor 6>] and this in a separate buffer: You have encountered a bug in SLIME. The communication state machine received an event that was illegal for its current state, which means that the communication between Emacs and Lisp has lost synchronization. The connection to Lisp has therefore been closed. You can open a fresh connection with `M-x slime'. Please report this problem to your friendly neighbourhood SLIME hacker, or the mailing list at slime-devel(a)common-lisp.net. Please include in your report: A description of what you were doing when the problem occured, the version of SLIME, Emacs, and Lisp that you are using, the Lisp backtrace, if one was printed, and the information printed below: The event was: (:emacs-quit) The state stack was: (slime-idle-state) I can't remember exactly what I was doing, but I was evaluating very simple forms and checking a few SLIME commands such as `lisp-describe-sym'. Previously, I had exited a SLIME session with `(quit)' *inferior-lisp*, and then started a new one with `M-x slime'. My setup is: Debian Woody, GNU Emacs 20.7, CMUCL 18e and SLIME CVS sources updated half a dozen hours ago. Paolo -- Paolo Amoroso <amoroso(a)mclink.it>

2 3

[slime-devel] Abnormal exit with code 256
by Paolo Amoroso 29 Oct '03

29 Oct '03

When I quit CMUCL from *inferior-lisp* with `(quit)' I get the following message in the buffer: Process inferior-lisp finished and these messages in the echo area/minibuffer: (Inferior Lisp:no process Inf-Slime[not connected]) Lisp connection closed:exited abnormally with code 256^J Is this the expected behavior? My setup is: Debian Woody, GNU Emacs 20.7, CMUCL 18e, SLIME CVS sources updated half a dozen hours ago. Paolo P.S. I almost forgot: kudos! -- Paolo Amoroso <amoroso(a)mclink.it>

2 3

[slime-devel] not-so-inferior-slime-mode, backhackattack-1
by Luke Gorrie 28 Oct '03

28 Oct '03

Ahoy, Did some improvements to the inferior-slime-mode based on helpful feedback: now it's careful about preserving history with multi-line input, and it also indents it as Lisp code. There's also a command on C-RET that closes all your open parenthesis and sends the input to Lisp. More significantly, I started on The Great Backend Refactoring. This is ultra-disruptive, so I (gag) made a branch: backhackattack-1. The idea is to violently hack things into shape, initially only with the CMUCL backend, and then, only when it's right, update the other backends too. Meanwhile normal use/development can continue on the trunk. The hope is to only be branched for less than a week. So far all I've done is split swank.lisp and swank-cmucl.lisp into separate packages, so that the interface is more explicit. It currently gets through the test suite. The code looks pretty much like a pair of Siamese twins separated by a chainsaw -- lots of internal stuff shared all around the place with no logical division, but with the connections laid bare for the eye to see. The next step is to jumble things around so that the backend implements a small and well-defined interface, and swank.lisp exports as little as possible to support it. AFAICS the best general strategy is moving code from the backend into swank.lisp. Anyone who wants to get muddy is welcome to join in :-) For the callbacks, I'm currently defining the symbols and placeholder-functions in the SWANK package. Then swank-cmucl.lisp contains a bunch of "(defun swank:foobar ..)" forms to properly define the callbacks. May or may not be a good idea. Cheers, Luke

2 3

[slime-devel] slime messing with my window configuration
by Andreas Fuchs 26 Oct '03

26 Oct '03

hi, I often use slime as I used ILISP: have two windows in a frame, split vertically, one containing the lisp source, the other containing the *inferior-lisp*. When slime pops up a buffer, e.g. a debug buffer and I exit it, slime closes the window with my code in it and I am left with just an *inferior-lisp* buffer in the frame. Although I'm used to typing <restart> C-x 3 C-x b RET (luckily the last "code" buffer is the default) now, it's pretty tedious. Other than that, I'm very happy with SLIME right now. Great work, guys. Thanks, -- Andreas Fuchs, <asf(a)acm.org>, asf(a)jabber.at, antifuchs

2 2

[slime-devel] SBCL backend fix
by Luke Gorrie 23 Oct '03

23 Oct '03

Hi, I updated the SBCL backend to use a character stream to match the swank.lisp changes, which fixes a problem reported by Raymond Wiker on comp.lang.lisp. It doesn't look like the OpenMCL backend needs a similar update, but I'm not certain. For me the symptom of this problem includes totally hanging Emacs. That's no good, I'm looking for the cause. Cheers, Luke

3 3

[slime-devel] slime-space fix
by Hannu Koivisto 22 Oct '03

22 Oct '03

Greetings, The attached patch makes it possible to insert several spaces with slime-space, just like you can when SPC is bound to self-insert-command. Also this problem, like the one of not checking whether an inferior Lisp is connected, seems to have been plagiarized from an old version of ILISP ;) -- Hannu

1 0

[slime-devel] more stuff
by Luke Gorrie 21 Oct '03

21 Oct '03

Hi-diddly-ho, Very nice cleanup and extension work Helmut :-) I wonder - now that we have both input and output redirected to Emacs, would writing an `ielm'-style top-level just be a matter of some elisp hacking? I've hacked the connection setup to run asynchronously, so M-x slime will try to connect in the background using a timer to retry. There's a new command `slime-disconnect' that will abort connection retrying or, if already connected, close the connection. This makes it easier to see what's going on and do manual fixes if e.g. the backend fails to compile or something. Now I'm wondering about the next steps in the backend integration/factoring. There are two things I'd like to do: Have a well-defined interface that the backend-specific code implements. Perhaps a `defcallback' macro that we use in swank.lisp where we can put a docstring and possibly some assertions about return values. We should also detect/warn for unimplemented backend functions. This seems pretty easy. The other idea is not so clear, but I would like to factor all of the protocol-related code that sends and receives messages into common code. This is to make the protocol hackable without modifying/breaking all backends, and to get protocol invariants (like proper nesting of :debug and :debug-return) taken care of in one place. I'm also now leaning towards Helmut's idea of using send/receive asynchronous message passing as the lowest layer of communication. Currently we have a hybrid where Emacs always talks to Lisp with RPC but Lisp can send state-specific asynchronous messages to Emacs. This is a bit funky in some cases, e.g. invoking a restart from Emacs would be better done as an asynchronous message than as an RPC since we don't want a result. There's currently a bug in the protocol that you can see when trying to invoke restarts. In some cases the backends will want to send (:debug-condition <string>) messages to Emacs, but the Elisp code doesn't understand those messages anymore (due to my last "improvements"). In the automaton it would be nice to handle these messages in the `debugging' state, but since invoking a restart is done by RPC we end up in the `evaluating' state waiting for a result. So it seems nicer to control the debugger with asynchronous messages instead of RPCs. So, um, that's pretty vague. Mostly written to publicly recant my previous suggestion that RPC is the way to go for everything :-) One thing I did hacking-wise is to add more significant detection of protocol errors. If the Elisp code gets a message that it can't understand in its current state, it closes the connection and pops up a buffer with some debug info and a statement to the effect of "hey, you've found a bug!". Currently I'm getting this trying to invoke the `q'uit restart in the SBCL backend, due to the Elisp :debug-condition bug mentioned above (though I'm not sure why this is hitting a debug-condition in the first place - maybe a bug in the SBCL backend). Cheers, Luke

3 3

[slime-devel] inferior-slime-mode
by Luke Gorrie 21 Oct '03

21 Oct '03

Ahoyhoy, There is now an `inferior-slime-mode'. This is a minor mode to use with inferior-lisp-mode, i.e. in the *inferior-lisp* buffer. It's like the normal slime-mode but with fewer keybindings, e.g. it doesn't have M-p and M-n because a) there're no compiler notes in that buffer and b) comint uses those for input history. I was pretty generous in adding slime-mode bindings to this new mode, though some of them are shadowed by inferior-lisp-mode (probably rightly so). Some tweaking may be in order. The README is updated - what you need is: (add-hook 'inferior-lisp-mode-hook (lambda () (inferior-slime-mode t))) Thanks to everyone who pointed out the problems of using the regular slime-mode with the inf-lisp buffer. Cheers, Luke

1 0

[slime-devel] recent symbol completion change
by Andreas Fuchs 21 Oct '03

21 Oct '03

hi all, after today's "cvs up", I read in the changelog: * swank.lisp (completions): Slight change of semantics: when a prefix-designator is package-qualified, like "swank:", only match symbols whose home-package matches the one given - ignore inherited symbols. I think this leads to unexpected and not-so-useful behaviour. In short, as Krystof said on IRC, "if the symbol is exported from a given package, it's irrelevant what its home package is". To elaborate: This will break with interface packages, i.e. ones that re-export symbols that they import from other, more implementation-dependent packages. SB-MOP and CLIM could be examples of this. For example, CLIM:OUTPUT-STREAM-P is a symbol :IMPORTed-FROM #:CLIM-LISP in McCLIM. McCLIM imports it from COMMON-LISP. It is documented in the spec (http://www.stud.uni-karlsruhe.de/~unk6/clim-spec/D-1.html#_1927) but the programmer can't complete it (even though it's there); This will lead to the programmer losing hair or to SLIME losing users. OTOH, slime does complete symbols that are in a package that :USEs another, e.g. SB-MOP. This isn't all too consistent, IMHO. Now there. Please undo this change (-: Thanks, -- Andreas Fuchs, <asf(a)acm.org>, asf(a)jabber.at, antifuchs

2 2

[slime-devel] strange failure with the sbcl backend
by Andreas Fuchs 18 Oct '03

18 Oct '03

Hi, I was wondering lately why slime/sbcl did not want to compile swank-sbcl.lisp. When I tried it, I got the backtrace available at <URL:http://shell.iddqd.org:8081/paste/display/103>. As you can see, somehow sbcl fails to find the appropriate method for slime-output-stream-buffer. I can trigger this by executing C-c : (defclass slime-output-stream (sb-gray:fundamental-character-output-stream) ((buffer :initform (make-string-output-stream :element-type 'character) :accessor slime-output-stream-buffer))) RET (i.e. a complete 1:1 redefinition of the slime-output-stream class and the slime-output-stream-buffer GF) I'm not sure which is to blame: me, sbcl or swank. It also seems like I'm the only person for whom this is failing. On my machine, I can reproduce this with a clean slime, fresh sbcl (no .sbclrc), while running emacs -q; so it must be my karma or something (-: Thanks, -- Andreas Fuchs, <asf(a)acm.org>, asf(a)jabber.at, antifuchs

2 1

[slime-devel] stuff
by Luke Gorrie 17 Oct '03

17 Oct '03

Howdyo, Feels good to be hacking again :-) Helmut, list-callers is great! The inspector too! This backend integration is groovy too. I've been hacking on the Elisp source-path support a bit more just now. It turns out backquote is really hard (see ChangeLog for details). We probably should push resolving source-paths into Lisp to use their reader for compiler notes too. Maybe `forward-source-path's days are numbered? Also hacked the batch-mode test suite a bit. There's a little 'test.sh' in CVS for running it. I drive it with different lisp/emacs versions with this script: #!/bin/bash tester="/home/luke/hacking/slime/test.sh" emacsen="emacs21 emacs20" lispen="sbcl-cvs cmucl-snapshot cmucl-cvs" echo "(Removing old output.)" rm *.dribble* *.results* &>/dev/null for emacs in $emacsen; do for lisp in $lispen; do tag=${emacs}_${lisp} echo -en "Testing $tag:\t" $tester $emacs $lisp $tag.dribble $tag.results && echo "passed." done done which then prints output like: $ ./slime-test.sh (Removing old output.) Testing emacs21_sbcl-cvs: 6 test(s) failed. Testing emacs21_cmucl-snapshot: 1 test(s) failed. Testing emacs21_cmucl-cvs: 1 test(s) failed. Testing emacs20_sbcl-cvs: 6 test(s) failed. Testing emacs20_cmucl-snapshot: 1 test(s) failed. Testing emacs20_cmucl-cvs: 1 test(s) failed. The details/results and dribble output are saved in files. One test they all failed is placing a compiler note inside a backquote. The extra failed SBCL cases are on tests where we currently assume we're looking things up in CMUCL's codebase. Cheers, Luke

2 2

[slime-devel] OpenMCL Stuff and Swank Compilation
by James Bielman 17 Oct '03

17 Oct '03

Greetings, I've about finished merging my latest OpenMCL code with Slime CVS. However, the code that compiles the sys-dependent backend in an EVAL-WHEN in swank.lisp does not work in OpenMCL. (As I understand the problem, all the DEFMACROs and DEFVARs would need to have EVAL-WHENs around them as well...) Following Dan's suggestion in IRC I started on a loader that the Emacs Lisp calls to compile and load the backend---I've put it up at http://jamesjb.com/slime/swank-loader.lisp for comments. One thing we lose if we do it this way is the ability to give the user the nice "recompile swank?" prompt---we could instead have the elisp compile each of the backend files but then we cannot automagically figure the right backend based on *FEATURES*. (I tried to test the loader under MacOS X SBCL but Swank doesn't seem to run in my build of 0.8.4., thus only tested in OpenMCL). Speaking of testing, a few trivial runs of the unit tests with the OpenMCL backend resulted in 255 failures---after glancing at the code it looks like it would need a fair bit of work to port. In particular it doesn't seem to deal very well with unimplemented slimefuns---perhaps we need a better way to say 'this function is unimplemented' besides dumping the user into the debugger? James -- #:jamesjb

2 1

[slime-devel] STYLE-WARNING/NOTE distinction
by Christophe Rhodes 17 Oct '03

17 Oct '03

Hi, SBCL pays careful attention to the distinction between a STYLE-WARNING (a condition strong enough to warrant returning from COMPILE-FILE with WARNINGSP set) and a compiler note (generally an optimization note, but sometimes a code deletion note or something similar), which aren't counted as warnings. Attached is a patch to implement this. I know cmucl doesn't have this distinction; I'm unsure as to whether OpenMCL does, so I've just implemented it for SBCL; the behaviour of other lisps should be unchanged. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)

1 0

[slime-devel] Re: [slime-cvs] CVS update: slime/swank-cmucl.lisp
by Daniel Barlow 16 Oct '03

16 Oct '03

Helmut Eller <heller(a)common-lisp.net> writes: > +(defun read-next-form () > + (handler-case > + (let* ((length (logior (ash (read-byte *emacs-io*) 16) > + (ash (read-byte *emacs-io*) 8) > + (read-byte *emacs-io*))) > + (string (make-string length))) > + (sys:read-n-bytes *emacs-io* string 0 length) > + (read-form string)) > + (condition (c) > + (throw 'serve-request-catcher c)))) OK, so what is the problem with CMUCL that means it can't use read-sequence here? I know it used to be broken (did partial reads) but I thought that was fixed ages ago. Can we not report this as a bug to the cmucl developers? Thanks for cleaning up my other mess. Now I have to look through your structure stuff and who-calls, see what I can steal for sbcl :-) -dan -- http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro

2 2