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