The bug that Bob points out is certainly the culprit here (not for 
the crashes Stephane reports, probably, but at least for the hangs 
that I was experiencing.)

The code as it stands now actually can result in arbitrary globals, 
including #Smalltalk, #Morph, and, say, #Object, getting assigned new 
values.  In Bob's example, the global #Morph actually stopped 
referring to a class and started referring to an instance of that 
class!

I would look with suspicion on any 3.3a image that had any 
tile-scripting activity done in it anytime after the arrival of the 
modules code.

A fix will be published shortly.

  -- Scott


At 10:14 PM -0500 1/31/02, Bob Arning wrote:
>On Thu, 31 Jan 2002 18:22:34 -0800 Scott Wallace 
><scott.wallace at squeakland.org> wrote:
>>As you'll see, you are correct that it relates to the referencing
>>mechanism in scripting.  The point of departure -- the method from
>>which, once entered in these "hang" conditions, one never returns --
>>is Object.uniqueNameForReference.
>
>Scott,
>
>One problem is that Object>>uniqueNameForReference has a bug:
>
>	aName _ Utilities keyLike:  stem satisfying:
>		[:jinaLake |
>			nameSym _ jinaLake asSymbol.
>			((References definedNames includesKey: 
>nameSym) not and:
>				[(Module root moduleDefining: 
>nameSym) notNil]) and:
>						[(knownClassVars 
>includes: nameSym) not]].
>
>will return a name that *is* defined by a module.
>
>				[(Module root moduleDefining: 
>nameSym) notNil]) and:
>
>should be
>
>				[(Module root moduleDefining: 
>nameSym) isNil]) and:
>
>If you want to see this in action, before you make the change, try
>
>	Morph new uniqueNameForReference
>
>Do this once and you get #Morph. It will fail the second time 
>because the name #Morph now refers to the instance of Morph created 
>in the first test. Needless to say, don't do this on an image you 
>care about.
>
>Cheers,
>Bob