May 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Method Wrappers and the Debugger

by Sean P. DeNigris

Sean P. DeNigris wrote > > I'm going to take a look at the other MethodWrapper implementation, which > I think creates CompiledMethods, so maybe that will fare better... > Indeed, the MethodWrappers on SqS (see http://forum.world.st/MethodWrappers-td3829576.html#a4601624) allows one to step over the wrapper in the debugger. Stepping in fails, but I expected that, and it's not so important to simulate the stub in the debugger... Sean -- View this message in context: http://forum.world.st/Method-Wrappers-and-the-Debugger-tp4601773p4601880.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 1, 2012

[Pharo-project] Method Wrappers and the Debugger

by Sean P. DeNigris

I'm writing a test double library similar to Ruby's rspec. The first signs of life can be downloaded via: Gofer new squeaksource: 'BDDExtensions'; package: 'Mock'; load. One of the features is to partially stub a class, so one could have e.g. DateAndTime>>#now return a canned value. It's easy enough to implement, but the wheels fall off in the debugger, where the VM quits and leaves no log on the last line of the following snippet. In a workspace, I just get a DNU, described in the comment: startTime := DateAndTime now. DateAndTime stub: #now andReturn: startTime. "DoIt this last line... works great. Debug this last line... DateAndTime class(Object)>>doesNotUnderstand: 224@116. It originally ran into Object>>at: error not indexable until I implemented at: and forwarded it to the original CompiledMethod" DateAndTime now. The ObjectAsMethodWrapper approach has a similar limitation: wrapper := ObjectAsMethodWrapper installOn: DateAndTime class selector: #now. "Debugging this line leads to 'Error: Instances of ObjectAsMethodWrapper are not indexable'" DateAndTime now. I'm going to take a look at the other MethodWrapper implementation, which I think creates CompiledMethods, so maybe that will fare better... Any other ideas? Thanks. Sean -- View this message in context: http://forum.world.st/Method-Wrappers-and-the-Debugger-tp4601773.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 1, 2012

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

by Mariano Martinez Peck

> >> >>> But tempNames is fundamentally broken for closures. >>> >> >> Just to avoid confusing, #tempNames itself looks correct: >> >> tempNames >> "Answer a SequenceableCollection of the names of the receiver's >> temporary >> variables, which are strings." >> >> ^ self debuggerMap tempNamesForContext: self >> > > Yes. That's for ContextPart. But it doesn't work for CompiledMethod, > since temps may differ between a method and its blocks. > > Right, but weren't we always talking about Contexts? Because #tempNames of CompiledMethod is different than the thing of contexts, isn't it? It is related to the method trailer. In fact, I have just checked Squeak 4.3 and CompiledMethod does not even implement #tempNames. The implementation in Pharo is: CompiledMethod >> #tempNames self holdsTempNames ifFalse: [^#()]. ^self tempNamesString subStrings: ' ' how would it be the correct implementation then? Thanks -- Mariano http://marianopeck.wordpress.com

May 1, 2012

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

by Eliot Miranda

On Tue, May 1, 2012 at 1:12 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > > > > On Tue, May 1, 2012 at 9:29 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> >> >> On Tue, May 1, 2012 at 9:13 AM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> >>> >>> On Tue, May 1, 2012 at 6:09 PM, Mariano Martinez Peck < >>> marianopeck(a)gmail.com> wrote: >>> >>>> Hi guys. I noticed stef did this issue: >>>> http://code.google.com/p/pharo/issues/detail?id=5642 >>>> However, now I have the following test that fails in Pharo 2.0 but >>>> works fine in 1.4: >>>> >>>> | string context | >>>> string := 'test'. >>>> context := [self class. string asUppercase] asContext. >>>> self assert: (context tempNamed: 'string') = 'test' >>>> >>>> the current implementation of #tempNamed: is: >>>> >>>> tempNamed: aName >>>> "Returns the value of the temporaries, aName." >>>> "Implementation notes: temporary initialization in blocks simply >>>> uses pushNil to allocate and initialize each temp. So if one inspects >>>> [|a|a:=2] and sends it self method symbolic you get: >>>> >>>> 13 <8F 00 00 05> closureNumCopied: 0 numArgs: 0 bytes 17 to 21 >>>> 17 <73> pushConstant: nil >>>> 18 <77> pushConstant: 2 >>>> 19 <81 40> storeIntoTemp: 0 >>>> 21 <7D> blockReturn >>>> 22 <7C> returnTop >>>> >>>> And when we check self asContext pc we get 17, which is *before* >>>> the nil is pushed. Therefore we should pay attention when querying a >>>> temporary if the temporary allocation was executed." >>>> >>>> | index | >>>> index := (self tempNames indexOf: aName). >>>> ^ index >= stackp >>>> >>> >>> >>> Maybe the solution is to use #> rather than #>= ? >>> >> >> right. >> > > Ok, so I will integrate that as a first version. > > >> But tempNames is fundamentally broken for closures. >> > > Just to avoid confusing, #tempNames itself looks correct: > > tempNames > "Answer a SequenceableCollection of the names of the receiver's > temporary > variables, which are strings." > > ^ self debuggerMap tempNamesForContext: self > Yes. That's for ContextPart. But it doesn't work for CompiledMethod, since temps may differ between a method and its blocks. > > >> It does not answer temps in indirection vectors. That is the whole point >> of schematicTempNamesString; it gives the topology of temps in a method. >> e.g. (where => means printIt returns...) >> >> (Collection>>#inject:into:) methodNode schematicTempNamesString => >> 'thisValue binaryBlock (nextValue)[each binaryBlock (nextValue)]' >> >> This says that >> a) at method level there are three temps, thisValue, binaryBlock and an >> indirection vector, and in the indirection vector is one temp named >> nextValue. >> b) in the block in inject:into: there are three temps, each (the >> argument), binaryBlock and an indirection vector, and in that indirection >> vector is a temp named nextValue. >> >> This is all orchestrated by DebuggerMethodMap, so that >> >> aContext method debuggerMap tempNamesForContext: aContext >> > > So #tempNames implementation is correct? > Yes. > > >> >> answers a list of the flattened temp names in a context (flattening out >> indirection vectors) and for the above would answer either #('thisValue' >> 'binaryBlock' 'nextValue') or #('each' 'binaryBlock' 'nextValue'), and >> >> | map | >> map := aContext method debuggerMap. >> map namedTempAt: ((map tempNamesForContext: aContext) indexOf: >> aTempName) in: aContext >> >> gets the temp from the unflattened temps in a context. This is how the >> debugger accesses temp names. >> >> So you need to throw away the broken tempName: implementation and use >> DebuggerMethodMap or some parse over schematicTempNamesString, because >> *with closures temps are not simply at contiguous offsets on the stack*. >> Make sense? >> > > 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, one good way to understand this is through examples. inject:into: is >> the canonical simple example I've used for years. But we can find more >> complex examples that may help. So this query looks for all methods that >> contain a bytecode to create an indirection vector with 2 or more elements: >> >> SystemNavigation new browseAllSelect: >> [:m| | is | >> is := InstructionStream on: m. >> is scanFor: [:b| b = 138 and: [is followingByte between: 2 and: 127]]] >> >> and the simplest example in a trunk 4.3 image I find is: >> >> Bag>>sum >> "Faster than the superclass implementation when you hold many instances >> of the same value (which you probably do, otherwise you wouldn't be using a >> Bag)." >> | sum first | >> first := true. >> contents keysAndValuesDo: [ :value :count | >> first >> ifTrue: [ sum := value * count. first := false ] >> ifFalse: [ sum := sum + (value * count) ] ]. >> first ifTrue: [ self errorEmptyCollection ]. >> ^sum >> >> which needs a two-element indirection vector because the block [ :value >> :count |...] assigns to both sum and first. Hence >> >> (Bag>>#sum) methodNode schematicTempNamesString => '(sum >> first)[value count (sum first)]' >> >> So in an activation of Bag>>sum the value of first is (sumContext tempAt: >> 1) at: 2 (cuz tempAt: 1 is the indirection vector represented as (sum >> first) in schematic temps, and first is the second element. But in an >> activation of the block in Bag>>sum the value of first is (sumBlockContext >> tempAt: 3) at: 2. >> >> >> I can keep repeating myself until I'm blue in the face, but y'all have to >> put in the effort to understand this simple scheme. Temps that are >> modified after they are closed-over end up in indirection vectors. >> >> > > Thanks, I am trying to undersand and fix it :) > > >> >>> >>> >>>> ifTrue: [ nil] >>>> ifFalse: [self tempAt: (self tempNames indexOf: aName)] >>>> >>>> >>>> and previously it was: >>>> >>>> tempNamed: aName >>>> ^self tempAt: (self tempNames indexOf: aName) >>>> >>>> >>>> ideas? >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> -- >> best, >> Eliot >> > -- > Mariano > http://marianopeck.wordpress.com -- best, Eliot

May 1, 2012

Re: [Pharo-project] Pharo 2.0: Just need a recompileAll or a real problem in background?

by Mariano Martinez Peck

On Tue, May 1, 2012 at 10:05 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 1 May 2012 21:45, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > > > On Tue, May 1, 2012 at 9:22 PM, Francisco Garau < > francisco.garau(a)gmail.com> > > wrote: > >> > >> Your code snippet is comparing the associations. The below one evaluates > >> to true: > >> > >> (Smalltalk globals associationAt: #ScriptLoader) value > >> == > >> ((SmalltalkImage >> #shrinkToCore) literalAt: 4) value > >> > > > > Yes, but the literals of CompiledMethod that refer to classes should have > > the SAME association as Smalltalk globals. In fact, that's the reason > why we > > have: > > > indeed. > The question is what leads to creation of multiple associations > pointing to same global? > Exactly. I can easily fix it with a Compiler recompileAll. But the main question is if we have a bug or something that could let us in that state. > > > Association >> #literalEqual: otherLiteral > > "Answer true if the receiver and otherLiteral represent the same > > literal. > > Variable bindings are literally equals only if identical. > > This is how variable sharing works, by preserving identity and > changing > > only the value." > > ^self == otherLiteral > > > > instead of the Object implementation. > > > > > >> > >> On 1 May 2012 17:52, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > >>> > >>> (Smalltalk globals associationAt: #ScriptLoader) == ((SmalltalkImage >> > >>> #shrinkToCore) literalAt: 4) > >>> gives false when it should be true. If I do a Compiler recompileAll it > >>> gets fixed. So, my question is, is that normal? how could that happen? > >>> is there any real problem behind? > >>> > >>> anyway, can we do a recompileAll for the moment? > >>> > >>> thanks! > >>> > >>> -- > >>> Mariano > >>> http://marianopeck.wordpress.com > >>> > >> > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > -- > Best regards, > Igor Stasenko. > > -- Mariano http://marianopeck.wordpress.com

May 1, 2012

Re: [Pharo-project] MethodWrappers

by Sean P. DeNigris

Marcus Denker-4 wrote > >> On 21 September 2011 11:48, Torsten Bergmann <astares@> wrote: >>> at [1] you mentioned a port of MethodWrappers to Squeak 4.2. >>> Is there also a port for Pharo available or do you plan to >>> port it? > But that is working in Pharo already, isn't it? > Most of the tests pass in both 1.4 and 2.0. The only failure, #testNoProtoInstanceCount, is a test that does not make sense to me (I think it should fail) and the ~6 errors are due to a missing MethodNode>>ensureNotQuick, which doesn't exist in Squeak 4.2 either Also, Gofer does not like packages with dots in the name, so one has to write "MethodWrappers4.2-eem.25" "MethodWrappers4", not "MethodWrappers4.2". I'm guessing this will fall apart when "MethodWrappers4.3" is released... Gofer it squeaksource: 'MethodWrappers'; package: 'MethodWrappers4'; load. Sean -- View this message in context: http://forum.world.st/MethodWrappers-tp3829576p4601624.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 1, 2012

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

by Mariano Martinez Peck

On Tue, May 1, 2012 at 9:29 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > On Tue, May 1, 2012 at 9:13 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> On Tue, May 1, 2012 at 6:09 PM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> Hi guys. I noticed stef did this issue: >>> http://code.google.com/p/pharo/issues/detail?id=5642 >>> However, now I have the following test that fails in Pharo 2.0 but works >>> fine in 1.4: >>> >>> | string context | >>> string := 'test'. >>> context := [self class. string asUppercase] asContext. >>> self assert: (context tempNamed: 'string') = 'test' >>> >>> the current implementation of #tempNamed: is: >>> >>> tempNamed: aName >>> "Returns the value of the temporaries, aName." >>> "Implementation notes: temporary initialization in blocks simply >>> uses pushNil to allocate and initialize each temp. So if one inspects >>> [|a|a:=2] and sends it self method symbolic you get: >>> >>> 13 <8F 00 00 05> closureNumCopied: 0 numArgs: 0 bytes 17 to 21 >>> 17 <73> pushConstant: nil >>> 18 <77> pushConstant: 2 >>> 19 <81 40> storeIntoTemp: 0 >>> 21 <7D> blockReturn >>> 22 <7C> returnTop >>> >>> And when we check self asContext pc we get 17, which is *before* the >>> nil is pushed. Therefore we should pay attention when querying a temporary >>> if the temporary allocation was executed." >>> >>> | index | >>> index := (self tempNames indexOf: aName). >>> ^ index >= stackp >>> >> >> >> Maybe the solution is to use #> rather than #>= ? >> > > right. > Ok, so I will integrate that as a first version. > But tempNames is fundamentally broken for closures. > Just to avoid confusing, #tempNames itself looks correct: tempNames "Answer a SequenceableCollection of the names of the receiver's temporary variables, which are strings." ^ self debuggerMap tempNamesForContext: self > It does not answer temps in indirection vectors. That is the whole point > of schematicTempNamesString; it gives the topology of temps in a method. > e.g. (where => means printIt returns...) > > (Collection>>#inject:into:) methodNode schematicTempNamesString => > 'thisValue binaryBlock (nextValue)[each binaryBlock (nextValue)]' > > This says that > a) at method level there are three temps, thisValue, binaryBlock and an > indirection vector, and in the indirection vector is one temp named > nextValue. > b) in the block in inject:into: there are three temps, each (the > argument), binaryBlock and an indirection vector, and in that indirection > vector is a temp named nextValue. > > This is all orchestrated by DebuggerMethodMap, so that > > aContext method debuggerMap tempNamesForContext: aContext > So #tempNames implementation is correct? > > answers a list of the flattened temp names in a context (flattening out > indirection vectors) and for the above would answer either #('thisValue' > 'binaryBlock' 'nextValue') or #('each' 'binaryBlock' 'nextValue'), and > > | map | > map := aContext method debuggerMap. > map namedTempAt: ((map tempNamesForContext: aContext) indexOf: > aTempName) in: aContext > > gets the temp from the unflattened temps in a context. This is how the > debugger accesses temp names. > > So you need to throw away the broken tempName: implementation and use > DebuggerMethodMap or some parse over schematicTempNamesString, because > *with closures temps are not simply at contiguous offsets on the stack*. > Make sense? > 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: ? > > Now, one good way to understand this is through examples. inject:into: is > the canonical simple example I've used for years. But we can find more > complex examples that may help. So this query looks for all methods that > contain a bytecode to create an indirection vector with 2 or more elements: > > SystemNavigation new browseAllSelect: > [:m| | is | > is := InstructionStream on: m. > is scanFor: [:b| b = 138 and: [is followingByte between: 2 and: 127]]] > > and the simplest example in a trunk 4.3 image I find is: > > Bag>>sum > "Faster than the superclass implementation when you hold many instances of > the same value (which you probably do, otherwise you wouldn't be using a > Bag)." > | sum first | > first := true. > contents keysAndValuesDo: [ :value :count | > first > ifTrue: [ sum := value * count. first := false ] > ifFalse: [ sum := sum + (value * count) ] ]. > first ifTrue: [ self errorEmptyCollection ]. > ^sum > > which needs a two-element indirection vector because the block [ :value > :count |...] assigns to both sum and first. Hence > > (Bag>>#sum) methodNode schematicTempNamesString => '(sum > first)[value count (sum first)]' > > So in an activation of Bag>>sum the value of first is (sumContext tempAt: > 1) at: 2 (cuz tempAt: 1 is the indirection vector represented as (sum > first) in schematic temps, and first is the second element. But in an > activation of the block in Bag>>sum the value of first is (sumBlockContext > tempAt: 3) at: 2. > > > I can keep repeating myself until I'm blue in the face, but y'all have to > put in the effort to understand this simple scheme. Temps that are > modified after they are closed-over end up in indirection vectors. > > Thanks, I am trying to undersand and fix it :) > >> >> >>> ifTrue: [ nil] >>> ifFalse: [self tempAt: (self tempNames indexOf: aName)] >>> >>> >>> and previously it was: >>> >>> tempNamed: aName >>> ^self tempAt: (self tempNames indexOf: aName) >>> >>> >>> ideas? >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > -- > best, > Eliot > > > > > -- Mariano http://marianopeck.wordpress.com

May 1, 2012

Re: [Pharo-project] Pharo 2.0: Just need a recompileAll or a real problem in background?

by Igor Stasenko

On 1 May 2012 21:45, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Tue, May 1, 2012 at 9:22 PM, Francisco Garau <francisco.garau(a)gmail.com> > wrote: >> >> Your code snippet is comparing the associations. The below one evaluates >> to true: >> >> (Smalltalk globals associationAt: #ScriptLoader) value >> Â == >> ((SmalltalkImage >> #shrinkToCore) literalAt: 4) value >> > > Yes, but the literals of CompiledMethod that refer to classes should have > the SAME association as Smalltalk globals. In fact, that's the reason why we > have: > indeed. The question is what leads to creation of multiple associations pointing to same global? > Association >> #literalEqual: otherLiteral > Â Â Â "Answer true if the receiver and otherLiteral represent the same > literal. > Â Â Â Variable bindings are literally equals only if identical. > Â Â Â This is how variable sharing works, by preserving identity and changing > only the value." > Â Â Â ^self == otherLiteral > > instead of the Object implementation. > > >> >> On 1 May 2012 17:52, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>> >>> (Smalltalk globals associationAt: #ScriptLoader) == ((SmalltalkImage >> >>> #shrinkToCore) literalAt: 4) >>> gives false when it should be true.Â If I do a Compiler recompileAll it >>> gets fixed. So, my question is, is that normal? how could that happen? >>> is there any real problem behind? >>> >>> anyway, can we do a recompileAll for the moment? >>> >>> thanks! >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Best regards, Igor Stasenko.

May 1, 2012

Re: [Pharo-project] Pharo 2.0: Just need a recompileAll or a real problem in background?

by Mariano Martinez Peck

On Tue, May 1, 2012 at 9:22 PM, Francisco Garau <francisco.garau(a)gmail.com>wrote: > Your code snippet is comparing the associations. The below one evaluates > to true: > > (Smalltalk globals associationAt: #ScriptLoader) value > == > ((SmalltalkImage >> #shrinkToCore) literalAt: 4) value > > Yes, but the literals of CompiledMethod that refer to classes should have the SAME association as Smalltalk globals. In fact, that's the reason why we have: Association >> #literalEqual: otherLiteral "Answer true if the receiver and otherLiteral represent the same literal. Variable bindings are literally equals only if identical. This is how variable sharing works, by preserving identity and changing only the value." ^self == otherLiteral instead of the Object implementation. > On 1 May 2012 17:52, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> (Smalltalk globals associationAt: #ScriptLoader) == ((SmalltalkImage >> >> #shrinkToCore) literalAt: 4) >> gives false when it should be true. If I do a Compiler recompileAll it >> gets fixed. So, my question is, is that normal? how could that happen? >> is there any real problem behind? >> >> anyway, can we do a recompileAll for the moment? >> >> thanks! >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > -- Mariano http://marianopeck.wordpress.com

May 1, 2012

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

by Eliot Miranda

On Tue, May 1, 2012 at 9:13 AM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > > > On Tue, May 1, 2012 at 6:09 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Hi guys. I noticed stef did this issue: >> http://code.google.com/p/pharo/issues/detail?id=5642 >> However, now I have the following test that fails in Pharo 2.0 but works >> fine in 1.4: >> >> | string context | >> string := 'test'. >> context := [self class. string asUppercase] asContext. >> self assert: (context tempNamed: 'string') = 'test' >> >> the current implementation of #tempNamed: is: >> >> tempNamed: aName >> "Returns the value of the temporaries, aName." >> "Implementation notes: temporary initialization in blocks simply uses >> pushNil to allocate and initialize each temp. So if one inspects [|a|a:=2] >> and sends it self method symbolic you get: >> >> 13 <8F 00 00 05> closureNumCopied: 0 numArgs: 0 bytes 17 to 21 >> 17 <73> pushConstant: nil >> 18 <77> pushConstant: 2 >> 19 <81 40> storeIntoTemp: 0 >> 21 <7D> blockReturn >> 22 <7C> returnTop >> >> And when we check self asContext pc we get 17, which is *before* the >> nil is pushed. Therefore we should pay attention when querying a temporary >> if the temporary allocation was executed." >> >> | index | >> index := (self tempNames indexOf: aName). >> ^ index >= stackp >> > > > Maybe the solution is to use #> rather than #>= ? > right. But tempNames is fundamentally broken for closures. It does not answer temps in indirection vectors. That is the whole point of schematicTempNamesString; it gives the topology of temps in a method. e.g. (where => means printIt returns...) (Collection>>#inject:into:) methodNode schematicTempNamesString => 'thisValue binaryBlock (nextValue)[each binaryBlock (nextValue)]' This says that a) at method level there are three temps, thisValue, binaryBlock and an indirection vector, and in the indirection vector is one temp named nextValue. b) in the block in inject:into: there are three temps, each (the argument), binaryBlock and an indirection vector, and in that indirection vector is a temp named nextValue. This is all orchestrated by DebuggerMethodMap, so that aContext method debuggerMap tempNamesForContext: aContext answers a list of the flattened temp names in a context (flattening out indirection vectors) and for the above would answer either #('thisValue' 'binaryBlock' 'nextValue') or #('each' 'binaryBlock' 'nextValue'), and | map | map := aContext method debuggerMap. map namedTempAt: ((map tempNamesForContext: aContext) indexOf: aTempName) in: aContext gets the temp from the unflattened temps in a context. This is how the debugger accesses temp names. So you need to throw away the broken tempName: implementation and use DebuggerMethodMap or some parse over schematicTempNamesString, because *with closures temps are not simply at contiguous offsets on the stack*. Make sense? Now, one good way to understand this is through examples. inject:into: is the canonical simple example I've used for years. But we can find more complex examples that may help. So this query looks for all methods that contain a bytecode to create an indirection vector with 2 or more elements: SystemNavigation new browseAllSelect: [:m| | is | is := InstructionStream on: m. is scanFor: [:b| b = 138 and: [is followingByte between: 2 and: 127]]] and the simplest example in a trunk 4.3 image I find is: Bag>>sum "Faster than the superclass implementation when you hold many instances of the same value (which you probably do, otherwise you wouldn't be using a Bag)." | sum first | first := true. contents keysAndValuesDo: [ :value :count | first ifTrue: [ sum := value * count. first := false ] ifFalse: [ sum := sum + (value * count) ] ]. first ifTrue: [ self errorEmptyCollection ]. ^sum which needs a two-element indirection vector because the block [ :value :count |...] assigns to both sum and first. Hence (Bag>>#sum) methodNode schematicTempNamesString => '(sum first)[value count (sum first)]' So in an activation of Bag>>sum the value of first is (sumContext tempAt: 1) at: 2 (cuz tempAt: 1 is the indirection vector represented as (sum first) in schematic temps, and first is the second element. But in an activation of the block in Bag>>sum the value of first is (sumBlockContext tempAt: 3) at: 2. I can keep repeating myself until I'm blue in the face, but y'all have to put in the effort to understand this simple scheme. Temps that are modified after they are closed-over end up in indirection vectors. > > >> ifTrue: [ nil] >> ifFalse: [self tempAt: (self tempNames indexOf: aName)] >> >> >> and previously it was: >> >> tempNamed: aName >> ^self tempAt: (self tempNames indexOf: aName) >> >> >> ideas? >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- best, Eliot

May 1, 2012