problem with mixinVector in OSG 2.6

[GoogleCodeExporter]

Befor complaining I just wish to thank you for this work, and congratulate
you for the nice and easy to install package :-)

What steps will reproduce the problem?
1. I set all path so a the simple demo works well
2. I run : python pyramid.py 

What is the expected output? What do you see instead?
I get the following error (full traceback)

Traceback (most recent call last):
  File "pyramid.py", line 24, in <module>
    lineVertices.push_back(osg.Vec3(-10,10,0))
  File "/home/at216043/Logiciels/pyOSG/build/lib/python/osg.py", line
13902, in <lambda>
    __getattr__ = lambda self, name: _swig_getattr(self, Vec3Array, name)
  File "/home/at216043/Logiciels/pyOSG/build/lib/python/osg.py", line 34,
in _swig_getattr
    raise AttributeError,name
AttributeError: push_back

What version of the product are you using? On what operating system?
I'm using rev 169 with OpenSeneGraph 2.6.0, swig 1.3 on a Ubuntu 8.04 64
bit system.

Please provide any additional information below.
The following examples run smoothly : 
osgviewerGTK.py simpleosg.py

Original issue reported on code.google.com by anthony.truchet@gmail.com on 25 Sep 2008 at 5:05

[GoogleCodeExporter]

I've investigated a bit... There seems to lack in osg.i some lines of the form :
%template(mixinVectorVec2)      osg::MixinVector<osg::Vec2f>;

But when I add these I get a compile time error from GCC :

[  1%] Building CXX object src/python/CMakeFiles/_osg.dir/osgPYTHON_wrap.o
/usr/bin/c++   -D_osg_EXPORTS   -fPIC -I/usr/local/include
-I/home/at216043/Logiciels/pyOSG/include -I/usr/include/python2.5   -o
src/python/CMakeFiles/_osg.dir/osgPYTHON_wrap.o -c
/home/at216043/Logiciels/pyOSG/src/python/osgPYTHON_wrap.cxx
/usr/local/include/osg/MixinVector: In function «PyObject*
_wrap_new_mixinVectorVec2__SWIG_3(PyObject*, PyObject*)»:
/usr/local/include/osg/MixinVector:30: erreur: «typedef class 
std::vector<osg::Vec2f,
std::allocator<osg::Vec2f> > osg::MixinVector<osg::Vec2f>::vector_type» is 
private
/home/at216043/Logiciels/pyOSG/src/python/osgPYTHON_wrap.cxx:136809: erreur: à
l'intérieur du contexte

The whole log is in attachement.
The only (and quite old) track I've found is related to public vs private 
typedef...
but I can't see the link with what SWIG generates :-(
(http://gcc.gnu.org/ml/gcc-prs/2000-q2/msg00073.html)

Any suggestion ?

Original comment by anthony.truchet@gmail.com on 26 Sep 2008 at 4:35

Attachments:

• make2.log

[GoogleCodeExporter]

Dear Antony,
only now I noticed your bugreport after one of my colleagues reported similar 
issues.
I was held back to osg 2.4 up till now, so I hope to come up with a workaround 
for
this issue in osg 2.6
will keep you updated,
Gerwin

Original comment by gerwinde...@gmail.com on 14 Oct 2008 at 12:05

[GoogleCodeExporter]

Ok, it seems this is serious bug and a setback for stepping up to osg 2.6.
Currently I do not see a simple workaround, but I must say swig already made my 
head
explode a couple of times. I see three options:

 * Copy std_vector.i things to work with MixinVectors directly
http://www.swig.org/Doc1.3/Library.html#Library_nn15 

 * Trick SWIG into thinking a MixinVector is actually just a std::vector.

 * Modify source code of osg to typedef MixinVector as a std::vector (but it might
break other stuff)

Original comment by gerwinde...@gmail.com on 14 Oct 2008 at 2:59

[GoogleCodeExporter]

Dear Gerwin,

Unfortunately I don't have any experience or expertise at this level of SWIG 
usage...

The third point seems very risky and implied OSG itself which is not a good 
thing.

In case MixinVectors are "sub-concept" of std::vector the second point might be
interesting but I don't have the slightest idea about how to do it :(

I'm sorry this bug seems so serious...

Original comment by anthony.truchet@gmail.com on 14 Oct 2008 at 3:06

[GoogleCodeExporter]

For those interested,
I posted a question on the SWIG mailing list for this one:

http://sourceforge.net/mailarchive/forum.php?thread_name=715518200810140958w7531
a1e8t9e46d06cadedbbf%40mail.gmail.com&forum_name=swig-user

Original comment by gerwinde...@gmail.com on 15 Oct 2008 at 12:23

[GoogleCodeExporter]

FYI, This is the response from the swig mailing list

From your link above you are supporting Python, Ruby, Java and Lua. The 
std::vector
library files are quite different for each and support different aspects of
std::vector. Replicating all could be quite hard unless you just do a copy 
paste kind
of approach of the SWIG std::vector library for each of these target languages. 
The
easiest is probably to run SWIG -E on std_vector.i and copy paste and change 
std to
osg and vector to MixinVector. You'll see that there is a lot of code developed 
for
some of these target languages and you could provide a much simpler cut down 
api,
something similar to the Java approach, see Lib/java/std_vector.i.

Original comment by gerwinde...@gmail.com on 14 Nov 2008 at 3:35

[GoogleCodeExporter]

Original comment by gerwinde...@gmail.com on 30 Dec 2008 at 9:30

• Changed title: _problem with mixinVector in OSG 2.6 _
• Changed state: Accepted
• Added labels: Maintainability, OpSys-All

[GoogleCodeExporter]

Has a decision been made on how to move forward with this issue?  Is the SWIG 
mailing
list preprocessing suggestion viable?

Original comment by mday...@gmail.com on 28 Apr 2009 at 3:46

[GoogleCodeExporter]

I tried once, but failed ... One really needs to get into SWIG internals for 
this
one. The thing one could try is:
Just before the swig wrapping generation, "replace" the Array include file 
(e.g. 2.6+
version with the mixinvector stuff) with an older version of the Array include 
file
(e.g. 2.4 version without the mixinvector stuff). Then hope that stuff can be 
linked :-)

