visualpython-users

[Visualpython-users] wglCreateContext error - again

[Axel K. <ko...@mo...>]

Hi everybody,

I saw that in July someone had exactly the same problem, but I didn't 
find a solution. So here is my problem:

I installed the latest Vpython on my WinXP Pro SP1 with a nVidia 440MX 
graphics card running python 2.3 and get the following error message:

========================================================
Visual-2003-10-05
OpenGL initialization failed.
  wglCreateContext: A dynamic link library (DLL) initialization routine 
failed.
========================================================

Is there a way to find out which DLL caused the problem ??


Many thanks,

                                Axel


P.S. On my much older win2k computer at work Vpython runs fine.

[Visualpython-users] Re: sphere ok, box missing 5 faces

[Jack W. <ja...@ja...>]

Marty, thanks for your reply and advice. I had indeed done as you
suggested, but there is clearly only one face. I've experimented with
different colours, different sizes, specifying length, width, height
instead of size(a,b,c), etc.,etc.. all to no avail.

If anyone else has this, or anyone is interested, I can reveal the exact
libs I'm using.

Regards,
Jack

  >Jack,
  > This is not a problem:  everything is (apparently) working as it 
 >should.
  > If you hold down the middle mouse button you should be able to zoom in
  > and out; if you hold down the right mouse button you should be able
  > to view the cube from different orientations.  You"ll then see that >the
  > various faces are lighted differently.
  > Regards,
  > Marty
  > On Wednesday 18 August 2004 08:09 am, Jack Wasey wrote:
  > > Hello, this is probably a newbie problem.
  > >
  > > Completely clean compile and install on debian testing/unstable,
  >python 2.3
  > >

Re: [Visualpython-users] sphere ok, box missing 5 faces

[Martin G. <mar...@co...>]

Jack,
This is not a problem:  everything is (apparently) working as it should.
If you hold down the middle mouse button you should be able to zoom in 
and out; if you hold down the right mouse button you should be able
to view the cube from different orientations.  You'll then see that the
various faces are lighted differently.
Regards,
Marty
On Wednesday 18 August 2004 08:09 am, Jack Wasey wrote:
> Hello, this is probably a newbie problem.
>
> Completely clean compile and install on debian testing/unstable, python 2.3
>
> import visual as V
> V.box()
>
> gives me just one face (apparently the near face). I've altered the
> lights, and ambient level, but i see nothing. V.sphere() gives me a
> sphere, shaded correctly, and cylinder works, too.
>
> Any suggestions would be very welcome.
>
> This vpython module is awesome. Could I suggest adding support for
> transformations using direction cosine matrices? I.e. define a frame of
> reference in three unit vectors, then the conversion to and from a
> frame of reference can be done by matrix multiplication of a vector with
> the DCM or its inverse. This would be very handy for 3d manipulations...
>
> Thanks,
> Jack
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

-- 
Martin Gelfand

Associate Professor.............Phone: 970 491 5263
Department of Physics.............Fax: 970 491 7947
Colorado State University.......Email: ge...@la...
Fort Collins CO 80523-1875

[Visualpython-users] sphere ok, box missing 5 faces

[Jack W. <sou...@ja...>]

Hello, this is probably a newbie problem.

Completely clean compile and install on debian testing/unstable, python 2.3

import visual as V
V.box()

gives me just one face (apparently the near face). I've altered the
lights, and ambient level, but i see nothing. V.sphere() gives me a
sphere, shaded correctly, and cylinder works, too.

Any suggestions would be very welcome.

This vpython module is awesome. Could I suggest adding support for
transformations using direction cosine matrices? I.e. define a frame of
reference in three unit vectors, then the conversion to and from a
frame of reference can be done by matrix multiplication of a vector with 
the DCM or its inverse. This would be very handy for 3d manipulations...

Thanks,
Jack

Re: [Visualpython-users] Release: VPython 3.0.1

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

On Mon, 2004-08-16 at 13:17, Jonathan Brandmeyer wrote:
> This is a bugfix release and may be downloaded from the file release
> area at www.sourceforge.net/projects/visualpython.  The following bugs
> were fixed:
> 
> vector.mag and vector.mag2 are writable (they scale the vector).
> Color values may be specified by any 3-sequence, not just 
>     3-tuples.
> Setting curve.x, y, or z in the constructor to a single value while also
>     setting the others to a list or array works.
> When the camera is within the extent of the scene, the near 
>     clipping plane will not move forward into the scene.
> The erroneous operator __div__(float, vector), has been 
>     removed.


Also, the mystery class "shared_vector" has been given the slightly more
stealthy name "Vector".

-Jonathan

Re: [Visualpython-users] bug incrementing vector ?

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

On Tue, 2004-08-17 at 15:11, gp...@ri... wrote:
>  Should I expect that "+=" will not increment a vector?

It should work (and does, as far as I can tell) partially because
visual.vector provides the __iadd__() "special member function".  Worst
case, event if a visual.vector only provided __add__(), the interpreter
would synthesize the expression "x += y" as "x = x + y".  Python floats
are manipulated in this way.

