pygccxml-development

[pygccxml-development] container_traits.key_type() missing in 0.9.5

[Gustavo C. <gjc...@gm...>]

Hi, I am trying to scan std::map container types.  I need to obtain the key
and element types separately, but pygccxml (0.9.5) keeps fighting me
(below).  Wasn't there supposed to be a key_type method/attribute in the
container_traits classes?

Apparently key_type() method works well in SVN pygccxml.  Any idea when will
be next pygccxml release?


**************************** std::map< std::string, int > intTraceback (most
recent call last):
  File "../tests/foomodulegen-auto-split.py", line 57, in <module>
    my_module_gen()
  File "../tests/foomodulegen-auto-split.py", line 41, in my_module_gen
    gccxml_options=gccxml_options)
  File "/home/gjc/projects/pybindgen/trunk/pybindgen/gccxmlparser.py", line
551, in parse
    self.scan_types()
  File "/home/gjc/projects/pybindgen/trunk/pybindgen/gccxmlparser.py", line
730, in scan_types
    self._scan_namespace_types(self.module, self.module_namespace,
pygen_register_function_name="register_types")
  File "/home/gjc/projects/pybindgen/trunk/pybindgen/gccxmlparser.py", line
1160, in _scan_namespace_types
    self._register_container(module, traits, type_info, _outer_class, name)
  File "/home/gjc/projects/pybindgen/trunk/pybindgen/gccxmlparser.py", line
1318, in _register_container
    print >> sys.stderr, "****************************", name,
traits.element_type(definition), traits.key_type(definition)
AttributeError: class xxx_traits has no attribute 'key_type'


-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

Re: [pygccxml-development] Py++ typedef handling

[Patrick H. <pat...@pr...>]

On Apr 23, 2009, at 1:03 PM, Roman Yakovenko wrote:

> On Thu, Apr 23, 2009 at 8:01 PM, Patrick Hartling
> <pat...@pr...> wrote:
>> I have asked a couple of questions about typedef handling in the  
>> past, and I
>> have yet another one: is there anything that I can do to force Py++  
>> to use
>> the typedefs from the original code in function default argument  
>> values and
>> in instance method return types?
>
> I guess, it is possible to attach "pretty name" to a type and use it
> for code generation, but this is a huge change.

Is such an approach necessary, though? Since the type information  
identified by GCC-XML is the typedef, doesn't that mean that pygccxml  
or Py++ is "drilling down" to the un-aliased type in some cases?

>> What I see is that the typedef gets used in
>> some places but not others. I haven't identified a pattern to this  
>> yet, but
>> I am sure that there is one.
>
> Yes: http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/pyplusplus/decl_wrappers/decl_wrapper.py?revision=1664&view=markup
>
> Take a look on "_get_alias" method.

I have used the alias property in some cases. Does it apply to what I  
posted, though? If so, then I am not seeing the full extent of what  
opportunities exist for operating on Py++ objects. For example, how  
can the alias property be used to alter the type casting done for  
keyword argument values?

>> I have attached code that demonstrates the behavior that I see.  
>> test.cpp was
>> generated on Windows using Py++ 1.0 and GCC-XML (emulating Visual C+ 
>> + 9.0)
>> built from its CVS repository as of April 21, 2009. I have added  
>> comments to
>> the generated test.cpp where I see unexpected behavior. From  
>> looking at the
>> output generated by GCC-XML, I think I understand how the typedef
>> information used in template parameters gets lost, and that is  
>> unfortunate.
>> Maybe there is some room to improve GCC-XML in this area.
>
> It is very difficult. A year or two ago I tried to add something
> similar to GCCXML ad got lost in GCC code. May be you will have more
> luck.

I cannot make any promises, and it depends on how my work hours are  
allocated. I would like to see this addressed, though, and maybe I can  
make a case for devoting time to it.

>> In case it matters, the use of 64-bit integers in the example is  
>> deliberate.
>> Our code uses 64-bit types, and we use typedefs to mask the  
>> variation in the
>> type declaration depending on operating system and bit width of the  
>> binary
>> output. 64-bit integers are not the only type that has caused us  
>> problems,
>> but this is the one that crops up most consistently.
>
> You can do few tricks, before Py++ starts working:
> * rename classes and types
> * construct new types and typedefs
>
> It is not a nice way. If your code has some coding convention or other
> rules you can rely on, it should not be too difficult.
>
> Take a look on http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/examples/pyboost_dev/dev/date_time/generate_code.py?revision=1428&view=markup
> file.
> It contains code that does exactly this.
>
> Let me know if you need more help.


That pointer is helpful. It set me on a course where I have already  
resolved several of our most frustrating issues.

I have attached a small patch against the SVN trunk that makes a  
significant difference in generating more portable code--at least in  
our case. I have not yet run this change through the test suite (as I  
still have to learn how to run the test suite).

  -Patrick


--
Patrick L. Hartling
Senior Software Engineer, Priority 5
http://www.priority5.com/

The information transmitted in this communication is intended only for
the person or entity to which it is addressed and contains proprietary
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please destroy any copies, contact the sender
and delete the material from any computer.

Re: [pygccxml-development] Header path normalization and cross-platform code

[Roman Y. <rom...@gm...>]

On Thu, Apr 23, 2009 at 9:29 PM, Patrick Hartling
<pat...@pr...> wrote:
>> You also can replace both functions and submit the patch later :-)
>>
>> import pyplusplus
>>
>> def your_function( ..... ):
>>   <<< .... >>>
>>
>> pyplusplus.code_creators.module_t.replace_included_headers = <<<your
>> function>>>
>
>
> I will probably just proceed in this way for now.
>
> I haven't observed any
> problems by changing
> pyplusplus.code_creators.include_directories.include_directories_t.normalize()
> so that it does nothing except return the reference it is passed, but I have
> not tried the Py++ test suite to see if that change exposes bugs elsewhere.

It is a little bit broken now. I am working on fixing it.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] Header path normalization and cross-platform code

[Patrick H. <pat...@pr...>]

On Apr 23, 2009, at 12:37 PM, Roman Yakovenko wrote:

