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

[slime-devel] comma shortcut doesn't work always
by Edi Weitz 31 Jan '06

31 Jan '06

Another minor glitch that I encountered is that the comma shortcut in the REPL doesn't always work. I can consistently reproduce it (GNU Emacs 21.3.50 and also 21.3 release) like this: 1. Make sure point is at the beginning of a REPL input line. 2. Split Emacs frame into two windows, one of them being the REPL the other one containing something else. 3. Hide REPL window with C-x 0. 4. Now type M-x slime. 5. Type the comma. At this point I'm not asked for a shortcut command in the minibuffer but the comma is simply entered into the REPL instead. Anybody else seeing this? Cheers, Edi.

10 25

Re: [slime-devel] Re: CLISP SLIME implementation breaks in CVS
by Bill_Clementson＠peoplesoft.com 21 Jan '06

21 Jan '06

Luke Gorrie <luke(a)bluetail.com> writes: > Bill_Clementson(a)peoplesoft.com writes: > > > My previous SLIME installation was a CVS install from 4/18. I've just taken > > the latest CVS install and the CLISP SLIME implementation (under Windows) > > breaks. Here is the error: > > > > COERCE: #<MACRO #<COMPILED-CLOSURE SWANK::DEFSLIMEFUN>> cannot be coerced > > to type FUNCTION > > [Condition of type SIMPLE-TYPE-ERROR] > > I can reproduce this but I've no idea what is causing it. It /looks/ > like someone is trying to call defslimefun as a function rather than a > macro, but I don't see where it could happen -- the macro is declared > at the top of the only file that refers to it. > > I did fix a different but similar problem that I got under CLISP. It > seems like I had to swap the order of a couple of macros, one of which > expanded into into code that calls the other, but that surely can't be > the reason. > > > Backtrace: > > 0: EVAL frame for form (SWANK:CREATE-SWANK-SERVER 4007) > > Mine actually gives an empty backtrace (!). I fixed the Elisp-side to > handle that incase it helps someone more CLISP-savvy find the problem. Has anybody had any luck in finding the source of this problem? CLISP still breaks for me in the latest CVS. I have had a look at all of the DEFSLIMEFUN's that were modified since 4/18 (the previous CVS version that I had which was working ok with CLISP) and haven't found any obvious clues. Any suggestions on how I might debug this issue as it occurs at startup during the slime-connect processing in Emacs (after CLISP has started up successfully)? - Bill

5 6

[slime-devel] Comment indentation in newer Emacsen
by Edi Weitz 03 Jul '05

03 Jul '05

Dumb question number two for today: I've recently switched to a CVS build (circa end of January) of GNU Emacs on Windows. Now, if I have a function like this in a lisp mode buffer (defun foo () "This is a very very very very very very very very very very very very long comment line." (bar x)) and press M-q within the comment string the result looks like so: (defun foo () "This is a very very very very very very very very very very very very long comment line." (bar x)) However, in 21.3 the result looked like this (defun foo () "This is a very very very very very very very very very very very very long comment line." (bar x)) which is what I prefer. Is this a bug or can the behaviour be changed with some setting that I'm missing? Thanks, Edi.

3 3

[slime-devel] debian package uploaded
by Peter Van Eynde 03 May '05

03 May '05

|To: pvaneynd(a)debian.org |Subject: Processing of slime_cvs-20050429-1_i386.changes |From: Archive Administrator <katie(a)ftp-master.debian.org> |Date: Fri, 29 Apr 2005 03:12:48 -0400 | |slime_cvs-20050429-1_i386.changes uploaded successfully to localhost |along with the files: | slime_cvs-20050429-1.dsc | slime_cvs-20050429.orig.tar.gz | slime_cvs-20050429-1.diff.gz | slime_cvs-20050429-1_all.deb | |Greetings, | | Your Debian queue daemon The packages are based on the work on Sean Champ <schamp(a)commonwerx.org> that I modified to reflect the fact that the only place to be is HEAD. It will be for some time in the NEW queue and then will appear in debian unstable, until then people can download the packages from http://people.debian.org/~pvaneynd/slime/. If Sean wants to maintain it, he is welcome to do so, and I will gladly sponsor him. I regret having to kidnap the package, but people have been waiting for slime package far too long. Fire at will! Groetjes, Peter -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson|

2 1

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

