visualpython-users

Re: [Visualpython-users] Correction

[Anton S. <br...@po...>]

Bruce Sherwood wrote:
 > thanks to Rob Salgado for bringing up the possibility
 > of color stereo with red-cyan or yellow-blue glasses.

Since green is the brightest of the primaries,
I wonder why nobody uses green-magenta.

-- 
Anton Sherwood, http://www.ogre.nu/

[Visualpython-users] Correction

[Bruce S. <bas...@un...>]

I made a mistake in the deployment of the color stereo versions 
yesterday, now corrected (Win/Linux/Unix/OSX). And by the way, public 
thanks to Rob Salgado for bringing up the possibility of color stereo 
with red-cyan or yellow-blue glasses.

In the current implementation fully saturated object colors are 
displayed with 50% saturation, which ensures that both eyes have 
something to see. With the 50-cent red-cyan paper glasses I have, the 
cyan filter almost perfectly excludes all red, but the red filter allows 
quite a bit of green through, making ghosts in the view seen by the left 
eye. These ghost images are more or less noticeable/annoying/distracting 
depending on the details of how extreme the stereo is, the background, 
etc. Even with shutter glasses there are some ghosts, though typically 
less noticeable. However, shutter glasses plus a special graphics card 
are a lot more expensive, and there is flicker unless you can drive the 
monitor at a very high repetition rate.

It would seem worthwhile to see whether it would be possible to find a 
red filter that passes plenty of red light yet excludes almost all green 
(and blue). I don't know whether this is feasible, given the overlap in 
sensitivity of the red and green receptors in the eye.

Bruce Sherwood

[Visualpython-users] Linux/Unix redcyan

[Bruce S. <bas...@un...>]

New installers for Linux/Unix/OSX with redcyan and yellowblue color stereo.

Bruce Sherwood

[Visualpython-users] Color stereo with cheap glasses

[Bruce S. <bas...@un...>]

The redcyan and yellowblue stereo modes have been changed to produce 
color displays. This has been implemented by unsaturating the colors by 
50% (that is, multiplying the saturation by 0.5), to ensure that there 
is something to see for both eyes. New Windows installer, Linux/Unix to 
follow. This provides very cheap color stereo; all you need are 50-cent 
glasses.

I consider this to be experimental. Those of you who have redcyan or 
yellowblue glasses, please take a look at this and tell me what you think.

Bruce Sherwood

Re: [Visualpython-users] another idle annoying thing

[Jonathan B. <jbr...@ea...>]

On Thu, 2003-10-02 at 18:27, Richard Chapman wrote:
> hi
> 
> also is it just me, or does ctrl+c and ctrl+v etc not work in the idle if
> the caps lock key is on?
> 
> rich

We aren't really maintaining Idle as part of this project anymore.  You
should probably try upgrading to Python 2.3 (or backporting the Python
2.3 idle to Python 2.2), and failing that, you should file a bug report
with the core Python development team at www.python.org.

-Jonathan Brandmeyer

Re: [Visualpython-users] idle again

[Jonathan B. <jbr...@ea...>]

On Thu, 2003-10-02 at 18:29, Richard Chapman wrote:
> okay i closed idle and reloaded it then opened the files again, and
> everything was fine?
> 
> dont know what going on
> 

I don't mean to sound harsh, but without a complete, working test case
that clearly demonstrates the problem, I have no idea what you are
talking about.  I certainly haven't seen this problem before.

-Jonathan Brandmeyer

[Visualpython-users] idle again

[Richard C. <ax...@ch...>]

okay i closed idle and reloaded it then opened the files again, and
everything was fine?

dont know what going on

any help

thanks rich

[Visualpython-users] another idle annoying thing

[Richard C. <ax...@ch...>]

hi

also is it just me, or does ctrl+c and ctrl+v etc not work in the idle if
the caps lock key is on?

rich

[Visualpython-users] idle problem i think

[Richard C. <ax...@ch...>]

hi

i dont know whats going on, i am having problems where i am working with two
files, one a main file main.py and the other a class file cf.py, now i run
the main file and it crashes with a trace back to the class file cf.py and
the fileline number. okay so i change the cf.py file and save it and F5 it,
then i go back to the main.py file and run it it comes back with the
same error. i comment out the problem line in the cf.py file, i save it and
f5 it. i then go back to the main.py file and run it again. it crashes with
the same trace back information before, same line number that was the
problem before, but now displays the commented out line.

cf.py and main.py are in the same directory, dont know what other
information you need, but whats going wrong?

rich

any help is appreciated

[Visualpython-users] red-cyan stereo

[Bruce S. <bas...@un...>]

I bought some cheap red-cyan glasses from www.reel3d.com and find that 
they are in some ways significantly better than the more common red-blue 
glasses for cheap stereo. With red-blue, the complete lack of green to 
which the eye is particularly sensitive makes the overall scene quite 
dark, and overlap regions are magenta, which isn't very attractive. With 
red-cyan, the scene is much brighter, and overlap regions are gray, 
which looks nicer. It is true that "ghosts" are somewhat more of a 
problem with red-cyan, but surprisingly not as much as one might expect.

It seems possible that one might even achieve something like full color. 
In the overlap regions, which are gray with the current implementation 
of scene.stereo = 'redcyan', in principle one could display all colors, 
with only the nonoverlap areas being limited to red and cyan. Even if 
there is no overlap, you could still perceive full color if the red 
channel plus the cyan channel preserved the full color information. 
However, that would mean that a pure red object would display to only 
the left eye (and an object that has no red content would display only 
to the right eye). Perhaps one could unsaturate the colors somewhat 
(that is, add some white) to ensure that all objects had some red and 
cyan? Maybe this is worth tinkering with.

Bruce Sherwood

[Visualpython-users] VPython and LiveZope

[Bruce S. <bas...@un...>]

-------- Original Message --------

Subject: 	Re: Vpython in bootable linux cdrom
Date: 	Wed, 1 Oct 2003 23:35:34 +0800
From: 	chu-ching huang <cc...@ma...>
To: 	Bruce Sherwood <bas...@un...>
References: 	<000901c38720$258ebac0$a76819a3@math> 
<3F7...@un...>


Hi Bruce Sherwood,

As attached, VPython example running under pythonIDE, boa-constructor,
in LiveZope-0.1.

Best regards,
-----------------------------------------------------------------
chu-ching huang

email address:cc...@ma...

************************

I asked Chu-Ching Huang about what he had sent me, and here are his comments:

On Wed, 01 Oct 2003 22:10:36 -0400, Bruce Sherwood wrote

> Thanks much for showing this to me. Please explain the significance,

> because I don't know what boa-constructor is, nor Zope, nor LiveZope,

> nor Knoppix. As you can see, my ignorance is quite broad!

Boa-constructor is a project supported by sourceforge. It is similar to IDLE

but with more functionalities.

Zope is open CMS, Content Management System, developed mainly by Python.

It owns its http and ftp server abilites.

Knoppix is live Linux CDROM. As booting from this CDROM, Linux is ready for

users. LiveZope is Knoppix- based integration of Python resource, including

Zope with its products, VPython, biopython etc.  It is built for establishing 

Linux-based courses including Math, Phy and Med.


> Your development may be very important, because many people have wanted

> to be able to run VPython programs in a browser. Is that what you 

> have achieved? Can this work in other browsers?

I purpose to integrate the Vpython codes into Zope server but no achieved.

It can only run on Xterm or IDE env.


> I only see one of the two graphics windows that gas.py produces. The

> other is an animation of a gas of colliding hard spheres. Does your

> environment not display the animation window?

The animation is displayed but removed as catching picture by the program

"ksnapshot".


> Is your work available to others? If so, I would be pleased to advertise

> your work to the VPython community through its user mailing list.

Yes, LiveZope is also released under GPL license. 

The previous LiveZope-0.1 can be downloaded from:

http://sourceforge.net/projects/open-outcomes

or

ftp://ftp.texmacs.org/pub/TeXmacs/knoppix

And the last LiveZope-0.1.2 can be downloaded from

ftp://math.cgu.edu.tw/pub/KNOPPIX

Best regards, 

----------------------------------------------------------------- 

chu-ching huang 

email address:cc...@ma... <mailto:address:cc...@ma...> 

 

Re: [Visualpython-users] Visual in a frame or window...

[Jonathan B. <jbr...@ea...>]

