Re: [Visualpython-users] Still no progress with the Beta version of visual python

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

It appears that other standard examples (like stonehenge) don't
work either.  Is it possible that boost 1.34 is not compatible
with visual-beta15?  The backtrace from stonehenge is:

#0  PyDict_GetItem (op=0xd122f0, key=0x0) at Objects/dictobject.c:569
#1  0x0000002a9c8b777a in boost::python::objects::function::call ()
   from 
/home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
#2  0x0000002a9c8bb305 in 
boost::detail::function::void_function_ref_invoker0<boost::python::objects::(anonymous 
namespace)::bind_return, void>::invoke ()
   from 
/home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
#3  0x0000002a9c8c2167 in boost::function0<void, 
std::allocator<boost::function_base> >::operator() ()
   from 
/home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
#4  0x0000002a9c8c1c58 in 
boost::python::detail::exception_handler::operator()
    ()
   from 
/home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
#5  0x0000002a99b90dbf in 
boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, 
boost::python::detail::translate_exception<std::runtime_error, void 
(*)(std::runtime_error)>, boost::_bi::list3<boost::arg<1> (*)(), 
boost::arg<2> (*)(), boost::_bi::value<void (*)(std::runtime_error)> > 
 >, bool, boost::python::detail::exception_handler const&, 
boost::function0<void, std::allocator<boost::function_base> > 
const&>::invoke (function_obj_ptr=Variable "function_obj_ptr" is not 
available.
)
    at 
/home/dharrison/wares/rhe4_a64/include/boost-1_34/boost/python/detail/translate_exception.hpp:45
#6  0x0000002a9c8c1fe7 in boost::function2<bool, 
boost::python::detail::exception_handler const&, boost::function0<void, 
std::allocator<boost::function_base> >const&, 
std::allocator<boost::function_base> >::operator() ()
   from 
/home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
#7  0x0000002a9c8c1c48 in 
boost::python::detail::exception_handler::operator()
    ()
   from 
/home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
#8  0x0000002a99b90ccf in 
boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, 
boost::python::detail::translate_exception<std::invalid_argument, void 
(*)(std::invalid_argument)>, boost::_bi::list3<boost::arg<1> (*)(), 
boost::arg<2> (*)(), boost::_bi::value<void (*)(std::invalid_argument)> 
 > >, bool,boost::python::detail::exception_handler const&, 
boost::function0<void, std::allocator<boost::function_base> > 
const&>::invoke (function_obj_ptr=Variable "function_obj_ptr" is not 
available.
)
    at 
/home/dharrison/wares/rhe4_a64/include/boost-1_34/boost/python/detail/translate_exception.hpp:45
#9  0x0000002a9c8c1fe7 in boost::function2<bool, 
boost::python::detail::exception_handler const&, boost::function0<void, 
std::allocator<boost::function_base> >const&, 
std::allocator<boost::function_base> >::operator() ()
   from 
/home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
#10 0x0000002a9c8c1c48 in 
boost::python::detail::exception_handler::operator()
    ()
   from 
/home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
#11 0x0000002a99b90baf in 
boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, 
boost::python::detail::translate_exception<std::out_of_range,void 
(*)(std::out_of_range)>, boost::_bi::list3<boost::arg<1> (*)(), 
boost::arg<2> (*)(), boost::_bi::value<void (*)(std::out_of_range)> > >, 
bool, boost::python::detail::exception_handler const&, 
boost::function0<void, std::allocator<boost::function_base> > 
const&>::invoke (function_obj_ptr=Variable "function_obj_ptr" is not 
available.
)
    at 
/home/dharrison/wares/rhe4_a64/include/boost-1_34/boost/python/detail/translate_exception.hpp:45
#12 0x0000002a9c8c1fe7 in boost::function2<bool, 
boost::python::detail::exception_handler const&, boost::function0<void, 
std::allocator<boost::function_base> >const&, 
std::allocator<boost::function_base> >::operator() ()
   from 
/home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
#13 0x0000002a9c8c1c7b in boost::python::handle_exception_impl ()
   from 
