visualpython-users

[Visualpython-users] One more stab at OS X compatibility

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

Hi folks,

I'm trying to get beta5 to build and I'm stuck in ./configure.  I've  
even buckled and installed Fink, against my better judgement, just  
for this one project.  I've tried to install all the pre-requisites  
for VPython but I'm still getting the following error:

checking for GTK... configure: error: gtkglextmm 1.2, pangoft2,  
glibmm-2.4, and pangomm-1.4 libglademm-2.4 are required on Unix-like  
systems

Now, I have gtk+, gtk+-shlibs, gtk+2, gtk+2-dev, gtk+2-shlibs, gtk- 
glarea, gtkglarea2, gtkglext1, gtkglext1-shlibs, gtkmm2, gtkmm2-dev,  
gtkmm2-shlibs, pango1, pango1-dev, pango1-shlibs, pango1-xft2, pango1- 
xft2-dev, pango1-xft2-shlibs, etc.

In other words, I've installed every fink library I can find which  
might be helpful in getting VPython to build, but no luck so far.   
Apparently VPython wasn't dependent enough on GTK and had to move  
further towards platform-dependence.  Please correct me if I'm wrong,  
but at this point my guess is that VPython no longer supports  
building on OS X at all.

--Dethe

"Any idea that couldn't stand a few decades of neglect is not worth  
anything." --Gabriel Garcia Marquez

Re: [Visualpython-users] One more stab at OS X compatibility

[Arthur <ajs...@op...>]

Dethe Elza wrote:

>Hi folks,
>
>I'm trying to get beta5 to build and I'm stuck in ./configure.  I've  
>even buckled and installed Fink, against my better judgement, just  
>for this one project.  I've tried to install all the pre-requisites  
>for VPython but I'm still getting the following error:
>
>checking for GTK... configure: error: gtkglextmm 1.2, pangoft2,  
>glibmm-2.4, and pangomm-1.4 libglademm-2.4 are arequired on Unix-like  
>systems
>
>  
>
The "mm" series of GTK+ libraries are (as I understand it) the C++ 
wrapper for the corresponding gtk libraries.

Some of what I think you are missing glibmm, libglademm (grab sigc++ 
while you are there) seem to be available at

http://ftp.acc.umu.se/pub/GNOME/bindings/2.16/2.16.0/sources/c++/

gtkglextmm is more of an issue

Which is a guess consistent with what I see at 

http://www.student.cs.uwaterloo.ca/~azolotko/cse more 488onmac.html

where instructions on building gtkglextmm for fink are given.

I don't understand the relationship between FreeBSD and fink, but there 
does seem to be a FreeBSD version of gtkglextmm.

http://www.freebsdsoftware.org/x11-toolkits/

Pangomm is a wildcard. I don't see a separate fink version, but do see 
evidence of programs dependent on it being built on fink.  I suspect it 
is included in
what you have.

Have you dealt with., prepared for, the boost dependency issues.  I 
promise you that they are there as well, but not sure configure deals 
with them.

Anxious to help...

And counseling patience.

Art







>Now, I have gtk+, gtk+-shlibs, gtk+2, gtk+2-dev, gtk+2-shlibs, gtk- 
>glarea, gtkglarea2, gtkglext1, gtkglext1-shlibs, gtkmm2, gtkmm2-dev,  
>gtkmm2-shlibs, pango1, pango1-dev, pango1-shlibs, pango1-xft2, pango1- 
>xft2-dev, pango1-xft2-shlibs, etc.
>
>In other words, I've installed every fink library I can find which  
>might be helpful in getting VPython to build, but no luck so far.   
>Apparently VPython wasn't dependent enough on GTK and had to move  
>further towards platform-dependence.  Please correct me if I'm wrong,  
>but at this point my guess is that VPython no longer supports  
>building on OS X at all.
>
>--Dethe
>
>"Any idea that couldn't stand a few decades of neglect is not worth  
>anything." --Gabriel Garcia Marquez
>
>
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>_______________________________________________
>Visualpython-users mailing list
>Vis...@li...
>https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>
>  
>

Re: [Visualpython-users] One more stab at OS X compatibility

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

Arthur wrote:
[]
> gtkglextmm is more of an issue

There is now a Fink package of gtkglextmm, so this is now no more an 
issue than the other packages. In fact, I got vpython-core2 CVS to build 
on OSX 10.4.8/intel without problem, using existing Fink packages for 
all prerequisites:

   fink install freetype219 fontconfig2-dev libglademm2.4 gtkglextmm 
scipy-py25 boost1.33
     (this list is probably not complete)
   sh ./autogen.sh
   export 
PKG_CONFIG_PATH=/sw/lib/fontconfig2/lib/pkgconfig:/sw/lib/xft2/lib/pkgconfig:/sw/lib/freetype219/lib/pkgconfig
   ./configure --prefix=/sw
   make

-- 
Martin

Re: [Visualpython-users] One more stab at OS X compatibility

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

Hi Martin,

> Adding it to Fink's 10.4/unstable tree is a matter of seconds, so I  
> just
> did it.

Thanks for putting this together.  I switched to unstable and was  
able to install visual-py25 without problems.  I haven't exercised it  
extensively yet, but I can open a window and create basic shapes  
(sphere, cube). [Update: I took some time to run it over some more  
(much more) complex examples and haven't had any trouble]

> I am, however, not completely comfortable with these pythonXX  
> variants,
> because I don't know if they wouldn't ultimately also require
> corresponding variants for the boost-python libraries. Currently I am
> building the libboost_python libraries with the version of python that
> comes with OSX, which is python-2.3. This is then linked into the
> cvisualmodule.so which is ultimately run under python-2.5. On starting
> vpython2.5, the python shell complains mildly about differing APIs,  
> but
> in my (very few) tests it did run correctly. I cannot exclude that  
> there
> will be other situations where this leads to serious problems, though.

When I import visual, I do get the following error, although it  
appears to work OK:

 >>> from visual import *
/sw/lib/python2.5/site-packages/visual/array_backend.py:1:  
RuntimeWarning: Python C API version mismatch for module cvisual:  
This Python has API version 1013, module cvisual has version 1012.
   import cvisual

I assume that is the warning you were talking about?

Under the assumption that Python2.5 extensions were binary  
compatible, as long as it was the same version, I naively tried  
moving cvisualpython.so and visual/ to the site-packages directory of  
my framework build of Python2.5, but no such luck:

 >>> from visual import *
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/visual/__init__.py", line 15, in <module>
     import array_backend
   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/visual/array_backend.py", line 1, in <module>
     import cvisual
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/cvisualmodule.so, 2): Symbol not found:  
_PyType_GenericAlloc
   Referenced from: /Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/cvisualmodule.so
   Expected in: /Library/Frameworks/Python.framework/Versions/2.5/ 
Resources/Python.app/Contents/MacOS/Python

> Rearranging the packaging of the boost libraries so that the
> libboost_python libs would inhabit different packages corresponding to
> different python versions would require some work for which I haven't
> had the time yet.

Well, I certainly appreciate what you've done so far.

> So for now I am just waiting for reports on working/non-working
> visual-py25 (and visual-py24 for that matter) installations.

Looks good here.

>> Ultimately, some are hoping for a vpython that does not require fink.
>> Do you have an opinion as to what might be the best path towards  
>> that??
>
> I am not the right person to ask about this. In my opinion, every Mac
> user should install Fink ;-)
>
> What might be more interesting is to get rid of the X11 dependency and
> build a vpython that runs with Apple's python and aqua graphics.  
> Fink or
> not Fink is not the question.

I think you've nailed the crux of the matter.  What is wanted is (in  
order of importance):

1. Run under Aqua with no dependencies on X11 (and thus no need for  
gtk libraries)
2. Integrate with other tools that run under a framework build of  
Python (so, for instance, VPython programs could be packaged with  
py2app, could run in the same process as PyObjC programs, could  
interact with PyGame, etc.)

I think there is some resistance to Fink because of perhaps some  
instability in earlier versions, but more importantly, because Fink  
tends to bring along more Linuxisms and retain a dependency on X11  
rather than integrating with Aqua.  At least, that has been my  
impression, whether fairly or not.

>> Untangling vpython from its boost dependencies does not seem  
>> realistic.
>> I see that you maintain the boost fink packages.  But is boost itself
>> dependent upon fink if it is to be used as a dependency on OS X??

I could live with (but never love) Boost, if VPython could play  
nicely as an OS X citizen (no X11, framework build of Python).

Thanks also for the insights into how Fink packages are built.  That  
process has been opaque to me up until now, but I feel like you've  
given me enough to get started.

--Dethe

"Why is Virtual Reality always posited in terms of space, when time  
is the only real commodity left?" --Rich Gold

Re: [Visualpython-users] One more stab at OS X compatibility

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

Dethe Elza wrote:
[]
> When I import visual, I do get the following error, although it  
> appears to work OK:
> 
>  >>> from visual import *
> /sw/lib/python2.5/site-packages/visual/array_backend.py:1:  
> RuntimeWarning: Python C API version mismatch for module cvisual:  
> This Python has API version 1013, module cvisual has version 1012.
>    import cvisual
> 
> I assume that is the warning you were talking about?

Yes. I think (not 100% sure though) that it detects some trace of the 
python2.3 that libboost_python was built with. The cvisual module now 
links to the static version of libboost_python. When it linked to the 
dynamic version, at the place of the above warning there was a crash.

> Under the assumption that Python2.5 extensions were binary  
> compatible, as long as it was the same version, I naively tried  
> moving cvisualpython.so and visual/ to the site-packages directory of  
> my framework build of Python2.5, but no such luck:
> 
>  >>> from visual import *
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
>    File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
> python2.5/site-packages/visual/__init__.py", line 15, in <module>
>      import array_backend
>    File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
> python2.5/site-packages/visual/array_backend.py", line 1, in <module>
>      import cvisual
> ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.5/ 
> lib/python2.5/site-packages/cvisualmodule.so, 2): Symbol not found:  
> _PyType_GenericAlloc
>    Referenced from: /Library/Frameworks/Python.framework/Versions/2.5/ 
> lib/python2.5/site-packages/cvisualmodule.so
>    Expected in: /Library/Frameworks/Python.framework/Versions/2.5/ 
> Resources/Python.app/Contents/MacOS/Python

The cvisualmodule.so wants to load this symbol PyType_GenericAlloc from 
the python executable. It is defined in Fink's python2.5, but apparently 
not in the framework version of the python executable. There it is 
defined in the Python library. The module is compiled with the 
-bundle-loader linker flag which can have this side effect.

[]
>> So for now I am just waiting for reports on working/non-working
>> visual-py25 (and visual-py24 for that matter) installations.
> 
> Looks good here.

Thanks.
[]
> I think you've nailed the crux of the matter.  What is wanted is (in  
> order of importance):
> 
> 1. Run under Aqua with no dependencies on X11 (and thus no need for  
> gtk libraries)
> 2. Integrate with other tools that run under a framework build of  
> Python (so, for instance, VPython programs could be packaged with  
> py2app, could run in the same process as PyObjC programs, could  
> interact with PyGame, etc.)
> 
> I think there is some resistance to Fink because of perhaps some  
> instability in earlier versions, but more importantly, because Fink  
> tends to bring along more Linuxisms and retain a dependency on X11  
> rather than integrating with Aqua.  At least, that has been my  
> impression, whether fairly or not.

It may appear so, because Fink traditionally focused on porting software 
from linux/Unix (hence X11) to Mac OSX. But there is no technical or 
philosophical reason why Fink cannot package Aqua applications and 
application bundles. There are a couple (though still very few) of them 
in Fink now.

-- 
Martin

Re: [Visualpython-users] One more stab at OS X compatibility

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

On 25-Nov-06, at 12:51 PM, Martin Costabel wrote:

> Arthur wrote:
> []
>> gtkglextmm is more of an issue
>
> There is now a Fink package of gtkglextmm, so this is now no more an
> issue than the other packages. In fact, I got vpython-core2 CVS to  
> build
> on OSX 10.4.8/intel without problem, using existing Fink packages for
> all prerequisites:
>
>    fink install freetype219 fontconfig2-dev libglademm2.4 gtkglextmm
> scipy-py25 boost1.33
>      (this list is probably not complete)
>    sh ./autogen.sh
>    export
> PKG_CONFIG_PATH=/sw/lib/fontconfig2/lib/pkgconfig:/sw/lib/xft2/lib/ 
> pkgconfig:/sw/lib/freetype219/lib/pkgconfig
>    ./configure --prefix=/sw
>    make

OK, this looks like an excellent tutorial which explains (at least in  
part) why I have been having so much trouble getting VPython to  
configure (much less build).  Unfortunately, I still am getting the  
same errors I always have when I try to build visual-4.beta5 (when  
running .configure)

checking for GTK... configure: error: gtkglextmm 1.2, pangoft2,  
glibmm-2.4, and pangomm-1.4 libglademm-2.4 are required on Unix-like  
systems

Now one thing I notice immediately that differs on my system from the  
instructions above is that I do not have an autogen.sh script in the  
root.

If you can help me get through the config/build steps, I'm willing to  
look into Aquafication.  My stumbling block with VPython has been my  
poor autoconf-fu.

Thanks!

--Dethe


>
> -- 
> Martin
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users


"The real trouble with this world of ours is not that it is an  
unreasonable world, nor even that it is a reasonable one. The  
commonest kind of trouble is that it is nearly reasonable, but not  
quite. Life is not an illogicality; yet it is a trap for logicians.  
It looks just a little more mathematical and regular than it is; its  
exactitude is obvious, but its inexactitude is hidden; its wildness  
lies in wait." --G.K. Chesterton

Re: [Visualpython-users] One more stab at OS X compatibility

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

Dethe Elza wrote:

> checking for GTK... configure: error: gtkglextmm 1.2, pangoft2,  
> glibmm-2.4, and pangomm-1.4 libglademm-2.4 are required on Unix-like  
> systems

You can look in src/build.log for more information on this error. It 
will show you which library or package is still missing.

> Now one thing I notice immediately that differs on my system from the  
> instructions above is that I do not have an autogen.sh script in the  
> root.

I am building this from inside a source tree checked out directly via 
cvs. Maybe the tarball that you are using doesn't contain autogen.sh, 
but it will contain a ready configure script. I was simply following 
instructions from HACKING.txt.

-- 
Martin

Re: [Visualpython-users] One more stab at OS X compatibility

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

Hi Martin,

On 28-Nov-06, at 12:58 AM, Martin Costabel wrote:

> Dethe Elza wrote:
>
>> checking for GTK... configure: error: gtkglextmm 1.2, pangoft2,   
>> glibmm-2.4, and pangomm-1.4 libglademm-2.4 are required on Unix- 
>> like  systems
>
> You can look in src/build.log for more information on this error.  
> It will show you which library or package is still missing.

Excellent, thanks for the tip.

>> Now one thing I notice immediately that differs on my system from  
>> the  instructions above is that I do not have an autogen.sh script  
>> in the  root.
>
> I am building this from inside a source tree checked out directly  
> via cvs. Maybe the tarball that you are using doesn't contain  
> autogen.sh, but it will contain a ready configure script. I was  
> simply following instructions from HACKING.txt.

OK, I've checked out a clean copy from CVS.  Now when I run "sh ./ 
autogen.sh" I get the following:

configure.ac: installing `./install-sh'
configure.ac: installing `./mkinstalldirs'
configure.ac: installing `./missing'
aclocal.m4:319: installing `./py-compile'
Makefile.am:6: SUBDIRS was already defined in condition TRUE, which  
implies condition BUILD_EXAMPLES_TRUE

   SUBDIRS (User, where = Makefile.am:6) +=
   {
     TRUE => site-packages/visual src
   }
Makefile.am:6: SUBDIRS was already defined in condition TRUE, which  
implies condition BUILD_DOCS_TRUE

   SUBDIRS (User, where = Makefile.am:6) +=
   {
     TRUE => site-packages/visual src
     BUILD_EXAMPLES_TRUE => examples
   }
