pygccxml-development

[pygccxml-development] Any recent commits that may affect performance

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

Have there been any recent commits (past 1-2 months) that may have had a 
significant affect on performance in py++?

I just update to the latest svn version and my code generation process 
is back up around 15 minutes.  Is there anything I should look for as a 
cause?

-Allen

Re: [pygccxml-development] code generation problem, py++ bug??

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

On 1/10/07, Allen Bierbaum <al...@vr...> wrote:
> Ok.  Thanks.  One last question, is it possible for Py++ to detect that
> this gccxml bug is happening and output a warning tell the user they
> need to do something?  I am guessing that it is not or you would have
> already done it right. :)

http://language-binding.net/pygccxml/design.html#patchers

While working on few Python bindings I discovered few errors. For some of them
I was able to create a fix. In this case, right now, I am not able to
create it.

> I am only asking because for me as a user, I have to admit I probably
> never would have traced this back to a bug in gccxml or this reference
> on the webpage.

That is exactly the reason this list exists.

> Thanks for the assistance.

My pleasure

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

Re: [pygccxml-development] code generation problem, py++ bug??

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

Roman Yakovenko wrote:
> On 1/10/07, Allen Bierbaum <al...@vr...> wrote:
>> Roman:
>>
>> Note: I am e-mailing you directly because I have a bug report with a
>> rather large attachment so I didn't want to blanket everyone on the list
>> with the file.
> 
> The support will be given on the mailing list. Thus my answers available to
> other users too.

Of course.  As I said I just didn't want everyone to receive a 1MB file 
in their e-mail. :)


>> If you extract the attached file it will create a directory called
>> pypp_vector_problem.  There is a python py++ generation script, an
>> gccxml XML file, and example output.  I have also attached the header
>> file that has the methods I am trying to wrap.  I am using the latest
>> svn HEAD but I have also replicated this problem with several older
>> versions of Py++ from a couple months ago.
> 
> I will appreciate if next time you at least will try to create small
> test case that
> reproduce the problem:
> 
> #include <vector>
> 
> namespace osg{
>     struct node{};
>     node* clone_tree( const std::vector<std::string>
> &types=std::vector<std::string>() );
> }
> 
> That is all the code needed to reproduce the error.

Ok.  I thought it was going to be more then that since the other methods 
worked and this one didn't.  I apologize for not stripping things down 
further.

>> The problem is the 'bp::arg("...")=vector<' parts of the generated
>> code.  This shows up for multiple of the generated methods.  Because it
>> does not use std::vector the compiler can not build the code and fails
>> pretty miserably.
>>
>> I have checked older versions of Py++ and it looks like this has been
>> the way the code works for quite a while.
>>
>> Do you have any ideas?  Is there something I am missing here or am I
>> just misusing Boost.Python in some way?  Is it a bug in Py++?
> 
> This is a gccxml bug:
> http://www.language-binding.net/pygccxml/design.html#patchers
> In this case I cannot create patcher. Also I hope I will be able to do
> this in future.
> I can explain why if you want.
> 
> What should you do in order to compile the generated code:
> mb = module_builder_t( ....)
> mb.code_creator.add_namespace_usage( 'std' )
> 
> This should solve the problem. The functionality presents even in very
> old version
> of Py++. If it does not help you have to change default value strings:
> 
> for arg in f.arguments:
>     arg.default_value = ...
> 
> Or you can ask Py++ to generate code without default arguments:
> f.use_default_arguments = False
> 
> Or you can use BOOST_PYTHON_FUNCTION_OVERLOADS macro as explained
> here: http://www.language-binding.net/pyplusplus/documentation/functions/overloading.html#overloading-using-macros
> 
> You have plenty of options to deal with the bug

Ok.  Thanks.  One last question, is it possible for Py++ to detect that 
this gccxml bug is happening and output a warning tell the user they 
need to do something?  I am guessing that it is not or you would have 
already done it right. :)

I am only asking because for me as a user, I have to admit I probably 
never would have traced this back to a bug in gccxml or this reference 
on the webpage.

Thanks for the assistance.

-Allen

> 

Re: [pygccxml-development] Current status on additional caching support

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