29 Apr '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.674 slime/ChangeLog:1.675 --- slime/ChangeLog:1.674 Wed Apr 27 16:54:41 2005 +++ slime/ChangeLog Fri Apr 29 01:32:29 2005 @@ -1,3 +1,25 @@ +2005-04-29 Dan Pierson <dlp(a)itasoftware.com> + + * slime.el (slime-parse-context): Fix method parsing so that + pressing, say, C-c C-t when point is on a '-' in a symbol name + won't break. + (slime-browser-map): New variable. Add support for the common 'q' + keystroke to quit out of the xref. + (slime-fetch-browsable-xrefs): New function. Remove the (FLET ...) + entries which appear on at least CMUCL. I don't believe you can + actually expand them on any current implementation and they just + mess up the browse tree. Use only the method name when looking + up (METHOD ...) entries on CMUCL. This really shouldn't be here, + but I can't see how to avoid the error thrown by swank:xref. + (slime-expand-xrefs): Use it. + (slime-call-with-browser-setup): Initialize slime-buffer-package + properly. Previously, lisp-mode was called after setting it, but + lisp-mode clears all local variables, use lisp-mode-variables + instead. + + * swank-cmucl.lisp (toggle-trace): Be more carefully when tracing + methods: try both (METHOD ...) and (PCL:FAST-METHOD ...). + 2005-04-27 Helmut Eller <heller(a)common-lisp.net> * swank-cmucl.lisp (+header-type-symbols+): Drop the third arg to

1 0

[slime-devel] Slime bug in macro handling
by Will M. Farr 29 Apr '05

29 Apr '05

Hello all, I have just encountered a bug while using SBCL 0.9.0.1 or OpenMCL 0.14.3 and the latest CVS slime (as of 10 minutes ago) on my PowerBook G4 with Mac OS 10.3.9. Evaluating the following commands using C-M-x (except for the in-package, which I have to type at the REPL) works fine: (defpackage :fast-math (:use :cl)) (in-package :fast-math) (defmacro f+ (&rest xs) `(the double-float (+ ,@(map 'list #'(lambda (x) `(the double-float ,x)) xs)))) (defmacro f- (&rest xs) `(the double-float (- ,@(map 'list #'(lambda (x) `(the double-float ,x)) xs)))) (defmacro f* (&rest xs) `(the double-float (* ,@(map 'list #'(lambda (x) `(the double-float ,x)) xs)))) (defmacro f/ (&rest xs) `(the double-float (/ ,@(map 'list #'(lambda (x) `(the double-float ,x)) xs)))) (f* 10.d0 30.d0) (f+ 10.d0 30.d0) (f- 10.d0 30.d0) (f/ 30.d0 10.d0) However, if I then type (f* 10.d0 30.d0) at the REPL, I get an error involving the "undefined function f*". Even after this, if I then evaluate (f* 10.d0 30.d0) using C-M-x it works fine! I notice that typing (f* ...) in the REPL doesn't bring up the autocomplete information from SLIME, while typing it in a different slime buffer does bring up the note (f* &rest xs). The problem doesn't occur if the macros are defined in the cl-user package. I don't really know anything about the internal workings of slime or I'd post a fix, too. Sorry. Let me know if there's more information I can offer about the problem. Thanks! Will Farr

3 3

[slime-devel] New trace fixes for CMUCL
by Dan Pierson 28 Apr '05

28 Apr '05

