[Pharo-project] 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
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 <hernan.morales@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr 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 <nicolas.cellier.aka.nice@gmail.com>:
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 <hernan.morales@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/11/15 Hernán Morales Durand <hernan.morales@gmail.com>:
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 <nicolas.cellier.aka.nice@gmail.com>:
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 <hernan.morales@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 <nicolas.cellier.aka.nice@gmail.com> wrote:
2009/11/15 Hernán Morales Durand <hernan.morales@gmail.com>:
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 <nicolas.cellier.aka.nice@gmail.com>:
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 <hernan.morales@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <mike@mjr104.co.uk>:
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 <nicolas.cellier.aka.nice@gmail.com> wrote:
2009/11/15 Hernán Morales Durand <hernan.morales@gmail.com>:
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 <nicolas.cellier.aka.nice@gmail.com>:
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 <hernan.morales@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (3)
-
Hernán Morales Durand -
Michael Roberts -
Nicolas Cellier