2016-02-20 20:31 GMT+01:00 Nicolai Hess <nicolaih...@gmail.com>:
> > > 2016-02-20 19:11 GMT+01:00 Nicolai Hess <nicolaih...@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-methods-then-they-fail-when-platform-changes> > > Any idea what has changed? I could not spot a change that could be responsible for this. The order of tempvars in a block context somehow changed, and the way the debugger accesses the temps by name (get an index and access the context temp vars by index) somehow changed. Recompiling the affected methods helps, but I would like to know if this change (where is it?) was on purpose.
