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

[slime-devel] repl shortcut commands feature request
by Brian Downing 17 Jun '04

17 Jun '04

Continuing my attempts to spam slime-devel: I find the slime-repl comma shortcuts to be quite useful. However, it would be nice if when a comma shortcut was run, if a re-runable version of the command with its arguments could be put in the repl buffer and on the repl command history. That would seem make interacting with the repl a little bit nicer, as it would remove some of the discontinuity between lisp forms (you can see them in the repl buffer, and they can be called up with M-p) and repl commands (you can sometimes see their results in the repl buffer, and they cannot be called up with M-p.) I looked into doing this, but it wasn't immediately obvious to me how I'd accomplish it. (I was going to put the emacs form executed for the shortcut into the buffer prepended by a comma, much like you see the raw emacs forms when you use repeat-complex-command.) -bcd -- *** Brian Downing <bdowning at lavos dot net>

4 6

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

17 Jun '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.395 slime/ChangeLog:1.397 --- slime/ChangeLog:1.395 Tue Jun 15 17:13:48 2004 +++ slime/ChangeLog Wed Jun 16 15:05:27 2004 @@ -1,3 +1,50 @@ +2004-06-16 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * slime.el (slime-set-default-directory): Don't call + slime-repl-update-banner in Emacs 20. + (slime-show-source-location, slime-recenter-window): Use + set-window-start instead of recenter; this avoids flickering. + (sldb-list-locals): Don't forget about slime-current-thread in the + temporary buffer. (Fixes bug reported by Mike Beedle.) + (sldb-step): Re-enabled. The CMUCL backend has rudimentary support + for stepping. + + * swank.lisp (*readtable-alist*): Call backend function for + initialization. + (eval-for-emacs, guess-buffer-package): Signal a continuable error + if a package name was supplied but no such package exists. Not + sure if this is better than what we did before (i.e. silently use + the current package). + + * swank-cmucl.lisp (default-directory): Add implementation. + (sldb-step): Uncomment it and remove references to + *swank-debugger-condition*. + + * swank-backend.lisp (sldb-step, default-readtable-alist): New + backend functions. + (emacs-connected): Pass the redirected stream as argument, so that + the OpenMCL backend can add it to CCL::*AUTO-FLUSH-STREAMS*. + + * swank-sbcl.lisp (default-readtable-alist): Implement it. + + * swank-loader.lisp: Move readtable-alist initialization to + swank-sbcl.lisp. + + * swank-allegro.lisp (default-directory, call-with-syntax-hooks): + Add implementations as workarounds for ACL5 bugs. + +2004-06-16 Lawrence Mitchell <wence(a)gmx.li> + + * slime.el (slime-maybe-rearrange-inferior-lisp): Call + `generate-new-buffer-name' manually, rather than relying on the + UNIQUE argument to `rename-buffer' to do so. + +2004-06-16 Frederic Brunel <frederic.brunel(a)in-fusio.com> + + * slime.el (slime-startup-animation): Use defcustom to declare the + variable. + (slime-enable-startup-animation-p): Deleted. + 2004-06-16 Robert Lehr <bozzio(a)the-lehrs.com> * slime.el (slime-backend): This variable can now be set to an

1 0

[slime-devel] Re: Slime?
by Luke Gorrie 17 Jun '04

17 Jun '04

Hi Mike, Sorry about the wait, I put the mail aside while CVS was down. I'm CC'ing the mailing list now that it's back. "Mike Beedle" <beedlem(a)e-architects.com> writes: > Luke: > > Some quick feedback. Overall, SLIME is great. > > I like it much better over ILISP or ELI. > > Here are some comments, mostly on the debugger. (You > may already know some of these things.) > > 1. LINUX > > CMU 18e (Linux) > --------------- > (loaded as inferior lisp) > > 1. s, sldb-step does not work AND causes the connection to > be dropped I've disabled the step command in the Elisp end. It doesn't seem to be implemented by any backend, nor have an interface definition. (Anyone know the history?) > 2. v works on "swank" frames but it does not work for > the compiled code. This works for me. Can you post more details, e.g. a step by step example? The Swank frames aren't treated specially so possibly there is something funky about the other frames your v'ing. > l, d, i, t, r, etc. all work. > > Allegro 6.2 (Linux) > ------------------- > (loaded as inferior lisp) > > 1. s, sldb-step does not work AND causes the connection to > be dropped: > > [Symbol "SLDB-STEP" not found in the SWANK package. > [file position = 28]] (As above.) > 2. v does not work This feature isn't implemented in the ACL backend. > 3. l sort of hangs the process but Ctrl-g get it out of the > state. I don't have ACL installed to test this. Anyone? > 2. XP > > Clisp 2.33.1 (XP) > ----------------- > (loaded as inferior lisp) > > 1. s, sldb-step does not work but there are no sides effects > (as far as I can tell). (As above.) > 2. v, for jumping to the code on the debugger does not work The command isn't implemented in the CLISP backend. > Allegro 6.2 (XP) > ---------------- > (loaded through swank interface through ACL.) > > 1. s, sldb-step does not work AND causes the connection to > be dropped: > > [Symbol "SLDB-STEP" not found in the SWANK package. > [file position = 28]] > > 2. v, for jumping to the code on the debugger does not work These are as above. The last ones sound nasty: > 3. l on the debugger causes both Emacs and Allegro to hang, > but you can get out with Ctrl-g on Emacs and by > hitting RETRUN on Allegro (I think). > 4. Esc (Meta) - . does not work > 5. Get a "broken Allegro process" on exit from Emacs: > > ;; [eof encountered on stream > #<MULTIVALENT stream socket connected from localhost/4005 to > localhost/3809 @ #x206738f2>] Anyone able to investigate? I'm not wild about ACL's licensing mechanism and would prefer not to install it on my computer. Cheers, Luke

2 2

[slime-devel] SLIME, OpenMCL and aborting a process
by Gary King 16 Jun '04

16 Jun '04

Suppose I type (loop repeat 10000 do (sleep 0.5) (princ ".")) by "accident" in the listener. I'd like to stop this from running so that I can get back to work but don't see how? Also, no periods are printing. Where are they going? Are they filling up my computer like those little holes from a three hold punch? What if it runs out of space? (Sorry, long night). -- Gary Warren King, Lab Manager EKSL East, University of Massachusetts * 413 577 0176 All Windows users: Please be aware that there is a new unknown worm spreading itself via email. (Mac and Linux users don't have to read this email) -- typical computing support e-mail

5 4

[slime-devel] AllegroCL: Problems with COMPILE-FILE
by Edi Weitz 16 Jun '04

16 Jun '04

Hi! While loading and partly recompiling a system from within SLIME I came across the following error (in the *slime-repl* buffer): ; While compiling FILL-PAGE: Warning: Variable *LOG-NAME* is never used. Error: Received signal number 11 (Segmentation violation) [condition type: SYNCHRONOUS-OPERATING-SYSTEM-SIGNAL] Restart actions (select using :continue): 0: retry the compilation of /home/edi/prodata/html-fill.lisp 1: continue compiling /home/edi/prodata/html-fill.lisp but generate no output file 2: Retry performing #<ASDF:COMPILE-OP NIL @ #x7154e1a2> on #<ASDF:CL-SOURCE-FILE "html-fill" @ #x715878aa>. 3: Continue, treating #<ASDF:COMPILE-OP NIL @ #x7154e1a2> on #<ASDF:CL-SOURCE-FILE "html-fill" @ #x715878aa> as having been successful. 4: Abort SLIME compilation. 5: Abort handling SLIME request. 6: Abort entirely from this (lisp) process. [Current process: repl-thread] [1] CL-USER(1): CL-USER> It turned out I had forgotten a closing parenthesis at the end of one form. If I do the same thing from the command line it looks like this: ; While compiling FILL-PAGE: Warning: Variable *LOG-NAME* is never used. Error: eof encountered on stream #<EXCL:FILE-SIMPLE-STREAM #p"/home/edi/prodata/html-fill.lisp" for input pos 22368 @ #x722e3de2> starting at position 1712. [condition type: END-OF-FILE] Restart actions (select using :continue): 0: retry the compilation of /home/edi/prodata/html-fill.lisp 1: continue compiling /home/edi/prodata/html-fill.lisp but generate no output file 2: Retry performing #<ASDF:COMPILE-OP NIL @ #x7148e20a> on #<ASDF:CL-SOURCE-FILE "html-fill" @ #x71495c5a>. 3: Continue, treating #<ASDF:COMPILE-OP NIL @ #x7148e20a> on #<ASDF:CL-SOURCE-FILE "html-fill" @ #x71495c5a> as having been successful. 4: Return to Top Level (an "abort" restart). 5: Abort entirely from this (lisp) process. [changing package from "COMMON-LISP-USER" to "PRODATA"] [1] PRODATA(2): Any idea why SLIME behaves like this? [Allegro 7.0 beta on Linux, GNU Emacs 21.3, SLIME from CVS.] Cheers, Edi.

2 1

[slime-devel] Patch for startup animation
by Frederic Brunel 16 Jun '04

16 Jun '04

Hi, Here is a tiny patch concerning the startup animation. I've just added a customizable variable instead of having a «simple» variable to be setted. Actually, I tend to use only customizable variables, I think it's a great system. -- Frederic Brunel

2 1

[slime-devel] Patch for recent changes in CVS emacs.
by Lawrence Mitchell 16 Jun '04

16 Jun '04

I wondered today why doing C-u M-x slime wasn't prompting me to create a new inferior-lisp buffer. It turns out that a recentish change to generate-new-buffer-name in CVS emacs meant that rename-buffer wasn't actually renaming the inferior-lisp buffer. This patch fixes things (we generate the buffer-name semi-manually). 2004-06-11 Lawrence Mitchell <wence(a)gmx.li> * slime.el (slime-maybe-rearrange-inferior-lisp): Call `generate-new-buffer-name' manually, rather than relying on the UNIQUE argument to `rename-buffer' to do so. Index: slime.el =================================================================== RCS file: /project/slime/cvsroot/slime/slime.el,v retrieving revision 1.312 diff -u -r1.312 slime.el --- slime.el 10 Jun 2004 17:34:07 -0000 1.312 +++ slime.el 11 Jun 2004 22:16:08 -0000 @@ -1122,7 +1122,7 @@ "Offer to rename *inferior-lisp* so that another can be started." (when (y-or-n-p "Create an additional *inferior-lisp*? ") (with-current-buffer "*inferior-lisp*" - (rename-buffer (buffer-name) t) + (rename-buffer (generate-new-buffer-name (buffer-name))) t))) (defun slime-maybe-start-lisp () -- Lawrence Mitchell <wence(a)gmx.li>

2 1

[slime-devel] Fix for slime-reindent-defun when in repl
by Brian Downing 16 Jun '04

16 Jun '04

Here is a quick fix for slime-reindent-defun when used in the repl input area. As it was, (beginning-of-defun) tended to find the beginning of the repl buffer, which was suboptimal (especially for 20000 line repl buffers! :). There may be a more kosher way of finding out if you're in a repl buffer, but checking for the input mark seems to work. -bcd

1 0

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

16 Jun '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.393 slime/ChangeLog:1.395 --- slime/ChangeLog:1.393 Sat Jun 12 05:30:28 2004 +++ slime/ChangeLog Tue Jun 15 17:13:48 2004 @@ -1,3 +1,14 @@ +2004-06-16 Robert Lehr <bozzio(a)the-lehrs.com> + + * slime.el (slime-backend): This variable can now be set to an + absolute filename. + +2004-06-15 Luke Gorrie <luke(a)bluetail.com> + + * slime.el (slime-compile-file): Just prompt for saving the + current file instead of calling `save-some-buffers'. Based on a + patch from Brian Downing. + 2004-06-12 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> * wank-allegro.lisp (format-sldb-condition, condition-references):

1 0

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

13 Jun '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.391 slime/ChangeLog:1.393 --- slime/ChangeLog:1.391 Thu Jun 10 11:08:23 2004 +++ slime/ChangeLog Sat Jun 12 05:30:28 2004 @@ -1,3 +1,13 @@ +2004-06-12 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * wank-allegro.lisp (format-sldb-condition, condition-references): + Add workarounds for buggy no-applicable-method. + + * swank.lisp (parse-symbol, parse-package): Handle reader errors. + + * swank-openmcl.lisp (send, receive): Ensure that messages are + never nil. + 2004-06-10 Christophe Rhodes <csr21(a)cam.ac.uk> * swank-sbcl.lisp (call-with-syntax-hooks): Add hooks to fix

1 0

[slime-devel] Re: [Openmcl-devel] Problems with the SLIME debugger
by Alan Ruttenberg 12 Jun '04

12 Jun '04

I'm having a few problems as well and have been really wanting to sit down and document and try to untangle them. I think a couple of messages to slime-devel got lost in the down time. 1) I get this periodically in the inferior lisp, when running slime in openmcl. > Error in process control-thread(3): Undefined function :DEBUG called with arguments (#<PROCESS control-thread(3) [Active] #x6C76166> 1 ("destructure-case failed: NIL" " [Condition of type SIMPLE-ERROR]") (("ABORT" "Restart dispatch loop.") ("ABORT-BREAK" "#<RESTART ABORT-BREAK #x7FEE06>") ("ABORT" "#<RESTART ABORT #x7FEE2E>")) ((0 "(SWANK::DISPATCH-EVENT #<TCP-STREAM (SOCKET/19) #x6C76EBE>)") (1 "(SWANK::DISPATCH-LOOP #<TCP-STREAM (SOCKET/19) #x6C76EBE> #S(SWANK::CONNECTION :SOCKET-IO #<TCP-STREAM (SOCKET/19) #x6C76EBE> :DEDICATED-OUTPUT #<TCP-STREAM (SOCKET/20) #x6C76756> :USER-INPUT #<SWANK-BACKEND::SLIME-INPUT-STREAM #x6C76366> :USER-OUTPUT #<TCP-STREAM (SOCKET/20) #x6C76756> :USER-IO #<TWO-WAY-STREAM input #<SWANK-BACKEND::SLIME-INPUT-STREAM #x6C76366>, output #<TCP-STREAM (SOCKET/20) #x6C76756> #x6C76326> :CONTROL-THREAD #<PROCESS control-thread(3) [Active] #x6C76166> :READER-THREAD #<PROCESS reader-thread(4) [Active] #x6C75F66> :REPL-THREAD #<PROCESS repl-thread(5) [Active] #x6C75D6E> :READ #<Compiled-function SWANK::READ-FROM-CONTROL-THREAD #x6C2DCC6> :SEND #<Compiled-function SWANK::SEND-TO-CONTROL-THREAD #x6C2B1BE> :SERVE-REQUESTS #<Compiled-function SWANK::SPAWN-THREADS-FOR-CONNECTION #x6C1FE16> :CLEANUP NIL :INDENTATION-CACHE #<HASH-TABLE :TEST EQ size 60/60 #x6C768E6> :INDENTATION-CACHE-PACKAGES (#<Package \"ASDF1017\"> #<Package \"ASDF945\"> #<Package \"ASDF-INSTALL-CUSTOMIZE\"> #<Package \"ASDF-INSTALL\"> #<Package \"ASDF-INSTALL-SYSTEM\"> #<Package \"ASDF942\"> #<Package \"SWANK-COMPLETION-TEST\"> #<Package \"SWANK-IO-PACKAGE\"> #<Package \"SWANK\"> #<Package \"NREGEX\"> #<Package \"SWANK-BACKEND\"> #<Package \"SWANK-LOADER\"> #<Package \"ASDF\"> #<Package \"CROSS-REFERENCE\"> #<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\">)))") (2 "(RUN-PROCESS-INITIAL-FORM '(#<COMPILED-LEXICAL-CLOSURE (:LAMBDA 1 :IN %PROCESS-RUN-FUNCTION) #x6C7612E>))") (3 "((:LAMBDA 1 :IN %PROCESS-PRESET-INTERNAL) '(#<COMPILED-LEXICAL-CLOSURE (:LAMBDA 1 :IN %PROCESS-RUN-FUNCTION) #x6C7612E>))") (4 "((:LAMBDA 1 :IN THREAD-MAKE-STARTUP-FUNCTION))"))) . > While executing: FUNCALL It's usually impossible to recover once this starts happening. It's as if the :emacs-rex if being left off the car of all the messages. 2) In openmcl. Traced send and receive. These receives don't seem to be initiated by a send... They happen now and then when loading a system that takes a while to load (probably other times too). Ignoring them prevents my lisp from being hosed. If you already know what the problem is, send me a note, otherwise I will continue looking when I have a chance. Calling (SWANK-BACKEND:RECEIVE) SWANK-BACKEND:RECEIVE returned NIL DISPATCHING: NIL IGNORING UNKNOWN EVENT: NIL Calling (SWANK-BACKEND:RECEIVE) SWANK-BACKEND:RECEIVE returned NIL DISPATCHING: NIL IGNORING UNKNOWN EVENT: NIL Calling (SWANK-BACKEND:RECEIVE) SWANK-BACKEND:RECEIVE returned NIL DISPATCHING: NIL IGNORING UNKNOWN EVENT: NIL 3) CCL::%%FRAME-BACKLINK periodically hard crashes the lisp. I'll send the kernel debugger backtrace next time it happens 4) Typically after a very large amount of output to the repl, slime space starts infinite looping in emacs and I have to interrupt it with control-g (after I type each space). Needless to say, I restart as soon as I can. So things are a bit of a mess and I would spend some time looking into it but have been flat out recently. But maybe this will give someone a hint about what is going on. And I should start having some more time in a couple of weeks. -Alan On Jun 11, 2004, at 4:25 PM, Gary Byers wrote: > > > On Fri, 11 Jun 2004, Christian Hofer wrote: > >> Hi, >> >> when I'm working with OpenMCL on Darwin, and SLIME, I just cannot >> figure out, how to use the debugger correctly. I just downloaded the >> newest OpenMCL release and the newest SLIME tarball, and the behaviour >> is getting even worse. >> >> E.g. when I try to evaluate the variable test in the listener, I get - >> as expected - the following error: >> >> Unbound variable: TEST >> [Condition of type UNBOUND-VARIABLE] >> >> Restarts: >> 0: [CONTINUE] Retry getting the value of TEST. >> 1: [USE-VALUE] Specify a value of TEST to use this time. >> 2: [STORE-VALUE] Specify a value of TEST to store and use. >> 3: [ABORT] Abort handling SLIME request. >> 4: [ABORT-BREAK] #<RESTART ABORT-BREAK #x1692E06> >> 5: [ABORT] #<RESTART ABORT #x1692E2E> >> >> Now, none of the aborts seem to work properly. When I chose 3, I get >> the following error: >> >> Undefined function CCL::SIMPLE-RESTART called with arguments () . >> [Condition of type CCL::UNDEFINED-FUNCTION-CALL] >> >> When I try, on the other hand option 4 or 5, the listener seems to >> loose contact to OpenMCL. >> >> SBCL on FreeBSD behaves completely different and I did not encounter >> any similiar problems. >> >> Thus I wanted to know, if the lost connection is expected behaviour. >> And on the other hand, if I did s.th. wrong during installation or if >> simple-restart does not work at the moment? > > CCL::SIMPLE-RESTART isn't a function (it -is- the name of a type of > restart), so if something's calling it as a function it's not too > surprising that it's undefined. If something's trying to call it as a > function, there would probably have been undefined-function warnings > during compilation; you might want to look at the *INFERIOR-LISP* > buffer to see if it shows any evidence of this. > > I tried to reproduce this with the current SLIME from CVS; I found that > restarts 0-2 worked as expected in this case; 3-5 seemed to all lose > the connection, with messages in the *INFERIOR-LISP* buffer to the > effect that some socket used to communicate between Emacs and the lisp > had received an unexpected EOF. The thread that's running the SLIME > REPL seems to be in: > > (defimplementation receive () > (let* ((mbox (mailbox ccl:*current-process*)) > (mutex (mailbox.mutex mbox))) > (ccl:wait-on-semaphore (mailbox.semaphore mbox)) > (ccl:with-lock-grabbed (mutex) > (pop (mailbox.queue mbox))))) > > waiting on a semaphore that'll probably never be signalled (I don't > know much about the protocol SLIME/SWANK use, but I'd guess that > the unexpected EOF has something to do with this ... > > Sorry that's not more helpful. > >> >> Thanks, >> Chris >> >> _______________________________________________ >> Openmcl-devel mailing list >> Openmcl-devel(a)clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel >> >> > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel(a)clozure.com > http://clozure.com/mailman/listinfo/openmcl-devel

2 1

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

11 Jun '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.390 slime/ChangeLog:1.391 --- slime/ChangeLog:1.390 Wed Jun 9 21:40:28 2004 +++ slime/ChangeLog Thu Jun 10 11:08:23 2004 @@ -1,3 +1,48 @@ +2004-06-10 Christophe Rhodes <csr21(a)cam.ac.uk> + + * swank-sbcl.lisp (call-with-syntax-hooks): Add hooks to fix + "SB!"-style package names. + (shebang-readtable): Return a readtable with readermacros needed + to parse SBCL sources. + + * swank.lisp (with-buffer-syntax): New macro. This should be used + for code which needs to READ code from Emacs buffers. *package* + and *readtable* are bound suitable values. + (to-string, format-values-for-echo-area, interactive-eval) + (eval-region, interactive-eval-region, re-evaluate-defvar) + (swank-pprint, pprint-eval, listener-eval) + (compile-string-for-emacs, disassemble-symbol, describe-to-string) + (describe-symbol, describe-function) + (describe-definition-for-emacs) + (documentation-symbol, init-inspector, inspect-nth-part) + (inspector-pop, inspector-next, describe-inspectee) + (inspect-current-condition): Use it. + +2004-06-10 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * swank-loader.lisp: Initialize swank::*readtable-alist* for SBCL. + + * swank-backend.lisp (default-directory, call-with-syntax-hooks): + New functions. + + * swank.lisp (*readtable-alist*): New configurable. The keys are + package name and the values readtables. The readtable will be + used to READ code originating from Emacs buffers in the associated + slime-buffer-package. + (drop-thread): Simplified. + (*buffer-readtable*): New variable. + (parse-package): New function. + (parse-string): Renamed from symbol-from-string. Make it case + insensitive. + (eval-for-emacs): Initialize the *buffer-readtable*. + (symbol-indentation): Don't consider symbols in the CL package. + Emacs already knows how to indent them. + (compile-file-if-needed): Used for REPL shortcut + 'compile-and-load'. + + * slime.el (pwd): Re-add REPL shortcut. + (slime-repl-push-directory, slime-repl-compile-and-load): Simplified. + 2004-06-10 Luke Gorrie <luke(a)bluetail.com> * slime.el (sldb-step): Command is disabled because the function

1 0

[slime-devel] M-x slime-ensure-typeout-frame ?
by Sung-youn Kim 10 Jun '04

10 Jun '04

Hmm.. After M-x slime-ensure-typeout-frame, the command related messages are still directed to minibuffer with typeout frame open and idle. I use cmucl 18e and emacs21 on Debian sarge. -- _________________ Sung-youn Kim Political Science Dept. Stony Brook University (SUNY at Stony Brook) Office : 631-632-7664 Web : http://www.ic.sunysb.edu/stu/sungyoki

1 0

[slime-devel] Re: sbcl sources support
by Helmut Eller 10 Jun '04

10 Jun '04

I integrated your patch in the CVS version. It does basically the same as your patch, but the functionality is a bit better separated between front-end and backend. As a side-effect, *readtable-alist* can now be used to associate readtables with packages. Helmut. Christophe Rhodes <csr21(a)cam.ac.uk> writes: > Helmut Eller <e9626484(a)stud3.tuwien.ac.at> writes: > >> I think it's rather unlikely, that someone works on SBCL and another >> project with conflicting reader macros. > > Relatively unlikely, I grant you -- but not beyond the bounds of > possibility. (A number of projects I work on have their own > readtables, and it would be awkward if a minor bugfix to sbcl in the > interim caused odd things to happen). > >> What do you think about a command like: >> >> (defun set-sbcl-syntax () >> (setf *readtable* (sb-introspect:sbcl-readtable)) >> (sb-introspect:advice-find-package)) > > What I would like to happen is that, when a user does e.g. M-. to find > the source of an sbcl function, that the normal slime commands work as > expected without user intervention. The precise mechanism to achieve > this doesn't worry me so much (though I think global advising of > find-package, and global setting of *readtable*, is a lot uglier than > advice in the dynamic contour of slime evaluation -- this is in fact a > defect of my patch, which handles slightly too many > BOOTSTRAP-PACKAGE-NOT-FOUND conditions: during evaluation as well as > compilation.) > > The problem from my point of view with the requirement of an explicit > command is that it only marginally lowers the barrier of entry. If > you want a typical use case, I can imagine someone wishing to find the > location of the error emitted from defconstant when a constant is > being redefined, and redefine the checking function; notwithstanding > the fact that there may be better ways of achieving the ultimate aim, > I think this kind of interaction should be supported. I don't think > that this ability to treat the system as incrementally modifiable is > assisted very much (over the current situation) by having to run an > explicit command... > > Cheers, > > Christophe > > (Lest my tone be too negative: for the record I really appreciate the > work you, Luke and others have done. The fact that I'm even > contemplating incremental modification of sbcl via slime should be > testimony to that! :-)

1 0

[slime-devel] abcl
by Andras Simon 10 Jun '04

10 Jun '04

While the list was sleeping, I adapted Helmut's allegro backend for abcl. It is not quite ready for prime time, but is somewhat usable. Actually, it's already at version 2 (or should I say 0.02): originally, I had to patch swank.lisp, but thanks to Peter Graves, who tracked down pretty printing bugs in abcl, this is no longer necessary. Nevertheless, it's probably too early to include it in the official slime sources, but I thought I'd let you know about it anyway. It's temporarily available here: http://www.math.bme.hu/~asimon/slime-abcl.tgz The tar file includes swank-loader.lisp (so back up yours if you untar it in the slime directory) and swank-abcl.lisp. It doesn't work with the latest abcl release, only with the cvs version. (In fact, it's probably better to wait a few hours until anon cvs at sourceforge picks up the latest sources.) Andras

2 5

[slime-devel] slime-maybe-start-lisp patch
by Robert Lehr 10 Jun '04

10 Jun '04

I have applied this patch to my local installation of SLIME. It enables me to point to the 'swank-loader' lisp in any location. It enables the user to bypass the original concatenation of SLIME-PATH and SLIME-BACKEND depending on whether SLIME-BACKEND is an absolute pathname or not. In other words, if SLIME-BACKEND is an absolute pathname then the original procedure is bypassed, avoiding the concatenation of SLIME-PATH and SLIME-BACKEND. Otherwise, they are concatenated. Whether you accept this specific logic or not, you should be aware that some installations do not want to put the emacs code and the lisp code in the same location. Hence, my conflict with the 'swank-loader' that I resolved with this patch. -- Robert Lehr (concatenate 'string "bozzio" "@" "the-lehrs" ".com" )

1 1

[slime-devel] Anonymous CVS back (again)
by Luke Gorrie 10 Jun '04

10 Jun '04

Ahoy, Anonymous CVS should be working again now.

1 0

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

10 Jun '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.387 slime/ChangeLog:1.390 --- slime/ChangeLog:1.387 Tue Jun 8 16:58:32 2004 +++ slime/ChangeLog Wed Jun 9 21:40:28 2004 @@ -1,3 +1,48 @@ +2004-06-10 Luke Gorrie <luke(a)bluetail.com> + + * slime.el (sldb-step): Command is disabled because the function + `swank:sldb-step' that it calls doesn't exist. I don't see any + stepping code in our backends. + +2004-06-09 Helmut Eller <e9626484(a)stud3.tuwien.ac.at> + + * slime.el (slime-goto-location-position) [:function-name]: The + function name can also occur after a ?(, not only after + whitespace. + + * (slime-init-output-buffer): Initialize the package stack. + Reported by Rui Patrocínio. + + * (slime-completions): Make it consistent with + slime-simple-completions. The second argument was never supplied. + Reported by Rui Patrocínio. + +2004-06-09 Eric Blood <eblood(a)winkywooster.org> + + * slime.el (slime-indent-and-complete-symbol): Renamed from + slime-repl-indent-and-complete-symbol. + + (slime-typeout-frame-properties): Add more default options for the + typeout frame--specifically it now has a default width, and moves + the typeout frame to the upper right. + +2004-06-09 Andras Simon <andras(a)renyi.hu> + + * swank-abcl.lisp: New backend for Armed Bear Common Lisp. + + * swank-loader.lisp: Add ABCL support. + +2004-06-09 Martin Simmons <martin(a)xanalys.com> + + * swank-lispworks.lisp (dspec-stream-position): New function to + make source location work for anything complicated e.g. methods. + (with-swank-compilation-unit): Refactoring. + (who-macroexpands): Implemented. + (list-callers): Implemented. + + * swank-backend.lisp (network-error): Inherit from simple-error to + get correct initargs. + 2004-06-09 Luke Gorrie <luke(a)bluetail.com> * slime.el (sldb-insert-references): Added support for hyperlinked

1 0

[slime-devel] Welcome back!
by Luke Gorrie 09 Jun '04

09 Jun '04

Greetings, The mailing list is now operational again! At least I presume it is, if this test message gets through :-)

5 6

[slime-devel] sbcl sources support
by Christophe Rhodes 09 Jun '04

09 Jun '04

Hi, Attached is a (probably corrupt, sorry) patch which partly implements DWIM when slime commands are executed on sbcl sources. The background: for those who do not know the detail, suffice it to say that, out of the box, sbcl sources are unreadable (in the READ sense) to a running sbcl. The unreadability comes in two forms: firstly, all of the package names are different (this enables sbcl to build cleanly even from itself); secondly, the #! reader macro (reserved to the user) is used extensively by the sources to implement reader conditionals against the *features* that will be active under the to-be-built lisp. This patch uses knowledge of sbcl internals (some of which should probably be in sb-introspect; they'll get moved there once we establish exactly what we need) to, firstly, modify the behaviour of FIND-PACKAGE to treat SB!FOO as a nickname for SB-FOO; and secondly, to temporarily replace the current readtable with one which includes a #! reader macro. This, I think, is good enough for a DWIM system; it gets about 99% of sbcl sources right. My implementation of it is, of course, sucky. I don't really have a handle on the package discipline, nor where a feature like this logically belongs in slime -- it seems to cross-cut several layers. On top of this, I'm fairly sure I haven't found all the places where this is necessary: essentially all places that could do READ need to be wrapped. [ The implementation of the #! reader macro logically belongs in sb-introspect, I think, but it isn't there yet. ] I hope this patch gives enough of a flavour for what is necessary, and enough information to either desuckify it for me, or to tell me what I should do to make it suck less. 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)

2 2

[slime-devel] some problems
by Rui Patrocínio 09 Jun '04

09 Jun '04

Hello, I'm currently working on some extensions to slime (I hope to release the source at end of the month) and I've found some minor problems. Currently the 'slime-repl-stack-package' is not initialized with M-x slime (only with slime-start-and-load, AFAIK), none the less the repl starts with the CL-USER package. Shouldn't the stack be initialized with that package? The other problem is only a matter of consistency. The slime-simple-completions doesn't have the same interface of slime-completions. I think there are some problems with the handling of CL symbols and packages, but I'll comment on that later. Continue with the great job. :) Rui Patrocínio

2 1

[slime-devel] find-definitions
by Andras Simon 09 Jun '04

09 Jun '04

I'd like to make M-. work in abcl, and it looks like it wouldn't be too hard to record source file name, kind (ie. function, macro, etc.), and approximate file-position ("the next form after this position") info in fasl files. Exact file-position is doable, but harder. Ideally, what information is expected from swank-backend:find-definitions, and how accurate should it be? Is there a minimal subset which slime can go by? Which lisp/swank backend has the best support for M-.? Andras

2 1

[slime-devel] slime-load-system
by Thomas F. Burdick 09 Jun '04

09 Jun '04

(Using slime with sbcl here) For asdf systems that have warnings or errors when compiling, slime-load-system is a little less helpful than I'd hope for; I get the slime debugger before I get the nice tree view of what happened. Which is problematic, because I don't know if it's okay to tell asdf to continue, until I know what went wrong. Anyone have a workaround for this? Would it be difficult to get the tree view along with the debugger? I should really familiarize myself better with the slime sources.

2 2

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

09 Jun '04

Index: slime/ChangeLog diff -u slime/ChangeLog:1.385 slime/ChangeLog:1.387 --- slime/ChangeLog:1.385 Mon Jun 7 11:38:02 2004 +++ slime/ChangeLog Tue Jun 8 16:58:32 2004 @@ -1,3 +1,28 @@ +2004-06-09 Luke Gorrie <luke(a)bluetail.com> + + * slime.el (sldb-insert-references): Added support for hyperlinked + references as part of conditions being debugged. This is a new + feature in SBCL to reference appropriate sections of their manual + or CLHS from condition objects. The references are clickable. + + * swank-backend.lisp (format-sldb-condition): New backend function + to format conditions for SLDB. + (condition-references): New function to return a list of + documentation references associated with a condition. + + * swank.lisp (debugger-condition-for-emacs): Call the above + backend functions to add a `references' list for Emacs. + + * swank-sbcl.lisp (format-sldb-condition, condition-references): + Implemented. Requires a recent (latest?) SBCL release. + +2004-06-08 Luke Gorrie <luke(a)bluetail.com> + + * swank-cmucl.lisp (close-socket): Remove any SERVE-EVENT handlers + for the socket's file descriptor. + + * swank-sbcl.lisp (close-socket): Same fix. + 2004-06-07 Luke Gorrie <luke(a)bluetail.com> * swank-cmucl.lisp: Minor refactorings.

1 0

[slime-devel] SBCL clickable documentation, FAIRLY-STABLE
by Luke Gorrie 09 Jun '04

09 Jun '04

Ahoy, I've added support for Christophe's new SBCL `reference-condition' feature. Some SBCL conditions include references to documentation in CLHS or the SBCL manual to explain them, and these become clickable hyperlinks in SLDB. Requires a new (or perhaps latest) SBCL. But I set FAIRLY-STABLE before committing this to give people time to upgrade. An example that produces the references is: CL-USER> (defconstant foo 1) FOO CL-USER> (defconstant foo 2) Kudos Christophe! This will probably be great newbie feature. NB: I haven't gone all the way, e.g. it doesn't hyperlink CLHS glossary references yet - only symbols. Cheers, Luke

1 0