2010/1/4 Nicolas Cellier <[email protected]>: > If the method is installed, I would only store a reference > (MyClass>>#myMethod).
+1 > 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... because you could store the source code instead. > Anyway, is the trailer a relevant point of comparison ? > i am against storing the compiled method in any other form than source code, except referential form, like 'Array >> #at: ' , you mentioned. So, either way, after restoring you getting an already existing CompiledMethod instance, or fresh one, which just compiled from stored source code. We just should not allow a potentially dangerous ways of manipulating a binary data, stored in compiled method, including trailer and bytecodes. Because they are subject of change (if we observe them over long period ;) > Nicolas > > 2010/1/4 Igor Stasenko <[email protected]>: >> 2010/1/4 Henrik Johansen <[email protected]>: >>> >>> 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 >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