Makefile.am:6: directory should not contain `/'
configure.ac:33: error: possibly undefined macro: AC_MSG_ERROR
       If this token and others are legitimate, please use  
m4_pattern_allow.
       See the Autoconf documentation.
Completed successfully

====================== snip ========================

Lulled by the false sense of security from that last line ("Completed  
successfully") I tried running the resulting .configure, but received  
syntax errors, so I'm taking a step back to try to get autogen.sh to  
run without errors.  Do any of the above ring any bells for you?  Do  
these indicate that I'm missing a library, need a newer version of  
the autoconf chain (I'm pretty sure I'm up to date with that), or  
something else?

Thanks again for your help!

--Dethe

>
> -- 
> Martin
>


Email is where knowledge goes to die. --Bill French

Re: [Visualpython-users] One more stab at OS X compatibility

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

On 28-Nov-06, at 12:58 AM, Martin Costabel wrote:

> I am building this from inside a source tree checked out directly  
> via cvs. Maybe the tarball that you are using doesn't contain  
> autogen.sh, but it will contain a ready configure script. I was  
> simply following instructions from HACKING.txt.

I'm using the source tree from CVS and I've compared the autogen.sh  
to the one you are using and they are identical, so I'm not sure why  
I'm getting errors with it.  When I try to run the resulting  
configure script I get the following errors:

./configure: line 19239: syntax error near unexpected token `GTK,'
./configure: line 19239: `      PKG_CHECK_MODULES( GTK, sigc++-2.0, ,'

So it looks like the autogen.sh is building a bum configure, but I'm  
still no closer to understanding why.  I've done a fink upgrade-all  
and run on a clean checkout from CVS.  I guess the next step is to  
delve into autoconf lore, but that is black magick I never really  
wanted to have to get into, and this is the only program where I feel  
I have no choice.

Any advice or pointers would be welcome.

--Dethe

>
> -- 
> Martin
>


"...coding isn't the poor handmaiden of design or analysis. Coding is
where your fuzzy, comfortable ideas awaken in the harsh dawn of reality.
It is where you learn what your computer can do. If you stop coding,
you stop learning."     Kent Beck, Smalltalk Best Practice Patterns

Re: [Visualpython-users] One more stab at OS X compatibility

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

Dethe Elza wrote:
[]
> I'm using the source tree from CVS and I've compared the autogen.sh to 
> the one you are using and they are identical, so I'm not sure why I'm 
> getting errors with it.  When I try to run the resulting configure 
> script I get the following errors:
> 
> ./configure: line 19239: syntax error near unexpected token `GTK,'
> ./configure: line 19239: `      PKG_CHECK_MODULES( GTK, sigc++-2.0, ,'

I don't know anything about the autotools either, but this doesn't look 
good, indeed. Here is what I have installed in this area from Fink:

  i   autoconf                   2.60-4
  i   automake1.9                1.9.6-3
  i   libtool14                  1.5.22-1000
  i   libtool14-shlibs           1.5.22-1000
  i   m4                         1.4.5-3

What do you have there? (This is on 10.4.8/intel).

-- 
Martin

Re: [Visualpython-users] One more stab at OS X compatibility

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

On 29-Nov-06, at 9:43 AM, Martin Costabel wrote:

> Dethe Elza wrote:
> []
>> I'm using the source tree from CVS and I've compared the  
>> autogen.sh to the one you are using and they are identical, so I'm  
>> not sure why I'm getting errors with it.  When I try to run the  
>> resulting configure script I get the following errors:
>> ./configure: line 19239: syntax error near unexpected token `GTK,'
>> ./configure: line 19239: `      PKG_CHECK_MODULES( GTK, sigc+ 
>> +-2.0, ,'
>
> I don't know anything about the autotools either, but this doesn't  
> look good, indeed. Here is what I have installed in this area from  
> Fink:
>
>  i   autoconf                   2.60-4
>  i   automake1.9                1.9.6-3
>  i   libtool14                  1.5.22-1000
>  i   libtool14-shlibs           1.5.22-1000
>  i   m4                         1.4.5-3
>
> What do you have there? (This is on 10.4.8/intel).

That's what I have too.  The only difference (from the above, there  
may be other differences) is my m4 is listed as "(i)" rather than  
"i".  I'm also on 10.4.8/intel.

Curiouser and curiouser.

Well, Apple just applied a bunch of security updates via Software  
Update.  I'll reboot and try again.

Thanks!

--Dethe

>
> -- 
> Martin
>


Every day computers are making people easier to use. --David Tompkin

[Visualpython-users] OS X build getting closer

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

OK the problem turned out to be that I am a doofus.  Although I had  
sourced /sw/bin/init.sh, I hadn't actually checked my path afterwards  
(maybe I ran it instead of sourcing it?).  Anyway, I was picking up  
Apple's autoconf chain, not fink's.  Changed that, found a couple of  
more dependencies needed, installed those, made it much further.

I'm running into a problem when VPython tries to bind to numpy.  I  
have numpy installed in my standard Python, and (via scipy) in fink.   
But VPython's make can't find it, and setting GCC_INCLUDE_DIR doesn't  
appear to help.  Is this something I need to add to PKG_CONFIG_PATH?

I'm feeling like this is so close now.  And I found where the .info  
file was hiding, so I'm looking at that to see how the fink VPython  
was built.

Progress!

Thanks,

--Dethe


On 29-Nov-06, at 9:43 AM, Martin Costabel wrote:

> Dethe Elza wrote:
> []
>> I'm using the source tree from CVS and I've compared the  
>> autogen.sh to the one you are using and they are identical, so I'm  
>> not sure why I'm getting errors with it.  When I try to run the  
>> resulting configure script I get the following errors:
>> ./configure: line 19239: syntax error near unexpected token `GTK,'
>> ./configure: line 19239: `      PKG_CHECK_MODULES( GTK, sigc+ 
>> +-2.0, ,'
>
> I don't know anything about the autotools either, but this doesn't  
> look good, indeed. Here is what I have installed in this area from  
> Fink:
>
>  i   autoconf                   2.60-4
>  i   automake1.9                1.9.6-3
>  i   libtool14                  1.5.22-1000
>  i   libtool14-shlibs           1.5.22-1000
>  i   m4                         1.4.5-3
>
> What do you have there? (This is on 10.4.8/intel).
>
> -- 
> Martin
>


We must be careful not to build a world we don't want to live in. -- 
Stu Card

[Visualpython-users] VPython on OS X, steps forward and otherwise

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

The following incantation has allowed me to compile visual (fresh  
checkout from vpython-core2) once I got all the dependencies  
installed and made sure my paths had /sw/bin first:

#!/bin/sh -ex
   rm config.guess
   rm config.sub
   rm ltmain.sh
   sh ./autogen.sh
   export PKG_CONFIG_PATH=/sw/lib/fontconfig2/lib/pkgconfig:/sw/lib/ 
xft2/lib/pkgconfig:/sw/lib/freetype219/lib/pkgconfig
   export PYTHON=/sw/bin/python2.5
   export CXXFLAGS="-O2 -finline-functions"
   export CFLAGS='-O3'
   ./configure --prefix=/sw --disable-dependency-tracking
    make

Unfortunately,  when I go into python after building and installing,  
I get this:

 >>> from visual import *
Fatal Python error: Interpreter not initialized (version mismatch?)
Abort trap

Not sure why this is, but my config.log doesn't look right.  I've  
attached both that file and my src/build.log.  That's all I can do  
for today, maybe I'll make more progress tomorrow.  Any suggestions  
welcome.

--Dethe

Re: [Visualpython-users] VPython on OS X, steps forward and otherwise

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

Dethe Elza wrote:
[]
>  >>> from visual import *
> Fatal Python error: Interpreter not initialized (version mismatch?)
> Abort trap

Yes, that's what you get when you link cvisualmodule.so with Fink's 
libboost_python.dylib that was compiled with the system python2.3. To 
work around this, you can link with the static libboost_python.a by 
changing "-lboost_python" to "/sw/lib/libboost_python.a" at the right 
place in src/Makefile.in.

A better fix would be to build libboost_python.dylib with python2.5, but 
as I mentioned in one of my earlier messages, there is currently no Fink 
package that does this. I'll make one soon if I have some time left.

-- 
Martin

Re: [Visualpython-users] VPython on OS X, steps forward and otherwise

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

On 30-Nov-06, at 12:17 PM, Martin Costabel wrote:

> Yes, that's what you get when you link cvisualmodule.so with Fink's  
> libboost_python.dylib that was compiled with the system python2.3.  
> To work around this, you can link with the static libboost_python.a  
> by changing "-lboost_python" to "/sw/lib/libboost_python.a" at the  
> right place in src/Makefile.in.

That did it!  Thanks for being patient with me and repeating your  
good advice until I see it.  I now have a build of visual that  
supports transparency!

> A better fix would be to build libboost_python.dylib with  
> python2.5, but as I mentioned in one of my earlier messages, there  
> is currently no Fink package that does this. I'll make one soon if  
> I have some time left.

I have build libboost_python before on OS X.  Building all of Boost  
is a major undertaking, but the python part is relatively achievable.

Here's a sample session:

 >>> from visual import *
/sw/lib/python2.5/site-packages/visual/__init__.py:27:  
RuntimeWarning: Python C API version mismatch for module cvisual:  
This Python has API version 1013, module cvisual has version 1012.
   import cvisual
 >>> ball = sphere(color=(0,1,0), opacity=0.3)

(<unknown>:20183): libglade-WARNING **: unknown property  
`urgency_hint' for class `gtkmm__GtkWindow'

