Question

I’m using SLIME to debug my Common Lisp function. Inside the function, I’ve made it artificially signal an error (trying to “debug”—perhaps I should be stepping) like so:

(define-condition unknown-zone (error)
  ((text :initarg :text :reader text)))

(defun parse-mime-date (date)
  (let ((last-space (position #\Space date :from-end t)))
    (let ((date-time (net.telent.date:parse-time (subseq date 0 last-space)))
          (zone (subseq date (1+ last-space))))
      (unless (or (char= (elt zone 0) #\+)
                  (char= (elt zone 0) #\-))
        (error 'unknown-zone :text (format nil "Unknown timezone: ~a" zone)))
      (let ((hours (parse-integer (subseq zone 0 3)))
            (minutes (parse-integer
                      (concatenate 'string
                                   (list (elt zone 0))
                                   (subseq zone 3)))))
        (error 'unknown-zone :text "LOL")
        (let ((adjusted-date-time (- date-time (* 60 (+ minutes (* 60 hours))))))
          (format t "date-time: ~a; zone: ~a~%" date-time zone)
          (format t "adjusted: ~a" (net.telent.date:universal-time-to-http-date adjusted-date-time)))))))

I’m trying to work around what appears to be a deficiency in net.telent.date:parse-time (it seems to botch up timezone handling, though I’m not 100% yet).

The “LOL” unknown-zone error is of course the artificial breakpoint.

When it hits this part of the function, SLDB faithfully opens up with the backtrace:

Bad type argument:
  NS-MAIL2ZD::UNKNOWN-ZONE
   [Condition of type SIMPLE-TYPE-ERROR]

Restarts:
 0: [RETRY] Retry SLIME REPL evaluation request.
 1: [*ABORT] Return to SLIME's top level.
 2: [REMOVE-FD-HANDLER] Remove #<SB-IMPL::HANDLER INPUT on descriptor 7: #<CLOSURE (LABELS SWANK-BACKEND::RUN :IN SWANK-BACKEND:ADD-FD-HANDLER) {10030AD9FB}>>
 3: [ABORT] Exit debugger, returning to top level.

Backtrace:
  0: (MAKE-CONDITION NS-MAIL2ZD::UNKNOWN-ZONE :TEXT "LOL")
  1: (ERROR NS-MAIL2ZD::UNKNOWN-ZONE :TEXT "LOL")
  2: (NS-MAIL2ZD:PARSE-MIME-DATE "Wed, 14 Mar 2012 06:59:36 +1100")
  3: (SB-INT:SIMPLE-EVAL-IN-LEXENV (NS-MAIL2ZD:PARSE-MIME-DATE *LOL*) #<NULL-LEXENV>)
  4: (EVAL (NS-MAIL2ZD:PARSE-MIME-DATE *LOL*))
 --more--

Then I page down to the frame:

Backtrace:
  0: (MAKE-CONDITION NS-MAIL2ZD::UNKNOWN-ZONE :TEXT "LOL")
  1: (ERROR NS-MAIL2ZD::UNKNOWN-ZONE :TEXT "LOL")
      Locals:
        SB-KERNEL::ARGUMENTS = (:TEXT "LOL")
        SB-KERNEL::DATUM = NS-MAIL2ZD::UNKNOWN-ZONE
  2: (NS-MAIL2ZD:PARSE-MIME-DATE "Wed, 14 Mar 2012 06:59:36 +1100")

Now I hit e to invoke sldb-eval-in-frame and type last-space, as that should be available where the error was signaled.

It seems this isn’t how it’s meant (?) to work:

The variable LAST-SPACE is unbound.
   [Condition of type UNBOUND-VARIABLE]

Restarts:
 0: [ABORT] Return to sldb level 1.
 1: [RETRY] Retry SLIME REPL evaluation request.
 2: [*ABORT] Return to SLIME's top level.
 3: [REMOVE-FD-HANDLER] Remove #<SB-IMPL::HANDLER INPUT on descriptor 7: #<CLOSURE (LABELS SWANK-BACKEND::RUN :IN SWANK-BACKEND:ADD-FD-HANDLER) {10030AD9FB}>>
 4: [ABORT] Exit debugger, returning to top level.

Backtrace:
  0: ((LAMBDA (#:G1144)) #<unavailable argument>)
 --more--

Is there a way to do what I want? Am I over-complicating matters?

Thanks!

---

Addendum: I’ve tried using (break) (this seems a tad more canonical), but I still can’t see let-bound variables with e. :<

Answer 1

Try using the complete name of the symbol (i.e. package::symbol-name) instead of just the symbol name (i.e. symbol-name). In the current case, maybe net.telent.date::last-space.

Also make sure that you compiled with debugging support set to maximum (for instance, try placing a (declaim (optimize debug)) before your function and recompile the file – C-c C-k).

Checking that the code you’re trying to debug has enough debug information: in the sldb window, put the cursor on the relevant line in the backtrace and press t – this should expand the frame and show values for all the locals. Pressing t again collapses the local frame information. If there is not enough debug information, you won’t see the local variables, but some made up names (such as SB-DEBUG:ARG-0 under SBCL). Inside the sldb window, if you press Enter with the cursor on a value, it will expand that value into an inspector window (useful if the value is a long list which is shown truncated).

Also, SLIME debugging support seems to vary with the implementation. The advice above works on SBCL under Linux, YMMV under different implementations.