> On Thu, Apr 23, 2009 at 12:44 AM, Patrick Hartling
> <pat...@pr...> wrote:
>> I am working on setting up a development environment where team  
>> members can
>> run Py++ from Linux, Windows, or Mac OS X. Thus far, we have  
>> struggled to
>> get GCC-XML to handle our code on Windows, but we are getting very  
>> close to
>> having that resolved. In the process, I have come across some  
>> unexpected
>> behavior from Py++. Specifically, use of the static method
>> pyplusplus 
>> .code_creators.include_directories.include_directories_t.normalize()
>> produces code on Windows that will not compile on other platforms.  
>> For
>> example, if I have a class MyClass, Py++ on Windows generates code  
>> that
>> references the .hpp file as myclass.pypp.hpp. The generated file,  
>> however,
>> will be named MyClass.pypp.hpp. This won't work on a case-sensitive  
>> file system.
>
> Basically, in this moment you introduced a new use case to the
> project. This use case is problematic:
>
> 1. In many cases, the generated code could\will be a little bit
> different. For example, boost::date_time library uses different
> integer types to represent\keep time. The generated code will be
> different on Windows and on Linux.
>
> 2. Even if your generated code is ( could be ) same for all platforms,
> I cant promise you, that I will not break this feature in future - I
> don't enough resources to run such tests.
>
> In most cases, I deliver Py++ script which handles the differences
> between platforms and generates the code.
>
> If you need this feature, I suggest you to submit a patch - I will be
> glad to commit it.
>
>> The second issue is with the directory separator. If I use
>> pyplusplus.code_creators.module.module_t.replace_included_headers()  
>> and tell
>> Py++ to include a file such as <dir/SomeHeader.h>, the generated  
>> output on
>> Windows will reference <dir\someheader.h>. Again, the case- 
>> sensitive name is
>> lost, and the directory separator has changed to be one that only  
>> works when
>> building on Windows.
>
> What about Mac OS? Will '/' work on it too? ( I never worked on Mac. )

Yes.

>> Is there a specific need for header path normalization?
>
> If I remember right, Py++ has few functions ( don't remember what are
> they ), that work with paths. Introducing path "normalized" form
> greatly reduces bugs in that functions. I think, if you turn off
> normalize functionality, Py++ will introduce few bugs here and there.
>
> As with previous problem, if you submit the patch I'll gladly accept  
> it.
>
>> Under typical
>> circumstances, I would expect that the UNIX-style path would always  
>> work on
>> Windows. At the moment, I can't think of an example of when it  
>> would not. If
>> header path normalization cannot be removed, could an option be  
>> added to
>> pyplusplus.code_creators.include_directories.include_directories_t  
>> so that
>> the use of header path normalization can be turned off? Given that  
>> it is a
>> static method, a class variable for include_directories_t or a global
>> variable for the pyplusplus.code_creators.include_directories  
>> module would
>> do the job.
>
> You also can replace both functions and submit the patch later :-)
>
> import pyplusplus
>
> def your_function( ..... ):
>    <<< .... >>>
>
> pyplusplus.code_creators.module_t.replace_included_headers = <<<your  
> function>>>


I will probably just proceed in this way for now. I haven't observed  
any problems by changing  
pyplusplus 
.code_creators.include_directories.include_directories_t.normalize()  
so that it does nothing except return the reference it is passed, but  
I have not tried the Py++ test suite to see if that change exposes  
bugs elsewhere.

  -Patrick


--
Patrick L. Hartling
Senior Software Engineer, Priority 5
http://www.priority5.com/

The information transmitted in this communication is intended only for
the person or entity to which it is addressed and contains proprietary
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please destroy any copies, contact the sender
and delete the material from any computer.

Re: [pygccxml-development] Py++ typedef handling

[Roman Y. <rom...@gm...>]

On Thu, Apr 23, 2009 at 8:01 PM, Patrick Hartling
<pat...@pr...> wrote:
> I have asked a couple of questions about typedef handling in the past, and I
> have yet another one: is there anything that I can do to force Py++ to use
> the typedefs from the original code in function default argument values and
> in instance method return types?

I guess, it is possible to attach "pretty name" to a type and use it
for code generation, but this is a huge change.

> What I see is that the typedef gets used in
> some places but not others. I haven't identified a pattern to this yet, but
> I am sure that there is one.

Yes: http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/pyplusplus/decl_wrappers/decl_wrapper.py?revision=1664&view=markup

Take a look on "_get_alias" method.

> I have attached code that demonstrates the behavior that I see. test.cpp was
> generated on Windows using Py++ 1.0 and GCC-XML (emulating Visual C++ 9.0)
> built from its CVS repository as of April 21, 2009. I have added comments to
> the generated test.cpp where I see unexpected behavior. From looking at the
> output generated by GCC-XML, I think I understand how the typedef
> information used in template parameters gets lost, and that is unfortunate.
> Maybe there is some room to improve GCC-XML in this area.

It is very difficult. A year or two ago I tried to add something
similar to GCCXML ad got lost in GCC code. May be you will have more
luck.

> In case it matters, the use of 64-bit integers in the example is deliberate.
> Our code uses 64-bit types, and we use typedefs to mask the variation in the
> type declaration depending on operating system and bit width of the binary
> output. 64-bit integers are not the only type that has caused us problems,
> but this is the one that crops up most consistently.

You can do few tricks, before Py++ starts working:
* rename classes and types
* construct new types and typedefs

It is not a nice way. If your code has some coding convention or other
rules you can rely on, it should not be too difficult.

Take a look on http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/examples/pyboost_dev/dev/date_time/generate_code.py?revision=1428&view=markup
file.
It contains code that does exactly this.

Let me know if you need more help.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] Header path normalization and cross-platform code

[Roman Y. <rom...@gm...>]

On Thu, Apr 23, 2009 at 12:44 AM, Patrick Hartling
<pat...@pr...> wrote:
> I am working on setting up a development environment where team members can
> run Py++ from Linux, Windows, or Mac OS X. Thus far, we have struggled to
> get GCC-XML to handle our code on Windows, but we are getting very close to
> having that resolved. In the process, I have come across some unexpected
> behavior from Py++. Specifically, use of the static method
> pyplusplus.code_creators.include_directories.include_directories_t.normalize()
> produces code on Windows that will not compile on other platforms. For
> example, if I have a class MyClass, Py++ on Windows generates code that
> references the .hpp file as myclass.pypp.hpp. The generated file, however,
> will be named MyClass.pypp.hpp. This won't work on a case-sensitive file system.

Basically, in this moment you introduced a new use case to the
project. This use case is problematic:

1. In many cases, the generated code could\will be a little bit
different. For example, boost::date_time library uses different
integer types to represent\keep time. The generated code will be
different on Windows and on Linux.

2. Even if your generated code is ( could be ) same for all platforms,
I cant promise you, that I will not break this feature in future - I
don't enough resources to run such tests.

In most cases, I deliver Py++ script which handles the differences
between platforms and generates the code.

If you need this feature, I suggest you to submit a patch - I will be
glad to commit it.

> The second issue is with the directory separator. If I use
> pyplusplus.code_creators.module.module_t.replace_included_headers() and tell
> Py++ to include a file such as <dir/SomeHeader.h>, the generated output on
> Windows will reference <dir\someheader.h>. Again, the case-sensitive name is
> lost, and the directory separator has changed to be one that only works when
> building on Windows.

What about Mac OS? Will '/' work on it too? ( I never worked on Mac. )

> Is there a specific need for header path normalization?

If I remember right, Py++ has few functions ( don't remember what are
they ), that work with paths. Introducing path "normalized" form
greatly reduces bugs in that functions. I think, if you turn off
normalize functionality, Py++ will introduce few bugs here and there.

As with previous problem, if you submit the patch I'll gladly accept it.