/home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
#14 0x0000002a9c8bb219 in 
boost::python::handle_exception<boost::python::objects::(anonymous 
namespace)::bind_return> ()
   from 
/home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
#15 0x0000002a9c8b9a1e in 
boost::python::objects::function::add_to_namespace ()
   from 
/home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
#16 0x00000000004194c3 in PyObject_Call (func=Variable "func" is not 
available.
) at Objects/abstract.c:1860

David Harrison wrote:
>
> Well, to get around the latest issue, I went ahead and downloaded
> a modern libboost (1.34) and compiled it as well.  There are some issues
> in getting visual to use this libboost.  It appears it now counts on
> libboost being available from the compiler.  But the boost provided
> for my compiler, g++ (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3),
> doesn't appear to link.  I managed to force it to use a local libboost
> by modifying the Makefiles.  After that, everything finally compiled,
> linked, and installed.  However, a simple test program dies with
> the following backtrace.  Any ideas?
>
>       David
>
> #0  0x0000002a9a3ae1b5 in cvisual::icososphere::subdivide 
> (this=0x40a01090,
>    span=Variable "span" is not available.
> ) at ./core/util/icososphere.cpp:137
> #1  0x0000002a9a3aea0f in icososphere (this=0x40a01090, depth=Variable 
> "depth" is not available.
> )
>    at 
> /home/dharrison/wares/rhe4_a64/include/boost-1_34/boost/shared_array.hpp:93 
>
> #2  0x0000002a9a2e685c in cvisual::sphere::create_cache ()
>    at 
> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_vector.h:557 
>
> #3  0x0000002a9a2e437e in cvisual::renderable::refresh_cache 
> (this=0x8b0890,
>    geometry=Variable "geometry" is not available.
> ) at ./core/renderable.cpp:122
> #4  0x0000002a9a2cca96 in cvisual::display_kernel::draw (this=0x8ca6a0,
>    scene_geometry=@0x40a01690, whicheye=Variable "whicheye" is not 
> available.
> )
>    at 
> /home/dharrison/wares/rhe4_a64/include/boost-1_34/boost/iterator/iterator_facade.hpp:644 
>
> #5  0x0000002a9a2cfc04 in cvisual::display_kernel::render_scene 
> (this=0x8ca6a0)
>    at ./core/display_kernel.cpp:791
> #6  0x0000002a9a3c1840 in cvisual::render_surface::on_expose_event 
> (this=Variable "this" is not available.
> )
>    at ./gtk2/render_surface.cpp:237
> #7  0x0000002a9b071e46 in Gtk::Widget_Class::expose_event_callback (
>    self=0x8f4030, p0=0x40a01e50) at widget.cc:4494
> #8  0x0000002a9bae3fa8 in _gtk_marshal_BOOLEAN__BOXED (closure=0x9316b0,
>    return_value=0x40a01990, n_param_values=Variable "n_param_values" 
> is not available.
> ) at gtkmarshalers.c:84
> #9  0x0000002a9c5dbd39 in IA__g_closure_invoke (closure=0x9316b0,
>    return_value=0x40a01990, n_param_values=2, param_values=0x40a01b20,
>    invocation_hint=0x40a019c0) at gclosure.c:490
> #10 0x0000002a9c5effcc in signal_emit_unlocked_R (node=0x931720, 
> detail=0,
>    instance=0x8f4030, emission_return=0x40a01aa0,
>    instance_and_params=0x40a01b20) at gsignal.c:2478
> #11 0x0000002a9c5f08fa in IA__g_signal_emit_valist (instance=0x8f4030,
>    signal_id=Variable "signal_id" is not available.
> ) at gsignal.c:2209
> #12 0x0000002a9c5f0f13 in IA__g_signal_emit (instance=Variable 
> "instance" is not available.
> ) at gsignal.c:2243
> #13 0x0000002a9bbebcc0 in gtk_widget_event_internal (widget=0x8f4030,
>    event=0x40a01e50) at gtkwidget.c:3915
> #14 0x0000002a9bae2821 in IA__gtk_main_do_event (event=0x40a01e50)
>    at gtkmain.c:1537
> #15 0x0000002a9be70712 in gdk_window_process_updates_internal 
> (window=0x8fbe10)
>    at gdkwindow.c:2338
> #16 0x0000002a9be707db in IA__gdk_window_process_all_updates ()
>    at gdkwindow.c:2401
> #17 0x0000002a9be70848 in gdk_window_update_idle (data=Variable "data" 
> is not available.
> ) at gdkwindow.c:2259
> #18 0x0000002a9cb6f147 in IA__g_main_context_dispatch (context=0x8ff410)
>    at gmain.c:2045
> #19 0x0000002a9cb70b78 in g_main_context_iterate (context=0x8ff410,
>    block=2037111104, dispatch=1, self=Variable "self" is not available.
> ) at gmain.c:2677
> #20 0x0000002a9cb70eda in IA__g_main_loop_run (loop=0x92b5f0) at 
> gmain.c:2881
> #21 0x0000002a9bae1b81 in IA__gtk_main () at gtkmain.c:1154
> #22 0x0000002a9a3c769d in cvisual::gui_main::run (this=0x8cf010)
>    at ./gtk2/display.cpp:547
> #23 0x0000002a9a3cad71 in cvisual::gui_main::thread_proc ()
>    at ./gtk2/display.cpp:567
> #24 0x0000002a9cd1c167 in boost::function0<void, 
> std::allocator<boost::function_base> >::operator() ()
>   from 
> /home/dharrison/wares/rhe4_a64/lib/libboost_python-gcc34-1_34.so.1.34.0
> #25 0x0000002a9ce37427 in boost::thread_group::join_all ()
>   from 
> /home/dharrison/wares/rhe4_a64/lib/libboost_thread-gcc34-mt-1_34.so.1.34.0 
>
>
>
>
> David Harrison wrote:
>> I got past the problem in num_util.cpp: it looks like a simple typo.
>> Line 234 in that file should read:
>>
>>   npy_intp* dims_ptr = PyArray_DIMS(arr.ptr());
>>
>> I then found that visual inherits the linking problem from
>> gtkglextmm-1.2.0.  It tries to link against libGL twice: once
>> in the right place /usr/lib64/libGL.so and once in the wrong
>> place: /usr/lib/libGL.so.  A hack to its generated libtool
>> script gets around that problem.
>>
>> But then it finally threw me a very significant curve:
>>
>> /usr/bin/ld: 
>> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib64/libboost_python.a(numeric.o): 
>> relocation R_X86_64_32 against `a local symbol' can not be used when 
>> making a shared object; recompile with -fPIC
>> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../lib64/libboost_python.a: 
>> could not read symbols: Bad value
>>
>> It appears it is trying to link against a non-shared version of 
>> libboost_python.
>> I will try to hack around this one too (there appears to be a .so for
>> libboost_python) but I think I am going to have to edit the final 
>> link line.
>>
>>        David
>>
>> Bruce Sherwood wrote:
>>  
>>> Alas, I have no experience with nor access to a 64-bit environment, 
>>> and it does sound like that's the issue. I'm surprised that there 
>>> aren't standard 64-bit packages for GTK, which after all is a pretty 
>>> standard library. Is there anyone reading this list with 64-bit 
>>> experience?
>>>
>>> Bruce Sherwood
>>>
>>> David Harrison wrote:
>>>    
>>>> At Bruce's suggestion, I downloaded visual-4.beta15
>>>> and tried installing it on my AMD 64-bit machine
>>>> running RedHat Enterprise 4.  It uses numpy and
>>>> that is good.  But it now has a very major dependency
>>>> on GTK and its libraries.  I spent about 4 hours today
>>>> compiling an ever increasing number of dependent
>>>> libraries to try to get things going.  Just for grins,
>>>> take a look at what libraries are needed:
>>>>
>>>> 4 atk-1.19.3/     4 gtk+-2.10.13/     4 libsigc++-1.2.7/  4 
>>>> cairo-1.4.8/    4 gtkglext-1.2.0/   4 libsigc++-2.0.17/
>>>> 4 cairomm-1.2.4/  4 gtkglextmm-1.2.0/   4 gtkmm-2.10.10/    4 
>>>> numpy-1.0.3/     4 glib-2.12.9/    4 gtkmm-2.2.12/     4 
>>>> pango-1.17.3/     4 visual-4.beta15/
>>>> 4 glibmm-2.12.10/ 4 libglademm-2.4.2/ 4 Python-2.5.1/
>>>>
>>>> Many of these are tricky to install because they are either
>>>> not very friendly to 64-bit or to installs in non-standard
>>>> locations.  After a fair bit of hacking, I managed to get
>>>> all of these installed (watch out for gtkglextmm -- it has some
>>>> sort of wild problem attempting to link against libGL -- libtool
>>>> for it had to be seriously hacked).
>>>>
>>>> After everything was installed, visual-4.beta15 finally stopped
>>>> complaining about dependent libraries and compiled.  But
>>>> it looks like it has a problem:
>>>>
>>>> steiner.visual-4.beta15: make
>>>> Making all in site-packages/visual
>>>> make[1]: Entering directory 
>>>> `/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/site-packages/visual' 
>>>>
>>>> make[1]: Nothing to be done for `all'.
>>>> make[1]: Leaving directory 
>>>> `/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/site-packages/visual' 
>>>>
>>>> Making all in src
>>>> make[1]: Entering directory 
>>>> `/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/src'
>>>> This is a quiet Makefile. If make exits with an error, check 
>>>> src/build.log to see the complete error message(s). In the event of 
>>>> an error that you cannot debug, please send a message to 
>>>> vis...@li..., including the files 
>>>> config.log and src/build.log, requesting assistance.
>>>> Compiling ./core/arrow.cpp ...
>>>> Compiling ./core/axial.cpp ...
>>>> Compiling ./core/box.cpp ...
>>>> Compiling ./core/cone.cpp ...
>>>> Compiling ./core/cylinder.cpp ...
>>>> Compiling ./core/display_kernel.cpp ...
>>>> Compiling ./core/ellipsoid.cpp ...
>>>> Compiling ./core/frame.cpp ...
>>>> Compiling ./core/label.cpp ...
>>>> Compiling ./core/mouseobject.cpp ...
>>>> Compiling ./core/primitive.cpp ...
>>>> Compiling ./core/pyramid.cpp ...
>>>> Compiling ./core/rectangular.cpp ...
>>>> Compiling ./core/renderable.cpp ...
>>>> Compiling ./core/ring.cpp ...
>>>> Compiling ./core/sphere.cpp ...
>>>> Compiling ./python/convex.cpp ...
>>>> Compiling ./python/curve.cpp ...
>>>> Compiling ./python/cvisualmodule.cpp ...
>>>> Compiling ./python/faces.cpp ...
>>>> Compiling ./python/num_util.cpp ...
>>>> make[1]: *** [num_util.lo] Error 1
>>>> make[1]: Leaving directory 
>>>> `/home/dharrison/wares/rhe4_a64/src/visual-4.beta15/src'
>>>> make: *** [all-recursive] Error 1
>>>>
>>>> I looked at the build log and here is what it says:
>>>>
>>>>  g++ -I/home/dharrison/wares/rhe4_a64/include/python2.5 
>>>> -I/home/dharrison/wares/rhe4_a64/lib/python2.5/site-packages/numpy/core/include 
>>>> -DHAVE_CONFIG_H -I../include -I../include 
>>>> -I/home/dharrison/wares/rhe4_a64/include/gtkglextmm-1.2 
>>>> -I/home/dharrison/wares/rhe4_a64/lib/gtkglextmm-1.2/include 
>>>> -I/home/dharrison/wares/rhe4_a64/include/gtkglext-1.0 
>>>> -I/home/dharrison/wares/rhe4_a64/include/gtkmm-2.4 
>>>> -I/home/dharrison/wares/rhe4_a64/lib/gtkmm-2.4/include 
>>>> -I/home/dharrison/wares/rhe4_a64/lib/gtkglext-1.0/include 
>>>> -I/usr/X11R6/include 
>>>> -I/home/dharrison/wares/rhe4_a64/include/gdkmm-2.4 
>>>> -I/home/dharrison/wares/rhe4_a64/lib/gdkmm-2.4/include 
>>>> -I/home/dharrison/wares/rhe4_a64/include/pangomm-1.4 
>>>> -I/home/dharrison/wares/rhe4_a64/include/gtk-2.0 
>>>> -I/home/dharrison/wares/rhe4_a64/lib/gtk-2.0/include 
>>>> -I/home/dharrison/wares/rhe4_a64/include/pango-1.0 
>>>> -I/home/dharrison/wares/rhe4_a64/include/glib-2.0 
>>>> -I/home/dharrison/wares/rhe4_a64/lib/glib-2.0/include 
>>>> -I/home/dharrison/wares/rhe4_a64/include/cairo 
>>>> -I/home/dharrison/wares/rhe4_a64/include/glibmm-2.4 
>>>> -I/home/dharrison/wares/rhe4_a64/lib/glibmm-2.4/include 
>>>> -I/home/dharrison/wares/rhe4_a64/include/cairomm-1.0 
>>>> -I/home/dharrison/wares/rhe4_a64/include/sigc++-2.0 
>>>> -I/home/dharrison/wares/rhe4_a64/lib/sigc++-2.0/include 
>>>> -I/home/dharrison/wares/rhe4_a64/include/atk-1.0 
>>>> -I/home/dharrison/wares/rhe4_a64/include/atkmm-1.6 
>>>> -I/usr/include/freetype2 
>>>> -I/home/dharrison/wares/rhe4_a64/include/libglademm-2.4 
>>>> -I/home/dharrison/wares/rhe4_a64/lib/libglademm-2.4/include 
>>>> -I/usr/include/libpng12 -I/usr/include/libglade-2.0 
>>>> -I/usr/include/libxml2 -I../include/gtk2 -pthread 
>>>> -I/home/dharrison/wares/rhe4_a64/include/glib-2.0 
>>>> -I/home/dharrison/wares/rhe4_a64/lib/glib-2.0/include 
>>>> -I/home/dharrison/wares/rhe4_a64/include/python2.5 
>>>> -I/home/dharrison/wares/rhe4_a64/lib/python2.5/site-packages/numpy/core/include 
>>>> -fpic -DPIC -g -O2 -ftemplate-depth-120 -MMD -MF num_util.d -MT 
>>>> "num_util.d num_util.lo" -c ./python/num_util.cpp  -fPIC -DPIC -o 
>>>> .libs/num_util.o
>>>> ./python/num_util.cpp: In function `std::vector<npy_intp, 
>>>> std::allocator<npy_intp> > 
>>>> cvisual::python::shape(boost::python::numeric::array)':
>>>> ./python/num_util.cpp:234: error: cannot convert `npy_intp*' to 
>>>> `int*' in initialization
>>>>
>>>> I will take a look see and see if this is something that can be 
>>>> fixed. Has anyone else
>>>> managed to get the beta to compile from ground zero on 64-bit 
>>>> linux?  So far,
>>>> I think I have spent about 1.5 days just on the installation.  I hope
>>>> this is not typical.
>>>>
>>>>        David
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------- 
>>>>
>>>> This SF.net email is sponsored by DB2 Express
>>>> Download DB2 Express C - the FREE version of DB2 express and take
>>>> control of your XML. No limits. Just data. Click to get it now.
>>>> http://sourceforge.net/powerbar/db2/
>>>> _______________________________________________
>>>> Visualpython-users mailing list
>>>> Vis...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>>>       
>>
>>
>> ------------------------------------------------------------------------- 
>>
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> _______________________________________________
>> Visualpython-users mailing list
>> Vis...@li...
>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>
>>   
>
>

Re: [Visualpython-users] Still no progress with the Beta version of visual python

This project is no longer active. See vpython.org.

Re: [Visualpython-users] Still no progress with the Beta version of visual python