[gambit-list] Debugging

Christian christian at pflanze.mine.nu
Sat Jan 14 16:15:00 EST 2006


In beta 17, it seems that the leap operation in the debugger still
doesn't work as it should, right? Can this be fixed?

Ideas on some other things which could be useful for a good debugging

- easily redefine functions which have been defined in the interpreter
to use non-tail calls: something like

(define (function-proper-tail-calls-set! name true?)
  (let ((code (##decompile (eval name))))
    (if (pair? code)
	(parameterize ((generate-proper-tail-calls true?))
	  (eval `(define ,name ,code)))
	(error "not an interpreted procedure:" name code))))

; > (define (f n) (if (<= n 0) (error "fin") (f (- n 1))))
; > (f 10)
; *** ERROR IN (console)@10.1 -- fin
; 1>
; ctl-d
; > (function-proper-tail-calls-set! 'f #f)
; > (f 10)
; *** ERROR IN f -- fin
; 1> 

Ok this works so far, but it would be nice if it would keep location
information, and probably also if it would act on the lambda itself,
instead of on one particular binding of the lambda.

- could regions of code, either lexically or dynamically scoped, be
made un-stepped? I'm currently using compilation to prevent the
debugger from single-stepping code which I know works, and in general
this makes sense. But in some cases (like when adding new code to an
existing module) I can't compile the old/working/uninteresting
functions without moving them to another file, which may be tedious,
so a simple (function-step-set! foo #f) or something similar to
achieve the same effect would be nice.

- keep the continuations of each step of a calculation in a list which
can be inspected. For "going back in time" (will work sensibly only
for purely functional code, of course). Something like:

  ;; switch on tracking:
  ;; or (step/track 10) for limiting the length of the backtrack to 10
  ;;    steps
  ;; or (track 10) for tracking the execution path without switching
  ;;    on single stepping
  ;; re-run program from 10 steps before now:
  ((list-ref (current-track-head) 10) "someval") 

Well those "continuations" might not actually take a value [by
default] but store the value from the previous calculation

Once that is in place, the debugger might even provide a back-step


(BTW note that (with b17) unlike ctrl-d, entering ,s into the repl
terminates the running system without safety question. Ok, ,q does
that too. Might be friendlier? But ok, I guess I'll go for running
repl's in separate threads anyway in the future (attach to a running
system through a socket), probably, then it won't matter.)

PS. can I compile gambit so that it works safely in all places and
doesn't crash if I feed the wrong data to some internal function?  And
can I compile it with the '(debug) compiler option enabled?

More information about the Gambit-list mailing list