pygccxml-development Mailing List for C++ Python language bindings

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Pygccxml

https://bitly.com/3lb36SH

Pygccxml

https://j.mp/3jVqBNP

Pygccxml          https://bitly.com/3wFVb2L          

Pygccxml
Â 
Â 
https://j.mp/37Ui1K7
Â 
Â 
Â 
Â 

Pygccxml
Â 
Â 
https://bit.ly/36hbkRa
Â 
Â 
Â 
Â 

Â 

Pygccxml
Â 
Â 
https://bitly.com/3potjwh
Â 
Â 
Â 
Pygccxml    https://j.mp/2PK4rPK

Pygccxml
Â 
Â 
http://bit.ly/2MdI1oQ
Â 
Â 
Â 
Â 
Â 
Â  PygccxmlÂ  Â  Â  https://clck.ru/HoBNL Â  Â  Â 
hi pygccxml

http://meister-roofing.com/forgot.php?brown=175uv6f0rwnphpd

Yours Truly

hey pygccxml

http://cocaine-recovery-private.com/attached.php?action=u15vmbv9g27w

Hi pygccxml

http://fishercatsdaily.com/widely.php?sand=guc9hd6h4gew4

Franu00e7ois du Vignaud

Sent from my iPhone

Thank you for problem & solution contribution :-)

On Tue, Aug 2, 2011 at 11:31 PM, Scott Sturdivant <sc...@bi...> wrote:
> As a follow on, I did get this to work by using an actual list, and not a
> pointer to one.  So the pseudocode becomes:
>
> #pramga once
> #ifndef __GCCXML__
> #include <boost/python.hpp>
> typedef boost::python::list list;
> #else
> class list {};
> #endif
>
> class MyClass {
>   public list mylist;
>   MyClass() { mylist.append(1); }
> };
>
> Then in python, I have no problems:
>
>>>> mc.mylist
> [1]
>>>> mc.append(2)
>>>> mc.mylist
> [1,2]
>
> Thanks,
>
> Scott
>
>
> On Mon, 1 Aug 2011, Scott Sturdivant wrote:
>
>> Hi,
>>
>> I'd like to have a class which as a boost::python::list as a public
>> attribute.  I know that gccxml cannot parse boost/python.hpp, so given a
>> suggestion on the mailing list archives, I have done the following:
>>
>> #pragma once
>> #ifndef __GCCXML__
>> #include <boost/python.hpp>
>> typedef boost::python::list list;
>> #else
>> class list;
>> #endif
>>
>> class MyClass {
>>  public:
>>    list * mylist;
>> };
>>
>> MyClass::MyClass()
>> {
>>  mylist = new boost::python::list();
>>  mylist.append(1);
>> }
>> MyClass::~MyClass()
>> {
>>  delete mylist;
>> }
>>
>> Py++ is able to create the bindings and it compiles fine.  However, when
>> accessing the 'mylist' attribute in python, I'm seeing the following
>> behavior:
>>
>>>>> print type(myclass.mylist)
>>
>>>>> print type(myclass.mylist)
>> Traceback (most recent call last):
>>  File "<stdin>", line 1, in <module>
>> TypeError: cannot create weak reference to 'list' object
>>>>> print type(myclass.mylist)
>> Fatal Python error: GC object already tracked
>> Aborted
>>
>> I think I'm going about this the wrong way, but am unsure of the proper way.
>> Would this be a use case for the 'inserting_code' functionality of py++?
>>
>> Thank you!
>>
>> Scott
>>
>
> ------------------------------------------------------------------------------
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> pygccxml-development mailing list
> pyg...@li...
> https://lists.sourceforge.net/lists/listinfo/pygccxml-development
>

As a follow on, I did get this to work by using an actual list, and not a 
pointer to one.  So the pseudocode becomes:

#pramga once
#ifndef __GCCXML__
#include <boost/python.hpp>
typedef boost::python::list list;
#else
class list {};
#endif

class MyClass {
   public list mylist;
   MyClass() { mylist.append(1); }
};

Then in python, I have no problems:

>>> mc.mylist
[1]
>>> mc.append(2)
>>> mc.mylist
[1,2]

Thanks,

Scott

On Mon, 1 Aug 2011, Scott Sturdivant wrote:

> Hi,
>
> I'd like to have a class which as a boost::python::list as a public 
> attribute.  I know that gccxml cannot parse boost/python.hpp, so given a 
> suggestion on the mailing list archives, I have done the following:
>
> #pragma once
> #ifndef __GCCXML__
> #include <boost/python.hpp>
> typedef boost::python::list list;
> #else
> class list;
> #endif
>
> class MyClass {
>  public:
>    list * mylist;
> };
>
> MyClass::MyClass()
> {
>  mylist = new boost::python::list();
>  mylist.append(1);
> }
> MyClass::~MyClass()
> {
>  delete mylist;
> }
>
> Py++ is able to create the bindings and it compiles fine.  However, when 
> accessing the 'mylist' attribute in python, I'm seeing the following 
> behavior:
>
>>>> print type(myclass.mylist)
>
>>>> print type(myclass.mylist)
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
> TypeError: cannot create weak reference to 'list' object
>>>> print type(myclass.mylist)
> Fatal Python error: GC object already tracked
> Aborted
>
> I think I'm going about this the wrong way, but am unsure of the proper way. 
> Would this be a use case for the 'inserting_code' functionality of py++?
>
> Thank you!
>
> Scott
>

Hi,

I'd like to have a class which as a boost::python::list as a public 
attribute.  I know that gccxml cannot parse boost/python.hpp, so given a 
suggestion on the mailing list archives, I have done the following:

#pragma once
#ifndef __GCCXML__
#include <boost/python.hpp>
typedef boost::python::list list;
#else
class list;
#endif

class MyClass {
   public:
     list * mylist;
};

MyClass::MyClass()
{
   mylist = new boost::python::list();
   mylist.append(1);
}
MyClass::~MyClass()
{
   delete mylist;
}

Py++ is able to create the bindings and it compiles fine.  However, when 
accessing the 'mylist' attribute in python, I'm seeing the following 
behavior:

>>> print type(myclass.mylist)

>>> print type(myclass.mylist)
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
TypeError: cannot create weak reference to 'list' object
>>> print type(myclass.mylist)
Fatal Python error: GC object already tracked
Aborted

I think I'm going about this the wrong way, but am unsure of the proper 
way.  Would this be a use case for the 'inserting_code' functionality of 
py++?

Thank you!

Scott

On Sat, Jul 23, 2011 at 5:28 AM, Scott Sturdivant <sc...@bi...> wrote:
>
> Hi,
> Is it possible to have py++ understand a vector of vectors?

If I remember right, such functionality does not exist

>
> Alternatively, is there a mechanism to support multi-dimensional arrays?

Almost. Py++ has some functionality in place for integration with
ctypes, but it only works with POD types.

HTH

Hi,

Is it possible to have py++ understand a vector of vectors?  I have the
following C++ code:

vtest.h:

class Foo {
public:
    int doStuff(void) { return 1; }
};

class VectorTest {
public:
    VectorTest(void);
    std::vector<std::vector<Foo *> > foo;
};

vtest.cpp:

VectorTest::VectorTest(void)
{
    for (int i = 0; i < 2; i++)
    {
        foo.push_back( std::vector<Foo *> () );
        for (int j = 0; j < 2; j++)
        {
            foo[i].push_back ( new Foo() );
        }
    }
}

After undergoing the binding process, the usage in python results in the
following:

>>> import vectortest
>>> v = vectortest.VectorTest()
>>> v.foo[0][0]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: No Python class registered for C++ class std::vector<Foo*,
std::allocator<Foo*> >

Alternatively, is there a mechanism to support multi-dimensional arrays?

Thank you for your help!

Scott

Hi,

I'm in the process of creating a binding for a third party library using
py++ but have encountered a problem whereby the partial_decl_string of
function argument seems incorrect. The function full declaration string
is...