On Wed, 2003-10-01 at 13:16, IVES,THOM (HP-Boise,ex1) wrote:
> VP Users,
>  
> I am curious if anyone else has ever wished that they could run
> VPython within a tkinter frame or window, or within a wxPython frame.
> It seems that this would have some nice benefits with respect to some
> of the projects that I have used it on.
>  
> Thom
>  

At the moment you can't really do that, in the same program.  However,
someone else pointed out recently that you can run a Visual-based
program in a separate python interpreter and communicate with it via a
pipe or socket.  I haven't tried this method myself.

-Jonathan Brandmeyer

[Visualpython-users] Visual in a frame or window...

[IVES,THOM (HP-Boise,ex1) <tho...@hp...>]

VP Users,
 
I am curious if anyone else has ever wished that they could run VPython
within a tkinter frame or window, or within a wxPython frame. It seems that
this would have some nice benefits with respect to some of the projects that
I have used it on.
 
Thom
 

 
 
  _____  

 
<http://www.hp.com/Redirect/gw/useng_welcome/logo/=http://welcome.hp.com/cou
ntry/us/eng/welcome.htm> HP logo	 
Thom Ives, Ph.D.

R&D Engineering Scientist	

11413 Chinden Blvd MS 400
Boise, ID.  83714

208.396.6880 Phone
208.396.3587 Fax
tho...@hp...  <mailto:tho...@hp...> 

Home:
5556 N Columbine Pl
Boise, ID 83713
208.938.9357 Phone
208.332.6558 Fax
tw...@ca... <mailto:tw...@ca...> 
  _____  

 
 

[Visualpython-users] Just the DLL

[Bruce S. <bas...@un...>]

I should probably mention that if you're running Python 2.3 on Windows, 
you don't need the whole VPython package. You can just download the DLL 
(link at the bottom of the Windows download page) and replace the one in 
C:\Python23\Lib\site-packages\visual.

Bruce Sherwood

[Visualpython-users] New Linux/Unix/OSX installer

[Bruce S. <bas...@un...>]

The Linux/Unix/OSX installer now contains Jonathan Brandmeyer's fix to 
the obj.visible bug. Graphing now works much better on Linux, though 
there is still some other bug present. A graph window from a previous 
run stays around until the next run; there's always an extra, though it 
doesn't seem to cause much harm and does go away when you quit completely.

Bruce Sherwood

[Visualpython-users] Fix on Windows

[Bruce S. <bas...@un...>]

Jonathan Brandmeyer found and fixed a major bug in Visual that showed 
itself mainly in programs that make graphs. He found a mistake in the 
ordering of locking and unlocking resources associated with making an 
object visible or invisible. The locking/unlocking sequence was 
inconsistent between the main thread and the rendering thread. 
Manipulating obj.visible isn't very common in VPython programs, but the 
graph module does this a lot when autoscaling to display or hide tick 
marks as needed along axes. Hence it was programs that make graphs that 
show the problem most often.

This fix doesn't cure all problems with graphing, so there must be 
another bug lurking somewhere, yet to be found and squashed. But it 
reduces the frequency of the problems and makes them milder. In 
particular, you can kill the windows -- no zombies. The remaining 
problem is that sometimes the graphing window stops graphing while other 
windows continue along their way, which sounds like a different problem.

New Windows installer; other platforms to come shortly.

A partial workaround if you're unable to update immediately is to 
specify fixed graphing axes with something like

    gdisplay(xmax=100, ymax=50)

This helps by reducing the obj.visible manipulations involved in 
autoscaling the axes.

Thank you, Jonathan!

Bruce Sherwood

Re: [Visualpython-users] gdisplay objects seldom work

[Jonathan B. <jbr...@ea...>]

On Tue, 2003-09-30 at 08:49, Roger Fearick wrote:
> On Mon, 29 Sep 2003, Bruce Sherwood wrote:

> The result is a frozen window, usually displaying the minimum
> axes possible (i.e. the problem seems to lie in the creation of the
> window). 
> In general, related activity in a display window will continue.

Can you send me an example of this behavior?  All of the locks that I
have seen have locked all of the windows.  Sometimes there would be a
hiccup and the main window would jump, but the main window would never
keep rendering new frames when the other windows were frozen.

> I guess that this is related to threading and some deadlock. 

I think that the problem was that the Python thread and the rendering
thread were obtaining a pair of mutex locks in opposite order from each
other, creating a race condition to lock the second mutex and the
subsequent deadlock.

> I've
> tried to trace through the code and find whereabouts the stall
> is happening, but with little success - the usual problem with an
> intermittent fault! However, some tests did seem to suggest that it got
> lost between the exit from gdisplay's __init__ and the next call to the 
> class instance.
> One thing is that it does seem worse on machines that are a little tight 
> on memory.
> It is the one thing that does upset students a little with the visual 
> package, otherwise they seem to like it.
> 
> Roger.

I have a VPython script that consistently locked up my computers, and
now it runs fine with the Boostified version of VPython.  However, just
because I can't reproduce the bug anymore in this case doesn't mean it
isn't there.  I could use a few more people's eyes on this one.

I haven't written generic build scripts for any platform, but I can
e-mail a Windows binary to anyone that wants to help test this problem. 
The attachment would be a .5MB tar.gz file.  I can also work with anyone
who wants to build it on their Linux or Mac to help test this fix.

Thanks,
Jonathan Brandmeyer

Re: [Visualpython-users] gdisplay objects seldom work

[Bruce S. <bas...@un...>]

You're right. It's great that you've put your finger on a problem. I too 
am seeing programs with gdisplays (graphs) hanging more than any other 
kind of program, and on Windows as well as Linux, as you say. It is true 
that most of the multiwindow programs I run involve a graph, so it might 
be important to play with multiwindow programs that don't involve graphs 
to see whehter we see it there, too. But now that Jonathan has pointed 
to a possible problem area, might it be that contention is most likely 
to happen precisely in a program where we're constantly bouncing back 
and forth between windows, as is the case where an animation of a system 
is displayed in one window, and a corresponding graph is updated in 
another? What do you think, Jonathan?

Bruce Sherwood

Roger Fearick wrote:
> On Mon, 29 Sep 2003, Bruce Sherwood wrote:
> 
> 
>>Jonathan Brandmeyer explained to me that there is a fundamental problem 
>>with which I was unaware. Recent versions of the Unix/Linux kernel no 
>>longer do "recursive" locking/unlocking of resources, something that 
>>Visual has used. Jonathan has been working on eliminating the deadlocks 
>>that can now occur and which may well be responsible for what you're 
>>seeing. He's doing this in his experimental Boost-based version but 
>>might retrofit the current Visual. This is not a problem on Windows.
> 
> 
> Hi,
> This problem looks like it is related to something I have noticed
> on both Linux and Windows (98,2k,XP): gdisplay objects mostly work,
> but occasionally they don't.
> The result is a frozen window, usually displaying the minimum
> axes possible (i.e. the problem seems to lie in the creation of the
> window). 
> In general, related activity in a display window will continue.
> I guess that this is related to threading and some deadlock. I've
> tried to trace through the code and find whereabouts the stall
> is happening, but with little success - the usual problem with an
> intermittent fault! However, some tests did seem to suggest that it got
> lost between the exit from gdisplay's __init__ and the next call to the 
> class instance.
> One thing is that it does seem worse on machines that are a little tight 
> on memory.
> It is the one thing that does upset students a little with the visual 
> package, otherwise they seem to like it.
> 
> Roger.
> 

Re: [Visualpython-users] gdisplay objects seldom work

[Roger F. <fe...@bi...>]

On Mon, 29 Sep 2003, Bruce Sherwood wrote:

> Jonathan Brandmeyer explained to me that there is a fundamental problem 
> with which I was unaware. Recent versions of the Unix/Linux kernel no 
> longer do "recursive" locking/unlocking of resources, something that 
> Visual has used. Jonathan has been working on eliminating the deadlocks 
> that can now occur and which may well be responsible for what you're 
> seeing. He's doing this in his experimental Boost-based version but 
> might retrofit the current Visual. This is not a problem on Windows.