Here's a patch to more carefully try both (METHOD ...) and (PCL:FAST-METHOD ...) when tracing methods on CMUCL. Dan Pierson Index: swank-cmucl.lisp =================================================================== RCS file: /project/slime/cvsroot/slime/swank-cmucl.lisp,v retrieving revision 1.143 diff -u -r1.143 swank-cmucl.lisp --- swank-cmucl.lisp 3 Apr 2005 23:27:41 -0000 1.143 +++ swank-cmucl.lisp 28 Apr 2005 15:11:12 -0000 @@ -2136,9 +2136,13 @@ (let ((name (second spec))) (toggle-trace-aux name :methods name))) ((:defmethod) - (toggle-trace-aux `(method ,(cdr spec))) - ;; Man, is this ugly - (toggle-trace-aux `(pcl::fast-method ,(cdr spec)))) + (cond ((fboundp `(method ,@(cdr spec))) + (toggle-trace-aux `(method ,(cdr spec)))) + ;; Man, is this ugly + ((fboundp `(pcl::fast-method ,@(cdr spec))) + (toggle-trace-aux `(pcl::fast-method ,@(cdr spec)))) + (t + (error 'undefined-function :name (cdr spec))))) ((:call) (destructuring-bind (caller callee) (cdr spec) (toggle-trace-aux (process-fspec callee)

2 1

[slime-devel] Fixes for slime-browse-xrefs on cmucl
by Dan Pierson 28 Apr '05

28 Apr '05

I've made a couple of fixes to slime-browse-xrefs: 1. Add support for the common 'q' keystroke to quit out of the xref. 2. Remove the (FLET ...) entries which appear on at least CMUCL. I don't believe you can actually expand them on any current implementation and they just mess up the browse tree. 3. Hack swank:xref to look up (METHOD ...) entries on CMUCL. This really shouldn't be here, but I can't see how to put it in swank-cmucl.lisp and avoid the error thrown by swank:xref. 4. Fix slime-parse-context so that pressing, say, C-cC-t when point is on a '-' in a symbol name won't break. (This is part of a CMUCL patch for the new trace which will appear in my next post.) Dan Pierson Index: swank.lisp =================================================================== RCS file: /project/slime/cvsroot/slime/swank.lisp,v retrieving revision 1.295 diff -u -r1.295 swank.lisp --- swank.lisp 21 Apr 2005 07:39:12 -0000 1.295 +++ swank.lisp 28 Apr 2005 15:10:45 -0000 @@ -3038,18 +3038,29 @@ errors)))))))) (defslimefun xref (type symbol-name) - (let ((symbol (parse-symbol-or-lose symbol-name *buffer-package*))) - (group-xrefs - (ecase type - (:calls (who-calls symbol)) - (:calls-who (calls-who symbol)) - (:references (who-references symbol)) - (:binds (who-binds symbol)) - (:sets (who-sets symbol)) - (:macroexpands (who-macroexpands symbol)) - (:specializes (who-specializes symbol)) - (:callers (list-callers symbol)) - (:callees (list-callees symbol)))))) + ;; Minimal attempts to retrieve something when passed "(METHOD FOO ...)". + ;; Return nil when passed something incomprehensible like "(FLET FOO ...)". + ;;---*** This is way too CMUCL-specific for the front end, but I have to + ;;---*** do something before parse-symbol-or-lose looses. + (let* ((spec (from-string symbol-name)) + (symbol-string nil)) + (cond ((and (listp spec) (string-equal (string (first spec)) "METHOD")) + (setq symbol-string (string (second spec)))) + ((not (listp spec)) + (setq symbol-string symbol-name))) + (when symbol-string + (let ((symbol (parse-symbol-or-lose symbol-string *buffer-package*))) + (group-xrefs + (ecase type + (:calls (who-calls symbol)) + (:calls-who (calls-who symbol)) + (:references (who-references symbol)) + (:binds (who-binds symbol)) + (:sets (who-sets symbol)) + (:macroexpands (who-macroexpands symbol)) + (:specializes (who-specializes symbol)) + (:callers (list-callers symbol)) + (:callees (list-callees symbol)))))))) ;;;; Inspecting Index: slime.el =================================================================== RCS file: /project/slime/cvsroot/slime/slime.el,v retrieving revision 1.484 diff -u -r1.484 slime.el --- slime.el 18 Apr 2005 19:23:40 -0000 1.484 +++ slime.el 28 Apr 2005 15:10:48 -0000 @@ -5587,7 +5587,7 @@ (backward-up-list 1) (slime-parse-context `(setf ,name))) ((slime-in-expression-p '(defmethod *)) - (unless (looking-at "\\>\\|\\s ") + (unless (looking-at "\\s ") (forward-sexp 1)) ; skip over the methodname (let (qualifiers arglist) (loop for e = (read (current-buffer)) @@ -7485,6 +7485,14 @@ :dynargs 'slime-expand-class-node :has-echildren t)))) +(defvar slime-browser-map nil + "Keymap for tree widget browsers") + +(unless slime-browser-map + (setq slime-browser-map (make-sparse-keymap)) + (set-keymap-parent slime-browser-map widget-keymap) + (define-key slime-browser-map "q" 'bury-buffer)) + (defun slime-call-with-browser-setup (buffer package title fn) (require 'tree-widget) (switch-to-buffer buffer) @@ -7495,9 +7503,9 @@ (funcall fn) (lisp-mode) (slime-mode t) - (use-local-map widget-keymap) + (use-local-map slime-browser-map) (widget-setup)) - + ;;;; Xref browser @@ -7510,6 +7518,9 @@ append specs))) (loop for (dspec . _) in specs + ;; We can't expand FLET references so they're useless + unless (string= "(FLET" (substring dspec 0 5)) + ;;---*** Need to find and remove duplicates collect `(tree-widget :tag ,dspec :xref-type ,type :dynargs slime-expand-xrefs

2 2

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

27 Apr '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.672 slime/ChangeLog:1.674 --- slime/ChangeLog:1.672 Thu Apr 21 14:07:42 2005 +++ slime/ChangeLog Wed Apr 27 16:54:41 2005 @@ -1,3 +1,8 @@ +2005-04-27 Helmut Eller <heller(a)common-lisp.net> + + * swank-cmucl.lisp (+header-type-symbols+): Drop the third arg to + apropos-list; it's no longer supported in recent CMUCLs. + 2005-04-21 Luke Gorrie <luke(a)synap.se> * swank.lisp (arglist-to-string): Rolled back the previous change

1 0

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

21 Apr '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.669 slime/ChangeLog:1.672 --- slime/ChangeLog:1.669 Wed Apr 20 19:27:52 2005 +++ slime/ChangeLog Thu Apr 21 14:07:42 2005 @@ -1,3 +1,8 @@ +2005-04-21 Luke Gorrie <luke(a)synap.se> + + * swank.lisp (arglist-to-string): Rolled back the previous change + because it interferred with values appearing in parameter lists. + 2005-04-20 Luke Gorrie <luke(a)synap.se> * swank.lisp (arglist-to-string): Bind *PRINT-ESCAPE* to NIL. This @@ -8,9 +13,6 @@ `linux_no_threads_p' alien variable to decide whether to use :SPAWN. From dan_b for compatibility with new SBCLs. -2005-04-19 heller <heller@xaital> - - * /project/slime/cvsroot/slime/PROBLEMS: Warn about old kernels. 2005-04-19 Helmut Eller <heller(a)common-lisp.net> * PROBLEMS: Warn about old kernels. @@ -1417,7 +1419,7 @@ * swank-cmucl.lisp (return-from-frame): Add it. -2004-10-11 Thomas Burdick <tfb(a)OCF.Berkeley.EDU> +2004-10-11 Thomas F. Burdick <tfb(a)OCF.Berkeley.EDU> * swank-sbcl.lisp (function-definitions): Find compiler macros, too. (find-defintions, compiler-definitions)

1 0

[slime-devel] Any word on a 1.1 release?
by Peter Seibel 21 Apr '05

21 Apr '05

So I'm lagging behind my original plan vis a vis the Practical Common Lisp Lispbox distribution. (I've got preliminary versions of OS X and GNU/Linux Lispboxes up.) So now that it's mid-April is there any chance of an official 1.1 release of SLIME. To date I've been making my own "releases" out of CVS HEAD but it'd be nice to have an official one. -Peter -- Peter Seibel peter(a)gigamonkeys.com Lisp is the red pill. -- John Fraser, comp.lang.lisp

5 12

[slime-devel] Stepping in SBCL
by Svein Ove Aas 21 Apr '05

21 Apr '05

As you may have noticed, single-stepping using the step macro doesn't work with SBCL. [1] After some poking around, I figured out that the cause is a missing handler-bind, and is appaarently easily fixable - just insert the following code. (handler-bind ((sb-impl::step-condition #'sb-impl::invoke-stepper)) <code leading to a (step) form>) My problem is that I can't decide where to put it. The call stack for code run in the REPL seems to only include functions defined in swank.lisp, which is presumably the wrong place to put implementation-dependent code. What should I do?

2 1

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

20 Apr '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.667 slime/ChangeLog:1.669 --- slime/ChangeLog:1.667 Tue Apr 19 22:24:49 2005 +++ slime/ChangeLog Wed Apr 20 19:27:52 2005 @@ -1,3 +1,13 @@ +2005-04-20 Luke Gorrie <luke(a)synap.se> + + * swank.lisp (arglist-to-string): Bind *PRINT-ESCAPE* to NIL. This + way symbols in arglists are printed as with PRINC, i.e. without + package qualifier. + + * swank-sbcl.lisp (preferred-communication-style): Use + `linux_no_threads_p' alien variable to decide whether to use + :SPAWN. From dan_b for compatibility with new SBCLs. + 2005-04-19 heller <heller@xaital> * /project/slime/cvsroot/slime/PROBLEMS: Warn about old kernels.

1 0

[slime-devel] Re: Slime and :sb-futex on recent CVS SBCLs
by Luke Gorrie 20 Apr '05

20 Apr '05

Vincent Arkesteijn <vincent(a)arkesteijn.net> writes: > Doesn't work for me. It looks like you've added a new function > communication-style, which never gets called. Changing the existing > function preferred-communication-style does work for me (on 2.4 both > with and without NPTL). See attached patch. Wow :-) thanks for catching that!

