On Thu, Dec 10, 2009 at 3:32 AM, Martin McClure <martin@hand2mouse.com> 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
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project