Need Help to understand
arning at charm.net
Sat Aug 19 18:55:21 UTC 2000
On Sat, 19 Aug 2000 13:20:28 -0400 Raymond Asselin <raymondasselin at sympatico.ca> wrote:
>as I'm new to Smalltalk (and I'm not a programmer, but love
>Smalltalk) I have to digest what you send me...I'm not mastering the
>Dependents mecanisms yet. But for now i evaluated 'Smalltalk
>reclaimDependents' which I found looking for 'dependents' in the
>Method Finder, and my image shranked from 20 Meg to 9.5 Meg. so
>that is nice. But I don't yet understand the source of the problem so
>may be the problem will come back.
It probably will. While #reclaimDependents cleaned out a lot of stuff you didn't need any longer (and, perhaps, some that you actually do want), it didn't do anything about the source of the problem.
>I readed in a book I have, "Inside Smalltalk, volume II", that this
>mecanism is intended <principalement> for MVC. AFAIK I used
>exclusively Morphic...so ???
That's more or less correct. While the DependentsFields mechanism is intended for use with MVC, it can be used anywhere, although the results aren't always optimum, as you are finding out.
>An unrelated question: where can I find information about
>"Undeclared", and what we have to do when we saw that message in a
>Transcript ? I allready know that it is a Global variable in the
>Smalltalk dictionnary. But who put something there, when, why, how
>and...do we have something to do with it...
> 'Smalltalk at:#Undeclared' give me:
>a Dictionary(#IntegerKeyDictionary->nil #IntegerSet->nil
>#NbCibles->nil #PluggableFileListMorph->nil #PutNewClassHere->nil
>#Screen->nil #UsingIsolation->nil #appl->nil #classArray->nil
>#copy->nil #dict->an IdentityDictionary() #draggedMorph->nil
>#fillColor2->nil #gradientDirection->nil #mainValue->nil
>#methodDictArray->nil #openToDragNDrop->nil #orgArray->nil
Undeclared is a dictionary where Squeak keeps a record of references to things for which it can find no definition. This happens most often while filing in code, where Squeak is a bit lenient in assuming that things will be fixed up by the time the file-in is complete Those messages you saw in the Transcript were essentially warnings during the file-in process that this was happening. It can also occur when, e.g., you remove a class variable from a class that still has methods referring to that variable. In such cases you are asked if you want to move the variable to Undeclared. To check on the things in undeclared, there is an item in the world/do menu
Undeclared removeUnreferencedKeys; inspect
which will do something like the 'Smalltalk at:#Undeclared' you used, but first it will remove those entries for which there are no longer any references. I suspect that most of what you saw will be gone after doing this. If you want to understand a bit more about how things get into and out of Undeclared, you can find references to it by selecting the word Undeclared and doing cmd-shift-N (or alt-shift-N). This will point you to a number of methods that refer to Undeclared. The most relevant are those in Class, Encoder and SystemDictionary.
Now, on to the heart of your problem. What I would suggest is this:
1. start with a reasonably clean image.
2. do 'Undeclared removeUnreferencedKeys; inspect' to see things Undeclared in a clean image.
3. do 'DependentsFields inspect' to see the dependents in a clean image
4. file-in whatever code you have been using.
5. do steps 2 and 3 again to see what the mere act of filing in code may have changed. You may, for instance, see some new Undeclared entries if the filed-in code was for an earlier version of Squeak and things that it referenced are no longer present. If there are new entries, you can find the methods involved by selecting one of the names in the upper left of the inspector on Undeclared and selecting 'references' from the menu on that pane. These may need to be fixed to avoid problems.
6. run whatever tests you have been running that may have been creating instances that never seem to go away.
7. do step 3 again to see what new entries there are in DependentsFields. If, in fact, you now see some of your classes appearing in the list, we are getting close. There are basically two ways to deal with these entries:
-- 7a. Remove them when no longer needed. Very often these are added when some UI component is created. The UI has some sort of model that it represents and says something like:
model addDependent: self
to insure that it knows when it needs to display new information. The key to this approach is to balance each of these messages with
model removeDependent: self
when the UI is no longer interested in the model (like when it is deleted). This can often be rather difficult to manage, so there is another option:
-- 7b. Don't put them there in the first place. Any object in squeak can have a dependent and DependentsFields is a very general mechanism that deals with this. An alternate approach is illustrated by the class Model (and its subclasses). Here the dependents to an object are kept within the object so that when the UI is deleted and if the only references to the model were from the UI, then garbage collection will be able to remove both the modle object(s) and the UI object(s). For this to work, you need your model classes to be subclasses of Model (as are the example classes in the original BobsUI).
That's probably far enough without knowing some of the results of the above experiment. Let me know what you find.
More information about the Squeak-dev