Yet again, wrong tempvars in debuggers context variables list
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)
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...>
2016-02-20 20:31 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
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...>
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.
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 <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>>:
2016-02-20 19:11 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com <mailto: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...>
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.
On 22 Feb 2016, at 10:27, Guille Polito <guillermopolito@gmail.com> wrote:
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.
We should have recompiled the whole image after⦠lets do this soon and see.
On 02/22/2016 09:08 AM, Nicolai Hess wrote:
2016-02-20 20:31 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com> <mailto:nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>>>:
2016-02-20 19:11 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com> <mailto:nicolaihess@gmail.com <mailto: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 <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 <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... <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.
participants (3)
-
Guille Polito -
Marcus Denker -
Nicolai Hess