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

[slime-devel] Fuzzy completion
by Brian Downing 23 Jun '04

23 Jun '04

Hello Slime developers, For the past while, I've been using a Mac OS X program called Quicksilver, which is sort of a multi-purpose quick access tool. It features a fuzzy completion algorithm that I've quite grown to like. For example I can hit Command-Space and type "liswp<return>", and it will match and launch "LISpWorks Personal". I decided I wanted to add something like this (only better :) to Slime, to go alongside the existing completion algorithm. It can't really be a replacement as they are good at different things. The existing one is good for incrementally typing and completing a symbol. The fuzzy one is good for typing a short version of the symbol, running the completer, and then picking the right result, which hopefully scored at or near the top. While I've attached a patch, this is more a request for comments than a request to commit the code. As I'll discuss, the Emacs interface is incredibly lacking, mostly on account of this being my first time using elisp for anything but configuration. It's very ugly. Also, the completion core code in Swank should be cleaned up - it still looks somewhat hacky. Finally, everything needs documentation. The elisp code has some chunks from isearch.el. Since they are both GPL, I figured this is okay. Besides, it will probably change anyway. :) ---------------------------------------------------------------------- The low level core of the algorithm are implemented in Swank, just like the old completer. The interface looks very similar: ; SLIME 2004-06-10 CL-USER> (setq *print-pretty* t) T CL-USER> (swank::completions "m-v-" "CL-USER") (("multiple-value-bind" "multiple-value-call" "multiple-value-list" "multiple-value-prog1" "multiple-value-setq" "multiple-values-limit") "multiple-value-") CL-USER> (swank::fuzzy-completions "mvb" "CL-USER") (("multiple-value-bind" 26.588236 ((0 "m") (9 "v") (15 "b"))) ("most-negative-double-float" 12.416667 ((0 "m") (11 "v") (17 "b"))) ("most-positive-double-float" 12.416667 ((0 "m") (11 "v") (17 "b"))) ("named-variable" 10.833333 ((2 "m") (6 "v") (11 "b"))) ("*compile-verbose*" 10.666667 ((3 "m") (9 "v") (12 "b"))) ("environment-variable" 10.555555 ((7 "m") (12 "v") (17 "b"))) ("remove-symbol-profiler" 3.5 ((2 "m") (4 "v") (10 "b")))) The return value is obviously a bit more complicated. :) The fields are (completion score chunks), where "chunks" are a description of where the completion matched. There's a convenience function in Swank that is not used by the Emacs interface to print this information in a human readable form. I used this to tune the scoring algorithm. This shows a little more clearly how the algorithm matches: CL-USER> (swank::format-fuzzy-completions (swank::fuzzy-completions "mvb" "CL-USER")) Multiple-Value-Bind score 26.59 ((0 m) (9 v) (15 b)) Most-negatiVe-douBle-float score 12.42 ((0 m) (11 v) (17 b)) Most-positiVe-douBle-float score 12.42 ((0 m) (11 v) (17 b)) naMed-VariaBle score 10.83 ((2 m) (6 v) (11 b)) *coMpile-VerBose* score 10.67 ((3 m) (9 v) (12 b)) environMent-VariaBle score 10.56 ((7 m) (12 v) (17 b)) reMoVe-symBol-profiler score 3.50 ((2 m) (4 v) (10 b)) NIL Here are some more examples, which might show why I think something like this can be useful. (There is an optional third argument to swank::fuzzy-completions, limit. This limits the number of results, which is important for this completer since completing, say, "a" will match many, many symbols. This isn't currently used from Emacs however.) CL-USER> (swank::format-fuzzy-completions (swank::fuzzy-completions "stdout" "CL-USER" 5)) *STanDard-OUtpuT* score 34.83 ((1 st) (5 d) (10 ou) (15 t)) moST-negative-DOUble-floaT score 22.48 ((2 st) (14 dou) (25 t)) moST-positive-DOUble-floaT score 22.48 ((2 st) (14 dou) (25 t)) leaST-positive-DOUble-floaT score 22.45 ((3 st) (15 dou) (26 t)) leaST-negative-DOUble-floaT score 22.45 ((3 st) (15 dou) (26 t)) NIL CL-USER> (swank::format-fuzzy-completions (swank::fuzzy-completions "prp" "CL-USER" 5)) *PRint-Pretty* score 23.83 ((1 pr) (7 p)) PRint-Profile-list score 23.62 ((0 pr) (6 p)) *PRint-Pprint-dispatch* score 23.48 ((1 pr) (7 p)) *step-PRint-Pretty* score 20.59 ((6 pr) (12 p)) *trace-PRint-Pretty* score 20.56 ((7 pr) (13 p)) NIL CL-USER> (swank::format-fuzzy-completions (swank::fuzzy-completions "norm-df" "CL-USER" 5)) least-positive-NORMalized-Double-Float score 32.31 ((15 norm) ...) least-negative-NORMalized-Double-Float score 32.31 ((15 norm) ...) NIL CL-USER> (swank::format-fuzzy-completions (swank::fuzzy-completions "udc" "CL-USER" 1)) Update-instance-for-Different-Class score 26.30 ((0 u) (20 d) (30 c)) NIL CL-USER> (swank::format-fuzzy-completions (swank::fuzzy-completions "urc" "CL-USER" 1)) Update-instance-for-Redefined-Class score 26.30 ((0 u) (20 r) (30 c)) NIL Despite being expensive (it tries all combinations of matches up to a relatively high cutoff per symbol to maximize the score) and not optimized at all, the completion speed doesn't seem bad at all on compiled Lisps on my 500mhz Powerbook. I haven't tried it on interpreted Lisps, but I imagine it wouldn't be too fun. There are some scoring configuration parameters in swank.lisp that are mostly self-explanitory. Adjust to fit your own symbol naming schemes; these seemed to be the five-minute opinion of #lisp. Some way to set these from Emacs would probably be nice in the future. (defparameter *fuzzy-completion-symbol-prefixes* "*+-%&?<") (defparameter *fuzzy-completion-symbol-suffixes* "*+->") (defparameter *fuzzy-completion-word-separators* "-/.") The scoring algorithm is currently completely static. It would probably be a nifty project to implement some machine learning on it. ---------------------------------------------------------------------- Now, the Emacs interface. Well, it kind of sucks. I bound slime-fuzzy-complete-symbol to C-c M-i in the Slime map. The problem is that since the first letters of the short form aren't necessarily the first letters of the matches, the existing Emacs completion system will fail miserably with this algorithm. What I did was, if there was more than one completion, pop up a window with the results (formatted nicely like above, but with a bold face instead of upcasing). Point starts on the highest scoring result, and the result is immediately placed into the Lisp buffer in place of the short form. Then the user can hit 'n' and 'p' to navigate the list of completions. As they do, the replacement is updated. To pick a completion and keep it, hit Return. To abort and revert to the short form, hit almost anything else. It is a recursive edit, like isearch, so doing anything else in Emacs will abort the completion. It's also implemented very poorly. I don't really like this, but I'm not sure what a better option is. If you have the completion buffer come up normally, it will have embedded state from the Lisp source buffer. If the Lisp source buffer changes before a completion is picked, it may modify the wrong position. And again, it can't really work like the (stateless) normal completion. ---------------------------------------------------------------------- So anyway, I'd appreciate it if people could try it out. If anyone has good interface ideas (or even better, would implement them :) I'd like to hear them, since I'm not so happy with what I've got. Thanks, -bcd -- *** Brian Downing <bdowning at lavos dot net>

