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

[Rob Browning]

Mikael Djurfeldt <address@hidden> writes:

> 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.

Right, the crash comes when the stack overflows, I suspect.

> There's a special primitive, "with-traps" I think, for enabling the
> traps only in the code to be debugged/profiled.

I suppose it would also be sufficient to be able to turn off tracing
while in my apply/exit handler, but I wonder if I could even make the
call to turn it off without causing an infinite recursion...

> 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.

Ahh.  Is this a bug that would prevent a simple scheme-only profiler
written using 'trace from working at all?  Though it would be nice to
have the fancy profiler you mention below, short-term it would also be
helpful to have a small, "dumb" (and maybe slow) profiler that's just
scheme code that'll work with guile 1.4.  That way I can commit the
source to the gnucash tree and and people can use the dumb profiler
without having to migrate to guile CVS.

> 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.

Well, if you've got other things that you need to do, don't let me
push you.  I'm happy to keep playing around a bit longer, and if I
can't get anything working soon, I can just go do something else for a
while.  I just wanted to see if I could get something simple working
immediately.

And as I mentioned above, there would be some short-term merit to a
scheme only (1.4 compatible) profiler for us, so I don't mind spending
a little effort in the attempt if it's likely to work at all.

PS: I was a little surprised that the frame-procedure in the exit
handler call was not the same as the frame-procedure in the apply
call, but I guess as long as I can presume proper nesting, I should be
able to match the apply/exit pairs up.

Thanks

-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930