If the method is installed, I would only store a reference (MyClass>>#myMethod). That's what is done on Class, they are stored by reference: String streamContents: [:strm | Array storeOn: strm] -> 'Array' Otherwise, if the method is not installed, I would not store a trailer pointing to some source somewhere indeed, but why not a trailer encoding compressed temp vars or direct source... Anyway, is the trailer a relevant point of comparison ? Nicolas 2010/1/4 Igor Stasenko <siguctua@gmail.com>:
2010/1/4 Henrik Johansen <henrik.s.johansen@veloxit.no>:
On Jan 4, 2010, at 2:45 57AM, Levente Uzonyi wrote:
On Wed, 30 Dec 2009, Stéphane Ducasse wrote:
BIG THANKS igor!!!
11127 -----
- Issue 1690: New Method Trailer part 7 (cs 9)
There are still some issues. Some methods (for example TPureBehavior >> #addTraitSelector:withMethod:) still use the old trailer bytes #(0 0 0 0). These should be removed asap (I had to make some surgery with #become: to compile the new version.)
Levente
CompiledMethod>>storeOn: also needs to be updated,
(Compiler evaluate: aCompiledMethod storeString) does not reconstruct the original trailer.
The only way how you should be allowed to reconstruct a compiled method from string, is compilation, otherwise you risking crashing the system. But compilation _always_ creating a new artifact - a compiled method , and picking an appropriate trailer for it.
The way, how CompiledMethod>>storeOn: does, seems an abuse, as to me, because i won't bet on safety of keeping a methods in such format, even for existing images. For instance, you could store a method , then condense changes, and then if you attempt to restore it, you will end up with having a sourcePointer pointing to invalid .changes file location.
So, i rather prefer seeing this method implemented like following:
CompiledMethod>>storeOn: aStream  ^ self shoulNotBeImplemented
Caught by ArrayTest >> testComplexIsSelfEvaluating, of all places :)
Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project