Ned,

Wow ... considering I am just starting doing Smalltalk and Squeak (apart from 
playing with Squeak last fall with my kids) and struggling with basic things 
such as  .. well pretty much everything :) .. this is a "black belt lesson" 
here.  I will, nevertheless, try to follow what you did as a learning 
exercise .. of course can take me days or weeks if I finish at all, but it's 
gonna be worth it I am sure, when i re-appear on this list a year from now 
you know i mastered Ned's lesson :D

Thanks for all the details provided along the way while investigating and 
helping out with this, really appreciated,

Milan

PS: I would think it's worth putting out on Squeak wiki?

On July 12, 2004 04:11 pm, Ned Konz wrote:
> On Monday 12 July 2004 6:42 am, Milan Zimmermann wrote:
> > one note/question - when playing with your solution last night I
> > thought the "reason" why the save hang was the "improperly renamed class
> > ZTime" - do you think it was that or just the fact I had the Changeset
> > browser opened in the project, which made the object graph too big and
> > Squeak decided to stop the save?)
>
> It's not that the object graph was too big. It's that there was a pointer
> outside the graph that couldn't get resolved properly (in this case, a
> ReadOnlyVariableBinding of #ZTime to the class Time). This was caused
> (indirectly) by your having a ChangeSorter open in the project.
>
> > I tried to look for the "ZTime" class in Browser before I closed the
> > "Change Sorter" but did not find it, not sure why. In any case, do you
> > think I must have renamed it or something else could have happened to the
> > image? - Just curious, I am not aware of renaming any class, perhaps by
> > accident .. I have been playing with creating classes from the workspace,
> > perhaps I messed up at some point.
>
> The problem existed in a stock image. Read on...
>
> I will explain in detail what I did to explore the problem in hopes that it
> may help some of you. This is in the "teaching people to fish" spirit.
>
> [For those of you who want to play along at home, you may repeat this
> problem using a stock 3.7g image by making a new Morphic project, opening a
> ChangeSorter in it, and trying to save the project on disk]
>
> - First, I noticed that the project stopped saving at some point and the
> world would respond to mouse clicks again (that is, I could raise a menu).
>
> - I then returned to the parent project (the one I had asked to save) and
> saw an inform dialog that said "extra associations".
>
> - I opened a Workspace, typed in the phrase "extra associations", and hit
> alt-shift-E (search for methods containing the string in a string literal).
> Actually, I could have done this easier by shift-clicking on the string in
> the informer, and hitting alt-shift-E, but I knew I'd need a Workspace
> anyway.
>
> - I found ImageSegment>>prepareToBeSaved. Looking down at the bottom of
> this method, I saw that it was trying to (but didn't) open an inspector.
> So...
>
> - In my Workspace, I typed in
> 	ImageSegment allInstances
> and hit alt-shift-I (explore it). I saw that there was one of them.
>
> - I selected this one in the explorer, and typed in
> 	self prepareToBeSaved
> in the bottom of the explorer, and hit alt-D (do it).
>
> - Again I saw the inform dialog, but this time when I hit the OK button I
> saw the inspector pop up. It contained an IdentitySet with one element
> (which printed itself as #ZTime).
>
> - I typed in to the bottom of the dialog
> 	self anyOne inspect
>
> - This brought up an Inspector on a ReadOnlyVariableBinding whose key was
> #ZTime and whose value was Time
>
> - selecting the key (#ZTime) in the inspector's upper left hand pane, I
> brought up the context menu using the mouse. I chose "objects pointing to
> this value"
>
> [A much better tool for tracing pointers is Avi Bryant's Pointer Explorer,
> available using SqueakMap. I rarely have much success using the "chase
> pointers" choice (the Pointer Finder).].
>
> - I got an inspector on an array with five slots. The last slot was an
> ObjectExplorerWrapper (a side effect of having the other explorer open).
> But the other four were interesting. They were:
>
> 	- a big array with symbols and other things in it: #(#EventPollFrequency
> #startUpWithCaption:at:allowKeyboard: #delayedBy: #anchors #panForTrack:
> nil #'read/write segment' #reciprocalFloorLog: an Object an Object #radial
> #packageNamed:ifAbsent: an Object #blockAssociationCheck: an Object an
> Object ...
> 	- a ClassChangeRecord
> 	- #ZTime->a ClassChangeRecord
> 	- another big array: #(Array Project nil a Project(NewChanges) false
> PasteUpMorph TranscriptStream ChangeSet Form HandMorph a
> StringMorph(2714)'a StringMorph(113)''a PasteUpMorph(1263) [world] that was
> not counted'' that was not counted' a StringMorph(3918)'a
> StringMorph(1420)''a
> SimpleHierarchicalListMorph(1810) that was not counted'' ...
>
> - I guessed that the two big arrays were used by the ImageSegment, so
> focused on the ClassChangeRecords.
>
> - Now, I knew that ClassChangeRecords lived in ChangeSets, which are
> pointed to by ChangeSorters. Having seen a ChangeSorter in your project, I
> suspected that was the problem. So I selected the association (#ZTime->a
> ClassChangeRecord) and chose from the Inspector context menu "objects
> pointing to it". I saw:
>
> #(#Time->a ClassChangeRecord #TimeStamp->a ClassChangeRecord #ZTime->a
> ClassChangeRecord nil nil nil nil #Date->a ClassChangeRecord nil #ZDate->a
> ClassChangeRecord nil #ZTimeStamp->a ClassChangeRecord)
>
> - "Ah, I see" I said to myself. Now I recalled that we renamed some classes
> in the Great Time And Date Revolution around CS 5660. So I did "objects
> pointing to it" another two times until I got to
> 	a ChangeSet named 5668Chrnl-i-CnvtTDateTTime1
>
> - So now my suspicion that the ChangeSorter was involved was proved. I knew
> how ChangeSorters and ChangeSets were structured, but following the
> pointers further would have led to a ChangeSetCategory and/or the
> ChangeSorter.
>
> - But the question about why was this one class an unresolved out pointer
> still remained.
>
> The answer was here in ImageSegment>>prepareToBeSaved:
>
> 		(Smalltalk associationAt: assoc key ifAbsent: [3]) == assoc ifTrue: [
> 			outPointers at: (outIndexes at: assoc) put:
> 				(DiskProxy global: #Smalltalk selector: #associationAt:
> 					args: (Array with: assoc key)).
>
> In other words, since Smalltalk didn't contain #ZTime (this was a temporary
> rename), we didn't replace the association with a DiskProxy.
>
> In the Workspace, you can see other potential problems like this by doing a
> print-it or inspect-it on:
>
> ReadOnlyVariableBinding allInstances
> 	select: [ :ea | ea value isBehavior and: [ (Smalltalk at: ea key ifAbsent:
> []) ~~ ea value ]]
> 	thenCollect: [ :ea | ea key -> ea value ]
>
> which returns:
>
> #(#CRGestureProcessor->AnObsoleteCRGestureProcessor
> #PseudoClassOrganizer->AnObsoletePseudoClassOrganizer
> #CRDictionary->AnObsoleteCRDictionary
> #ClassOrganizer->AnObsoleteClassOrganizer #ZDate->Date
> #CRAddFeatureMorph->AnObsoleteCRAddFeatureMorph
> #CRLookupItem->AnObsoleteCRLookupItem #ZTime->Time
> #IRCProtocolMessage->AnObsoleteIRCProtocolMessage
> #IRCMorph->AnObsoleteIRCMorph #SMTPSocket->AnObsoleteSMTPSocket
> #CRDisplayProperties->AnObsoleteCRDisplayProperties)
>
> But this begs the question of "why did it appear in the out pointers?". If
> you look at ChangeSet>>objectForDataStream: you will see that ChangeSets
> themselves don't get stored. So something else must have been responsible.
> What? Hmm...
>
> Let's look at who might be pointing to it. We can skip ChangeRecords, since
>
> they won't get stored. So let's try this:
> | zt ptrs baddies ptrs2 |
>
> Smalltalk garbageCollect.
> zt := (ReadOnlyVariableBinding allInstances select: [ :ea | ea key = #ZTime
> ]) first.
> ptrs := Smalltalk pointersTo: zt except: { zt. zt key. zt value. }.
> baddies := OrderedCollection new.
> ptrs do: [ :p |
> 	ptrs2 := nil.
> 	ptrs2 := Smalltalk pointersTo: p except: { ptrs. p. thisContext.
> thisContext sender. thisContext home. thisContext blockHome. zt. zt key. zt
> value. baddies. baddies collector }.
> 	ptrs2 := ptrs2 reject: [ :ea |
> 		('*ChangeRecord*' match: ea class name) ].
> 	ptrs2 isEmpty ifFalse: [baddies addAll: ptrs2 ].
> ].
> baddies asArray inspect.
>
>
> Which shows me a single MethodContext, whose receiver is Delay, and whose
> source is missing. But looking around the context, I see that there is a
> temp of a Semaphore, and on its list is a process with priority 80.
>
> Opening a Process browser, I see that that's the timer interrupt watcher.
> Apparently this didn't get recompiled and restarted, or it's the old
> method.
>
> By printing the result of
>
> 	Delay class compiledMethodAt: #timerInterruptWatcher
>
> I see that the method is different (different identityHash).
>
> OK... let's try to fix the problem. Looks like I'll have to restart the
> timer interrupt watcher, but I don't want to kill off the existing delays.
>
> Reading the code of Delay class shows how this might work.
>
> Let's try:
>
> 	Delay shutDown; startTimerInterruptWatcher; startUp.
>
> Repeating the search for baddies above shows that that one reference has
> been removed.
>
> Trying the project storage (with a change sorter) again now works.
>
> Was that fun, or what?
>
> Why did I say that the class was "improperly renamed"? Notice that all of
> the other associations besides #ZTime and #ZDate refer to classes whose
> names start with "AnObsolete" and which will in fact report that they are
> obsolete when asked.
>
> However, #ZTime and #ZDate actually point to live classes with other names!
>
> How did this happen? Well, in the postscript of change set
>
> 5668Chrnl-i-CnvtTDateTTime1 there is the following code:
> | jdn |
>
> jdn _ SystemVersion current date asDate julianDayNumber.
>
> #(#Date #Time #TimeStamp)
> 	do: 	[ :s | | zname tname |
> 		Transcript show: (Smalltalk at: s) allInstances; cr.
> 		zname  _ ('Z', s) asSymbol.
> 		tname  _ ('T', s) asSymbol.
> 		(Smalltalk at: s) rename: zname.
> 		(Smalltalk at: tname) rename: s.
> 		(Smalltalk systemNavigation allCallsOn: (Smalltalk associationAt: zname))
> 			do: [ :ref | ref actualClass ifNotNilDo: [ :ac | ac recompile: ref
> methodSymbol ] ].
> 		Smalltalk forgetClass: (Smalltalk at: zname) logged: false.
> 		Transcript show: 'replaced ', s; cr ].
>
> Transcript show: 'removing subclasses....'.
> (Magnitude subclasses select: [ :sc | sc name beginsWith: 'Z' ])
> 	do:  [ :sc | Magnitude  removeSubclass: sc ].
> Transcript tab; show: 'removed.'; cr.
>
>
> That is (for instance, for #ZTime):
>
> * There used to be a subclass of Magnitude called Time.
> * we defined a new class called TTime
> * we renamed Time to ZTime
> * we renamed TTime to Time
> * we then recompiled all the references to the old versions of Time (which
> was now named #ZTime)
> * we then forgot #ZTime, and tried not to remember that we had done so (in
> the change set)
> * then we tried to remove #ZTime (again) using #removeSubclass: (this
> shouldn't have been necessary after #forgetClass:logged:, and is almost
> always the wrong thing to do from outside the guts of the system).
>
> However, this didn't work entirely right. First, what we *should* have done
> instead of #forgetClass:logged: and #removeSubclass: was instead
>
> 	(Smalltalk at: zname) removeFromSystem: false.
>
>
> Anyway, this is probably more than you wanted to know.
>
> I'll post a change set that fixes this problem, so saving projects that
> contain change sorters will work.
>
> Have fun,