pygccxml-development

Re: [pygccxml-development] Weird problem apparently caused by decl.readme()

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

On Fri, May 14, 2010 at 3:25 PM, Benoit Leveau
<ben...@mo...> wrote:
> Hello,
>
> I managed to get a minimal script reproducing the problem.
> I have a python script calling the py++ binding, and two header files
> (Base.h and Derived.h). The Base class expose a virtual function called
> 'dummyFunction'. The python script exclude this function from all classes.
> Depending on the command line parameter, the script calls or not calls
> readme() on the classes declarations.
>
> You need to set the GCCXML_PATH environment variable for the script to run,
> or you can edit the python script.
>
> To reproduce the bug, cd to the extracted folder, then type:
>
>> python py_bug_reproduce.py 0
> look in the generated/Derived.pypp.cpp file
> there is nothing exposed in the class
>
> THEN instead:
>
>> python py_bug_reproduce.py 1
> look again in the generated/Derived.pypp.cpp file,
> the dummyFunction is exposed in this case
>
> It seems that it doesn't happen if both classes are in the same header file.

Thank you very much. I was able to reproduce the problem, I am going to deeg :-)


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

Re: [pygccxml-development] Weird problem apparently caused by decl.readme()

[Benoit L. <ben...@mo...>]

Roman Yakovenko wrote:
> On Wed, May 12, 2010 at 8:08 PM, Benoit Leveau
> <ben...@mo...> wrote:
>> Hello,
> 
> Good evening
> 
>> I just found a very odd problem when using py++.
>> I don't have time right now to generate files that exhibit the error,
>> but still thought I would report it.
>> Maybe it sounds familiar to someone.
>>
>> C++ input:
>> - Class A with some virtual functions
>> - Class B inherits from A (and doesn't override the virtual functions)
>>
>> Steps:
>> - The binding code first includes all declarations from A and B (class,
>> functions, variables, etc.).
>> While doing this, it also calls readme() on each declaration.
>> - Later, it calls exclude() on the set of virtual functions, for both
>> classes.
>>
>> Result:
>> In the file generated by py++ for class B, the virtual functions are
>> present.
>>
>> Expected result:
>> The virtual functions have been specifically excluded and should not be
>> present.
>>
>> Cause:
>> When removing the call to readme(), the virtual functions are correctly
>> excluded in the generated files.
>> I verified that it's indeed caused by the call to readme() and not by
>> the fact that some of the code parses the result of the call.
> 
> Interesting. I will take a look, may be I will see something.
> 
> Thanks for reporting.
> 
> 
Hello,

I managed to get a minimal script reproducing the problem.
I have a python script calling the py++ binding, and two header files 
(Base.h and Derived.h). The Base class expose a virtual function called 
'dummyFunction'. The python script exclude this function from all classes.
Depending on the command line parameter, the script calls or not calls 
readme() on the classes declarations.

You need to set the GCCXML_PATH environment variable for the script to 
run, or you can edit the python script.

To reproduce the bug, cd to the extracted folder, then type:

 > python py_bug_reproduce.py 0
look in the generated/Derived.pypp.cpp file
there is nothing exposed in the class

THEN instead:

 > python py_bug_reproduce.py 1
look again in the generated/Derived.pypp.cpp file,
the dummyFunction is exposed in this case

It seems that it doesn't happen if both classes are in the same header file.

I tested it with pyplusplus revision 1835 
(https://pygccxml.svn.sourceforge.net/svnroot/pygccxml/pyplusplus_dev)
and pygccxml revision 1835 
(https://pygccxml.svn.sourceforge.net/svnroot/pygccxml/pygccxml_dev).

Thanks,
Benoit

Re: [pygccxml-development] Weird problem apparently caused by decl.readme()

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

On Wed, May 12, 2010 at 8:08 PM, Benoit Leveau
<ben...@mo...> wrote:
> Hello,

Good evening

> I just found a very odd problem when using py++.
> I don't have time right now to generate files that exhibit the error,
> but still thought I would report it.
> Maybe it sounds familiar to someone.
>
> C++ input:
> - Class A with some virtual functions
> - Class B inherits from A (and doesn't override the virtual functions)
>
> Steps:
> - The binding code first includes all declarations from A and B (class,
> functions, variables, etc.).
> While doing this, it also calls readme() on each declaration.
> - Later, it calls exclude() on the set of virtual functions, for both
> classes.
>
> Result:
> In the file generated by py++ for class B, the virtual functions are
> present.
>
> Expected result:
> The virtual functions have been specifically excluded and should not be
> present.
>
> Cause:
> When removing the call to readme(), the virtual functions are correctly
> excluded in the generated files.
> I verified that it's indeed caused by the call to readme() and not by
> the fact that some of the code parses the result of the call.

Interesting. I will take a look, may be I will see something.

Thanks for reporting.


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

[pygccxml-development] Weird problem apparently caused by decl.readme()

[Benoit L. <ben...@mo...>]

Hello,

I just found a very odd problem when using py++.
I don't have time right now to generate files that exhibit the error, 
but still thought I would report it.
Maybe it sounds familiar to someone.

C++ input:
- Class A with some virtual functions
- Class B inherits from A (and doesn't override the virtual functions)

Steps:
- The binding code first includes all declarations from A and B (class, 
functions, variables, etc.).
While doing this, it also calls readme() on each declaration.
- Later, it calls exclude() on the set of virtual functions, for both 
classes.

Result:
In the file generated by py++ for class B, the virtual functions are 
present.

Expected result:
The virtual functions have been specifically excluded and should not be 
present.

Cause:
When removing the call to readme(), the virtual functions are correctly 
excluded in the generated files.
I verified that it's indeed caused by the call to readme() and not by 
the fact that some of the code parses the result of the call.

Benoit Leveau

Re: [pygccxml-development] Removing copy constructor

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

On Wed, Apr 14, 2010 at 11:32 AM, Benoit Leveau
<ben...@mo...> wrote:
> * default_call_policies
> * return_value_policy
>   - return_opaque_pointer
>   - copy_const_reference
>   - return_by_value
>   - copy_non_const_reference
>   - return_internal_reference <= should be at the same level as
> return_value_policy, else we think we must use return_value_policy(
> return_internal_reference )
> * return self
>
> so this would just be a matter of changing the indentation in
> docs/documentation/functions/call_policies/call_policies.rest

Done: http://pygccxml.svn.sourceforge.net/pygccxml/?rev=1836&view=rev

Thank you.



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

Re: [pygccxml-development] Removing copy constructor

[Benoit L. <ben...@mo...>]

Roman Yakovenko wrote:
> On Tue, Apr 13, 2010 at 5:58 PM, Benoit Leveau
> <ben...@mo...> wrote:
> 
>> using your example, I indeed don't get a copy-constructor, even after
>> "complexifying" the class so it looks more like mine... this is probably
>> something tricky! I'm not sure I really have to bind that class, but I'll
>> let you know if I find where the problem was
> 
> Thanks. "copyable" is the most "fragile" part of the project. That's
> why I has so many tests for it.
>> I was thinking about something. I had a few troubles now and then using the
>> call_policies. I explain:
>> If you want to use "copy_non_const_reference" you use:
>> function.call_policies =
>> call_policies.return_value_policy(call_policies.copy_non_const_reference)
>>
>> but if you want to use return_internal_reference you use:
>> function.call_policies = call_policies.return_internal_reference()
>>
>> I had to look into call_policies.py and from time to time I forget and get
>> some errors (even sometimes py++ doesn't complain but the errors appear at
>> compilation).
>> All these policies are listed in the same section, without any mention that
>> one is a function, the others are string and need to be passed to
>> return_value_policy().
>> It might be useful to add that to the documentation, if it's not already
>> somewhere I missed.
> 
> I tried to implement the interface similar to Boost.Python library:
> 
> http://www.boost.org/doc/libs/1_42_0/libs/python/doc/tutorial/doc/html/python/functions.html#python.call_policies
> 
>     * with_custodian_and_ward: Ties lifetimes of the arguments
>     * with_custodian_and_ward_postcall: Ties lifetimes of the
> arguments and results
>     * return_internal_reference: Ties lifetime of one argument to that of result
>     * return_value_policy<T> with T one of:
>           o reference_existing_object: naive (dangerous) approach
>           o copy_const_reference: Boost.Python v1 approach
>           o copy_non_const_reference:
>           o manage_new_object: Adopt a pointer and hold the instance
> 
> where you replace "< T >" with "( T )", I hoped it will be enough to
> look at Boost.Python documentation and understand how the code (py++)
> should be written.
> 
> Will few comments in the source file fix this or we need to introduce
> some validation checks?

I don't think introducing some validation checks is necessary.
The confusing thing is that the online doc shows a different indentation 
than what you just said:

* default_call_policies
* return_value_policy
    - return_opaque_pointer
    - copy_const_reference
    - return_by_value
    - copy_non_const_reference
    - return_internal_reference <= should be at the same level as 
return_value_policy, else we think we must use return_value_policy( 
return_internal_reference )
* return self

so this would just be a matter of changing the indentation in
docs/documentation/functions/call_policies/call_policies.rest

Re: [pygccxml-development] Removing copy constructor

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

On Tue, Apr 13, 2010 at 5:58 PM, Benoit Leveau
<ben...@mo...> wrote:

> using your example, I indeed don't get a copy-constructor, even after
> "complexifying" the class so it looks more like mine... this is probably
> something tricky! I'm not sure I really have to bind that class, but I'll
> let you know if I find where the problem was

Thanks. "copyable" is the most "fragile" part of the project. That's
why I has so many tests for it.

> I was thinking about something. I had a few troubles now and then using the
> call_policies. I explain:
> If you want to use "copy_non_const_reference" you use:
> function.call_policies =
> call_policies.return_value_policy(call_policies.copy_non_const_reference)
>
> but if you want to use return_internal_reference you use:
> function.call_policies = call_policies.return_internal_reference()
>
> I had to look into call_policies.py and from time to time I forget and get
> some errors (even sometimes py++ doesn't complain but the errors appear at
> compilation).
> All these policies are listed in the same section, without any mention that
> one is a function, the others are string and need to be passed to
> return_value_policy().
> It might be useful to add that to the documentation, if it's not already
> somewhere I missed.

I tried to implement the interface similar to Boost.Python library:

http://www.boost.org/doc/libs/1_42_0/libs/python/doc/tutorial/doc/html/python/functions.html#python.call_policies

    * with_custodian_and_ward: Ties lifetimes of the arguments
    * with_custodian_and_ward_postcall: Ties lifetimes of the
arguments and results
    * return_internal_reference: Ties lifetime of one argument to that of result
    * return_value_policy<T> with T one of:
          o reference_existing_object: naive (dangerous) approach
          o copy_const_reference: Boost.Python v1 approach
          o copy_non_const_reference:
          o manage_new_object: Adopt a pointer and hold the instance

where you replace "< T >" with "( T )", I hoped it will be enough to
look at Boost.Python documentation and understand how the code (py++)
should be written.

Will few comments in the source file fix this or we need to introduce
some validation checks?

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

Re: [pygccxml-development] Removing copy constructor

[Benoit L. <ben...@mo...>]

Benoit Leveau wrote:
> Roman Yakovenko wrote:
>> On Tue, Apr 13, 2010 at 3:11 PM, Benoit Leveau
>> <ben...@mo...> wrote:
>>> That's really interesting...I didn't know py++ was supposed to detect this
>>> case (when a class has a non-copyable member).
>> :-)
>>
>> Take a look on:
>>
>> http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/unittests/data/noncopyable_to_be_exported.hpp?view=markup
>> http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/unittests/noncopyable_tester.py?view=markup
>>
>> and the attached generated file
>>
>>> I'm going to try to reproduce
>>> your example, then i'll introduce my types...hopefully at some point I'll
>>> see what's causing the problem.
>>> I'll let you know what I can find.
>> Cool.
> 
> Thanks a lot! I'll try this in a few minutes..
> I should have looked in the unit tests, I didn't think about it...
using your example, I indeed don't get a copy-constructor, even after 
"complexifying" the class so it looks more like mine... this is probably 
something tricky! I'm not sure I really have to bind that class, but 
I'll let you know if I find where the problem was

I was thinking about something. I had a few troubles now and then using 
the call_policies. I explain:
If you want to use "copy_non_const_reference" you use:
function.call_policies = 
call_policies.return_value_policy(call_policies.copy_non_const_reference)

but if you want to use return_internal_reference you use:
function.call_policies = call_policies.return_internal_reference()

I had to look into call_policies.py and from time to time I forget and 
get some errors (even sometimes py++ doesn't complain but the errors 
appear at compilation).
All these policies are listed in the same section, without any mention 
that one is a function, the others are string and need to be passed to 
return_value_policy().
It might be useful to add that to the documentation, if it's not already 
somewhere I missed.

Benoit

Re: [pygccxml-development] Removing copy constructor

[Benoit L. <ben...@mo...>]

Roman Yakovenko wrote:
> On Tue, Apr 13, 2010 at 3:11 PM, Benoit Leveau
> <ben...@mo...> wrote:
>> That's really interesting...I didn't know py++ was supposed to detect this
>> case (when a class has a non-copyable member).
> 
> :-)
> 
> Take a look on:
> 
> http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/unittests/data/noncopyable_to_be_exported.hpp?view=markup
> http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/unittests/noncopyable_tester.py?view=markup
> 
> and the attached generated file
> 
>> I'm going to try to reproduce
>> your example, then i'll introduce my types...hopefully at some point I'll
>> see what's causing the problem.
>> I'll let you know what I can find.
> 
> Cool.

Thanks a lot! I'll try this in a few minutes..
I should have looked in the unit tests, I didn't think about it...

Re: [pygccxml-development] Removing copy constructor

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

On Tue, Apr 13, 2010 at 3:11 PM, Benoit Leveau
<ben...@mo...> wrote:
> That's really interesting...I didn't know py++ was supposed to detect this
> case (when a class has a non-copyable member).

:-)

Take a look on:

http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/unittests/data/noncopyable_to_be_exported.hpp?view=markup
http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/unittests/noncopyable_tester.py?view=markup

and the attached generated file

> I'm going to try to reproduce
> your example, then i'll introduce my types...hopefully at some point I'll
> see what's causing the problem.
> I'll let you know what I can find.

Cool.

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

Re: [pygccxml-development] Removing copy constructor

[Benoit L. <ben...@mo...>]

Roman Yakovenko wrote:
> On Tue, Apr 13, 2010 at 2:40 PM, Benoit Leveau
> <ben...@mo...> wrote:
>> Hi,
>>
>> I have a problem with a class I try to bind (how original!).
> 
> I hope py++ is part of the solution. If you have comments how it could
> be improved - I'll be glad to get them.
So far, everything is going well ;)

>> It has a boost::mutex member (which is non-copyable).
>> My class itself has no explicitely defined copy-constructor.
>> ==> py++ tries to access this copy-constructor in the wrapper class
>> copy-constructor.
>>
>> class MyClass
>> {
>> public:
>>    MyClass(){....}
>>    // ....
>> protected:
>>    // ....
>>    boost::mutex m_mutex;
>>    // ....
>> };
>>
>> struct MyClassWrapper : MyClass, bp::wrapper<MyClass> {
>>     MyClassWrapper(MyClass const & arg ) : MyClass( arg ), bp::wrapper<
>> MyClass >()
>>     {
>>           // copy constructor
>>     }
>>
>>     // other stuff....
>>     // ...
>> };
>>
>> I tried to set the class.copyable to False, but py++ still generates the
>> same code...
>>
>> Any clue?
> 
> 
> No. I have the following test: ( see noncopyable_to_be_exported.hpp file )
> 
> 
> C++ code:
> 
> 
> 
> class c_t : public boost::noncopyable{
> 
> public:
> 
>     static char get_c(){ return 'c'; }
> 
> 
> 
> };
> 
> struct e_t{
> 
>     virtual void do_smth() = 0;
> 
> private:
> 
>     c_t c;
> 
> };
> 
> 
> The generated code (without tweaking) is the following:
> 
> namespace bp = boost::python;
> 
> struct e_t_wrapper : noncopyables::e_t, bp::wrapper< noncopyables::e_t > {
> 
>     virtual void do_smth(  ){
>         bp::override func_do_smth = this->get_override( "do_smth" );
>         func_do_smth(  );
>     }
> 
> };
 > Can you provide more details?

That's really interesting...I didn't know py++ was supposed to detect 
this case (when a class has a non-copyable member). I'm going to try to 
reproduce your example, then i'll introduce my types...hopefully at some 
point I'll see what's causing the problem.
I'll let you know what I can find.

Re: [pygccxml-development] Removing copy constructor

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

On Tue, Apr 13, 2010 at 2:40 PM, Benoit Leveau
<ben...@mo...> wrote:
> Hi,
>
> I have a problem with a class I try to bind (how original!).

I hope py++ is part of the solution. If you have comments how it could
be improved - I'll be glad to get them.

Some time ago I wrote "easy extending guide"(
http://language-binding.net/pyplusplus/troubleshooting_guide/easy_extending_guide/easy_extending_guide.html
). Only pretty simple code could be wrapped without problems.

> It has a boost::mutex member (which is non-copyable).
> My class itself has no explicitely defined copy-constructor.
> ==> py++ tries to access this copy-constructor in the wrapper class
> copy-constructor.
>
> class MyClass
> {
> public:
>    MyClass(){....}
>    // ....
> protected:
>    // ....
>    boost::mutex m_mutex;
>    // ....
> };
>
> struct MyClassWrapper : MyClass, bp::wrapper<MyClass> {
>     MyClassWrapper(MyClass const & arg ) : MyClass( arg ), bp::wrapper<
> MyClass >()
>     {
>           // copy constructor
>     }
>
>     // other stuff....
>     // ...
> };
>
> I tried to set the class.copyable to False, but py++ still generates the
> same code...
>
> Any clue?


No. I have the following test: ( see noncopyable_to_be_exported.hpp file )


C++ code:



class c_t : public boost::noncopyable{

public:

    static char get_c(){ return 'c'; }



};

struct e_t{

    virtual void do_smth() = 0;

private:

    c_t c;

};


The generated code (without tweaking) is the following:

namespace bp = boost::python;

struct e_t_wrapper : noncopyables::e_t, bp::wrapper< noncopyables::e_t > {

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

};


Can you provide more details?


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

[pygccxml-development] Removing copy constructor

[Benoit L. <ben...@mo...>]

Hi,

I have a problem with a class I try to bind (how original!).

It has a boost::mutex member (which is non-copyable).
My class itself has no explicitely defined copy-constructor.
==> py++ tries to access this copy-constructor in the wrapper class 
copy-constructor.

class MyClass
{
public:
    MyClass(){....}
    // ....
protected:
    // ....
    boost::mutex m_mutex;
    // ....
};

struct MyClassWrapper : MyClass, bp::wrapper<MyClass> {
     MyClassWrapper(MyClass const & arg ) : MyClass( arg ), bp::wrapper< 
MyClass >()
     {
           // copy constructor
     }

     // other stuff....
     // ...
};

I tried to set the class.copyable to False, but py++ still generates the 
same code...

Any clue?

Thanks!

Benoit

Re: [pygccxml-development] Parsing a single header file for the whole project

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

2010/4/1 Benoît Leveau <ben...@gm...>:
> What I ended up doing is:
> creating a temporary file with a list of #include "header_path" then
> constructing the module_builder_t with this file.
>
> I first tried with create_text_fc but if you do that, in all the cpp
> files generated by py++ , you won't get any include, so nothing will
> compile.

create_text_fc takes as argument valid C++ code. It is very useful for
small tests:

mb = module_builder.module_builder_t(  [
module_builder.create_text_fc( 'namespace enums{ enum color{ red = 1};
}' )]
            , gccxml_path=autoconfig.gccxml.executable,
compiler=pygccxml.utils.native_compiler.get_gccxml_compiler() )

mb.namespace( name='::enums' ).include()

> The only weird thing now is that in all the cpp files, they all
> include this temp file, so I need to keep this temp file for building.

I believe you will end making that file "permanent". You will add
there few work around and template instantiations.

> I didn't know this create_cached_source... I'll try that to see if
> that solves my problem.

It will save you compilation of source files with gccxml, py++ will
still have to parse the generated xml file.

> I remember I tried the cache=cache_file_path option to
> module_builder_t constructor, but it was not helping at all.
> Each time the cache file was read, then recreated, and the generation
> time was almost the same as without any cache.

I guess, it was recreated because you generated temp file each time (
may be I wrong ).

>From the benchmarks I did, "pickling" declarations tree was much
slower then recreating it from the existing xml file.

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

Re: [pygccxml-development] Parsing a single header file for the whole project

[Benoît L. <ben...@gm...>]

What I ended up doing is:
creating a temporary file with a list of #include "header_path" then
constructing the module_builder_t with this file.

I first tried with create_text_fc but if you do that, in all the cpp
files generated by py++ , you won't get any include, so nothing will
compile.
The only weird thing now is that in all the cpp files, they all
include this temp file, so I need to keep this temp file for building.
I didn't know this create_cached_source... I'll try that to see if
that solves my problem.

I remember I tried the cache=cache_file_path option to
module_builder_t constructor, but it was not helping at all.
Each time the cache file was read, then recreated, and the generation
time was almost the same as without any cache.

Le 1 avril 2010 17:27, Roman Yakovenko <rom...@gm...> a écrit :
> 2010/4/1 Benoît Leveau <ben...@gm...>:
>> Hi all,
>
> Good evening.
>
>> There's something that's driving me mad, and I'm sure it's really
>> basic or simple to fix.
>> I have a big project to bind and parsing all the files takes a lot of
>> time, and finally hit the 8GB point at which I prefer to kill the
>> process.
>
> Take a look on "pygccxml.parser.project_reader.create_cached_source_fc(header,
> cached_source_file)" function (
> http://language-binding.net/pygccxml/apidocs/parser.html )
>
> It will allow you to save gccxml compilation time.
>
> If you can send me( privatly ) gccxml generated file, I can try to
> improve py++/pygccxml performance.
>
>> In the "Best practices" page, it is suggested to "Create one header
>> file, which will include all project header files."
>
> pygccxml is able to merge results from different gccxml invocation,
> but from my experience it will take more time and memory.
>
> Did you include all your projects in that file or a single one? Ogre
> 3D engine is pretty big project, but even it doesn't consumes so much
> memory.
>
> --
> Roman Yakovenko
> C++ Python language binding
> http://www.language-binding.net/
>

Re: [pygccxml-development] Parsing a single header file for the whole project

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

2010/4/1 Benoît Leveau <ben...@gm...>:
> Hi all,

Good evening.

> There's something that's driving me mad, and I'm sure it's really
> basic or simple to fix.
> I have a big project to bind and parsing all the files takes a lot of
> time, and finally hit the 8GB point at which I prefer to kill the
> process.

Take a look on "pygccxml.parser.project_reader.create_cached_source_fc(header,
cached_source_file)" function (
http://language-binding.net/pygccxml/apidocs/parser.html )

