[Edu-sig] Vpython 4.0

Arthur ajsiegel at optonline.net
Sun Nov 5 14:42:50 CET 2006


Dethe Elza wrote:

> Hi Art,
>
> I've been following your VPython adventures with interest, but am  
> pretty tied up right now (article draft overdue for IBM and a big  
> release coming at work).  On OS X the 4.0 beta won't even finish  
> configure, much less build.

Yeah, fitting this kind of stuff in can be tough.  I had been traveling 
overseas alot over the last few weeks, and getting some grounding in the 
Vpython C++ code and working on the numpy compatibility issue (which, as 
opposed to the issues related to the wndowing code, is a pretty 
straightforward matter)  was a perfect way to kill time on flights and 
airport layovers.

> <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
> </error>

Yeah, all that just to get the GTK++ windowing. Ultimately there should 
be an option to build just as far as the display_kernel, which would  
make all these dependencies go away.  Though one still needs to deal 
with the Boost dependencies, which I don't think ./configure checks 
for.  In fact VPython4.xxx extends the boost dependencies beyong 
Boost.Python, and into the Boost.Threading library.  Debian/ubuntu has  
binary distributions of the boost libraries which install painlessly. 
Thankfully, because understanding the boost native build and install 
system can be painful. I have spent enough hunt and peck time with it 
over the last few weeks though, that I think I finally have the issues 
under some control.   And I do see that Boost.build does recognize the 
use of the darwin toolset as a build option, so the dependency on it 
should not be a barrier to a native OS X distribution. As I see it, 
Boost is pretty major stuff, and certainly don't think it reasonable to 
consider vpython's dependeny on it as a deal killer in any way, beyond 
it being a deal killer for inclusion in the Python standard library, 
particularly once the dependencies extend beyond Boost.Python. That 
disappoints me some, but probably saves me a losing battle.

One dependency decision that Jonathan made with which I think I disagree 
is that of using the sigc++ libraries. It is part of the GTK toolchain, 
and creates build complications on Windows, and I suspect it will do so 
on OS X native, as well.  In fact Boost.Signals and sigc++ have similar 
functionality and I believe there is a viable alternative to move to 
that, and thereby limit the overall dependencies to the Boost 
libraries.  The issue might also go away, because I see that the C++ 
authorities are looking at combining the best of the sigc++ and 
Boost.Signals ideas and make it part of the C++ standard library. 

Was kind of looking for a Winter project, and if I want to get to the 
next stage of sophistication with PyGeo's possiblities I probably need 
to become a vpython guru.

We'll see how far I get.  But so far, its a learning curve I am enjoying.

Art


> I've tried to get these installed via fink, but no luck so far.   
> Admittedly, I haven't put a lot of time into it yet, but I have taken  
> a few stabs.
>
> If I can get it to build, I'd happily work on getting it working.  I  
> get frustrated when I'm stuck in the configure stage.
>
> --Dethe
>
>
> Young children play in a way that is strikingly similar to the way  
> scientists work --Busytown News
>
>
>
>




More information about the Edu-sig mailing list