[comp.lang.smalltalk] Unwanted Instances

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