2016-02-20 19:11 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
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-meth...>