Menu
▾
▴
Re: [Visualpython-users] Question about frame objects
|
From: Bruce S. <Bru...@nc...> - 2005-12-16 17:18:58
|
This may be a feature rather than a bug after all, but at a minimum the documentation needs to be corrected. There's a subtle connection to the way deletion of objects works in Visual. In Python itself, if an object no longer has a reference to it, that object is eligible for deletion (through periodic garbage collection). For example, suppose you write rec = recordobject(name, id, age) and then later say rec = 5. Now there is no longer any way to refer to the recordobject you had created, and Python can eventually get around to freeing up the memory occupied by the object. The way this works is that there is a reference count associated with every object, and if this count ever goes to zero, the object can be deleted. (As another example, if after creating the object labeled "rec" you said b = rec and c = rec, the reference count would be 3, and executing rec = 5 would reduce the reference count on the original object to 2.) In the Visual environment there's an additional reference count corresponding to the human viewer, if the object is visible. Suppose you say s = sphere(). Essentially, this humanly visible object has a reference count of two. If you say s = 5, the reference count on the sphere decrements to 1, not to zero, because there's a human still looking at the object. If instead of saying s = 5 you say s.visible = 0, the reference count also decrements to 1, not to zero (there's still the s reference to it), and later you can get the sphere back by saying s.visible = 1. If on the other hand you say s = 5 and then try to say s.visible = 0, you get an error because 5 doesn't have a visible attribute. This means that a visible object with no symbolic reference cannot be deleted (because a human is viewing it, and there's no way to make it invisible). The only way to delete a sphere from memory is to first make it invisible, then remove symbolic references to the object; this reduces the reference count to zero and makes the memory reclaimable by Python. Associated with a frame (and a display) is an attribute "objects", which is a list only of the visible objects in that frame or display. The basic reason is that if this list also included invisible objects, the reference to that object in this list would essentially give an additional reference count to the object, adding even more complexity to this rather complex situation. And if somehow we all figure out how to define the behavior in such a way that making an object in a frame be invisible without removing it from the "objects" list, it's possible that this nonremoval would apply only if you created the object with a name, but it would be removed if you didn't give it a name. Yuck. One possibility that occurs to me is that it might be possible to implement frame.visible = 0 which I think could be unambiguous: make the objects in this frame temporarily invisible not because they themselves have visible = 0 but because the frame they're in does. I note that currently something odd happens with this: f = frame() s = sphere(frame=f) f.visible = 0 print f.objects RunTimeError: boost::bad_weak_ptr As a first step it seems like I should make it clear in the documentation that frame.objects and display.objects are lists solely of visible objects. Comments and corrections are welcome! Bruce Sherwood wrote: > For completeness, I tried this on an old version of VPython (Python > 2.3 plus Visual from October 2003). Both in that old version and the > current one, when an object is made invisible it is also removed from > the display.objects and frame.objects lists. This seems like a design > flaw, since as you point out once the object has been removed from the > list you can't find it that way. You'd have to keep a copy of the list > before making anything invisible. > > I have a very dim recollection that this was supposed to be a feature, > not a bug, that if an object was invisible you didn't want to be told > about it while looking through the list of objects. Does anyone > remember anything about this? At the moment (admittedly it's late at > night, so I might be thinking fuzzily) it seems much better to keep > the invisible objects in the lists so that you can reference them > again through the list, as you tried to do. Looping through the list > you could easily skip objects that are invisible, if that's what you > want to do. > > Bruce Sherwood > > Jeremy Sachs wrote: > >> The VPython documentation says that the objects in a frame can be >> made "temporarily invisible" with the following: >> >> for obj in someframe.objects: >> obj.visible=0 >> >> And that works, only not temporarily. For any other object, I can >> set the "visible" property to 1 and that object will be drawn. I >> can't get this to work with the contents of a frame. Am I >> overlooking something? There are three labels in the frame, as well >> as more typical objects, but I don't suspect them to be the source >> of the problem. Could someone please offer a suggestion? >> >> -Jeremy S. >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. Do you grep through >> log files >> for problems? Stop! Download the new AJAX search engine that makes >> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >> _______________________________________________ >> Visualpython-users mailing list >> Vis...@li... >> https://lists.sourceforge.net/lists/listinfo/visualpython-users > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users |