debugger in 2.0?

debugger in 2.0?

[Andy Wingo]

Hi Neil,

I am going over the debugger section in the manual, and realizing that I
duplicated a lot of your excellent work, and that the debugger situation
is really in an uncomfortable half-equilibrium. And indeed, we don't
debug as well on the expression level that we did in the past; I have
some thoughts about that, but I don't think they should hold back 2.0.

I wanted to write to say that I was considering combing (ice-9 debugger)
for salvageable code, and pulling things over to (system vm debug). I
would refactor the manual section as well. The VM debugger is not yet as
nice as yours was, but it does work, and is closer to the VM
implementation -- and the old one is broke. I feel bad about that, but
it is how it is.

Anyway, let me know if this is the wrong thing to do.

Cheers,

Andy
-- 
http://wingolog.org/

Re: debugger in 2.0?

[Andy Wingo]

On Sun 14 Mar 2010 22:15, Andy Wingo <wingo@pobox.com> 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.

Cheers,

Andy
-- 
http://wingolog.org/

Re: debugger in 2.0?

[Neil Jerram]

Andy Wingo <wingo@pobox.com> writes:

> On Sun 14 Mar 2010 22:15, Andy Wingo <wingo@pobox.com> 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/guile-devel@gnu.org/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

Re: debugger in 2.0?

[Neil Jerram]

Andy Wingo <wingo@pobox.com> writes:

> Hi Neil,

Hi Andy!

> I am going over the debugger section in the manual, and realizing that I
> duplicated a lot of your excellent work,

At least partly my fault for not being more in touch recently...

Incidentally, if you are thinking of (ice-9 debugger), I should point
out that that's not all my work; most of it already existed before I
joined Guile.

> and that the debugger situation
> is really in an uncomfortable half-equilibrium.

Yes, certainly.  But I think that was pretty inevitable, given the level
of core change for 2.0.

> And indeed, we don't
> debug as well on the expression level that we did in the past; I have
> some thoughts about that, but I don't think they should hold back 2.0.

I agree that they don't need to hold back 2.0.  We can add things back
during the 2.0.x series.  I guess we should be clear about the situation
in the release notes though.

> I wanted to write to say that I was considering combing (ice-9 debugger)
> for salvageable code, and pulling things over to (system vm debug).

Yes, that sounds good to me.

> I would refactor the manual section as well.

Even better!

> The VM debugger is not yet as
> nice as yours was, but it does work, and is closer to the VM
> implementation -- and the old one is broke. I feel bad about that, but
> it is how it is.
>
> Anyway, let me know if this is the wrong thing to do.

It's certainly right in the sense that the old stuff is broken, and so
some process is needed of seeing what can be reused from the 1.8 design
and code.

I actually made a bit of a start on this a few weeks ago when I was
looking at a UTF-16 problem, and I've just pushed this as
"wip-utf16-debugging" so that you can take a look.  I think the main
points of interest are:

- (gds-debug-vm) - attempt to connect the VM hooks to the GDS interface
  in Emacs

- updates in (ice-9 debugging traps) and (ice-9 gds-client) to cope with
  changes to frame-* API

- (ice-9 debugging new) - debugging by instrumentation instead of by
  using builtin hooks, as discussed a few weeks ago on the list

Please let me know if you think any of this is useful, and feel free to
incorporate in your own work.

When I was last working on this, the point that I reached was that the
VM->GDS hooks were working, but I was suffering from the lack (at the
time) of start-stack, and hence I was seeing too many hook calls from
infrastructure code before getting to the code that I was actually
trying to debug.  I guess that should be fixable now that start-stack is
back.

      Neil