slime-devel March 2006

slime-devel@common-lisp.net

43 participants
49 discussions

[slime-devel] slime-apropos-package now sorts correctly
by Hoehle, Joerg-Cyril 20 Apr '07

20 Apr '07

Hi, slime-apropos-package now conforms to its specification and also sorts symbols printed with package prefix. I supply the patches as attachments in the hope that MS-Windows nor MS-Outlook will break the TAB and LF characters of the original diff. I hope this is fine. Regards, Jörg Höhle.

3 3

[slime-devel] slime-display-edit-hilights
by Marco Baringer 23 Dec '06

23 Dec '06

for those of you who don't follow c.l.l (which is probaly a good idea) i commited William Bland's patch[1]. see the ChangeLog for details. 1 - http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/e1d0b7bf… -- -Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen

8 20

[slime-devel] How to inspect locals
by Jonathon McKitrick 27 Aug '06

27 Aug '06

Hi all, when running SBCL and a condition occurs that causes a break, how can I view the locals that have been bound in the function? Viewing the arguments isn't hard, but I cannot seem to figure out the locals. -Jonathon -- "I am sure that Jesus would use a command prompt. Hello? Ten Commandments??"

12 17

[slime-devel] Error: (void-variable name); slime-autodoc-mode now disabled.
by Goenninger, Frank 14 Apr '06

14 Apr '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi all: Using SLIME as of 2006-03-28 from CVS I get the following error: Error: (void-variable name); slime-autodoc-mode now disabled. I am using Emacs 22.0.50.1 (as downloaded from Apple) in a build version of 2006-03-06 on a Apple OS X 10.4.5 system running ACL8.0. Anybody else seeing this also (No, I didn't search the slime-devel archives but think to remember a related symptom having been mentioned earlier). Any ideas? Thanks!!! Cheers Frank -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.5 (Build 5050) iQIVAwUBRCrgX2AKVUddnkqnAQoEcA/+NaXiESRbzSZH4jx47MnLh73Ly8yTtTbr Uh32FoWE+NSBUSFjD563ASEsBCrezZd2OreaYuWHDiJnK5njgXvzEs1OWLTh2mOw DXH5NXHT4Ji8kebpQjj5R2xVaX8JbZDKXFXALR5bKrKoWC0hZHxYcrdA+qQgvxAf LMcKOC8aigGljsIwuIIR4KQy7BxDTulIZYRysrNAP4UwJ/AcfSeHwbe1MSusKqFu qpdBGAUMtNmRM3nAAxpDBOWY8X6mHhT+w2ShrxfJ+Gk/bC2WlaTVYVvvA7ul82w9 HS1d+I6L0WA4qSwN7QqVqEJl1jNhK+wu2SPdBKceqW1DY5K1yquDflt5RI0g3z5M o680MH30nywXH7h4DjDEKHiYXSGD4ddSFiFx6Dcl6tGQ5ZVNF1TO69TtVegTXNm8 uUWrakMxyteiA2ZFBfw50YEv4XBSPjun1JR3n8sUC0s3pynpiRWdO+tjl3w8R551 DPmsZEFW9VbJR3nlhqCElCjeepcy+LyagfnmqOtoe6cIVcOvKnMftFh1GN8sx/H+ AbwNn0IZQzbLMkTbh3nhsIvjNqvkyaHt9gkOsn9hQTNHldjS1DB5sPiGU0MwSFdc f7h/6E52UeWefIBpTDDH7RWJn0wOKIAoC0ysFjC7hF/oqhcUQ0WiN2daBYclVr+N EJOJXwX88+o= =OMN5 -----END PGP SIGNATURE-----

4 4

[slime-devel] sbcl stream flushing race
by Robert J. Macomber 12 Apr '06

12 Apr '06

After some time, I've finally got annoyed by the SBCL output race buglet to do something about it. For those who haven't seen this (either because you don't use sbcl, or your systems aren't the "right" speed to trigger it), sometimes when outputting to the dedicated output stream, multiple flushes will be done to aren't the "right" speed to trigger it), sometimes when outputting to the dedicated output stream, multiple flushes will be done at the same time, resulting in something that looks like this paragraph. I have a patch that fixes it, but it's a bit of a blunt instrument. It wraps the streams passed to MAKE-STREAM-INTERACTIVE in a Gray stream containing a mutex, so that the stream acts as a monitor, preventing different threads from using it at the same time. (This changes the semantics of the make-stream-interactive interface; before it was called for side-effects, now it may or may not have a side effect and returns an "interactive" stream that may or may not be the same object as the one it was called with. All the swank backends are updated in the patch.) Currently, the patch is sbcl-only. While updating the other backends, I noticed abcl uses the same "thread which FORCE-OUTPUTs" technique, but I don't have abcl here, so I don't know if the same race manifests, if abcl even supports Gray strams, or how to create and use a mutex if the two previous conditions held. Is there any interest in this, or does anyone have a better idea how to approach this bug? -- Robert Macomber slime(a)rojoma.com / Thas on #lisp

5 6

[slime-devel] three little patches
by Gary King 06 Apr '06

06 Apr '06

Hiya, Here are three small patches for SLIME. They do the following: 1. Make find-definitions a little more flexible with an around method: if the symbol isn't in the current package, the around method goes on to look in all the packages too. (I haven't added similar logic to symbol completion but will someday). 2. Modifies swank-loader so that Allegro's alisp and mlisp programs get different locations. Otherwise mlisp complains about alisp's files. 3. Added two more symbols to the exports list in swank-openmcl. HTH, > Index: swank-backend.lisp > =================================================================== > RCS file: /project/slime/cvsroot/slime/swank-backend.lisp,v > retrieving revision 1.94 > diff -u -w -r1.94 swank-backend.lisp > --- swank-backend.lisp 20 Nov 2005 23:25:38 -0000 1.94 > +++ swank-backend.lisp 16 Mar 2006 01:04:37 -0000 > @@ -615,6 +615,20 @@ > LOCATION is the source location for the definition.") > +(defvar *currently-finding-definitions* nil) > + > +(defmethod find-definitions :around ((name symbol)) > + ;; look in other packages if we don't find something in this > package > + (let ((result (call-next-method))) > + (unless (or result *currently-finding-definitions*) > + (let ((*currently-finding-definitions* t) > + (symbol-name (symbol-name name))) > + (dolist (package (list-all-packages)) > + (let ((symbol (find-symbol symbol-name package))) > + (when symbol > + (setf result (append result (find-definitions > symbol)))))))) > + result)) > + > (definterface buffer-first-change (filename) > "Called for effect the first time FILENAME's buffer is modified." > (declare (ignore filename)) > Index: swank-loader.lisp > =================================================================== > RCS file: /project/slime/cvsroot/slime/swank-loader.lisp,v > retrieving revision 1.55 > diff -u -w -r1.55 swank-loader.lisp > --- swank-loader.lisp 19 Jan 2006 22:56:16 -0000 1.55 > +++ swank-loader.lisp 16 Mar 2006 01:04:38 -0000 > @@ -65,7 +65,8 @@ > ccl::*openmcl-major-version* > ccl::*openmcl-minor-version*) > #+lispworks (lisp-implementation-version) > - #+allegro excl::*common-lisp-version-number* > + #+allegro (concatenate 'string (if (eq 'h 'H) "A" "M") ; > ANSI vs MoDeRn > + excl::*common-lisp-version-number*) > #+clisp (let ((s (lisp-implementation-version))) > (subseq s 0 (position #\space s))) > #+armedbear (lisp-implementation-version) > Index: swank-openmcl.lisp > =================================================================== > RCS file: /project/slime/cvsroot/slime/swank-openmcl.lisp,v > retrieving revision 1.103 > diff -u -w -r1.103 swank-openmcl.lisp > --- swank-openmcl.lisp 11 Nov 2005 23:43:43 -0000 1.103 > +++ swank-openmcl.lisp 16 Mar 2006 01:04:38 -0000 > @@ -65,6 +65,8 @@ > cl:method > cl:standard-class > ccl::eql-specializer > + ccl::eql-specializer-object > + ccl::class-name > ;; standard-class readers > openmcl-mop:class-default-initargs > openmcl-mop:class-direct-default-initargs -- Gary Warren King metabang.com http://www.metabang.com/

