From: Neil Jerram <neil@ossau.uklinux.net>
To: Andy Wingo <wingo@pobox.com>
Cc: guile-devel <guile-devel@gnu.org>,
Neil Jerram <neiljerram@googlemail.com>
Subject: Re: debugger in 2.0?
Date: Tue, 16 Mar 2010 21:48:41 +0000 [thread overview]
Message-ID: <87vdcwq6o6.fsf@ossau.uklinux.net> (raw)
In-Reply-To: <m3mxya61vn.fsf@pobox.com> (Andy Wingo's message of "Sun, 14 Mar 2010 22:15:40 +0100")
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
prev parent reply other threads:[~2010-03-16 21:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-14 21:15 debugger in 2.0? Andy Wingo
2010-03-14 22:02 ` Andy Wingo
2010-03-16 23:36 ` Neil Jerram
2010-03-16 21:48 ` Neil Jerram [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vdcwq6o6.fsf@ossau.uklinux.net \
--to=neil@ossau.uklinux.net \
--cc=guile-devel@gnu.org \
--cc=neiljerram@googlemail.com \
--cc=wingo@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).