Consider this toy example:

>>> class fwrap(object):
...     def __init__(self):
...         self.x = 1.0
...     def get(self):
...         return self.x
...     def __add__(self, other):
...         return self.x + other
...
>>> f = fwrap()
>>> f.get()
1.0
>>> f + 1.0
2.0
>>> f += 1.0
>>> f.get()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'float' object has no attribute 'get'
>>> f
2.0

HTH,
-Jonathan

Re: [Visualpython-users] Mac installer

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

Many thanks!

Martin Costabel wrote:

> Jonathan Brandmeyer wrote:
>
>>>> Perhaps Mr. Costabel would be willing to add it in the fink package's
>>>> post-install script? (see /sw/lib/python2.3/idlelib/config-main.def)
>>>
> []
>
>> Please point fink's IDLE maintainer at this:
>> http://sourceforge.net/tracker/index.php?func=detail&aid=900580&group_id=5470&atid=105470 
>>
>
> []
>
> There are now new versions of python23 and of visual-py23 in Fink that 
> are supposed to take care of this problem. In particular, the IDLE 
> help bug is patched now in the python23 package.
>
> In visual-py23 I am now providing a small config-main.cfg file 
> pointing to the vpython help files, and at the first run of vpython 
> this is copied to the user's ~/.idlerc directory. This avoids fiddling 
> with the main config-main.def that is managed by the python23 package.
>

[Visualpython-users] bug incrementing vector ?

[<gp...@ri...>]

I recently ran a simulation that I haven't looked at for a while.

It didn't run correctly:  the physics was wrong.  I can't be certain, but
I think it was doing the right thing last time I looked at it.

I'm trying to distill the program down to a small example that illustrates
the problem.  The problem is rather mischievous (or I'm missing something
obvious) and attempts to write a small broken program haven't yet met with
success.  Nonetheless ...

I discovered that if a replace the line

FMass.v = FMass.v + (Fext / FMass.m)*dt

with

FMass.v += (Fext / FMass.m)*dt

The behavior of the program changes.  FMass is a sphere.  FMass.v is a
visual vector, FMass.m is a scalar.  Fext is a vector.  Did I miss
something?  Should I expect that "+=" will not increment a vector?

Interactively, I *can* correctly
increment a vector using "+=".

While I'm trying to track down the problem and write a small example, I
thought I'd check with the group for a sanity check.

-gary

[Visualpython-users] Re: Release: VPython 3.0.1

[Jonathan B. <jdb...@un...>]

Some people have had a difficult time building VPython on OSX 10.3.  I
have placed a simple tarball of a binary build for that platform in the
Sourceforge download area.

You will need to have the following packages installed from fink:
python23
numeric-py23
gtk+-shlibs
x11-shlibs
darwin

The tarball is meant to be decompressed to the root directory.  So,
download the file (into say, /Users/jonathan/Desktop/Downloads), cd into
/, and decompress the file:
cd /
tar -xvzf /Users/jonathan/Desktop/Downloads/VPython-OSX10.3-3.0.1.tar.gz

This will plow over any existing installation of visual-py23.

-Jonathan

[Visualpython-users] [Re: Linux : segmentation faults]

[Lew R. <lr...@ur...>]

Hi Jonathan,

Here's the backtrace from orbit.py:

(gdb) bt
#0  0x55f8d326 in loopback_MultiTexCoord1svARB ()
    from /usr/X11R6/lib/modules/dri/r200_dri.so
#1  0x55f8a719 in _ae_loopback_array_elt ()
    from /usr/X11R6/lib/modules/dri/r200_dri.so
#2  0x5606985e in fallback_drawelements ()
    from /usr/X11R6/lib/modules/dri/r200_dri.so
#3  0x5534bf22 in visual::curve::thickline ()
    from /usr/lib/python2.3/site-packages/cvisualmodule.so
#4  0x5534b458 in visual::curve::glRender ()
    from /usr/lib/python2.3/site-packages/cvisualmodule.so
#5  0x553d81e8 in visual::GLDevice::draw ()
    from /usr/lib/python2.3/site-packages/cvisualmodule.so
#6  0x553d6d14 in visual::GLDevice::render_control ()
    from /usr/lib/python2.3/site-packages/cvisualmodule.so
#7  0x553d862f in visual::GLDevice::callback ()
    from /usr/lib/python2.3/site-packages/cvisualmodule.so
#8  0x554da9d5 in g_main_set_poll_func () from /usr/lib/libglib-1.2.so.0
#9  0x554d995b in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#10 0x554d9e47 in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#11 0x554da0f5 in g_main_run () from /usr/lib/libglib-1.2.so.0
#12 0x414d753f in gtk_main () from /usr/lib/libgtk-1.2.so.0
#13 0x5540b74d in visual::mainloop ()
    from /usr/lib/python2.3/site-packages/cvisualmodule.so
#14 0x4133498c in start_thread () from /lib/tls/libpthread.so.0
#15 0x410d416a in clone () from /lib/tls/libc.so.6

...and here is the backtrace from the demise of bounce.py

(gdb) bt
#0  0x55f8d326 in loopback_MultiTexCoord1svARB ()
    from /usr/X11R6/lib/modules/dri/r200_dri.so
#1  0x55f8a719 in _ae_loopback_array_elt ()
    from /usr/X11R6/lib/modules/dri/r200_dri.so
#2  0x5606985e in fallback_drawelements ()
    from /usr/X11R6/lib/modules/dri/r200_dri.so
#3  0x5533b231 in visual::box::glRender ()
    from /usr/lib/python2.3/site-packages/cvisualmodule.so
#4  0x553d81e8 in visual::GLDevice::draw ()
    from /usr/lib/python2.3/site-packages/cvisualmodule.so
#5  0x553d6d14 in visual::GLDevice::render_control ()
    from /usr/lib/python2.3/site-packages/cvisualmodule.so
#6  0x553d862f in visual::GLDevice::callback ()
    from /usr/lib/python2.3/site-packages/cvisualmodule.so
#7  0x554da9d5 in g_main_set_poll_func () from /usr/lib/libglib-1.2.so.0
#8  0x554d995b in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#9  0x554d9e47 in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#10 0x554da0f5 in g_main_run () from /usr/lib/libglib-1.2.so.0
#11 0x414d753f in gtk_main () from /usr/lib/libgtk-1.2.so.0
#12 0x5540b74d in visual::mainloop ()
    from /usr/lib/python2.3/site-packages/cvisualmodule.so
#13 0x4133498c in start_thread () from /lib/tls/libpthread.so.0
#14 0x410d416a in clone () from /lib/tls/libc.so.6

Cheers,

Lew
-- 
___________________________________________________
Lew Riley        http://webpages.ursinus.edu/lriley
Ursinus College Department of Physics and Astronomy
(610) 409-3000 ext. 2293       (610) 409-3660 (FAX)

Re: [Visualpython-users] Mac installer

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

Jonathan Brandmeyer wrote:

>>>Perhaps Mr. Costabel would be willing to add it in the fink package's
>>>post-install script? (see /sw/lib/python2.3/idlelib/config-main.def)
[]
> Please point fink's IDLE maintainer at this:
> http://sourceforge.net/tracker/index.php?func=detail&aid=900580&group_id=5470&atid=105470
[]

There are now new versions of python23 and of visual-py23 in Fink that 
are supposed to take care of this problem. In particular, the IDLE help 
bug is patched now in the python23 package.

In visual-py23 I am now providing a small config-main.cfg file pointing 
to the vpython help files, and at the first run of vpython this is 
copied to the user's ~/.idlerc directory. This avoids fiddling with the 
main config-main.def that is managed by the python23 package.

-- 
Martin

Re: [Visualpython-users] Re: Linux : segmentation faults

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

On Mon, 2004-08-16 at 14:02, Lew Riley wrote:
> Jonathan Brandmeyer wrote:
> 
> > Uh-oh.  Yea, it sounds familiar.  I'm assuming that you have a laptop. 
> > Do you by chance have a Pentium M processor in it (not a Pentium 3-M or
> > Pentium 4-M)?
> 
> Yep. I've got a Dell Latitude D600 with a Pentium M processor.
> 
> > Please run one of the VPython programs that crashes in GDB (the GNU
> > Debugger) by following these instructions, and send me the console
> > output from the entire session.  I'm hoping that setting MESA_DEBUG=1 in
> > the environment will produce something useful, but it might not.
> > 
> 
> OK. Here's the initial output and bactrace from gdb:

Close.  Can you repeat the process, only before you give GDB the "run"
command, give it this one:
`(gdb) handle SIGFPE nostop`
and then complete the process as normal.  The mesa code is supposed to
cause SIGFPE, and then catch it.  Since GDB caught the signal, the catch
wasn't tested (and I think that is where the problem is).  The extra
command above tells GDB not to catch that signal.  It will print out a
message telling you that it was sent, though.

Thanks,
-Jonathan

[Visualpython-users] Re: Linux : segmentation faults

[Lew R. <lr...@ur...>]

Jonathan Brandmeyer wrote:

> Uh-oh.  Yea, it sounds familiar.  I'm assuming that you have a laptop. 
> Do you by chance have a Pentium M processor in it (not a Pentium 3-M or
> Pentium 4-M)?

Yep. I've got a Dell Latitude D600 with a Pentium M processor.

> Please run one of the VPython programs that crashes in GDB (the GNU
> Debugger) by following these instructions, and send me the console
> output from the entire session.  I'm hoping that setting MESA_DEBUG=1 in
> the environment will produce something useful, but it might not.
> 

OK. Here's the initial output and bactrace from gdb:

--
MMX cpu detected.
Testing OS support for SSE... yes.
Testing OS support for SSE unmasked exceptions...
Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 1441717168 (LWP 11823)]
0x56094c94 in _mesa_test_os_sse_exception_support ()
    from /usr/X11R6/lib/modules/dri/r200_dri.so
(gdb) bt
#0  0x56094c94 in _mesa_test_os_sse_exception_support ()
    from /usr/X11R6/lib/modules/dri/r200_dri.so
#1  0x56094a21 in check_os_sse_support ()
    from /usr/X11R6/lib/modules/dri/r200_dri.so
#2  0x56094b40 in _mesa_init_all_x86_transform_asm ()
    from /usr/X11R6/lib/modules/dri/r200_dri.so
#3  0x56013beb in _math_init () from /usr/X11R6/lib/modules/dri/r200_dri.so
#4  0x55f989fa in one_time_init ()
    from /usr/X11R6/lib/modules/dri/r200_dri.so
#5  0x55f9abd4 in _mesa_initialize_context ()
    from /usr/X11R6/lib/modules/dri/r200_dri.so
#6  0x55f9b689 in _mesa_create_context ()
    from /usr/X11R6/lib/modules/dri/r200_dri.so
#7  0x5609a646 in r200CreateContext ()
    from /usr/X11R6/lib/modules/dri/r200_dri.so
#8  0x55f867f0 in driCreateContext ()
    from /usr/X11R6/lib/modules/dri/r200_dri.so
#9  0x0092a5da in _glthread_SetTSD () from /usr/X11R6/lib/libGL.so.1
#10 0x0092a992 in _glthread_SetTSD () from /usr/X11R6/lib/libGL.so.1
#11 0x0092ac2e in glXCreateContext () from /usr/X11R6/lib/libGL.so.1
#12 0x554c292e in gdk_gl_context_share_new () from /usr/lib/libgtkgl.so.5
#13 0x554c33f4 in gtk_gl_area_share_new () from /usr/lib/libgtkgl.so.5
#14 0x554c3325 in gtk_gl_area_new () from /usr/lib/libgtkgl.so.5
---Type <return> to continue, or q <return> to quit---
#15 0x5540daef in visual::xglContext::initWindow ()
    from /usr/lib/python2.3/site-packages/cvisualmodule.so
#16 0x553d705f in visual::GLDevice::render_control ()
    from /usr/lib/python2.3/site-packages/cvisualmodule.so
#17 0x553d862f in visual::GLDevice::callback ()
    from /usr/lib/python2.3/site-packages/cvisualmodule.so
#18 0x554da9d5 in g_main_set_poll_func () from /usr/lib/libglib-1.2.so.0
#19 0x554d995b in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#20 0x554d9e47 in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#21 0x554da0f5 in g_main_run () from /usr/lib/libglib-1.2.so.0
#22 0x414d753f in gtk_main () from /usr/lib/libgtk-1.2.so.0
#23 0x5540b74d in visual::mainloop ()
    from /usr/lib/python2.3/site-packages/cvisualmodule.so
#24 0x4133498c in start_thread () from /lib/tls/libpthread.so.0
#25 0x410d416a in clone () from /lib/tls/libc.so.6
(gdb)
--

Thanks for looking into this.

Lew

-- 
___________________________________________________
Lew Riley        http://webpages.ursinus.edu/lriley
Ursinus College Department of Physics and Astronomy
(610) 409-3000 ext. 2293       (610) 409-3660 (FAX)

[Visualpython-users] Release: VPython 3.0.1

[Jonathan B. <jdb...@un...>]

This is a bugfix release and may be downloaded from the file release
area at www.sourceforge.net/projects/visualpython.  The following bugs
were fixed:

vector.mag and vector.mag2 are writable (they scale the vector).
Color values may be specified by any 3-sequence, not just 
    3-tuples.
Setting curve.x, y, or z in the constructor to a single value while also
    setting the others to a list or array works.
When the camera is within the extent of the scene, the near 
    clipping plane will not move forward into the scene.
The erroneous operator __div__(float, vector), has been 
    removed.

-Jonathan

Re: [Visualpython-users] Mac installer

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

Martin Costabel wrote:

> Bruce Sherwood wrote:
> 
>> You apparently have packaged the VPython version of the IDLE 
>> configuration file Libs/idlelib/config-main.def, since IDLE lists 
>> "Visual" on its help menu. The file contains this entry:
>>
>> [HelpFiles]
>> 1 = Visual;C:\Python23\Lib\site-packages\visual\docs\index.html
> 
> Hmm, my copy of this file does not contain a Visual entry nor such a 
> DOSish path. Are you sure you didn't modify this yourself?
> 

I didn't think I did this, as I wiped out all of /sw and started fresh. 
Not only did I see Visual on the help menu, but IDLE was also configured 
in VPython style to start in the editor rather than the shell, and 
auto-save was specified, neither of which are the defaults that come 
with Python. Nevertheless, if your copy of the configuration file didn't 
have these features, I must have somehow installed a different 
configuration file from somewhere.

Bruce Sherwood

