Re: [cgkit-user] cgkit on Ubuntu 8.10

[Matthias B. <mat...@gm...>]

Tauscher wrote:
> Hi Matthias,
> 
>> What version of cgkit is this (alpha8)?
> Yes, this is alpha8, but I also tried last cvs version with similiar 
> result.
> 
>> Is your OS 32bit or 64bit?
> It's a 32bit OS.
> 
>> Is there anything "special" about your system
> I don't think so, it's standard ubuntu install - I tried on my laptop as 
> well as on a desktop computer.
> 
>> Where does the Boost library come from
> Prebuild version for python 2.5 from the ubuntu repository installed 
> using the synaptic package manager. All ependencies should be fulfilled.
> 
>> Was there any warning when building the C++ support library or the 
>> wrappers?
> Yes, a lot - I append the logfile.

All those warnings about the format specifier shouldn't matter anyway. 
These are used to print some information when debugging output is 
enabled. There should be fewer warnings if you use the svn version (I 
thought I got rid of them, but apparently newer versions of gcc are more 
picky again). But I don't think this has anything to do with your 
problem (especially as you are on a 32bit system where ints, longs and 
pointers have the same size anyway).

>> Which optional libraries did you include in the build (lib3ds, 
>> CyberX3D, ...)?
> I have included none of them.
> 
>>  >>> import cgkit._core
> This does work.

So as this works, it means building the C++ library and the Python 
module did work fine and it can be imported and used. I suppose if you 
try using something from that module it will work as well. For example:

 >>> import cgkit._core
 >>> v=cgkit._core.vec3(1,2,3)
 >>> print v
(1, 2, 3)

So this suggests there is a genuine bug somewhere in the code. 
Unfortunately, I can't reproduce the crash here (everything runs fine on 
Fedora 6, OSX Tiger and WinXP).
The only difference I see between our systems is the version of gcc. You 
are using 4.3.2 whereas the newest version I have access to is 4.1.2.

>> If this should succeed, can you try importing individual modules 
>> instead of cgkit.all (such as cgkit.cgtypes)?
> Well, this also works.

All right, so we know that importing cgkit.all crashes whereas 
cgkit._core and some other modules can be imported fine.

Importing cgkit.all runs the script cgkit/all/__init__.py in the cgkit 
package which just does a lot of imports and assigns a few variables.
So could you try to figure out which of the imports actually triggers 
the segmentation fault? You could just add some prints and see how far 
it goes.
I hope this gets us nearer to the source of the problem.

>>> $ for i in test_*; do echo; echo _____________ $i ____________;
>>> python $i; done
>>
>> By the way, there is a script all.py which just does that.
> 
> Yes, I saw this and tried it, but the python interpreter quits after the 
> first segfaulted test, so the result isn't that verbose.

Oh, right, good point.

>> the next release will include those files.
> 
> By the way: When do you plan the next release? 

Actually, I was planning on getting out another release in the next few 
weeks (initially I was thinking end of February, but it rather looks 
like it will be early March).

> In the meantime I played 
> around a little bit with Soya3d, but I still would love to stick with 
> cgkit and I am glad to see, that there's still active development.

Thanks for your loyalty! :) I take it you want to use cgkit for 
interactive 3D stuff which, I have to admit, is not really cgkit's 
strong point. Packages that focus on being a game engine like Soya3D, 
Panda3D, PyOgre, etc. may actually be better suited for now. But having 
said that, I'm actually planning on improving cgkit's realtime rendering 
capabilities. I have already started with that but I think only some 
bits of that will make it into the upcoming release. The latest 
additions to the package are all on the RenderMan side, so this is 
nothing you would use in a realtime application.

Cheers,

- Matthias -