2 11

[slime-devel] abcl problem and workaround
by Andras Simon 23 Jun '04

23 Jun '04

If you have trouble starting up (a recent copy of) slime with abcl, try setting *swank-debug-p* to nil. The problem is probably a symptom of a bug in abcl's synonym-stream implementation. (There may be other issues involved.) Andras

2 2

[slime-devel] Jumping to source from debugger in Allegro?
by Peter Seibel 23 Jun '04

23 Jun '04

Is this *supposed* to work? I'm using Allegro 6.2 and some recent CVS update of SLIME. But in the debugger if I hit 'v' I get the message: Cannot find source for frame: #<fd -268443954 in "repl-thread" stack group> Pilot error of some sort? -Peter -- Peter Seibel peter(a)javamonkey.com Lisp is the red pill. -- John Fraser, comp.lang.lisp

2 2

[slime-devel] hyperspec-browse-url
by Marco Baringer 23 Jun '04

23 Jun '04

i have a patch to hyperspec.el which allows one to change the viewing of hyperspec entries. this came up on irc a while ago because some people want to use one browser for "regular" links and another for C-c C-h, there are two ways to achieve this, and i don't know which is better: 1) change hyperspec.el to use a hyperspec-browse-url-function variable which is, normally, set to browse-url. 2) buffer locally set browse-url-function. preferences? -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen

2 1

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 23 Jun '04

23 Jun '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.419 slime/ChangeLog:1.424 --- slime/ChangeLog:1.419 Mon Jun 21 23:25:07 2004 +++ slime/ChangeLog Tue Jun 22 10:04:17 2004 @@ -1,3 +1,32 @@ +2004-06-22 Luke Gorrie <luke(a)bluetail.com> + + * doc/slime.texi: Noted ABCL support. + + * slime.el: Backed out all of my changes to fuzzy completion. I + was too hasty and didn't do good things. Now it's back in pristine + state from Brian's patch -- use `C-c M-i' to fuzzy-complete. + + * doc/Makefile (contributors.texi): The contributors list in the + manual is now sorted by most number of ChangeLog entries. Patch + from Michael Weber. + + * slime.el: Some minor hacking to fuzzy completion: + Use the shorter `slime-fuzzy-' symbol prefix. + Use markers instead of numbers to remember where the completion is + being done. This way they are self-updating. + Use `buffer-modified-tick' to detect modifications instead of text + comparison. + Always restore window configuration when a completion is + chosen. For this completion style I think this will work okay + [famous last words], and the existing code wasn't + XEmacs-compatible for want of window-configuration-change-hook. + Now there is no separate keybinding for fuzzy completion, but it's + included as a customize option for `slime-complete-symbol-function' + +2004-06-22 Brian Downing <bdowning(a)lavos.net> + + * slime.el, swank.lisp: Added "fuzzy completion." + 2004-06-22 Matthew Danish <mdanish(a)andrew.cmu.edu> * swank-backend.lisp (unbound-slot-filler): New structure for

1 0

[slime-devel] Design question
by Peter Seibel 23 Jun '04

23 Jun '04

So to make up for my dumb question before (which I see is answered in the ChangeLog) I'm working on adding a feature to SLIME--I want to highlight frames in the debugger for which there is source. (I'm thinking of adding a key to toggle hiding and showing frames for which source is not available.) So here's my question--my first crack at it was to do this entirely in Emacs--when I'm inserting frames I call swank:frame-source-location-for-emacs for each frame and use a different face if the result contains :location. However if it occurs to me it might be more efficient to simply grab the source information along with the rest of the stack trace in debugger-info-for-emacs, i.e. instead of sending back a (number description) tuple for each stack frame, send back (number description source-location). Any thoughts on why that would be a bad way to go? -Peter -- Peter Seibel peter(a)javamonkey.com Lisp is the red pill. -- John Fraser, comp.lang.lisp

3 2

Re: [slime-devel] Re: SLIME User Survey
by Bill_Clementson＠peoplesoft.com 22 Jun '04

22 Jun '04

Luke Gorrie <luke(a)bluetail.com> writes: > Lars Magne Ingebrigtsen <larsi(a)gnus.org> writes: > > > It's not a bug, but I find it a bit annoying that default directory > > that the REPL buffer uses doesn't work more, er, "the way I want". > > That is, if I'm working on a directory on some files (perhaps evaling > > functions in a different buffer), and I then say (load "whatever") in > > the REPL buffer, it doesn't find that file, because the directory > > hasn't been updated... > > Don't want to `C-c C-l' (slime-load-file) from a lisp buffer instead? Alternatively, you might want to use C-c ~ (slime-sync-package-and-default-directory) - Bill

1 0

[slime-devel] How do I abort the debugger and return to the repl?
by Anders Conradi 22 Jun '04

