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

Eliot Miranda eliot.miranda at gmail.com
Wed May 2 23:27:31 UTC 2012

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

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


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

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

More information about the Vm-dev mailing list