[squeak-dev] A case for #storeString on Morph

Frank Shearar frank.shearar at angband.za.org
Wed Sep 15 09:23:15 UTC 2010


On 2010/09/15 07:09, Casey Ransberger wrote:
> 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.

I think that would be... pretty awesome!

> 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.

Are you looking for Floyd's tortoise-and-hare, perhaps?

* http://c2.com/cgi/wiki?TortoiseAndHare
* http://en.wikipedia.org/wiki/Cycle_detection

That _identifies_ cycles in a graph.

frank

> 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
> <mailto:eliot.miranda at gmail.com>> wrote:
>
>> Hi Casey,
>>
>> On Tue, Sep 14, 2010 at 7:41 PM, Casey Ransberger <
>> <mailto:casey.obrien.r at gmail.com>casey.obrien.r at gmail.com
>> <mailto: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?
>>
>>
>>
>
>
>




More information about the Squeak-dev mailing list