> Under typical
> circumstances, I would expect that the UNIX-style path would always work on
> Windows. At the moment, I can't think of an example of when it would not. If
> header path normalization cannot be removed, could an option be added to
> pyplusplus.code_creators.include_directories.include_directories_t so that
> the use of header path normalization can be turned off? Given that it is a
> static method, a class variable for include_directories_t or a global
> variable for the pyplusplus.code_creators.include_directories module would
> do the job.

You also can replace both functions and submit the patch later :-)

import pyplusplus

def your_function( ..... ):
    <<< .... >>>

pyplusplus.code_creators.module_t.replace_included_headers = <<<your function>>>

HTH

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

[pygccxml-development] Py++ typedef handling

[Patrick H. <pat...@pr...>]

I have asked a couple of questions about typedef handling in the past,  
and I have yet another one: is there anything that I can do to force Py 
++ to use the typedefs from the original code in function default  
argument values and in instance method return types? What I see is  
that the typedef gets used in some places but not others. I haven't  
identified a pattern to this yet, but I am sure that there is one.

I have attached code that demonstrates the behavior that I see.  
test.cpp was generated on Windows using Py++ 1.0 and GCC-XML  
(emulating Visual C++ 9.0) built from its CVS repository as of April  
21, 2009. I have added comments to the generated test.cpp where I see  
unexpected behavior. From looking at the output generated by GCC-XML,  
I think I understand how the typedef information used in template  
parameters gets lost, and that is unfortunate. Maybe there is some  
room to improve GCC-XML in this area.

In case it matters, the use of 64-bit integers in the example is  
deliberate. Our code uses 64-bit types, and we use typedefs to mask  
the variation in the type declaration depending on operating system  
and bit width of the binary output. 64-bit integers are not the only  
type that has caused us problems, but this is the one that crops up  
most consistently.

  -Patrick


--
Patrick L. Hartling
Senior Software Engineer, Priority 5
http://www.priority5.com/

The information transmitted in this communication is intended only for
the person or entity to which it is addressed and contains proprietary
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please destroy any copies, contact the sender
and delete the material from any computer.

[pygccxml-development] Header path normalization and cross-platform code

[Patrick H. <pat...@pr...>]

I am working on setting up a development environment where team members can
run Py++ from Linux, Windows, or Mac OS X. Thus far, we have struggled to
get GCC-XML to handle our code on Windows, but we are getting very close to
having that resolved. In the process, I have come across some unexpected
behavior from Py++. Specifically, use of the static method
pyplusplus.code_creators.include_directories.include_directories_t.normalize()
produces code on Windows that will not compile on other platforms. For
example, if I have a class MyClass, Py++ on Windows generates code that
references the .hpp file as myclass.pypp.hpp. The generated file, however,
will be named MyClass.pypp.hpp. This won't work on a case-sensitive file system.

The second issue is with the directory separator. If I use
pyplusplus.code_creators.module.module_t.replace_included_headers() and tell
Py++ to include a file such as <dir/SomeHeader.h>, the generated output on
Windows will reference <dir\someheader.h>. Again, the case-sensitive name is
lost, and the directory separator has changed to be one that only works when
building on Windows.

Is there a specific need for header path normalization? Under typical
circumstances, I would expect that the UNIX-style path would always work on
Windows. At the moment, I can't think of an example of when it would not. If
header path normalization cannot be removed, could an option be added to
pyplusplus.code_creators.include_directories.include_directories_t so that
the use of header path normalization can be turned off? Given that it is a
static method, a class variable for include_directories_t or a global
variable for the pyplusplus.code_creators.include_directories module would
do the job.

 -Patrick


-- 
Patrick L. Hartling
Senior Software Engineer, Priority 5
http://www.priority5.com/

The information transmitted in this communication is intended only for
the person or entity to which it is addressed and contains proprietary
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please destroy any copies, contact the sender
and delete the material from any computer.

Re: [pygccxml-development] Wrapping virtual functions only

[Roman Y. <rom...@gm...>]

On Mon, Mar 9, 2009 at 9:05 PM, Kevin Atkinson <kev...@gm...> wrote:
> Hi there, Roman et al,

Good evening.

> First of all, thanks for the lovely tool.  I've created many python
> wrappers, with varying degrees of automation, and it looks like PY++ is what
> I should have been using all along.

Thank you!

> I've been getting some behaviour I don't understand with the include and
> exclude methods in PY++.  I am trying to create a wrapper for Qt 4.5.  Qt
> has a nice reflection API with allows creating a very minimal generic
> wrapper that will work for most things -- invoking methods, getting and
> setting properties.  The one thing you can't do is override virtual methods
> in python and have them get called from C++.
>
> To remedy that, the wrappings will only wrap virtual methods on classes
> derived from QObject.  (Objects not derived from QObject don't support the
> Qt reflection methods and so have to be conventionally wrapped).
>
> I'm testing with the following classes:
>
> class A
> {
> public:
>    void g() { printf("A::g()\n"); }
>    virtual void foo() = 0;
> };
>
> class B : public A
> {
>    virtual void foo() { printf("B:foo()\n"); }
> };
>
> void free_func(A *a)
> {
>    a->foo();
> }

Let me to summarize what we have here:

    class A has two *public* functions:
       g - regular function ( virtuality == "not virtual" )
       foo - pure virtual function ( virtuality == "pure virtual" )

    class B has single *private* virtual function "foo"

> When I do this:
>
> virtual_funcs = mb.member_functions(function=lambda
> decl:decl.virtuality=='virtual').include()

You can print the result of the statement. The only function you will
see is: B::foo

> Py++ adds the non-virtual function g as well:
> ...

By default, Py++ exports all "declarations" from the directory, where
the source file is.
It is explained here:
http://www.language-binding.net/pyplusplus/documentation/tutorials/module_builder/module_builder.html#declarations-customization

> If I do this:
>
> mb.member_functions(function=lambda decl:decl.virtuality == "virtual").include()

So, you select private B::foo function and include it. Py++ will not
expose it, because it is private and not pure virtual.

> mb.member_functions(function=lambda decl:decl.virtuality != "virtual").exclude()

Here, you select A::foo and A::g and exclude them

> It doesn't add any member functions at all:

I hope, now it is clear why.

What you really want is to write:

