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

[slime-devel] sb-impl::indenting-streams on the chopping block
by Nikodemus Siivola 31 Oct '08

31 Oct '08

Aside from slime/contrib/swank-presentations.lisp (or (and (typep stream 'sb-impl::indenting-stream) (slime-stream-p (sb-impl::indenting-stream-stream stream))) (and (typep stream (find-symbol "PRETTY-STREAM" 'sb-pretty)) (find-symbol "ENQUEUE-ANNOTATION" 'sb-pretty) (not *use-dedicated-output-stream*) (slime-stream-p (sb-pretty::pretty-stream-target stream))))) SB-IMPL::INDENTING-STREAM is, as far as I can tell, otherwise unused. Does someone actually use them? Any objections to deleting them? (And the first leg of the OR in Slime.) Cheers, -- Nikodemus

2 2

[slime-devel] Auto-jumping to compiler notes
by Jeff Workman 31 Oct '08

31 Oct '08

I noticed that there seems to have been a recent change to SLIME that makes it jump to compiler notes automatically when a file is compiled. Also, it seems to jump even to SBCL compiler optimization notes, which makes it very annoying to work on files where I have speed declarations. I don't like the auto-jumping in general, since there are times I might have a warning in a file temporarily while working on something else in the file, and people can just run slime-next-note manually if they want to see the notes, but at a minimum it shouldn't apply to optimization notes. Or if you don't want to change the default behavior, is there a variable I can set to disable it?

2 1

[slime-devel] Problem with `slime-popup-buffer-quit' in XEmacs
by Steven E. Harris 30 Oct '08

30 Oct '08

I've noticed this problem in XEmacs, but not in Emacs. When one macroexpands a form, the frame splits, the "*SLIME Macroexpansion*" window appears, and the cursor jumps there. If one then presses 'q' -- bound to `slime-popup-buffer-quit-function' (which is bound to `slime-popup-buffer-quit' in the buffer), not only does the macroexpansion buffer's window close, but the original window that contained the form that was macroexpanded gets buried as well. That is, quitting from the macroexpansion buffer does not return to the original buffer; it returns to what I guess is one buffer below that original buffer in the stack. -- Steven E. Harris

2 2

[slime-devel] swank+sbcl and cpu utilization
by Chris Goellner 30 Oct '08

30 Oct '08

I'm trying to get a remote SWANK+SBCL setup going and I've hit a snag. Everything works and I can connect to the running SBCL. However, when I disconnect the SBCL process drives the CPU to 100%. I've tried this on OS X 10.5, Solaris 2.8, and Linux Ubuntu with SBCL 1.0.20. I've checked that the slime on the remote and local ends are the same version which is the latest from the CVS. My guess is I'm doing something obviously wrong since it looks like a lot of people use this setup without a problem. So, few that I could only find one Google entry that seemed on point but the recommended change is to a function that isn't in my version of slime. my .emacs file looks like: (add-to-list 'load-path "path/to/slime") (setq inferior-lisp-program "/usr/local/bin/sbcl") (require 'slime) (slime-setup) and my .sbclrc file looks like: (require 'asdf) (require 'asdf-install) I've got another file called swank.lisp that starts up my remote side sbcl+swank process: (asdf:oos 'asdf:load-op 'swank) (setf swank:*communication-style* :fd-handler) (setf swank:*use-dedicated-output-stream* nil) (swank:create-server :dont-close t) I call this file as 'sbcl --load swank.lisp' and the whole system works great. Until I disconnect from the sbcl instance. Then it spikes the CPU and will spin until I stop it. I've got this working in CLISP but I've been using SBCL and I would like to have both working. Any suggestions?

2 2

[slime-devel] Problems with slime-edit-definition
by Yarek Kowalik 28 Oct '08

28 Oct '08

I've recently (3 weeks ago) updated slime from CVS, and now the M-. command no longer works for me. I am no longer able to "drill-down" on the definition of a CLOS class, for example, and jump to the source file. I'm using SBCL 1.0.20 on x86. I'm working with Weblocks source code if that matters. This is was one of the features I used very frequently, and not having it is a serious handicap. Any suggestions on how to make it work would be much appreciated. Thanks, Yarek

2 4

[slime-devel] Simplifying backtraces in the debugger
by Steven E. Harris 27 Oct '08

27 Oct '08

I'm not sure if this grievance falls to CLISP or to SLIME. When I land in the debugger, there are way too many frames present. Most of them are just noise, and I usually can't find the interesting frames -- such as those corresponding to named functions that I wrote -- with lexical bindings to inspect. Playing around with CLISP outside of SLIME, I see that one can set the mode used by the ":bt" command in the debugger. This can help to simplify the output, though I haven't yet figured out which of the five modes corresponds to what I'd /like/ to see. Consider this contrived example: ,---- | CL-USER> (defun foo (n) | (/ 3 n)) | FOO | CL-USER> (foo 0) `---- Evaluating that second form provokes this view in the debugger: (Take a deep breath.) ,---- | /: division by zero | [Condition of type SYSTEM::SIMPLE-DIVISION-BY-ZERO] | | Restarts: | 0: [RETRY] Retry SLIME REPL evaluation request. | 1: [ABORT] Return to SLIME's top level. | 2: [CLOSE-CONNECTION] Close SLIME connection | 3: [ABORT] Abort main loop | | Backtrace: | 0: [366] frame binding variables (~ = dynamically): | | ~ SWANK::*SLDB-STEPPING-P* <--> NIL | 1: [363] frame binding variables (~ = dynamically): | | ~ SWANK::*SLDB-LEVEL* <--> 0 | 2: [360] frame binding variables (~ = dynamically): | | ~ *PACKAGE* <--> #<PACKAGE COMMON-LISP-USER> | 3: <1/354> #<COMPILED-FUNCTION SWANK::DEBUG-IN-EMACS> | [353] frame binding variables (~ = dynamically): | | ~ SWANK::*SLIME-INTERRUPTS-ENABLED* <--> T | 4: <1/347> #<COMPILED-FUNCTION SWANK:INVOKE-SLIME-DEBUGGER> | - #<COMPILED-FUNCTION SWANK::SWANK-DEBUGGER-HOOK-1> | 5: <1/345> #<COMPILED-FUNCTION SWANK::SWANK-DEBUGGER-HOOK-1> | - #<COMPILED-FUNCTION SWANK::SWANK-DEBUGGER-HOOK-1> | 6: [344] frame binding variables (~ = dynamically): | | ~ *DEBUGGER-HOOK* <--> NIL | 7: <1/340> #<COMPILED-FUNCTION #:|624 629 (DEFINTERFACE CALL-WITH-DEBUGGER-HOOK (HOOK FUN) ...)-61-3-1|> | - #<COMPILED-FUNCTION #:|624 629 (DEFINTERFACE CALL-WITH-DEBUGGER-HOOK (HOOK FUN) ...)-61-3-1|> | 8: <1/335> #<COMPILED-FUNCTION SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK> | - #(NIL #<SYSTEM::SIMPLE-DIVISION-BY-ZERO #x10140B4D>) | 9: <1/331> #<COMPILED-FUNCTION SWANK:SWANK-DEBUGGER-HOOK> | [329] frame binding variables (~ = dynamically): | | ~ *DEBUGGER-HOOK* <--> #<COMPILED-FUNCTION SWANK:SWANK-DEBUGGER-HOOK> | 10: <1/326> #<SYSTEM-FUNCTION INVOKE-DEBUGGER> 1 | [325] frame binding variables (~ = dynamically): | | ~ SYSTEM::*PRIN-STREAM* <--> #<UNBOUND> | 11: [322] frame binding variables (~ = dynamically): | | ~ *PRINT-READABLY* <--> NIL | 12: [319] frame binding variables (~ = dynamically): | | ~ *PRINT-ESCAPE* <--> T | 13: <1/315> #<SYSTEM-FUNCTION /> 2 | - 3 | 14: [313] EVAL frame for form (/ 3 N) | Locals: | N = 0 | 15: [309] frame binding environments | VAR_ENV <--> NIL | FUN_ENV <--> NIL | BLOCK_ENV <--> NIL | GO_ENV <--> NIL | DECL_ENV <--> ((DECLARATION OPTIMIZE DECLARATION)) | 16: [303] frame binding variables #<ADDRESS #x7FF404FC> binds (~ = dynamically): | | N <--> 0 | Next environment: NIL | 17: [297] APPLY frame for call (FOO '0) | 18: <1/293> #<FUNCTION FOO (N) (DECLARE (SYSTEM::IN-DEFUN FOO)) (BLOCK FOO (/ 3 N))> 1 | - #<FUNCTION FOO (N) (DECLARE (SYSTEM::IN-DEFUN FOO)) (BLOCK FOO (/ 3 N))> | 19: [292] EVAL frame for form (FOO 0) | 20: [289] frame binding environments | VAR_ENV <--> NIL | FUN_ENV <--> NIL | BLOCK_ENV <--> NIL | GO_ENV <--> NIL | DECL_ENV <--> ((DECLARATION OPTIMIZE DECLARATION)) | 21: <1/284> #<SYSTEM-FUNCTION EVAL> | - (FOO 0) `---- If I ran across this output in a large program, I'd probably be most interested in frame 14, where the division operator is being evaluated. Expanding it shows that "N" was bound to 3. Is there some way to configure SLIME to sift through these frames and reduce them to something more "interesting"? For instance, by my criteria, everything in frames 1 through 12 above is irrelevant to the debugging intent, unless I was trying to debug the debugger. As an aside, I'd appreciate any comparison in the output to other implementations besides CLISP. Are they less chatty? -- Steven E. Harris

2 2

[slime-devel] slime.el requires arc-mode
by Steven E. Harris 27 Oct '08

27 Oct '08

Line 4603 in slime.el contains the following form: ,---- | ((:zip file entry) | (require 'arc-mode) | (set-buffer (find-file-noselect file t)) | (goto-char (point-min)) | (re-search-forward (concat " " entry "$")) | (let ((buffer (save-window-excursion | (archive-extract) | (current-buffer)))) | (set-buffer buffer) | (goto-char (point-min)))) `---- Note that it requires arc-mode. I don't have arc-mode, so slime.el won't load in XEmacs. Is this a new prerequisite for running SLIME? -- Steven E. Harris

3 5

[slime-devel] ASDF contrib always reports "Compilation failed" in the minibuffer
by Mark Evenson 22 Oct '08

22 Oct '08

The 'slime-asdf' contribution always reports "Compilation failed" in the minibuffer for all of the various REPL shortcut commands (i.e. those prefixed with the "'" character) dealing with ASDF (tested this under SBCL, ABCL, and CLISP). This is occurring because the value of ASDF:OPERATE (aka ASDF:OOS) is seemingly always NIL. COLLECT-NOTES in swank.lisp:2461 is passing this result back to SLIME in the COMPILATION-RESULT to be reported in the minibuffer as status. Did something get lost in a refactoring somewhere? Or did the ASDF hooks always have this behavior? I can't see a plausible way to assign a meaningful status from ASDF:OPERATE anyways (my understanding is that it always returns nil), so my suggestion would be to change the minibuffer message for COMPILATION-RESULTs from ASDF invocations, but that didn't look like a fast fix, so I wanted to solicit advice. In the scale of things, this is a minor cosmetic problem with SLIME, but it was bugging me (and would be confusing for new users)… -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 1

[slime-devel] Current slime head broken on alisp.
by Luke Hope 21 Oct '08

21 Oct '08

Confirmed with a user on #lisp. Both alisp and acl-express. In *slime-scratch*, try evaluating (+ 1 'foo) with C-x C-e. The swank-debugger fails to come up. It works fine in SBCL and Clojure. Also, does anyone know what happened to the little "eval..." message in the emacs status bar when the lisp is working? That was extremely useful to me. -Luke

2 2

[slime-devel] [patch] slime-end-of-defun complain "Symbol's value as variable is void: major"
by S.P.Tseng 21 Oct '08

21 Oct '08

Follow function in file "slime-editing-commands.el", should use "major-mode" instead of "major". It seems variable "major" in emacs23 is deprecated. ,---- | (defun slime-end-of-defun () | (interactive) | (if (eq major 'slime-repl-mode) | (slime-repl-end-of-defun) | (end-of-defun))) | `---- -- The opposite of love is not hate; the opposite of love is solitude.

2 1