Hi,
This problem looks like it is related to something I have noticed
on both Linux and Windows (98,2k,XP): gdisplay objects mostly work,
but occasionally they don't.
The result is a frozen window, usually displaying the minimum
axes possible (i.e. the problem seems to lie in the creation of the
window). 
In general, related activity in a display window will continue.
I guess that this is related to threading and some deadlock. I've
tried to trace through the code and find whereabouts the stall
is happening, but with little success - the usual problem with an
intermittent fault! However, some tests did seem to suggest that it got
lost between the exit from gdisplay's __init__ and the next call to the 
class instance.
One thing is that it does seem worse on machines that are a little tight 
on memory.
It is the one thing that does upset students a little with the visual 
package, otherwise they seem to like it.

Roger.

-- 
Roger Fearick
Dept. of Physics
University of Cape Town

Re: [Visualpython-users] gdisplay objects seldom work

[Jonathan B. <jbr...@ea...>]

On Mon, 2003-09-29 at 22:24, Gary Pajer wrote:
> ----- Original Message ----- 
> From: "Joe Heafner" <hea...@vn...>

> > I'm still experiencing problems with gdisplay objects. If I create, for
> > example, a graph with gcurve the program usually stalls upon execution,
> > but no errors are indicated. Sometimes, roughly 90% of the time, both
> > the main window and the graph window open up but the graph window is
> > just blank and the other window, usually containing an animation of a
> > physical system (e.g. oscillating spring-mass system) remains static.
> > Sometimes, roughly 10% of the time, the graph shows up correctly, but
> > NOT point by point. The entire graph is displayed after the animation
> > is over, and the oscillating spring-mass never appears to move at all.
> > On a very, very few occasions I get the correct output, which is an
> > oscillating spring-mass system in one window and a graph updated in
> > real time in the other window. However, I never ever get the program to
> > work completely correctly twice in a row. Everything works fine when
> > all the gdisplay related statements are commented out.
> 
> In my case the program never locks up, but it does stutter a bit, especially
> when the animation first starts.  And I have seen the stutter be long enough
> that the simulation is all but finished before the graphics start, and then
> they're there all at once (as you described).   I've experimented with
> placing a time.sleep(n) [where n is typically between 2 and 7]  at various
> places.  I find that if I initialize the gdisplay window,  then
> time.sleep(),  then start my "while" loop,  I don't lose any of the
> animation.  Of course, there is a bit of a delay, and it's still a bit
> jerky, but it works.  YMMV.


The worst part of this is that it is a probabilistic problem.  Sometimes
you will get a complete lock-up, sometimes just a stutter, sometimes
totally smooth operation.  All of this makes it *hard* to debug, but
most of the issues are resolved on the boostification branch, and can be
backported.

The most stressful case for me ended up being a program that produced
two graphs simultaneously while running a simulation, and that one runs
smoothly now.

Since we don't have anything in our demos that really exercises this
bug, can you submit a particularly damning test case to the online
bugtracker at Sourceforge?  I'll probably be adding one or two of my
own, but it always helps to have multiple people attacking probabilistic
bugs like this one.

> > Another issue is that when a program that uses a gdisplay object
> > terminates, the only way to remove the open windows is to choose "End
> > program" from inside IDLE. Otherwise, the output windows remain active
> > and can only be removed by opening up an xterm, issuing "top", getting
> > the PID, exiting "top", and issuing "kill xxx" where xxx is the pid of
> > the correct python22 process.
> 
> Yep.  But simply restarting the program (F5) kills the old windows and opens
> new ones. At the end of the day, though, its "End Program".  Would "ps" be a
> hair more convenient than "top"?
> 
> -gary

Unfortunately process termination still sucks for multiple windows.  I
have gotten it to work for the case where a simulation has ended and the
interpreter is waiting on you to close the windows, but not when you are
still running the simulation (or are running an infinite simulation).  I
have a couple of ideas that I can try in the next couple of days, but
the debugger isn't helping at all in this case.

Thanks for your reports,
-Jonathan Brandmeyer

Re: [Visualpython-users] gdisplay objects seldom work

[Gary P. <pa...@in...>]

----- Original Message ----- 
From: "Joe Heafner" <hea...@vn...>



> Hi.
>
> I'm running Mac OS X (10.2.6) and Visual 2.1.1 compiled from source.

ditto, except I have 2.1.somethingelse