'void ( *test_function_type )(
::__gnu_cxx::__normal_iterator<Imath::Vec3<int> const*,
std::vector<Imath::Vec3<int>, std::allocator<Imath::Vec3<int> > > >
&,::std::vector<Imath::Vec3<int>, std::allocator<Imath::Vec3<int> > > & )'

while the partial declaration string is

'void ( *test_function_type )( ::__gnu_cxx::__normal_iterator< Imath::Vec3<
int >, std::vector< Imath::Vec3<int> > > &,::std::vector< Imath::Vec3<int> >
& )'

note that the const* from the first argument is gone. Is this the correct
behaviour ?

The generated cpp code seems to use the partial_decl_string and does not
compile. I think this is because of the missing const*, which is being lost
in the function pygccxml.declarations.class_declaration.get_partial_name.

from pygccxml.declarations import class_declaration
name = "'__normal_iterator<Imath::Vec3<int> const*,
std::vector<Imath::Vec3<int>, std::allocator<Imath::Vec3<int> > > >"
print class_delaration.get_partial_name(name)
>>> '__normal_iterator< Imath::Vec3< int >, std::vector< Imath::Vec3<int> >
>'

Is there anyway to use decl_string instead of the partial one when
generating the code ?

thanks alot,
Babak

Hello

On Mon, Jun 13, 2011 at 9:39 PM, Babak Khataee <bab...@gm...> wrote:

> Hi There,
>
> I've come across what might be an unusual problem involving py++ generated
> boost python code that I was hoping someone might be able to help me with.
>
> We're using py++ to create python bindings for two libraries, one third
> party (libA)  and the other in house (libB - which has a dependency on
> libA). The two libraries both define a class called 'Box2f' which is being
> exposed in both bindings. Before importing the bindings into python we set
> the dlopen flags to be 'RTLD_GLOBAL | RTLD_NOW' to avoid cross module
> problems. Due to the dependency between the two libA needs to be imported
> first. Doing so defines and calls the registration function for the Box2f
> class, now when libB is imported it calls the same Box2f registration
> function rather its own one.

Are you sure?