1 0

[slime-devel] Re: [Sbcl-devel] Slime and :sb-futex on recent CVS SBCLs
by dan＠telent.net 20 Apr '05

20 Apr '05

This isn't just about CVS SBCL; SB-FUTEX was removed last month before the 0.8.21 release On Tue, Apr 19, 2005 at 01:56:21PM +0200, Vincent Arkesteijn wrote: > A somewhat related problem, which will be uncovered by fixing the > one that Andreas describes, surfaces when running SLIME+SBCL on > a non-NPTL 2.4 kernel. :sb-thread is still on *features*, so > swank:*communication-style* will be set to :spawn, but calling > make-thread will then fail. Not nice. > > Possible solutions: > 1) Remove :sb-thread from *features* when running on a non-NPTL > kernel. I think this (and the consequently necessary changes to the fasl compatibility checker) is probably TRT, but not this close to a release. > 2) Add some function or variable to SBCL that can be used to check > whether threads actually work, and change SLIME to use that. * (defun communication-style () (if (and (member :sb-thread *features*) (not (sb-alien:extern-alien "linux_no_threads_p" sb-alien:boolean))) :spawn :fd-handler)) COMMUNICATION-STYLE * (communication-style) :SPAWN ... but note that this uses implementation-internal stuff and is not guaranteed to stay working. As the useful working life of any SLIME version on SBCL rarely exceeds three months anyway, that might not be such a big deal -dan

