Process-specific state difficult to debug...
Locked
Process-specific state difficult to debug...
 
|
Hi!
There are process-specific variables. However, #doStep in Debugger does #completeStep: on the process object and Processor >> #activeProcess will be wrong during that execution. Is this a general problem of global state or could we fix that somehow? Best, Marcel |
Re: Process-specific state difficult to debug...
|
Hi
On 29.01.2015, at 09:50, Marcel Taeumel <[hidden email]> wrote: > Hi! > > There are process-specific variables. However, #doStep in Debugger does > #completeStep: on the process object and Processor >> #activeProcess will be > wrong during that execution. > > Is this a general problem of global state or could we fix that somehow? The same problem exists for DynamicVariables that are not implemented with process-specific variables but with Notifications. Just want to throw that in :) Best -Tobias |
Re: Process-specific state difficult to debug...
|
|
On 29.01.2015, at 10:06, Tobias Pape <[hidden email]> wrote: > Hi > > On 29.01.2015, at 09:50, Marcel Taeumel <[hidden email]> wrote: > >> Hi! >> >> There are process-specific variables. However, #doStep in Debugger does >> #completeStep: on the process object and Processor >> #activeProcess will be >> wrong during that execution. >> >> Is this a general problem of global state or could we fix that somehow? > > The same problem exists for DynamicVariables that are not implemented with > process-specific variables but with Notifications. Just want to throw that > in :) To clarify, for example WADynamicVariable from Seaside. Best -Tobias |
|
|
In reply to this post by marcel.taeumel (old)
I don't know much about it, but I've been poking around there recently in Pharo, so maybe I can l learn something more looking at this. Can you be specific about the specific variable you are referring to? And can you report a short script for others to test against to get to the point of your question? cheers - On Thu, Jan 29, 2015 at 4:50 PM, Marcel Taeumel <[hidden email]> wrote: Hi! |
Re: Process-specific state difficult to debug...
|
|
In reply to this post by Tobias Pape
On 29 January 2015 at 09:06, Tobias Pape <[hidden email]> wrote:
> Hi > > On 29.01.2015, at 09:50, Marcel Taeumel <[hidden email]> wrote: > >> Hi! >> >> There are process-specific variables. However, #doStep in Debugger does >> #completeStep: on the process object and Processor >> #activeProcess will be >> wrong during that execution. >> >> Is this a general problem of global state or could we fix that somehow? > > The same problem exists for DynamicVariables that are not implemented with > process-specific variables but with Notifications. Just want to throw that > in :) Yes: debugging with dynamic variables is Hard(tm), regardless of whether nice (delimited, through Notifications) or nasty (undelimited, through ProcessSpecificVariable), because you typically want the value of the variable in the context in which the code under debug is running, but asking it "what is your value?" returns the value of the variable in the context of the debugger. Which I guess is the answer: the debugger needs to recognise you're working with a dynamic variable, and it must perform that current-value-lookup in the correct context (that of the process you're debugging). frank > Best > -Tobias |
Re: Process-specific state difficult to debug...
|
|
On 29 January 2015 at 16:22, Frank Shearar <[hidden email]> wrote:
> On 29 January 2015 at 09:06, Tobias Pape <[hidden email]> wrote: >> Hi >> >> On 29.01.2015, at 09:50, Marcel Taeumel <[hidden email]> wrote: >> >>> Hi! >>> >>> There are process-specific variables. However, #doStep in Debugger does >>> #completeStep: on the process object and Processor >> #activeProcess will be >>> wrong during that execution. >>> >>> Is this a general problem of global state or could we fix that somehow? >> >> The same problem exists for DynamicVariables that are not implemented with >> process-specific variables but with Notifications. Just want to throw that >> in :) > > Yes: debugging with dynamic variables is Hard(tm), regardless of > whether nice (delimited, through Notifications) or nasty (undelimited, > through ProcessSpecificVariable), because you typically want the value > of the variable in the context in which the code under debug is > running, but asking it "what is your value?" returns the value of the > variable in the context of the debugger. > > Which I guess is the answer: the debugger needs to recognise you're > working with a dynamic variable, and it must perform that > current-value-lookup in the correct context (that of the process > you're debugging). Oh, I should add: I usually pin the (current) value of the dynamic variable down by assigning its value to a local variable. It's invasive, but it does work. frank > >> Best >> -Tobias |
Re: Process-specific state difficult to debug...
|
|
In reply to this post by marcel.taeumel (old)
Hi Marcel, can you give a specific example? Andreas and I came up with a solution for accessing Processor activeProcess correctly in the debugger. It works like this: ProcessorScheduler>>activeProcess ^activeProcess effectiveProcess Process>>effectiveProcess "effectiveProcess is a mechanism to allow process-faithful debugging. The debugger executes code on behalf of processes, so unless some effort is made the identity of Processor activeProcess is not correctly maintained when debugging code. The debugger uses evaluate:onBehalfOf: to assign the debugged process as the effectiveProcess of the process executing the code, preserving process identity." ^effectiveProcess ifNil: [self] Process>>evaluate: aBlock onBehalfOf: aProcess "Evaluate aBlock setting effectiveProcess to aProcess. Used in the execution simulation machinery to ensure that Processor activeProcess evaluates correctly when debugging." | oldEffectiveProcess | oldEffectiveProcess := effectiveProcess. effectiveProcess := aProcess. ^aBlock ensure: [effectiveProcess := oldEffectiveProcess] and then in activateReturn:value: complete: popTo: popTo:value: return:value: step step: stepToCallee stepToSendOrReturn it is used as in Process>>step ^Processor activeProcess evaluate: [suspendedContext := suspendedContext step] onBehalfOf: self Perhaps all that is needed is the access of process-specific variables to use effectiveProcess? On Thu, Jan 29, 2015 at 12:50 AM, Marcel Taeumel <[hidden email]> wrote: Hi! best,
Eliot |
Re: Process-specific state difficult to debug...
|
|
That would help, but it seems like the effectiveProcess variable is not
set correctly. At least I don't see it being set while debugging the following: | ep | ep := Processor activeProcess instVarNamed: #effectiveProcess. self haltIf: ep isNil Levente On Thu, 29 Jan 2015, Eliot Miranda wrote: > Hi Marcel, > can you give a specific example? Andreas and I came up with a solution for accessing Processor activeProcess correctly in the debugger. It works like this: > > ProcessorScheduler>>activeProcess > ^activeProcess effectiveProcess > > Process>>effectiveProcess > "effectiveProcess is a mechanism to allow process-faithful debugging. The debugger executes code > on behalf of processes, so unless some effort is made the identity of Processor activeProcess is not > correctly maintained when debugging code. The debugger uses evaluate:onBehalfOf: to assign the > debugged process as the effectiveProcess of the process executing the code, preserving process > identity." > ^effectiveProcess ifNil: [self] > > Process>>evaluate: aBlock onBehalfOf: aProcess > "Evaluate aBlock setting effectiveProcess to aProcess. Used > in the execution simulation machinery to ensure that > Processor activeProcess evaluates correctly when debugging." > | oldEffectiveProcess | > oldEffectiveProcess := effectiveProcess. > effectiveProcess := aProcess. > ^aBlock ensure: [effectiveProcess := oldEffectiveProcess] > > and then in activateReturn:value: complete: popTo: popTo:value: return:value: step step: stepToCallee stepToSendOrReturn it is used as in > > Process>>step > > ^Processor activeProcess > evaluate: [suspendedContext := suspendedContext step] > onBehalfOf: self > > Perhaps all that is needed is the access of process-specific variables to use effectiveProcess? > > On Thu, Jan 29, 2015 at 12:50 AM, Marcel Taeumel <[hidden email]> wrote: > Hi! > > There are process-specific variables. However, #doStep in Debugger does > #completeStep: on the process object and Processor >> #activeProcess will be > wrong during that execution. > > Is this a general problem of global state or could we fix that somehow? > > Best, > Marcel > > > > -- > View this message in context: http://forum.world.st/Process-specific-state-difficult-to-debug-tp4802422.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. > > > > > -- > best,Eliot > > |
Re: Process-specific state difficult to debug...
|
|
Hi Levente,
On Thu, Jan 29, 2015 at 10:29 AM, Levente Uzonyi <[hidden email]> wrote: That would help, but it seems like the effectiveProcess variable is not set correctly. At least I don't see it being set while debugging the following: That is correct behavior. effectiveProcess is only ever non-nil in the process the debugger is using to run code on behalf of another. In a normal process effectiveProcess is always nil, and therefore the effectiveProcess is the process itself. Try this instead, stepping over the second environment access. If you look at the stack top you'll see it is #present. Processor activeProcess environmentAt: #foo put: #present. self halt. Processor activeProcess environmentAt: #foo Try it without the System-eem.699 changes and you'll get the environment key not found error. Levente best,
Eliot |
Re: Process-specific state difficult to debug...
|
|
On Thu, Jan 29, 2015 at 12:29 PM, Eliot Miranda <[hidden email]> wrote:
Hmmm. Perhaps a better fix would be to install the debugged process's env in the debugger's process during evaluate:onBehalfOf:
best,
Eliot |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |