Help with processes and debugger

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Help with processes and debugger

F.Balaguer
Hello,

I am working on a couple of tools that do tracing. You can think of them
as a debugger that creates an execution tree. I took almost everything
from the OA's Debugger and Ian's Profiler.
One of them is a GUI-less tool that gets a block as a parameter and
traces it evaluation.

The problem I have with this particular one is that I am not able to
make the tool "step into" the next context automatically.
Here is the #break: method on class Tracer

break: interruptFrame

        self beBroken.
        self isInCompositeOp
                ifTrue:
                        [topFrame := interruptFrame.
                        breakAction postToInputQueue.
                        breakAction := nil]
                ifFalse:
                        [
                        (topFrame = interruptFrame and: [topFrame index <= interruptFrame
index])
                                ifFalse: [topFrame := interruptFrame]].
        isTracing ifTrue: [self addFrameToTrace: interruptFrame].
        "self suspend"
        self stepInFrame: interruptFrame
        "N.B. There must be no further code after this point"

It doesn't work. My guess is that the tracer end ups tracing itself (in
an infinite loop). So can anyone can give ideas of how to do it?

Thanks! Federico


Reply | Threaded
Open this post in threaded view
|

Re: Help with processes and debugger

Blair McGlashan
"Federico Balaguer" <[hidden email]> wrote in message
news:9UEgb.503$[hidden email]...

>
> I am working on a couple of tools that do tracing. You can think of them
> as a debugger that creates an execution tree. I took almost everything
> from the OA's Debugger and Ian's Profiler.
> One of them is a GUI-less tool that gets a block as a parameter and
> traces it evaluation.
>
> The problem I have with this particular one is that I am not able to
> make the tool "step into" the next context automatically.
> Here is the #break: method on class Tracer
>...[snip]...

I admire your nerve - this will not be an easy task.
Without seeing a lot more detail the only thing I can suggest is that you
follow the instruction in the comment "There must be no further code after
this point" to the letter. It means there must be no further code executed
except for any returns from the methods back to the #onStep: interrupt
handler. If there is then it is possible that the step interrupt will occur
while executing that code, and (as you suggest) you may then end up in a
infinite loop.

Regards

Blair


Reply | Threaded
Open this post in threaded view
|

Re: Help with processes and debugger

F.Balaguer
Blair,

Thanks for your comments. Reading now my message I can see that it was
written from my desasperation :-).

I was able to handle the problem. I (again ) mimic OA code on the way
animation is handled in the debugger.

Hopefully I will be able to clean up the code and make it public soon.

Federico

Blair McGlashan wrote:

> "Federico Balaguer" <[hidden email]> wrote in message
> news:9UEgb.503$[hidden email]...
>
>>I am working on a couple of tools that do tracing. You can think of them
>>as a debugger that creates an execution tree. I took almost everything
>>from the OA's Debugger and Ian's Profiler.
>>One of them is a GUI-less tool that gets a block as a parameter and
>>traces it evaluation.
>>
>>The problem I have with this particular one is that I am not able to
>>make the tool "step into" the next context automatically.
>>Here is the #break: method on class Tracer
>>...[snip]...
>
>
> I admire your nerve - this will not be an easy task.
> Without seeing a lot more detail the only thing I can suggest is that you
> follow the instruction in the comment "There must be no further code after
> this point" to the letter. It means there must be no further code executed
> except for any returns from the methods back to the #onStep: interrupt
> handler. If there is then it is possible that the step interrupt will occur
> while executing that code, and (as you suggest) you may then end up in a
> infinite loop.
>
> Regards
>
> Blair
>
>