Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!ut-sally!seismo!gatech!akgua!whuxlm!whuxl!houxm!ihnp4!inuxc!pur-ee!uiucdcs!uiucdcsb!graver From: graver@uiucdcsb.CS.UIUC.EDU Newsgroups: net.lang.st80 Subject: HELP, Smalltalk problems Message-ID: <9500001@uiucdcsb> Date: Thu, 26-Jun-86 03:55:00 EDT Article-I.D.: uiucdcsb.9500001 Posted: Thu Jun 26 03:55:00 1986 Date-Received: Mon, 30-Jun-86 03:14:24 EDT Lines: 47 Nf-ID: #N:uiucdcsb:9500001:000:2614 Nf-From: uiucdcsb.CS.UIUC.EDU!graver Jun 26 02:55:00 1986 I am working with Ralph Johnson on building a type system for Smalltalk-80, and we have run into some problems. (By the way, we are running Smalltalk-80 on the Tektronix 4404.) Most of the difficulties arise when we attempt to add instance variables to classes with many instances (e.g. ClassDescription, MethodDictionary, etc.). In the case of ClassDescription, we tried to add an instance variable which required that every class be recompiled. When the system was about half done with this recompiling we started getting "Low On Memory" warnings. Plodding on undaunted we eventually got thrown out of the Smalltalk interpreter with the message: "Smalltalk system error - Too many objects." When we tried to add an instance variable to the class MethodDiction- ary we encountered a quite different problem. MethodDictionary was recompiled with no problem, but then the "updateInstancesFrom: oldClass" message was sent to the class description for the new class (MethodDictionary). This involved "recreating any existing instances of the argument, oldClass, as instances of the receiver, which is a newly changed class." The following message appears in the method, oldClass allInstances do: [:old | ... old become: new] The "allInstances" message yields a collection of all the MethodDictionaries in the system. These are then updated one at a time, as "new", and then the object pointers are swapped with the "become:" message. The problem occurred when "become:" tried to swap the object pointers for the MethodDictionary that contains the definition for the "become:" message. We are thrown out of the Smalltalk interpreter with the message: "Smalltalk system error - recursive DoesNotUnderstand:." We have a suspicion that the interpreter may assume certain things about some fundamental classes and that adding instance variables as described above may be impossible. It would be helpful if someone could confirm or deny this. We have also considered using the system tracer to modify such large classes, but feel that this may be an unreasonable solution. Has anyone ever used the tracer for such a purpose and is it feasable? Unless these problems can be solved, our present solution is to change the meaning of existing instance variables (for example, a list could easily become a list of ordered pairs or ordered triples) or to build each "new" class from scratch. Has anyone come across these problems before? Has anyone found any solutions? Does anyone have any suggestions? I would appreciate any information that anyone thinks would be helpful, thanks. Justin Graver