2016-02-20 19:11 GMT+01:00 Nicolai Hess <[email protected]>: > This is not an issue with GTDebugger, but the way opal generates the > tempvar > index or the way, debuggerMap tries to access the context vars > > 17660 > <https://pharo.fogbugz.com/f/cases/17660/wrong-tempvar-values-in-debugger> > wrong tempvar values in debugger > > > This is a really special case, I wasn't able yet to create an easier > example for reproducing this bug: > - put a self haltOnce in > RAbstractClass>>#directlyDefinesLocalMethod: > - enable halt once > - select any other method in Nautilus and choose > "Rename method (all)" from method panes context menu > - enter a new name and push "OK" > -> the debugger pops up in method > directlyDefinesLocalMethod: > - select the first "allClassesDo:" context from top of the stack > -> the debugger shows that we are in the evalBlock context > The "seen" variable is a Set, but if you look at the "Variables"-pane, it > is shown > as a block (this is actually the parameter aBlock) >
again, this is caused by a change for spur migration This worked up to pharo 50496 starting with pharo 50497, the order of variables has changed. see http://forum.world.st/pharo-project-pharo-core-dfd4f3-50497-td4867046.html <https://pharo.fogbugz.com/f/cases/17241/ffi-nb-is-not-cleaning-compiled-methods-then-they-fail-when-platform-changes>