3 2

[slime-devel] Difficulty connecting to external process
by Dan Knapp 20 Apr '05

20 Apr '05

Much like in the recent thread on ssh, I'm trying to use Slime by connecting to a running Lisp. In theory, this ought to be simpler, because I'm not using ssh for it. I am not having much luck. I'm using the latest CVS version of Slime (just ran an update and repeated my test); OpenMCL 1.14.3; and the Emacs version: GNU Emacs 21.3.50.1 (powerpc-apple-darwin7.3.0) of 2004-05-08 on iBook.local In the host process, I load Slime through asdf, then I start it by invoking (setq swank:*use-dedicated-output-stream* nil) (swank:create-server :port 9090 :dont-close t :style nil) The *use-dedicated-output-stream* is there because an old thread on this list advised it. I have also tried without the :style parameter, not that that should have any relevance. Then in Emacs, I do M-x slime-connect RET 127.0.0.1 RET 9090 RET. Emacs says this: Connecting to Swank on port 9090.. net-read error: (end-of-file) error in process-filter: byte-code: PANIC! error in process-filter: PANIC! Lisp says this (I have it set up to dump into syslog): ;; Connection to Emacs lost. ;; [Short read: length=3158064 pos=58] If I try to connect again, I get the same error messages on both ends, so at least I know the loop isn't falling through... Both processes happen to be on the same computer, but are using different copies of the same version of Slime (one of them is inside a .app bundle...), in case that's relevant. Please advise? -- Dan Knapp

2 2

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

19 Apr '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.666 slime/ChangeLog:1.667 --- slime/ChangeLog:1.666 Mon Apr 18 21:39:12 2005 +++ slime/ChangeLog Tue Apr 19 22:24:49 2005 @@ -1,3 +1,15 @@ +2005-04-19 heller <heller@xaital> + + * /project/slime/cvsroot/slime/PROBLEMS: Warn about old kernels. +2005-04-19 Helmut Eller <heller(a)common-lisp.net> + + * PROBLEMS: Warn about old kernels. + + * swank-backend.lisp: Fix some typos. + + * swank-sbcl.lisp (preferred-communication-style): Don't test for + sb-futex, it has lost its meaning in 0.8.21. + 2005-04-18 Helmut Eller <heller(a)common-lisp.net> * slime.el (inferior-lisp-program): Defvar it here, in case it is

1 0

[slime-devel] Re: Slime and :sb-futex on recent CVS SBCLs
by Christophe Rhodes 19 Apr '05

19 Apr '05

Andreas Fuchs <asf(a)boinkor.net> writes: > I'm not entirely sure which of SBCL or SLIME needs to be fixed. Either > SBCL should start including :sb-futex on its *feature* list again (or > some other feature saying that threads are non-broken on this lisp > build), or SLIME should stop checking for :sb-futex (which will break > on SBCLs older than 0.8.21). If it's possible given the time constraints and cvs tagging activity, I'd be happy if the preferred-communication-style checked only :sb-thread, and if the slime release notes for 1.2 required an sbcl of 0.8.21 or later. Would that be OK with you guys? Sorry for the eleventh-hour (or even later) change request... Cheers, Christophe

4 5

[slime-devel] Slime and :sb-futex on recent CVS SBCLs
by Andreas Fuchs 18 Apr '05

18 Apr '05

