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.
>
>
Even more...#onFileWithSymbols becomes as state in the method
writeToFileWithSymbols
But, look the first line of this method:
writeToFileWithSymbols
| symbols nonSymbols pound |
state = #extracted ifFalse: [self error: 'wrong state'].
The state #extracted DOES NOT EXISTS!!! Look the senders and you will
find only that method hahahahahah
I guess it should be #active, because, as you can see in the method extract,
the final states it sets is #active.
So....you always get "wrong state" ;)
Cheers,
Mariano
> 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.
>
> 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