Re: [Visualpython-users] Mac installer

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

Bruce Sherwood wrote:

> Martin, thanks for pointing out a mistake in the vpython.org 
> installation instructions, now corrected. Indeed, we now depend on the 
> IDLE that comes with Python, and it is not appropriate to install the 
> old IDLE for VPython.

OK, I understand this now. So I will see how to integrate this with 
python's config files. I will also talk to Fink's python maintainer when 
he comes back from his vacation :-) OTOH...
> 
> You apparently have packaged the VPython version of the IDLE 
> configuration file Libs/idlelib/config-main.def, since IDLE lists 
> "Visual" on its help menu. The file contains this entry:
> 
> [HelpFiles]
> 1 = Visual;C:\Python23\Lib\site-packages\visual\docs\index.html

Hmm, my copy of this file does not contain a Visual entry nor such a 
DOSish path. Are you sure you didn't modify this yourself?

> You could rebuild your visual-py23 installer to point to the /sw/share 
> location of the Visual documentation in this configuration file.

I'll think about something. Maybe a config-main.def that the user is 
invited to copy into ~/.idlerc.

-- 
Martin

Re: [Visualpython-users] Mac installer

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

On Sun, 2004-08-15 at 14:50, Martin Costabel wrote:

> > Perhaps Mr. Costabel would be willing to add it in the fink package's
> > post-install script? (see /sw/lib/python2.3/idlelib/config-main.def)
> 
> I have started to look at this, and I have a question: Right now, the 
> idle_VPython module is not being installed (contrary to what the new web 
> page seems to indicate). This is the default for python-2.3 as it seems, 
> because there is already an IDLE module. Would it be useful to install 
> this module or is it not advisable with python-2.3? Is it too broken?

Way back in the day, VPython's original author forked idle to make
idle_VPython.  Sometime between then and now, the "idlefork" project was
created based on Mr. Sherer's work.  After enhancing IDLE further,
idlefork became the stock IDLE in Python 2.3.  Since IDLE in Python 2.3
is essentially idle_VPython + tweaks, we don't install idle_VPython on
Python 2.3+.

I'll bet that idle_VPython suffers from the win vs. darwin bug as well,
but I haven't looked.

> I don't know much about IDLE, and there is still a bug in Fink's python 
> package that prevents IDLE to read html documentation (it thinks 
> dar'win' is a kind of windows OS). This is not hard to fix, but I am not 
> the maintainer of the python package. 

Please point fink's IDLE maintainer at this:
http://sourceforge.net/tracker/index.php?func=detail&aid=900580&group_id=5470&atid=105470

It is a bug that I filed against IDLE upstream that lead to changes in
Python CVS.  I haven't tried it yet (actually, I just found out that it
was closed).


> The advantage of installing 
> idle_VPython would be that I could easily configure this so that it 
> finds the documentation and maybe fix the bug if it is there, too, or 
> other bugs.

Well, since idle_VPython isn't really maintained anymore, I wouldn't
recommend packaging it separately, but that is your choice.  If you do
decide to install idle_VPython anyway, see the options
--{en,dis}able-idle-vpython and --with-idle-vpython-dir= in configure.

> I have also been looking at vpython-3.0 on and off, too. It is not too 
> hard to translate the mkdist_osx.sh script into a Fink package 
> description. What keeps me from releasing a Fink package is that it 
> needs a complete gcc and boost, and I am not yet clear in my mind how 
> this should be related to other Fink packages. Is it acceptable that 
> building vpython would use 600 MB of disk space and take 5 hours? I was 
>   thinking of splitting it and have a separate gcc package, but this 
> needs some more thinking.

I understand.  Since 3.0's changes are mostly internal, there's no rush
to upgrade yet.  

Something to think about for the future:  VPython 4.0 will use Gtkmm 2.2
+ Gtkglextmm 1.0 on UNIX-like platforms.  I note that neither of these
are in fink right now, but both of them build out-of-the box on OS X
when the Gtk C development libs are installed from fink.  Although 4.0
will include new user-visible features, even a public alpha release is
some ways off, so no rush there, either.

-Jonathan

Re: [Visualpython-users] Mac installer

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

We all thank Martin Costabel for his most appreciated work in providing 
a VPython installer for the Mac, which greatly simplifies the 
installation procedure.

Martin, thanks for pointing out a mistake in the vpython.org 
installation instructions, now corrected. Indeed, we now depend on the 
IDLE that comes with Python, and it is not appropriate to install the 
old IDLE for VPython.

You apparently have packaged the VPython version of the IDLE 
configuration file Libs/idlelib/config-main.def, since IDLE lists 
"Visual" on its help menu. The file contains this entry:

[HelpFiles]
1 = Visual;C:\Python23\Lib\site-packages\visual\docs\index.html

You could rebuild your visual-py23 installer to point to the /sw/share 
location of the Visual documentation in this configuration file.