5 9

[slime-devel] can't load slime (sbcl)
by Irène Durand 05 Apr '06

05 Apr '06

Hello, I am trying to have Slime and SBCL on my students machines. On my machine everything works fine but on the students machines I obtain at the end of the loading the error error in process filter: Wrong number of arguments: nil, 12 in the emacs mini-buffer. I have SBCL 0.9.11 and the latest cvs version of Slime. Any idea of what can be wrong? Irène ; loading #P"/net/cremi/irdurand/Common-Lisp/slime/swank-loader.lisp" ;; loading #P"/net/cremi/irdurand/.slime/fasl/2006-03-31/sbcl-0.9.11-linux-x86/swank-backend.fasl" ;; loading #P"/net/cremi/irdurand/.slime/fasl/2006-03-31/sbcl-0.9.11-linux-x86/nregex.fasl" ;; loading #P"/net/cremi/irdurand/.slime/fasl/2006-03-31/sbcl-0.9.11-linux-x86/swank-sbcl.fasl" STYLE-WARNING: redefining PREFERRED-COMMUNICATION-STYLE NIL in DEFMETHOD STYLE-WARNING: redefining CALL-WITHOUT-INTERRUPTS (T) in DEFMETHOD STYLE-WARNING: redefining LISP-IMPLEMENTATION-TYPE-NAME NIL in DEFMETHOD STYLE-WARNING: redefining CALL-WITH-SYNTAX-HOOKS (T) in DEFMETHOD STYLE-WARNING: redefining DEFAULT-READTABLE-ALIST NIL in DEFMETHOD STYLE-WARNING: redefining ARGLIST (T) in DEFMETHOD STYLE-WARNING: redefining INSTALL-DEBUGGER-GLOBALLY (T) in DEFMETHOD STYLE-WARNING: redefining CALL-WITH-DEBUGGER-HOOK (T T) in DEFMETHOD STYLE-WARNING: redefining FORMAT-SLDB-CONDITION (T) in DEFMETHOD STYLE-WARNING: redefining CONDITION-REFERENCES (T) in DEFMETHOD STYLE-WARNING: redefining UNPROFILE-ALL NIL in DEFMETHOD STYLE-WARNING: implicitly creating new generic function STARTUP-MULTIPROCESSING WARNING: DEFIMPLEMENTATION of undefined interface (STARTUP-MULTIPROCESSING) STYLE-WARNING: redefining THREAD-NAME (T) in DEFMETHOD STYLE-WARNING: redefining THREAD-STATUS (T) in DEFMETHOD STYLE-WARNING: redefining MAKE-LOCK NIL in DEFMETHOD STYLE-WARNING: redefining CALL-WITH-LOCK-HELD (T T) in DEFMETHOD STYLE-WARNING: redefining CURRENT-THREAD NIL in DEFMETHOD STYLE-WARNING: redefining KILL-THREAD (T) in DEFMETHOD STYLE-WARNING: redefining THREAD-ALIVE-P (T) in DEFMETHOD STYLE-WARNING: redefining MAKE-STREAM-INTERACTIVE (T) in DEFMETHOD ;; loading #P"/net/cremi/irdurand/.slime/fasl/2006-03-31/sbcl-0.9.11-linux-x86/swank-source-path-parser.fasl" ;; loading #P"/net/cremi/irdurand/.slime/fasl/2006-03-31/sbcl-0.9.11-linux-x86/swank-source-file-cache.fasl" STYLE-WARNING: redefining BUFFER-FIRST-CHANGE (T) in DEFMETHOD ;; loading #P"/net/cremi/irdurand/.slime/fasl/2006-03-31/sbcl-0.9.11-linux-x86/swank-gray.fasl" STYLE-WARNING: implicitly creating new generic function STREAM-READ-CHAR-WILL-HANG-P ;; loading #P"/net/cremi/irdurand/.slime/fasl/2006-03-31/sbcl-0.9.11-linux-x86/swank.fasl" STYLE-WARNING: implicitly creating new generic function INSPECT-BIGGER-PIECE-ACTIONS STYLE-WARNING: implicitly creating new generic function INSPECT-WHOLE-THING-ACTION STYLE-WARNING: implicitly creating new generic function INSPECT-SHOW-MORE-ACTION STYLE-WARNING: implicitly creating new generic function MENU-CHOICES-FOR-PRESENTATION WARNING: These Swank interfaces are unimplemented: (ACTIVATE-STEPPING CALLS-WHO DISASSEMBLE-FRAME INSPECT-FOR-EMACS SLDB-BREAK-AT-START SLDB-BREAK-ON-RETURN WHO-BINDS WHO-CALLS WHO-MACROEXPANDS WHO-REFERENCES WHO-SETS WHO-SPECIALIZES) T * ;; Swank started at port: 35880. NIL *

