Heh, I was afraid that might be the case. 

I looked at SmartRefStream, but a binary solution doesn't do what I need. 

I want to make it possible for people to (e.g.) pull up halos, rip the various submorphs off of (e.g.) a system browser, compose a new UI by sticking these morphs together in perhaps new and radical ways, and then ask the resulting "application" object for a programmatic representation. 

Maybe I should just go and play with Self. 

I suspect that this could be very powerful with regard to an "Etoys for adults."

So I'll ask this: is there a particular algorithm, or group thereof, that I might study in order to learn about identifying/eliminating cycles in data structures? I bet if there is, there's some die hard computer scientist here who can point me in the right direction. 

In any event: thank you all very much. I've already learned something, which is the most anyone can ever ask for. 

On Sep 14, 2010, at 9:45 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:

> 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/fa8f5b8c/attachment.htm