> I'm still experiencing problems with gdisplay objects. If I create, for
> example, a graph with gcurve the program usually stalls upon execution,
> but no errors are indicated. Sometimes, roughly 90% of the time, both
> the main window and the graph window open up but the graph window is
> just blank and the other window, usually containing an animation of a
> physical system (e.g. oscillating spring-mass system) remains static.
> Sometimes, roughly 10% of the time, the graph shows up correctly, but
> NOT point by point. The entire graph is displayed after the animation
> is over, and the oscillating spring-mass never appears to move at all.
> On a very, very few occasions I get the correct output, which is an
> oscillating spring-mass system in one window and a graph updated in
> real time in the other window. However, I never ever get the program to
> work completely correctly twice in a row. Everything works fine when
> all the gdisplay related statements are commented out.

In my case the program never locks up, but it does stutter a bit, especially
when the animation first starts.  And I have seen the stutter be long enough
that the simulation is all but finished before the graphics start, and then
they're there all at once (as you described).   I've experimented with
placing a time.sleep(n) [where n is typically between 2 and 7]  at various
places.  I find that if I initialize the gdisplay window,  then
time.sleep(),  then start my "while" loop,  I don't lose any of the
animation.  Of course, there is a bit of a delay, and it's still a bit
jerky, but it works.  YMMV.

>
> Another issue is that when a program that uses a gdisplay object
> terminates, the only way to remove the open windows is to choose "End
> program" from inside IDLE. Otherwise, the output windows remain active
> and can only be removed by opening up an xterm, issuing "top", getting
> the PID, exiting "top", and issuing "kill xxx" where xxx is the pid of
> the correct python22 process.

Yep.  But simply restarting the program (F5) kills the old windows and opens
new ones. At the end of the day, though, its "End Program".  Would "ps" be a
hair more convenient than "top"?

-gary

>
> Any ideas what's going on?
>
> Cheers,
> Joe Heafner
>
> -----
> New email address: hea...@ct...
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

[Visualpython-users] Re: further improved copyobjects() and a label BUG?

[Rob S. <sa...@ph...>]

I am a newbie to Python, and my experience
is limited to working with VPython and its objects.

Working as an end user (within the confines of the current
Python language and VPython objects), I was merely extending
the documentation's copyobjects() to work with
all of the display objects, which (except for label)
do seem to return a value for __members__ .
Certainly, a C++ copy constructor would be most efficient...
but I'm wearing the hat of an end user.

In addition, I am actually interested in selective copying of
objects and performing transformations on some object properties.
For instance, I'd like to create scenes which are coordinate-plane
projections of a full 3D scene, as in a CAD program.
Something else I'd like to do is to visualize a collision
in the lab-frame and from the center-of-mass frame.  
So, the scenes are not necessarily complete copies of each other.

As for the __methods__ attribute, I don't have any particular
need for this attribute.  I was merely [and possibly naively]
following a Python book I bought 
(the Visual Quicksart Guide (2002), p. 260),
which suggests that an object has at least three attributes
__dict__, __methods__, and __members__.


Now... looking over some of the older Python documentation, I found
http://www.python.org/doc/2.2.3/whatsnew/sect-rellinks.html#SECTION000320000000000000000
"2.2 Descriptors 
In previous versions of Python, there was no consistent way to discover 
what attributes and methods were supported by an object. There were some 
informal conventions, such as defining __members__ and __methods__ 
attributes that were lists of names, but often the author of an extension 
type or a class wouldn't bother to define them. ..."

...So, maybe it's time to find a new Python book.


Rob Salgado





Jonathan Brandmeyer wrote:
>
>
> Maybe, maybe not.  
> 
> First off, only a handful of Python classes supply __members__ and
> __methods__, so I'm not sure that we should be providing them at all.  I
> think they are intruding on the interpreter's namespace, in much the
> same way users should never define symbols with a leading _ in C (even
> if several libraries do).
> 
> Secondly, if supporting an algorithm like that is all that they are
> being used for, I think that there is a better solution.
> 
> Finally, I think that the above is a little hackish.  IMO the right
> answer is to provide a copy constructor from C++.  Then, copyobjects()
> looks like this:
> 
> def copyobjects( to_display, from_display):
> 	# Copies all displayobjects from from_display to to_display.
> 	
> 	displaylist = from_display.objects
> 	 # iterate across the list in reverse order.
> 	order.displaylist.reverse()
> 	for obj in scenelist:
> 		newobj = obj.__class__(obj)
> 		# newobj has identical properties to obj at this point.
> 		# Now move it to the new display.
> 		newobj.display = to_scene
> 
> Of course, that algorithm doesn't work right now, but it can with Boost
> and a little effort on my part.
> 
> Comments?  Suggestions? 
> 
> Other than the purpose of copying objects' properties from one to
> another, I am not aware of a good use for __methods__ and
> __properties__.  What are you using them for?
> 
> -Jonathan Brandmeyer

