Hmm, I know that the Spur bootstrap does a lot of changes "in the
background". For example, it replaces literals in methods
(Float->BoxedFloat64), plus it inlines all immediate characters.
I do not know if it is related, but this could be a side effect, and it
would explain why there is no evident change causing this.
On 02/22/2016 09:08 AM, Nicolai Hess wrote:
2016-02-20 20:31 GMT+01:00 Nicolai Hess <[email protected]
<mailto:[email protected]>>:
2016-02-20 19:11 GMT+01:00 Nicolai Hess <[email protected]
<mailto:[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>
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.
