visualpython-users

[Visualpython-users] Release: VPython 2.9.4

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

VPython 2.9.4 is ready for download from
http://sourceforge.net/project/showfiles.php?group_id=6013

The most important fixes in this package are:

scene.lights correctly extracts the tuples passed to it.

Libtool has been fixed (affects users of Linux and other POSIX-like
systems).

On Linux and OSX, programs that use multiple display objects should exit
correctly.

curve, faces, and convex objects have had their data models
significantly overhauled to support more of the implicit behavior that
some programs had expected.

The source package builds and installs cleanly on MS Windows.  Also, the
precompiled package for Windows uses an Inno setup-based package similar
to what is currently used for VPython 2.1.

This release has passed a much larger set of test programs and is likely
to become the 3.0 release.

Enjoy!
-Jonathan Brandmeyer

Re: [Visualpython-users] Release: VPython 2.9.4

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

Jonathan Brandmeyer wrote:
> VPython 2.9.4 is ready for download from
> http://sourceforge.net/project/showfiles.php?group_id=6013

I am trying for the first time to build vpython from sourceforge (I am 
actually trying to make a Fink package for 2.9.4 on MacOSX). Until now I 
had only tried 2.1.9 from vpython.org.

There is now a boost package in Fink, so I had hope this might work 
without too much trouble. Unfortunately, compilation fails with the 
error message below. I don't know enough C++ to see whether this has to 
be fixed in boost or in visualpython, or whether something else needs to 
be done. gcc is the version that comes with OSX 10.3.4 and XCode tools 
1.2,  gcc 3.3 20030304 (Apple Computer, Inc. build 1640). Any advice 
welcome.

