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
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 -
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:bert@freudenbergs.de] Sent: Tuesday, September 05, 2006 10:12 AM To: Ron@USMedRec.com; 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 -
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:bert@freudenbergs.de] Sent: Tuesday, September 05, 2006 10:12 AM To: Ron@USMedRec.com; 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 -
squeak-dev@lists.squeakfoundation.org