It will allow you to save gccxml compilation time.

If you can send me( privatly ) gccxml generated file, I can try to
improve py++/pygccxml performance.

> In the "Best practices" page, it is suggested to "Create one header
> file, which will include all project header files."

pygccxml is able to merge results from different gccxml invocation,
but from my experience it will take more time and memory.

Did you include all your projects in that file or a single one? Ogre
3D engine is pretty big project, but even it doesn't consumes so much
memory.

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

Re: [pygccxml-development] Parsing a single header file for the whole project

[Benoît L. <ben...@gm...>]

I've just realized this is the same topic as another thread, which
should help me fix my problem.
Don't know how I could miss it the first time....
So, you can ignore this thread.

Le 1 avril 2010 14:38, Benoît Leveau <ben...@gm...> a écrit :
> Hi all,
>
> There's something that's driving me mad, and I'm sure it's really
> basic or simple to fix.
> I have a big project to bind and parsing all the files takes a lot of
> time, and finally hit the 8GB point at which I prefer to kill the
> process.
> In the "Best practices" page, it is suggested to "Create one header
> file, which will include all project header files.". I've tried that,
> both manually (creating the file on disk and then only parsing this
> file), or automatically (using module_builder.create_text_fc to
> construct a file based on a list of files), and in both ways py++
> doesn't generate any binding.
>
> I mean if I try to parse:
> - A.h and B.h I will get the wrappers for the classes from these files,
> - but if I try with a X.h which contains
> #include "A.h"
> #include "B.h"
> nothing is wrapped by Py++.
>
> I only get these files generated:
> exposed_decl.pypp.txt
> PROJECTNAME.main.cpp (this file is almost empty, ie. it doesn't
> register any class)
> named_tuple.py
>
> Any idea, clue?
>
> Thanks for your help.
>

[pygccxml-development] Parsing a single header file for the whole project

[Benoît L. <ben...@gm...>]

Hi all,

There's something that's driving me mad, and I'm sure it's really
basic or simple to fix.
I have a big project to bind and parsing all the files takes a lot of
time, and finally hit the 8GB point at which I prefer to kill the
process.
In the "Best practices" page, it is suggested to "Create one header
file, which will include all project header files.". I've tried that,
both manually (creating the file on disk and then only parsing this
file), or automatically (using module_builder.create_text_fc to
construct a file based on a list of files), and in both ways py++
doesn't generate any binding.

I mean if I try to parse:
- A.h and B.h I will get the wrappers for the classes from these files,
- but if I try with a X.h which contains
#include "A.h"
#include "B.h"
nothing is wrapped by Py++.

I only get these files generated:
exposed_decl.pypp.txt
PROJECTNAME.main.cpp (this file is almost empty, ie. it doesn't
register any class)
named_tuple.py

Any idea, clue?

Thanks for your help.

Re: [pygccxml-development] runs py++ on mac osx 10.6.2

[Massimo Di S. <mas...@gm...>]

Hi Roman,

this a message from the gccxml list :



Inizio messaggio inoltrato:

> Da: Brad King <bra...@ki...>
> Data: 08 marzo 2010 14.44.10 GMT+01.00
> A: Massimo Di Stefano <mas...@gm...>
> Cc: gc...@gc...
> Oggetto: Re: [GCC-XML] runs py++ on mac osx 10.6.2
> 
> Massimo Di Stefano wrote:
>> http://paste.debian.net/62716/
>> 
>> have you any clue on what'swrong ?
>> the same example file works fine on linux, 
>> so i guess my py++ installation on osx is broken :'(
>> 
>> Is it possible that for some reason gccxml uses Objective C/C++ headers?
> 
> gccxml detects the include path used by the target compiler
> and simulates its preprocessor.  If that ends up including
> Objective C/C++ code then it won't know the difference.
> 
> You can use the "--print" or "--debug" option to gccxml to
> see what it detects about the target compiler.
> 
> -Brad


this is my gcc -version :

MacBook-Pro-15-di-Massimo-Di-Stefano:vitables-839c604ba964 sasha$ gcc -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5646.1~2/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5646) (dot 1)


please,  can you suggest me a way to try to debug the problem ?
how to use the command line to test what's wrong ?

thanks for any help!!!

regards,

Massimo.



Il giorno 06/mar/2010, alle ore 10.53, Roman Yakovenko ha scritto:

> On Sat, Mar 6, 2010 at 11:20 AM, Massimo Di Stefano
> <mas...@gm...> wrote:
>> Hi All
>> 
>> i'm tring to use py++ on mac osx
>>  .. i'm having some problems,
>> i hope you can help me
>> 
>> running py++ gui module on the example file :
>> 
>> http://paste.debian.net/62714/
>> 
>> i get this error :
>> 
>> http://paste.debian.net/62716/
>> 
>> have you any clue on what'swrong ?
>> the same example file works fine on linux,
>> so i guess my py++ installation on osx is broken :'(
>> 
>> let me know if i need to give you more details,
>> thanks for any suggestion!
> 
> Unfortunately I don't have access to any Mac computer. I think the
> best way to handle this problem is to take it to gccxml mailing list.
> The problem is with your gccxml installation.
> 
> When Py++ runs gccxml it prints the command line used. You can use it
> to better understand what the problem is.
> 
> Is it possible that for some reason gccxml uses Objective C/C++ headers?
> 
> 
> -- 
> Roman Yakovenko
> C++ Python language binding
> http://www.language-binding.net/

Re: [pygccxml-development] runs py++ on mac osx 10.6.2

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

On Sat, Mar 6, 2010 at 11:20 AM, Massimo Di Stefano
<mas...@gm...> wrote:
> Hi All
>
> i'm tring to use py++ on mac osx
>  .. i'm having some problems,
> i hope you can help me
>
> running py++ gui module on the example file :
>
> http://paste.debian.net/62714/
>
> i get this error :
>
> http://paste.debian.net/62716/
>
> have you any clue on what'swrong ?
> the same example file works fine on linux,
> so i guess my py++ installation on osx is broken :'(
>
> let me know if i need to give you more details,
> thanks for any suggestion!

Unfortunately I don't have access to any Mac computer. I think the
best way to handle this problem is to take it to gccxml mailing list.
The problem is with your gccxml installation.

When Py++ runs gccxml it prints the command line used. You can use it
to better understand what the problem is.

Is it possible that for some reason gccxml uses Objective C/C++ headers?


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

[pygccxml-development] runs py++ on mac osx 10.6.2

[Massimo Di S. <mas...@gm...>]

Hi All

i'm tring to use py++ on mac osx
 .. i'm having some problems, 
i hope you can help me

running py++ gui module on the example file : 

http://paste.debian.net/62714/

i get this error : 

http://paste.debian.net/62716/

have you any clue on what'swrong ?
the same example file works fine on linux, 
so i guess my py++ installation on osx is broken :'(

let me know if i need to give you more details,
thanks for any suggestion!

regards,
Mssimo.

Re: [pygccxml-development] Default template parameters

[Berserker <ber...@ho...>]

> Yes. I suggest you to read the following document:
> http://language-binding.net/pygccxml/upgrade_issues.html
 
> The bottom line  - change argument default value:
 
> mb.calldef( 'test' ).arguments[0].default_value = mb.calldef( 'test'
> ).arguments[0].default_value + '()'
 
> HTH

Thanks for the help
 		 	   		  
_________________________________________________________________
La tua privacy è al sicuro con Internet Explorer 8. Scopri di più
http://www.microsoft.com/italy/windows/internet-explorer/features/browse-privately.aspx?tabid=2&catid=1

Re: [pygccxml-development] Default template parameters

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

On Wed, Feb 17, 2010 at 1:49 PM, Berserker <ber...@ho...> wrote:
> Hi, I found a problem in the wrapper code generated by Py++ on functions
> with default template parameters (with more than one template parameter)
> Example:
>
> class Foo
> {
> public:
>    void test( const std::map<std::string, std::string> & p =
>    std::map<std::string, std::string>() );
> };
>
> Py++ actually generates:
>
> struct Foo_wrapper : public ...
> {
>
> static void test( ::Foo & inst, std::map< std::string, std::string > const &
> p = std::map<std::basic_string<char, std::char_traits<char>,
> std::allocator<char> >, std::basic_string<char, std::char_traits<char>,
> std::allocator<char> > >() )
> {
> // My pre_call_code
>
> inst.test(p);
>
> // My post_call_code
> }
>
> }
>
> and
>
> typedef void ( *test_function_type )( ::Foo &,std::map<std::string,
> std::string> const & );
>
> Foo_exposer.def(
> "test"
> , test_function_type( &Foo_wrapper::test )
> , ( ::boost::python::arg("inst"),
> ::boost::python::arg("p")=std::map<std::basic_string<char,
> std::char_traits<char>, std::allocator<char> >, std::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >() ) );
>
> On VC8 this code compiles fine, but on GCC ( due to a bug reported here
> http://stackoverflow.com/questions/851584/default-template-class-argument-confuses-g
> )
> it doesn't. On the last GCC version this problem seems fixed but on GCC 4.2
> (tested on MAC)
> I can reproduce it.
>
> Is there a quick fix to "protect" default arguments with ( )? An alternative
> solution would
> be to define an "alias" for the template, something like this:
>
> struct Foo_wrapper : public ...
> {
>
> static void test( ::Foo & inst, std_map_string_string const & p=
> std_map_string_string() )
> {
> // My pre_call_code
> inst.test(p);
> // My post_call_code
> }
>
> }
>
> and
>
> typedef void ( *test_function_type )( ::Foo &,std_map_string_string const &
> );
>
> Foo_exposer.def(
> "test"
> , test_function_type( &Foo_wrapper::test )
> , ( ::boost::python::arg("inst"),
> ::boost::python::arg("p")=std_map_string_string() ) );
>
>
> is it already possible?

Yes. I suggest you to read the following document:
http://language-binding.net/pygccxml/upgrade_issues.html

The bottom line  - change argument default value:

mb.calldef( 'test' ).arguments[0].default_value = mb.calldef( 'test'
).arguments[0].default_value + '()'

HTH

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

[pygccxml-development] Default template parameters

[Berserker <ber...@ho...>]

Hi, I found a problem in the wrapper code generated by Py++ on functions 
with default template parameters (with more than one template parameter)
Example:

class Foo
{
public:
   void test( const std::map<std::string, std::string> & p =
   std::map<std::string, std::string>() );
};

Py++ actually generates:

struct Foo_wrapper : public ...
{

static void test( ::Foo & inst, std::map< std::string, std::string > const & p = std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >() )
{
// My pre_call_code

inst.test(p);

// My post_call_code
}

}

and

typedef void ( *test_function_type )( ::Foo &,std::map<std::string, std::string> const & );
            
Foo_exposer.def(
"test"
, test_function_type( &Foo_wrapper::test )
, ( ::boost::python::arg("inst"), ::boost::python::arg("p")=std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >() ) );

On VC8 this code compiles fine, but on GCC ( due to a bug reported here
http://stackoverflow.com/questions/851584/default-template-class-argument-confuses-g )
it doesn't. On the last GCC version this problem seems fixed but on GCC 4.2 (tested on MAC)
I can reproduce it.

Is there a quick fix to "protect" default arguments with ( )? An alternative solution would
be to define an "alias" for the template, something like this:

struct Foo_wrapper : public ...

{



static void test( ::Foo & inst, std_map_string_string const & p= std_map_string_string() )

{

// My pre_call_code

inst.test(p);

// My post_call_code

}



}

and

typedef void ( *test_function_type )( ::Foo 
&,std_map_string_string const & );

            

Foo_exposer.def(

"test"

, test_function_type( &Foo_wrapper::test )

, ( ::boost::python::arg("inst"), 
::boost::python::arg("p")=std_map_string_string() ) );




is it already possible?

Bye
 		 	   		  
_________________________________________________________________
Personalizza la tua vita digitale, scarica i nuovi gadget!
http://www.pimpit.it/

Re: [pygccxml-development] USE_CALLDEF_ORGANIZER

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

On Fri, Jan 29, 2010 at 11:25 AM, Berserker <ber...@ho...> wrote:
>> I also changed the methods names, so they will not be private. All you
>> need is to redefine "cmp_calldefs" and to introduce your logic. Both
>> functions have same number of required arguments. You can take a look
>> on pygccxml.declarations.type_traits module, which contains many
>> useful functions.
>>
>> Enjoy.
>
> Shouldn't algorithm.registration_order.select_problematics be changed
> according to this patch?Actually it's:
>
> def select_problematics( calldef ):
> """Return list of problematic functions for function "calldef" """
> if 1 != len( calldef.required_args ):
>    return []
> ...

Yes, it should. I will fix it in a few days.Thanks for noting this.


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