On Thu, Dec 10, 2009 at 3:32 AM, Martin McClure <[email protected]>wrote:
> Sheridan Mahoney wrote: > > > Martin and I had been working towards the idea that ImageSegments should > > never create non-Canonical symbols, and the user should not have to use > > manual techniques to preserve symbols they are interested in keeping > alive. > > > > I ended up getting stuck however, in trying to discover what process > > ImageSegment > > goes through while it is installing objects - ImageSegment #install has > a > > call to an > > unimplemented method #readFromFileWithSymbols which it seems it should > be > > using, but isn't....(wha' the?) > > > > > > install > > "This operation retrieves the segment if necessary from file > storage, > > installs it in memory, and replaces (using become:) all the root stubs > with > > the reconstructed roots of the segment." > > > > | newRoots | > > state = #onFile ifTrue: [self readFromFile]. > > state = #onFileWithSymbols ifTrue: [self readFromFileWithSymbols. > > My guess (and only a guess) is that #onFileWithSymbols never becomes a > state in the test case that's failing. > > Yes! > And my opinion is that it's suspicious to require something different > for a image segment that contains symbols as opposed to one that > doesn't; the ideal would be to have image segments just transparently > handle Symbols correctly. Users just shouldn't have to deal with details > at that level; the correct semantics are extremely clear. > 142% agree. So...there are a couple of things I think ImageSegment should do instead of the user: 1) If you put in the segment a class, ImageSegment automatically puts also the metcaclass. 2) Deal transparently if you put symbols in the segment. 3) Evaluate "Smalltalk garbageCollect" after the message "extract". This is most of the cases something you want to do. I addition, look the senders of extract and you will see that in most of the cases, after doing the extract, it evaluates a garbageCollect. Cheers, Mariano > Regards, > > -Martin > > _______________________________________________ > 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