That doesn't of course address the Python installation problem that 
results in IDLE not pointing to Python documentation. When I looked 
around in the Python installation, the only documentation files I found 
seemed to be in LaTeX, so it seemed that there wasn't any html for IDLE 
to point to. There does seem to be an inconsistency in the Python 
installer. Since IDLE is a part of the Python installation, it's a bug 
that the IDLE link to Python documentation seems to be broken.

Bruce Sherwood

Martin Costabel wrote:

> Jonathan Brandmeyer wrote:
> []
> 
>>> You install fink, then ask to binary install visual-py23, and it 
>>> installs all the other needed packages, including Python. The only 
>>> slight glitch is that the Visual documentation isn't placed with the 
>>> other Visual stuff in site-packages/visual but rather in 
>>> sw/share/doc/visual-py23,
>>
>>
>>
>> This conforms with policies that are applied Fink-wide.  IMO it is
>> entirely appropriate.
> 
> 
> I could, of course, make a symlink in the python site-packages 
> directory, or vice-versa, but there are more serious problems with IDLE 
> and documentation, see below.
> 
>>> which IDLE doesn't point to. 
>>
>>
>>
>> Perhaps Mr. Costabel would be willing to add it in the fink package's
>> post-install script? (see /sw/lib/python2.3/idlelib/config-main.def)
> 
> 
> I have started to look at this, and I have a question: Right now, the 
> idle_VPython module is not being installed (contrary to what the new web 
> page seems to indicate). This is the default for python-2.3 as it seems, 
> because there is already an IDLE module. Would it be useful to install 
> this module or is it not advisable with python-2.3? Is it too broken?
> 
> I don't know much about IDLE, and there is still a bug in Fink's python 
> package that prevents IDLE to read html documentation (it thinks 
> dar'win' is a kind of windows OS). This is not hard to fix, but I am not 
> the maintainer of the python package. The advantage of installing 
> idle_VPython would be that I could easily configure this so that it 
> finds the documentation and maybe fix the bug if it is there, too, or 
> other bugs.
> 
> I have also been looking at vpython-3.0 on and off, too. It is not too 
> hard to translate the mkdist_osx.sh script into a Fink package 
> description. What keeps me from releasing a Fink package is that it 
> needs a complete gcc and boost, and I am not yet clear in my mind how 
> this should be related to other Fink packages. Is it acceptable that 
> building vpython would use 600 MB of disk space and take 5 hours? I was 
>  thinking of splitting it and have a separate gcc package, but this 
> needs some more thinking.
> 

Re: [Visualpython-users] Mac installer

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

Jonathan Brandmeyer wrote:
[]
>>You install fink, then ask to binary install visual-py23, and it 
>>installs all the other needed packages, including Python. The only 
>>slight glitch is that the Visual documentation isn't placed with the 
>>other Visual stuff in site-packages/visual but rather in 
>>sw/share/doc/visual-py23,
> 
> 
> This conforms with policies that are applied Fink-wide.  IMO it is
> entirely appropriate.

I could, of course, make a symlink in the python site-packages 
directory, or vice-versa, but there are more serious problems with IDLE 
and documentation, see below.

>> which IDLE doesn't point to. 
> 
> 
> Perhaps Mr. Costabel would be willing to add it in the fink package's
> post-install script? (see /sw/lib/python2.3/idlelib/config-main.def)

I have started to look at this, and I have a question: Right now, the 
idle_VPython module is not being installed (contrary to what the new web 
page seems to indicate). This is the default for python-2.3 as it seems, 
because there is already an IDLE module. Would it be useful to install 
this module or is it not advisable with python-2.3? Is it too broken?

I don't know much about IDLE, and there is still a bug in Fink's python 
package that prevents IDLE to read html documentation (it thinks 
dar'win' is a kind of windows OS). This is not hard to fix, but I am not 
the maintainer of the python package. The advantage of installing 
idle_VPython would be that I could easily configure this so that it 
finds the documentation and maybe fix the bug if it is there, too, or 
other bugs.

I have also been looking at vpython-3.0 on and off, too. It is not too 
hard to translate the mkdist_osx.sh script into a Fink package 
description. What keeps me from releasing a Fink package is that it 
needs a complete gcc and boost, and I am not yet clear in my mind how 
this should be related to other Fink packages. Is it acceptable that 
building vpython would use 600 MB of disk space and take 5 hours? I was 
  thinking of splitting it and have a separate gcc package, but this 
needs some more thinking.

-- 
Martin

Re: [Visualpython-users] Linux : segmentation faults

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

On Sun, 2004-08-15 at 11:18, Lew Riley wrote:
> Hi Folks,
> 
> I'm running Fedora Core 2 (gcc version 3.3.3). I get my openGL libraries
> from openmotif-2.2.3-4.1. According to my xorg.conf file, I have an "ATI
> Radeon Mobility M9" video card.
> 
> I just installed Vpython-3.0, and the following demos work fine:

(snipped ... and other stuff crashes half-randomly)
> Does any of this sound familiar? Any ideas?

