On Thu, Jan 29, 2015 at 12:29 PM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

> Hi Levente,
>
> On Thu, Jan 29, 2015 at 10:29 AM, Levente Uzonyi <leves at elte.hu> 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:
>>
>> | ep |
>> ep := Processor activeProcess instVarNamed: #effectiveProcess.
>> self haltIf: ep isNil
>
>
> 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.
>

Hmmm.  Perhaps a better fix would be to install the debugged process's env
in the debugger's process during evaluate:onBehalfOf:


>
> 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 <
>>> marcel.taeumel at student.hpi.uni-potsdam.de> 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
>>>
>>>
>>
>>
>>
>
>
> --
> best,
> Eliot
>



-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150129/83783ef0/attachment.htm