On 1/10/07, Matthias Baas <ba...@ir...> wrote:
> Allen Bierbaum wrote:
> > I know that Matthias had proposed some ideas in October that would
> > minimize the number of symbols pulled in from gccxml.  What ever
> > happened with that effort?  Are you still using it Matthias?
>
> Yes, so far I'm still using it. Maybe with some additional work I could
> have also used the -fxml-start option from gccxml but at least an
> initial quick test had revealed some slight problems with it (I don't
> remember the details though).
> My other optimization stuff in pypp_api (i.e. the query cache) is still
> not committed because I still have to catch up with the current version
> of Py++.
>
> I'm currently trying to get everything working on OSX as I got myself a
> new Apple notebook. Basically it all works already, but I have to clean
> up some stuff. Maybe after that I can look into getting the current
> version of Py++ (but I'm afraid this will mean that I have to update a
> lot of things in my code to get it working with the latest version).

Except function transformation, everything should work.


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

Re: [pygccxml-development] svn rev # for release times

[Matthias B. <ba...@ir...>]

Allen Bierbaum wrote:
> Does anyone know where I could find the revision numbers for the various 
> py++ releases?  Are there tags somewhere in the svn repository that I am 
> missing.

That's not done automatically (svn cannot know when Roman does a 
release). Maybe if there's a file that only changes when a release is 
done (is there a file that just contains the version number?) then you 
could inspect the logs for that file.

