newProcess debugging help
Locked
 
|
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 |
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 - |
|
|
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 - |
Re: newProcess debugging help
|
|
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 - > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |