April 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] 14606 Really Important bug - Can't see some variables values while debugging closure

by Sven Van Caekenberghe

Yes, incredible work, well done. Thank you. > On 05 Apr 2015, at 14:59, stepharo <stepharo(a)free.fr> wrote: > > > Thanks both of you for the energy you put into Pharo. > The tam really appreciates. > This is because there are guys like you that Pharo is worth being done. > Thanks for the tests. > Esteban has apparently found the bug on the VM. > > Stef >> >> >> On Sun, Apr 5, 2015 at 1:23 PM, Ben Coman <btc(a)openinworld.com> wrote: >> I got annoyed since a few times I thought I'd solved everything just the issue looking at the manual examples of one issue, only to find I'd caused the other case to fail. Also keeping track of all cases as I threw away images with partial solutions was awkward. So I turned the examples from all these Cases into tests and uploaded AdditionalTests-14606-13260-15174-BenComan.1 - so solutions can consistently test all cases. These can be integrated once we have a solution for all of them. Can you think of anymore to add? >> >> >> >> >> And of course, please advise if you think the tests are correct. >> cheers -ben >> >> >> They look good. >> >> Just for reference, in the slice for fixing issue 13260, I added two testcases >> MethodMapTest>>#testCopiedVarFromDeadContext >> and >> MethodMapTest>>#testExampleTempNamedTempVectorInlinedLoop >> >> >

April 5, 2015

Re: [Pharo-dev] 14606 Really Important bug - Can't see some variables values while debugging closure

by stepharo

Thanks both of you for the energy you put into Pharo. The tam really appreciates. This is because there are guys like you that Pharo is worth being done. Thanks for the tests. Esteban has apparently found the bug on the VM. Stef > > > > On Sun, Apr 5, 2015 at 1:23 PM, Ben Coman <btc(a)openinworld.com > <mailto:btc@openinworld.com>> wrote: > > I got annoyed since a few times I thought I'd solved > everything just the issue looking at the manual examples of > one issue, only to find I'd caused the other case to fail. > Also keeping track of all cases as I threw away images with > partial solutions was awkward. So I turned the examples from > all these Cases into tests and uploaded > AdditionalTests-14606-13260-15174-BenComan.1 - so solutions > can consistently test all cases. These can be integrated once > we have a solution for all of them. Can you think of anymore > to add? > > > > > And of course, please advise if you think the tests are correct. > cheers -ben > > > > They look good. > > Just for reference, in the slice for fixing issue 13260, I added two > testcases > MethodMapTest>>#testCopiedVarFromDeadContext > and > MethodMapTest>>#testExampleTempNamedTempVectorInlinedLoop > >

April 5, 2015

Re: [Pharo-dev] 14606 Really Important bug - Can't see some variables values while debugging closure

by Nicolai Hess

2015-04-05 7:25 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > > > On Sun, Apr 5, 2015 at 1:23 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> I got annoyed since a few times I thought I'd solved everything just the >> issue looking at the manual examples of one issue, only to find I'd caused >> the other case to fail. Also keeping track of all cases as I threw away >> images with partial solutions was awkward. So I turned the examples from >> all these Cases into tests and uploaded >> AdditionalTests-14606-13260-15174-BenComan.1 - so solutions can >> consistently test all cases. These can be integrated once we have a >> solution for all of them. Can you think of anymore to add? >> >> >> >> > And of course, please advise if you think the tests are correct. > cheers -ben > They look good. Just for reference, in the slice for fixing issue 13260, I added two testcases MethodMapTest>>#testCopiedVarFromDeadContext and MethodMapTest>>#testExampleTempNamedTempVectorInlinedLoop

April 5, 2015

Re: [Pharo-dev] 14606 Really Important bug - Can't see some variables values while debugging closure

by Ben Coman

On Sun, Apr 5, 2015 at 1:23 PM, Ben Coman <btc(a)openinworld.com> wrote: > I got annoyed since a few times I thought I'd solved everything just the > issue looking at the manual examples of one issue, only to find I'd caused > the other case to fail. Also keeping track of all cases as I threw away > images with partial solutions was awkward. So I turned the examples from > all these Cases into tests and uploaded > AdditionalTests-14606-13260-15174-BenComan.1 - so solutions can > consistently test all cases. These can be integrated once we have a > solution for all of them. Can you think of anymore to add? > > > > And of course, please advise if you think the tests are correct. cheers -ben

April 5, 2015

Re: [Pharo-dev] 14606 Really Important bug - Can't see some variables values while debugging closure

by Ben Coman

I got annoyed since a few times I thought I'd solved everything just the issue looking at the manual examples of one issue, only to find I'd caused the other case to fail. Also keeping track of all cases as I threw away images with partial solutions was awkward. So I turned the examples from all these Cases into tests and uploaded AdditionalTests-14606-13260-15174-BenComan.1 - so solutions can consistently test all cases. These can be integrated once we have a solution for all of them. Can you think of anymore to add? On Sun, Apr 5, 2015 at 8:27 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-04-01 18:56 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > >> Issue 14606 [1] is tagged "Really Important" where evaluating.... >> >> | t1 t2 t3 t4 t5 t6 | >> t1 := 1. >> t2 := 2. >> t3 := 3. >> t4 := 4. >> t5 := 5 . >> t6 := 6. >> [ t5 := 50. >> t6 := 60. >> t3 + t4. >> 1 halt. >> ] value >> >> => can't see the value of t4, t5, t6. >> >> I've just submitted a possible solution for this, but its a bit late >> before release for such a change - so I'm asking for "all hands in" to help >> stress test it. You don't need to review code, just please merge latest >> slice 14606 into your normal working image and report your experience. >> >> cheers -ben >> >> [1] https://pharo.fogbugz.com/default.asp?14606#124466 >> >> > > > Origins of issue "14606 Can't see some variables values while debugging > closure" > It starts with issue: > 14079 Inconsistent information in debugger (pharo 4) > (fixed in 40258) > The thisContext inspector in the debugger (sometimes) shows the wrong > values for the thisContext temp vars. > This was first seen in Method FreeTypeFontProvider>>#updateFromFile: > I extracted a minimal example to reproduce this behavior: > [ :x | > | d c b a | > a := 1. > b := 2. > c := 3. > d := 4. > [ c:=3. c=0 ] on:Error do:[:ex|]. > d halt. > [ c:=3. c=0 ] whileTrue:[]] value:23 > If you execute this method, it stops at "d halt". Look at the "all temp > vars" and the > individual temp var entries in the context inspector. It shows the temp > vars with the correct > values. Now do a step over, int the whileTrue block the temp var name list > is unchanged but > the values changed their order, now the list of individual temp vars shows > the wrong values! > Why did this happen? > There are two problems, > 1. The order of temp vars changes between the method context and the block > closure > 2. The EyeDebuggerContextInspector compares ContextTempEyeElements > without their inst vars (tempName AND tempIndex). > In EyeInspector>>#updateList: > We step into a new block and the debugger calls updateList, here > we check the current list (self list getItems) with the new list (elements) > and check if they are equal, they aren't, because the lists contain > ContextTempEyeElements with > the same tempName but different tempIndex, but the #= selector in > AbstractEyeElement doesn't check this. > EyeInspector>>#updateList > "update the list of elements displayed according to the new object" > > | elements | > " self haltOnce." > elements := self generateElements. > self list getItems = elements ifTrue: [ ^ self ]. "<<<--- returns > event if the elements aren't equal" > .... > > Possible solutions: > - Don't reorder tempvars in inner scopes. This needs some deeper knowlegde > of opals AST Translator. > - Fix the #= for AbstractEyeElement resp. ContextTempEyeElement > - in ContextTempEyeElement, access the temp values not by index (they > changed) but by name > I choosed the latter, because I could not get a working fix for the other, > this raised some > new issues. Not really new, they exists already, but weren't visible > because they were only > used in special cases: > > 13260 inspecting variables in the debugger fails in some cases > (fixed in 40354) > Minimal example: > x := [ :k || b a | b:=[ a:=1. a:=k+1.a]] value:7. > x value > > *Execute* the first line, then debug the second. > In the debugger, in the thisContext inspector, you can select the var > "k", it shows 7, you can select the var "b" it shows nil (because it *is* > nil), > you can not show the value for "a", although it should show "1". > Why did this happens? > With the fix for issue 14079, we now use #tempNamed:aName instead of > #namedTempAt: anIndex > but in the end, the context only stores the temp vars by index, so we (the > debugger) > needs to find the index for the named temp. This is done through > DebuggerMethodMapOpal > namedTempAt:in: resp. tempNamed:in: > It looks up the temp index by the variable binding for the *Method* scope > (and finally the method context). > This is wrong, because in this case, the method context is already dead. > I fixed this by changing OCVectorTempVariable>>#readFromContext:scope: > to start from the inner scope instead of the scope that defined the method > (because it can > be already dead). (This wasn't straight forward, I need to change some > more because the > way the IR class for constructing the closures bytecodes, only searched in > its "block sequence" > but the copyied tempvector is defined in its "sequence" (I don't really > remember what is what). > Even if I had choosed a different fix for issue 14079, this still had to > be fixed, because > indirect variable access through namedTempAt: is used, if we select the > temp var in the *code view* > and do a inspectIt. > Even with this fix, the issue is not fully solved: > > Unsolved issues: > 14606 Can't see some variables values while debugging closure > Minimal example: > |a b c| > a := [ Transcript show: 'test' ]. > [ b :=4. > c := 5. > 1 halt] on: Error do: a. > select the b or c value in the thisContext inspector shows "nil" although > they actually have a value. > And > > 15174 error when inspecting/printing variables in the debugger > > this is a minimal example, reproducing this case, the assignment on "a" is > alreaday > done, after that accessing the value with DebuggerMethodMapOpal should > work, but > it raises an error > | a b | > [ ] value. > a := 1. > b := [ > a := 4. > (DebuggerMethodMapOpal forMethod: thisContext method) tempNamed: 'a' > in: thisContext ] value. > ^ a + b > > -> MessageNotUnderstood: receiver of "indexForVarNamed:" is nil > in OCCopyingTempVariable>>indexInTempVectorFromIR: > > Both issues has to be solved and they have actually two causes: > 1. There is a guarding clause in Context>>tempNamed: anIndex > If the context stackpointer is below temp index, it returns nil. This is > for the case > the block closure vars aren't yet fully initialized (context tempvars are > pushed > on the stack with pushNil, if the stack pointer is below the index, it > looks like we > access a temp var, for which there isn't yet a place on the stack). > But this is wrong! > If the closure uses a closure copied or closure indirect tempvars, then > multiple > vars may be in *one* array that only takes one place on the stack. > 2. (This is the reason for the MNU). Reading the temp vector index for > "copied" temp > vars fails. My proposed solution in "15174 error when inspecting/printing > variables in the debugger" > Looks like fixing this bug at the wrong place. I think it has something to > do with 12887 Fix pc->AST maping. > > There was another issue, something with optimized blocks and reading and > or writing closure temp > vars, but I don't remember that, one. Don't know if it had something to do > with this issues. > > Hope this was understandable and it helps (but I doubt we can solve any of > this for this release. > I was working on them the last 6 month, and issues 12887 is there since > one year, still exists). > > > nicolai > > >

April 5, 2015

Re: [Pharo-dev] Spotter

by Ben Coman

On Sun, Apr 5, 2015 at 9:03 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi Ben, >> >> >> This is quite a hidden and implicit key stroke. Regardless that I know >> I've used it before follow a tutorial, I forgot it. Since Spotter has a >> <Settings Icon> (which I like and think it could be pushed as a standard >> throughout the system in Pharo 5), it might be useful for Pharo 4 if the >> Spotter Settings page contains a "How To" or "Keyboard shortcuts" item that >> just contains descriptive text. Or if there is no facility for that, >> perhaps a few of the keyboard shortcuts listed as individual items with >> descriptions, even if you can't change them. I think this will be useful >> for people presented with Spotter for the first time, particularly since >> first use already prompts users to go to settings to send usage data. > > > > Yes, you right, shortcuts were quite hidden. However, after we received a > lot of similar feedback we improved the situation with shortcuts. Now all > actions in Spotter have explicit action buttons: > Cool. When I was looking at a results category down the page, I didn't notice the icon at the top (in the image shown next to 16/16) or in advance understand that it would move if I clicked in the category. I can understand the logic that it indicates which category the shortcut will apply to, however... * I'm not really going to be looking at a graphic UI component when using shortcut. I'll "just know" what it applies to. * To use the shortcut on other than the first category, it takes two actions: mouse-click the category *then* use the shortcut. If the icon appeared on each category, it would only need one action to just click the icon. (After I wrote this I see Sean had a similar issue, so I know its late. but can Pharo 4 get that icon per category, rather than just on the top category?) > > As soon as you press "shift" (you can't not to press shift during usage of > spotter) all action buttons are highlighted explicitly: > Nice feature, but actually I don't notice myself using <Shift> a lot (maybe I am under utilising the shortcuts) so this is catch-22 [1] - the feature may go unnoticed for newbies. Perhaps where the text entry is seeded with "Search", this could accommodate a tip more like "Search - hold shift to show functions/tooltips" [1] http://www.urbandictionary.com/define.php?term=Catch+22 > > If you hover action button for a few second a hint appears that tells > which shortcut is assigned to an action. If you hover the button while > pressing shift a hint appears immediately: > > Also, in Pharo help there is a good tutorial listing all Spotter shortcuts > and assigned actions: > This is good, but not immediately discoverable. Perhaps a button on the settings page could link to that page? cheers -ben > > On Sun, Apr 5, 2015 at 2:35 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> Thanks Aliaksei. >> >> This is quite a hidden and implicit key stroke. Regardless that I know >> I've used it before follow a tutorial, I forgot it. Since Spotter has a >> <Settings Icon> (which I like and think it could be pushed as a standard >> throughout the system in Pharo 5), it might be useful for Pharo 4 if the >> Spotter Settings page contains a "How To" or "Keyboard shortcuts" item that >> just contains descriptive text. Or if there is no facility for that, >> perhaps a few of the keyboard shortcuts listed as individual items with >> descriptions, even if you can't change them. I think this will be useful >> for people presented with Spotter for the first time, particularly since >> first use already prompts users to go to settings to send usage data. >> >> cheers -ben >> >> On Sun, Apr 5, 2015 at 8:25 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> >> wrote: >> >>> Hi Ben, >>> >>> It's CMD+Shift+Right >>> On Apr 5, 2015 2:23 AM, "Ben Coman" <btc(a)openinworld.com> wrote: >>> >>>> Just a note, I went back to an old image and really miss the Spotter >>>> workflow. >>>> >>>> One thing, can you remind me how when it shows 5/30 implementors I get >>>> a list of all 30? I'm sure I've done this before but can't remember. >>>> Perhaps this means its not obvious and maybe should appear in a "How To >>>> Use" section in the Release Notes. >>>> >>>> cheers -ben >>>> >>> >> >

