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

[slime-devel] emacs build complains about slime
by GP lisper 16 May '05

16 May '05

While tracking down an emacs problem, I noticed the following while compiling emacs: Dumping under names emacs and emacs-21.3.1 715504 pure bytes used ./emacs -q -batch -f list-load-path-shadows This site has duplicate Lisp libraries with the same name. If a locally-installed Lisp library overrides a library in the Emacs release, that can cause trouble, and you should probably remove the locally-installed version unless you know what you are doing. /usr/share/emacs/site-lisp/tree-widget hides /usr/share/emacs/site-lisp/slime/tree-widget -- Everyman has three hearts; one to show the world, one to show friends, and one only he knows.

3 4

[slime-devel] Daily ChangeLog diff
by lgorrie＠common-lisp.net 12 May '05

12 May '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.684 slime/ChangeLog:1.685 --- slime/ChangeLog:1.684 Wed May 11 16:47:06 2005 +++ slime/ChangeLog Thu May 12 21:05:04 2005 @@ -1,3 +1,18 @@ +2005-05-12 Alan Ruttenberg <alanr-l(a)mumble.net> + + * swank.lisp Add ability to customize behavior of the repl. To do + so, add a function to the list swank::*slime-repl-eval-hooks*. + This function is passed the form typed into the repl. The function + should decide whether it wants to handle evaluation of the + form. If not, call (repl-eval-hook-pass) and the next hook is + tried. Otherwise the values the function returns are used instead + of calling eval. Inside the body of the function you can also + suppress having the repl print the result by calling + (repl-suppress-output) and/or suppress the advancement of the + history variables (*** ** * /// // /) by calling + (repl-suppress-advance-history). + + 2005-05-11 Tim Daly Jr. <tim(a)tenkan.org> * swank-source-path-parser.lisp (read-and-record-source-map):

1 0

[slime-devel] Load-system produces multiple identical compiler notes when invoked several times
by Ignas Mikalajunas 12 May '05

12 May '05

