Trailer format

> Hi all,
>  Possibly this is a bug. To reproduce it download a Pharo-Core (I'm
> using #11045), update from servers and evaluate:
>
> CompiledMethod allInstances first getSource asString
>
> if you see something like the following result, some things could be wrong:
>
>  '(firstCollection at: index) equals:  a.
>                self assert: (secondCollection at: index) equals:  b.]
>
>        '
>
> because that isn't a message pattern. The compiled method instance is
>
> (BlockClosure>>#newProcess "a CompiledMethod(1962)")
>
> and the source string is in PharoV10.sources, but
> #fileIndexFromSourcePointer: is answering "2" which is the changes
> file and should answer "1"... someone with a better understanding of
> sources arithmetic may comment.
> Cheers,
>
> Hernán
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> You should check this:
>   CompiledMethod allInstances first isInstalled.
>
> If false, the answer probably is at
> http://code.google.com/p/pharo/issues/detail?id=1423
>
> 2009/11/15 Hernán Morales Durand <[hidden email]>:
>> Hi all,
>>  Possibly this is a bug. To reproduce it download a Pharo-Core (I'm
>> using #11045), update from servers and evaluate:
>>
>> CompiledMethod allInstances first getSource asString
>>
>> if you see something like the following result, some things could be wrong:
>>
>>  '(firstCollection at: index) equals:  a.
>>                self assert: (secondCollection at: index) equals:  b.]
>>
>>        '
>>
>> because that isn't a message pattern. The compiled method instance is
>>
>> (BlockClosure>>#newProcess "a CompiledMethod(1962)")
>>
>> and the source string is in PharoV10.sources, but
>> #fileIndexFromSourcePointer: is answering "2" which is the changes
>> file and should answer "1"... someone with a better understanding of
>> sources arithmetic may comment.
>> Cheers,
>>
>> Hernán
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> Hi Nicolas,
>  Thanks for your comments. I've checked all CompiledMethods in a Core image
>
> | col |
> col := OrderedCollection new: 20.
> CompiledMethod allInstancesDo: [: cm |
>        [ RBParser
>                parseMethod: cm getSource asString
>                onError: [ :msg :pos |  col add: (msg -> cm) ] ]
>        on: Error do: [: ex | ] ].
> col explore
>
> which gave me 9 instances with problems, 8 of them have source pointer
> problems and they are uninstalled, in explorer :
>
> self collect: [: assoc | assoc value getSource asString ]
>

> After applying your patch and condensing changes and source files,
> I've tried again
>
> CompiledMethod allInstances first getSource asString
>
> and the Decompiler raises now an exception, is this expected?
> It would be too hard to correct the source pointer numbers of
> uninstalled compiled methods?
>
> Cheers,
>
> Hernán
>

> 2009/11/15 Nicolas Cellier <[hidden email]>:
>> You should check this:
>>   CompiledMethod allInstances first isInstalled.
>>
>> If false, the answer probably is at
>> http://code.google.com/p/pharo/issues/detail?id=1423
>>
>> 2009/11/15 Hernán Morales Durand <[hidden email]>:
>>> Hi all,
>>>  Possibly this is a bug. To reproduce it download a Pharo-Core (I'm
>>> using #11045), update from servers and evaluate:
>>>
>>> CompiledMethod allInstances first getSource asString
>>>
>>> if you see something like the following result, some things could be wrong:
>>>
>>>  '(firstCollection at: index) equals:  a.
>>>                self assert: (secondCollection at: index) equals:  b.]
>>>
>>>        '
>>>
>>> because that isn't a message pattern. The compiled method instance is
>>>
>>> (BlockClosure>>#newProcess "a CompiledMethod(1962)")
>>>
>>> and the source string is in PharoV10.sources, but
>>> #fileIndexFromSourcePointer: is answering "2" which is the changes
>>> file and should answer "1"... someone with a better understanding of
>>> sources arithmetic may comment.
>>> Cheers,
>>>
>>> Hernán
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 2009/11/15 Hernán Morales Durand <[hidden email]>:
>> Hi Nicolas,
>>  Thanks for your comments. I've checked all CompiledMethods in a Core image
>>
>> | col |
>> col := OrderedCollection new: 20.
>> CompiledMethod allInstancesDo: [: cm |
>>        [ RBParser
>>                parseMethod: cm getSource asString
>>                onError: [ :msg :pos |  col add: (msg -> cm) ] ]
>>        on: Error do: [: ex | ] ].
>> col explore
>>
>> which gave me 9 instances with problems, 8 of them have source pointer
>> problems and they are uninstalled, in explorer :
>>
>> self collect: [: assoc | assoc value getSource asString ]
>>
>
> I recommend trying:
>    ScriptLoader new cleanUpMethods.
> That should eliminate most copies of CompiledMethod and replace with
> an original.
>
>
>> After applying your patch and condensing changes and source files,
>> I've tried again
>>
>> CompiledMethod allInstances first getSource asString
>>
>> and the Decompiler raises now an exception, is this expected?
>> It would be too hard to correct the source pointer numbers of
>> uninstalled compiled methods?
>>
>> Cheers,
>>
>> Hernán
>>
>
> Decompiler might have bugs, some since closure refactorings, some
> older, but at least we know something is wrong.
> I always prefer a Debugger to a false response !
>
> Instead of simply erasing the source pointer of un-installed
> CompiledMethod during condenseChanges/condenseSources, we could log
> their source.
> But it was already too late when I discovered this (while chasing
> MethodProperties)...
>
>> 2009/11/15 Nicolas Cellier <[hidden email]>:
>>> You should check this:
>>>   CompiledMethod allInstances first isInstalled.
>>>
>>> If false, the answer probably is at
>>> http://code.google.com/p/pharo/issues/detail?id=1423
>>>
>>> 2009/11/15 Hernán Morales Durand <[hidden email]>:
>>>> Hi all,
>>>>  Possibly this is a bug. To reproduce it download a Pharo-Core (I'm
>>>> using #11045), update from servers and evaluate:
>>>>
>>>> CompiledMethod allInstances first getSource asString
>>>>
>>>> if you see something like the following result, some things could be wrong:
>>>>
>>>>  '(firstCollection at: index) equals:  a.
>>>>                self assert: (secondCollection at: index) equals:  b.]
>>>>
>>>>        '
>>>>
>>>> because that isn't a message pattern. The compiled method instance is
>>>>
>>>> (BlockClosure>>#newProcess "a CompiledMethod(1962)")
>>>>
>>>> and the source string is in PharoV10.sources, but
>>>> #fileIndexFromSourcePointer: is answering "2" which is the changes
>>>> file and should answer "1"... someone with a better understanding of
>>>> sources arithmetic may comment.
>>>> Cheers,
>>>>
>>>> Hernán
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> The Decompiler definitely has bugs.  We disabled its tests because it
> needs quite a lot of work post closure integration.
>
> Do you know what is referencing these compiled methods? i.e can they
> possibly be run.  Or is it just a question of clean up?
>
> thanks,
> Mike
>
> On Sun, Nov 15, 2009 at 6:30 PM, Nicolas Cellier
> <[hidden email]> wrote:
>> 2009/11/15 Hernán Morales Durand <[hidden email]>:
>>> Hi Nicolas,
>>>  Thanks for your comments. I've checked all CompiledMethods in a Core image
>>>
>>> | col |
>>> col := OrderedCollection new: 20.
>>> CompiledMethod allInstancesDo: [: cm |
>>>        [ RBParser
>>>                parseMethod: cm getSource asString
>>>                onError: [ :msg :pos |  col add: (msg -> cm) ] ]
>>>        on: Error do: [: ex | ] ].
>>> col explore
>>>
>>> which gave me 9 instances with problems, 8 of them have source pointer
>>> problems and they are uninstalled, in explorer :
>>>
>>> self collect: [: assoc | assoc value getSource asString ]
>>>
>>
>> I recommend trying:
>>    ScriptLoader new cleanUpMethods.
>> That should eliminate most copies of CompiledMethod and replace with
>> an original.
>>
>>
>>> After applying your patch and condensing changes and source files,
>>> I've tried again
>>>
>>> CompiledMethod allInstances first getSource asString
>>>
>>> and the Decompiler raises now an exception, is this expected?
>>> It would be too hard to correct the source pointer numbers of
>>> uninstalled compiled methods?
>>>
>>> Cheers,
>>>
>>> Hernán
>>>
>>
>> Decompiler might have bugs, some since closure refactorings, some
>> older, but at least we know something is wrong.
>> I always prefer a Debugger to a false response !
>>
>> Instead of simply erasing the source pointer of un-installed
>> CompiledMethod during condenseChanges/condenseSources, we could log
>> their source.
>> But it was already too late when I discovered this (while chasing
>> MethodProperties)...
>>
>>> 2009/11/15 Nicolas Cellier <[hidden email]>:
>>>> You should check this:
>>>>   CompiledMethod allInstances first isInstalled.
>>>>
>>>> If false, the answer probably is at
>>>> http://code.google.com/p/pharo/issues/detail?id=1423
>>>>
>>>> 2009/11/15 Hernán Morales Durand <[hidden email]>:
>>>>> Hi all,
>>>>>  Possibly this is a bug. To reproduce it download a Pharo-Core (I'm
>>>>> using #11045), update from servers and evaluate:
>>>>>
>>>>> CompiledMethod allInstances first getSource asString
>>>>>
>>>>> if you see something like the following result, some things could be wrong:
>>>>>
>>>>>  '(firstCollection at: index) equals:  a.
>>>>>                self assert: (secondCollection at: index) equals:  b.]
>>>>>
>>>>>        '
>>>>>
>>>>> because that isn't a message pattern. The compiled method instance is
>>>>>
>>>>> (BlockClosure>>#newProcess "a CompiledMethod(1962)")
>>>>>
>>>>> and the source string is in PharoV10.sources, but
>>>>> #fileIndexFromSourcePointer: is answering "2" which is the changes
>>>>> file and should answer "1"... someone with a better understanding of
>>>>> sources arithmetic may comment.
>>>>> Cheers,
>>>>>
>>>>> Hernán
>>>>>
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>> [hidden email]
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>