It should be indeed --- the test is to see if using a fixed heap size (as allocated with the -memory switch) "solves" the problem ...

take care, -Marc

On Wed, Jul 07, 2004 at 01:07:29PM -0400, Milan Zimmermann wrote:

Marc,

Let me try this evening and I will report what happened.

Just a quick question: should something like -memory 96m be sufficient?

Milan

On July 7, 2004 12:13 pm, mds wrote:

...

Hi Milan,

I've got a feeling this is related to the ImageSegment problems that Goran and I have also been experiencing in relation to SqueakMap.

Ken in fact suggested a test for this ImageSegment issue --- that of loading in saved projects from disk back into the image, which resulted in the same primitive 99 failings; this might be what you're experiencing [I can't tell without a full report].

The hope is that the 64-bit code amendments from Ian and co. will rectify the problem. For now, try running your VM with the -memory ##m switch and trying this procedure again; if you still have the same problems, the likelihood is it's an unrelated issue, else we're at least on the same page.

Regards, Marc

On Wed, Jul 07, 2004 at 12:20:20AM -0400, Milan Zimmermann wrote:

...

Hello,

I have a simple project with a Playfield with one Morph and one script (stopped). When I do "Save Project on File", and select local directory, Squeak is "Collecting" and then "Publishing" forever (well I had patience for about 7 minutes max).

This is on SuSE 8.2 Squeak 3.7b-5967. In the process, Squeak uses about 90% resources and it feels almost "hang" but it's not, always refreshes after a while.

Does this feel like a bug or can there be something about the project? I would attach the project but do not know how to export it in some other way.

Milan

PS PLease let me know if the squeakland@squeakland.org is a better forum for such questions ...

Milan Zimmermann milan.zimmermann@sympatico.ca wrote:

Marc,

The behaviour is the same (Squeak "hangs" on the save) with or without the "-memory 96m" switch:

cd $HOME/dev/smalltalk/squeak/3.7;squeak Squeak3.7b-5967.image cd $HOME/dev/smalltalk/squeak/3.7;squeak -memory 96m Squeak3.7b-5967.image

The VM version:

mzimmermann@home-server:~> squeak -version 3.7b-5 #2 Tue Apr 6 20:38:14 CEST 2004 gcc egcs-2.91.66 Squeak3.7beta of '1 April 2004' [latest update: #5868] Linux pingu.inria.fr 2.2.19-6.2.7 #1 Thu Jun 14 07:51:10 EDT 2001 i686 default plugin location: /usr/lib/squeak/3.7b-5/*.so

Please let me know if I can provide more info, try something else, and/or try a different VM or image (although, I do not know enough on how to "export" that project to duplicate in a new image - i tried to create a similar project and the "Save Project onFile" works correctly.).

Ehmm. So you could create *another* Project and save that one? Then it can't be a general issue with ImageSegment saving. Did you try to do alt-. while it is running? That will hopefully get a notifier so that you can get into the debugger and/or send a debug.log.

Also - saving a Project on file should produce (IIRC) a so called "export" ImageSegment, otherwise it wouldn't be loadable in another image.

It's not all that importand for me to save this project, but if it helps debug something that may be a bug, I am available to experiment with it,

Milan

Yeah, it sounds like a Squeak image bug to me. So hopefully you should be able to interrupt it with alt-.

regards, Göran

On Friday 09 July 2004 8:51 pm, Milan Zimmermann wrote:

...

Then it can't be a general issue with ImageSegment saving. Did you try to do alt-. while it is running? That will hopefully get a notifier so that you can get into the debugger and/or send a debug.log.

Doing Atl-. while the "Save as" is running brings me to the debugger. Unfortunately I do not know enough about Squeak or it's debugger to get a debug.log. I made a screenshot of where I get after Atl-. ,  and can attach (70K),please let me know if it makes sense / would help to attach it here. Or if I can be helped to get the "log".

If you have the standard Preference settings, the debug log file should be produced automaticaly in the same directory when you interrupt Squeak with an Alt-. keystroke.

Alternatively, you can choose "Debug" from the pre-debug window that pops up, then choose "mail out bug report" to send it here.

On Saturday 10 July 2004 8:33 am, Milan Zimmermann wrote:

Ned Konz wrote:

...

If you have the standard Preference settings, the debug log file should be produced automaticaly in the same directory when you interrupt Squeak with an Alt-. keystroke.

Interesting - I should have standard Preferences (I only changed Fonts etc), my "logDebuggerStackToFile" is checked (is it the option that controls the log?) - but I cannot get a "debug.log" or any log, what I was doing: - Alt-. - User Input dialog appears

