<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 29, 2015 at 12:29 PM, Eliot Miranda <span dir="ltr">&lt;<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Levente,<div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Jan 29, 2015 at 10:29 AM, Levente Uzonyi <span dir="ltr">&lt;<a href="mailto:leves@elte.hu" target="_blank">leves@elte.hu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">That would help, but it seems like the effectiveProcess variable is not set correctly. At least I don&#39;t see it being set while debugging the following:<br>
<br>
| ep |<br>
ep := Processor activeProcess instVarNamed: #effectiveProcess.<br>
self haltIf: ep isNil</blockquote><div><br></div></span><div>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&#39;ll see it is #present.</div><div><br></div><div><div>Processor activeProcess environmentAt: #foo put: #present.</div><div>self halt.</div><div>Processor activeProcess environmentAt: #foo</div></div><div><br></div><div>Try it without the System-eem.699 changes and you&#39;ll get the environment key not found error.</div></div></div></div></blockquote><div><br></div><div>Hmmm.  Perhaps a better fix would be to install the debugged process&#39;s env in the debugger&#39;s process during evaluate:onBehalfOf:</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><font color="#888888">Levente</font></span><div><div><br>
<br>
On Thu, 29 Jan 2015, Eliot Miranda wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi Marcel,<br>
    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:<br>
<br>
ProcessorScheduler&gt;&gt;<u></u>activeProcess<br>
    ^activeProcess effectiveProcess<br>
<br>
Process&gt;&gt;effectiveProcess<br>
&quot;effectiveProcess is a mechanism to allow process-faithful debugging.  The debugger executes code<br>
on behalf of processes, so unless some effort is made the identity of Processor activeProcess is not<br>
correctly maintained when debugging code.  The debugger uses evaluate:onBehalfOf: to assign the<br>
debugged process as the effectiveProcess of the process executing the code, preserving process<br>
identity.&quot;<br>
^effectiveProcess ifNil: [self]<br>
<br>
Process&gt;&gt;evaluate: aBlock onBehalfOf: aProcess<br>
&quot;Evaluate aBlock setting effectiveProcess to aProcess.  Used<br>
in the execution simulation machinery to ensure that<br>
Processor activeProcess evaluates correctly when debugging.&quot;<br>
| oldEffectiveProcess |<br>
oldEffectiveProcess := effectiveProcess.<br>
effectiveProcess := aProcess.<br>
^aBlock ensure: [effectiveProcess := oldEffectiveProcess]<br>
<br>
and then in activateReturn:value: complete: popTo: popTo:value: return:value: step step: stepToCallee stepToSendOrReturn it is used as in<br>
<br>
Process&gt;&gt;step<br>
<br>
^Processor activeProcess<br>
evaluate: [suspendedContext := suspendedContext step]<br>
onBehalfOf: self<br>
<br>
Perhaps all that is needed is the access of process-specific variables to use effectiveProcess?<br>
<br>
On Thu, Jan 29, 2015 at 12:50 AM, Marcel Taeumel &lt;<a href="mailto:marcel.taeumel@student.hpi.uni-potsdam.de" target="_blank">marcel.taeumel@student.hpi.<u></u>uni-potsdam.de</a>&gt; wrote:<br>
      Hi!<br>
<br>
      There are process-specific variables. However, #doStep in Debugger does<br>
      #completeStep: on the process object and Processor &gt;&gt; #activeProcess will be<br>
      wrong during that execution.<br>
<br>
      Is this a general problem of global state or could we fix that somehow?<br>
<br>
      Best,<br>
      Marcel<br>
<br>
<br>
<br>
      --<br>
      View this message in context: <a href="http://forum.world.st/Process-specific-state-difficult-to-debug-tp4802422.html" target="_blank">http://forum.world.st/Process-<u></u>specific-state-difficult-to-<u></u>debug-tp4802422.html</a><br>
      Sent from the Squeak - Dev mailing list archive at Nabble.com.<br>
<br>
<br>
<br>
<br>
--<br>
best,Eliot<br>
<br>
</blockquote>
</div></div><br><br>
<br></blockquote></div></div></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div>best,<div>Eliot</div></div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div></div>