| Re: Object Madness or Restoring Nightmares [message #38342 is a reply to message #38341] |
Wed, 03 March 2004 12:26   |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
JD Smith writes:
> I think it's actually simpler than that. I suspect that if you follow
> the train of objects containing pointers to objects with pointers
> etc., you'll find that some object somewhere beneath your "theStudy"
> object actually has a pointer or object reference to the top-level
> application object in it.
OK, I like this theory. Here is my problem. (Those of you whose
eyes are already glazing over are excused. You can read the
Executive Summary to follow in a couple of days.)
My study object contains three object references: one to the imageCube
object that exists at the main application level and which is stored
as a field in the top-level object, and two to IDL container objects.
One container is empty, so don't worry about it. The other
container contains ImageSlice objects, which are abstractions simply
to draw a particular slice of the imageCube object. As such, they
also contain references to the original imageCube object. The only
other object an ImageSlice contains is a WindowIndex number reference
to a drawWidgetObject, that is a child of the "self" or main object.
This may be your connection back to the main object.
OK, before saving the studyObject I null out the ImageCube reference,
and I go through both containers, get all the ImageSlice objects and
null out their imageCube references and their WindowIndex references.
The imageSlice objects now don't point to anything, and the studyObject
only has references to ImageSlice objects that should be nulled out.
So now, I get the original data from the ImageCube object everyone has
been pointing to, and I save it *along* with the the studyObject in
a save file. (I need the data, that is the most important part of a
"study".)
Are you ready? I am chagrined to see that my save file (which you
remember should have been about 3 MB and was already a bloated
10 MB) is now nearly 13 MB!. And, I *still* have 1203 unnecessary
objects stored in my save file. I take it my save file is now all
the objects from before *plus* the real data.
Now, *all* objects in this program inherit from a single object
class. I can understand if we had to save down to that object
class. But I think IDL got down to that object class (CATATOM,
by the way) and saved *all* the current objects that inherit from
that class! That is the only explanation that makes sense to me.
If that is true, I begin to understand some of the complexity of
the iTools system, which doesn't work with objects at all, but
with "descriptions" of objects. They would absolutely have to
do this or they could never save and restore any of their iTool
objects. Someone there must have run into this problem.
> If this is the case, here's what happens: IDL very dutifully follows all
> of these downward-linking object/pointer chains, collecting and saving
> everything it finds on the way. This is the correct thing to do, since,
> as far as it knows, to have a valid "theStudy" object on disk requires
> all of its various holdings. Now, if at some point down the chain, IDL
> runs into an object which is just a convenience reference to the top
> level application object, it will dutifully jump right to the top of the
> heap and start saving the whole thing.
I can't think how, in its current configuration, IDL could possibly get
back to the top. I've been through these objects with a fine-tooth comb.
There are *no* valid object references except to containers of objects
that do not have valid object references.
> This is a problem. It's actually a bigger problem than you think,
> because (see the various articles on your site describing it), any
> object which is saved has implicit in it its class definition, so if you
> accidentally save 10 extra objects of different classes along with the
> one you're really interested in, when you restore them, any updates to
> any of the class definition files (class__define.pro) will never be
> consulted, since IDL thinks it already knows all about them. The
> much-discussed solution is to explicitly resolve the class *before*
> restoring the object. You can find my latest incarnation of my routine
> which automates this here:
>
> http://turtle.as.arizona.edu/idl/restore_object.pro
Alas, that EXECUTE statement makes this virtually useless
to me except as an academic exercise. :-(
I've preferred not to think about this for the moment.
I'm just assuming the client is always working with a fully
compiled project so that which definition we are using is well-defined.
That will probably bite me later, as this project just never seems
to go away.
> So, how do you avoid this situation? What I do is "detach" all the
> irrelevant data from my object before saving it. I've talked about this
> before, but the basic idea is (in your terms):
>
> theStudy = self.currentStudy
> theStudy->Save,'somename.sav'
>
> with
>
> pro theStudy::Save,filename
> saved_ptr=self.BigAndUselessDataPtr ; detach
> self.BigAndUselessDataPtr=ptr_new() ; a null pointer
> save, self,FILENAME=filename
> self.BigAndUselessDataPtr=saved_ptr ; reattach
> end
>
>
> and to restore it:
>
> theStudy=restore_object(file,'theStudy')
> if obj_valid(theStudy) then begin
> if NOT obj_isa(theStudy,'theStudy') then $
> message,'Error restoring Study file: '+file
> ;; The study is valid
> obj_destroy,self.currentStudy
> self.currentStudy=theStudy
> endif
>
> This requires, of course, that you plan ahead and group all of the data
> that isn't necessary to include in the save file in some conveniently
> detachable object or pointer (or perhaps a few of them). Aside
> from convenience object references, widget data is a good
> candidate for detachment. Detaching an object reference works just the
> same, but with "obj_new()" instead of "ptr_new()".
If I understand you correctly, this is exactly what I have
tried to do, and I find myself worse off than before. I've
appealed to the IDL newsgroup because the RSI technical support
people don't exactly like to hear from me with my "big file"
examples. :-)
Cheers,
David
P.S. Let's just say if you can't reduce the problem to a 10
line program you just don't understand it well enough to ask
questions about it. :-)
--
David Fanning, Ph.D.
Fanning Software Consulting
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
