On Jan 14 01:01, Neil Jerram wrote: > With Guile 1.8 or CVS, I find that the breakpoint doesn't even work > the first time! I'm still looking into that.
I use Guile from cvs tip too. And after you asked for "Where did you place the new breakpoint?" I realized that the problem is with putting the breakpoint on an IF s-exp. IMHO, more importantly, what are the available places that we can safely place a breakpoint. For instance, in (define (foo ...)) or (define foo (lambda ...)) example, where should I place my breakpoint to make it stop at FOO calls. Maybe some words about this in the gds-tutorial.txt would be nice. > > I don't think there's any use case for setting many breakpoints in a > > region. Because, once user gets stopped in the first breakpoint of the > > beginning of a region of breakpoints, he/she can move forward by > > stepping. There's no need to stop at the next s-exp. > > OK, you've persuaded me on this - but I'm not sure it addresses the > whole problem. I still think it might be useful to be able to set a > breakpoint on a procedure by doing C-x SPC anywhere in the procedure's > definition - which conflicts with your backward-up-list > interpretation. What do you recommend? What about defining a new `set' of bindings for placing a breakpoint: ;;; A generic internal method to set a breakpoint. (define (gds-set-breakpoint type) ...) ;;; Set a breakpoint to the current s-exp cursor is currently in. ;;; Example binding: C-c C-b s (define (gds-set-breakpoint-on-sexp) (gds-set-breakpoint 's-exp)) ;;; Set a breakpoint to the outmost DEFINE s-exp. ;;; Example binding: C-c C-b d (define (gds-set-breakpoint-on-def) (gds-set-breakpoint 'def)) BTW, is it possible to handle exceptions in a more fancy way. For instance: (define (inc n) (+ n 1)) (inc "str") ;;; Evaluating in current module (guile-user) EXCEPTION: wrong-type-arg ("+" "Wrong type argument in position ~A: ~S" (1 "str") ("str")) => unhandled-exception-in-evaluation Yes, it's not possible to make GDS understand all of the thrown exceptions, but at least we should be able to place some hooks for the known exceptions. (Like in this example, wrong-type-arg exception.) IMHO, we can at least use OBJECT->STRING to place given arguments into the error string and print whole information in a more fancy style. If you agree on this idea, I'm volunteered to prepare a patch for this if you'd give me an example about how can I place such a hook. (And this will be the only step to take to make people be able to place their own fancy-exception-printing handler hooks.) Regards. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user