Re: Question about (debug-enable 'trace) vs (trap-enable ...)

[Mikael Djurfeldt]

Rob Browning <address@hidden> writes:

> I'm trying to see if I can get a fairly simple (though good enough for
> our needs) profiler up and working using your debug.scm as a guide.
> 
> I've gotten a trivial (empty) framework up and working using
> (debug-enable 'trace), but for my first attempt I thought perhaps it
> would be better to just use 
> 
>   (trap-enable 'apply-frame)
>   (trap-enable 'exit-frame)
> 
> directly, and perform my checking inside my handlers.  Of course now I
> realize that's going to be a lot slower than using the trace
> infrastructure, but I still was curious if that would even be a viable
> approach.  It seemed not since defining apply-frame and exit frame
> would just crash guile.  I presume that's because I was causing
> infinite recursion by executing any code inside the handlers.  Is that
> a correct analysis?

There shouldn't be a crash, but, of course, if you don't do anything
special, the handlers will be invoked also by the code in the
handlers, so, yes, you can get an infinite recursion.  There's a
special primitive, "with-traps" I think, for enabling the traps only
in the code to be debugged/profiled.

There's also a bug in one of the logical expressions in the debugging
code of the evaluator.  I have committed or will commit a fix for this.

As I've said, I have a working profiler, with all bells and whistles,
but I'd like to replace some code with C to get reasonable speed.
I'll try to mail you what I have right now tomorrow evening or so, and
will *try* to get time to finish it during this weekend.

Best,
/mdj