newProcess debugging help

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

newProcess debugging help

Ron Teitelbaum
Hello all,

Is there a way to know that a method is being simulated in a debugger?  I
would like to have two different paths

thisContext isDebugging ifTrue: [aBlock value]
        ifFalse: [aBlock newProcess].

so that I can debug the new process without having to change the code and
remove the threading.  Or is there a better way to step through code that is
executing in a different thread?  It would be nice if when the debugger hit
a new thread it would simply open up a new debugger on that thread, then you
could keep stepping through either debugger.

Thanks,

Ron Teitelbaum


Reply | Threaded
Open this post in threaded view
|

Re: newProcess debugging help

Bert Freudenberg
Ron Teitelbaum schrieb:
> Hello all,
>
> Is there a way to know that a method is being simulated in a debugger?  I
> would like to have two different paths
>
> thisContext isDebugging ifTrue: [aBlock value]
> ifFalse: [aBlock newProcess].
 >
> so that I can debug the new process without having to change the code and
> remove the threading.  Or is there a better way to step through code that is
> executing in a different thread?  It would be nice if when the debugger hit
> a new thread it would simply open up a new debugger on that thread, then you
> could keep stepping through either debugger.

Actually, when you step into a #newProcess send, you should get a new
debugger (see ContextPart>>doPrimitive:method:receiver:args:). Maybe
this mechanism could be used to do something more intelligent:

   (primitiveIndex = 19) ifTrue:[
     meth == (BlockContext>>#newProcess) ifTrue: [
       ^self push: [receiver halt: 'New process'; value] newProcess].
     ...

If you now try to step into #newProcess, a new process is created that
raises a Halt when resumed. Alternatively, you could immediately open a
Debugger on the new process:

(primitiveIndex = 19) ifTrue:[
     meth == (BlockContext>>#newProcess) ifTrue: [
       | process |
       process := receiver newProcess.
       process step; step. "step "
       process debugWithTitle: 'New process'].
       ...

Here, you have to be careful not to resume the process in the original
debugger.

This interception of #newProcess will only work if you step "into" or
"through" a send, stepping "over" does not simulate the code but runs it
at full speed.

Anyway, that's the basic idea. I'm pretty sure you could do a lot more
if you grok contexts and processes. To be really useful you would have
to intercept waits, too.

- Bert -

Reply | Threaded
Open this post in threaded view
|

RE: newProcess debugging help

Ron Teitelbaum
Thanks for responding!  (Sometimes I feel like I'm talking to myself!)  

I'll have to look at your suggestions more closely.  I like that you were
interested in opening a second debugger.  It would be nice if when you step
into a new thread, the new debugger opens up, but the old one processes
through instead so that it could be continued also.

Thanks again!!

Ron Teitelbaum

> -----Original Message-----
> From: Bert Freudenberg [mailto:[hidden email]]
> Sent: Tuesday, September 05, 2006 10:12 AM
> To: [hidden email]; The general-purpose Squeak developers list
> Subject: Re: newProcess debugging help
>
> Ron Teitelbaum schrieb:
> > Hello all,
> >
> > Is there a way to know that a method is being simulated in a debugger?
> I
> > would like to have two different paths
> >
> > thisContext isDebugging ifTrue: [aBlock value]
> > ifFalse: [aBlock newProcess].
>  >
> > so that I can debug the new process without having to change the code
> and
> > remove the threading.  Or is there a better way to step through code
> that is
> > executing in a different thread?  It would be nice if when the debugger
> hit
> > a new thread it would simply open up a new debugger on that thread, then
> you
> > could keep stepping through either debugger.
>
> Actually, when you step into a #newProcess send, you should get a new
> debugger (see ContextPart>>doPrimitive:method:receiver:args:). Maybe
> this mechanism could be used to do something more intelligent:
>
>    (primitiveIndex = 19) ifTrue:[
>      meth == (BlockContext>>#newProcess) ifTrue: [
>        ^self push: [receiver halt: 'New process'; value] newProcess].
>      ...
>
> If you now try to step into #newProcess, a new process is created that
> raises a Halt when resumed. Alternatively, you could immediately open a
> Debugger on the new process:
>
> (primitiveIndex = 19) ifTrue:[
>      meth == (BlockContext>>#newProcess) ifTrue: [
>        | process |
>        process := receiver newProcess.
>        process step; step. "step "
>        process debugWithTitle: 'New process'].
>        ...
>
> Here, you have to be careful not to resume the process in the original
> debugger.
>
> This interception of #newProcess will only work if you step "into" or
> "through" a send, stepping "over" does not simulate the code but runs it
> at full speed.
>
> Anyway, that's the basic idea. I'm pretty sure you could do a lot more
> if you grok contexts and processes. To be really useful you would have
> to intercept waits, too.
>
> - Bert -



Reply | Threaded
Open this post in threaded view
|

Re: newProcess debugging help

Bert Freudenberg
That's what my first variant allows. It pushes a new process to the
stack, which becomes the result of the #newProcess send in the original
process. The second debugger is not opened immediately, but only when
the new process is resumed from the first debugger.

It would be nice if the second debugger would automatically step into
the forked block (that's what the doubled #step in the second variant
does). It is surely possible, but not with a one-liner like this I fear ;)

- Bert -

Ron Teitelbaum schrieb:

> Thanks for responding!  (Sometimes I feel like I'm talking to myself!)  
>
> I'll have to look at your suggestions more closely.  I like that you were
> interested in opening a second debugger.  It would be nice if when you step
> into a new thread, the new debugger opens up, but the old one processes
> through instead so that it could be continued also.
>
> Thanks again!!
>
> Ron Teitelbaum
>
>> -----Original Message-----
>> From: Bert Freudenberg [mailto:[hidden email]]
>> Sent: Tuesday, September 05, 2006 10:12 AM
>> To: [hidden email]; The general-purpose Squeak developers list
>> Subject: Re: newProcess debugging help
>>
>> Ron Teitelbaum schrieb:
>>> Hello all,
>>>
>>> Is there a way to know that a method is being simulated in a debugger?
>> I
>>> would like to have two different paths
>>>
>>> thisContext isDebugging ifTrue: [aBlock value]
>>> ifFalse: [aBlock newProcess].
>>  >
>>> so that I can debug the new process without having to change the code
>> and
>>> remove the threading.  Or is there a better way to step through code
>> that is
>>> executing in a different thread?  It would be nice if when the debugger
>> hit
>>> a new thread it would simply open up a new debugger on that thread, then
>> you
>>> could keep stepping through either debugger.
>> Actually, when you step into a #newProcess send, you should get a new
>> debugger (see ContextPart>>doPrimitive:method:receiver:args:). Maybe
>> this mechanism could be used to do something more intelligent:
>>
>>    (primitiveIndex = 19) ifTrue:[
>>      meth == (BlockContext>>#newProcess) ifTrue: [
>>        ^self push: [receiver halt: 'New process'; value] newProcess].
>>      ...
>>
>> If you now try to step into #newProcess, a new process is created that
>> raises a Halt when resumed. Alternatively, you could immediately open a
>> Debugger on the new process:
>>
>> (primitiveIndex = 19) ifTrue:[
>>      meth == (BlockContext>>#newProcess) ifTrue: [
>>        | process |
>>        process := receiver newProcess.
>>        process step; step. "step "
>>        process debugWithTitle: 'New process'].
>>        ...
>>
>> Here, you have to be careful not to resume the process in the original
>> debugger.
>>
>> This interception of #newProcess will only work if you step "into" or
>> "through" a send, stepping "over" does not simulate the code but runs it
>> at full speed.
>>
>> Anyway, that's the basic idea. I'm pretty sure you could do a lot more
>> if you grok contexts and processes. To be really useful you would have
>> to intercept waits, too.
>>
>> - Bert -
>