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?
Afficher les réponses par date
On Jan 14, 2006, at 3:15 PM, Christian wrote:
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.
Doesn't
(proper-tail-calls-set! #f)
do what you want? Do this before loading interpreted code you don't want to use tail calls.
Brad
At 15:39 Uhr -0600 14.01.2006, Bradley Lucier wrote:
On Jan 14, 2006, at 3:15 PM, Christian wrote:
(parameterize ((generate-proper-tail-calls true?))
..
Doesn't
(proper-tail-calls-set! #f)
do what you want? Do this before loading interpreted code you don't want to use tail calls.
Sure, that's what the above code is using underneath; Marc has changed the proper-tail-calls-set! function to be a generate-proper-tail-calls parameter.
What I want is change the tco property without having to reload code from a file. And if it would be acting on the function (the lambda) itself instead of on the binding, it would also change that reference which has been taken by another part of the running system. (Am I still explaining myself complicated? Imagine: (define (fun a b) .....) (define (make-g f) (lambda (x) (f x))) (define g (make-g fun)) Now reload fun with tco disabled (or apply my function-proper-tail-calls-set! operation). It will not change the workings of the version of fun trapped in g. But you might actually want that.)
Ah by the way: I've forgotten one thing on my debugging "wishlist":
- being able to set break points into a running program. (And an emacs interface for it.)
BTW if given the ability to read the souce code with location information from an interpreted function, one could also compile that function into the running system, like you can with common lisp systems (I may then add the functionality for that to chjmodule).
Christian.
-
Bradley Lucier -
Christian