pygccxml-development

[pygccxml-development] Generated file name length

[Allen B. <al...@vr...>]

We have been running into a problem lately where py++ generates some 
filenames that are so long they cause problems with some windows utilities.

For example, one generated file was named:

vector_less_boost_scope_shared_ptr_less_OSG_scope_SampleInfo_grate__comma__std_scope_allocator_less_boost_scope_shared_ptr_less_OSG_scope_SampleInfo_grate___grate___grate_.pypp.cpp

Would it be possible to add a feature to py++ that would generate 
shorter filenames?  For example maybe part of the filename could be 
created by taking an md5 hash of the typename similar to how the 
function transformer code generates a unique function name.

-Allen

[pygccxml-development] First Try: call policies

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

hi,

I have a simple auto generated 'basictest2.cpp' and a 'basictest2.hpp'. when I try to build the Py++ code I get some warnings about need of call policy: as this is my first try I got a bit stuck

Any help would be most appreciated:


****CODE: basictest2.cpp

#include "basictest2.hpp"

namespace __basictest2__ {

str *const_0;

str *__name__;

void __init() {
    const_0 = new str("Basic Test OK");

    __name__ = new str("basictest2");

}

str *basictest2() {
    
    return const_0;
}

} // module namespace

__ END 


****CODE: basictest2.hpp

#ifndef __BASICTEST2_HPP
#define __BASICTEST2_HPP

#include "builtin.hpp"

using namespace __shedskin__;
namespace __basictest2__ {

extern str *const_0;

extern str *__name__;


extern str * __name__;
void __init();
str *basictest2();

} // module namespace
#endif

__ END 





WARNING: extern __shedskin__::str * __basictest2__::basictest2() [free function]
> compilation error W1050: The function returns "__shedskin__::str *"
> type. You have to specify a call policies.Be sure to take a look on
> Py++ defined call policies: http://language-
> binding.net/pyplusplus/documentation/functions/call_policies.html#py-
> defined-call-policies

WARNING: __basictest2__::const_0 [variable]
> compilation error W1035: Py++ can not expose static pointer member
> variables. This could be changed in future.

WARNING: __shedskin__::str [class]
> execution error W1040: The declaration is unexposed, but there are
> other declarations, which refer to it. This could cause "no to_python
> converter found" run time error. Declarations:   extern
> __shedskin__::str * __basictest2__::basictest2() [free function]
> __test__::x [variable]



Thanks Matthias J.
-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

Re: [pygccxml-development] Howto wrap "out" arguments of a methode

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

On 6/4/07, Alexander Eisenhuth <new...@st...> wrote:
> How to wrap methode Get with Boost.Python?
>
>
>      class MyClass {
>      public:
>          MyClass();
>
>          void GetX(double pos_x);
> [...]
>
>
> Py++ generates following code:
>
> [...]
>              .def( bp::init< >() )
>              .def(
>                  "Get"
>                  , &::MyClass::Get
>                  , ( bp::arg("pos_x")) )
> [...]

It generates the right code, that works just fine

> It seems that it (or gccxml) cannot distinguish between in and out parameter.

I am not sure I understand you. What do you mean under in/out arguments.

> I'v tried it with:
>
>          .def(
>              "GetX"
>              , &::MyClass::GetX
>              , bp::arg("")
>              , bp::return_value_policy<bp::return_arg<1>() >()
>
> But when I try it in python:
>
> Boost.Python.ArgumentError: Python argument types in
>      MyClass.GetX(MyClass, int)
> did not match C++ signature:
>      GetX(class MyClass::LedPosition_C {lvalue}, int {lvalue} )

I guess you are doing wrong something else. Py++ contains
call_policies_tester.py. You can see that I use return_arg policy and
it works just fine. If you want to return int you should pass 2 to
call policy as argument.

If you can create small and complete example I will be glad to help you.

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

[pygccxml-development] Howto wrap "out" arguments of a methode

[Alexander E. <new...@st...>]

How to wrap methode Get with Boost.Python?


     class MyClass {
     public:
         MyClass();

         void GetX(double pos_x);
[...]


Py++ generates following code:

[...]
             .def( bp::init< >() )
             .def(
                 "Get"
                 , &::MyClass::Get
                 , ( bp::arg("pos_x")) )
[...]

It seems that it (or gccxml) cannot distinguish between in and out parameter.

I'v tried it with:

         .def(
             "GetX"
             , &::MyClass::GetX
             , bp::arg("")
             , bp::return_value_policy<bp::return_arg<1>() >()

But when I try it in python:

Boost.Python.ArgumentError: Python argument types in
     MyClass.GetX(MyClass, int)
did not match C++ signature:
     GetX(class MyClass::LedPosition_C {lvalue}, int {lvalue} )


Thanks
Alexander

[pygccxml-development] new feature: exclude erronious

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

Hi. I just committed new functionality, which allows to exclude all
declarations that will cause compilation error. The use is pretty
simple:

    mb = module_builder_t( ... )
    xyz = mb.namespace( name='xyz' )
    xyz.exclude(compilation_errors=True)


Enjoy

P.S. Comments are welcome.

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

Re: [pygccxml-development] Infinite recursion

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

The fix to the problem was committed to SVN, revision 1038.

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

Re: [pygccxml-development] Infinite recursion

[Niki S. <ni...@vi...>]

Roman Yakovenko wrote:
> 
> P.S. I am on Windows machine, so I don't have access to diff\patch 
> utilities, you will have to apply the patch manually.

FYI you can try WinMerge http://winmerge.org/. It can make diff files.

Niki Spahiev

Re: [pygccxml-development] Infinite recursion

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

On 5/22/07, Gustavo Carneiro <gjc...@gm...> wrote:
>
>   Thanks, it works.  Your changes in patch form attached as diff file.


Good. I will apply the patch later. Thanks for bug report.

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

Re: [pygccxml-development] Infinite recursion

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

  Thanks, it works.  Your changes in patch form attached as diff file.

On 22/05/07, Roman Yakovenko <rom...@gm...> wrote:
>
> On 5/22/07, Gustavo Carneiro <gjc...@gm...> wrote:
> >
> >   Py++ entered an infinite recursive loop when parsing some header file;
> > I'm not sure which.  Log file in attachment for more details.
>
>
> :-(
>
> I am looking at code right now and I think I found the problem.
>
> First of all context. It happens when Py++ analyze declarations to produce
> warnings to the user. One of them is related to "function registration
> order":
>
> http://www.language-binding.net/pyplusplus/documentation/functions/registration_order.html
>
> The infinite loop is possible if you have 2 functions with single
> argument. Now the argument type should be pointer to a function. In this
> case remove_pointer returns the original type:
>
> http://www.language-binding.net/pyplusplus/documentation/apidocs/pygccxml.declarations.type_traits-pysrc.html#remove_pointer
>
>
> Do you mind to try attached patch?
>
> Basically you should replace the pyplusplus/decl_wrapper/algorithm.py
> select_problematics function with the attached one. I believe it will solve
> the problem.
>
> P.S. I am on Windows machine, so I don't have access to diff\patch
> utilities, you will have to apply the patch manually.
>
> --
> Roman Yakovenko
> C++ Python language binding
> http://www.language-binding.net/
>



-- 
Gustavo J. A. M. Carneiro
"The universe is always one step beyond logic." -- Frank Herbert

Re: [pygccxml-development] Infinite recursion

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

ICAgIEBzdGF0aWNtZXRob2QNCiAgICBkZWYgc2VsZWN0X3Byb2JsZW1hdGljcyggY2FsbGRlZiAp
Og0KICAgICAgICAiIiJSZXR1cm4gbGlzdCBvZiBwcm9ibGVtYXRpYyBmdW5jdGlvbnMgZm9yIGZ1
bmN0aW9uICJjYWxsZGVmIiAiIiINCiAgICAgICAgaWYgMSAhPSBsZW4oIGNhbGxkZWYucmVxdWly
ZWRfYXJncyApOg0KICAgICAgICAgICAgcmV0dXJuIFtdDQogICAgICAgIGFyZ190eXBlID0gY2Fs
bGRlZi5hcmd1bWVudHNbMF0udHlwZQ0KICAgICAgICBpZiBkZWNsYXJhdGlvbnMuaXNfcG9pbnRl
ciggYXJnX3R5cGUgKSBcDQogICAgICAgICAgIGFuZCBpc2luc3RhbmNlKCBhcmdfdHlwZS5iYXNl
LCBkZWNsYXJhdGlvbnMuY2FsbGRlZl90eXBlX3QgKToNCiAgICAgICAgICAgIHJldHVybiBbXQ0K
ICAgICAgICBwcm9ibGVtYXRpY3MgPSBbXQ0KICAgICAgICBmb3IgZiBpbiBjYWxsZGVmLm92ZXJs
b2FkczoNCiAgICAgICAgICAgIGlmIDEgIT0gbGVuKCBmLnJlcXVpcmVkX2FyZ3MgKToNCiAgICAg
ICAgICAgICAgICBjb250aW51ZQ0KICAgICAgICAgICAgaWYgZi5pZ25vcmU6DQogICAgICAgICAg
ICAgICAgY29udGludWUNCiAgICAgICAgICAgIGlmIE5vbmUgIT0gcmVnaXN0cmF0aW9uX29yZGVy
LmlzX3JlbGF0ZWQoIGNhbGxkZWYuYXJndW1lbnRzWzBdLnR5cGUsIGYuYXJndW1lbnRzWzBdLnR5
cGUgKToNCiAgICAgICAgICAgICAgICBwcm9ibGVtYXRpY3MuYXBwZW5kKCBmICkNCiAgICAgICAg
cmV0dXJuIHByb2JsZW1hdGljcw0KDQo=

Re: [pygccxml-development] Indexing suite in Py++ code

[Alexander E. <new...@st...>]

Roman Yakovenko schrieb:
> 
> "GetButtonMappingArray" function returns reference to std::vector<...>, right?
> Now you should tell Boost.Python how to manage memory of this object.
> 
> If this function returns reference to a member variable you can use
> "return_internal_reference" call policy (
> http://boost.org/libs/python/doc/v2/return_internal_reference.html )
> 
> Tutorials to Py++ call policies:
> http://language-binding.net/pyplusplus/documentation/functions/call_policies.html
> 
Ok, i got it.

Re: [pygccxml-development] Indexing suite in Py++ code

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

On 5/15/07, Alexander Eisenhuth <new...@st...> wrote:
> I think this is the code.
>
> { //::ToolData_C::GetButtonMappingArray
>
>      typedef ::std::vector<short unsigned int,std::allocator<short unsigned int>
>  > & ( ::ToolData_C::*GetButtonMappingArray_function_type )(  ) ;
>
>      ToolData_C_exposer.def(
>                  "GetButtonMappingArray"
>                  , GetButtonMappingArray_function_type(
> &::ToolData_C::GetButtonMappingArray )
>                      /* undefined call policies */ );
>
> }

"GetButtonMappingArray" function returns reference to std::vector<...>, right?
Now you should tell Boost.Python how to manage memory of this object.

If this function returns reference to a member variable you can use
"return_internal_reference" call policy (
http://boost.org/libs/python/doc/v2/return_internal_reference.html )

Tutorials to Py++ call policies:
http://language-binding.net/pyplusplus/documentation/functions/call_policies.html

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

Re: [pygccxml-development] Indexing suite in Py++ code

[Alexander E. <new...@st...>]

Roman Yakovenko schrieb:
> On 5/15/07, Alexander Eisenhuth <new...@st...> wrote:
>> I got a compiler within visual studio:
>>
>> python\detail\caller.hpp(199) : error C2027: Verwendung des undefinierten Typs
>> "boost::python::detail::specify_a_return_value_policy_to_wrap_functions_returning<T>
>>
>> In english "usage of a undefined type"
>>
>> Does this have something todo with indexing suite? Can I tell py++ to generate
>> other code?
> 
> Can you extract relevant piece of your code, that fails to compile?
> Without seeing it I cannot answer your question.
> 

I think this is the code.

{ //::ToolData_C::GetButtonMappingArray

     typedef ::std::vector<short unsigned int,std::allocator<short unsigned int> 
 > & ( ::ToolData_C::*GetButtonMappingArray_function_type )(  ) ;

     ToolData_C_exposer.def(
                 "GetButtonMappingArray"
                 , GetButtonMappingArray_function_type( 
&::ToolData_C::GetButtonMappingArray )
                     /* undefined call policies */ );

}

Re: [pygccxml-development] Indexing suite in Py++ code

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

On 5/15/07, Alexander Eisenhuth <new...@st...> wrote:
> I got a compiler within visual studio:
>
> python\detail\caller.hpp(199) : error C2027: Verwendung des undefinierten Typs
> "boost::python::detail::specify_a_return_value_policy_to_wrap_functions_returning<T>
>
> In english "usage of a undefined type"
>
> Does this have something todo with indexing suite? Can I tell py++ to generate
> other code?

Can you extract relevant piece of your code, that fails to compile?
Without seeing it I cannot answer your question.

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

[pygccxml-development] Indexing suite in Py++ code

[Alexander E. <new...@st...>]

I got a compiler within visual studio:

python\detail\caller.hpp(199) : error C2027: Verwendung des undefinierten Typs 
"boost::python::detail::specify_a_return_value_policy_to_wrap_functions_returning<T>

In english "usage of a undefined type"

Does this have something todo with indexing suite? Can I tell py++ to generate 
other code?

Regards
Alexander

PS: I use a tailored boost.python 1.33.1

Re: [pygccxml-development] How to make Py++ not generate code it knows won't compile

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

On 5/12/07, Gustavo Carneiro <gjc...@gm...> wrote:
>
> On 12/05/07, Roman Yakovenko <rom...@gm...> wrote:
> >
> > On 5/12/07, Gustavo Carneiro <gjc...@gm...> wrote:
> > >   Sometimes Py++ _knows_ a method won't compile, but tries to bind it
> > anyway.  This can be bad when you have developers adding C++ methods and not
> > aware or not caring about Python bindings; sometimes they add methods that
> > won't compile.
> >
> > >Not to mention that is a pain to have to manually exclude the methods
> > that won't compile.
> >
> > Why? I think Py++ provide a convenient interface for such things.
>
>
>   Yes, Py++ provides the best possible interface for everything.  But
> sometimes no interface at all is even better ;-)
>

I agree with you.

>   Couldn't Py++ just not bind methods that will not compile for sure?
> >
> > Yes. Today every declaration has "exclude" method. I will add new
> > argument - "declarations_that_cause_compile_time_errors_only" ( please give
> > a better name ).
> > You will have to set it to "True". The function will write to the log
> > all declarations it excluded.
> >
> > I guess you don't want to exclude function that missing call policies,
> > right?
>
>
>   Yes, missing call policies is what usually hits me.  I am not sure if
> there are other cases when Py++ definitely knows the generated code won't
> compile...
>

Yes it knows:
http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/pyplusplus/messages/warnings_.py?view=markupsome
of the warnings related to functions.

Also you don't have to wait for the patch - you don't need one

mb = module_builder_t(...)
mb.calldefs( lambda calldef: calldef.call_policies is None ).exclude()

This will work for your version of Py++

The way I am going to implement this is to check messages reported by
> > "readme" method, to find all those I will define as problematic and exclude
> > the declarations.
> >
> > P.S. I am a little bit busy these days, can you add new "feature
> > request" to the project? Thanks.
>
>
>   Sure.
>
>   I should try to produce a patch, I guess... :P
>

No, let me to handle this :-)

  PS:  0.9 was a _great_ release; it even produces code that compiles fine
> with "off the shelf " Boost 1.33.1.  That is a great thing; thank you so
> much :-)
>


Thanks.

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

Re: [pygccxml-development] How to make Py++ not generate code it knows won't compile

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

On 12/05/07, Roman Yakovenko <rom...@gm...> wrote:
>
> On 5/12/07, Gustavo Carneiro <gjc...@gm...> wrote:
> >   Sometimes Py++ _knows_ a method won't compile, but tries to bind it
> anyway.  This can be bad when you have developers adding C++ methods and not
> aware or not caring about Python bindings; sometimes they add methods that
> won't compile.
>
> >Not to mention that is a pain to have to manually exclude the methods
> that won't compile.
>
> Why? I think Py++ provide a convenient interface for such things.


  Yes, Py++ provides the best possible interface for everything.  But
sometimes no interface at all is even better ;-)

>   Couldn't Py++ just not bind methods that will not compile for sure?
>
> Yes. Today every declaration has "exclude" method. I will add new argument
> - "declarations_that_cause_compile_time_errors_only" ( please give a better
> name ).
> You will have to set it to "True". The function will write to the log all
> declarations it excluded.
>
> I guess you don't want to exclude function that missing call policies,
> right?


  Yes, missing call policies is what usually hits me.  I am not sure if
there are other cases when Py++ definitely knows the generated code won't
compile...

The way I am going to implement this is to check messages reported by
> "readme" method, to find all those I will define as problematic and exclude
> the declarations.
>
> P.S. I am a little bit busy these days, can you add new "feature request"
> to the project? Thanks.


  Sure.

  I should try to produce a patch, I guess... :P

  PS:  0.9 was a _great_ release; it even produces code that compiles fine
with "off the shelf " Boost 1.33.1.  That is a great thing; thank you so
much :-)

-- 
Gustavo J. A. M. Carneiro
"The universe is always one step beyond logic." -- Frank Herbert

Re: [pygccxml-development] How to make Py++ not generate code it knows won't compile

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

On 5/12/07, Gustavo Carneiro <gjc...@gm...> wrote:
>   Sometimes Py++ _knows_ a method won't compile, but tries to bind it
anyway.  This can be bad when you have developers adding C++ methods and not
aware or not caring about Python bindings; sometimes they add methods that
won't compile.

>Not to mention that is a pain to have to manually exclude the methods that
won't compile.

Why? I think Py++ provide a convenient interface for such things.

>   Couldn't Py++ just not bind methods that will not compile for sure?

Yes. Today every declaration has "exclude" method. I will add new argument -
"declarations_that_cause_compile_time_errors_only" ( please give a better
name ).
You will have to set it to "True". The function will write to the log all
declarations it excluded.

I guess you don't want to exclude function that missing call policies,
right?

The way I am going to implement this is to check messages reported by
"readme" method, to find all those I will define as problematic and exclude
the declarations.

P.S. I am a little bit busy these days, can you add new "feature request" to
the project? Thanks.

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

[pygccxml-development] How to make Py++ not generate code it knows won't compile

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

  Sometimes Py++ _knows_ a method won't compile, but tries to bind it
anyway.  This can be bad when you have developers adding C++ methods and not
aware or not caring about Python bindings; sometimes they add methods that
won't compile.  Not to mention that is a pain to have to manually exclude
the methods that won't compile.

  Couldn't Py++ just not bind methods that will not compile for sure?

-- 
Gustavo J. A. M. Carneiro
"The universe is always one step beyond logic." -- Frank Herbert

Re: [pygccxml-development] Utilizing typedef in code generated by Py++

[Patrick H. <pa...@in...>]

Roman Yakovenko wrote:
> On 5/11/07, Patrick Hartling <pa...@in...
> <mailto:pa...@in...>> wrote:
>> The case I have to deal with at the moment involves the return type of=
 a
>> member function. The return type is a template class for std::vector-l=
ike
>> object that takes a template parameter specifying the contained data t=
ype.
>> In the C++ code, a member function will look like this:
>>
>>    const OSG::MFGLenum& getValue() const;
>>
>> OSG::MFGLenum is a typedef for OSG::MField<GLenum,1> (the 1 is for
> internal
>> usage, I think), and GLenum is in turn a typedef.
>=20
> Ok, now I can provide better answer.
>=20
> Py++ has nice feature related to "class typedefs"
> http://www.language-binding.net/pyplusplus/documentation/hints.html
>=20
> Py++ do knows all typedefs related to the class, but uses them only for=

> aliasing - name of the class for Python user. I think it can use them
> for "class registration" too and thus to achieve better portability.
> Thanks for this idea.
>=20
> Can you submit "feature request"(
> http://sourceforge.net/tracker/?group_id=3D118209&atid=3D684321
> <http://sourceforge.net/tracker/?group_id=3D118209&atid=3D684321> )?

Certainly. I will do it as soon as I can.

>> On Linux, the bindings code that gets generated uses
> OSG::MField<unsigned,1>
>> as the return type, and that is where the problem arises. There is alr=
eady
>> some code being inserted to convert these OSG::MField<> instantiations=

> into
>> boost::python::list, and it turns out that this bit of code is explici=
tly
>> discarding the typedef information as part of stripping the return
> type down
>> to its "naked" form. Using the original information for the member
> function
>> return type, I have added what is needed for this case. It is not
> elegant,
>> but it works [*].
>=20
> I lost you :-(

Don't worry about it. I was just "thinking out loud" about how I could de=
al
with the case that I have.

>> > :-) Be sure to read the first link I gave to the end. It is possible=

>> > to configure Py++ to generate code which will contain only bare
>> > minimum of included files.
>>
>> This is certainly an issue for this particular software, but we're pin=
ning
>> our hopes on using pre-compiled headers in GCC 4.2. We will see how th=
at
>> turns out.
>=20
> May be you should consider distributed compilation too.

That is already being done to some extent. I am not doing it, but that is=

mainly because I have enough other things to do that I can let builds run=

for a while and then come back to test things when it finishes. It also
doesn't help that I am using operating environments that are not availabl=
e
beyond the door to my office.

>> [*] In looking at things more closely, I think I found an opportunity
> for a
>> small performance improvement in the generated code that will also
> eliminate
>> the need for treating GLenum as a special case. There will probably be=

> later
>> instances of needing to handle GLenum, though, so it is good to get
> started
>> on this with something that is relatively easy.
>=20
> Do you mean that Py++ can generate better code in some cases? If so I
> would like to know these use-cases and tweak it.

It is generating what I consider to be better code by making use of
information provided by Py++. It is specific to this usage of Py++ becaus=
e
we are injecting custom code to handle this one type conversion.

 -Patrick


--=20
Patrick L. Hartling
VP Engineering, Infiscape Corp.
http://www.infiscape.com/

Re: [pygccxml-development] Utilizing typedef in code generated by Py++

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

On 5/11/07, Patrick Hartling <pa...@in...> wrote:
> The case I have to deal with at the moment involves the return type of a
> member function. The return type is a template class for std::vector-like
> object that takes a template parameter specifying the contained data type.
> In the C++ code, a member function will look like this:
>
>    const OSG::MFGLenum& getValue() const;
>
> OSG::MFGLenum is a typedef for OSG::MField<GLenum,1> (the 1 is for
internal
> usage, I think), and GLenum is in turn a typedef.

Ok, now I can provide better answer.

Py++ has nice feature related to "class typedefs"
http://www.language-binding.net/pyplusplus/documentation/hints.html

Py++ do knows all typedefs related to the class, but uses them only for
aliasing - name of the class for Python user. I think it can use them for
"class registration" too and thus to achieve better portability. Thanks for
this idea.

Can you submit "feature request"(
http://sourceforge.net/tracker/?group_id=118209&atid=684321 )?

> On Linux, the bindings code that gets generated uses
OSG::MField<unsigned,1>
> as the return type, and that is where the problem arises. There is already
> some code being inserted to convert these OSG::MField<> instantiations
into
> boost::python::list, and it turns out that this bit of code is explicitly
> discarding the typedef information as part of stripping the return type
down
> to its "naked" form. Using the original information for the member
function
> return type, I have added what is needed for this case. It is not elegant,
> but it works [*].

I lost you :-(

> > :-) Be sure to read the first link I gave to the end. It is possible
> > to configure Py++ to generate code which will contain only bare
> > minimum of included files.
>
> This is certainly an issue for this particular software, but we're pinning
> our hopes on using pre-compiled headers in GCC 4.2. We will see how that
> turns out.

May be you should consider distributed compilation too.

>
> [*] In looking at things more closely, I think I found an opportunity for
a
> small performance improvement in the generated code that will also
eliminate
> the need for treating GLenum as a special case. There will probably be
later
> instances of needing to handle GLenum, though, so it is good to get
started
> on this with something that is relatively easy.

Do you mean that Py++ can generate better code in some cases? If so I would
like to know these use-cases and tweak it.

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

Re: [pygccxml-development] Utilizing typedef in code generated by Py++

[Patrick H. <pa...@in...>]

Roman Yakovenko wrote:
> On 5/10/07, Patrick Hartling <pa...@in...> wrote:
>> I have run into a case where a typedef used for portability varies in =
the
>> actual type in use. The type being defined is GLenum from OpenGL. On
>> Linux
>> and Windows, the underlying type for GLenum is unsigned int, but on
>> Mac OS
>> X, it is unsigned long. When Py++ generates the Boost.Python bindings
>> code
>> for functions that include GLenum in their signature, it uses the
>> underlying
>> type in the function signature typedef rather than GLenum. This
>> results in
>> compile failures when generating the code on Linux and trying to
>> compile on
>> Mac OS X (or vice versa).
>>
>> In trying to resolve this, I have come up with two questions:
>>
>>    1. Can Py++ generate code that uses typedefs instead of fully expan=
ded
>>       types?
>=20
> Right now it cannot, but it is possible to implement this feature.
> Also you should understand that the user will have to say when Py++
> should use a typedef or real type.

OK. I was trying to find some flag to set or something since I expected t=
his
to be something that the user would have to do. This could be a very usef=
ul
feature to have in the future, especially for the case of typedefs being
used to make code more portable. Losing that thin layer of abstraction ca=
n
lead to problems.

>>    2. Is there a way to have a special case where GLenum can be used
>> in the
>>       generated code and everything else can continue using fully
>> expanded
>>       types?
>=20
> Yes. There are so many ways to implement this in Py++. I don't know
> the exact use case, so I will give you all possible solutions:
>=20
> 1. You can ask Py++ to generate your code instead of the default one:
>  =20
> http://www.language-binding.net/pyplusplus/documentation/inserting_code=
=2Ehtml
>=20
>=20
>    Not the best one
>=20
> 2. Lets say you have function argument or member variable with such
> fully expanded type and you want Py++ to generate typedef - you can
> just replace the type of the variable:
>=20
> from pygccxml import declarations
>=20
> mb =3D module_builder_t( ... )
> f =3D mb.member_function( 'f' )
> #lets say that you want to replace second argument
> f.arguments[1].type =3D declarations.dummy_type_t( 'GLenum' )
>=20
> dummy_type_t documentation
> http://www.language-binding.net/pygccxml/apidocs/pygccxml.declarations.=
cpptypes.dummy_type_t-class.html
>=20
>=20
> If you give some concrete example, may be I will be able to provide
> better answer.

The case I have to deal with at the moment involves the return type of a
member function. The return type is a template class for std::vector-like=

object that takes a template parameter specifying the contained data type=
=2E
In the C++ code, a member function will look like this:

   const OSG::MFGLenum& getValue() const;

OSG::MFGLenum is a typedef for OSG::MField<GLenum,1> (the 1 is for intern=
al
usage, I think), and GLenum is in turn a typedef.

On Linux, the bindings code that gets generated uses OSG::MField<unsigned=
,1>
as the return type, and that is where the problem arises. There is alread=
y
some code being inserted to convert these OSG::MField<> instantiations in=
to
boost::python::list, and it turns out that this bit of code is explicitly=

discarding the typedef information as part of stripping the return type d=
own
to its "naked" form. Using the original information for the member functi=
on
return type, I have added what is needed for this case. It is not elegant=
,
but it works [*].

>> The second question came to mind because this currently affects only t=
wo
>> .cpp files out of over 350 being generated by Py++.
>=20
> :-) Be sure to read the first link I gave to the end. It is possible
> to configure Py++ to generate code which will contain only bare
> minimum of included files.

This is certainly an issue for this particular software, but we're pinnin=
g
our hopes on using pre-compiled headers in GCC 4.2. We will see how that
turns out.

Thanks for the help.

 -Patrick


[*] In looking at things more closely, I think I found an opportunity for=
 a
small performance improvement in the generated code that will also elimin=
ate
the need for treating GLenum as a special case. There will probably be la=
ter
instances of needing to handle GLenum, though, so it is good to get start=
ed
on this with something that is relatively easy.


--=20
Patrick L. Hartling
VP Engineering, Infiscape Corp.
http://www.infiscape.com/

Re: [pygccxml-development] Utilizing typedef in code generated by Py++

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

On 5/10/07, Patrick Hartling <pa...@in...> wrote:
> I have run into a case where a typedef used for portability varies in the
> actual type in use. The type being defined is GLenum from OpenGL. On Linux
> and Windows, the underlying type for GLenum is unsigned int, but on Mac OS
> X, it is unsigned long. When Py++ generates the Boost.Python bindings code
> for functions that include GLenum in their signature, it uses the underlying
> type in the function signature typedef rather than GLenum. This results in
> compile failures when generating the code on Linux and trying to compile on
> Mac OS X (or vice versa).
>
> In trying to resolve this, I have come up with two questions:
>
>    1. Can Py++ generate code that uses typedefs instead of fully expanded
>       types?

Right now it cannot, but it is possible to implement this feature.
Also you should understand that the user will have to say when Py++
should use a typedef or real type.

>    2. Is there a way to have a special case where GLenum can be used in the
>       generated code and everything else can continue using fully expanded
>       types?

Yes. There are so many ways to implement this in Py++. I don't know
the exact use case, so I will give you all possible solutions:

1. You can ask Py++ to generate your code instead of the default one:
    http://www.language-binding.net/pyplusplus/documentation/inserting_code.html

    Not the best one

2. Lets say you have function argument or member variable with such
fully expanded type and you want Py++ to generate typedef - you can
just replace the type of the variable:

from pygccxml import declarations

mb = module_builder_t( ... )
f = mb.member_function( 'f' )
#lets say that you want to replace second argument
f.arguments[1].type = declarations.dummy_type_t( 'GLenum' )

dummy_type_t documentation
http://www.language-binding.net/pygccxml/apidocs/pygccxml.declarations.cpptypes.dummy_type_t-class.html

If you give some concrete example, may be I will be able to provide
better answer.

> The second question came to mind because this currently affects only two
> .cpp files out of over 350 being generated by Py++.

:-) Be sure to read the first link I gave to the end. It is possible
to configure Py++ to generate code which will contain only bare
minimum of included files.

HTH

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

[pygccxml-development] Utilizing typedef in code generated by Py++

[Patrick H. <pa...@in...>]

I have run into a case where a typedef used for portability varies in the=

actual type in use. The type being defined is GLenum from OpenGL. On Linu=
x
and Windows, the underlying type for GLenum is unsigned int, but on Mac O=
S
X, it is unsigned long. When Py++ generates the Boost.Python bindings cod=
e
for functions that include GLenum in their signature, it uses the underly=
ing
type in the function signature typedef rather than GLenum. This results i=
n
compile failures when generating the code on Linux and trying to compile =
on
Mac OS X (or vice versa).

In trying to resolve this, I have come up with two questions:

   1. Can Py++ generate code that uses typedefs instead of fully expanded=

      types?
   2. Is there a way to have a special case where GLenum can be used in t=
he
      generated code and everything else can continue using fully expande=
d
      types?

The second question came to mind because this currently affects only two
=2Ecpp files out of over 350 being generated by Py++.

Thanks in advance.

 -Patrick


--=20
Patrick L. Hartling
VP Engineering, Infiscape Corp.
http://www.infiscape.com/

[pygccxml-development] [ANN] pygccxml & Py++ - 0.9.0

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

Hi all.
I would like to announce new versions of pygccxml and Py++ available.

Changes.

pygccxml
  Performance. The project is 30 - 50 % faster.

Py++
   1. Bug fixes:
          * Declaration of virtual functions that have an exception
specification with an empty throw was fixed. Now the exception
specification is generated properly. Many thanks to Martin Preisler
for reporting the bug.

   2. Added exposing of copy constructor, operator= and operator<<.
          * operator= is exposed under "assign" name
          * operator<< is exposed under "__str__" name

   3. Added new call policies:
          * as_tuple
          * custom_call_policies
          * return_range

   4. Added an initial support for multi-module development. Now you
can mark your declarations as already_exposed and Py++ will do the
rest. For more information read multi-module development guide.

   5. input_c_buffer - new functions transformation, which allows to
pass a Python sequence to function, instead of pair of arguments:
pointer to buffer and size.

   6. Added ability to control generated "include" directives. Now you
can ask Py++ to include a header file, when it generates code for some
declaration. For more information refers to inserting code guide.

   7. Code generation improvements: system header files ( Boost.Python
or Py++ defined ) will be included from the generated files only in
case the generated code depends on them.

   8. Performance improvements: Py++ runs 1.5 - 2 times faster, than
the previous one.

   9. Added ability to add code before overridden and default function
calls. For more information refer to member function API
documentation.

  10. Py++ will generate documentation for automatically constructed
properties. For more information refer to properties guide

  11. Added iteration functionality to Boost.Python Indexing Suite V2
std::map and std::multimap containers.


I would like to thank to every one who contributed to this release -
thank you very much!

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