mb.member_functions(function=lambda decl:decl.virtuality == "not
virtual").exclude()

> Many apologies if I doing something really stupid.

No need. You provided very detailed description and even me it took
some time to understand what was going on.

> Just in case, here's the whole py++ file:
> ...

I hope, it was clear. If not come back. I will be glad to see Qt
exposed to Python using Boost Python and Py++.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

[pygccxml-development] Wrapping virtual functions only

[Kevin A. <kev...@gm...>]

Hi there, Roman et al,

First of all, thanks for the lovely tool.  I've created many python
wrappers, with varying degrees of automation, and it looks like PY++ is what
I should have been using all along.

I've been getting some behaviour I don't understand with the include and
exclude methods in PY++.  I am trying to create a wrapper for Qt 4.5.  Qt
has a nice reflection API with allows creating a very minimal generic
wrapper that will work for most things -- invoking methods, getting and
setting properties.  The one thing you can't do is override virtual methods
in python and have them get called from C++.

To remedy that, the wrappings will only wrap virtual methods on classes
derived from QObject.  (Objects not derived from QObject don't support the
Qt reflection methods and so have to be conventionally wrapped).

I'm testing with the following classes:

*class A
{
public:
   void g() { printf("A::g()\n"); }
   virtual void foo() = 0;
};

class B : public A
{
   virtual void foo() { printf("B:foo()\n"); }
};

void free_func(A *a)
{
   a->foo();
}
*
When I do this:

*virtual_funcs = mb.member_functions(function=**lambda
decl:decl.virtuality=='**virtual').include()
*
Py++ adds the non-virtual function g as well:


*struct A_wrapper : A, bp::wrapper< A > {

    A_wrapper()
    : A()
      , bp::wrapper< A >(){
        // null constructor

    }

    virtual void foo(  ){
        bp::override func_foo = this->get_override( "foo" );
        func_foo(  );
    }

};

BOOST_PYTHON_MODULE(test_lib){
    bp::class_< A_wrapper, boost::noncopyable >( "A" )
        .def(
            "foo"
            , bp::pure_virtual( (void ( ::A::* )(  ) )(&::A::foo) ) )
        .def(
            "g"
            , (void ( ::A::* )(  ) )( &::A::g ) );

    bp::class_< B, bp::bases< A > >( "B" );

    { //::free_func

        typedef void ( *free_func_function_type )( ::A * );

        bp::def(
            "free_func"
            , free_func_function_type( &::free_func )
            , ( bp::arg("a") ) );

    }
}
*
If I do this:

*mb.member_functions(function=lambda decl:decl.virtuality ==
"virtual").include()
mb.member_functions(function=lambda decl:decl.virtuality !=
"virtual").exclude()
*
It doesn't add any member functions at all:

*BOOST_PYTHON_MODULE(test_lib){
    bp::class_< A, boost::noncopyable >( "A", bp::no_init );

    bp::class_< B, bp::bases< A > >( "B" );

    { //::free_func

        typedef void ( *free_func_function_type )( ::A * );

        bp::def(
            "free_func"
            , free_func_function_type( &::free_func )
            , ( bp::arg("a") ) );

    }
}
*

Many apologies if I doing something really stupid.  Just in case, here's the
whole py++ file:
*
import os
from pyplusplus import module_builder

#Creating an instance of class that will help you to expose your
declarations
mb = module_builder.module_builder_t(
[r"C:/kevin/source/tests/py++_tests/test_lib/test_classes.h"]
                                      , gccxml_path=r"C:/Program
Files/gccxml 0.9/bin/gccxml.exe"
                                      ,
working_directory=r"C:/kevin/source/tests/py++_tests/test_lib"
                                      , include_paths=[]
                                      , define_symbols=[] )



mb.member_functions(function=lambda decl:decl.virtuality ==
"virtual").include()
mb.member_functions(function=lambda decl:decl.virtuality !=
"virtual").exclude()


#Creating code creator. After this step you should not modify/customize
declarations.
mb.build_code_creator( module_name='test_lib' )

#Writing code to file.
mb.write_module( './test_lib_bindings.cpp' )
*
Many thanks,

Kevin Atkinson

Re: [pygccxml-development] Cannot exclude inherited virtual methods

[Patrick H. <pat...@pr...>]

Roman Yakovenko wrote:
> On Thu, Feb 19, 2009 at 4:17 PM, Patrick Hartling
> <pat...@pr...> wrote:
>> Roman Yakovenko wrote:
>>> On Thu, Feb 19, 2009 at 1:57 AM, Patrick Hartling
>>> <pat...@pr...> wrote:
>>>> I have a case where a base class defines virtual methods that are
>>>> inherited
>>>> by a derived class. I need to be able to exclude at least one of the
>>>> virtual
>>>> methods from the generated Boost.Python code for the derived class, but I
>>>> cannot figure out how to do it. If I understand correctly, I am having
>>>> problems because the virtual methods are not overridden by the derived
>>>> class, and thus they are not part of the
>>>> pyplusplus.decl_wrappers.class_wrapper.class_t object for the derived
>>>> class.
>>>>
>>>> I have attached a header file and Py++ script that demonstrate the issue.
>>>> Is
>>>> there some way for me to apply a customization to the class wrapper's
>>>> inherited virtual methods for the derived object? I am using r1669 of the
>>>> pygccxml trunk and GCC 0.9 (1.127).
>>> I am not sure, I understand you correctly. The following is the code
>>> generated by Py++.
>>>
>>> Please change it so I could understand what you want.
>> What I would like to see is the following generated by Py++:
>>
>> #include "boost/python.hpp"
>>
>> namespace bp = boost::python;
>>
>> struct Base_wrapper : Base, bp::wrapper< Base > {
>>
>>    Base_wrapper(Base const & arg )
>>    : Base( arg )
>>      , bp::wrapper< Base >(){
>>        // copy constructor
>>
>>    }
>>
>>    Base_wrapper()
>>    : Base()
>>      , bp::wrapper< Base >(){
>>        // null constructor
>>
>>    }
>>
>>    virtual void f( int v ) {
>>        if( bp::override func_f = this->get_override( "f" ) )
>>            func_f( v );
>>        else
>>            this->Base::f( v );
>>    }
>>
>>
>>    void default_f( int v ) {
>>        Base::f( v );
>>    }
>>
>>    virtual void f( float v ) {
>>        if( bp::override func_f = this->get_override( "f" ) )
>>            func_f( v );
>>        else
>>            this->Base::f( v );
>>    }
>>
>>
>>    void default_f( float v ) {
>>        Base::f( v );
>>    }
>>
>> };
>>
>> BOOST_PYTHON_MODULE(pyplusplus){
>>    bp::class_< Base_wrapper >( "Base" )
>>        .def(
>>            "f"
>>            , (void ( ::Base::* )( int ) )(&::Base::f)
>>            , (void ( Base_wrapper::* )( int ) )(&Base_wrapper::default_f)
>>            , ( bp::arg("v") ) )
>>        .def(
>>            "f"
>>            , (void ( ::Base::* )( float ) )(&::Base::f)
>>            , (void ( Base_wrapper::* )( float ) )(&Base_wrapper::default_f)
>>            , ( bp::arg("v") ) );
>>
>>    bp::class_< Derived, bp::bases< Base > >( "Derived" )
>>        .def(
>>            "f"
>>            , (void ( ::Base::* )( int ) )(&::Base::f)
>>            , ( bp::arg("v") ) )
>>        .def(
>>            "f"
>>            , (void ( ::Base::* )( float ) )(&::Base::f)
>>            , ( bp::arg("v") ) );
>> }
>>
>> I have three goals:
>>
>> 1. Expose Base in a manner that allows its virtual methods to be overridden
>> by a Python subclass.
> 
> This is what you already have .
> 
>> 2. Expose Derived in a manner that *does not* allow its virtual methods to
>> be overridden by a Python subclass.
> 
> Py++ doesn't allow to do this and it is not simple to achieve in
> general use case. For example, if Base class has pure virtual method,
> the wrapper should be generated.
> 
>> 3. Prevent the exposure of an inherited, non-overridden virtual method with
>> a signature that does not work well with Python.
> 
> For this case, Py++ introduces "Function Transformation" feature,
> which works fine for all public member functions, even pure virtual
> http://language-binding.net/pyplusplus/documentation/functions/transformation/transformation.html?highlight=function%20transformation

We are using function transformations elsewhere, but this case would have 
required a custom transformer. Since it is very isolated (basically 1 class 
out of over 500), I just wanted to handle it in as simple a manner as 
possible. I thought that that would be excluding the method, but that turned 
out to be more involved than I had expected.

>> The third item was not expressed in my original message or in the code
>> example because I wanted to focus on being able to exclude an inherited
>> virtual method with no override. That seems to me to be the fundamental
>> issue that I am seeing. I can exclude virtual methods for Base, but those
>> that are inherited by Derived and not overridden seem beyond my reach for
>> excluding.
> 
> There is no "clean" way to achieve this, but try to take a look on
> http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/pyplusplus/decl_wrappers/class_wrapper.py?revision=1664&view=markup
> redefined_funcs function.
> 
> It returns reference to list, which contains all function that should
> be redefined in the class wrapper. Try to delete it content.

Ah, I didn't think of that. I was trying to come up with ways to force the 
cached list to be rebuilt, but modifying it directly by removing the desired 
items is far more effective. Thanks for the tip.

  -Patrick


-- 
Patrick L. Hartling
Senior Software Engineer, Priority 5
http://www.priority5.com/

The information transmitted in this communication is intended only for
the person or entity to which it is addressed and contains proprietary
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please destroy any copies, contact the sender
and delete the material from any computer.

Re: [pygccxml-development] Cannot exclude inherited virtual methods

[Roman Y. <rom...@gm...>]

On Thu, Feb 19, 2009 at 4:17 PM, Patrick Hartling
<pat...@pr...> wrote:
> Roman Yakovenko wrote:
>>
>> On Thu, Feb 19, 2009 at 1:57 AM, Patrick Hartling
>> <pat...@pr...> wrote:
>>>
>>> I have a case where a base class defines virtual methods that are
>>> inherited
>>> by a derived class. I need to be able to exclude at least one of the
>>> virtual
>>> methods from the generated Boost.Python code for the derived class, but I
>>> cannot figure out how to do it. If I understand correctly, I am having
>>> problems because the virtual methods are not overridden by the derived
>>> class, and thus they are not part of the
>>> pyplusplus.decl_wrappers.class_wrapper.class_t object for the derived
>>> class.
>>>
>>> I have attached a header file and Py++ script that demonstrate the issue.
>>> Is
>>> there some way for me to apply a customization to the class wrapper's
>>> inherited virtual methods for the derived object? I am using r1669 of the
>>> pygccxml trunk and GCC 0.9 (1.127).
>>
>> I am not sure, I understand you correctly. The following is the code
>> generated by Py++.
>>
>> Please change it so I could understand what you want.
>
> What I would like to see is the following generated by Py++:
>
> #include "boost/python.hpp"
>
> namespace bp = boost::python;
>
> struct Base_wrapper : Base, bp::wrapper< Base > {
>
>    Base_wrapper(Base const & arg )
>    : Base( arg )
>      , bp::wrapper< Base >(){
>        // copy constructor
>
>    }
>
>    Base_wrapper()
>    : Base()
>      , bp::wrapper< Base >(){
>        // null constructor
>
>    }
>
>    virtual void f( int v ) {
>        if( bp::override func_f = this->get_override( "f" ) )
>            func_f( v );
>        else
>            this->Base::f( v );
>    }
>
>
>    void default_f( int v ) {
>        Base::f( v );
>    }
>
>    virtual void f( float v ) {
>        if( bp::override func_f = this->get_override( "f" ) )
>            func_f( v );
>        else
>            this->Base::f( v );
>    }
>
>
>    void default_f( float v ) {
>        Base::f( v );
>    }
>
> };
>
> BOOST_PYTHON_MODULE(pyplusplus){
>    bp::class_< Base_wrapper >( "Base" )
>        .def(
>            "f"
>            , (void ( ::Base::* )( int ) )(&::Base::f)
>            , (void ( Base_wrapper::* )( int ) )(&Base_wrapper::default_f)
>            , ( bp::arg("v") ) )
>        .def(
>            "f"
>            , (void ( ::Base::* )( float ) )(&::Base::f)
>            , (void ( Base_wrapper::* )( float ) )(&Base_wrapper::default_f)
>            , ( bp::arg("v") ) );
>
>    bp::class_< Derived, bp::bases< Base > >( "Derived" )
>        .def(
>            "f"
>            , (void ( ::Base::* )( int ) )(&::Base::f)
>            , ( bp::arg("v") ) )
>        .def(
>            "f"
>            , (void ( ::Base::* )( float ) )(&::Base::f)
>            , ( bp::arg("v") ) );
> }
>
> I have three goals:
>
> 1. Expose Base in a manner that allows its virtual methods to be overridden
> by a Python subclass.

This is what you already have .

> 2. Expose Derived in a manner that *does not* allow its virtual methods to
> be overridden by a Python subclass.

Py++ doesn't allow to do this and it is not simple to achieve in
general use case. For example, if Base class has pure virtual method,
the wrapper should be generated.

> 3. Prevent the exposure of an inherited, non-overridden virtual method with
> a signature that does not work well with Python.

For this case, Py++ introduces "Function Transformation" feature,
which works fine for all public member functions, even pure virtual
http://language-binding.net/pyplusplus/documentation/functions/transformation/transformation.html?highlight=function%20transformation

> The third item was not expressed in my original message or in the code
> example because I wanted to focus on being able to exclude an inherited
> virtual method with no override. That seems to me to be the fundamental
> issue that I am seeing. I can exclude virtual methods for Base, but those
> that are inherited by Derived and not overridden seem beyond my reach for
> excluding.

There is no "clean" way to achieve this, but try to take a look on
http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/pyplusplus/decl_wrappers/class_wrapper.py?revision=1664&view=markup
redefined_funcs function.

It returns reference to list, which contains all function that should
be redefined in the class wrapper. Try to delete it content.

HTH

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] Cannot exclude inherited virtual methods

