guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debugging plans


From: Martin Grabmueller
Subject: Re: Debugging plans
Date: Fri, 29 Jun 2001 10:31:51 +0200 (MET DST)

> From: Neil Jerram <address@hidden>
> Date: 28 Jun 2001 22:44:17 +0100
> 
> I think a nice general way of specifying a breakpoint is a procedure
> that gets the current stack and can decide, by examining that stack,
> whether to drop into the debugger, display some variable, etc.  So the
> signature for such procedures is (lambda (stack) ...).
> 
> This allows for many kinds of breakpoint specification, for example
> 
> (define (in proc)
>   (lambda (stack)
>     (if (eq? (frame-procedure (stack-current-frame stack)) proc)
>         (debug-stack stack))))
> 
> (define (at file line)
>   (lambda (stack)
>     (let ((source-properties (... stack)))
>       (if ... ; file and line match those in source-properties
>           (debug-stack stack)))))
> 
> (define (watch expr)
>   (let ((last-value #f))
>     (lambda (stack)
>       (let ((value (eval expr)))
>         (or (equal? value last-value)
>             (begin
>               (set! last-value value)
>               (debug-stack stack)))))))

I like this very much.  It's schemey and looks like it's quite
flexible.

> (Perhaps it would be better if these procedures simply returned non-#f
> to indicate that their caller should then do (debug-stack stack); this
> way the procedures could be logically composed.)

I'm not sure about it.  Maybe we should try out the #f/non-#f
returning variants first, because it offers more flexibility.

> To link such procedures with the evaluator traps mechanism, I propose
> to change the current apply-, enter- and exit-frame-handlers to hooks
> (defined in C and visible from Scheme) to which users can add such
> procedures using add-hook!.  (Hmm... not sure exactly what the
> parameter list should be for these hooks; currently the handlers are
> given more than just a debug object - do they need the other
> parameters?)

Hmm, don't know about that.  I haven't looked into debugger.scm
closely yet.

> Things like gdb's `tb +1' could be done by adding a hook procedure
> that automatically removed itself after being called once.  Does
> anyone know how to implement a hook procedure that can remove itself?

First I thought about implementing the hook procedures like this

(define (step n)
  (let ((calls 0))
    (lambda (hook self stack)
      (set! calls (1+ calls))
      (if (= step calls)
        (begin
          (remove-hook! hook self)
          #t   ; return #t  to invoke the debugger
          )
        #f   ; return #f not to invoke the debugger
        ))))

and then install them as hooks

(add-hook! enter-frame-hook (step 5) #t)

and call them from the evaluator, somethink like that

(run-hook enter-frame-hook enter-frame-hook proc)

but then I noticed that `proc' above is not known, because it is any
of the elements of the hook.  Hmmm.  It seems that the hook
implementation is not the Right Thing for breakpoints.

Another possibility would be that the breakpoint procedures do not
remove themselves from the hook but rather disable themselves when
they don't want to be called again.  This could be done with a simple
flag variable.

Don't know if all this helps, but you asked for it.

Regards,
  'martin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]