> This means that libAbinding.Box2f is the same as libBbinding.Box2f :(
>
> It seems that the binding code for both libraries defines a
> 'register_Box2f_class' function and that renaming this in either library
> binding code fixes the problem. However, I was wondering if there is a way
> change the name of the function that gets generated through  py++ ? I've had
> a peek around the code and got the impression that by creating a custom
> 'multiple_files_t' class I could control this behaviour, but I wasn't sure
> whether this would be a good approach or not ?
>
> An alternative would be to just change the name of the classes in the
> binding so they're not the same, but if possible we'd rather avoid
> introducing differences between the binding and library code.
>

I think your analysis has a mistake.  'RTLD_GLOBAL | RTLD_NOW' causes
Boost.Python registry (the component, which keeps the registered classes,
functions, conversions and etc) to be defined only once and shared between
all extension modules. In my opinion, what happens is that you are trying to
register class with the same name and Boost.Python skips the second
definition. (You should get the warning, during your extension import).

I think, what you can do is to change the classes aliased, import them into
Python and then to provide a new alias, which is the original name,

mb = module_builder_t(...)
mb.class_('Box2f').alias = "LibBBox2f"

libB/
    __init__.py
    libbbinding.so

where __init__.py content is something like:

import * from libbbinding
Box2f = LibBox2f

> Hopefully that makes sense, any advice/help with this would be greatly
> appreciated.
> Thank you very much.
>
> HTH

Hi There,

I've come across what might be an unusual problem involving py++ generated
boost python code that I was hoping someone might be able to help me with.

We're using py++ to create python bindings for two libraries, one third
party (libA)  and the other in house (libB - which has a dependency on
libA). The two libraries both define a class called 'Box2f' which is being
exposed in both bindings. Before importing the bindings into python we set
the dlopen flags to be 'RTLD_GLOBAL | RTLD_NOW' to avoid cross module
problems. Due to the dependency between the two libA needs to be imported
first. Doing so defines and calls the registration function for the Box2f
class, now when libB is imported it calls the same Box2f registration
function rather its own one. This means that libAbinding.Box2f is the same
as libBbinding.Box2f :(

It seems that the binding code for both libraries defines a
'register_Box2f_class' function and that renaming this in either library
binding code fixes the problem. However, I was wondering if there is a way
change the name of the function that gets generated through  py++ ? I've had
a peek around the code and got the impression that by creating a custom
'multiple_files_t' class I could control this behaviour, but I wasn't sure
whether this would be a good approach or not ?

An alternative would be to just change the name of the classes in the
binding so they're not the same, but if possible we'd rather avoid
introducing differences between the binding and library code.

Hopefully that makes sense, any advice/help with this would be greatly
appreciated.
Thank you very much.
Babak

On Mon, Mar 14, 2011 at 10:07 PM, Scott Sturdivant <sc...@bi...> wrote:
> Hi Roman,
>
> Thanks for the suggestion, but unfortunately I get the error that the
> attribute '__doc__' of 'instacemethod' objects is not writeable.  No doubt
> this is due to my constructor being private as the class is not to be
> instantiated from python, only the methods are to be used.
>
> I guess unless I change the ctor to be public, I'm stuck without docstrings
> for virtual methods?

I don't think this is related to a private constructor. I thought,
these is what was done in Python-Ogre project.
Let me take a look once again on the project and I will back to you
with the answer.

>
> Thank you for your help,

You are welcome :-)

Hi Roman,

Thanks for the suggestion, but unfortunately I get the error that the 
attribute '__doc__' of 'instacemethod' objects is not writeable.  No doubt 
this is due to my constructor being private as the class is not to be 
instantiated from python, only the methods are to be used.

I guess unless I change the ctor to be public, I'm stuck without 
docstrings for virtual methods?

Thank you for your help,

Scott

On Mon, 14 Mar 2011, Roman Yakovenko wrote:

> On Mon, Mar 14, 2011 at 4:50 PM, Scott Sturdivant <sc...@bi...> wrote:
>>
>> Hi again py++ friends,
>
> Good evening
>
>>
>> I had a question concerning docstrings for virtual methods.  For a normal method, my docstring extractor is working great, resulting in bindings that generate looking like this:
>>
>>         .def(
>>             "disableDebug"
>>             , (void ( ::myManager::* )(  ) )( &::myManager::disableDebug )
>>             , "disableDebug()\nDisable debug, returning the logging output to a sane level.")
>>
>> However, if the method is virtual, the generated wrapper looks more like this:
>>
>>         .def(
>>             "getFoo"
>>             , (double ( ::myManager::* )(  ) )(&::myManager::getFoo)
>>             , (double ( myManager_wrapper::* )(  ) )(&myManager_wrapper::default_getFoo) );
>>
>> In the call to the actual wrapper, no where is my method's documentation present.  Is this a limitation of py++, or of boost python?
>
> At the time, I implemented that feature, Boost.Python did not support
> docstring for them. What you can do is to generate a small Python
> module, with doc strings and inject them into the method:
>
> import foo
> foo.myManager.getFoo.__doc__ = <what ever>
>
> Than just ensure to import this module, right after the extension:
> http://www.boost.org/doc/libs/1_46_1/libs/python/doc/tutorial/doc/html/python/techniques.html#python.extending_wrapped_objects_in_python
>
>> Thanks!
>
> You are welcome.
>
On Mon, Mar 14, 2011 at 4:50 PM, Scott Sturdivant <sc...@bi...> wrote:
>
> Hi again py++ friends,

Good evening

>
> I had a question concerning docstrings for virtual methods.  For a normal method, my docstring extractor is working great, resulting in bindings that generate looking like this:
>
>         .def(
>             "disableDebug"
>             , (void ( ::myManager::* )(  ) )( &::myManager::disableDebug )
>             , "disableDebug()\nDisable debug, returning the logging output to a sane level.")
>
> However, if the method is virtual, the generated wrapper looks more like this:
>
>         .def(
>             "getFoo"
>             , (double ( ::myManager::* )(  ) )(&::myManager::getFoo)
>             , (double ( myManager_wrapper::* )(  ) )(&myManager_wrapper::default_getFoo) );
>
> In the call to the actual wrapper, no where is my method's documentation present.  Is this a limitation of py++, or of boost python?

At the time, I implemented that feature, Boost.Python did not support
docstring for them. What you can do is to generate a small Python
module, with doc strings and inject them into the method:

import foo
foo.myManager.getFoo.__doc__ = <what ever>

Than just ensure to import this module, right after the extension:
http://www.boost.org/doc/libs/1_46_1/libs/python/doc/tutorial/doc/html/python/techniques.html#python.extending_wrapped_objects_in_python

> Thanks!

You are welcome.

Hi again py++ friends,

I had a question concerning docstrings for virtual methods.  For a normal
method, my docstring extractor is working great, resulting in bindings that
generate looking like this:

        .def(
            "disableDebug"
            , (void ( ::myManager::* )(  ) )( &::myManager::disableDebug )
            , "disableDebug()\nDisable debug, returning the logging output
to a sane level.")

However, if the method is virtual, the generated wrapper looks more like
this:

        .def(
            "getFoo"
            , (double ( ::myManager::* )(  ) )(&::myManager::getFoo)
            , (double ( myManager_wrapper::* )(  )
)(&myManager_wrapper::default_getFoo) );

In the call to the actual wrapper, no where is my method's documentation
present.  Is this a limitation of py++, or of boost python?

Thanks!

Scott

On Tue, Mar 8, 2011 at 6:30 AM, Scott Sturdivant <sc...@bi...> wrote:
> Hi Roman,

Good morning.

> Thanks, I was not aware about the dlopen flags.  Still not entirely sure
> what they do, but preliminary investigation indicates that they solve the
> problem.
> Indeed, I was planning to create my __init__.py and file structure layout
> such that this would be a common exception handler that my other extensions
> could put into their init files something along the lines of "from
> MyPkg.common import myexceptions".  What I had provided as the example was
> just a small 'quick and dirty' way to demonstrate the problem.
> I am curious as to why I need the flags on one machine but not the other,
> but like you say, gcc is certainly different (one is a modern, up to date
> linux distribution, the other is an antiquated red hat enterprise 5 box).

Boost.Python contains registry of classes (more-or-less), in case of
multi-module development there should be only 1 instance of it,
otherwise the conversion will not work. The flags, you used for
dlopen( the function which is called by Python t load shared library
), makes this happen.

> Thank you for your help!  So far it's looking good.

You are welcome.

2006	Jan	Feb (6)	Mar (160)	Apr (96)	May (152)	Jun (72)	Jul (99)	Aug (189)	Sep (161)	Oct (110)	Nov (9)	Dec (3)
2007	Jan (13)	Feb (48)	Mar (35)	Apr (7)	May (37)	Jun (8)	Jul (15)	Aug (8)	Sep (2)	Oct (1)	Nov (2)	Dec (38)
2008	Jan (11)	Feb (29)	Mar (17)	Apr (3)	May	Jun (64)	Jul (49)	Aug (51)	Sep (18)	Oct (22)	Nov (9)	Dec (9)
2009	Jan (28)	Feb (15)	Mar (2)	Apr (11)	May (6)	Jun (2)	Jul (3)	Aug (34)	Sep (5)	Oct (7)	Nov (13)	Dec (14)
2010	Jan (39)	Feb (3)	Mar (3)	Apr (14)	May (11)	Jun (8)	Jul (9)	Aug	Sep	Oct	Nov	Dec
2011	Jan	Feb	Mar (7)	Apr	May	Jun (3)	Jul (3)	Aug (3)	Sep	Oct	Nov	Dec
2015	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (1)	Sep	Oct	Nov	Dec (2)
2016	Jan (1)	Feb (1)	Mar	Apr (1)	May	Jun	Jul (1)	Aug (1)	Sep	Oct	Nov (1)	Dec
2019	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (1)	Sep	Oct	Nov	Dec (1)
2020	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (1)	Sep	Oct	Nov	Dec (1)
2021	Jan (1)	Feb (1)	Mar	Apr	May (1)	Jun	Jul	Aug	Sep (1)	Oct (1)	Nov	Dec