831059l@aucs.UUCP (Langlois) (10/20/88)
I just started to use Smalltalk/V so please bare with my questions. I am using Smalltalk/V and have filed in the multiprocessing classes that came on the Goodies disk. I need the multiprocessing for doing simulations my area of study in school. I want to modify to hierarchy of classes which I created but when I try to execute Uniform removeFromSystem I get a walkback window saying that Uniform has instances. When I execute Uniform allInstances I get (an Uniform) back so its there somewhere, but where? How can I find out where this instance is? Another more general question is, is Smalltalk/V286 better than Smalltalk/V? Could someone, hopefully someone who has used both, give a short comparison of the two, advantages and disadvantages. Thanks in advance for any info. Steven Langlois UUCP: {uunet|watmath|utai|garfield}!dalcs!auc!831059l Acadia University BITNET: Steven@Acadia Wolfville, NS Internet: Steven%Acadia.BITNET@CUNYVM.CUNY.EDU CANADA B0P 1X0
elt@entire.UUCP (Edward L. Taychert) (10/22/88)
In article <1318@aucs.UUCP>, 831059l@aucs.UUCP (Langlois) writes: > > I just started to use Smalltalk/V so please bare with my questions. > I am using Smalltalk/V and have filed in the multiprocessing classes that > came on the Goodies disk. I need the multiprocessing for doing simulations > my area of study in school. I want to modify to hierarchy of classes which > I created but when I try to execute > > Uniform removeFromSystem > > I get a walkback window saying that Uniform has instances. When I execute > > Uniform allInstances > > I get (an Uniform) back so its there somewhere, but where? How can I find > out where this instance is? > I've had the same problem. Digitalk customer support gave be the WORKAROUND and I wrote it into the jacket of my manual. Unfortunately, that's at home. Here's the best that I can remember: Uniform allInstances do: [:i| i become: String new ] The nil strings are reaped on the next garbage collection. I've had to do this so often that I keep it in my transcript pane. I also get phantom panes. The only way I know to get rid of them is Scheduler reinitialize Warning, this wipes out all panes, including the Transcript pane. Save anything that you really want to keep to disk first. Customer support tells me that both problems are fixed in 286V but I don't have it yet and cannot verify the statement. -- ____________________________________________________________________________ Ed Taychert Phone: USA (716) 381-7500 Entire Inc. UUCP: rochester!rocksanne!entire!elt 445 E. Commercial Street East Rochester, N.Y. 14445 _____________________________________________________________________________
jans@tekgvs.GVS.TEK.COM (Jan Steinman) (10/28/88)
<If anyone has any tried-n-true heuristics for chiseling an obnoxious object loose from an image, I'd sure like to hear about it.> I don't have a quick answer, but there are ways of avoiding generating "obnoxious objects" in the first place. Any object that is potentially circular (which includes any object that stores BlockContexts) should implement "release", which should always include "super release". "release" should nil the fields that contain BlockContexts or could be circular. (If you're dredging up MethodContexts, your obnoxious object probably references BlockContexts.) The need to store BlockContexts is a real problem, but avoiding direct circularities is a bit easier to deal with. The reasons circular objects are created can often be fulfilled by judicious use of "thisContext", which is the execution state of a particular method. (C++er's drool! You'll never do this!) I've implemented a number of methods for detecting recursion and carrying on a dialog with a sender, and I find I can often use these instead of creating circular references. :::::: Software Productivity Technologies -- Experiment Manager Project :::::: :::::: Jan Steinman N7JDB Box 500, MS 50-383 (w)503/627-5881 :::::: :::::: jans@tekcrl.TEK.COM Beaverton, OR 97077 (h)503/657-7703 ::::::
obrien@anpiel.aero.org (Mike O'Brien) (10/29/88)
In article <4157@tekgvs.GVS.TEK.COM> jans@tekgvs.GVS.TEK.COM (Jan Steinman) writes: >Any object that is potentially >circular (which includes any object that stores BlockContexts) should implement >"release", which should always include "super release". "release" should nil >the fields that contain BlockContexts or could be circular. (If you're >dredging up MethodContexts, your obnoxious object probably references >BlockContexts.) > >The need to store BlockContexts is a real problem, but avoiding direct >circularities is a bit easier to deal with. >I've implemented a number of methods for detecting recursion and >carrying on a dialog with a sender, and I find I can often use these instead of >creating circular references. True, "release" is a good first level of defense, and I've written a whole bunch of "release" methods in my time, and even, in desperation, some "superrelease" methods for hand invocation in cases of very stubborn objects. Not even these always work. The basic problem seems to be those cases where an execution error interrupts the normal flow of control and prevents various "release" methods from ever being sent. And in most cases, it is not my own objects which directly hold the circularities. In general my problems have been caused, as best I can determine, by the BlockContexts held by Buttons as actions. I phrased my question in a somewhat more general way in order to elicit the most general possible responses. The only thing I can think of to do is to implement a special case of your "dialog": a set of special release messages which causes a flurry of other "release" messages to be sent down through subsidiary objects, to break up circularities which invade the lower levels. A straight mark-and-sweep GC should still eliminate these, but when things start getting esoteric, it would seem that these interrupted control sequences can leave these low-level things hooked strongly into the remainder of the image. It's very annoying. -- Mike O'Brien obrien@aerospace.aero.org {sdcrdcf,trwrb}!aero!obrien
jans@tekgvs.GVS.TEK.COM (Jan Steinman) (11/01/88)
<<jans@tekgvs.GVS.TEK.COM (Jan Steinman)>>
<obrien@anpiel.aero.org (Mike O'Brien)>
<<Any object that is potentially circular... should implement "release"...
I've implemented a number of methods for... carrying on a dialog with a
sender...>>
<..."release" is a good first level of defense..., (but doesn't) always work..
(for) those cases where an execution error interrupts the normal flow of
control and prevents various "release" methods from ever being sent... The
only thing I can think of to do is to implement a special case of your
"dialog":>
(N.B.: The following is for Tek Smalltalk, your mileage may vary. I just
wrote it on the spot to illustrate the point, and it should not be considered a
fully debugged solution!)
As a starting point, here is a method that will execute a block for each sender
in the context. When things break, DO NOT throw away the debugger, instead,
execute within the debugger:
thisContext sendersDo: [:sender |
(#(TroublesomeClass1 TroublesomeClass2) includes: sender class)
ifTrue: [sender release]]
Note that simply putting "sender release" in the block will probably
irrepairably damage your image, as things like ControlManager get released!
{!ContextPart methodsFor: 'testing'!
sendersDo: aBlock
"Cause each sender receiver to execute <aBlock> with itself as the argument."
| ctx |
ctx _ self.
[true] whileTrue:
[aBlock value: ctx receiver.
(ctx _ ctx sender) == nil ifTrue: [^self]]! !}
:::::: Software Productivity Technologies -- Experiment Manager Project ::::::
:::::: Jan Steinman N7JDB Box 500, MS 50-383 (w)503/627-5881 ::::::
:::::: jans@tekcrl.TEK.COM Beaverton, OR 97077 (h)503/657-7703 ::::::
jaffe@jaffe.mc.ab.com (Bruce Jaffe (ext 3581)) (02/19/91)
How do you get rid of unwanted instances in ST/V286? I am trying to modify a class, but get a walkback with "Has instances". I have tried "Scheduler reintialize". Since I am running with Acumen's Widgets/V286, I have also tried their "close windows" system menu entry, which usually clears up this sort of problem. Neither of these does the trick. I looked at allInstances of the class, and allReferences to each instance. Apparently, there is just one instance with no references. Just to make things more interesting, executing PageText allInstances do: [:each | each allReferences] sometimes causes the system to return to DOS in a most undignified manner, with the error message "Exception 0D: General protection fault, Error code/ selector: 0934" Any ideas on how to proceed?
cooper@netcom.COM (Ken Cooper) (02/20/91)
Bruce, Since you have Widgets, you can use a method we've added. Try sending the message #removeInstances to the offending class. Note that this will transform all instances of the class to new strings, so don't do this in places where you might depend on the objects still being there. Ken Cooper Acumen Software
pkr@media01.UUCP (Peter Kriens) (02/20/91)
If you have instances you cannot get rid of with: DisplayScreen initSystem or ApplicationWindow removeInstances, then there is only one way out: <Myclass> allInstances [ :c | c become: (String new:0) ]. Where ofcourse <Myclass> is the class that has the instances. This leaves some pointers pointing to an unexpected object. If you really experience this problem often, take a clean image and file in your changes (Isn't a bad idea anyway). Peter Kriens pkr@media01