2 1

[slime-devel] source location snippet searching
by Taylor R. Campbell 01 Apr '06

01 Apr '06

If the Lisp system provides a snippet hint for a source location, `slime-goto-source-location' uses `slime-isearch' to find the nearest occurrence of it in order to narrow down the location better, and subsequently uses `slime-search-call-site' to narrow it down even further. However, the search may send the point off into some random place in the file, even in a completely different defun, but then `slime-search-call-site' narrows itself to whichever defun it's on and searches *there*, so if `slime-isearch' got lost then the whole thing will get lost. Is there a reason that `slime-goto-source-location' does not narrow to the defun before running `slime-isearch'? The above problem is solved by this simple patch: Index: slime.el =================================================================== RCS file: /project/slime/cvsroot/slime/slime.el,v retrieving revision 1.605 diff -u -r1.605 slime.el --- slime.el 26 Mar 2006 03:51:56 -0000 1.605 +++ slime.el 30 Mar 2006 23:51:34 -0000 @@ -5043,7 +5043,9 @@ (slime-goto-location-buffer buffer) (slime-goto-location-position position) (when-let (snippet (getf hints :snippet)) - (slime-isearch snippet)) + (save-restriction + (narrow-to-defun) + (slime-isearch snippet))) (when-let (fname (getf hints :call-site)) (slime-search-call-site fname))) ((:error message)

2 2

[slime-devel] Remote slime broken?
by Joel Reymont 31 Mar '06

31 Mar '06

I think this must have something to do with the recent fix to change- directory. I positively have this remote directory but all of a sudden I cannot change into it. There is no file named /ssh:jreymont@repdb2.cur:/home/jreymont/fraud [Condition of type FILE-ERROR] Restarts: 0: [ABORT-REQUEST] Abort handling SLIME request. 1: [ABORT] Abort entirely from this (lisp) process. Backtrace: 0: (SWANK::DEBUG-IN-EMACS #<FILE-ERROR @ #x10010ab292>) 1: (SWANK:SWANK-DEBUGGER-HOOK #<FILE-ERROR @ #x10010ab292> #<Function SWANK-DEBUGGER-HOOK>) 2: (ERROR FILE-ERROR :PATHNAME #1=#P"/ssh:jreymont@repdb2.cur:/ home/jreymont/fraud" :ERRNO 2 :FORMAT-CONTROL "There is no file named ~a" :FORMAT-ARGUMENTS (#1#)) 3: ((METHOD SWANK-BACKEND:SET-DEFAULT-DIRECTORY (T)) "/ ssh:jreymont@repdb2.cur:/home/jreymont/fraud") 4: (EVAL (SWANK-BACKEND:SET-DEFAULT-DIRECTORY "/ ssh:jreymont@repdb2.cur:/home/jreymont/fraud")) 5: ((:INTERNAL SWANK::EVAL-FOR-EMACS 0)) 6: ((METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) #<Function SWANK-DEBUGGER-HOOK> #<Closure (:INTERNAL SWANK::EVAL-FOR- EMACS 0) @ #x10010aaa62>) 7: (SWANK::EVAL-FOR-EMACS (SWANK-BACKEND:SET-DEFAULT-DIRECTORY "/ ssh:jreymont@repdb2.cur:/home/jreymont/fraud") "COMMON-LISP-USER" 50) 8: (FUNCALL SWANK::EVAL-FOR-EMACS (SWANK-BACKEND:SET-DEFAULT- DIRECTORY "/ssh:jreymont@repdb2.cur:/home/jreymont/fraud") "COMMON- LISP-USER" 50) 9: (SWANK::READ-FROM-EMACS) 10: ((:INTERNAL SWANK::HANDLE-REQUEST 0)) 11: ((METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) #<Function SWANK-DEBUGGER-HOOK> #<Function (:INTERNAL SWANK::HANDLE-REQUEST 0)>) 12: ((:INTERNAL SWANK::CALL-WITH-CONNECTION 0)) 13: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION @ #x1000f4d6d2> #<Closure (:INTERNAL SWANK::CALL-WITH-CONNECTION 0) @ #x10010aa9e2>) 14: (SWANK::MAYBE-CALL-WITH-IO-REDIRECTION #<SWANK::CONNECTION @ #x1000f4d6d2> #<Closure (:INTERNAL SWANK::CALL-WITH-CONNECTION 0) @ #x10010aa9e2>) 15: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION @ #x1000f4d6d2> #<Function (:INTERNAL SWANK::HANDLE-REQUEST 0)>) 16: (SWANK::HANDLE-REQUEST #<SWANK::CONNECTION @ #x1000f4d6d2>) 17: ((:INTERNAL SWANK::REPL-LOOP 0)) 18: ((METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) #<Function SWANK-DEBUGGER-HOOK> #<Closure (:INTERNAL SWANK::REPL-LOOP 0) @ #x10010aa922>) 19: ((:INTERNAL SWANK::CALL-WITH-CONNECTION 0)) 20: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION @ #x1000ce9072> #<Closure (:INTERNAL SWANK::CALL-WITH-CONNECTION 0) @ #x1000d3ab72>) 21: (SWANK::MAYBE-CALL-WITH-IO-REDIRECTION #<SWANK::CONNECTION @ #x1000ce9072> #<Closure (:INTERNAL SWANK::CALL-WITH-CONNECTION 0) @ #x1000d3ab72>) 22: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION @ #x1000ce9072> #<Closure (:INTERNAL SWANK::REPL-LOOP 0) @ #x1000d3ab42>) 23: (SWANK::REPL-LOOP #<SWANK::CONNECTION @ #x1000ce9072>) 24: ((:INTERNAL (:INTERNAL SWANK::SPAWN-REPL-THREAD 0) 0)) 25: (SWANK::CALL-WITH-BINDINGS NIL #<Closure (:INTERNAL (:INTERNAL SWANK::SPAWN-REPL-THREAD 0) 0) @ #x1000d3abd2>) 26: ((:INTERNAL SWANK::SPAWN-REPL-THREAD 0)) -- http://wagerlabs.com/

1 0

[slime-devel] Multiple SLIME Inspectors
by Lynn Quam 31 Mar '06

31 Mar '06

It is often very useful to inspect more than one object (object-tree) at the same time. With SLIME, one can Inspect an object, and then rename the *Slime Inspector* buffer, and inspect another object, getting a new *Slime Inspector* buffer. (It would be better to have a "Spawn New Inspector" command.) However, inspect operations in the old (renamed) buffer cause the results to be displayed in the new inspector rather than the "current" inspector. How hard would it be to make this work.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

slime-devel March 2006