I have no time for at least the coming month, although I have been discussing 
with
Hartmut (other developer) to get together and make a "real" version...

Original comment by gerwinde...@gmail.com on 29 Apr 2009 at 6:51

[GoogleCodeExporter]

After reading this issue (and issue 25) I am a bit confused. I have just built
osgswig for osg 2.8 and my code which references osg.Vec3Array no longer works. 
Is
there some way to do the same thing in Python given the current limitations or 
is
this a complete no-go with the MixinVector problems.

Original comment by joekil...@gmail.com on 24 Jul 2009 at 10:36

[GoogleCodeExporter]

@joekilner, I'm sorry to say there I am currently not aware of a fix for osg 
2.6+ and
osg.Vec3Array. I too really want to get this problem out of the way! I now have 
some
time on my hands to start addressing this and other osgswig issues, so I hope 
to get
some results in the coming weeks.

Original comment by gerwinde...@gmail.com on 24 Jul 2009 at 11:21

[GoogleCodeExporter]

If anyone else is in my situation and needs a quick hack to fix a particular 
problem
you might be interested in using scipy.weave. This allows you to inline C++ 
code like
this:

import scipy.weave

mesh2osgCode = """
osg::Geometry *tri_geometry = (osg::Geometry *)pGeom;
osg::Vec3Array *verts = new osg::Vec3Array();
// Some C++ code goes here...
tri_geometry->setVertexArray(verts);
"""

tri_geometry = osg.Geometry()
pGeom = int(tri_geometry.this)
v = mesh.vertices
scipy.weave.inline(mesh2osgCode,["v","pGeom"],headers=["<osg/Geometry>"],librari
es=["osg"])

I would only suggest using this if you are know what you are doing or don't mind
memory leaks, but when it works it is a real life-saver!

Original comment by joekil...@gmail.com on 24 Jul 2009 at 4:03

[GoogleCodeExporter]

I tried to "replace" the Array and Primitiveset include files (e.g. 2.6+
version with the mixinvector stuff) with an older version (e.g. 2.4 version 
without
the mixinvector stuff). Rebuilt osg and osgswig, and hope for the best. 

For now, it seems to work! I am running osg 2.8.2 with osgswig and VecArray 
support!

Will get back here later to submit changes in osg.i, the header files and maybe 
some
way to patch an osg installation.

Original comment by gerwinde...@gmail.com on 28 Jul 2009 at 5:48

• Changed state: Started

[GoogleCodeExporter]

closed some time ago, joekilner proposed the changes for MixinVector that 
allowed us to continue beyond osg 2.4:
http://code.google.com/p/osgswig/source/detail?r=c7c6fa9e23ba69538bf416b0c28641e
28c1fdccf

Original comment by gerwinde...@gmail.com on 21 Mar 2011 at 9:58

• Changed state: Fixed