Hi Michael,
  I was asking because I'm doing some mysterious tools, and I need to
scan and gather information from all compiled methods in an image in a
clean way.
Cheers,

Hernán

2009/11/15 Michael Roberts <[email protected]>:
> 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
> <[email protected]> wrote:
>> 2009/11/15 Hernán Morales Durand <[email protected]>:
>>> 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 <[email protected]>:
>>>> 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 <[email protected]>:
>>>>> 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
>>>>> [email protected]
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [email protected]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [email protected]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [email protected]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to