April 5, 2015

Re: [Pharo-dev] Spotter

by Sean P. DeNigris

Ben Coman wrote > One thing, can you remind me how when it shows 5/30 implementors I get a > list of all 30? One strange thing is that the arrow in "[category] x/yy ->" only appears in the top category, so you can't go to the second or third category and click it. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spotter-tp4817609p4817623.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 5, 2015

Re: [Pharo-dev] Spotter

by Aliaksei Syrel

Hi Ben, > > > This is quite a hidden and implicit key stroke. Regardless that I know > I've used it before follow a tutorial, I forgot it. Since Spotter has a > <Settings Icon> (which I like and think it could be pushed as a standard > throughout the system in Pharo 5), it might be useful for Pharo 4 if the > Spotter Settings page contains a "How To" or "Keyboard shortcuts" item that > just contains descriptive text. Or if there is no facility for that, > perhaps a few of the keyboard shortcuts listed as individual items with > descriptions, even if you can't change them. I think this will be useful > for people presented with Spotter for the first time, particularly since > first use already prompts users to go to settings to send usage data. Yes, you right, shortcuts were quite hidden. However, after we received a lot of similar feedback we improved the situation with shortcuts. Now all actions in Spotter have explicit action buttons: [image: Inline image 1] As soon as you press "shift" (you can't not to press shift during usage of spotter) all action buttons are highlighted explicitly: [image: Inline image 2] If you hover action button for a few second a hint appears that tells which shortcut is assigned to an action. If you hover the button while pressing shift a hint appears immediately: [image: Inline image 3] Also, in Pharo help there is a good tutorial listing all Spotter shortcuts and assigned actions: [image: Inline image 4] How else can we improve discoverability of Spotter features? Cheers, Alex Cheers, Alex On Sun, Apr 5, 2015 at 2:35 AM, Ben Coman <btc(a)openinworld.com> wrote: > Thanks Aliaksei. > > This is quite a hidden and implicit key stroke. Regardless that I know > I've used it before follow a tutorial, I forgot it. Since Spotter has a > <Settings Icon> (which I like and think it could be pushed as a standard > throughout the system in Pharo 5), it might be useful for Pharo 4 if the > Spotter Settings page contains a "How To" or "Keyboard shortcuts" item that > just contains descriptive text. Or if there is no facility for that, > perhaps a few of the keyboard shortcuts listed as individual items with > descriptions, even if you can't change them. I think this will be useful > for people presented with Spotter for the first time, particularly since > first use already prompts users to go to settings to send usage data. > > cheers -ben > > On Sun, Apr 5, 2015 at 8:25 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> > wrote: > >> Hi Ben, >> >> It's CMD+Shift+Right >> On Apr 5, 2015 2:23 AM, "Ben Coman" <btc(a)openinworld.com> wrote: >> >>> Just a note, I went back to an old image and really miss the Spotter >>> workflow. >>> >>> One thing, can you remind me how when it shows 5/30 implementors I get a >>> list of all 30? I'm sure I've done this before but can't remember. >>> Perhaps this means its not obvious and maybe should appear in a "How To >>> Use" section in the Release Notes. >>> >>> cheers -ben >>> >> >

April 5, 2015

Re: [Pharo-dev] Spotter

by Ben Coman

Thanks Aliaksei. This is quite a hidden and implicit key stroke. Regardless that I know I've used it before follow a tutorial, I forgot it. Since Spotter has a <Settings Icon> (which I like and think it could be pushed as a standard throughout the system in Pharo 5), it might be useful for Pharo 4 if the Spotter Settings page contains a "How To" or "Keyboard shortcuts" item that just contains descriptive text. Or if there is no facility for that, perhaps a few of the keyboard shortcuts listed as individual items with descriptions, even if you can't change them. I think this will be useful for people presented with Spotter for the first time, particularly since first use already prompts users to go to settings to send usage data. cheers -ben On Sun, Apr 5, 2015 at 8:25 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi Ben, > > It's CMD+Shift+Right > On Apr 5, 2015 2:23 AM, "Ben Coman" <btc(a)openinworld.com> wrote: > >> Just a note, I went back to an old image and really miss the Spotter >> workflow. >> >> One thing, can you remind me how when it shows 5/30 implementors I get a >> list of all 30? I'm sure I've done this before but can't remember. >> Perhaps this means its not obvious and maybe should appear in a "How To >> Use" section in the Release Notes. >> >> cheers -ben >> >

April 5, 2015

Re: [Pharo-dev] 14606 Really Important bug - Can't see some variables values while debugging closure

by Nicolai Hess

2015-04-01 18:56 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > Issue 14606 [1] is tagged "Really Important" where evaluating.... > > | t1 t2 t3 t4 t5 t6 | > t1 := 1. > t2 := 2. > t3 := 3. > t4 := 4. > t5 := 5 . > t6 := 6. > [ t5 := 50. > t6 := 60. > t3 + t4. > 1 halt. > ] value > > => can't see the value of t4, t5, t6. > > I've just submitted a possible solution for this, but its a bit late > before release for such a change - so I'm asking for "all hands in" to help > stress test it. You don't need to review code, just please merge latest > slice 14606 into your normal working image and report your experience. > > cheers -ben > > [1] https://pharo.fogbugz.com/default.asp?14606#124466 > > Origins of issue "14606 Can't see some variables values while debugging closure" It starts with issue: 14079 Inconsistent information in debugger (pharo 4) (fixed in 40258) The thisContext inspector in the debugger (sometimes) shows the wrong values for the thisContext temp vars. This was first seen in Method FreeTypeFontProvider>>#updateFromFile: I extracted a minimal example to reproduce this behavior: [ :x | | d c b a | a := 1. b := 2. c := 3. d := 4. [ c:=3. c=0 ] on:Error do:[:ex|]. d halt. [ c:=3. c=0 ] whileTrue:[]] value:23 If you execute this method, it stops at "d halt". Look at the "all temp vars" and the individual temp var entries in the context inspector. It shows the temp vars with the correct values. Now do a step over, int the whileTrue block the temp var name list is unchanged but the values changed their order, now the list of individual temp vars shows the wrong values! Why did this happen? There are two problems, 1. The order of temp vars changes between the method context and the block closure 2. The EyeDebuggerContextInspector compares ContextTempEyeElements without their inst vars (tempName AND tempIndex). In EyeInspector>>#updateList: We step into a new block and the debugger calls updateList, here we check the current list (self list getItems) with the new list (elements) and check if they are equal, they aren't, because the lists contain ContextTempEyeElements with the same tempName but different tempIndex, but the #= selector in AbstractEyeElement doesn't check this. EyeInspector>>#updateList "update the list of elements displayed according to the new object" | elements | " self haltOnce." elements := self generateElements. self list getItems = elements ifTrue: [ ^ self ]. "<<<--- returns event if the elements aren't equal" .... Possible solutions: - Don't reorder tempvars in inner scopes. This needs some deeper knowlegde of opals AST Translator. - Fix the #= for AbstractEyeElement resp. ContextTempEyeElement - in ContextTempEyeElement, access the temp values not by index (they changed) but by name I choosed the latter, because I could not get a working fix for the other, this raised some new issues. Not really new, they exists already, but weren't visible because they were only used in special cases: 13260 inspecting variables in the debugger fails in some cases (fixed in 40354) Minimal example: x := [ :k || b a | b:=[ a:=1. a:=k+1.a]] value:7. x value *Execute* the first line, then debug the second. In the debugger, in the thisContext inspector, you can select the var "k", it shows 7, you can select the var "b" it shows nil (because it *is* nil), you can not show the value for "a", although it should show "1". Why did this happens? With the fix for issue 14079, we now use #tempNamed:aName instead of #namedTempAt: anIndex but in the end, the context only stores the temp vars by index, so we (the debugger) needs to find the index for the named temp. This is done through DebuggerMethodMapOpal namedTempAt:in: resp. tempNamed:in: It looks up the temp index by the variable binding for the *Method* scope (and finally the method context). This is wrong, because in this case, the method context is already dead. I fixed this by changing OCVectorTempVariable>>#readFromContext:scope: to start from the inner scope instead of the scope that defined the method (because it can be already dead). (This wasn't straight forward, I need to change some more because the way the IR class for constructing the closures bytecodes, only searched in its "block sequence" but the copyied tempvector is defined in its "sequence" (I don't really remember what is what). Even if I had choosed a different fix for issue 14079, this still had to be fixed, because indirect variable access through namedTempAt: is used, if we select the temp var in the *code view* and do a inspectIt. Even with this fix, the issue is not fully solved: Unsolved issues: 14606 Can't see some variables values while debugging closure Minimal example: |a b c| a := [ Transcript show: 'test' ]. [ b :=4. c := 5. 1 halt] on: Error do: a. select the b or c value in the thisContext inspector shows "nil" although they actually have a value. And 15174 error when inspecting/printing variables in the debugger this is a minimal example, reproducing this case, the assignment on "a" is alreaday done, after that accessing the value with DebuggerMethodMapOpal should work, but it raises an error | a b | [ ] value. a := 1. b := [ a := 4. (DebuggerMethodMapOpal forMethod: thisContext method) tempNamed: 'a' in: thisContext ] value. ^ a + b -> MessageNotUnderstood: receiver of "indexForVarNamed:" is nil in OCCopyingTempVariable>>indexInTempVectorFromIR: Both issues has to be solved and they have actually two causes: 1. There is a guarding clause in Context>>tempNamed: anIndex If the context stackpointer is below temp index, it returns nil. This is for the case the block closure vars aren't yet fully initialized (context tempvars are pushed on the stack with pushNil, if the stack pointer is below the index, it looks like we access a temp var, for which there isn't yet a place on the stack). But this is wrong! If the closure uses a closure copied or closure indirect tempvars, then multiple vars may be in *one* array that only takes one place on the stack. 2. (This is the reason for the MNU). Reading the temp vector index for "copied" temp vars fails. My proposed solution in "15174 error when inspecting/printing variables in the debugger" Looks like fixing this bug at the wrong place. I think it has something to do with 12887 Fix pc->AST maping. There was another issue, something with optimized blocks and reading and or writing closure temp vars, but I don't remember that, one. Don't know if it had something to do with this issues. Hope this was understandable and it helps (but I doubt we can solve any of this for this release. I was working on them the last 6 month, and issues 12887 is there since one year, still exists). nicolai

April 5, 2015