I have managed to track the problem to slime-remove-old-overlays which clears overlays only in the current buffer. I know that it is supposed to do that, yet when using load-system, i am geting a lot of duplicate notes in the buffers that contain other files from the same system. Is there a way to hook into the system being compiled and clear the notes for all the files that are recompiled or even all the files that belong to the given system. I could not find an obvious way of accomplishing such a task myself :( Ignas Mikalajūnas

2 2

[slime-devel] Daily ChangeLog diff
by lgorrie＠common-lisp.net 11 May '05

11 May '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.683 slime/ChangeLog:1.684 --- slime/ChangeLog:1.683 Fri May 6 18:34:00 2005 +++ slime/ChangeLog Wed May 11 16:47:06 2005 @@ -1,3 +1,19 @@ +2005-05-11 Tim Daly Jr. <tim(a)tenkan.org> + + * swank-source-path-parser.lisp (read-and-record-source-map): + Ensure that at least the toplevel form is in the source-map. + +2005-05-11 Helmut Eller <heller(a)common-lisp.net> + + * slime.el (slime-remove-old-overlays): Remove overlays in all + slime buffers not only in the current buffer. + (slime-filter-buffers): New helper. + (slime-display-completion-list): Take the completed prefix as + additional argument to initialize completion-base-size. This is + apparently needed to make mouse-selection working. + (slime-maybe-complete-as-filename): Factor for common code in + slime-complete-symbol* and slime-simple-complete-symbol. + 2005-05-06 Alan Ruttenberg <alanr-l(a)mumble.net> * swank-openmcl.lisp specializer-name didn't handle structure-class which caused meta-. of methods specialized on

1 0

[slime-devel] error in source path parser
by tim＠tenkan.org 11 May '05

11 May '05

When compiling this file: 1 ;; don't delete the one (defmethod foo () (call-next-method)) with current SBCL and SLIME, I get this error: error while parsing arguments to DESTRUCTURING-BIND: invalid number of elements in () to satisfy lambda list ((SWANK-BACKEND::START . SWANK-BACKEND::END)): exactly 1 expected, but 0 found [Condition of type SB-KERNEL::ARG-COUNT-ERROR] This is the first bit of the backtrace: Backtrace: 0: (SWANK-BACKEND::SOURCE-PATH-SOURCE-POSITION (0) 1 #<HASH-TABLE :TEST EQ :COUNT 0 {C3C99C9}>) Locals: SB-DEBUG::ARG-0 = (0) SB-DEBUG::ARG-1 = 1 SB-DEBUG::ARG-2 = #<HASH-TABLE :TEST EQ :COUNT 0 {C3C99C9}> [No catch-tags] 1: (SB-DEBUG::TRACE-CALL #<SB-DEBUG::TRACE-INFO SWANK-BACKEND::SOURCE-PATH-SOURCE-POSITION>) 2: (SB-INT:EVAL-IN-LEXENV (SB-DEBUG::TRACE-CALL (QUOTE #<SB-DEBUG::TRACE-INFO SWANK-BACKEND::SOURCE-PATH-SOURCE-POSITION>)) #<NULL-LEXENV>) 3: (SB-IMPL::ENCAPSULATION (0) 1 #<HASH-TABLE :TEST EQ :COUNT 0 {C3C99C9}>) 4: (SWANK-BACKEND::SOURCE-PATH-FILE-POSITION (0) #P"/tmp/foo.lisp") 5: (SWANK-BACKEND::LOCATE-COMPILER-NOTE #P"/tmp/foo.lisp" (0) " 1") 6: (SWANK-BACKEND::COMPILER-NOTE-LOCATION #<SB-C::COMPILER-ERROR-CONTEXT >) 7: (SWANK-BACKEND::SIGNAL-COMPILER-CONDITION #<CODE-DELETION-NOTE {C3AFE59}> #<SB-C::COMPILER-ERROR-CONTEXT >) 8: (SWANK-BACKEND::HANDLE-NOTIFICATION-CONDITION #<CODE-DELETION-NOTE {C3AFE59}>) 9: (SIGNAL #<CODE-DELETION-NOTE {C3AFE59}>) ... Nearest I can figure, SBCL is generating a code deletion note, and the location is that 1 at the top of the file. In order to find the note in the source file, slime reads the appropriate toplevel form using a special readtable that records the start and end locations of each subform in a hashtable called a source-map. It then looks up the location of the innermost, leftmost subform in the source-map. I think the problem is that the source location recording readtable only starts recording when it sees a macro character like #\(. That's reasonable, because it splits up the subforms. However, #\1 is not a macro character, so nothing is recorded, and the source-map ends up empty. This is the best fix I could come up with. It's not so hot because the location of the note is not precise, and for some reason that I haven't understood yet, emacs sometimes doesn't underline the note at all. But at least the error is gone, and it doesn't seem to break anything that already worked. This does seem like an obscure case. I encountered it because of a stray character in a mcclim source file. Thanks a ton for slime! -- -Tim

2 1

[slime-devel] slime repl prompt's intangible property
by Hertog, Pieter den 09 May '05

09 May '05

Hi, First of all, thanks for Slime! I am using it to take my first baby-steps into the wonderful Lisp. At the moment I have a small problem with symbol completion at the repl prompt and I was wondering whether I am the only one with the problem or just the only one without an elegant solution (not unlikely). Example: CL-USER> *f <TAB> -> choose *features* and hit RETURN will get me an 'args-out-of-range' error. The error seems due to the fact that hitting return in the emacs completions buffer ends up calling simple.el's `choose-completion-delete-max-match' whose code doesn't cater for the buffer containing text with text property `intangible' nearby the symbol to be completed. That is, it uses (forward-char 1) and assumes point is moved forward 1 char, which is not true when point is in slime's repl prompt. My current solution (other than using slime-fuzzy-complete-symbol) is to: (add-hook 'slime-repl-mode-hook (lambda () (set (make-local-variable 'inhibit-point-motion-hooks) t))) in my .emacs file. I was wondering if there is a better solution. thanks in advance, -- pieter

1 0

[slime-devel] Daily ChangeLog diff
by lgorrie＠common-lisp.net 06 May '05

06 May '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.681 slime/ChangeLog:1.683 --- slime/ChangeLog:1.681 Thu May 5 01:15:43 2005 +++ slime/ChangeLog Fri May 6 18:34:00 2005 @@ -1,3 +1,13 @@ +2005-05-06 Alan Ruttenberg <alanr-l(a)mumble.net> + * swank-openmcl.lisp specializer-name didn't handle + structure-class which caused meta-. of methods specialized on + defstruct arguments to fail. + +2005-05-06 Helmut Eller <heller(a)common-lisp.net> + + * swank-cmucl.lisp (post-gc-hook): Include the elapsed time and + the size distribution. + 2005-05-05 Edi Weitz <edi(a)agharta.de> * swank-lispworks.lisp (unmangle-unfun): New function to convert

1 0

[slime-devel] proposed customization mechanism for repl behavior
by Alan Ruttenberg 06 May '05

06 May '05

For some work I am doing I wanted to customize the behavior of the repl so that some forms wouldn't be evaluated, but instead handled in a different way. Below is a proposed hook for doing so. Unless someone can think of why this is a bad idea, or finds a bug, I'll update the cvs sources. This would be a change to swank.lisp. It also fixes a behavior I found objectionable, namely that when a form caused an error, and you aborted, *, **, *** and friends were changed. (in-package :swank) (defvar *slime-repl-advance-history* nil "In the dynamic scope of a single form typed at the repl, set to nil to prevent the repl from advancing the history - * ** *** etc.") (defvar *slime-repl-suppress-output* nil "In the dynamic scope of a single form typed at the repl, set to nil to prevent the repl from printing the result of the evalation.") (defvar *slime-repl-eval-hook-pass* (gensym "PASS") "Token to indicate that a repl hook declines to evaluate the form") (defvar *slime-repl-eval-hooks* nil "A list of functions. When the repl is about to eval a form, first try running each of these hooks. The first hook which returns a value which is not *slime-repl-eval-hook-pass* is considered a replacement for calling eval. If there are no hooks, or all pass, then eval is used.") (defslimefun listener-eval (string) (clear-user-input) (with-buffer-syntax () (let ((*slime-repl-suppress-output* :unset) (*slime-repl-advance-history* :unset)) (multiple-value-bind (values last-form) (eval-region string t) (unless (or (and (eq values nil) (eq last-form nil)) (eq *slime-repl-advance-history* nil)) (setq *** ** ** * * (car values) /// // // / / values)) (setq +++ ++ ++ + + last-form) (if (eq *slime-repl-suppress-output* t) "" (cond ((null values) "; No value") (t (format nil "~{~S~^~%~}" values)))))))) (defun eval-region (string &optional package-update-p) "Evaluate STRING and return the result. If PACKAGE-UPDATE-P is non-nil, and evaluation causes a package change, then send Emacs an update." (unwind-protect (with-input-from-string (stream string) (let (- values) (loop (let ((form (read stream nil stream))) (when (eq form stream) (fresh-line) (force-output) (return (values values -))) (setq - form) (if *slime-repl-eval-hooks* (loop for hook in *slime-repl-eval-hooks* for res = (multiple-value-list (funcall hook form)) until (not (eq (car res) *slime-repl-eval-hook-pass*)) finally (when (eq (car res) *slime-repl-eval-hook-pass*) (setq values (multiple-value-list (eval form))))) (setq values (multiple-value-list (eval form)))) (force-output))))) (when (and package-update-p (not (eq *package* *buffer-package*))) (send-to-emacs (list :new-package (package-name *package*) (package-string-for-prompt *package*)))))) ;; example hook - if you type (setq foo *) then nothing is printed, and ;; the history is not advanced. (defun setq-no-print-repl-hook(form) (if (and (listp form) (listp (cdr form)) (eq (car form) 'setq) (eq (third form) '*)) (progn (setq *slime-repl-suppress-output* t) (setq *slime-repl-advance-history* nil) (eval form)) *slime-repl-eval-hook-pass*))

1 0

[slime-devel] Daily ChangeLog diff
by lgorrie＠common-lisp.net 05 May '05

05 May '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.680 slime/ChangeLog:1.681 --- slime/ChangeLog:1.680 Wed May 4 10:52:10 2005 +++ slime/ChangeLog Thu May 5 01:15:43 2005 @@ -1,3 +1,9 @@ +2005-05-05 Edi Weitz <edi(a)agharta.de> + + * swank-lispworks.lisp (unmangle-unfun): New function to convert + strange symbols in SETF package to SETF function names. + (signal-undefined-functions): Use it. + 2005-05-04 Edi Weitz <edi(a)agharta.de> * swank-lispworks.lisp (call-with-compilation-hooks): Provide

1 0

[slime-devel] #;
by Harald Hanche-Olsen 05 May '05

05 May '05

This is perhaps really a problem with forward-sexp, not so much a slime issue, but I'll bring it up here anyway: I recently played around with creating a reader macro for the #; combination. But then I found that trying for example (foo #;bar) then I would only get [input not complete] in the minibuffer. Perhaps forward-sexp should be taught that a semicolon after a sharpsign doesn't start a comment? This can get tricky if someone were to write #1#; of course. ... - Harald

3 3