22 Jun '04

Hi, How do I abort the debugger and return to the repl? When I enter an expression that is invalid into the repl slime opens a debug buffer: CL-USER> (teddybear) Opens a debugger containing: Undefined function NO-SUCH-FUNCTION called with arguments () . [Condition of type CCL::UNDEFINED-FUNCTION-CALL] Restarts: 0: [CONTINUE] Retry applying NO-SUCH-FUNCTION to NIL. 1: [USE-VALUE] Apply specified function to NIL this time. 2: [STORE-VALUE] Specify a function to use as the definition of NO-SUCH-FUNCTION. 3: [ABORT] Abort handling SLIME request. 4: [ABORT-BREAK] #<RESTART ABORT-BREAK #xA4BE06> 5: [ABORT] #<RESTART ABORT #xA4BE2E> Backtrace: 0: (CCL::CALL-CHECK-REGS 'NO-SUCH-FUNCTION) --more-- In that buffer there is a list of restarts, the bottom three which seems like they might return to the repl. If I select number 3 I get another debugger, and if I continue to select the one described as "Abort handling SLIME request." openmcl eventually crash and enter the openmcl kernel debugger. Restart 4 & 5 aborts, but all I get is (for restart 5, but the result for restart 4 is similar): Invoking restart: #<RESTART ABORT #xA4BE2E> ; Evaluation aborted I don't get any new repl-prompt. What is going on? I run a version of slime updated just a few minutes ago and openmcl 0.14.2-p1. // Anders

4 5

Fwd: [slime-devel] Re: How do I abort the debugger and return to the repl?
by Anders Conradi 22 Jun '04

22 Jun '04