> I am trying to find this because one of my projects that had been 
> working now has a code generation bug (ie. py++ generates code that 
> won't compile).  I am trying to track down the specific revision that 
> caused the problem so I can point at something for Roman to look at.

You can do an "update" on your Py++ repository and specify a revision 
number using the -r option. That way you can also go *back* with the 
revision numbers to restore an older version.
To find out what revision contains a suspicious modification you can use 
the svn browser on the SF site to inspect what has changed between 
revisions: 
http://pygccxml.svn.sourceforge.net/viewvc/pygccxml?view=rev&revision=864

- Matthias -

Re: [pygccxml-development] Current status on additional caching support

[Matthias B. <ba...@ir...>]

Allen Bierbaum wrote:
> I know that Matthias had proposed some ideas in October that would 
> minimize the number of symbols pulled in from gccxml.  What ever 
> happened with that effort?  Are you still using it Matthias?

Yes, so far I'm still using it. Maybe with some additional work I could 
have also used the -fxml-start option from gccxml but at least an 
initial quick test had revealed some slight problems with it (I don't 
remember the details though).
My other optimization stuff in pypp_api (i.e. the query cache) is still 
not committed because I still have to catch up with the current version 
of Py++.

I'm currently trying to get everything working on OSX as I got myself a 
new Apple notebook. Basically it all works already, but I have to clean 
up some stuff. Maybe after that I can look into getting the current 
version of Py++ (but I'm afraid this will mean that I have to update a 
lot of things in my code to get it working with the latest version).

- Matthias -

Re: [pygccxml-development] code generation problem, py++ bug??

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

On 1/10/07, Allen Bierbaum <al...@vr...> wrote:
> Roman:
>
> Note: I am e-mailing you directly because I have a bug report with a
> rather large attachment so I didn't want to blanket everyone on the list
> with the file.

The support will be given on the mailing list. Thus my answers available to
other users too.

> If you extract the attached file it will create a directory called
> pypp_vector_problem.  There is a python py++ generation script, an
> gccxml XML file, and example output.  I have also attached the header
> file that has the methods I am trying to wrap.  I am using the latest
> svn HEAD but I have also replicated this problem with several older
> versions of Py++ from a couple months ago.

I will appreciate if next time you at least will try to create small
test case that
reproduce the problem:

#include <vector>

namespace osg{
    struct node{};
    node* clone_tree( const std::vector<std::string>
&types=std::vector<std::string>() );
}

That is all the code needed to reproduce the error.


> The problem is the 'bp::arg("...")=vector<' parts of the generated
> code.  This shows up for multiple of the generated methods.  Because it
> does not use std::vector the compiler can not build the code and fails
> pretty miserably.
>
> I have checked older versions of Py++ and it looks like this has been
> the way the code works for quite a while.
>
> Do you have any ideas?  Is there something I am missing here or am I
> just misusing Boost.Python in some way?  Is it a bug in Py++?

This is a gccxml bug:
http://www.language-binding.net/pygccxml/design.html#patchers
In this case I cannot create patcher. Also I hope I will be able to do
this in future.
I can explain why if you want.

What should you do in order to compile the generated code:
mb = module_builder_t( ....)
mb.code_creator.add_namespace_usage( 'std' )

This should solve the problem. The functionality presents even in very
old version
of Py++. If it does not help you have to change default value strings:

for arg in f.arguments:
    arg.default_value = ...

Or you can ask Py++ to generate code without default arguments:
f.use_default_arguments = False

Or you can use BOOST_PYTHON_FUNCTION_OVERLOADS macro as explained
here: http://www.language-binding.net/pyplusplus/documentation/functions/overloading.html#overloading-using-macros

You have plenty of options to deal with the bug

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

Re: [pygccxml-development] svn rev # for release times

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

On 1/9/07, Allen Bierbaum <al...@vr...> wrote:
> Roman et al:
>
> Does anyone know where I could find the revision numbers for the various
> py++ releases?  Are there tags somewhere in the svn repository that I am
> missing.
>
> I am trying to find this because one of my projects that had been
> working now has a code generation bug (ie. py++ generates code that
> won't compile).  I am trying to track down the specific revision that
> caused the problem so I can point at something for Roman to look at.

Unfortunately I didn't put the tags. I don't know SVN pretty well.

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

[pygccxml-development] svn rev # for release times

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

Roman et al:

Does anyone know where I could find the revision numbers for the various 
py++ releases?  Are there tags somewhere in the svn repository that I am 
missing.

I am trying to find this because one of my projects that had been 
working now has a code generation bug (ie. py++ generates code that 
won't compile).  I am trying to track down the specific revision that 
caused the problem so I can point at something for Roman to look at.

-Allen

[pygccxml-development] [new feature]aliases test

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

Hello. I added new feature - aliases test.
In huge projects with a lot of templates it is possible, by accident,
to give same alias
to 2 different classes. Py++ will check this situation and will print warning.

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

Re: [pygccxml-development] Current status on additional caching support

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

On 1/6/07, Allen Bierbaum <al...@vr...> wrote:
> If you look at goodi_perf_overrides.mb_override__init__ you can get a
> good idea of what I was caching.
> ...
> Is that clear for a definition?  As far as implementation, you can see
> how I implemented it but I am fine with any implementation you want to use.

Now I remember what I didn't like - the implementation :-(.
I think Py++ should define new class that derives from pygccxml cache class and
implements all the work. Thus you will eliminate the unnecessary dumping of the
whole declaration tree. In your current implementation it will happen twice.

Also before introducing such functionality I would like to know the numbers.
How much time it will save to you?

Allen performance is not a top priority right now. The top priorities are:
* to improve alias handling in the huge projects
* single click setup for the whole environment
* better documentation
* new transformers

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

Re: [pygccxml-development] Current status on additional caching support

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

Roman Yakovenko wrote:
> On 1/5/07, Allen Bierbaum <al...@vr...> wrote:
>   
>> I have been out of the loop for a couple of months and I was wondering
>> what the current status on supporting additional caching with py++ is.
>>     
>
> There were no changes in this area.
>
>   
>> I know that Matthias had proposed some ideas in October that would
>> minimize the number of symbols pulled in from gccxml.  What ever
>> happened with that effort?  Are you still using it Matthias?
>>     
>
> module_builder_t.__init__ has "start_with_declarations" argument.
> Take a look on GCC-XML help to find out more about it
>
>   
>> I had tried to increase performance by caching the decl parsing and
>> query optimization run in module_builder.init().  This worked very well
>> for me and I have code in goodie_perf_overrides.py that worked last time
>> I tried, but alas this code seems to have broken since the last time I
>> used it.  My guess is that module builder is now changed.
>>     
>
> May be. I don't support\upgrade goodies.
>   
Yep.  And I would not expect you too.  When I did the update to the 
latest py++ I expected that this would break.
>   
>> Roman: Is this idea of caching additional parts of the module builder
>> initialization something you are interested in integrating into Py++?
>>     
>
> Yes, but you will have to define exactly what you want. The previous one,
> implementation and definition, was problematic.
>   

If you look at goodi_perf_overrides.mb_override__init__ you can get a 
good idea of what I was caching.

The idea is this:

When the module builder is initialized in 
builder.module_builder_t.__init__, it goes through the following steps:

1 - parse the files using gccxml
2 - combine/merge/process all the parsed declarations
3 - run the query optimizer

All of this ends up in the __global_ns member of module_builder.  With 
the current caching in Py++ (non-goodies), the only thing that gets 
cached is the running of the files through gccxml (correct me if I am 
wrong here).  If the source files don't change then the processing from 
steps 2 and 3 is still done on the exact same input even though it will 
have the exact same output.  What my code did was cache the data in 
__global_ns after all the initial processing in module_builder.__init__ 
was complete.

Is that clear for a definition?  As far as implementation, you can see 
how I implemented it but I am fine with any implementation you want to use.

-Allen


>   
>> Are there any other optimizations floating around?
>>     
>
> No. Py++ is pretty usable and fast for me.
>
>   
>> If you can't tell
>> already I am pretty focused on performance on Py++.  In our workflow we
>> do a lot of iterative development and any tool that runs slow can grind
>> development progress to a halt.
>>     
>
> Py++ is now 20 - 30 % slower than it was. New features "dependency manager"
> and warnings introduced additional slowness. Patches are always welcome.
>
>   
>> Anyway, I just wanted to check in and see what is new that I should be
>> looking into.
>>     
>
> http://language-binding.net/pyplusplus/history/history.html
>
>   

Re: [pygccxml-development] Current status on additional caching support

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

On 1/5/07, Allen Bierbaum <al...@vr...> wrote:
> I have been out of the loop for a couple of months and I was wondering
> what the current status on supporting additional caching with py++ is.

There were no changes in this area.

> I know that Matthias had proposed some ideas in October that would
> minimize the number of symbols pulled in from gccxml.  What ever
> happened with that effort?  Are you still using it Matthias?

module_builder_t.__init__ has "start_with_declarations" argument.
Take a look on GCC-XML help to find out more about it

> I had tried to increase performance by caching the decl parsing and
> query optimization run in module_builder.init().  This worked very well
> for me and I have code in goodie_perf_overrides.py that worked last time
> I tried, but alas this code seems to have broken since the last time I
> used it.  My guess is that module builder is now changed.

May be. I don't support\upgrade goodies.

> Roman: Is this idea of caching additional parts of the module builder
> initialization something you are interested in integrating into Py++?

Yes, but you will have to define exactly what you want. The previous one,
implementation and definition, was problematic.

> Are there any other optimizations floating around?

No. Py++ is pretty usable and fast for me.

> If you can't tell
> already I am pretty focused on performance on Py++.  In our workflow we
> do a lot of iterative development and any tool that runs slow can grind
> development progress to a halt.

Py++ is now 20 - 30 % slower than it was. New features "dependency manager"
and warnings introduced additional slowness. Patches are always welcome.

> Anyway, I just wanted to check in and see what is new that I should be
> looking into.

http://language-binding.net/pyplusplus/history/history.html

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

[pygccxml-development] Current status on additional caching support

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

I have been out of the loop for a couple of months and I was wondering 
what the current status on supporting additional caching with py++ is.

I know that Matthias had proposed some ideas in October that would 
minimize the number of symbols pulled in from gccxml.  What ever 
happened with that effort?  Are you still using it Matthias?

I had tried to increase performance by caching the decl parsing and 
query optimization run in module_builder.init().  This worked very well 
for me and I have code in goodie_perf_overrides.py that worked last time 
I tried, but alas this code seems to have broken since the last time I 
used it.  My guess is that module builder is now changed.

Roman: Is this idea of caching additional parts of the module builder 
initialization something you are interested in integrating into Py++?  
Atleast for me it had a significant impact on performance and made Py++ 
much more usable.

Are there any other optimizations floating around?  If you can't tell 
already I am pretty focused on performance on Py++.  In our workflow we 
do a lot of iterative development and any tool that runs slow can grind 
development progress to a halt.

Anyway, I just wanted to check in and see what is new that I should be 
looking into.

Thanks,
Allen

[pygccxml-development] ANN: version 0.8.5

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

Hi. I am going to release next version of pygccxml and Py++. I think
they accumulated
enough features and bug fixes:

Py++ changes:

New functionality\features:
-------------------------------------
* Added "Function Transformation" feature
* Added new functionality, which allows you to control messages and warnings
* Adding new algorithm, which controls the registration order of the functions
* Added new "Py++" defined "return_pointee_value" call policy
* Opaque types are fully supported

Small features:
---------------------

* It is possible to configure "Py++" to generate faster ( compilation time )
  code for indexing suite version 2. See API documentation.

* The algorithm, which finds all class properties was improved. Now it provides
  a better way to control properties creation. A property that would
hide another
  exposed declaration will not be registered\\created.

* Work around for "custom smart pointer as member variable" Boost.Python bug
  was introduced.

pygccxml changes:

New functionality\features:
-------------------------------------

* Added new functionality: "I depend on them". Every declaration can report
  types and declarations it depends on. This functionality helps code
generators.
  For example, Py++, the Boost.Python code generator, uses it to
verify that all
  relevant declarations were exposed.

* Declarations, read from GCC-XML generated file, could be saved in cache.

Small features
---------------------
* New type traits have been added:

   * is_bool

* Small improvement to algorithm, which extracts value_type
  ( mapped_type ) from "std" containers.

* Few aliases to long method name were introduced:

    scopedef_t.variable  => scopedef_t.var
    scopedef_t.variables  => scopedef_t.vars
    scopedef_t.member_function  => scopedef_t.mem_fun
    scopedef_t.member_functions  => scopedef_t.mem_funs
    scopedef_t.free_function  => scopedef_t.free_fun
    scopedef_t.free_functions  => scopedef_t.free_funs

Bug fixes
--------------

* "signed char" and "char" are two different types. This bug was fixed and
  now pygccxml treats them right.

* Fixing bug related to array size and cache.

This release should not introduce any backward computability problems.
Please test both projects and report any problems you have.

Thanks

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

Re: [pygccxml-development] FT feature

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

On 12/11/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > Hi Matthias. I finally finished to make the refactoring on FT feature.
> > I did it on pyplusplus_dev_ft branch.  Basically it is not that
> > different from your one.
> > Now, there is a clear separation between code managers, substitution
> > managers and
> > code creators.
> >
> > Would you like to take a look on it?
>
> Sorry for the delay. Of course, I'll have a look at it sooner or later
> but currently I'm still a few releases behind as I still didn't dare
> doing an update of pyplusplus. ;) But once I do so I will certainly
> shout when there's something broken... :)

Be sure to back up your current version I made few changes.

P.S. Nice to hear from you again

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

Re: [pygccxml-development] FT feature

[Matthias B. <ba...@ir...>]

Roman Yakovenko wrote:
> Hi Matthias. I finally finished to make the refactoring on FT feature.
> I did it on pyplusplus_dev_ft branch.  Basically it is not that
> different from your one.
> Now, there is a clear separation between code managers, substitution
> managers and
> code creators.
> 
> Would you like to take a look on it?

Sorry for the delay. Of course, I'll have a look at it sooner or later 
but currently I'm still a few releases behind as I still didn't dare 
doing an update of pyplusplus. ;) But once I do so I will certainly 
shout when there's something broken... :)

- Matthias -

[pygccxml-development] [New feature]Dependency manager

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

Hi. I implemented new cool feature that in my opinion should improve the quality
of the bindings - dependency manager.

Did you or your users get  "no to_python converter found for ... " errors?
Well I think I have a solution for the problem. I added new
functionality - "dependency
manager".

In few words this class checks that you exported all relevant classes.
Search for "The declaration depends on unexposed declaration" text in warnings.

The feature is still young and I expect few bugs here and there. Best
of all you don't have to change single line of the code, the
functionality is already enabled.

( You will need to update pygccxml and Py++ to SVN )

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

[pygccxml-development] FT feature

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

Hi Matthias. I finally finished to make the refactoring on FT feature.
I did it on pyplusplus_dev_ft branch.  Basically it is not that
different from your one.
Now, there is a clear separation between code managers, substitution
managers and
code creators.

Would you like to take a look on it?

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

Re: [pygccxml-development] Memory ownership

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

On 11/17/06, Philip Abbet <phi...@my...> wrote:
> Hello
>
> I'm pretty new to Py++ and Boost::Python.
>
> Consider the following code (taken from the unit tests of my wrapped
> library):
>
>         self.logManager.addListener(MockLogListener())
>
> The C++ prototype of the addListener method is:
>
>         void addListener(ILogListener* pListener);
>
>
> I didn't found a way to specify that the logManager instance is now
> responsible of the destruction of the listener object. Several classes
> acts this way in my library.

http://boost.org/libs/python/doc/v2/faq.html#ownership

http://language-binding.net/pyplusplus/documentation/inserting_code.html

I hope the links will help you.

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

[pygccxml-development] Memory ownership

[Philip A. <phi...@my...>]

Hello

I'm pretty new to Py++ and Boost::Python.

Consider the following code (taken from the unit tests of my wrapped
library):

        self.logManager.addListener(MockLogListener())

The C++ prototype of the addListener method is:

        void addListener(ILogListener* pListener);


I didn't found a way to specify that the logManager instance is now
responsible of the destruction of the listener object. Several classes
acts this way in my library.

The result is that the logManager now holds an invalid pointer, and will
throw a C++ exception when trying to use it.

Is there any workaround (besides keeping a reference to every object on
the Python-side)?

Re: [pygccxml-development] FT changes

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

On 11/13/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > Hi Matthias. I have now more free time, so I am working on FT feature.
> > For some reason SF could not send notification mail, when a commit is done,
> > so I do this instead of it :-)
>
> Oops, it looks like the last 30 or so commits didn't make it into the
> list!? To me it appeared to be rather quiet lately, I didn't notice that
> there's still so much activity.

