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.


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
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project