Re: debugger in 2.0?

[Neil Jerram]

Andy Wingo <address@hidden> writes:

> On Sun 14 Mar 2010 22:15, Andy Wingo <address@hidden> writes:
>
>> I wanted to write to say that I was considering combing (ice-9 debugger)
>> for salvageable code
>
> ISTR You mentioned once that you weren't comfortable with the OO traps
> layer (or was that breakpoints?) -- actually could you clarify that? The
> interfaces look good to me.

It was the breakpoint layer that I became unhappy with during 1.8.x.  I
wrote about that here:
http://www.mail-archive.com/address@hidden/msg03081.html,

I think the traps layer is more or less OK.  As you say, I think the
interface is mostly clear.  If I have concerns, they are that

- it could be too heavy (at runtime) because of using GOOPS - TBH I
  don't have a feel right now for how heavy GOOPS usage is in practice

- in the 1.8 implementation, based on the 1.8 low-level evaluator traps
  interface, a heck of lot of layering code is needed to get up from
  that interface to something that is useful at the OO level
  (set-debug-and-trap-options, *-handler, run-traps, ...).

I see now that the second point comes from the 1.8 low-level interface
being so simple.  I.e. it doesn't allow you to say "when you start
executing THIS function, call THAT breakpoint proc".  It only allows
"when you start executing ANY ONE of the functions that I've set a
breakpoint mark on, call a handler proc that has to be the same for all
of them, and is also the same as when a couple of other types of low
level trap occur - oh, and without any unambiguous closure data".

:-)

This is one of the things that was leading me recently to favour
instrumentation-based debugging - because obviously the
instrumentation/compilation process can insert whatever closure/context
it wants.  But alternatively we could just try to make whatever new hook
interface there is (presumably the VM hooks) a bit richer.

I hope that's all of some use.  Let me know if you have any comments or
further questions.

       Neil