* Samium Gromoff [2006-04-23 20:26+0200] writes:
In fact, observing the debug stack makes it clear that none of its entries bear direct relevance to the source at fault. It points into the guts of the SBCL macroexpander.
Those are actually the guts of the loader, not the macroexpander. AFAIK, SBCL still generates code for source with this kind of error but the code just signals the condition.
It might help, if you use slime-compile-file (without loading) so that you can see the compiler messages without getting disturbed by the errors during load time.
So this raises the question -- how do i jump to the source location of a syntax error?
Well, SBCL doesn't provide the source location for those errors so SLIME can't display it.
Below is a little patch to SBCL to pass the source context along.
If you are debugging your own (toplevel) macros, it often useful to eval (instead of compile) the code, because then the compiler doesn't catch the error and you can jump to the source of the macro expander from the backtrace.
Helmut.
--- sbcl-0.9.11/src/compiler/main.lisp 2005-11-21 04:53:21.000000000 +0100 +++ /tmp/main-patched.lisp 2006-04-24 23:24:57.384035032 +0200 @@ -1185,7 +1185,9 @@ ;; sequence of steps in ANSI's "3.2.3.1 Processing of ;; Top Level Forms". #-sb-xc-host - (let ((expanded (preprocessor-macroexpand-1 form))) + (let ((expanded + (let ((*current-path* path)) + (preprocessor-macroexpand-1 form)))) (cond ((eq expanded form) (when compile-time-too (eval-in-lexenv form *lexenv*))