Hello
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 experience:
- 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: (step/track) ;; 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 (run-some-code) ... ;; 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 automatically.
Once that is in place, the debugger might even provide a back-step operation.
Thanks Christian.
(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?