Uh-oh.  Yea, it sounds familiar.  I'm assuming that you have a laptop. 
Do you by chance have a Pentium M processor in it (not a Pentium 3-M or
Pentium 4-M)?

Please run one of the VPython programs that crashes in GDB (the GNU
Debugger) by following these instructions, and send me the console
output from the entire session.  I'm hoping that setting MESA_DEBUG=1 in
the environment will produce something useful, but it might not.

Start gdb:
`MESA_DEBUG=1 gdb python2.3`
At the "(gdb) " prompt type 'run'.
(gdb) run
At the Python ">>> " prompt, do the following:
>>> import sys
>>> sys.path.append(
'/usr/local/lib/python2.3/site-packages/visual/demos')

If you installed VPython somewhere other than /usr/local, then change
that part of the string above.
Run the demo program that crashes by typing "import programname"
_without_ the .py at the end.  ex:
>>> import orbit

When the program crashes, control will be returned to the (gdb) prompt. 
Run the "bt" command:
(gdb) bt

This produces the backtrace.  I have a bad feeling that the crash will
be in _mesa_test_os_sse_exception_support.


Thanks,
-Jonathan

P.S.  FYI, the graph module is written entirely in Python and rides on
top of Visual's basic functionality.

[Visualpython-users] Linux : segmentation faults

[Lew R. <lr...@ur...>]

Hi Folks,

I'm running Fedora Core 2 (gcc version 3.3.3). I get my openGL libraries
from openmotif-2.2.3-4.1. According to my xorg.conf file, I have an "ATI
Radeon Mobility M9" video card.

I just installed Vpython-3.0, and the following demos work fine:

   convex.py
   crossproduct.py
   dipole.py
   faces_heightfield.py
   glinfo.py
   lathe.py
   texttest.py

However, any attempt to instantiate a box object leads to a segmentation 
fault with no prior error messages. I also see strange segmentation 
faults with the following demos:

   orbit.py

     ...dies via segmentation fault when either

     (a) appending a point to one of the curves. The curve to which it is
         appending (giant or dwarf) and the number of points at which it
         dies both vary.

     or

     (b) at the 'for a in [giant, dwarf]' before it executes any code in
         the block

   graphtest.py

     ...dies vie segmentation fault. Since most of the work is done in
     the C++ code, I don't know what's happening here.

   lorenz.py

     ...dies via segmentation fault apparently in the
     'for t in arrange(0,10,dt)'. Here again, the number of iterations it
     successfully completes varies. This is the most disturbing case,
     because it seems to point to problems with python itself(?).

   stars.py

     ...dies via segmentation fault. I haven't tried to track down where,
     but print statements before the various for loops inside the while
     show that it can die in different places.

Does any of this sound familiar? Any ideas?

Thanks,

Lew
-- 
___________________________________________________
Lew Riley        http://webpages.ursinus.edu/lriley
Ursinus College Department of Physics and Astronomy
(610) 409-3000 ext. 2293       (610) 409-3660 (FAX)

Re: [Visualpython-users] Mac installer

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

On Fri, 2004-08-13 at 22:17, Bruce Sherwood wrote:
> I've updated (at long last) the Mac OSX installer page at vpython.org to 
> reflect the existence of a standard Fink installer for VPython 
> (pre-boost version). It's gotten MUCH easier.
> 
> You install fink, then ask to binary install visual-py23, and it 
> installs all the other needed packages, including Python. The only 
> slight glitch is that the Visual documentation isn't placed with the 
> other Visual stuff in site-packages/visual but rather in 
> sw/share/doc/visual-py23,

This conforms with policies that are applied Fink-wide.  IMO it is
entirely appropriate.

>  which IDLE doesn't point to. 

Perhaps Mr. Costabel would be willing to add it in the fink package's
post-install script? (see /sw/lib/python2.3/idlelib/config-main.def)

-Jonathan

[Visualpython-users] Mac installer

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

I've updated (at long last) the Mac OSX installer page at vpython.org to 
reflect the existence of a standard Fink installer for VPython 
(pre-boost version). It's gotten MUCH easier.

You install fink, then ask to binary install visual-py23, and it 
installs all the other needed packages, including Python. The only 
slight glitch is that the Visual documentation isn't placed with the 
other Visual stuff in site-packages/visual but rather in 
sw/share/doc/visual-py23, which IDLE doesn't point to. And it appeared 
to me that this doesn't install html documentation for Python itself, 
which seems to contain only documentation in LaTeX.

Bruce Sherwood

Re: [Visualpython-users] Near clipping plane (Was: PyODE integration)

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

I'm glad Jonathan understood, as I obviously didn't. Also, Isaac Hanson 
sent me the following test routine which shows the problem:

import visual

visual.box(height=10, width=10, length=10, color=visual.color.cyan)
s = visual.sphere(pos=(0,0,-1180), color=visual.color.red)

visual.scene.autocenter = 0
visual.scene.autoscale = 0

while 1:
     visual.rate(30)
     s.pos.z += -1