• I select "Debug"
  • no log yet
• I tried miscelaneous stuff at this point (Full Stack, Proceed, Restart),

but no "debug.log" or similar appeared - still no log

No, I guess I was wrong. It only happens when a debugger is put up when you *don't* hit Alt-.

• after CTRL-click on "user interrupt window" and selecting "mail out bug

report", and a few questions I pasted the content into a file that is attached ... I am not sure the email from Squeak got through, does not seem so, it did not ask me my mailserver id/password, so I attached the file.

I don't see anything abnormal there. You say that it hangs?

Can you describe in detail how you created this project (or at least what's in the World you're trying to save)?

On July 10, 2004 07:38 pm, goran.krampe@bluefish.se wrote:

Ned Konz ned@squeakland.org wrote:

...

Can you describe in detail how you created this project (or at least what's in the World you're trying to save)?

Even better - zip up the image + changes file and put it somewhere on the net so we can take a look. Hmmm, if you can't find a place - email me and I give you a spot somewhere.

Goran, Ned,

Appretiate your helping here - for lack of a better place I put it on:

http://handwritingservices.com/squeak/

The project I am trying to "Save to File" is Meerka Chase, it's the project that opens. .. it is just a toy (start of a toy), so please don't spend too much time on it, unless you feel it's worth it finding a Squeak bug or unexpected behaviour.

Thanks, Milan

regards, Göran

On Sunday 11 July 2004 8:22 am, Milan Zimmermann wrote:

When I created another project similar this one, it saved in about 5 seconds. The project that has the problem has been through some changes but not that many. I attached my image in a separate email to the list. As I said there, please do not spend time with the problem unless you think it is valuable enough to perhaps discover an underlying  Squeak bug or something. I want to be able to save this project for future changes, but can easily start over at this point and hopefully the new version with save ...

Just do this after the save failure:

- click on the desktop in the project (the copy of the one that you're saving) that is displaying the progress morph forever (this project is called Unnamed#). - go to the previous project (the one you're trying to save). - click on the "OK" button on the requestor in the upper left hand corner that says "extra associations" - Open a Project history morph from the Objects tool - drag out project view morphs for any projects you didn't make yourself (like the "Unnamed#" one you just left) - hold the button down on each one of these and choose "expunge project" - close the change sorter in your original project and try again.

What's happening here is this:

- You ask to save the project.

- Squeak creates a new project that is a copy of the one being saved, and changes into it. This is the one that shows the progress morph and the grid.

- It finds something that it doesn't want to save (see below). This more or less aborts the saving, but instead of cleaning up the temp project and changing back to your original project, you're left in the temp project. Which actually isn't saving any more, despite the progress morph being displayed.

- You will find that in the temp project the menu works as soon as this happens (when it changes from "collecting resources" and starts displaying numbers again). Go to the previous (parent) project; this will be your original.

- In the original project, there is at the upper left hand corner of the world a string informer saying "extra associations". This means (to the three or four people who know and remember this) that "something bad happened and your project didn't get saved correctly."

- The cause of this was an improperly renamed class called "ZTime" which is being held in the change records of a change set which is being held by the ChangeSorter that you have in your project.

I'm looking into how we could better handle this kind of thing.

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,

I second that. Put it on the Swiki!

-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Milan Zimmermann Sent: Monday, July 12, 2004 1:22 PM To: squeak-dev@lists.squeakfoundation.org Subject: Re: How to explore a Project saving problem, in great detail

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,

On Wednesday, July 14, 2004, at 08:30 AM, Bert Freudenberg wrote:

Am 12.07.2004 um 22:11 schrieb Ned Konz:

...

I rarely have much success using the "chase pointers" choice (the Pointer Finder)

Me neither, until Andreas pointed (pun intended) out to me that you have to select "self". The problem is that the menu entry is displayed for all slots of an object, but the chase only works for "self".

Seems like this qualifies as a bug, especially since the similar 'objects pointing to this value' works on any variable selected in the inspector. Ought to be fixable, I'd think.

- Doug

Since I've never been able to make 'chase pointers' work (not knowing that it only worked on self) I don't know exactly what it does, but I imagine it's something along the lines of Avi's PointerExplorer. Perhaps it would be better to drop the 'chase pointers' feature and look at including something built from PointerExplorer (I know it still has a few issues) instead? It has the advantage of only opening one level at a time so it doesn't infinitely recurse.

Actually, reading Andreas' comment again, maybe recursion wasn't the problem he was referring to? Anyway, something to consider perhaps.

But if nothing else, it seems like it would be nice to make 'chase pointers' not show up for anything except self.