(<unknown>:20183): Gtk-WARNING **: gtkwidget.c:3143: widget  
`gtkmm__GtkToolButton' has no activatable signal "clicked" without  
arguments
 >>> cube = box(color=(0,0,1))

As you can see, it's not perfect, but it does put up a transparent  
green sphere with a blue cube inside it.  If X11 is not running or  
the DISPLAY environment variable is not set it crashes Python, and I  
haven't found a clean way to exit it yet, if running from the console  
(closing the window exits OK when I run "python [script]".  The first  
time I ran it, the sphere took a couple of minutes to show up, but it  
has been relatively immediate on subsequent runs.  Running this  
simple scene takes 25-30% of one of my CPUs (2GHz) when run from the  
console, but a much more complex example only uses 11% of a CPU when  
run as a script.

Still, it works, and I've tested most of the example programs.

Martin, thanks for all your help!  There is no motivator like success.

Now I can begin...

--Dethe

"Computers are beyond dumb, they're mind-numbingly stupid. They're  
hostile, rigid, capricious, and unforgiving. They're impossibly  
demanding and they never learn anything." -- John R. Levine

Re: [Visualpython-users] VPython on OS X, steps forward and otherwise

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

Dethe Elza wrote:
> On 30-Nov-06, at 12:17 PM, Martin Costabel wrote:
> 
>> Yes, that's what you get when you link cvisualmodule.so with Fink's  
>> libboost_python.dylib that was compiled with the system python2.3.  
>> To work around this, you can link with the static libboost_python.a  
>> by changing "-lboost_python" to "/sw/lib/libboost_python.a" at the  
>> right place in src/Makefile.in.
> 
> That did it!  Thanks for being patient with me and repeating your  
> good advice until I see it.  I now have a build of visual that  
> supports transparency!

I have now made and committed a new revision of Fink's boost1.33 
package, version 1.33.1-1007. It builds libboost_python.dylib using 
Fink's python, no longer with the system python framework. This avoids 
the crash we were talking about. In fact, the new libboost_python.dylib 
can be built with any one of Fink's python versions 2.3, 2.4, or 2.5. 
The resulting libraries are, for all intents and purposes, identical, as 
far as I can tell, and they can be used with any of these python versions.

In particular, I was able to compile the current vpython-core2 CVS 
sources (beta10) without any patches. The entire incantation was, as 
noted before:

   sh ./autogen.sh
   export 
PKG_CONFIG_PATH=/sw/lib/fontconfig2/lib/pkgconfig:/sw/lib/xft2/lib/pkgconfig:/sw/lib/freetype219/lib/pkgconfig
   ./configure --prefix=/sw
   make

-- 
Martin

Re: [Visualpython-users] VPython on OS X, steps forward and otherwise

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

On 3-Dec-06, at 8:28 AM, Martin Costabel wrote:

> Dethe Elza wrote:
>> On 30-Nov-06, at 12:17 PM, Martin Costabel wrote:
>>> Yes, that's what you get when you link cvisualmodule.so with  
>>> Fink's  libboost_python.dylib that was compiled with the system  
>>> python2.3.  To work around this, you can link with the static  
>>> libboost_python.a  by changing "-lboost_python" to "/sw/lib/ 
>>> libboost_python.a" at the  right place in src/Makefile.in.
>> That did it!  Thanks for being patient with me and repeating your   
>> good advice until I see it.  I now have a build of visual that   
>> supports transparency!
>
> I have now made and committed a new revision of Fink's boost1.33  
> package, version 1.33.1-1007. It builds libboost_python.dylib using  
> Fink's python, no longer with the system python framework. This  
> avoids the crash we were talking about. In fact, the new  
> libboost_python.dylib can be built with any one of Fink's python  
> versions 2.3, 2.4, or 2.5. The resulting libraries are, for all  
> intents and purposes, identical, as far as I can tell, and they can  
> be used with any of these python versions.
>
> In particular, I was able to compile the current vpython-core2 CVS  
> sources (beta10) without any patches. The entire incantation was,  
> as noted before:
>
>   sh ./autogen.sh
>   export PKG_CONFIG_PATH=/sw/lib/fontconfig2/lib/pkgconfig:/sw/lib/ 
> xft2/lib/pkgconfig:/sw/lib/freetype219/lib/pkgconfig
>   ./configure --prefix=/sw
>   make
>
> -- 
> Martin

Hi Martin,

I did the following:

   fink selfupdate
   fink update-all
   cvspurge # removes all locally-changed or added files
   cvs up  # in vpython-core2 directory
   sh ./autogen.sh
   export PKG_CONFIG_PATH=/sw/lib/fontconfig2/lib/pkgconfig:/sw/lib/ 
xft2/lib/pkgconfig:/sw/lib/freetype219/lib/pkgconfig
   ./configure --prefix=/sw
   make
   sudo make install
   python [vpython script]

Which results in:

   Fatal Python error: Interpreter not initialized (version mismatch?)
   Abort trap

What am I doing wrong?  Somewhere I seem to be missing a step.

--Dethe


"Computers are beyond dumb, they're mind-numbingly stupid. They're  
hostile, rigid, capricious, and unforgiving. They're impossibly  
demanding and they never learn anything." -- John R. Levine

Re: [Visualpython-users] VPython on OS X, steps forward and otherwise

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

Dethe Elza wrote:
[]
>    python [vpython script]
> 
> Which results in:
> 
>    Fatal Python error: Interpreter not initialized (version mismatch?)
>    Abort trap

Which python does your "python" command run? Is it the same as the one 
into whose site-packages directory the visual module was installed? And 
the same as used for compiling vpython and boost1.33?

With Fink, if you install for example the python25 package, you don't 
get a "python" executable, only "python2.5". You have to install 
additionally the "python" package which creates a symlink between 
/sw/bin/python2.5 and /sw/bin/python.

-- 
Martin

Re: [Visualpython-users] VPython on OS X, steps forward and otherwise

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

On 4-Dec-06, at 3:28 PM, Martin Costabel wrote:

> Dethe Elza wrote:
> []
>>    python [vpython script]
>> Which results in:
>>    Fatal Python error: Interpreter not initialized (version  
>> mismatch?)
>>    Abort trap
>
> Which python does your "python" command run? Is it the same as the  
> one into whose site-packages directory the visual module was  
> installed? And the same as used for compiling vpython and boost1.33?

/sw/bin/python is the first python in my path and points to /sw/bin/ 
python2.5  As far as I can tell, it should be the same for all of  
these cases.

> With Fink, if you install for example the python25 package, you  
> don't get a "python" executable, only "python2.5". You have to  
> install additionally the "python" package which creates a symlink  
> between /sw/bin/python2.5 and /sw/bin/python.

I already added that symlink manually.  Does the python package do  
more than that?

I don't know if I remembered to note this in my earlier mail, but the  
tip you gave about renaming -lboost_python to /sw/lib/ 
libboost_python.a worked to get a working VPython, though still  
crashing frequently.

--Dethe

"Say what you like about C++, but it's uninitialized variables will  
always
hold a special place in my heart. In a world where we define  
*everything*
concretely it is the last refuge of the undefined. It's the programmer's
Wild West, the untamed frontier." --Bjorn Stroustrap

Re: [Visualpython-users] VPython on OS X, steps forward and otherwise

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

Dethe Elza wrote:
> On 4-Dec-06, at 3:28 PM, Martin Costabel wrote:
> 
>> Dethe Elza wrote:
>> []
>>>    python [vpython script]
>>> Which results in:
>>>    Fatal Python error: Interpreter not initialized (version  
>>> mismatch?)
>>>    Abort trap
>> Which python does your "python" command run? Is it the same as the  
>> one into whose site-packages directory the visual module was  
>> installed? And the same as used for compiling vpython and boost1.33?
> 
> /sw/bin/python is the first python in my path and points to /sw/bin/ 
> python2.5  As far as I can tell, it should be the same for all of  
> these cases.

Hmm, if you run "otool -L" on the cvisualmodule.so and on 
libboost_python.dylib, does any Python.framework or other libpython 
still show up?

>> With Fink, if you install for example the python25 package, you  
>> don't get a "python" executable, only "python2.5". You have to  
>> install additionally the "python" package which creates a symlink  
>> between /sw/bin/python2.5 and /sw/bin/python.
> 
> I already added that symlink manually.  Does the python package do  
> more than that?

Not much more; it makes additional symlinks for idle, pydoc, smtpd.py, 
and for the python.1 man page.

> I don't know if I remembered to note this in my earlier mail, but the  
> tip you gave about renaming -lboost_python to /sw/lib/ 
> libboost_python.a worked to get a working VPython, though still  
> crashing frequently.

Did you look at the crash logs in ~/Library/Logs/CrashReporter/? Is 
there anything systematic jumping out from them?

-- 
Martin

Re: [Visualpython-users] One more stab at OS X compatibility

[Arthur <ajs...@op...>]

Martin Costabel wrote:

> Arthur wrote:
> []
>
>> gtkglextmm is more of an issue
>
>
> There is now a Fink package of gtkglextmm, so this is now no more an 
> issue than the other packages. In fact, I got vpython-core2 CVS to 
> build on OSX 10.4.8/intel without problem, using existing Fink 
> packages for all prerequisites:

Hi Martin -

I see that your interest,work,knowledge of these matters is more than 
casual:

http://pdb.finkproject.org/pdb/maintainer.php?maintainer=Martin%20Costabel

As my questions below will indicate, I am not a Mac person myself, but 
am interested in the subject of vpython and Mac.

Do you see a visual-py25 on the horizon?

And:

Is there anywhere where one can find  succinct and complete instructions 
for a fink build??

Ultimately, some are hoping for a vpython that does not require fink.  
Do you have an opinion as to what might be the best path towards that??

Untangling vpython from its boost dependencies does not seem realistic. 
I see that you maintain the boost fink packages.  But is boost itself 
dependent upon fink if it is to be used as a dependency on OS X??

Art

Re: [Visualpython-users] One more stab at OS X compatibility

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

Arthur wrote:
[]
> As my questions below will indicate, I am not a Mac person myself, but 
> am interested in the subject of vpython and Mac.
> 
> Do you see a visual-py25 on the horizon?

Adding it to Fink's 10.4/unstable tree is a matter of seconds, so I just 
did it.

I am, however, not completely comfortable with these pythonXX variants, 
because I don't know if they wouldn't ultimately also require 
corresponding variants for the boost-python libraries. Currently I am 
building the libboost_python libraries with the version of python that 
comes with OSX, which is python-2.3. This is then linked into the 
cvisualmodule.so which is ultimately run under python-2.5. On starting 
vpython2.5, the python shell complains mildly about differing APIs, but 
in my (very few) tests it did run correctly. I cannot exclude that there 
will be other situations where this leads to serious problems, though.

Rearranging the packaging of the boost libraries so that the 
libboost_python libs would inhabit different packages corresponding to 
different python versions would require some work for which I haven't 
had the time yet.

So for now I am just waiting for reports on working/non-working 
visual-py25 (and visual-py24 for that matter) installations.

> And:
> 
> Is there anywhere where one can find  succinct and complete instructions 
> for a fink build??

Well, for the released version of vpython, there is not much to say (in 
principle, at least):

1. Install Fink and (optionally) enable the "unstable" tree
2. Run "fink selfupdate"
3. Run "fink install visual-py24"

Points 2 and 3 can be replaced by the corresponding mouse clicks in the 
FinkCommander GUI.

Of course, there are details that need to be learned by reading 
documentation, and things can go wrong, too, but basically it is that 
simple.

> Ultimately, some are hoping for a vpython that does not require fink.  
> Do you have an opinion as to what might be the best path towards that??

I am not the right person to ask about this. In my opinion, every Mac 
user should install Fink ;-)

What might be more interesting is to get rid of the X11 dependency and 
build a vpython that runs with Apple's python and aqua graphics. Fink or 
not Fink is not the question.

> Untangling vpython from its boost dependencies does not seem realistic. 
> I see that you maintain the boost fink packages.  But is boost itself 
> dependent upon fink if it is to be used as a dependency on OS X??

Well, nothing "depends" on Fink. Fink is only a package manager and a 
convenient way to organize the downloading, building and installation of 
open source software. You can imitate by hand everything Fink does; it 
suffices to read the *.info and, if it exists, the *.patch file for each 
package in the list of dependencies. The *.info files are 
human-readable, not much more than succinct descriptions of the build 
procedures. If you do things by hand, you will even gain in simplicity: 
You can install into the standard directory /usr/local instead of Fink's 
/sw, and you can directly install into the runtime directory; you don't 
need to install into an intermediate directory like it needs to be done 
by a package manager. You will lose in cleanliness, on the other hand, 
because you have to live alongside all the other garbage that will be 
installed in /usr/local.

-- 
Martin

Re: [Visualpython-users] VPython on OS X, steps forward and otherwise

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

On 30-Nov-06, at 5:52 AM, Arthur wrote:

> I am concerned that you are working not at the bleeding edge, but =20
> beyond
> it a bit. And are trying to solve problems that shouldn't be yours =20
> - in
> that beta8 is a work in progress that has been focusing not only on
> numpy compatibility but on some Windows specific build issues, and =20
> that
> there has been some futzing with Makefile.in (that I think Bruce =20
> checked
> in) that address those, but without, at the moment, thinking =20
> through the
> crossplatform implications, mainly because we haven't finalized =20
> what the
> keepers are, even for Windows.

I was trying to build from the beta5 tarball, but the files Martin =20
was using weren't in it (there are several build tools involved--not =20
sure how/where pycompile, scons, or mkdist_osx.sh enter into the =20
process (are they used, or just cruft left from earlier builds?).  On =20=

the other hand, now that I have gotten it to build and run (see my =20
reply to Martin following this), I can try to repeat the process from =20=

the beta5 tarball, or selectively roll back what I have checked out =20
from CVS.

> That being said, I think Bruce successfully did a Linux build from the
> cvs as late as yesterday with no apparent problems.

Excellent.  Bruce, if you're reading this, could you give me some =20
insight into which of the build tools you're using?

> Coming in late, but looking at your build log where everything looks
> rather sensible.
>
> Is it clear where -lboost_python -lboost_thread are being found.

Martin had given me the key to this in an earlier message, but I had =20
missed it.  Got it now.

> Presumably you are using a binary distro of these libs that are =20
> placing
> them somewhere standard.  I mention it because when I have built those
> libraries, on Linux, or Windows I have had to handle them with kid
> gloves, re: naming and install issues.

I'm using Fink to build all of the libs.

> Beyond those clues, which might not be clues, don't have a clue =20
> what you
> might be running into.

It's all helpful.  Thanks, Art!

> Art

--Dethe

values of =CE=B2 will give rise to dom --Unix prehistory

Re: [Visualpython-users] VPython on OS X, steps forward and otherwise

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

I'm not using any special build tools. But as of a few minutes ago=20
there's a beta8 with many improvements.

On Windows Arthur and I are currently using MinGW in the Msys=20
environment (though Arthur is interested in trying the Microsoft C++=20
compiler instead). On both Windows and Ubuntu I'm following the=20
instructions in INSTALL.txt, which have been significantly simplified=20
for Windows thanks to Arthur.

You are correct that there is some leftover irrelevant stuff having to=20
do with the fact that at one point Jonathan Brandmeyer investigated=20
using scons instead of more traditional build tools.

Bruce Sherwood

Dethe Elza wrote:

>On 30-Nov-06, at 5:52 AM, Arthur wrote:
>
> =20
>
>>I am concerned that you are working not at the bleeding edge, but =20
>>beyond
>>it a bit. And are trying to solve problems that shouldn't be yours =20
>>- in
>>that beta8 is a work in progress that has been focusing not only on
>>numpy compatibility but on some Windows specific build issues, and =20
>>that
>>there has been some futzing with Makefile.in (that I think Bruce =20
>>checked
>>in) that address those, but without, at the moment, thinking =20
>>through the
>>crossplatform implications, mainly because we haven't finalized =20
>>what the
>>keepers are, even for Windows.
>>   =20
>>
>
>I was trying to build from the beta5 tarball, but the files Martin =20
>was using weren't in it (there are several build tools involved--not =20
>sure how/where pycompile, scons, or mkdist_osx.sh enter into the =20
>process (are they used, or just cruft left from earlier builds?).  On =20
>the other hand, now that I have gotten it to build and run (see my =20
>reply to Martin following this), I can try to repeat the process from =20
>the beta5 tarball, or selectively roll back what I have checked out =20
>from CVS.
>
> =20
>
>>That being said, I think Bruce successfully did a Linux build from the
>>cvs as late as yesterday with no apparent problems.
>>   =20
>>
>
>Excellent.  Bruce, if you're reading this, could you give me some =20
>insight into which of the build tools you're using?
>
> =20
>
>>Coming in late, but looking at your build log where everything looks
>>rather sensible.
>>
>>Is it clear where -lboost_python -lboost_thread are being found.
>>   =20
>>
>
>Martin had given me the key to this in an earlier message, but I had =20
>missed it.  Got it now.
>
> =20
>
>>Presumably you are using a binary distro of these libs that are =20
>>placing
>>them somewhere standard.  I mention it because when I have built those
>>libraries, on Linux, or Windows I have had to handle them with kid
>>gloves, re: naming and install issues.
>>   =20
>>
>
>I'm using Fink to build all of the libs.
>
> =20
>
>>Beyond those clues, which might not be clues, don't have a clue =20
>>what you
>>might be running into.
>>   =20
>>
>
>It's all helpful.  Thanks, Art!
>
> =20
>
>>Art
>>   =20
>>
>
>--Dethe
>
>values of =CE=B2 will give rise to dom --Unix prehistory
>
>
>
>------------------------------------------------------------------------=
-
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share =
your
>opinions on IT & business topics through brief surveys - and earn cash
>http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
>_______________________________________________
>Visualpython-users mailing list
>Vis...@li...
>https://lists.sourceforge.net/lists/listinfo/visualpython-users
> =20
>

Re: [Visualpython-users] VPython on OS X, steps forward and otherwise

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

On 30-Nov-06, at 3:34 PM, Bruce Sherwood wrote:

> I'm not using any special build tools. But as of a few minutes ago
> there's a beta8 with many improvements.

Excellent, I'll check it out.

> On Windows Arthur and I are currently using MinGW in the Msys
> environment (though Arthur is interested in trying the Microsoft C++
> compiler instead). On both Windows and Ubuntu I'm following the
> instructions in INSTALL.txt, which have been significantly simplified
> for Windows thanks to Arthur.

Yay Art!

> You are correct that there is some leftover irrelevant stuff having to
> do with the fact that at one point Jonathan Brandmeyer investigated
> using scons instead of more traditional build tools.

Glad to know I was doing the right thing by ignoring scons.

Thanks for the feedback, Bruce.

--Dethe


Ninety percent of the technology hasn't even been developed yet. -- 
Tim Armstrong, Google