[slime-devel] hacking system internals from Slime
heller at common-lisp.net
Mon Dec 1 09:44:43 UTC 2008
* Nikodemus Siivola [2008-12-01 09:50+0100] writes:
> Here's a workflow issue that I run into periodically:
> 1. While working on SBCL I instrument some internal operation to see
> what is going on -- let's say with BREAK.
> 2. Before I can run my test-case I need to page my way thru a number
> of debugger entries (sometimes a HUGE number) due to eg. cursor
> movement in a Lisp buffer causing the instrumented operation to be
> I'm not looking for a 100% solution, because I doubt anything like
> that exists. Hacking a live system is always tricky that way...
> An 80% solution might be being able to tell Slime to stop talking to
> the lisp, except for communications triggered by explicit REPL
> evaluations. Does this sound like a feasible idea? Any other
I'm not sure that I understand your problem. One problem that I
encountered is that calling BREAK inside the compiler isn't very
feasible because SLIME calls the compiler for other reasons too.
For this situation I use this special break function:
(defvar *break-in-compiler* nil)
(defun compiler-break (&rest args)
(apply #'break (or args (list "compiler-break")))))
(defun debug-compile-defun (s)
(let ((*break-in-compiler* t)
(with-input-from-string (in s)
COMPILER-BREAK invokes BREAK only if *BREAK-IN-COMPILER* is true.
To actually invoke the breakpoint I invoke the compiler via
DEBUG-COMPILE-DEFUN. Usually with this Emacs side command:
(defun slime-debug-compile-defun ()
(let ((s (apply #'buffer-substring-no-properties
(slime-eval-async `(cl-user::debug-compile-defun ,s)
(lambda (x) (message "debug-compile finished")))))
Are you are searching this kind of thing?
More information about the slime-devel