Hi, current SLIME CVS's swank-sbcl.lisp, function preferred-communication-style contains an assumption that is no longer true about recent SBCLs. Since 0.8.21, usefully threaded SBCL builds don't include :sb-futex in their feature list any more. Still, Swank checks for the presence of :sb-futex on the *features* list before adding the :spawn communication-style. I'm not entirely sure which of SBCL or SLIME needs to be fixed. Either SBCL should start including :sb-futex on its *feature* list again (or some other feature saying that threads are non-broken on this lisp build), or SLIME should stop checking for :sb-futex (which will break on SBCLs older than 0.8.21). Here's the (proof of concept) patch to make slime choose the right communication-style for 0.8.21 or later (but not earlier. I know no practical way to find out if we're running in SBCL version >=X): --- swank-sbcl.lisp 9 Apr 2005 07:07:00 -0000 1.129 +++ swank-sbcl.lisp 18 Apr 2005 22:27:45 -0000 @@ -42,8 +42,7 @@ ;;; TCP Server (defimplementation preferred-communication-style () - (if (and (sb-int:featurep :sb-thread) - (sb-int:featurep :sb-futex)) + (if (and (sb-int:featurep :sb-thread)) :spawn :fd-handler)) Cheers, -- Andreas Fuchs, <asf(a)boinkor.net>, asf(a)jabber.at, antifuchs

1 0

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

18 Apr '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.664 slime/ChangeLog:1.666 --- slime/ChangeLog:1.664 Thu Apr 14 17:41:17 2005 +++ slime/ChangeLog Mon Apr 18 21:39:12 2005 @@ -1,3 +1,20 @@ +2005-04-18 Helmut Eller <heller(a)common-lisp.net> + + * slime.el (inferior-lisp-program): Defvar it here, in case it is + not defined in loaddefs and inf-lisp is not loaded. (That's the + case in XEmacs.) + + * mkdist.sh: update version number. + + * doc/slime.texi: Update version numbers for SBCL and ACL. + +2005-04-17 Peter Seibel <peter(a)gigamonkeys.com> + + * swank-loader.lisp (*implementation-features*): Added features + for GCL and ECL ... + (lisp-version-string): ... and code to compute version + string. (Supplied by someone who's email I've misplaced.) + 2005-04-14 Helmut Eller <heller(a)common-lisp.net> * slime.el (slime-selector): Discard input after sleeping.

1 0

[slime-devel] custom indentation of macros
by Chris Capel 18 Apr '05

18 Apr '05