I paid attention to the problem only few days ago.

> > Until now I did pretty cosmetic changes, but still there is a
> > possibility I break something.
> > Would you like to take a look on the changes?
>
> Well, my version of Py++ is still at an earlier revision, so I can't run
> the new code yet. But I suppose if the unit test still succeeds then it
> can't be that much broken... ;)

You are right, the unit test is still running. I make small steps and
after every
step I run it. There is one point, which is not covered by unit test:
multi threading.
Do you use it? If so, please check, because I am sure I break something.

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

Re: [pygccxml-development] FT changes

[Matthias B. <ba...@ir...>]

Roman Yakovenko wrote:
> Hi Matthias. I have now more free time, so I am working on FT feature.
> For some reason SF could not send notification mail, when a commit is done,
> so I do this instead of it :-)

Oops, it looks like the last 30 or so commits didn't make it into the 
list!? To me it appeared to be rather quiet lately, I didn't notice that 
there's still so much activity.

> Until now I did pretty cosmetic changes, but still there is a
> possibility I break something.
> Would you like to take a look on the changes?

Well, my version of Py++ is still at an earlier revision, so I can't run 
the new code yet. But I suppose if the unit test still succeeds then it 
can't be that much broken... ;)

- Matthias -

[pygccxml-development] FT changes

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

Hi Matthias. I have now more free time, so I am working on FT feature.
For some reason SF could not send notification mail, when a commit is done,
so I do this instead of it :-)

Until now I did pretty cosmetic changes, but still there is a
possibility I break something.
Would you like to take a look on the changes?

Thanks

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

Re: [pygccxml-development] AttributeError: can't set attribute error when importing a compiled boost.python module generated by Py++

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

On 11/9/06, Pecevski Dejan <de...@ig...> wrote:
> Hi,
>
> I'm using py++ to generate boost.python wrappers in my project. The
> generated source code compiles well, but when I try
> to import the generated .so library in python, I get this strange poor
> error message:
> AttributeError: can't set attribute error
>
> Apparently there is a problem with the generated pypp code.
>
> After googling, I found this post related to some bug in pyste that
> produces the same error:
> http://mail.python.org/pipermail/c++-sig/2003-August/005108.html
> It has to do something with generating multiple def()'s  in boost.python
> code.
>
> Does somebody have any idea what can be the problem?
>
> I'm using linux with the latest gccxml cvs dump, and latest version of
> pygccxml and py++ (0.8.2).

I'll be glad to help you. Can you create small test case that reproduce the
problem?

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