* Nikodemus Siivola [2008-12-01 09:50+0100] writes:
Here's a workflow issue that I run into periodically:
- While working on SBCL I instrument some internal operation to see
what is going on -- let's say with BREAK.
- 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 used.
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 suggestions?
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) (when *break-in-compiler* (apply #'break (or args (list "compiler-break")))))
(compile 'compiler-break)
(defun debug-compile-defun (s) (let ((*break-in-compiler* t) (c::*check-consistency* t)) (with-input-from-string (in s) (ext:compile-from-stream in :trace-stream *standard-output* :verbose t :print t :progress t :byte-compile nil))))
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 () (interactive) (let ((s (apply #'buffer-substring-no-properties (slime-region-for-defun-at-point)))) (slime-eval-async `(cl-user::debug-compile-defun ,s) (lambda (x) (message "debug-compile finished")))))
Are you are searching this kind of thing?
Helmut.