Hi Casey,

On Tue, Sep 14, 2010 at 7:41 PM, Casey Ransberger
<casey.obrien.r at gmail.com>wrote:

> So I swear that I used to be able to send #storeString to morphs. Maybe I
> dreamed it.
>
> Around the time we shipped the 4.0 artifact, I noticed that upon sending
> #storeString to a visible morph, the CPU would spike and the image would
> hang.
>
> I believe I have figured out why that happens: I think that #storeString is
> recursing on the Morphs 'owner' ivar, thus attempting to store the world,
> which probably has references to much of the rest of the system.
>

Its even simpler than that.  storeString does not cope with circular data
structures and since morphs are circular through owner and submorphs
storeString is doomed to recurse infinitely for any morph with a sub-morph.
 Try
    | a |
    a := OrderedCollection new.
    a add: a.
    a storeString
and you'll see the same thing.

It appears the approved way is to use a SmartRefStream, via
ReadStream>>fileOutClass:andObject:, from Morph>>saveOnFile.

You could fix storeOn: to cope with circular data structures, but since
storeOn: is badly limited by compiler limitations (method size, number of
literals, etc), and since a storeString is not at all readable except for
the most trivial data structures, no one bothers anymore and simply uses the
binary SmartRefStream facilities.  If a textual representation is needed you
can always use the XML facilities.

HTH
Eliot


> One might argue that this is expected behavior, but it isn't very useful
> expected behavior AFAICT. I would really like to be able to construct a
> prototype manually through morph composition/decomposition, and get code to
> recreate the resulting object, so that the final product can be developed
> programmatically.
>
> I tested my hypothesis by creating a new morph, opening it in the world,
> inspecting it, and assigning nil to it's owner ivar, and then sending
> storeString to it. This worked as I expected.
>
> One way to make it work would be to implement storeString on Morph: send
> #veryDeepCopy to self, nil the owner reference on the copy if the owner (is
> the? is a?) world, and then send a message (say, #superStoreString) to the
> copy that does super storeString, returning it's answer. This prevents the
> morph in the UI from losing it's reference to the world, and gives you back
> what you were probably expecting (something useful.)
>
> OTOH, maybe that's a terrible, ugly hack. Maybe it makes sense to fix the
> problem somewhere else. Maybe there are nasty gotchas involved. Maybe I'm
> the only person in the world who wants to interact with Morphic in this way.
>
> What do the good people of Squeak think?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100914/c34a9275/attachment.htm