visualpython-users

Re: [Visualpython-users] Achievement / Project Showcase?

[Dethe E. <de...@li...>]

This is the place, but it relies on people mentioning what projects  
they're using VPython for.  If there was interest in having a place  
to list project (rather than just announce them), we could set up a  
page on the python wiki for existing VPython projects.

In fact, it would be so easy to set this up that I just did it.  It's  
just a stub, but could be a useful resource for listing projects, and  
answering FAQs.

http://wiki.python.org/moin/VPython

--Dethe

Young children play in a way that is strikingly similar to the way  
scientists work --Busytown News

[Visualpython-users] Achievement / Project Showcase?

[Jeremy S. <rez...@ma...>]

	Is there any place online where the current projects that people are  
working on with visual python are discussed, or are at least  
mentioned? The mailing list seems to be used more for correspondence  
than general announcements, and I'm very interested in what's going  
on in the vpython community... if there is a vpython community, that is.

	-Jeremy S.

[Visualpython-users] Demonic Computers

[Joel K. <jj...@ya...>]

John Brawley wrote:

>I am close to thinking computers and 
>their programs are actually demons
>viciously sitting on our desktops 
>waiting for the moment we are most vulnerable....

You are only *close* to thinking this?!

I run the computer lab at a public primary school. In
this case, "primary" means kindergarten through second
grade. If you are only *close* to thinking that
computers are demons, you have clearly never seen
twenty-five Windows PCs being used by twenty-five
children (say, five and six years old) all at the same
time in the same room. "Demonic" is a mild word for
some of the class sessions I've had to deal
with--computer glitches and all.

Still, I have had some limited chances to use VPython
in the lab; and the kids seem to like what they've
seen so far. I'm hoping to use it for more instruction
in solid geometry and computer graphics as time goes
on.

Joel


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[Visualpython-users] cx-Freeze

[Flavio C. <fcc...@gm...>]

Hi,
 has anyone succesfully frozen a VPython script using cx_freeze?
--
Fl=E1vio Code=E7o Coelho
registered Linux user # 386432
---------------------------
"Laws are like sausages. It's better not to see them being made."
Otto von Bismark

[Visualpython-users] VPython included in Quantian

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

Quantian is a "live CD" version of Linux for x86 type machines. 

The latest release includes VPython.  (I haven't tried it yet.)

http://www.quantian.org

Quantian is a scientific computing environment.  It's based on the 
Knoppix version of Debian.  It is enormous, and contains just about 
anything that you can imagine.  It's very nice.

Actually it is a "live DVD" version of Linux.   It's become too big for 
a CD.   "live" means that you put the disk in your drive at boot-up, and 
the operating system boots from there.  Once running, you have a 
complete Linux system running.  Thus, any pc that can boot from CD or 
DVD can run Quantian without any changes to the system hardware.  System 
configuration and local files can be stored on a USB flash drive between 
sessions. 

It is also possible to run it from an iso image on your otherwise 
unchanged Windows (NTFS or FAT) drive.  In this case, a bootloader on 
CD, DVD, floppy, or USB stick is needed to get the thing going.  Loading 
and running is much faster this way, as the system does not coninually 
have to access DVD drive.  Furthermore, this method works if you don't 
have a DVD drive.

If desired, it can be loaded onto your local hard drive (replacing the 
current o/s).

[Visualpython-users] Re: End of all-windows shutdown (?)

[John B. <jb...@te...>]

> From: "John Brawley" <jb...@te...>
> To: <vis...@li...>
> Date: Thu, 8 Dec 2005 23:24:59 -0600
> Subject: [Visualpython-users] Re: Horror story ends; all-windows shutdown
remains
>
> Thank you, Bruce, Jacob; I will try to find out what's causing the
> total-shutdown with graphics window-closing.
> (If nobody uses scene.exit=0, then what's it _for_?)

I am close to thinking computers and their programs are actually demons
viciously sitting on our desktops waiting for the moment we are most
vulnerable....

Without too much detail, a USB-host-to-host bridge app called
"genelink" --which had been working fine for weeks--this morning totally
screwed up _both_ my computers to such an extent that I was in DOS and Safe
Mode all day on first one, then the other, fixing the same problem the same
way: blow off every possible program that might have been causing a sequence
of five to eight Blue Screens of Death (which appeared each time a tasktray
applet tried to load), including VPython --_by_mistake_--; then use
DriverCleaner to eradicate all traces of nVidia drivers, and reinstall the
drivers.

Upshot: For Who Knows What Demonic Reason, VPython now is no longer exiting
all the windows when closing the graphics/stereo window.

Thanks to all (for no reason other than friendliness and helpfulness, 'cause
this one also got fixed without me having the least idea what fixed it).
The suggestion I reinstall VPython was probably it, but who knows?
(*sigh*; and I wanted to use computers.  Rue the Day.)

Merry and Happy, Christmas and New Year.
John
Peace
JB
jb...@te...
Web: http://tetrahedraverse.com

[Visualpython-users] Re: scene.exit=0 (Jacob S.)

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

http://physics.syr.edu/~salgado/vpython/
points to Windows .reg file that seems to fix the problem of IDLE shutting
down when the animation window is destroyed.

You may have to customize it for your setup.
(Yes, I'm still using an older release of VPython.)


Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Python.File]
@="Python File"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Python.File\shell]

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Python.File\shell\Edit in IDLE-VPython]

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Python.File\shell\Edit in
IDLE-VPython\command]
@="C:\\Python23\\pythonw.exe C:\\Python23\\Lib\\idlelib\\idle.pyw \"%1\" %*"

rob

[Visualpython-users] Re: Horror story ends; all-windows shutdown remains

[John B. <jb...@te...>]

Thank you, Bruce, Jacob; I will try to find out what's causing the
total-shutdown with graphics window-closing.
(If nobody uses scene.exit=0, then what's it _for_?)

On the other thing, the scrambling video, I can't provide any data because
it's not doing it any more (and I don't know why).
Like an unscientific fool, I meddled with too many things at once, chief
among which was a) running two video-card benchmarkers (AquaMark and
3DMark03) to diagnose the card itself, then (b) tweaking many things in the
card's drivers in hopes of upping frame rate (my sixty dollar card ain't as
fast as I thought it was), and (c) reinstalling nVidia's 8x.xx (latest)
drivers on both computers ('shotgun' approach).

When I again ran my VP program some hours later, it ran perfectly; no video
glitches at all with 10,000 points on screen, and flawless zoomings-in and
out.

So: mystery not solved, no data to help out if anyone else ever sees that
('cause I don't know which meddle fixed it), and all that once-valid
VP-guessing info is now worthless 'cause I don't think I could get the
problem back even if I wanted to.
(And I _don't_ want to.)

Upshot: Bandwidth-sorry;  apologies for bothering;  my bad;  
problem 'a' gone;  problem 'b' now under diagnosis.

Peace
JB
jb...@te...
Web: http://tetrahedraverse.com

Re: [Visualpython-users] Re: scene.exit=0

[Jacob S. <ke...@ja...>]

> What you're seeing has not been reported by anyone else. As far as I know, 
> you're the only user experiencing the disastrous behavior you report, that 
> starting from IDLE you can run only once before everything closes down. 
> This has nothing to do with the scene.exit bug, which everyone experiences 
> (if they use that not very commonly used feature).
>
> The uniqueness of your experience suggests something odd about your 
> particular computer environment, but I have no idea what the problem is. 
> One thing you might try, in desperation, is to uninstall VPython, then 
> uninstall Python, then reinstall.
>
> Bruce Sherwood


You're not alone John, I have experienced this problem before.  I tend to 
edit with idle, then Alt+Tab to the open folder and hit enter on the file 
I'm editing.  This way I can edit, save, alt+tab, enter - it runs, alt+tab, 
edit, etc.

Jacob Schmidt

PS  Running Windows XP, -and-  I don't know if this helps but - the file 
association on edit with idle is as follows    "C:\python24\pythonw.exe" 
"c:\python24\lib\idlelib\idle.pyw" -n -e "%1" %*

The file association might affect how idle interacts, say, whether it shuts 
down or not...
If idle thinks that -n or -e is a call to shut down after running  (it's a 
shot in the dark)

HTH


>
> John Brawley wrote:
>
>>>From: Bruce Sherwood <Bru...@nc...>
>>>Subject: Re: [Visualpython-users] Re: horror story
>>>
>>>On the exit issue: This is two different issues, not one. With the
>>>Boost-based version of Visual there crept in a new bug that scene.exit =
>>>0 doesn't prevent the exiting of all graphics wndows when one is closed.
>>>That has not yet been fixed.
>>>
>>
>>Thanks.  That is sad.
>>(You do mean, don't you, that scene.exit=0 doesn't prevent exiting of all
>>_VPython_ windows, not just graphics windows?
>>My experience: closing the graphics window (my old three-window stereo
>>method's, _or_ the single window given by scene.stereo='crosseyed'), shuts
>>that window, Idle (shell) window, and the program edit window.  IOW,
>>_everything_ closes and I have to start all the way over as if I had just
>>turned on the computer.)
>>
>>Is it important to fix this?
>>(Are there a lot of complaints about it, or not?)
>>
>>
>>>But there's a different issue that has always been present as far as I
>>>know, and never understood. If you start IDLE, then open a file for
>>>editing, you can repeatedly run, close the graphics window, and keep
>>>editing.
>>>
>>
>>_Yes_.  That's what I was familiar with, which makes it easy/fast to work 
>>on
>>a program, test, do more work, test, etc.
>>That's the way (imho) it _should_ be.
>>
>>
>>>If on the other hand (on Windows) you right-click on a .py file and ask
>>>to edit using IDLE, you only get to run once before IDLE itself quits,
>>>which is annoying. But starting from IDLE gets around this problem.
>>>
>>
>>I've never seen that, because I don't start Idle that way, but always from 
>>a
>>desktop icon/shortcut.
>>(IOW yes, I always start from Idle.)
>>
>>Peace
>>JB
>>jb...@te...
>>Web: http://tetrahedraverse.com
>>
>>
>>
>>
>>-------------------------------------------------------
>>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
> 

Re: [Visualpython-users] Re: scene.exit=0

[Bruce S. <Bru...@nc...>]

What you're seeing has not been reported by anyone else. As far as I 
know, you're the only user experiencing the disastrous behavior you 
report, that starting from IDLE you can run only once before everything 
closes down. This has nothing to do with the scene.exit bug, which 
everyone experiences (if they use that not very commonly used feature).

The uniqueness of your experience suggests something odd about your 
particular computer environment, but I have no idea what the problem is. 
One thing you might try, in desperation, is to uninstall VPython, then 
uninstall Python, then reinstall.

Bruce Sherwood

John Brawley wrote:

>>From: Bruce Sherwood <Bru...@nc...>
>>Subject: Re: [Visualpython-users] Re: horror story
>>
>>On the exit issue: This is two different issues, not one. With the
>>Boost-based version of Visual there crept in a new bug that scene.exit =
>>0 doesn't prevent the exiting of all graphics wndows when one is closed.
>>That has not yet been fixed.
>>    
>>
>
>Thanks.  That is sad.
>(You do mean, don't you, that scene.exit=0 doesn't prevent exiting of all
>_VPython_ windows, not just graphics windows?
>My experience: closing the graphics window (my old three-window stereo
>method's, _or_ the single window given by scene.stereo='crosseyed'), shuts
>that window, Idle (shell) window, and the program edit window.  IOW,
>_everything_ closes and I have to start all the way over as if I had just
>turned on the computer.)
>
>Is it important to fix this?
>(Are there a lot of complaints about it, or not?)
>
>  
>
>>But there's a different issue that has always been present as far as I
>>know, and never understood. If you start IDLE, then open a file for
>>editing, you can repeatedly run, close the graphics window, and keep
>>editing.
>>    
>>
>
>_Yes_.  That's what I was familiar with, which makes it easy/fast to work on
>a program, test, do more work, test, etc.
>That's the way (imho) it _should_ be.
>
>  
>
>>If on the other hand (on Windows) you right-click on a .py file and ask
>>to edit using IDLE, you only get to run once before IDLE itself quits,
>>which is annoying. But starting from IDLE gets around this problem.
>>    
>>
>
>I've never seen that, because I don't start Idle that way, but always from a
>desktop icon/shortcut.
>(IOW yes, I always start from Idle.)
>
>Peace
>JB
>jb...@te...
>Web: http://tetrahedraverse.com
>
>
>
>
>-------------------------------------------------------
>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
>  
>

[Visualpython-users] Re: scene.exit=0

[John B. <jb...@te...>]

> From: Bruce Sherwood <Bru...@nc...>
> Subject: Re: [Visualpython-users] Re: horror story
>
> On the exit issue: This is two different issues, not one. With the
> Boost-based version of Visual there crept in a new bug that scene.exit =
> 0 doesn't prevent the exiting of all graphics wndows when one is closed.
> That has not yet been fixed.

Thanks.  That is sad.
(You do mean, don't you, that scene.exit=0 doesn't prevent exiting of all
_VPython_ windows, not just graphics windows?
My experience: closing the graphics window (my old three-window stereo
method's, _or_ the single window given by scene.stereo='crosseyed'), shuts
that window, Idle (shell) window, and the program edit window.  IOW,
_everything_ closes and I have to start all the way over as if I had just
turned on the computer.)

Is it important to fix this?
(Are there a lot of complaints about it, or not?)

> But there's a different issue that has always been present as far as I
> know, and never understood. If you start IDLE, then open a file for
> editing, you can repeatedly run, close the graphics window, and keep
> editing.

_Yes_.  That's what I was familiar with, which makes it easy/fast to work on
a program, test, do more work, test, etc.
That's the way (imho) it _should_ be.

> If on the other hand (on Windows) you right-click on a .py file and ask
> to edit using IDLE, you only get to run once before IDLE itself quits,
> which is annoying. But starting from IDLE gets around this problem.

I've never seen that, because I don't start Idle that way, but always from a
desktop icon/shortcut.
(IOW yes, I always start from Idle.)

Peace
JB
jb...@te...
Web: http://tetrahedraverse.com

Re: [Visualpython-users] opening multiple files from command line

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

On Wed, 2005-12-07 at 10:41 -0500, Joe Heafner wrote:
> Is it possible to write a script that invokes IDLE and opens, say,  
> three or four .py files at once?

I think you will have to patch Idle to get this functionality.

-Jonathan

[Visualpython-users] Re: horror story, v.3

[John B. <jb...@te...>]

> Subject: Re: [Visualpython-users] Horror story
> From: Jonathan Brandmeyer <jbr...@ea...>
> On Mon, 2005-12-05 at 20:49 -0600, John Brawley wrote:
>
> > "Traceback (most recent call last):
[dels]
> I think that it means that you were somehow creating an visual object
> with an explicit color value set to "None" rather than a 3-tuple.  You
[and]
> Try to reduce the program to the minimum that reproduces the problem.
> If that process doesn't help you find it, post the minimal example here.
> Otherwise, it will be nearly impossible to see what is wrong.

I've poked around and found some other effects.

(I am pursuing this in-list partly because I may be doing something very
much more visually complex than might be the case with others' use of
VPython, thus might be "testing to near destruction" VPython's ability to
handle complex scenes.  That's a guess, though.)

This seems to be an 'interactive' problem between VPython, OpenGL, and my
(new) video card, which ought to be able to handle anything my program or
VPython can throw at it: it's an nVidia GeForce FX 5200 with _256MB_ of
memory on-card.

(In re: your (Jonathan's) diagnose of "None.None" object color as seemingly
reported in the traceback, since the error doesn't crash the program, it is
possible that this is a secondary reaction to occasional detection of a
zero- (or minus-) length cylinder, of which there can be many in this
program (but, the program's written to exclude this situation).
PovRay would call this a "degenerate cylinder," whose ends are the
same point in 3D space.  If a non-cylinder is nonetheless asked to be
colored, it might result in a similar error from the VPython coloring
subsystem. (?)

Furthermore, I find that allowing this visual nastiness to go on (and on,
and on...) eventually results in the system settling down and rendering
correctly (the problem mostly disappears by itself--but reoccurs if I
re-initialize the program with the same inputs), _even with_ 10,000 points
or so (see relation to complexity, below).
IOW, not only does the problem not crash the program, but also it "heals
itself" after a (usually very long) while, and at least without zooming
(likewise see complexity, below).

At any rate:

1) It is related to complexity of a scene, but does not occur using an
entirely different program with similar complexity.  IOW, my program causes
it when using more than 'x' number of visual objects, OR when using less
than that but zooming in.  My MYST games, though (hence no Pythons at all),
even with fast motion and very complex scenes, do not cause it.

2) Complexity: I ran a different VPython program I wrote, using 10,000
points, and it causes the problem you saw (in the URL I provided).  However,
using 3333 points causes a _different_ problem: the stereo scene "flashes"
back and forth between L eye and R eye, turning white objects (tiny balls,
hence points) blue for a time, and back again.  Using only 333 points does
not cause either problem, but does cause yet a _different_ problem: zooming
in on the scene, which has 333 "balls" in it (they look like points from a
distance, and are rendered as points by the system when they're tiny like
that) causes each ball on-screen to show a round (ball-diameter-limited)
version of the same horrible-orthogonal gridlike random-color crap shown in
the URL I gave you.  IOW, instead of the whole half-window (stereo) filling
with this crap, only the balls themselves (against a black background) fill
with it.
Moreover, zooming _out_ stops the problem, and zooming back in re-causes it.
Moremoreover, the difference between causing and not causing, in zooming
terms, is a matter of a millimeter or less of mouse movement.  IYOW, there
is a specific "distance" into the scene, where balls grow large enough to
require more rendering, and the problem appears, back away from which the
balls render just fine.  Increasing the number of balls used (say, from 333
to 500) makes the problem occur at a lesser distance-in to the scene.

3) SO, what I have is a rendering-capability problem, which sounds like a
video card problem, BUT there's the fact that it only happens when using my
program, VPython, and a highly complex rendering task.

Now, given this further info, do you have any other ideas as to what's what?
(And, thanks much for help so far.)

Peace
JB
jb...@te...
Web: http://tetrahedraverse.com

[Visualpython-users] opening multiple files from command line

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

Is it possible to write a script that invokes IDLE and opens, say,  
three or four .py files at once?

Joe Heafner
heafnerj(at)ctc(dot)net
SticksAndShadows.com

Re: [Visualpython-users] Re: horror story

[Bruce S. <Bru...@nc...>]

On the exit issue: This is two different issues, not one. With the 
Boost-based version of Visual there crept in a new bug that scene.exit = 
0 doesn't prevent the exiting of all graphics wndows when one is closed. 
That has not yet been fixed.

But there's a different issue that has always been present as far as I 
know, and never understood. If you start IDLE, then open a file for 
editing, you can repeatedly run, close the graphics window, and keep 
editing.

If on the other hand (on Windows) you right-click on a .py file and ask 
to edit using IDLE, you only get to run once before IDLE itself quits, 
which is annoying. But starting from IDLE gets around this problem.

Bruce Sherwood

John Brawley wrote:

>>   1. Re: Horror story (Jonathan Brandmeyer)
>>From: Jonathan Brandmeyer <jbr...@ea...>
>>    
>>
>[deletions]
>
>  
>
>>I think that it means that you were somehow creating an visual object
>>with an explicit color value set to "None" rather than a 3-tuple.
>>    
>>
>
>That's really odd, since I don't.  (*grin*)  What I'm doing is using an HSV
>color 3-tuple, since I only have to work with one element (the H, the first
>in the 3-tuple) in order to get a full range of colors according to a
>certain property of the object.  I then just translate the HSV to RGB for
>VPython's use.  Even if the first element of the tuple were weird, the other
>two elements are explicitly 1 and 1 (hue, 1,1).
>
>  
>
>>You can add an extra couple of lines of code to
>>process_init_args_from_keyword_dictionary (in primitives.py) that tests
>>keywords for the 'color' key and prints out the value if it exists.
>>eg,
>>if 'color' in keywords:
>>print type(keywords['color']), keywords['color']
>>    
>>
>
>Thank you, Jonathan, I'll try that, but I can't print anything to the shell
>window; I'll have to try to write any messages to a file and even that
>is unlikely to work.  When the program runs and expecially when this
>happens, the program hogs focus and the CPU is in 100% usage.  I can't even
>Windows-multitask at all and that's on a 2.2 GHz (Intel 3.4 GHz equivalent)
>Athlon64 w/512 MB memory.
>Thus I can't _see_ the shell without minimizing the stereo window, which
>sometimes works (after a _long_ pause) and sometimes doesn't.  There's
>no chance of catching "live" error messages, or more than one of them
>if static.
>
>This is all because the scene.exit=0 function (close the stereo window;
>leave the shell and edit windows open) _doesn't work_ in this VPython (2.4).
>I wanted especially to know if that has been fixed.
>Has it?
>(I know there's a new version up, but has this particular irritant been
>fixed in it?  I can't go on forever re-initializing Idle every time I close
>the stereo window.  It makes it really hard to work on a program when I have
>to start from scratch every time I test some minor thing and have to close
>the stereo window....)
>
>Peace
>JB
>jb...@te...
>Web: http://tetrahedraverse.com
>
>
>
>-------------------------------------------------------
>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
>  
>

[Visualpython-users] Re: horror story

[John B. <jb...@te...>]

>    1. Re: Horror story (Jonathan Brandmeyer)
> From: Jonathan Brandmeyer <jbr...@ea...>
[deletions]

> I think that it means that you were somehow creating an visual object
> with an explicit color value set to "None" rather than a 3-tuple.

That's really odd, since I don't.  (*grin*)  What I'm doing is using an HSV
color 3-tuple, since I only have to work with one element (the H, the first
in the 3-tuple) in order to get a full range of colors according to a
certain property of the object.  I then just translate the HSV to RGB for
VPython's use.  Even if the first element of the tuple were weird, the other
two elements are explicitly 1 and 1 (hue, 1,1).

> You can add an extra couple of lines of code to
> process_init_args_from_keyword_dictionary (in primitives.py) that tests
> keywords for the 'color' key and prints out the value if it exists.
> eg,
> if 'color' in keywords:
> print type(keywords['color']), keywords['color']

Thank you, Jonathan, I'll try that, but I can't print anything to the shell
window; I'll have to try to write any messages to a file and even that
is unlikely to work.  When the program runs and expecially when this
happens, the program hogs focus and the CPU is in 100% usage.  I can't even
Windows-multitask at all and that's on a 2.2 GHz (Intel 3.4 GHz equivalent)
Athlon64 w/512 MB memory.
Thus I can't _see_ the shell without minimizing the stereo window, which
sometimes works (after a _long_ pause) and sometimes doesn't.  There's
no chance of catching "live" error messages, or more than one of them
if static.

This is all because the scene.exit=0 function (close the stereo window;
leave the shell and edit windows open) _doesn't work_ in this VPython (2.4).
I wanted especially to know if that has been fixed.
Has it?
(I know there's a new version up, but has this particular irritant been
fixed in it?  I can't go on forever re-initializing Idle every time I close
the stereo window.  It makes it really hard to work on a program when I have
to start from scratch every time I test some minor thing and have to close
the stereo window....)

Peace
JB
jb...@te...
Web: http://tetrahedraverse.com

Re: [Visualpython-users] Horror story

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

On Mon, 2005-12-05 at 20:49 -0600, John Brawley wrote:

> "Traceback (most recent call last):
>   File "C:\Python24\Lib\site-packages\Tverse\TVVgapViewer2.py", line 114, in
> ?
>     cyl=gap(xyzs,xyzs2,gapLen)
>   File "C:\Python24\Lib\site-packages\Tverse\TVVgapViewer2.py", line 24, in
> gap
>     return
> cylinder(pos=x1s,axis=x2s-x1s,color=gapCol,length=gapLen,radius=pRad/20.0)
>   File "C:\PYTHON24\lib\site-packages\visual\primitives.py", line 131, in
> __init__
>     process_init_args_from_keyword_dictionary(self, keywords)
>   File "C:\PYTHON24\lib\site-packages\visual\primitives.py", line 49, in
> process_init_args_from_keyword_dictionary
>     displayobject.color =  keywords['color']
> ArgumentError: Python argument types in
>     None.None(cylinder, NoneType)
> did not match C++ signature:
>     None(visual::Primitive {lvalue}, visual::rgb)"
> 
> My guess: due to my strange (but fast and cute) means of getting a color,
> occasionally my program spits a number at VPython's OpenGL system that is
> out of range (or, it is zero), which causes the OpenGL system to spit crap
> at the video card, which then shows me this horrible screen trash.  It does
> not, however, crash the program; this oddness will continue indefinitely.
> It _seems_ to me from the traceback, that my rgb value was divided by a
> cylinder length of zero (or less), which produced a color number that,
> essentially, didn't exist.

I think that it means that you were somehow creating an visual object
with an explicit color value set to "None" rather than a 3-tuple.  You
can add an extra couple of lines of code to
process_init_args_from_keyword_dictionary (in primitives.py) that tests
keywords for the 'color' key and prints out the value if it exists.
eg,
if 'color' in keywords:
	print type(keywords['color']), keywords['color']

> I would like to know if you (anyone?) concur, or, if you know what all that
> traceback stuff actually means (especially the last couple of lines of it,
> which I don't understand), could you tell me _exactly_ what it is that
> happened?

Try to reduce the program to the minimum that reproduces the problem.
If that process doesn't help you find it, post the minimal example here.
Otherwise, it will be nearly impossible to see what is wrong.

-Jonathan

[Visualpython-users] Horror story

[John B. <jb...@te...>]

This is related to the bug that causes VPython to shut all windows when the
viewing ('scene.stereo=') window is closed regardless of what 'scene.exit'
is set to.  It caused me headaches/heartaches (thought my $60 video card was
defective) for weeks.
----(Has that bug been fixed yet?)----

This link explains the problem and what I feared.  It was intended to be
referred-to in an email to nVidia's support department:

http://tetrahedraverse.com/temp/nVidProb.htm
( tetrahedraverse(dot)com(fslash)temp(fslash)nVidProb(dot)htm )
(two 800x600 images are in the page; it may load slowly, if you care to
look.)

1) My program (my amateur coding) uses a cheap/fast way to get a color for a
cylinder, directly 'proportional' to its length.
I _think_ if the cylinder-getting method produces an out-of-range number,
crap happens.  This didn't happen, however, until I tried using the program
on tens of thousands of 'spheres' (balls, points, whatever), so I could find
no rhyme nor reason to it.

2) Because this was so scary, and because it delayed screenwrites
dramatically, I would either close the window immediately, or (feeling
afraid) leave it run for a while.  While it runs, nothing gets updated in
the VPython shell, so if there were an error message there, I would not see
it, and if I closed the stereo window, likewise I would not see it.

3) This evening, after writing that html page for nVidia techs to see (and
now you, if you're curious), I for the first time minimized the stereo
window, thinking maybe the screenwrites would complete and I could then see
what my program's supposed to let me see.
No such luck, BUT what that did do was take focus off of the stereo window
after many long seconds, and allow me for the first time to see what was in
the VPython Idle shell window.
Reproducibly now, this:

"Traceback (most recent call last):
  File "C:\Python24\Lib\site-packages\Tverse\TVVgapViewer2.py", line 114, in
?
    cyl=gap(xyzs,xyzs2,gapLen)
  File "C:\Python24\Lib\site-packages\Tverse\TVVgapViewer2.py", line 24, in
gap
    return
cylinder(pos=x1s,axis=x2s-x1s,color=gapCol,length=gapLen,radius=pRad/20.0)
  File "C:\PYTHON24\lib\site-packages\visual\primitives.py", line 131, in
__init__
    process_init_args_from_keyword_dictionary(self, keywords)
  File "C:\PYTHON24\lib\site-packages\visual\primitives.py", line 49, in
process_init_args_from_keyword_dictionary
    displayobject.color =  keywords['color']
ArgumentError: Python argument types in
    None.None(cylinder, NoneType)
did not match C++ signature:
    None(visual::Primitive {lvalue}, visual::rgb)"

My guess: due to my strange (but fast and cute) means of getting a color,
occasionally my program spits a number at VPython's OpenGL system that is
out of range (or, it is zero), which causes the OpenGL system to spit crap
at the video card, which then shows me this horrible screen trash.  It does
not, however, crash the program; this oddness will continue indefinitely.
It _seems_ to me from the traceback, that my rgb value was divided by a
cylinder length of zero (or less), which produced a color number that,
essentially, didn't exist.

I would like to know if you (anyone?) concur, or, if you know what all that
traceback stuff actually means (especially the last couple of lines of it,
which I don't understand), could you tell me _exactly_ what it is that
happened?

Thanks!

I love VPython, and I really need this to work.  Now that Bruce et.al. have
been so extraordinarily kind as to make that wonderful
'scene.stereo=crosseyed' addition to the stereo methods (VP 2.4), I can get
some real work done.  But this nastiness has got to go away....

Peace
JB
jb...@te...
Web: http://tetrahedraverse.com

Re: [Visualpython-users] povexport debugging

[Bruce S. <Bru...@nc...>]

Fixed; new version at vpython.org. Thanks much for the report.

Bruce Sherwood

Fabrice Tiercelin wrote:

>Hello,
>
>I think I have found a little bug in povexport code. When an object with a
>bad class is found (faces, etc...), the script print a warning on the
>output, but the name of the class (obj_name) seems not to be correctly
>updated :
>
>424:    for obj in display.objects:
>425:        key = obj.__class__
>426:        if legal.has_key(key):
>427:            obj_name = legal[key]
>428:            if obj_name != 'frame':
>429:                function_name = 'export_' + obj_name
>430:                function = globals().get(function_name)
>431:                object_code = function(obj)
>432:                file.write( object_code )
>433:        else:
>434:            print 'WARNING: export function for ' + obj_name + ' not
>implemented'
>
>
>causing bugs like that :
>
>
>Traceback (most recent call last):
>  File "C:\...\test.py", line 37, in -toplevel-
>    povexport.export(display=scene, include_list = inclist)
>  File "C:\...\povexport.py", line 396, in export
>    print 'WARNING: export function for ' + obj_name + ' not implemented'
>UnboundLocalError: local variable 'obj_name' referenced before assignment
>
>
>
>
>-------------------------------------------------------
>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
>  
>

[Visualpython-users] povexport debugging

[Fabrice T. <fab...@in...>]

Hello,

I think I have found a little bug in povexport code. When an object with a
bad class is found (faces, etc...), the script print a warning on the
output, but the name of the class (obj_name) seems not to be correctly
updated :

424:    for obj in display.objects:
425:        key = obj.__class__
426:        if legal.has_key(key):
427:            obj_name = legal[key]
428:            if obj_name != 'frame':
429:                function_name = 'export_' + obj_name
430:                function = globals().get(function_name)
431:                object_code = function(obj)
432:                file.write( object_code )
433:        else:
434:            print 'WARNING: export function for ' + obj_name + ' not
implemented'


causing bugs like that :


Traceback (most recent call last):
  File "C:\...\test.py", line 37, in -toplevel-
    povexport.export(display=scene, include_list = inclist)
  File "C:\...\povexport.py", line 396, in export
    print 'WARNING: export function for ' + obj_name + ' not implemented'
UnboundLocalError: local variable 'obj_name' referenced before assignment

Re: [Visualpython-users] trouble with installation under OS X 10.4

[Martin C. <cos...@wa...>]

Lenore Horner wrote:
> I used fink to install visual-py23 
> (visual-py23_2.1.9-6_darwin-powerpc.deb). After updating my path (see below)

Setting the path (or what is the same, PATH) variable has nothing to do 
with Python's module search path. It is the search path for executables 
that you start from the shell command prompt. For Python's module search 
path, you have the PYTHONPATH environment variable.

> I opened terminal and typed "idle" at the prompt.  Idle started, but it 
> cannot locate the visual package - see below.

Why don't you just use the "vpython2.3" command as suggested by the 
visual-py23 usage notes ("fink describe visual-py23")? This command sets 
the right environment variables and runs the right versions of idle and 
of python. It is a shell script, /sw/bin/python2.3, which you can read 
as a text file if you want to see what it is doing.

-- 
Martin

[Visualpython-users] trouble with installation under OS X 10.4

[Lenore H. <lh...@si...>]

I used fink to install visual-py23 (visual-py23_2.1.9-6_darwin- 
powerpc.deb). After updating my path (see below)

I opened terminal and typed "idle" at the prompt.  Idle started, but  
it cannot locate the visual package - see below.

I can find some files named visual in my file system, but, knowing  
nothing of python and only scattered linux, don't know what's missing  
or how to tell Idle where it should be looking for the module if  
nothing's missing.  Below is the list of files.

Any suggestions?
Lenore

(path setting in .tcshrc)
> set path=(/sw/lib/python2.3/idlelib $path)
> set path=(/sw/lib/python2.3/site-packages $path)

Attempting to use the visual module.
> Python 2.3.5 (#1, Mar 20 2005, 20:38:20)
> [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin
> Type "copyright", "credits" or "license()" for more information.
>
>     ****************************************************************
>     Personal firewall software may warn about the connection IDLE
>     makes to its subprocess using this computer's internal loopback
>     interface.  This connection is not visible on any external
>     interface and no data is sent to or received from the Internet.
>     ****************************************************************
>
> IDLE 1.0.5
> >>> from visual import *
>
> Traceback (most recent call last):
>   File "<pyshell#0>", line 1, in -toplevel-
>     from visual import *
> ImportError: No module named visual
> >>>

file list
> /sw/lib/python2.3/site-packages/cvisualmodule.so
> /sw/lib/python2.3/site-packages/visual
> /sw/lib/python2.3/site-packages/visual/controls.py
> /sw/lib/python2.3/site-packages/visual/controls.pyc
> /sw/lib/python2.3/site-packages/visual/controls.pyo
> /sw/lib/python2.3/site-packages/visual/crayola.py
> /sw/lib/python2.3/site-packages/visual/crayola.pyc
> /sw/lib/python2.3/site-packages/visual/crayola.pyo
> /sw/lib/python2.3/site-packages/visual/demos
> /sw/lib/python2.3/site-packages/visual/demos/bounce.py
> /sw/lib/python2.3/site-packages/visual/demos/bounce2.py
> /sw/lib/python2.3/site-packages/visual/demos/colorsliders.py
> /sw/lib/python2.3/site-packages/visual/demos/controlstest.py
> /sw/lib/python2.3/site-packages/visual/demos/convex.py
> /sw/lib/python2.3/site-packages/visual/demos/crossproduct.py
> /sw/lib/python2.3/site-packages/visual/demos/crystal.py
> /sw/lib/python2.3/site-packages/visual/demos/dipole.py
> /sw/lib/python2.3/site-packages/visual/demos/doublependulum.py
> /sw/lib/python2.3/site-packages/visual/demos/drape.py
> /sw/lib/python2.3/site-packages/visual/demos/faces_cone.py
> /sw/lib/python2.3/site-packages/visual/demos/faces_heightfield.py
> /sw/lib/python2.3/site-packages/visual/demos/gas.py
> /sw/lib/python2.3/site-packages/visual/demos/glinfo.py
> /sw/lib/python2.3/site-packages/visual/demos/graphtest.py
> /sw/lib/python2.3/site-packages/visual/demos/gyro.py
> /sw/lib/python2.3/site-packages/visual/demos/gyro2.py
> /sw/lib/python2.3/site-packages/visual/demos/hanoi.py
> /sw/lib/python2.3/site-packages/visual/demos/helix.py
> /sw/lib/python2.3/site-packages/visual/demos/lathe.py
> /sw/lib/python2.3/site-packages/visual/demos/lorenz.py
> /sw/lib/python2.3/site-packages/visual/demos/orbit.py
> /sw/lib/python2.3/site-packages/visual/demos/planar.py
> /sw/lib/python2.3/site-packages/visual/demos/randombox.py
> /sw/lib/python2.3/site-packages/visual/demos/stars.py
> /sw/lib/python2.3/site-packages/visual/demos/stonehenge.py
> /sw/lib/python2.3/site-packages/visual/demos/texttest.py
> /sw/lib/python2.3/site-packages/visual/demos/tictac.py
> /sw/lib/python2.3/site-packages/visual/demos/tictacdat.py
> /sw/lib/python2.3/site-packages/visual/demos/Tk-Visual.py
> /sw/lib/python2.3/site-packages/visual/demos/toroid.py
> /sw/lib/python2.3/site-packages/visual/demos/toroid_drag.py
> /sw/lib/python2.3/site-packages/visual/demos/wave.py
> /sw/lib/python2.3/site-packages/visual/factorial.py
> /sw/lib/python2.3/site-packages/visual/factorial.pyc
> /sw/lib/python2.3/site-packages/visual/factorial.pyo
> /sw/lib/python2.3/site-packages/visual/graph.py
> /sw/lib/python2.3/site-packages/visual/graph.pyc
> /sw/lib/python2.3/site-packages/visual/graph.pyo
> /sw/lib/python2.3/site-packages/visual/macevent.py
> /sw/lib/python2.3/site-packages/visual/macevent.pyc
> /sw/lib/python2.3/site-packages/visual/macevent.pyo
> /sw/lib/python2.3/site-packages/visual/text.py
> /sw/lib/python2.3/site-packages/visual/text.pyc
> /sw/lib/python2.3/site-packages/visual/text.pyo
> /sw/lib/python2.3/site-packages/visual/__init__.py
> /sw/lib/python2.3/site-packages/visual/__init__.pyc
> /sw/lib/python2.3/site-packages/visual/__init__.pyo

[Visualpython-users] Problem with visual.graph

[Markus W. <mw...@gm...>]

Hi!

I installed VPython on Ubuntu Linux (Breezy) via synaptic 
(python-visual 3.2.1-1build1). Everything works fine, but when
I want to use visual.graph (e.g. graphtest.py in the examples
directory) I get the following error message:

Traceback (most recent call last):
  File "graphtest.py", line 8, in ?
    oscillation = gdisplay(xtitle='t', ytitle='Response')
  File "/usr/lib/python2.4/site-packages/visual/graph.py", line 192, in __init__
    currentdisplay.select()
RuntimeError: boost::bad_weak_ptr

Does anyone know what's wrong and how to solve this?

Regards, Markus

[Visualpython-users] Re: Visualpython-users digest, Vol 1 #737 - 3 msgs

[Fabrice C. <fo...@ex...>]

> Please be more specific about the operations you carry out, and say 
> whether the sequence I outlined above works or fails for you. I suppose 
> it's just barely possible that there's something odd about AMD. I know 
> someone for whom mostly nothing works on AMD.
> 
> Bruce Sherwood

If I may add my experience to the debate:
I am also subject to similar problems (I am using Win32 and my processor is 
not an AMD).
->I control Python with Tkinter as in the example script and everything else
 (ie : Tkinter window included) closes when the Vpython window is closed.
->I am using SPE as an IDE and if ever I want to test the script currently 
under edition by hitting the 'run' command, it will run properly but if the 
Vpython window is closed, the whole IDE is also forced to exit.
->I have a script that lauches a Vpython window and then drops to an Ipython
 interactive shell in order to let the user choose different functions. If 
the Vpython window is closed, the Ipython session also terminates. On the 
other hand, if I use the Ipython shell to raise a SystemExit, the 
interactive session itself terminates but not the original script that 
launched everything (and the Vpython window keeps running as long as it is 
not closed).

As mentioned by the original poster the option to disable the close on exit 
feature does not seem to change anything to the problem.

Hoping the input is of any help,

Fabrice Capiez 

Re: [Visualpython-users] Re: Visualpython-users digest, Vol 1 #736 - 2 msgs

[Bruce S. <Bru...@nc...>]

I'm not sure what is meant by "open the Shell, grab a script." I have 
not seen the behavior you describe except in the following somewhat 
special case, on Windows: Right click on a .py file; choose "Edit with 
IDLE"; run program; close graphics window; everything closes.

But if I start up IDLE (configures either to open a blank edit window or 
the shell window), then open a .py file using File >> Open, then run the 
program, closing the graphics window leaves the other windows open.

Please be more specific about the operations you carry out, and say 
whether the sequence I outlined above works or fails for you. I suppose 
it's just barely possible that there's something odd about AMD. I know 
someone for whom mostly nothing works on AMD.

Bruce Sherwood

John Brawley wrote:

>
>Please advise if this is the same as what I'm experiencing?
>I open the Shell, grab a script, run it.  It gives me a stereo (crosseyed)
>window and starts showing me my program output (it packs balls; I get to
>watch).
>When I want to change the conditions, I _used_to_ close the window, make any
>changes I want in the script, then run it again.
>Now, though, when I close the stereo window, it closes everything and I have
>to reload Shell and script in order to run it again.
>Is this the _same_ bug as above noted?
>
>Thanks!
>(Crosseyed is working *magnificently*, for which implementation I at least
>will be forever grateful.
>Once I got P2.4 and VP2.4 working on this new machine (AMD Athlon64 3400+;
>512MB), everything has been working just as magnificently except for this
>above mentioned irritant.)
>
>Peace
>JB
>Xj...@te...
>( REMOVE the 'X' before using ! )
>NOTE: due to virus explosion, currently deleting ALL messages over 140kb
>from the server without downloading.
>http://tetrahedraverse.com
>
>
>  
>