OK, I sent this from the wrong address and it bounced. Begin forwarded message: > On tisdag, jun 22, 2004, at 09:25 Europe/Stockholm, Luke Gorrie wrote: > >> Anders Conradi <beque(a)telia.com> writes: >> >>> How do I abort the debugger and return to the repl? >> >> Taking the ABORT restart should give you a new prompt. This is a >> bug. I don't have access to OpenMCL currently so I can't check it out, >> but hopefully someone else can. >> >> I know we previously had a problem with restarts in SLDB on OpenMCL >> 0.14 but Gary and Alan fixed that one last month. >> >> Meanwhile it could be interesting to see the contents of your >> *slime-events* buffer immediately after reproducing this bug. > > OK. Here it is. This is after openmcl entered the kernel debugger: > > (:emacs-rex > (swank:connection-info) > nil t > (lambda > (&rest --cl-rest--) > (apply > '(lambda > (G99400 G99391) > (let* ... ...)) > '--cont-- --cl-rest--))) > (:open-dedicated-output-stream 61225) > (:indentation-update > (("without-gcing" . 0) > ("while" . 1) > ("%ilogior" . 1) > ("ignoring-without-interrupts" . 0) > ("once-only" . 1) > ("%with-recursive-lock-ptr" . 1) > ("ensuring-node-target" . 1) > ("restoring-interrupt-level" . 1) > ("%with-recursive-lock-ptr-maybe" . 1) > ("%ilogxor" . 1) > ("in-development-mode" . 0) > ("iterate" . 2) > ("do-interface-dirs" . 1) > ("do-db-links" . 1) > ("qlfun" . 2) > ("%ilogand" . 1) > ("until" . 1) > ("do-dll-nodes" . 1) > ("collect" . 1) > ("do-consing-areas" . 1) > ...)) > (:return > (:ok > (12195 "OpenMCL" "openmcl" > (:asdf :primary-classes :ccl :ccl-2 :ccl-3 :ccl-4 :coral > :common-lisp :mcl :openmcl :ansi-cl :processes :unix > :openmcl-native-threads :openmcl-partial-mop :mcl-common-mop-subset > :openmcl-mop-2 :interfaces-2 :powerpc :ppc-target ...))) > 1) > (:emacs-rex > (swank:listener-eval "(teddybear)") > "CL-USER" :repl-thread > (lambda > (G99425) > (let* > ((tmp-99430 G99425) > (op-99428 > (car tmp-99430)) > (rand-99429 > (cdr tmp-99430))) > (cond > ((eql op-99428 ...) > (let* ... ...)) > ((eql op-99428 ...) > (let* ... ... ...)) > (t > (error "destructure-case failed: %S" tmp-99430)))))) > (:debug 3 1 > ("Undefined function TEDDYBEAR called with arguments () ." " > [Condition of type CCL::UNDEFINED-FUNCTION-CALL]" nil) > (("CONTINUE" "Retry applying TEDDYBEAR to NIL.") > ("USE-VALUE" "Apply specified function to NIL this time.") > ("STORE-VALUE" "Specify a function to use as the definition > of TEDDYBEAR.") > ("ABORT" "Abort handling SLIME request.") > ("ABORT-BREAK" "#<RESTART ABORT-BREAK #xA4BE06>") > ("ABORT" "#<RESTART ABORT #xA4BE2E>")) > ((0 "(CCL::CALL-CHECK-REGS 'TEDDYBEAR)") > (1 "(SWANK::EVAL-REGION \"(teddybear)\" 'T)") > (2 "(#<Anonymous Function #x63B7776>)") > (3 "(#<STANDARD-METHOD NO-APPLICABLE-METHOD ((EQL > #<STANDARD-GENERIC-FUNCTION SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS > #x638668E>))> #<STANDARD-GENERIC-FUNCTION > SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS #x638668E>)") > (4 "(SWANK:LISTENER-EVAL \"(teddybear)\")") > (5 "(CCL::CALL-CHECK-REGS 'SWANK:LISTENER-EVAL)") > (6 "(SWANK::EVAL-FOR-EMACS '(SWANK:LISTENER-EVAL > \"(teddybear)\") \"CL-USER\" 2)") > (7 "(FUNCALL 'SWANK::EVAL-FOR-EMACS)") > (8 "(#<Anonymous Function #x63B38FE>)") > (9 "(SWANK::CALL-WITH-REDIRECTED-IO #<Anonymous Function > #x63B38FE>)") > (10 "(SWANK::HANDLE-REQUEST #S(SWANK::CONNECTION :SOCKET-IO > #<TCP-STREAM (SOCKET/11) #x63D57FE> :DEDICATED-OUTPUT #<TCP-STREAM > (SOCKET/12) #x63D5076> :USER-INPUT #<SWANK-BACKEND::SLIME-INPUT-STREAM > #x63D4C86> :USER-OUTPUT #<TCP-STREAM (SOCKET/12) #x63D5076> :USER-IO > #<TWO-WAY-STREAM input #<SWANK-BACKEND::SLIME-INPUT-STREAM #x63D4C86>, > output #<TCP-STREAM (SOCKET/12) #x63D5076> #x63D4C46> :READER-THREAD > #<PROCESS reader-thread(4) [Active] #x63FFDEE> :CONTROL-THREAD > #<PROCESS control-thread(3) [Active] #x63D440E> :REPL-THREAD #<PROCESS > repl-thread(5) [Active] #x63FFB1E> :SERVE-REQUESTS #<Compiled-function > SWANK::SPAWN-THREADS-FOR-CONNECTION #x63B083E> :READ > #<Compiled-function SWANK::READ-FROM-CONTROL-THREAD #x63ABD7E> :SEND > #<Compiled-function SWANK::SEND-TO-CONTROL-THREAD #x63AB30E> :CLEANUP > NIL :INDENTATION-CACHE #<HASH-TABLE :TEST EQ size 34/60 #x63D5226> > :INDENTATION-CACHE-PACKAGES (#<Package \"SWANK-COMPLETION-TEST\"> > #<Package \"SWANK-IO-PACKAGE\"> #<Package \"SWANK\"> #<Package > \"NREGEX\"> #<Package \"SWANK-BACKEND\"> #<Package \"SWANK-LOADER\"> > #<Package \"ASDF\"> #<Package \"PPC64\"> #<Package \"PPC\"> #<Package > \"PPC32\"> #<Package \"ILISP\"> #<Package \"OPENMCL-MOP\"> #<Package > \"GRAY\"> #<Package \"CLOS-BOOT\"> #<Package \"OPENMCL-SOCKET\"> > #<Package \"INSPECTOR\"> #<Package \"OS\"> #<Package \"ARCH\"> > #<Package \"ANSI-LOOP\"> #<Package \"COMMON-LISP-USER\"> #<Package > \"SETF\"> #<Package \"CCL\"> #<Package \"COMMON-LISP\"> #<Package > \"KEYWORD\">)))") > (11 "(#<Anonymous Function #x63B01EE>)") > (12 "(SWANK::CALL-WITH-REDIRECTED-IO > #<COMPILED-LEXICAL-CLOSURE #x641FE36>)") > (13 "(SWANK::REPL-LOOP #S(SWANK::CONNECTION :SOCKET-IO > #<TCP-STREAM (SOCKET/11) #x63D57FE> :DEDICATED-OUTPUT #<TCP-STREAM > (SOCKET/12) #x63D5076> :USER-INPUT #<SWANK-BACKEND::SLIME-INPUT-STREAM > #x63D4C86> :USER-OUTPUT #<TCP-STREAM (SOCKET/12) #x63D5076> :USER-IO > #<TWO-WAY-STREAM input #<SWANK-BACKEND::SLIME-INPUT-STREAM #x63D4C86>, > output #<TCP-STREAM (SOCKET/12) #x63D5076> #x63D4C46> :READER-THREAD > #<PROCESS reader-thread(4) [Active] #x63FFDEE> :CONTROL-THREAD > #<PROCESS control-thread(3) [Active] #x63D440E> :REPL-THREAD #<PROCESS > repl-thread(5) [Active] #x63FFB1E> :SERVE-REQUESTS #<Compiled-function > SWANK::SPAWN-THREADS-FOR-CONNECTION #x63B083E> :READ > #<Compiled-function SWANK::READ-FROM-CONTROL-THREAD #x63ABD7E> :SEND > #<Compiled-function SWANK::SEND-TO-CONTROL-THREAD #x63AB30E> :CLEANUP > NIL :INDENTATION-CACHE #<HASH-TABLE :TEST EQ size 34/60 #x63D5226> > :INDENTATION-CACHE-PACKAGES (#<Package \"SWANK-COMPLETION-TEST\"> > #<Package \"SWANK-IO-PACKAGE\"> #<Package \"SWANK\"> #<Package > \"NREGEX\"> #<Package \"SWANK-BACKEND\"> #<Package \"SWANK-LOADER\"> > #<Package \"ASDF\"> #<Package \"PPC64\"> #<Package \"PPC\"> #<Package > \"PPC32\"> #<Package \"ILISP\"> #<Package \"OPENMCL-MOP\"> #<Package > \"GRAY\"> #<Package \"CLOS-BOOT\"> #<Package \"OPENMCL-SOCKET\"> > #<Package \"INSPECTOR\"> #<Package \"OS\"> #<Package \"ARCH\"> > #<Package \"ANSI-LOOP\"> #<Package \"COMMON-LISP-USER\"> #<Package > \"SETF\"> #<Package \"CCL\"> #<Package \"COMMON-LISP\"> #<Package > \"KEYWORD\">)))") > (14 "(CCL::RUN-PROCESS-INITIAL-FORM > '(#<COMPILED-LEXICAL-CLOSURE #x63FFA96>))") > (15 "(#<Anonymous Function #x6101D3E> > '(#<COMPILED-LEXICAL-CLOSURE #x63FFA96>))") > (16 "(#<Anonymous Function #x60F491E>)"))) > (:debug-activate 4 1) > (:emacs-rex > (swank:invoke-nth-restart-for-emacs 1 3) > nil 3 > (lambda > (G99487) > (let* > ((tmp-99492 G99487) > (op-99490 > (car tmp-99492)) > (rand-99491 > (cdr tmp-99492))) > (cond > ((eql op-99490 ...) > (let* ... ...)) > ((eql op-99490 ...) > (let* ... ...)) > (t > (error "destructure-case failed: %S" tmp-99492)))))) > (:debug 6 2 > ("Error reporting error" " [Condition of type SIMPLE-ERROR]" > nil) > (("ABORT" "Return to sldb level 1.") > ("ABORT" "Abort handling SLIME request.") > ("ABORT-BREAK" "#<RESTART ABORT-BREAK #xA4BE06>") > ("ABORT" "#<RESTART ABORT #xA4BE2E>")) > ((0 "(CCL::FUNCALL-WITH-ERROR-REENTRY-DETECTION > #<COMPILED-LEXICAL-CLOSURE #xA4B54E>)") > (1 "(#<Anonymous Function #x6163E8E> -65535040)") > (2 "(CCL::%XERR-DISP -65535626)") > (3 "(CCL::CALL-CHECK-REGS > 'SWANK:INVOKE-NTH-RESTART-FOR-EMACS)") > (4 "(SWANK::EVAL-FOR-EMACS > '(SWANK:INVOKE-NTH-RESTART-FOR-EMACS 1 3) 'NIL 3)") > (5 "(FUNCALL 'SWANK::EVAL-FOR-EMACS)") > (6 "(SWANK::SLDB-LOOP 1)") > (7 "(#<STANDARD-METHOD > SWANK-BACKEND:CALL-WITH-DEBUGGING-ENVIRONMENT (T)> #<Anonymous > Function #x63BCA56>)") > (8 "(SWANK::DEBUG-IN-EMACS #<CCL::UNDEFINED-FUNCTION-CALL > #x641FA26>)") > (9 "(CCL::BREAK-LOOP-HANDLE-ERROR -65534284)") > (10 "(CCL::%%STANDARD-COMBINED-METHOD-DCODE)") > (11 "(CCL::%ERROR 'NIL -65534284)") > (12 "(CCL::DEFAULT-UNDEFINED-FUNCTION-CALL-RESTARTS > -65534284)") > (13 "(CCL::HANDLE-UDF-CALL -65534284)") > (14 "(#<Anonymous Function #x6163E06>)") > (15 "(CCL::FUNCALL-WITH-ERROR-REENTRY-DETECTION > #<COMPILED-LEXICAL-CLOSURE #xA4B9B6>)") > (16 "(#<Anonymous Function #x6163E8E> -65534284)") > (17 "(CCL::%XERR-DISP -65534870)") > (18 "(CCL::CALL-CHECK-REGS 'TEDDYBEAR)") > (19 "(SWANK::EVAL-REGION \"(teddybear)\" 'T)"))) > (:debug-activate 7 2) > (:emacs-rex > (swank:invoke-nth-restart-for-emacs 2 1) > nil 6 > (lambda > (G99533) > (let* > ((tmp-99538 G99533) > (op-99536 > (car tmp-99538)) > (rand-99537 > (cdr tmp-99538))) > (cond > ((eql op-99536 ...) > (let* ... ...)) > ((eql op-99536 ...) > (let* ... ...)) > (t > (error "destructure-case failed: %S" tmp-99538)))))) >

1 0

[slime-devel] Daily ChangeLog diff
by Luke Gorrie 22 Jun '04

22 Jun '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.417 slime/ChangeLog:1.419 --- slime/ChangeLog:1.417 Sun Jun 20 23:27:24 2004 +++ slime/ChangeLog Mon Jun 21 23:25:07 2004 @@ -1,3 +1,21 @@ +2004-06-22 Matthew Danish <mdanish(a)andrew.cmu.edu> + + * swank-backend.lisp (unbound-slot-filler): New structure for + representing an unbound slot in the inspector functions. + + * swank.lisp, swank-allegro.lisp: Use it. + +2004-06-22 Luke Gorrie <luke(a)bluetail.com> + + * slime.el (slime-output-filter): Choose connection based on + process-buffer, not current buffer. This fixes a bug where output + from multiple Lisp sessions could get mixed up. + (slime-kill-all-buffers): Include all *inferior-lisp*[<n>] buffers. + Split the customize settings into more subgroups. + + * swank.lisp (prefixed-var): Intern *REAL-STANDARD-INPUT* etc in + the SWANK package instead of the COMMON-LISP package. + 2004-06-21 Luke Gorrie <luke(a)bluetail.com> * swank-loader.lisp (*lisp-name*): Add version number to

1 0