Zoom in (manually) so the cube fills much of the window, and wait. 
You'll see the creep.

Bruce Sherwood

Jonathan Brandmeyer wrote:

> On Wed, 2004-08-11 at 16:51, Bruce Sherwood wrote:
> 
>>I don't understand the "near-clipping plane" problem. Is it simply that 
>>you want to set scene.autoscale = 0?
>>
>>Here is the bug report you submitted, for Linux:
>>
>>"My program is a test of a rigid body simulation package, pyode. The
>>scene consists of a few boxes near position (0,0,0) and a sphere.
>>The sphere starts from a position behind the viewer, rolls towards
>>the boxes, crashes into them, bounces back towards the viewer,
>>then continues to roll far behind the viewer. After the sphere rolls
>>for a little while, the near clipping plane begins to move forward into
>>the scene. I have "autocenter" turned off, and the forward
>>progression of the near clipping plane seems to be related to the
>>distance of the sphere from the scene."
>>
>>I wrote a similar-sounding program, which seems to behave properly:
>>
>>box(color=color.cyan)
>>s = sphere(pos=(0,0,100), color=color.red)
>>dz = -1
>>##scene.autocenter = 0
>>##scene.autoscale = 0
>>while 1:
>>     rate(20)
>>     s.pos += vector(0,0,dz)
>>     if s.pos.z < 1:
>>         dz = -dz
>>
>>Turning off autocenter doesn't do anything that I can see. With the 
>>default autoscale on, the camera is moved to make sure that you always 
>>see something. I'm not sure what you want to have happen, but it sounds 
>>to me like you should turn off autoscaling and manage the view yourself.
>>
>>Bruce Sherwood
> 
> 
> No, it is a legitimate complaint.  For example, run stars with a lot of
> stars and velocity such that at least a few stars fly away and there is
> plenty to look at in the middle for a while.  Zoom the camera into the
> scene, and position the camera such that a trail is "in your face".  You
> should be able to see the cross-section of the trail as it is clipped by
> the near clipping plane.  As some of the stars fly away from the
> cluster, you will notice the plane slowly move further into the scene. 
> Eventually, it will cut deeply into the scene.
> 
> I just committed a fix for this problem into CVS a few minutes ago. 
> Basically, the new behavior is that system decides if the camera might
> be located within the scene's bounding box, and if so, sets the near
> clipping plane distance to a small fixed value.
> 
> Previously, the distance was set to a fixed multiple of the scaled
> extent of the scene.  A scene whose objects span a volume much larger
> than the display's viewing volume would have an inappropriately large
> near clipping plane distance.
> 
> -Jonathan
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] Near clipping plane (Was: PyODE integration)

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

On Wed, 2004-08-11 at 16:51, Bruce Sherwood wrote:
> I don't understand the "near-clipping plane" problem. Is it simply that 
> you want to set scene.autoscale = 0?
> 
> Here is the bug report you submitted, for Linux:
> 
> "My program is a test of a rigid body simulation package, pyode. The
> scene consists of a few boxes near position (0,0,0) and a sphere.
> The sphere starts from a position behind the viewer, rolls towards
> the boxes, crashes into them, bounces back towards the viewer,
> then continues to roll far behind the viewer. After the sphere rolls
> for a little while, the near clipping plane begins to move forward into
> the scene. I have "autocenter" turned off, and the forward
> progression of the near clipping plane seems to be related to the
> distance of the sphere from the scene."
> 
> I wrote a similar-sounding program, which seems to behave properly:
> 
> box(color=color.cyan)
> s = sphere(pos=(0,0,100), color=color.red)
> dz = -1
> ##scene.autocenter = 0
> ##scene.autoscale = 0
> while 1:
>      rate(20)
>      s.pos += vector(0,0,dz)
>      if s.pos.z < 1:
>          dz = -dz
> 
> Turning off autocenter doesn't do anything that I can see. With the 
> default autoscale on, the camera is moved to make sure that you always 
> see something. I'm not sure what you want to have happen, but it sounds 
> to me like you should turn off autoscaling and manage the view yourself.
> 
> Bruce Sherwood

No, it is a legitimate complaint.  For example, run stars with a lot of
stars and velocity such that at least a few stars fly away and there is
plenty to look at in the middle for a while.  Zoom the camera into the
scene, and position the camera such that a trail is "in your face".  You
should be able to see the cross-section of the trail as it is clipped by
the near clipping plane.  As some of the stars fly away from the
cluster, you will notice the plane slowly move further into the scene. 
Eventually, it will cut deeply into the scene.

I just committed a fix for this problem into CVS a few minutes ago. 
Basically, the new behavior is that system decides if the camera might
be located within the scene's bounding box, and if so, sets the near
clipping plane distance to a small fixed value.

Previously, the distance was set to a fixed multiple of the scaled
extent of the scene.  A scene whose objects span a volume much larger
than the display's viewing volume would have an inappropriately large
near clipping plane distance.

-Jonathan