[Visualpython-users] new installation instructions

[Bruce S. <bas...@un...>]

There are improved installation instructions for Linux/Unix and for Mac 
OSX. There is also a new installer for these platforms: the previous one 
failed to install idle_VPython in some cases.

Bruce Sherwood

Re: [Visualpython-users] gdisplay objects seldom work

[Bruce S. <bas...@un...>]

Jonathan Brandmeyer explained to me that there is a fundamental problem 
with which I was unaware. Recent versions of the Unix/Linux kernel no 
longer do "recursive" locking/unlocking of resources, something that 
Visual has used. Jonathan has been working on eliminating the deadlocks 
that can now occur and which may well be responsible for what you're 
seeing. He's doing this in his experimental Boost-based version but 
might retrofit the current Visual. This is not a problem on Windows.

Bruce Sherwood

Joe Heafner wrote:

> Hi.
>
> I'm running Mac OS X (10.2.6) and Visual 2.1.1 compiled from source. 
> I'm still experiencing problems with gdisplay objects. If I create, 
> for example, a graph with gcurve the program usually stalls upon 
> execution, but no errors are indicated. Sometimes, roughly 90% of the 
> time, both the main window and the graph window open up but the graph 
> window is just blank and the other window, usually containing an 
> animation of a physical system (e.g. oscillating spring-mass system) 
> remains static. Sometimes, roughly 10% of the time, the graph shows up 
> correctly, but NOT point by point. The entire graph is displayed after 
> the animation is over, and the oscillating spring-mass never appears 
> to move at all. On a very, very few occasions I get the correct 
> output, which is an oscillating spring-mass system in one window and a 
> graph updated in real time in the other window. However, I never ever 
> get the program to work completely correctly twice in a row. 
> Everything works fine when all the gdisplay related statements are 
> commented out.
>
> Another issue is that when a program that uses a gdisplay object 
> terminates, the only way to remove the open windows is to choose "End 
> program" from inside IDLE. Otherwise, the output windows remain active 
> and can only be removed by opening up an xterm, issuing "top", getting 
> the PID, exiting "top", and issuing "kill xxx" where xxx is the pid of 
> the correct python22 process.
>
> Any ideas what's going on?
>
> Cheers,
> Joe Heafner
>
> -----
> New email address: hea...@ct...
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

[Visualpython-users] gdisplay objects seldom work

[Joe H. <hea...@vn...>]

Hi.

I'm running Mac OS X (10.2.6) and Visual 2.1.1 compiled from source. 
I'm still experiencing problems with gdisplay objects. If I create, for 
example, a graph with gcurve the program usually stalls upon execution, 
but no errors are indicated. Sometimes, roughly 90% of the time, both 
the main window and the graph window open up but the graph window is 
just blank and the other window, usually containing an animation of a 
physical system (e.g. oscillating spring-mass system) remains static. 
Sometimes, roughly 10% of the time, the graph shows up correctly, but 
NOT point by point. The entire graph is displayed after the animation 
is over, and the oscillating spring-mass never appears to move at all. 
On a very, very few occasions I get the correct output, which is an 
oscillating spring-mass system in one window and a graph updated in 
real time in the other window. However, I never ever get the program to 
work completely correctly twice in a row. Everything works fine when 
all the gdisplay related statements are commented out.

Another issue is that when a program that uses a gdisplay object 
terminates, the only way to remove the open windows is to choose "End 
program" from inside IDLE. Otherwise, the output windows remain active 
and can only be removed by opening up an xterm, issuing "top", getting 
the PID, exiting "top", and issuing "kill xxx" where xxx is the pid of 
the correct python22 process.

Any ideas what's going on?

Cheers,
Joe Heafner

-----
New email address: hea...@ct...