I think there should be a way to specify, in a source file for a CL macro, how SLIME should indent the macro. There is already a robust and capable, if under-documented, way to specify the indentation for arbitrary forms in cl-indent.el, and so it would be nice to wrap this up in a nice way and give it some SLIME support. My idea is to have SWANK look for a property on the CL symbols, custom-indent-spec, that, if present, has a list (or perhaps a string that can be read as a list in Emacs) that can be assigned to the common-lisp-indent-function property on the Emacs symbol to modify the indentation. It'd be nice to have some documentation for the format of this list, too. Anyway, here's the sort of thing I think would work. (setf (get 'defclass-ext 'custom-indent-spec) '((6 4 defclass-slots-options-indent) (defun defclass-slots-options-indent (path state indent-point sexp-column normal-indent) (if (> (length path) 1) (1+ sexp-column) 2)))) The above form is Common Lisp and contained in the source file, either after the macro definition or somewhere else. The quoted list (caddr of the setf form) is written in Emacs lisp. (Symbol case issues? Should everything in the Emacs-destined form be downcased by SLIME or something?) The first form in that list is the value the common-lisp-indent-function property on the Emacs symbol gets set to. The subsequent forms are function definitions that can be used in the first. My example would allow the following indentation: (defclass-ext some-class () (slot-a :a :ia slot-b :a (:if 2))) There should be some attention to name collision across packages--Emacs lisp symbols don't have packages, so two different CL authors with a macro with the same name and custom indentation could potentially collide in unpleasant ways. I think what has to happen is that SLIME adds and removes the common-lisp-indent-function property on Emacs symbols every time a package is switched, based on what is set up for the inferior lisp's symbols in the new package. Is this last bit feasible? Perhaps SLIME could check to make sure the Emacs symbols have been set up with the correct plists before every indentation, resetting them all if the package has changed since then. Other ideas? Chris Capel

1 0

[slime-devel] Release?
by Helmut Eller 17 Apr '05

17 Apr '05

Is there anything left that we should fix before the release? If not, can we release the baby in the next few days? I used 1.2 as version number in the documentation, because there was already a 1.1 CVS tag (from November, before the Unicode changes). I hope that's ok with everybody. Helmut.

2 1

[slime-devel] Double newlines sent to clisp on user input
by Alex Farran 17 Apr '05

17 Apr '05

I'm running through Practical Common Lisp using SLIME + clisp on slackware, and I've run into a problem in chapter 3 with the prompt-for-cd function: (defun prompt-for-cd () (make-cd (prompt-read "Title") (prompt-read "Artist") (or (parse-integer (prompt-read "Rating") :junk-allowed t)) (y-or-n-p "Ripped [y/n]: "))) If I run clisp in a terminal it works as expected: [6]> (prompt-for-cd) Title: La Peste Artist: Alabama 3 Rating: 5 Ripped [y/n]: (y/n) y (:TITLE "La Peste" :ARTIST "Alabama 3" :RATING 5 :RIPPED T) But in SLIME this happens: CL-USER> (prompt-for-cd) Title: La Peste Artist: Rating: 5 Ripped [y/n]: (y/n) Please answer with y or n : y (:TITLE "La Peste" :ARTIST "" :RATING 5 :RIPPED T) It seems that for every one newline I enter two are sent. Is there something I can configure to fix it? I've tried running SLIME with my existing emacs and clisp and also with the versions compiled as part of the lisp-in-a-box package. I get the same problem either way. Alex

2 2

[slime-devel] selective macroexpansion patch
by Chris Capel 16 Apr '05

16 Apr '05

I have a patch and new file that implements a few functions that allow the selective expansion of subforms. I have the beginnings of a new mode, but my very limited familiarity with Emacs/SLIME programming ensures that it's almost useless. I'm hoping the improvements will be obvious and trivial to make this more usable. I'm kind of puzzled about why my returned forms are printing out with every symbol qualified by its package. Also, the new function slime-macroexpand-expand-subform should probably make the expansion be undoable with one undo, instead of two. I don't have the keybindings set up for the new mode, and slime-mode could probably use a key and menu entry to open the buffer. swank-loader.lisp will need to be modified appropriately. I wasn't sure what to do here, as swank-source-path-parser.lisp was only loaded for SBCL and CMUCL. Is it really that unportable? I guess this is a good first stab. I might look at it some more, see if I can clean it up some, if no one else does. Chris Capel New file: swank-expander.lisp ;;;; Selective macro expander ;;; These are some macros that will macroexpand a specific subform of a form ;;; once (destructively), respecting macros locally established by macrolets and ;;; symbol-macrolets. ;;; There are currently some limitations. swank-source-path-parser.lisp doesn't ;;; currently return the path of the specific atom the cursor is on--only the ;;; list. So it's not possible to expand symbol-macros until this situation is ;;; improved. Also, forms that expand into macrolets that are not expanded ;;; before expanding the subform will not respect the macrolet. ;;; For example, with ;;; ;;; (defmacro foo (&body body) ;;; `(macrolet ((bar (x) `(y ,x))) ;;; ,@body))) ;;; ;;; expanding the subform in ;;; ;;; (foo (bar xyz)) ;;; ;;; will not be effective unless FOO is added to ;;; *macroexpand-macro-binding-form* (in-package :swank-backend) (defparameter *macroexpand-macro-binding-form* '((macrolet 2) (symbol-macrolet 2)) "This is a specification for forms that are expected to expand into forms that bind symbols to macros. Each element of the list contains, first, the name of the macro, and second, the number of elements (including the name) to keep before replacing the rest with the specific form to be expanded.") (defmacro expand (form &environment e) "Return a form that represents a macroexpand-1'd FORM when evaluated in the current environment." (list 'quote (macroexpand-1 form e))) (defun get-list-to-expand (list source-path) "Get a sublist based on the source-path argument, but wrap it in all forms that bind macros, using *macroexpand-macro-binding-form*" (flet ((recurse () (get-list-to-expand (nth (car source-path) list) (cdr source-path)))) (if (null source-path) (list 'expand list) (let ((sym (find (car list) *macroexpand-macro-binding-form* :key #'car))) (if sym (append (subseq list 0 (cadr sym)) (list (recurse))) (recurse)))))) (defun nsubst-list (source substitution source-path) "Destructively replace the form in SOURCE at the give source path with SUBSTITUTION." (if (null source-path) substitution (progn (setf (nth (car source-path) source) (nsubst-list (nth (car source-path) source) substitution (cdr source-path))) source))) (defun subst-all-tree (tree obj-a obj-b &key (test #'equal)) "Non-destructively replace all instances of OBJ-A in TREE with OBJ-B (compared using TEST)." (mapcar (lambda (i) (if (consp i) (subst-all-tree i obj-a obj-b :test test) (if (funcall test obj-a i) obj-b i))) tree)) (defun expand-part (list source-path) "Expand, once, the form located at SOURCE-PATH and replace it with its expansion." (nsubst-list list (eval (get-list-to-expand list source-path)) source-path)) (defun expand-part-from-position (form-string position) (with-input-from-string (s form-string) (multiple-value-bind (list hash) (read-and-record-source-map s) (expand-part list (source-position-source-path position list hash))))) Index: slime.el =================================================================== RCS file: /project/slime/cvsroot/slime/slime.el,v retrieving revision 1.482 diff -u -r1.482 slime.el --- slime.el 9 Apr 2005 07:05:54 -0000 1.482 +++ slime.el 16 Apr 2005 04:54:28 -0000 @@ -6137,6 +6137,56 @@ "Display the recursively macro expanded sexp at point." (interactive) (slime-eval-macroexpand 'swank:swank-macroexpand-all)) + + +;;;; Selective macroexpansion + +(defvar slime-macroexpand-mode-map) + +(setq slime-macroexpand-mode-map (make-sparse-keymap)) +(set-keymap-parent slime-macroexpand-mode-map lisp-mode-map) + +(slime-define-keys slime-macroexpand-mode-map + ("\C-m" 'slime-macroexpand-expand-subform)) + +(defun slime-macroexpand-selective () + "Start a selective macroexpansion buffer with whatever's at the current +point." + (interactive) + (let ((string (slime-sexp-at-point)) + (buffer (get-buffer-create "*slime-macroexpand*"))) + (with-current-buffer buffer + (slime-macroexpand-mode) + (erase-buffer) + (pp (first (read-from-string string)) + buffer)))) + +(defun slime-macroexpand-expand-subform () + "In macroexpand mode, expand the currently selected subform." + (interactive) + (let ((i (point)) + (text (buffer-string))) + ;;how to make this erase and replacement a single operation? + (erase-buffer) + (let ((new-form (slime-eval `(swank-backend::expand-part-from-position ,text ,i)))) + ;;prints package qualifier on everything. Not very nice. + (pp new-form (current-buffer)) + (goto-char i)))) + +(defun slime-macroexpand-mode () + "Major mode for expanding parts of a form interactively. +\\{slime-macroexpand-mode-map}" + (interactive) + ;;need to set package somewhere... + (kill-all-local-variables) + (setq major-mode 'slime-macroexpand-mode) + (use-local-map slime-macroexpand-mode-map) + (lisp-mode-variables t) + (set (make-local-variable 'lisp-indent-function) + 'common-lisp-indent-function) + (setq font-lock-defaults nil) + (setq mode-name "Macroexpand") + (run-hooks 'slime-macroexpand-hook)) ;;;; Subprocess control Index: swank-source-path-parser.lisp =================================================================== RCS file: /project/slime/cvsroot/slime/swank-source-path-parser.lisp,v retrieving revision 1.13 diff -u -r1.13 swank-source-path-parser.lisp --- swank-source-path-parser.lisp 1 Apr 2005 13:59:48 -0000 1.13 +++ swank-source-path-parser.lisp 16 Apr 2005 04:54:29 -0000 @@ -111,3 +111,26 @@ finally (destructuring-bind ((start . end)) positions (return (values (1- start) end)))))) +(defun source-position-source-path (position form source-map + &optional parent-form) + "Return the source path of the form most tightly surrounding the given +position." + (print form) + (if (and (not (null form)) (listp form)) + (destructuring-bind ((start . end)) (gethash form source-map) + (if (or (< position start) (> position end)) + nil + (let ((sub-path + (find-if #'identity + (mapcar (lambda (sub-form) + (source-position-source-path + position sub-form source-map form)) + form)))) + (cond + ((and sub-path parent-form) + (cons (position form parent-form) sub-path)) + (sub-path sub-path) + (parent-form + (list (position form parent-form))) + (t nil))))) + nil)) Index: swank.lisp =================================================================== RCS file: /project/slime/cvsroot/slime/swank.lisp,v retrieving revision 1.293 diff -u -r1.293 swank.lisp --- swank.lisp 9 Apr 2005 07:07:46 -0000 1.293 +++ swank.lisp 16 Apr 2005 04:54:38 -0000 @@ -34,6 +34,7 @@ #:*swank-pprint-bindings* #:*default-worker-thread-bindings* #:*macroexpand-printer-bindings* + #:*macroexpand-macro-binding-forms* ;; These are re-exported directly from the backend: #:buffer-first-change #:frame-source-location-for-emacs

1 0

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

14 Apr '05

Index: slime/ChangeLog diff -u slime/ChangeLog:1.663 slime/ChangeLog:1.664 --- slime/ChangeLog:1.663 Sat Apr 9 09:08:21 2005 +++ slime/ChangeLog Thu Apr 14 17:41:17 2005 @@ -1,3 +1,7 @@ +2005-04-14 Helmut Eller <heller(a)common-lisp.net> + + * slime.el (slime-selector): Discard input after sleeping. + 2005-04-09 Helmut Eller <heller(a)common-lisp.net> * slime.el (sldb-get-buffer): Create a fresh buffer if there's no @@ -8,8 +12,8 @@ because they are potentially useful. * swank.lisp (with-io-redirection, with-connection) - (with-buffer-syntax): Implement macros with a `call-with' - functions to avoid some code bloat. + (with-buffer-syntax): Implement macros with `call-with' functions + to avoid some code bloat. (call-with-connection, maybe-call-with-io-redirection) (call-with-buffer-syntax): New functions. (interactive-eval): Use from-string instead of read-from-string to

1 0