[Vm-dev] Re: [squeak-dev] Re: [Pharo-project] problem with tempNamed: in Pharo 2.0

[Eliot Miranda]

On Wed, May 2, 2012 at 12:31 AM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

>
>
>>
>>> Actually, we do have:
>>>
>>> namedTempAt: index
>>>     "Answer the value of the temp at index in the receiver's sequence of
>>> tempNames."
>>>     ^self debuggerMap namedTempAt: index in: self
>>>
>>> and
>>>
>>> namedTempAt: index put: aValue
>>>     "Set the value of the temp at index in the receiver's sequence of
>>> tempNames.
>>>      (Note that if the value is a copied value it is also set out along
>>> the lexical chain,
>>>       but alas not in along the lexical chain.)."
>>>     ^self debuggerMap namedTempAt: index put: aValue in: self
>>>
>>> so, if I understand correctly all we need to do is to fix tempNamed: and
>>> tempNamedPut: so that the delegate to namedTempAt: and namedTempPut: rather
>>> than to tempAt: and tempAtPut:   ?
>>>
>>
>> Yes.
>>
>>
>
> Now I was thinking, what happens with the rest of the senders of tempAt:
> and tempAtPut: ?  do I need to do something with them?
>

Let me answer more carefully.  It depends.  For example, uses of tempAt: in
ContextPart used to simulate the bytecode set are correct.  Uses in the
Debugger are likely correct.  When I look in Squeal trunk 4.3 I an see all
but one uses are correct and one, DiskProxy>comeUpFullyOnReload:, is just
scary:

(DataStream compiledMethodAt: #readArray)]) ifTrue: [
arrayIndex := (thisContext sender sender sender sender) tempAt: 4.

 :)


> Thanks
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120502/ad9faf1e/attachment.htm