g++ -I/sw/include/python2.3 -DHAVE_CONFIG_H -I. -I. 
-I/sw/include/gtk-1.2 -I/usr/X11R6/include -I/sw/include/glib-1.2 
-I/sw/lib/glib/include -D_REENTRANT -I/sw/include/glib-1.2 
-I/sw/lib/glib/include -Wno-long-double -I/sw/include -DPIC -O3 -c -o 
vector.lo vector.cpp
/sw/include/boost/python/object/inheritance.hpp: In static member function `
    static boost::python::objects::dynamic_id_t
    boost::python::objects::polymorphic_id_generator<T>::execute(void*) 
[with T
    = visual::shared_vector]':
/sw/include/boost/python/object/inheritance.hpp:74:   instantiated from 
`void boost::python::objects::register_dynamic_id(T*) [with T = 
visual::shared_vector]'
/sw/include/boost/python/object/class_converters.hpp:85:   instantiated 
from `void boost::python::objects::register_class_from_python(Derived*, 
Bases*) [with Derived = visual::shared_vector, Bases = 
boost::python::bases<visual::vector, boost::mpl::void_, 
boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, 
boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, 
boost::mpl::void_, boost::mpl::void_>]'
/sw/include/boost/python/class.hpp:626:   instantiated from `void 
boost::python::class_<T, X1, X2, X3>::register_() const [with T = 
visual::shared_vector, X1 = boost::python::bases<visual::vector, 
boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, 
boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, 
boost::mpl::void_, boost::mpl::void_, boost::mpl::void_>, X2 = 
boost::noncopyable, X3 = boost::python::detail::not_specified]'
/sw/include/boost/python/class.hpp:660:   instantiated from 
`boost::python::class_<T, X1, X2, X3>::class_(const char*, 
boost::python::no_init_t) [with T = visual::shared_vector, X1 = 
boost::python::bases<visual::vector, boost::mpl::void_, 
boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, 
boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, 
boost::mpl::void_, boost::mpl::void_>, X2 = boost::noncopyable, X3 = 
boost::python::detail::not_specified]'
vector.cpp:678:   instantiated from here
/sw/include/boost/python/object/inheritance.hpp:44: error: cannot 
dynamic_cast
    `p' (of type `class visual::shared_vector*') to type `void*' (source 
type is
    not polymorphic)

-- 
Martin

Re: [Visualpython-users] Release: VPython 2.9.4

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

On Sat, 2004-06-12 at 14:10, Martin Costabel wrote:
> Jonathan Brandmeyer wrote:
> > VPython 2.9.4 is ready for download from
> > http://sourceforge.net/project/showfiles.php?group_id=6013
> 
> I am trying for the first time to build vpython from sourceforge (I am 
> actually trying to make a Fink package for 2.9.4 on MacOSX). Until now I 
> had only tried 2.1.9 from vpython.org.
> 
> There is now a boost package in Fink, so I had hope this might work 
> without too much trouble. Unfortunately, compilation fails with the 
> error message below. I don't know enough C++ to see whether this has to 
> be fixed in boost or in visualpython, or whether something else needs to 
> be done. gcc is the version that comes with OSX 10.3.4 and XCode tools 
> 1.2,  gcc 3.3 20030304 (Apple Computer, Inc. build 1640). Any advice 
> welcome.

This is a bug in the Apple-distributed GCC.  A workaround exists for it,
but there is another code-generation bug in Apple's GCC that makes
Python deadlock when it imports cvisualmodule.so.   You have to build
both Boost.Python and Visual with a GCC built from the FSF's sources on
OSX.  3.3.x (x >= 1) should be fine.

I have attached mkdist_osx.sh, which has been slightly updated from what
is in the .tar.bz2 file on Sourceforge.  Hopefully, that will give you a
good starting point.  If you have any questions at all, feel free to
ask.

If you manage to get a set of working .debs, and you don't want to force
folks to upgrade to the unstable 2.9 version yet, I would be happy to
put them up on Sourceforge alongside the other packages.

HTH,
Jonathan Brandmeyer

Re: [Visualpython-users] Release: VPython 2.9.4

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

Jonathan Brandmeyer wrote:
[]
> OSX.  3.3.x (x >= 1) should be fine.
> 
> I have attached mkdist_osx.sh, which has been slightly updated from what
> is in the .tar.bz2 file on Sourceforge.  Hopefully, that will give you a
> good starting point.  If you have any questions at all, feel free to
> ask.

I am not yet quite there. I first tried a gcc-3.5.0 snapshot whose 
sources I had lying around (it is used for the Fink gfortran package). 
This didn't work. It produced internal compiler errors. Then I tried the 
version of gcc-3.3.3 that you recommended. This almost worked. The 
remaining problem is an undefined reference error to "typeinfo for 
boost::python::instance_holder" and a second one of the same sort.

They are caused by the fact that these symbols are contained in 
libboost_python.dylib, but as non-external. Did you build Boost.Python 
only with static libraries, or do you have an idea how to upgrade these 
symbols

00091340 s typeinfo for boost::python::instance_holder
000913a8 s typeinfo for boost::python::objects::py_function_impl_base

from "non-external (was a private external)" to external? Or eliminate 
the need for them in cvisual.so?

> If you manage to get a set of working .debs, and you don't want to force
> folks to upgrade to the unstable 2.9 version yet, I would be happy to
> put them up on Sourceforge alongside the other packages.

There is a version 2.1.9 .deb in the Fink binary distribution (no boost 
needed for this, but had to be compiled with gcc-3.1, as you may 
remember). http://fink.sourceforge.net/pdb/package.php/visual-py23

-- 
Martin

Re: [Visualpython-users] Release: VPython 2.9.4

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

On Mon, 2004-06-14 at 04:14, Martin Costabel wrote:
> Jonathan Brandmeyer wrote:
> []
> > OSX.  3.3.x (x >= 1) should be fine.
> > 
> > I have attached mkdist_osx.sh, which has been slightly updated from what
> > is in the .tar.bz2 file on Sourceforge.  Hopefully, that will give you a
> > good starting point.  If you have any questions at all, feel free to
> > ask.
> 
> I am not yet quite there. I first tried a gcc-3.5.0 snapshot whose 
> sources I had lying around (it is used for the Fink gfortran package). 
> This didn't work. It produced internal compiler errors. 

Gaaa!  GCC from stage 1?  You are far braver than I.  Besides,
Boost.Python needed a few patches to work with the new (and more strict)
C++ front-end that was released with GCC 3.4, and those patches are not
available in the 1.31.0 release.  That's why I specifically recommended
3.3.  3.3.0 had other bugs in it that lead to ICE in the compiler on all
platforms.

> They are caused by the fact that these symbols are contained in 
> libboost_python.dylib, but as non-external. Did you build Boost.Python 
> only with static libraries, or do you have an idea how to upgrade these 
> symbols
> 
> 00091340 s typeinfo for boost::python::instance_holder
> 000913a8 s typeinfo for boost::python::objects::py_function_impl_base
> 
> from "non-external (was a private external)" to external?

Yes.  Add -DBOOST_PYTHON_DYNAMIC_LIB to BOOSTFLAGS when building
libboost_python.dylib.  My mistake.


> > If you manage to get a set of working .debs, and you don't want to force
> > folks to upgrade to the unstable 2.9 version yet, I would be happy to
> > put them up on Sourceforge alongside the other packages.
> 
> There is a version 2.1.9 .deb in the Fink binary distribution (no boost 
> needed for this, but had to be compiled with gcc-3.1, as you may 
> remember). http://fink.sourceforge.net/pdb/package.php/visual-py23

Yes, I remember.  I was merely offering to help with a setup that
wouldn't force someone who is already using your 2.1.9 visual-py23
package to upgrade to the not-quite-stable 2.9 version.

Re: [Visualpython-users] Release: VPython 2.9.4

[Andy D. <dou...@la...>]

On Fri, 11 Jun 2004, Jonathan Brandmeyer wrote:

> VPython 2.9.4 is ready for download from
> http://sourceforge.net/project/showfiles.php?group_id=6013

I had a few configure nits with this version.  Specifically, I built it
with the following options:  (the use of python 2.2 is because my
Debian testing system only has boost 1.30)

    #!/bin/sh
    PYTHON=/usr/bin/python2.2
    export PYTHON
    PYTHONPATH=/opt/python/lib/python2.2/site-packages
    export PYTHONPATH
    test -d $PYTHONPATH || mkdir -p $PYTHONPATH
    ../visual-2.9.4/configure --prefix=/opt/python
    make
    make install

Somewhere, the setting of prefix is getting lost.  My
/opt/python/bin/vpython script starts like this:

    #!/bin/sh
    # Variables determined by configure.
    PYTHON=/usr/bin/python2.2
    visualdemodir=${prefix}/lib/python2.2/site-packages/visual/demos
    visualidledir=/opt/python/lib/python2.2/site-packages/visual/idle_VPython
    IDLE=idle.py

Note that visualdemodir depends on ${prefix}, but prefix isn't
defined anywhere.

Further, I would think that my needed setting of PYTHONPATH should
be included in the vpython script.  Finally, note that the setting of
PYTHON in the vpython script is pointless since it isn't exported.

My final fixed vpython script starts like this:

    #! /bin/sh
    # Variables determined by configure.
    PYTHON=/usr/bin/python2.2
    PYTHONPATH=/opt/python/lib/python2.2/site-packages
    export PYTHON PYTHONPATH
    prefix=/opt/python
    visualdemodir=${prefix}/lib/python2.2/site-packages/visual/demos
    visualidledir=/opt/python/lib/python2.2/site-packages/visual/idle_VPython
    IDLE=idle.py

but tracing the code paths through configure, I see that
visualdemodir and visualidledir are (at least superficially) treated
quite differently, so I'm not sure of the best way to patch things
up.

Next, I'll try running it on various applications I have.

-- 
    Andy Dougherty		dou...@la...
    Dept. of Physics
    Lafayette College, Easton PA 18042