[Patrick H. <pat...@pr...>]

Roman Yakovenko wrote:
> On Thu, Feb 19, 2009 at 1:57 AM, Patrick Hartling
> <pat...@pr...> wrote:
>> I have a case where a base class defines virtual methods that are inherited
>> by a derived class. I need to be able to exclude at least one of the virtual
>> methods from the generated Boost.Python code for the derived class, but I
>> cannot figure out how to do it. If I understand correctly, I am having
>> problems because the virtual methods are not overridden by the derived
>> class, and thus they are not part of the
>> pyplusplus.decl_wrappers.class_wrapper.class_t object for the derived class.
>>
>> I have attached a header file and Py++ script that demonstrate the issue. Is
>> there some way for me to apply a customization to the class wrapper's
>> inherited virtual methods for the derived object? I am using r1669 of the
>> pygccxml trunk and GCC 0.9 (1.127).
> 
> I am not sure, I understand you correctly. The following is the code
> generated by Py++.
> 
> Please change it so I could understand what you want.

What I would like to see is the following generated by Py++:

#include "boost/python.hpp"

namespace bp = boost::python;

struct Base_wrapper : Base, bp::wrapper< Base > {

     Base_wrapper(Base const & arg )
     : Base( arg )
       , bp::wrapper< Base >(){
         // copy constructor

     }

