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

Casey Ransberger casey.obrien.r at gmail.com
Thu Sep 16 00:14:12 UTC 2010


Yes, absolutely. I'm thinking I don't want to touch storeString. After reading Eliot's reply, I'm thinking that what I want isn't so much a specialization of storeString for Morph, but an analogue to it that deals with cycles in a general way. 

I looked at the tortoise/hare algorithm (thanks Frank!) A former coworker had explained this one to me once before, but without the adorable metaphor. I expect that I won't forget it again;)

Gotta admit that solving a CS problem in Squeak with a children's parable seems almost too right not to do:)

But it's not a simple, quick hack that can be trivially tested, so I won't attack it right away. Gotta dig in and understand storeString better before I go trying to implement an analogue to it. 

Perhaps eventually I will have a changeset for people to look at, but not without tests. 

On Sep 15, 2010, at 4:50 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:

> 
> On 15.09.2010, at 04:41, Casey Ransberger 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.
>> 
>> 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.
> 
> It is.
> 
>> Maybe it makes sense to fix the problem somewhere else.
> 
> Maybe.
> 
>> Maybe there are nasty gotchas involved. Maybe I'm the only person in the world who wants to interact with Morphic in this way.
> 
> You might, actually ;)
> 
>> What do the good people of Squeak think?     
> 
> I think "terrible, ugly hack" describes it pretty well ;)
> 
> But since nobody else is using this, why not fix it to do what you want? I'd do it differently though - override storeOn: to actually produce a sensible result. Not meddling with copying, but by writing out code that would properly re-generate that morph. That way it could even look nice, as if you had hand-written the code.
> 
> - Bert -
> 
> 



More information about the Squeak-dev mailing list