Hi
Browsing through a 3.9 image I found three senders of Symbol allInstances which store the result in a temp during image segment export: ImageSegment >> #copySmartRootsExport: CodeLoader >> #exportCodeSegment:classes:keepSource: SystemDictionary >> #writeImageSegmentsFrom:withKernel: Is this a problem?
Cheers Philippe
Philippe Marschall <philippe.marschall <at> gmail.com> writes:
Browsing through a 3.9 image I found three senders of Symbol allInstances which store the result in a temp during image segment export: ImageSegment >> #copySmartRootsExport: CodeLoader >> #exportCodeSegment:classes:keepSource: SystemDictionary >> #writeImageSegmentsFrom:withKernel: Is this a problem?
Cheers Philippe
Yes, Symbol is now an abstract class. Symbol allInstances size = 0. There are only ByteSymbol or WideSymbol in the image. If goal is to create strong pointers as mentionned in comment, then Symbol allSubInstances would be better.
Nicolas
Symbol allSymbols is the correct idiom to use. Symbol allSubInstances is overkill and very slow.
Cheers, - Andreas
nicolas cellier wrote:
Philippe Marschall <philippe.marschall <at> gmail.com> writes:
Browsing through a 3.9 image I found three senders of Symbol allInstances which store the result in a temp during image segment export: ImageSegment >> #copySmartRootsExport: CodeLoader >> #exportCodeSegment:classes:keepSource: SystemDictionary >> #writeImageSegmentsFrom:withKernel: Is this a problem?
Cheers Philippe
Yes, Symbol is now an abstract class. Symbol allInstances size = 0. There are only ByteSymbol or WideSymbol in the image. If goal is to create strong pointers as mentionned in comment, then Symbol allSubInstances would be better.
Nicolas
2007/7/31, Andreas Raab andreas.raab@gmx.de:
Symbol allSymbols is the correct idiom to use. Symbol allSubInstances is overkill and very slow.
How would you come up with a test that exploits the Symbol allInstances issue? It guess it involves the creation of a Symbol that is referenced by noone (including the code that creates it) and them filing it out in an ImageSegment and filing it in again.
Cheers Philippe
Cheers,
- Andreas
nicolas cellier wrote:
Philippe Marschall <philippe.marschall <at> gmail.com> writes:
Browsing through a 3.9 image I found three senders of Symbol allInstances which store the result in a temp during image segment export: ImageSegment >> #copySmartRootsExport: CodeLoader >> #exportCodeSegment:classes:keepSource: SystemDictionary >> #writeImageSegmentsFrom:withKernel: Is this a problem?
Cheers Philippe
Yes, Symbol is now an abstract class. Symbol allInstances size = 0. There are only ByteSymbol or WideSymbol in the image. If goal is to create strong pointers as mentionned in comment, then Symbol allSubInstances would be better.
Nicolas
On Thu, 02 Aug 2007 13:50:32 +0200, Philippe Marschall wrote:
2007/7/31, Andreas Raab:
Symbol allSymbols is the correct idiom to use. Symbol allSubInstances is overkill and very slow.
How would you come up with a test that exploits the Symbol allInstances issue? It guess it involves the creation of a Symbol that is referenced by noone (including the code that creates it) and them filing it out in an ImageSegment and filing it in again.
Good question.
| s | "thisContext has hash in it's printString" s := thisContext printString asSymbol. self assert: [(PointerFinder pointersTo: s) size = 2]
/Klaus
Cheers Philippe
Cheers,
- Andreas
nicolas cellier wrote:
Philippe Marschall <philippe.marschall <at> gmail.com> writes:
Browsing through a 3.9 image I found three senders of Symbol allInstances which store the result in a temp during image segment export: ImageSegment >> #copySmartRootsExport: CodeLoader >> #exportCodeSegment:classes:keepSource: SystemDictionary >> #writeImageSegmentsFrom:withKernel: Is this a problem?
Cheers Philippe
Yes, Symbol is now an abstract class. Symbol allInstances size = 0. There are only ByteSymbol or WideSymbol in the image. If goal is to create strong pointers as mentionned in comment, then
Symbol
allSubInstances would be better.
Nicolas
squeak-dev@lists.squeakfoundation.org