Re: guile-debugging and breakpoints

[Volkan YAZICI]

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.