[Vm-dev] Re: [squeak-dev] Re: [Pharo-project] problem with
tempNamed: in Pharo 2.0
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
>>> ^self debuggerMap namedTempAt: index in: self
>>> namedTempAt: index put: aValue
>>> "Set the value of the temp at index in the receiver's sequence of
>>> (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: ?
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev