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

[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