     Base_wrapper()
     : Base()
       , bp::wrapper< Base >(){
         // null constructor

     }

     virtual void f( int v ) {
         if( bp::override func_f = this->get_override( "f" ) )
             func_f( v );
         else
             this->Base::f( v );
     }


     void default_f( int v ) {
         Base::f( v );
     }

     virtual void f( float v ) {
         if( bp::override func_f = this->get_override( "f" ) )
             func_f( v );
         else
             this->Base::f( v );
     }


     void default_f( float v ) {
         Base::f( v );
     }

};

BOOST_PYTHON_MODULE(pyplusplus){
     bp::class_< Base_wrapper >( "Base" )
         .def(
             "f"
             , (void ( ::Base::* )( int ) )(&::Base::f)
             , (void ( Base_wrapper::* )( int ) )(&Base_wrapper::default_f)
             , ( bp::arg("v") ) )
         .def(
             "f"
             , (void ( ::Base::* )( float ) )(&::Base::f)
             , (void ( Base_wrapper::* )( float ) )(&Base_wrapper::default_f)
             , ( bp::arg("v") ) );

     bp::class_< Derived, bp::bases< Base > >( "Derived" )
         .def(
             "f"
             , (void ( ::Base::* )( int ) )(&::Base::f)
             , ( bp::arg("v") ) )
         .def(
             "f"
             , (void ( ::Base::* )( float ) )(&::Base::f)
             , ( bp::arg("v") ) );
}

I have three goals:

1. Expose Base in a manner that allows its virtual methods to be overridden 
by a Python subclass.
2. Expose Derived in a manner that *does not* allow its virtual methods to 
be overridden by a Python subclass.
3. Prevent the exposure of an inherited, non-overridden virtual method with 
a signature that does not work well with Python.

The third item was not expressed in my original message or in the code 
example because I wanted to focus on being able to exclude an inherited 
virtual method with no override. That seems to me to be the fundamental 
issue that I am seeing. I can exclude virtual methods for Base, but those 
that are inherited by Derived and not overridden seem beyond my reach for 
excluding.

  -Patrick


-- 
Patrick L. Hartling
Senior Software Engineer, Priority 5
http://www.priority5.com/

The information transmitted in this communication is intended only for
the person or entity to which it is addressed and contains proprietary
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please destroy any copies, contact the sender
and delete the material from any computer.

Re: [pygccxml-development] Cannot exclude inherited virtual methods

[Roman Y. <rom...@gm...>]

On Thu, Feb 19, 2009 at 1:57 AM, Patrick Hartling
<pat...@pr...> wrote:
> I have a case where a base class defines virtual methods that are inherited
> by a derived class. I need to be able to exclude at least one of the virtual
> methods from the generated Boost.Python code for the derived class, but I
> cannot figure out how to do it. If I understand correctly, I am having
> problems because the virtual methods are not overridden by the derived
> class, and thus they are not part of the
> pyplusplus.decl_wrappers.class_wrapper.class_t object for the derived class.
>
> I have attached a header file and Py++ script that demonstrate the issue. Is
> there some way for me to apply a customization to the class wrapper's
> inherited virtual methods for the derived object? I am using r1669 of the
> pygccxml trunk and GCC 0.9 (1.127).

I am not sure, I understand you correctly. The following is the code
generated by Py++.

Please change it so I could understand what you want.


#include "boost/python.hpp"

namespace bp = boost::python;

struct Base_wrapper : Base, bp::wrapper< Base > {

    Base_wrapper(Base const & arg )
    : Base( arg )
      , bp::wrapper< Base >(){
        // copy constructor

    }

    Base_wrapper()
    : Base()
      , bp::wrapper< Base >(){
        // null constructor

    }

    virtual void f( int v ) {
        if( bp::override func_f = this->get_override( "f" ) )
            func_f( v );
        else
            this->Base::f( v );
    }


    void default_f( int v ) {
        Base::f( v );
    }

    virtual void f( float v ) {
        if( bp::override func_f = this->get_override( "f" ) )
            func_f( v );
        else
            this->Base::f( v );
    }


    void default_f( float v ) {
        Base::f( v );
    }

};

struct Derived_wrapper : Derived, bp::wrapper< Derived > {

    Derived_wrapper(Derived const & arg )
    : Derived( arg )
      , bp::wrapper< Derived >(){
        // copy constructor

    }

    Derived_wrapper()
    : Derived()
      , bp::wrapper< Derived >(){
        // null constructor

    }

    virtual void f( int v ) {
        if( bp::override func_f = this->get_override( "f" ) )
            func_f( v );
        else
            this->Base::f( v );
    }


    void default_f( int v ) {
        Base::f( v );
    }

    virtual void f( float v ) {
        if( bp::override func_f = this->get_override( "f" ) )
            func_f( v );
        else
            this->Base::f( v );
    }


    void default_f( float v ) {
        Base::f( v );
    }

};

BOOST_PYTHON_MODULE(pyplusplus){
    bp::class_< Base_wrapper >( "Base" )
        .def(
            "f"
            , (void ( ::Base::* )( int ) )(&::Base::f)
            , (void ( Base_wrapper::* )( int ) )(&Base_wrapper::default_f)
            , ( bp::arg("v") ) )
        .def(
            "f"
            , (void ( ::Base::* )( float ) )(&::Base::f)
            , (void ( Base_wrapper::* )( float ) )(&Base_wrapper::default_f)
            , ( bp::arg("v") ) );

    bp::class_< Derived_wrapper, bp::bases< Base > >( "Derived" )
        .def(
            "f"
            , (void ( ::Base::* )( int ) )(&::Base::f)
            , (void ( Derived_wrapper::* )( int ) )(&Derived_wrapper::default_f)
            , ( bp::arg("v") ) )
        .def(
            "f"
            , (void ( ::Base::* )( float ) )(&::Base::f)
            , (void ( Derived_wrapper::* )( float )
)(&Derived_wrapper::default_f)
            , ( bp::arg("v") ) );
}


-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

[pygccxml-development] Cannot exclude inherited virtual methods

[Patrick H. <pat...@pr...>]

I have a case where a base class defines virtual methods that are inherited 
by a derived class. I need to be able to exclude at least one of the virtual 
methods from the generated Boost.Python code for the derived class, but I 
cannot figure out how to do it. If I understand correctly, I am having 
problems because the virtual methods are not overridden by the derived 
class, and thus they are not part of the 
pyplusplus.decl_wrappers.class_wrapper.class_t object for the derived class.

I have attached a header file and Py++ script that demonstrate the issue. Is 
there some way for me to apply a customization to the class wrapper's 
inherited virtual methods for the derived object? I am using r1669 of the 
pygccxml trunk and GCC 0.9 (1.127).

  -Patrick


-- 
Patrick L. Hartling
Senior Software Engineer, Priority 5
http://www.priority5.com/

The information transmitted in this communication is intended only for
the person or entity to which it is addressed and contains proprietary
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please destroy any copies, contact the sender
and delete the material from any computer.

Re: [pygccxml-development] std::vector<..> iteration error when using two extensions compiled with indexing_suite_v2

[Roman Y. <rom...@gm...>]

On Tue, Feb 17, 2009 at 10:53 PM, Maik Beckmann
<bec...@go...> wrote:
> 2009/2/17 Roman Yakovenko <rom...@gm...>:
>> Add the following lines before you import your modules
>>
>> import dl
>> import sys
>> sys.setdlopenflags(dl.RTLD_NOW | dl.RTLD_GLOBAL)
>>
>> and you are going to be fine.
>
> Ok, but I'll stick with with indexing_suite_v1 vor now.  I just don't
> feel comfortable with modules having special needs (dead line
> approaches).

If you are going to stick to std::vector and std::map you should be
fine. If you will need other containers - you will have to use V2.

> But thanks for the hint.  I've done a grep at /usr/lib/python2.6 for
> RTLD_GLOBAL and RTLD_NOW.  A few packages use them
>  - vtk
>  - libxslt
>  - setuptools
> So there must be some info about whether its a dirty hack or a
> recommended workaround.

If you will find one, please drop the link here.

> Thank you,

You are welcome.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] std::vector<..> iteration error when using two extensions compiled with indexing_suite_v2

[Maik B. <bec...@go...>]

2009/2/17 Roman Yakovenko <rom...@gm...>:
> Add the following lines before you import your modules
>
> import dl
> import sys
> sys.setdlopenflags(dl.RTLD_NOW | dl.RTLD_GLOBAL)
>
> and you are going to be fine.

Ok, but I'll stick with with indexing_suite_v1 vor now.  I just don't
feel comfortable with modules having special needs (dead line
approaches).

But thanks for the hint.  I've done a grep at /usr/lib/python2.6 for
RTLD_GLOBAL and RTLD_NOW.  A few packages use them
  - vtk
  - libxslt
  - setuptools
So there must be some info about whether its a dirty hack or a
recommended workaround.

Thank you,
 -- Maik

Re: [pygccxml-development] std::vector<..> iteration error when using two extensions compiled with indexing_suite_v2

[Roman Y. <rom...@gm...>]

On Tue, Feb 17, 2009 at 10:00 PM, Maik Beckmann
<bec...@go...> wrote:
> 2009/2/17 Roman Yakovenko <rom...@gm...>:
>>
>> Okey, my tester reproduced the problem on Linux. I am going to investigate it.
>>
>
> I can confirm that on WinXP using
>  - python 2.5.4
>  - tdm-mingw 4.3.3
>  - gccxml cvs
>  - pygccxml/pyplusplus svn
>  - boost svn
> I get the warning but it actually works.
>
> A wild guess:  May at be there is exactly one to_python registry for
> indexing_suite_v1 inside the boost.python dll/so and for
> indexing_suite_v2 each module contains it's own?  Maybe this causes
> the problem, because..
> (Watch out, non expert comment on dll/so:) AFAIK each .dll has its own
> address space, while a .so  belongs to the one of executable it's been
> linked to.

Cant comment on those - I don't know the thing so deep.

> Just a wild guess..

Add the following lines before you import your modules

import dl

import sys



sys.setdlopenflags(dl.RTLD_NOW | dl.RTLD_GLOBAL)



and you are going to be fine.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] std::vector<..> iteration error when using two extensions compiled with indexing_suite_v2

[Maik B. <bec...@go...>]

2009/2/17 Roman Yakovenko <rom...@gm...>:
>
> Okey, my tester reproduced the problem on Linux. I am going to investigate it.
>

I can confirm that on WinXP using
  - python 2.5.4
  - tdm-mingw 4.3.3
  - gccxml cvs
  - pygccxml/pyplusplus svn
  - boost svn
I get the warning but it actually works.

A wild guess:  May at be there is exactly one to_python registry for
indexing_suite_v1 inside the boost.python dll/so and for
indexing_suite_v2 each module contains it's own?  Maybe this causes
the problem, because..
(Watch out, non expert comment on dll/so:) AFAIK each .dll has its own
address space, while a .so  belongs to the one of executable it's been
linked to.

Just a wild guess..


Best,
 -- Maik

Re: [pygccxml-development] std::vector<..> iteration error when using two extensions compiled with indexing_suite_v2

[Roman Y. <rom...@gm...>]

On Tue, Feb 17, 2009 at 10:03 AM, Roman Yakovenko
<rom...@gm...> wrote:
> On Tue, Feb 17, 2009 at 9:49 AM, Maik Beckmann
> <bec...@go...> wrote:
>> Roman Yakovenko schrieb am Dienstag 17 Februar 2009 um 07:23:
>>
>>> This is something new and if I need to guess there is something wrong
>>> on your side.
>>
>> To ensure it's not my code causing the error, I've reduced the problem to the
>> simple example I've posted.  For the sake of simplicity I suggest we forget
>> about my actual code.
>
> I didn't say your code. There are other factors that could influence.
> For example how you built Boost.Python library or compilation flags
> for a compiler.
> What compiler do you use?
>
>>> I committed new test case (
>>> http://pygccxml.svn.sourceforge.net/viewvc/pygccxml?view=rev&revision=1686
>>> ) and it works fine on Windows and I believe it will work on Linux (
>>> Ubuntu 8.10 ). For tests I use Python 2.5.
>>
>> By which command can I run the test suite?
>
> You will have to edit the following file
> http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/environment.py?view=markup
> and install scons
> Than you can execute that file. It is self contained.
>
> It could be nice if you can run all unit tests. So we can discover and
> fix all issues, before you get to the real code.
>
> By the way, I will run your tests on my system this evening.

Okey, my tester reproduced the problem on Linux. I am going to investigate it.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] std::vector<..> iteration error when using two extensions compiled with indexing_suite_v2

[Roman Y. <rom...@gm...>]

On Tue, Feb 17, 2009 at 9:49 AM, Maik Beckmann
<bec...@go...> wrote:
> Roman Yakovenko schrieb am Dienstag 17 Februar 2009 um 07:23:
>
>> This is something new and if I need to guess there is something wrong
>> on your side.
>
> To ensure it's not my code causing the error, I've reduced the problem to the
> simple example I've posted.  For the sake of simplicity I suggest we forget
> about my actual code.

I didn't say your code. There are other factors that could influence.
For example how you built Boost.Python library or compilation flags
for a compiler.
What compiler do you use?

>> I committed new test case (
>> http://pygccxml.svn.sourceforge.net/viewvc/pygccxml?view=rev&revision=1686
>> ) and it works fine on Windows and I believe it will work on Linux (
>> Ubuntu 8.10 ). For tests I use Python 2.5.
>
> By which command can I run the test suite?

You will have to edit the following file
http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/environment.py?view=markup
and install scons
Than you can execute that file. It is self contained.

It could be nice if you can run all unit tests. So we can discover and
fix all issues, before you get to the real code.

By the way, I will run your tests on my system this evening.

> I have python 2.6.1 installed on a x86 and a x86_64 linux box, both show the
> error.

I don't have access to this architecture. So it could be a problem. Do
you use SVN version of pygccxml and Py++? It contains few fixes for
64bit system, some of them in Indexing Suite V2.

>> Until recently, all my tests worked in a single instance of Python
>> interpreter. I had a lot of "class already registered" warnings, but
>> everything worked fine.
>>
>> May be you should play with sys.setdlopenflags function.
>
> Will do.
>
>> I also suggest you to take a look on "multi module development"
>> http://language-
> binding.net/pyplusplus/documentation/multi_module_development.html?highlight=multi%20module%20development
>> document.
>
> I don't think this is related to this issue, since beside the stl no classes
> are involved.

I gave you the link to make your development a little bit easier and
compilation time smaller.
Python-Ogre uses that functionality and it is quite useful. You also
will avoid the warning raised.

>> P.S. I attached my compilation session on Windows and I will send to
>> you the compilation session on Linux this evening
>
> Today I'll start to port my code to WinXP, so I may comment on this this
> evening as well.  However, for now I switched to indexing_suite_v1, which
> works fine on the same code.

Okey.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] std::vector<..> iteration error when using two extensions compiled with indexing_suite_v2

[Maik B. <bec...@go...>]

Roman Yakovenko schrieb am Dienstag 17 Februar 2009 um 07:23:

> This is something new and if I need to guess there is something wrong
> on your side.

To ensure it's not my code causing the error, I've reduced the problem to the 
simple example I've posted.  For the sake of simplicity I suggest we forget 
about my actual code.

> I committed new test case (
> http://pygccxml.svn.sourceforge.net/viewvc/pygccxml?view=rev&revision=1686
> ) and it works fine on Windows and I believe it will work on Linux (
> Ubuntu 8.10 ). For tests I use Python 2.5.

By which command can I run the test suite?

I have python 2.6.1 installed on a x86 and a x86_64 linux box, both show the 
error.

> Until recently, all my tests worked in a single instance of Python
> interpreter. I had a lot of "class already registered" warnings, but
> everything worked fine.
>
> May be you should play with sys.setdlopenflags function.

Will do.

> I also suggest you to take a look on "multi module development"
> http://language-
binding.net/pyplusplus/documentation/multi_module_development.html?highlight=multi%20module%20development
> document.

I don't think this is related to this issue, since beside the stl no classes 
are involved.

> P.S. I attached my compilation session on Windows and I will send to
> you the compilation session on Linux this evening

Today I'll start to port my code to WinXP, so I may comment on this this 
evening as well.  However, for now I switched to indexing_suite_v1, which 
works fine on the same code.


Best,
 -- Maik

Re: [pygccxml-development] std::vector<..> iteration error when using two extensions compiled with indexing_suite_v2

[Roman Y. <rom...@gm...>]

On Mon, Feb 16, 2009 at 10:14 PM, Maik Beckmann
<bec...@go...> wrote:
> Hello,

Good morning

> I ran into issues when importing two extensions build using indexing_suite_v2.
> ...
> Changing indexing_site_version to 1 makes it work fine.  Is this a known
> limitation or a bug?

This is something new and if I need to guess there is something wrong
on your side.

I committed new test case (
http://pygccxml.svn.sourceforge.net/viewvc/pygccxml?view=rev&revision=1686
) and it works fine on Windows and I believe it will work on Linux (
Ubuntu 8.10 ). For tests I use Python 2.5.

Until recently, all my tests worked in a single instance of Python
interpreter. I had a lot of "class already registered" warnings, but
everything worked fine.

May be you should play with sys.setdlopenflags function.

I also suggest you to take a look on "multi module development"
http://language-binding.net/pyplusplus/documentation/multi_module_development.html?highlight=multi%20module%20development
document.

P.S. I attached my compilation session on Windows and I will send to
you the compilation session on Linux this evening

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

[pygccxml-development] std::vector<..> iteration error when using two extensions compiled with indexing_suite_v2

[Maik B. <bec...@go...>]

Hello,

I ran into issues when importing two extensions build using indexing_suite_v2.  
My code ran fine, but after I rearranged it, it stopped with:
  RuntimeError: get

The following code reproduces the this error.

ProjA:
{{{ 
#include <vector>
std::vector<double> create_vector_double_A()
{
  std::vector<double> ret;
  for(size_t i = 0; i < 10; i++)
    ret.push_back(i);
  return ret;
}
}}}

ProjB:
{{{
#include <vector>
std::vector<double> create_vector_double_B()
{
  std::vector<double> ret;
  for(size_t i = 0; i < 10; i++)
    ret.push_back(i);
  return ret;
}
}}}

Each project are build with:
  mb = module_builder.module_builder_t( ... , indexing_suite_version=2)

bug.py
{{{
import sys
import os

sys.path.append( os.getcwd() + '/ProjA/build/src')
sys.path.append( os.getcwd() + '/ProjB/build/src')

import ProjA
import ProjB

dv = ProjA.create_vector_double_A()
for d in dv:
    print d
}}}

Running it via
  $ python bug.py
results in
{{{
bug.py:8: RuntimeWarning: to-Python converter for std::vector<double, 
std::allocator<double> > already registered; second conversion method ignored.
  import ProjB
0.0
1.0
2.0
3.0
4.0
5.0
6.0
7.0
8.0
9.0
Traceback (most recent call last):
  File "bug.py", line 11, in <module>
    for d in dv:
RuntimeError: get
}}}

Changing indexing_site_version to 1 makes it work fine.  Is this a known 
limitation or a bug?  

Best,
 -- Maik  

PS:  full code attached.  Given cmake, boost, gccxml, pygccxml and pyplusplus 
are installed you can run:
$ make -C ProjA
$ make -C ProjB
$ python bug.py

Re: [pygccxml-development] [indexing_suite_v2] error: no class template named 'extract_return_type'

[Roman Y. <rom...@gm...>]

On Fri, Jan 30, 2009 at 9:55 PM, Maik Beckmann
<bec...@go...> wrote:
> Roman Yakovenko schrieb am Friday 30 January 2009 um 20:39:
>
>>
>> http://www.nabble.com/-C%2B%2B-sig--Raoul-Gough%27s-container-suite-with-sv
>>n-boost-trunk-boost.python--td13152941.html
>
> I found this as well after I've send the email. So I altered slice_handler.hpp
> (patch attached) and ran update_code_repository.py  It works.

Thank you. I committed the patch.


-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/