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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150129/5b4f3cd5/attachment-0001.htm