Andreas Raab wrote:

...

Seems like this qualifies as a bug, especially since the similar 'objects pointing to this value' works on any variable selected in the inspector. Ought to be fixable, I'd think.

This might be harder than you think - I remember briefly looking at this problem way, way back when I first encountered it and not being able to come up with a good solution - the issue is that you do NOT want to include the inspector in the reference chain to the object and that is not exactly trivial to do. But if you can find a way I'll be forever grateful ;-)

Cheers,

• Andreas

Folks,

I'm a long-time lurker, building a product prototype in squeak, and I'm having a similar problem with "Save Project On A File..."

Essentially, twice now when I save my project after some changes (small project, minor changes), the change goes on forever... I see the "Publishing (collecting resources)" and the grid stay there forever. Since this is a 3.6 image (or for other reasons) the instructions that Ned sent out don't apply.

Here are the steps: 1. In the project, I select "Save Project On A File..." 2. In the "Publish This Project" morph, I choose my folder from the list, then press "Save" 3. Squeak asks "Would you like to include all the changes in the change set as part of this publishing operation?" and I select "Yes" 4. Squeak asks "Some blocks which reference instance variables are included in this segment, These may fail when the segment is loaded if the class has been reshaped. What would you like to do?" I select "keep going"

Menus work, so when I "previous project", then I get "MessageNotUnderstood: CompiledMethod>>position", abandon that and I can continue. But never save the project.

Can anyone offer some help / suggestions on what to do next? I can work around, i.e. copy code into a working instance, but I'd like to help eradicate the bug.

I can get email the image or other - suggestions welcome.

Thanks, Steve Sanderson

-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org]On Behalf Of Milan Zimmermann Sent: Monday, July 12, 2004 8:42 AM To: squeak-dev@lists.squeakfoundation.org Subject: Re: "Save Project on File" "almost hangs" Squeak?

Ned,

(sorry i sent this to you instead to list last night .. just a copy here, with 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?)

Thanks for the detail description and help. I am now able to "save the project to file" and understand (partly) why Save did not work before, a few notes inline below:

On July 11, 2004 12:42 pm, Ned Konz wrote:

On Sunday 11 July 2004 8:22 am, Milan Zimmermann wrote:

<<snip>>

Just do this after the save failure:

• click on the desktop in the project (the copy of the one that you're

saving) that is displaying the progress morph forever (this project is called Unnamed#).

Just a note, I was only able to get control back from the "temp project" after Alt-. + Abandon.

• go to the previous project (the one you're trying to save).

I did

• click on the "OK" button on the requestor in the upper left hand corner

that says "extra associations"

Interesting - I have not seen anything in the upper left corner of my original project ...

• Open a Project history morph from the Objects tool

I did

• drag out project view morphs for any projects you didn't make yourself

(like the "Unnamed#" one you just left)

• hold the button down on each one of these and choose "expunge project"
• close the change sorter in your original project and try again.

I did

After that, I did "save" - from World menu, probably not needed - and was able to "Save Project On File" , great, Thanks!

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.

Thanks for your help, hope once I know more about Squeak I'd be able to fix such things :)

Milan

What's happening here is this:

• You ask to save the project.

• Squeak creates a new project that is a copy of the one being saved, and

changes into it. This is the one that shows the progress morph and the grid.

• It finds something that it doesn't want to save (see below). This more

or

less aborts the saving, but instead of cleaning up the temp project and changing back to your original project, you're left in the temp project. Which actually isn't saving any more, despite the progress morph being displayed.

• You will find that in the temp project the menu works as soon as this

happens (when it changes from "collecting resources" and starts displaying numbers again). Go to the previous (parent) project; this will be your original.

• In the original project, there is at the upper left hand corner of the

world a string informer saying "extra associations". This means (to the three or four people who know and remember this) that "something bad happened and your project didn't get saved correctly."

• The cause of this was an improperly renamed class called "ZTime" which

is

being held in the change records of a change set which is being held by

the

ChangeSorter that you have in your project.

I'm looking into how we could better handle this kind of thing.

Steve,

Late replying here, I was away for 3 weeks .. a question: do you have a "Changeset Browser" open in your project by any chance? If so, remove it from the project and that should fix it. As well, getting the latest version should help as Ned fixed this - You may want to browse messages in this thread, the problem seems the same. Let me know if this does not help and I'd try to dig out some details,

Milan On July 22, 2004 05:28 pm, Steve Sanderson wrote:

Folks,

I'm a long-time lurker, building a product prototype in squeak, and I'm having a similar problem with "Save Project On A File..."

Essentially, twice now when I save my project after some changes (small project, minor changes), the change goes on forever... I see the "Publishing (collecting resources)" and the grid stay there forever. Since this is a 3.6 image (or for other reasons) the instructions that Ned sent out don't apply.

Here are the steps:

1. In the project, I select "Save Project On A File..."
2. In the "Publish This Project" morph, I choose my folder from the list,

then press "Save" 3. Squeak asks "Would you like to include all the changes in the change set as part of this publishing operation?" and I select "Yes" 4. Squeak asks "Some blocks which reference instance variables are included in this segment, These may fail when the segment is loaded if the class has been reshaped. What would you like to do?" I select "keep going"

Menus work, so when I "previous project", then I get "MessageNotUnderstood: CompiledMethod>>position", abandon that and I can continue. But never save the project.

Can anyone offer some help / suggestions on what to do next? I can work around, i.e. copy code into a working instance, but I'd like to help eradicate the bug.

I can get email the image or other - suggestions welcome.

Thanks, Steve Sanderson

-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org]On Behalf Of Milan Zimmermann Sent: Monday, July 12, 2004 8:42 AM To: squeak-dev@lists.squeakfoundation.org Subject: Re: "Save Project on File" "almost hangs" Squeak?

Ned,

(sorry i sent this to you instead to list last night .. just a copy here, with 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?)

Thanks for the detail description and help. I am now able to "save the project to file" and understand (partly) why Save did not work before, a few notes inline below:

On July 11, 2004 12:42 pm, Ned Konz wrote:

...

On Sunday 11 July 2004 8:22 am, Milan Zimmermann wrote:

<<snip>>

...

Just do this after the save failure:

• click on the desktop in the project (the copy of the one that you're

saving) that is displaying the progress morph forever (this project is called Unnamed#).

Just a note, I was only able to get control back from the "temp project" after Alt-. + Abandon.

...

• go to the previous project (the one you're trying to save).

I did

...

• click on the "OK" button on the requestor in the upper left hand corner

that says "extra associations"

Interesting - I have not seen anything in the upper left corner of my original project ...

...

• Open a Project history morph from the Objects tool

I did

...

• drag out project view morphs for any projects you didn't make yourself

(like the "Unnamed#" one you just left)

• hold the button down on each one of these and choose "expunge project"
• close the change sorter in your original project and try again.

I did

After that, I did "save" - from World menu, probably not needed - and was able to "Save Project On File" , great, Thanks!

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.

Thanks for your help, hope once I know more about Squeak I'd be able to fix such things :)

Milan

...

What's happening here is this:

• You ask to save the project.

• Squeak creates a new project that is a copy of the one being saved, and

changes into it. This is the one that shows the progress morph and the grid.

• It finds something that it doesn't want to save (see below). This more

or

...

less aborts the saving, but instead of cleaning up the temp project and changing back to your original project, you're left in the temp project. Which actually isn't saving any more, despite the progress morph being displayed.

• You will find that in the temp project the menu works as soon as this

happens (when it changes from "collecting resources" and starts displaying numbers again). Go to the previous (parent) project; this will be your original.

• In the original project, there is at the upper left hand corner of the

world a string informer saying "extra associations". This means (to the three or four people who know and remember this) that "something bad happened and your project didn't get saved correctly."

• The cause of this was an improperly renamed class called "ZTime" which

is

...

being held in the change records of a change set which is being held by

the

...

ChangeSorter that you have in your project.

I'm looking into how we could better handle this kind of thing.

Goran,

Thanks for your notes, one question inline .. On July 10, 2004 09:06 am, goran.krampe@bluefish.se wrote:

Milan Zimmermann milan.zimmermann@sympatico.ca wrote:

<<snip>>

Ned explained in another post - check that.

Thanks, I followed up ...

...

(70K),please let me know if it makes sense / would help to attach it here. Or if I can be helped to get the "log".

...

Also - saving a Project on file should produce (IIRC) a so called "export" ImageSegment, otherwise it wouldn't be loadable in another image.

Unfortunately I do not know enough about Squek to know what this means :(

Nothing important - it sounded like you were wondering if a saved Project actually resulted in a so called "export ImageSegment" instead of a non-export ImageSegment (there are two kinds). A non-export ImageSegment can't be loaded into another image. Project files are always export ImageSegments.

I know I should do my homework for this, well, skipping that, a question: What is "non-export ImageSegment" good for? Just for a "manual overview", sort of a dump that is more readable than the "export version"? (From your note I assume that "export version" is good for a follow-up load :) )

Thanks Milan

But anyway, as I said - not relevant.

If you post that log we can probably figure it out. I hope. :)

regards, Göran