> On 22 Feb 2016, at 10:27, Guille Polito <[email protected]> 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 <[email protected] 
>> <mailto:[email protected]> <mailto:[email protected] 
>> <mailto:[email protected]>>>:
>> 
>> 
>> 
>>    2016-02-20 19:11 GMT+01:00 Nicolai Hess <[email protected] 
>> <mailto:[email protected]>
>>    <mailto:[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 
>> <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-methods-then-they-fail-when-platform-changes
>>  
>> <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.

Reply via email to