pygccxml-development

Re: [pygccxml-development] Basic Py++ questions

[Paul M. <pa...@sc...>]

Hi Roman,

Roman Yakovenko wrote:
> On Tue, Oct 28, 2008 at 3:27 PM, Paul Melis <pa...@sc...> wrote:
>   
>
>> I.e. I can
>> write for example class_('::mynamespace::C'), class_('mynamespace::C')
>> or class_('C'). Will these match different classes?
>>     
>
> The first and the last examples could match the different classes.
> This depends on flags you pass to the method. If you use class_
> method, you will get exception. I am not sure about the second
> example. I guess it will not match any class, but I could be wrong.
>
> I suggest you to take a look on the following document:
> http://language-binding.net/pygccxml/query_interface.html
>   
Surprisingly you say that class_('mynamespace::C') might not match any 
class, as the following example line is in the query interface docs:

do_smth = my_class.member_function( 'my_namespace::my_class::do_smth' )

I suppose that this form should match something as it is basically the most used form in C++ code. I haven't seen much code that consistently uses an absolute namespace path, like ::mynamespace::C, to refer to classes.

>> - I get warnings (W1005) during code generation about methods/functions
>> using instances of non-public classes, with the message that the
>> generated code will not compile :)  Is there a way to automatically
>> disable generation of method wrappers that use non-public classes?
>>     
>
> Yes. Py++ warnings are explained here:
> http://language-binding.net/pyplusplus/documentation/warnings.html
>
> Basically you can check why declarations is not exportable :
>
> <<untested>>
>
> from pyplusplus import messages
>
> f = <<<some function>>>
> if not f.exportable and f.why_not_exportable().identifier == messages.W1005:
>     f.exclude()
>
>   
Right, I did notice the docs about this and saw a quote from you 
somewhere that it allows you to exclude items based on warnings they 
generate.
The above indeed shows that, but the warnings API doesn't allow you to 
find WHICH items generated a certain warning so this would mean 
iterating over ALL items being exported and checking them for a certain 
warning?
>> - Finally, if I .exclude() a certain class it seems that this doesn't
>> propagate into excluding all methods/functions using that class (related
>> to the previous question)?
>>     
>
> You mean you have class A{}; and some function f( A& ) and excluding
> A, doesn't exclude f, right?
>   
Yes. I'm not certain how the generated wrapper would behave when class A 
is excluded, but f(A&) WOULD be wrapped.
If there was a class B derived from A that would be included in the 
wrappers then I could still call f(B)?
> If so, Py++ doesn't do it for performance\memory reasons.
>
> Now, when I think about it, it should be easy to add to the class_t
> new function - "exclude_me_and_references_to_me" ( better name is
> needed ) which will does exactly what you want. We can use
> "i_depend_on_them" functionality.
>   
It would be a nice addition to give users a choice of how exclusion of a 
class is treated. The current option is simply excluding only the 
wrapper for the class, but another variant would then be to exclude the 
class and all its uses.

Regards,
Paul

PS Why did you choose to name classes with the "_t" postfix, e.g. 
declaration_matcher_t versus the more common/pythonic 
DeclarationMatcher? And could a statement like "if not None is 
self.decl_type:" not also be written as "if self.decl_type is not None:"?

Re: [pygccxml-development] Basic Py++ questions

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

On Tue, Oct 28, 2008 at 3:27 PM, Paul Melis <pa...@sc...> wrote:
> Hello Roman,
>
> Thanks for your help so far!

You are welcome.

> I have a few beginners questions w.r.t. Py++:
> - When selecting a class with the class_() method how intelligent is the
> matching?

Well, it is able to do few things.

>Does it do purely a string match on the argument you provide,
> or does it actually parse the argument and go from there?

Neither. Parsing is error prone approach.

You can take a look on it:
http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pygccxml_dev/pygccxml/declarations/matchers.py?revision=1428&view=markup

search for declaration_matcher_t class

> I.e. I can
> write for example class_('::mynamespace::C'), class_('mynamespace::C')
> or class_('C'). Will these match different classes?

The first and the last examples could match the different classes.
This depends on flags you pass to the method. If you use class_
method, you will get exception. I am not sure about the second
example. I guess it will not match any class, but I could be wrong.

I suggest you to take a look on the following document:
http://language-binding.net/pygccxml/query_interface.html

> - I get warnings (W1005) during code generation about methods/functions
> using instances of non-public classes, with the message that the
> generated code will not compile :)  Is there a way to automatically
> disable generation of method wrappers that use non-public classes?

Yes. Py++ warnings are explained here:
http://language-binding.net/pyplusplus/documentation/warnings.html

Basically you can check why declarations is not exportable :

<<untested>>

from pyplusplus import messages

f = <<<some function>>>
if not f.exportable and f.why_not_exportable().identifier == messages.W1005:
    f.exclude()

> - Finally, if I .exclude() a certain class it seems that this doesn't
> propagate into excluding all methods/functions using that class (related
> to the previous question)?

You mean you have class A{}; and some function f( A& ) and excluding
A, doesn't exclude f, right?

If so, Py++ doesn't do it for performance\memory reasons.

Now, when I think about it, it should be easy to add to the class_t
new function - "exclude_me_and_references_to_me" ( better name is
needed ) which will does exactly what you want. We can use
"i_depend_on_them" functionality.

HTH

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

[pygccxml-development] Basic Py++ questions

[Paul M. <pa...@sc...>]

Hello Roman,

Thanks for your help so far!

I have a few beginners questions w.r.t. Py++:
- When selecting a class with the class_() method how intelligent is the 
matching? Does it do purely a string match on the argument you provide, 
or does it actually parse the argument and go from there?  I.e. I can 
write for example class_('::mynamespace::C'), class_('mynamespace::C') 
or class_('C'). Will these match different classes?
- I get warnings (W1005) during code generation about methods/functions 
using instances of non-public classes, with the message that the 
generated code will not compile :)  Is there a way to automatically 
disable generation of method wrappers that use non-public classes?
- Finally, if I .exclude() a certain class it seems that this doesn't 
propagate into excluding all methods/functions using that class (related 
to the previous question)?

Thanks in advance,
Paul

Re: [pygccxml-development] Querying subclasses of some class?

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

On Mon, Oct 27, 2008 at 12:38 PM, Paul Melis <pa...@sc...> wrote:
> Hi,
>
> I want to set a return policy for a whole set of class methods.
> This set consists of all methods returning a pointer to some class A
> *or one of its subclasses*.
>
> I don't think I can directly accomplish this using
> member_functions(return_value='A *'), as this doesn't seem to match the
> subclasses. One way I can probably make this work is if I can iterate
> over the subclasses of A and then do a member_functions() call
> for the subclass pointer type, followed by setting the return policy.
>
> Is there a way with pygccxml/Py++ to get a list of subclasses of
> some class A?

Yes. pygccxml and Py++ provides the functionality you need:

* http://language-binding.net/pyplusplus/documentation/apidocs/pygccxml.declarations.type_traits-pysrc.html#is_base_and_derived
  take a look on is_based_and_derived.

  pygccxml implements\mimics almost all type traits found in
Boost.TypeTraits library

*  use class_t.recursive_derived property to get list of all classes,
which derives from "self" class.

HTH

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

Re: [pygccxml-development] Incorrect code due to parameter default values

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

On Mon, Oct 27, 2008 at 12:39 PM, Paul Melis <pa...@sc...> wrote:
> Hello,
>
> Py++ generates incorrect code for me that won't compile, this is with
> the svn version of yesterday.
> The real problem is gccxml's stupid handling of parameter default
> values, where it
> only stores the argument value literally found during parsing, which is
> obviously dependent on context.
>
> I.e. when gccxml parses
>
> namespace doh {
> enum E { ONE, TWO, THREE };
> void f(int a, int b = THREE);
> }
>
> it stores for the default value of parameter b "THREE", instead of
> "doh::THREE".
> Py++ then generates code that isn't put inside namespace doh, but DOES
> use the value THREE. Which won't compile...
>
> I seem to recall there was a patch for this some time ago for Py++.
> Should that patch have solved all instances of this problem?
> If not, would patching the gccxml output be an appropriate way of
> working around this? (I.e. replacing THEE with doh::THREE).

The long version:
http://language-binding.net/pygccxml/upgrade_issues.html#free-and-member-function-default-arguments

The short version: there is nothing I can do about this and you will
have to replace default value from the script:

#f is "calldef_t" instance
for arg in f.arguments:
    arg.default_value = <<<new default value or None>>>


Another approach is described here:
http://language-binding.net/pyplusplus/documentation/functions/default_args.html

HTH

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

[pygccxml-development] Incorrect code due to parameter default values

[Paul M. <pa...@sc...>]

Hello,

Py++ generates incorrect code for me that won't compile, this is with 
the svn version of yesterday.
The real problem is gccxml's stupid handling of parameter default 
values, where it
only stores the argument value literally found during parsing, which is
obviously dependent on context.

I.e. when gccxml parses

namespace doh {
enum E { ONE, TWO, THREE };
void f(int a, int b = THREE);
}

it stores for the default value of parameter b "THREE", instead of 
"doh::THREE".
Py++ then generates code that isn't put inside namespace doh, but DOES
use the value THREE. Which won't compile...

I seem to recall there was a patch for this some time ago for Py++.
Should that patch have solved all instances of this problem?
If not, would patching the gccxml output be an appropriate way of
working around this? (I.e. replacing THEE with doh::THREE).

Regards,
Paul

[pygccxml-development] Querying subclasses of some class?

[Paul M. <pa...@sc...>]

Hi,

I want to set a return policy for a whole set of class methods.
This set consists of all methods returning a pointer to some class A
*or one of its subclasses*.

I don't think I can directly accomplish this using
member_functions(return_value='A *'), as this doesn't seem to match the
subclasses. One way I can probably make this work is if I can iterate
over the subclasses of A and then do a member_functions() call
for the subclass pointer type, followed by setting the return policy.

Is there a way with pygccxml/Py++ to get a list of subclasses of
some class A?

Thanks,
Paul

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

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

Hi all.

I am glad to release new version of both projects.

 Thanks to every one who helped me to improve the projects:
* Andy Miller
* Julian Scheid
* Oliver Schweitzer
* Hernán Ordiales
* Bernd Fritzke
* Gustavo Carneiro

pygccxml changes:

* support for ellipsis was added
* new experimental back-end, based on ``.pdb`` (progam database file),
was added. I am considering to add other back-ends in future.
Suggestions are welcome.
* new high-level API wrapper for ``.bsc`` (browse source code file) was added.
* many other small changes
* pygccxml is compatible with gccxml cvs version

py++ changes:

* algorightm, which defines what virtual functions should be redefined
was improved.
* exposing "C" code became easier - Py++ is able to generate
``ctypes`` friendly code.
* support for ``boost::python::make_constructor`` functionality was added.
* support for unions and unnamed classes was added.
* Indexing Suite V2 - few bugs were fixed.

You can download the files from here:
http://sourceforge.net/project/showfiles.php?group_id=118209

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

Re: [pygccxml-development] ctypes code generation?

[Gordon K. <gk...@bw...>]

hello-

Okay, thanks for these links and ideas.  I encourage you to work on a  
pygccxml-to-ctypes-wrapper-code-generator in all your free time :)

Gordon

On Oct 15, 2008, at 2:58 PM, Roman Yakovenko wrote:

> On Wed, Oct 15, 2008 at 6:43 PM, Gordon Kindlmann  
> <gk...@bw...> wrote:
>> Would it be possible to point me to an existing example of doing  
>> this?  Or
>> any hints about how to do it myself?
>
> I am not sure you need this, but if you ask:
> http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/ 
> docs/documentation/ctypes/
>
> The link contains few documents, which describes the idea and
> implementation behind "Py++ & ctypes integration".
>
>> I'm relatively new to python, so I have to admit I don't grasp the
>> significance of what this page describes.  Again, some simple  
>> examples of
>> wrapping C code would really help me understand how I could use  
>> your tools.
>
> If you are wrapping pure C code, I suggest you to stay with ctypeslib
> only. The overhead is too big.
>
>>> May be the best solution for you is to add missing functionality to
>>> ctypeslib? It is not too difficult after all. I can help you with
>>> gccxml.
>>> ...
>> Well, in the mean time I have in fact found a way to tweak the  
>> xml2py script
>> of ctypeslib, and I've announced the patch on the ctypes-users  
>> mailing list,
>> which I can forward to you if interested.  So ctypeslib is working  
>> again for
>> me, with gcc 4.0.1 and gccxml 0.9.0, but there are probably still  
>> some small
>> problems.
>>
>> I do think it would be very good if ctypeslib is still maintained by
>> someone.  To me it seems like a tool that is very good at its one  
>> thing, and
>> its a shame when those tools stop working.  Alternatively, from  
>> what I
>> understand, it seems like the pygccxml output could also be parsed to
>> generate the same ctypes code that ctypeslib generates- that is,  
>> the brains
>> of ctypeslib's xml2py script could operate on the pygccxml parse tree
>> instead of the XML file directly.  But I barely know what I'm  
>> talking about!
>
> This is exactly my plan - to port current code generator to deal with
> pygccxml and not with xml directly.
>
> -- 
> Roman Yakovenko
> C++ Python language binding
> http://www.language-binding.net/

Re: [pygccxml-development] Fwd: instance attribute with anonymous enum type

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

On Thu, Oct 16, 2008 at 1:51 AM, Gustavo Carneiro <gjc...@gm...> wrote:
> Personally I think it is deceptive to return a type expression that does not
> correspond to the real type.  I mean, it's worse, it is returning a type
> string that corresponds to _another_ type, one which is perfectly valid.
> This induces the code generator to generate incorrect code...

I will consider to change the behavior after the release. Can you open
the bug, so I will not forget this.

Thanks.

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

Re: [pygccxml-development] Fwd: instance attribute with anonymous enum type

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

2008/10/15 Roman Yakovenko <rom...@gm...>

> On Wed, Oct 15, 2008 at 7:06 PM, Gustavo Carneiro <gjc...@gm...>
> wrote:
> > Sorry, Roman, I really meant to send to the mailing list! :-)
>
> Hi. That's okey.
>
> > From: Gustavo Carneiro <gjc...@gm...>
> >
> > Hello, I am hitting a problem in pygccxml regarding anonymous enums used
> as
> > class member variables.
> >
> > Something like this:
> >
> > class SomeObject
> > {
> > public:
> >
> >     enum {
> >         TYPE_FOO,
> >         TYPE_BAR,
> >     } type;
> > };
> >
> > When I scan this, pygccxml tells me the attribute 'type' of 'SomeObject'
> is
> > of type 'SomeObject'.  I happily try to generate code for this, and of
> > course the generated code does not even compile:
> >
> > [14/25] cxx: build/default/tests/foomodule2.cc ->
> > build/default/tests/foomodule2_9.o
> > default/tests/foomodule2.cc: In function 'int
> > _wrap_PySomeObject__set_type(PySomeObject*, PyObject*)':
> > default/tests/foomodule2.cc:6211: error: cannot convert 'SomeObject' to
> > 'SomeObject::<anonymous enum>' in assignment
> > Build failed
>
> Indeed, pygccxml has a problem to create full type name for unnamed
> types, and the solution I choose, is to report named parts only.
>
> > It would be better if pygccxml reported the type as
>  "SomeObject::<anonymous
> > enum>", like GCC does.  This way at least I will not be lead me to
> generate
> > invalid code (I prefer no code at all than erroneous code).
>
> How? You still will have to check whether the type has name or not and
> avoid the generation.


If the type string returned by pygccxml was simply "SomeObject::<anonymous
enum>", I would not have to do anything in my case (pybindgen).  That type
is not registered, and so an exception like
TypeLookupError("SomeObject::<anonymous enum>") would be raised and printed
to the user as warning, but no code would be generated for that definition.


>
>
> More over in this concrete example, you can do better. You can expose
> all enum values as int within the class scope. Member variable "type"
> could also be exposed as int.
>
> Yes, this is a special case, but it could be completely handled by
> code generator.


Yes. I know it is possible wrap it.  Maybe some day I will wrap it, but I
don't have time for everything, and I don't need that feature right now ;-)


>
>
> > This with pygccxml 0.9.5, gccxml 2008-04-20.
> >
> > My work around for the moment is:
> >
> >                 real_type = type_traits.remove_declarated(member.type)
> >                 if hasattr(real_type, 'name') and not real_type.name:
> >                     print >> sys.stderr, ">>>>>>>>>>>>>> skip anonymous
> > type"
> >                     continue
>
> As I said unnamed types is a special case.


Personally I think it is deceptive to return a type expression that does not
correspond to the real type.  I mean, it's worse, it is returning a type
string that corresponds to _another_ type, one which is perfectly valid.
This induces the code generator to generate incorrect code...


>
>
> Py++ has solution for this and other issues. It extends every
> declaration class, defined in pygccxml. One of the functions, it adds
> is the ability of declarations to analyze "itself" and report
> problems, and whether it could be exported or not.
>
> For example:
>
> http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/pyplusplus/decl_wrappers/enumeration_wrapper.py?view=markup
>
>
> http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/pyplusplus/decl_wrappers/calldef_wrapper.py?revision=1428&view=markup
>
> take a look on _exportable_impl method.
>
> Thus the actual "code generator" code is clear, because it doesn't
> need to deal with such cases. It just asks the declaration.


Hm.. OK.  I am more of a down to earth guy and prefer more simple and direct
solutions...  at least to begin with  :-)

But thanks for the tip.

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

Re: [pygccxml-development] Fwd: instance attribute with anonymous enum type

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

On Wed, Oct 15, 2008 at 7:06 PM, Gustavo Carneiro <gjc...@gm...> wrote:
> Sorry, Roman, I really meant to send to the mailing list! :-)

Hi. That's okey.

> From: Gustavo Carneiro <gjc...@gm...>
>
> Hello, I am hitting a problem in pygccxml regarding anonymous enums used as
> class member variables.
>
> Something like this:
>
> class SomeObject
> {
> public:
>
>     enum {
>         TYPE_FOO,
>         TYPE_BAR,
>     } type;
> };
>
> When I scan this, pygccxml tells me the attribute 'type' of 'SomeObject' is
> of type 'SomeObject'.  I happily try to generate code for this, and of
> course the generated code does not even compile:
>
> [14/25] cxx: build/default/tests/foomodule2.cc ->
> build/default/tests/foomodule2_9.o
> default/tests/foomodule2.cc: In function 'int
> _wrap_PySomeObject__set_type(PySomeObject*, PyObject*)':
> default/tests/foomodule2.cc:6211: error: cannot convert 'SomeObject' to
> 'SomeObject::<anonymous enum>' in assignment
> Build failed

Indeed, pygccxml has a problem to create full type name for unnamed
types, and the solution I choose, is to report named parts only.

> It would be better if pygccxml reported the type as  "SomeObject::<anonymous
> enum>", like GCC does.  This way at least I will not be lead me to generate
> invalid code (I prefer no code at all than erroneous code).

How? You still will have to check whether the type has name or not and
avoid the generation.

More over in this concrete example, you can do better. You can expose
all enum values as int within the class scope. Member variable "type"
could also be exposed as int.

Yes, this is a special case, but it could be completely handled by
code generator.

> This with pygccxml 0.9.5, gccxml 2008-04-20.
>
> My work around for the moment is:
>
>                 real_type = type_traits.remove_declarated(member.type)
>                 if hasattr(real_type, 'name') and not real_type.name:
>                     print >> sys.stderr, ">>>>>>>>>>>>>> skip anonymous
> type"
>                     continue

As I said unnamed types is a special case.

Py++ has solution for this and other issues. It extends every
declaration class, defined in pygccxml. One of the functions, it adds
is the ability of declarations to analyze "itself" and report
problems, and whether it could be exported or not.

For example:
http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/pyplusplus/decl_wrappers/enumeration_wrapper.py?view=markup

http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/pyplusplus/decl_wrappers/calldef_wrapper.py?revision=1428&view=markup

take a look on _exportable_impl method.

Thus the actual "code generator" code is clear, because it doesn't
need to deal with such cases. It just asks the declaration.

HTH

P.S. Hope I was clear. If not we can discuss it using IRC or gmail
chat. I have some free time now.

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

Re: [pygccxml-development] ctypes code generation?

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

On Wed, Oct 15, 2008 at 6:43 PM, Gordon Kindlmann <gk...@bw...> wrote:
> Would it be possible to point me to an existing example of doing this?  Or
> any hints about how to do it myself?

I am not sure you need this, but if you ask:
http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/docs/documentation/ctypes/

The link contains few documents, which describes the idea and
implementation behind "Py++ & ctypes integration".

> I'm relatively new to python, so I have to admit I don't grasp the
> significance of what this page describes.  Again, some simple examples of
> wrapping C code would really help me understand how I could use your tools.

If you are wrapping pure C code, I suggest you to stay with ctypeslib
only. The overhead is too big.

>> May be the best solution for you is to add missing functionality to
>> ctypeslib? It is not too difficult after all. I can help you with
>> gccxml.
>>...
> Well, in the mean time I have in fact found a way to tweak the xml2py script
> of ctypeslib, and I've announced the patch on the ctypes-users mailing list,
> which I can forward to you if interested.  So ctypeslib is working again for
> me, with gcc 4.0.1 and gccxml 0.9.0, but there are probably still some small
> problems.
>
> I do think it would be very good if ctypeslib is still maintained by
> someone.  To me it seems like a tool that is very good at its one thing, and
> its a shame when those tools stop working.  Alternatively, from what I
> understand, it seems like the pygccxml output could also be parsed to
> generate the same ctypes code that ctypeslib generates- that is, the brains
> of ctypeslib's xml2py script could operate on the pygccxml parse tree
> instead of the XML file directly.  But I barely know what I'm talking about!

This is exactly my plan - to port current code generator to deal with
pygccxml and not with xml directly.

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

[pygccxml-development] Fwd: instance attribute with anonymous enum type

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

Sorry, Roman, I really meant to send to the mailing list! :-)

---------- Forwarded message ----------
From: Gustavo Carneiro <gjc...@gm...>
Date: 2008/10/15
Subject: instance attribute with anonymous enum type
To: Roman Yakovenko <rom...@gm...>


Hello, I am hitting a problem in pygccxml regarding anonymous enums used as
class member variables.

Something like this:

class SomeObject
{
public:

    enum {
        TYPE_FOO,
        TYPE_BAR,
    } type;
};

When I scan this, pygccxml tells me the attribute 'type' of 'SomeObject' is
of type 'SomeObject'.  I happily try to generate code for this, and of
course the generated code does not even compile:

[14/25] cxx: build/default/tests/foomodule2.cc ->
build/default/tests/foomodule2_9.o
default/tests/foomodule2.cc: In function 'int
_wrap_PySomeObject__set_type(PySomeObject*, PyObject*)':
default/tests/foomodule2.cc:6211: error: cannot convert 'SomeObject' to
'SomeObject::<anonymous enum>' in assignment
Build failed

It would be better if pygccxml reported the type as  "SomeObject::<anonymous
enum>", like GCC does.  This way at least I will not be lead me to generate
invalid code (I prefer no code at all than erroneous code).

This with pygccxml 0.9.5, gccxml 2008-04-20.

My work around for the moment is:

                real_type = type_traits.remove_declarated(member.type)
                if hasattr(real_type, 'name') and not real_type.name:
                    print >> sys.stderr, ">>>>>>>>>>>>>> skip anonymous
type"
                    continue

Take care,

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




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

Re: [pygccxml-development] ctypes code generation?

[Gordon K. <gk...@bw...>]

hello,

On Oct 13, 2008, at 4:39 PM, Roman Yakovenko wrote:

> I am developing Py++, a code generator for Boost.Python library, and
> recently integrated some functionality, which allows to export some
> "C" code easily. ...

I noticed that your announcement of the next version also seemed to  
mention something about this.

Would it be possible to point me to an existing example of doing  
this?  Or any hints about how to do it myself?

> There are few other solutions that help to export and
> create Pythonic interface for "C" classes and functions. For example
> take a look on functions transformation future (
> http://language-binding.net/pyplusplus/documentation/functions/ 
> transformation/transformation.html
> ). Do you want to reconsider your approach :-) ?

I'm relatively new to python, so I have to admit I don't grasp the  
significance of what this page describes.  Again, some simple  
examples of wrapping C code would really help me understand how I  
could use your tools.

> May be the best solution for you is to add missing functionality to
> ctypeslib? It is not too difficult after all. I can help you with
> gccxml.
>
> I did not know that ctypes code generator is not maintained. I think,
> I am going to evaluate and may be to support it. If you want we can
> join the efforts.

Well, in the mean time I have in fact found a way to tweak the xml2py  
script of ctypeslib, and I've announced the patch on the ctypes-users  
mailing list, which I can forward to you if interested.  So ctypeslib  
is working again for me, with gcc 4.0.1 and gccxml 0.9.0, but there  
are probably still some small problems.

I do think it would be very good if ctypeslib is still maintained by  
someone.  To me it seems like a tool that is very good at its one  
thing, and its a shame when those tools stop working.  Alternatively,  
from what I understand, it seems like the pygccxml output could also  
be parsed to generate the same ctypes code that ctypeslib generates-  
that is, the brains of ctypeslib's xml2py script could operate on the  
pygccxml parse tree instead of the XML file directly.  But I barely  
know what I'm talking about!

thanks,
Gordon

[pygccxml-development] pygccxml & Py++ - code freeze

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

Hi all.

I almost finished to develop and prepare next projects release ( 1.0
). There were many changes, improvements and contributions from the
last release. Thanks to every one who helped me to improve the
projects:
* Andy Miller
* Julian Scheid
* Oliver Schweitzer
* Hernán Ordiales
* Bernd Fritzke
* Gustavo Carneiro

pygccxml changes:

* support for ellipsis was added
* new experimental back-end, based on ``.pdb`` (progam database file),
was added. I am considering to add other back-ends in future.
Suggestions are welcome.
* new high-level API wrapper for ``.bsc`` (browse source code file) was added.
* many other small changes
* pygccxml is compatible with gccxml cvs version

py++ changes:

* algorightm, which defines what virtual functions should be redefined
was improved.
* exposing "C" code became easier - Py++ is able to generate
``ctypes`` friendly code.
* support for ``boost::python::make_constructor`` functionality was added.
* support for unions and unnamed classes was added.
* Indexing Suite V2 - few bugs were fixed.

The code is frozen, the documentation was updated, the tests pass. The
SVN version was tested on few big projects and I don't know about any
issue. It is time to test it on your projects and report the problems.
If no problems will be report, I will release the projects in a week
or two.

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

Re: [pygccxml-development] ctypes code generation?

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

On Mon, Oct 13, 2008 at 4:46 PM, Gordon Kindlmann <gk...@bw...> wrote:
> Hello,
>
> I'm new to pygccxml and have a simple question: does anyone have
> suggestions on how to use pygccxml to generate python code
> corresponding to the structs, functions, and variables that are
> available (from a shared library) in ctypes?
>
> I'm thinking of something that takes a C header like:
>
>   typedef struct {
>     int aaaa, bbbb;
>   } tst;
>
>   extern int tstSet(tst *t, int v);
>
> and generates python code which includes things like:
>
>   class tst(Structure):
>     pass
>   tst._fields_ = [
>     ('aaaa', c_int),
>     ('bbbb', c_int),
>   ]
>
>   tstSet.restype = c_int
>   tstSet.argtypes = [POINTER(tst), c_int]
>
> I know that ctypeslib serves this purpose:
>
> http://starship.python.net/crew/theller/wiki/CodeGenerator
>
> (and my example above is based on its output) but I've had problems
> using it with the current version of gccxml: its xml2py phase doesn't
> pick up the fields in C structs and convert them to a "_fields_"
> assignment.  The author of ctypeslib has warned me that ctypeslib is
> not really maintained anymore, and he pointed me to a python-only C-
> parser (pyglet/tools/wraptypes/wrap.py) included in pyglet <http://
> www.pyglet.org/>, but that choked on some of my header files, and
> pyglet doesn't really seem to be the right tool for this job.
>
> pygccxml, however, seems theoretically perfect, since it works
> directly from gccxml, right?  There are some ctypes-related comments
> that show up in the pygccxml-commit mailing list archive, but nothing
> (I could find, anyway) about ctypes in the documentation, or on this
> list.
>
> I'd very much appreciate any tips, suggestions, or examples that
> might help me.

I don't think that I can help you right now, may be in future.

I am developing Py++, a code generator for Boost.Python library, and
recently integrated some functionality, which allows to export some
"C" code easily. There are few other solutions that help to export and
create Pythonic interface for "C" classes and functions. For example
take a look on functions transformation future (
http://language-binding.net/pyplusplus/documentation/functions/transformation/transformation.html
). Do you want to reconsider your approach :-) ?

May be the best solution for you is to add missing functionality to
ctypeslib? It is not too difficult after all. I can help you with
gccxml.

I did not know that ctypes code generator is not maintained. I think,
I am going to evaluate and may be to support it. If you want we can
join the efforts.

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

[pygccxml-development] ctypes code generation?

[Gordon K. <gk...@bw...>]

Hello,

I'm new to pygccxml and have a simple question: does anyone have  
suggestions on how to use pygccxml to generate python code  
corresponding to the structs, functions, and variables that are  
available (from a shared library) in ctypes?

I'm thinking of something that takes a C header like:

   typedef struct {
     int aaaa, bbbb;
   } tst;

   extern int tstSet(tst *t, int v);

and generates python code which includes things like:

   class tst(Structure):
     pass
   tst._fields_ = [
     ('aaaa', c_int),
     ('bbbb', c_int),
   ]

   tstSet.restype = c_int
   tstSet.argtypes = [POINTER(tst), c_int]

I know that ctypeslib serves this purpose:

http://starship.python.net/crew/theller/wiki/CodeGenerator

(and my example above is based on its output) but I've had problems  
using it with the current version of gccxml: its xml2py phase doesn't  
pick up the fields in C structs and convert them to a "_fields_"  
assignment.  The author of ctypeslib has warned me that ctypeslib is  
not really maintained anymore, and he pointed me to a python-only C- 
parser (pyglet/tools/wraptypes/wrap.py) included in pyglet <http:// 
www.pyglet.org/>, but that choked on some of my header files, and  
pyglet doesn't really seem to be the right tool for this job.

pygccxml, however, seems theoretically perfect, since it works  
directly from gccxml, right?  There are some ctypes-related comments  
that show up in the pygccxml-commit mailing list archive, but nothing  
(I could find, anyway) about ctypes in the documentation, or on this  
list.

I'd very much appreciate any tips, suggestions, or examples that  
might help me.

Thanks in advance,
Gordon

Re: [pygccxml-development] Cloning an object which has been wrapped

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

On Wed, Sep 24, 2008 at 1:26 PM, Vincent Ferries
<vin...@gm...> wrote:
> I've got the following problem :
>
> I wrap a complex object, we will call it MyObject.

You are wrapping a "class", not object.

> If I modify data in MyObject using some of my wrapped methods, MyObject
> content will be changed.
> I'd like to create a copy from my base MyObject and work on a clone, to
> ensure I keep the initial data safe.
>
> I tried using copy and deepcopy from the python copy module but without
> success.
>
> The initial C++ object doesn't have any clone method.
>
> Does someone has an idea how I could do this?

1. If class has copy constructor  you can write MyObject( other
MyObject instance ) and this will work
2. If class has operator=, than P++ exposes it under "assign" name, so
you can use it: my_object.assign( other instance )
3. In order to work with copy or deepcopy, the exposed class should
have __copy__ or __deepcopy__ method.
   You can register a C++ function, which does the job, under such
name and you'll be okey.
4. Another option is described
here(http://www.boost.org/doc/libs/1_36_0/libs/python/doc/v2/pickle.html).
   Py++ doesn't support such functionality

HTH

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

[pygccxml-development] Cloning an object which has been wrapped

[Vincent F. <vin...@gm...>]

I've got the following problem :

I wrap a complex object, we will call it MyObject.
If I modify data in MyObject using some of my wrapped methods, MyObject
content will be changed.
I'd like to create a copy from my base MyObject and work on a clone, to
ensure I keep the initial data safe.

I tried using copy and deepcopy from the python copy module but without
success.

The initial C++ object doesn't have any clone method.

Does someone has an idea how I could do this?

Thanks in advance!

Re: [pygccxml-development] Compilation problem

[Vincent F. <vin...@gm...>]

Roman helped me solving the problem.

In fact I had two classes with the same name in different namespaces juste
like this

ns1::ns2::A
ns1::ns2bis::A

with ns1::ns2bis::A extends ns1::ns2::A

When I called ns1::ns2bis::A constructor it just called ns1::ns2::A one.

I used to rename these classes (prefixing it whith their namespace name) but
the wrappers in boost had allways the same name.

I prefixed the wrappers name just like I did with the classes and it just
works fine now.

Here is a solution to prefix both class name and wrapper name with the
namespace-name :

# Prefixes the classes and wrappers with their namespace name
def rename_in_namespace(mb, nameList):
  for namespaceName in nameList:
    nspace = mb.namespace('postLib').namespace(namespaceName,
recursive=False)
    for clz in nspace.classes():
      clz.rename(namespaceName.capitalize() + clz.name.capitalize())
      clz.wrapper_alias = 'wrapper_' + namespaceName.capitalize() +
clz.name.capitalize()

I hope that it could help someone.


2008/9/19 Roman Yakovenko <rom...@gm...>

> On Fri, Sep 19, 2008 at 10:55 AM, Vincent Ferries
> <vin...@gm...> wrote:
> > Here is the py++ trace :
> >
> > ...
> >
> > Nothing which deals with generic or nastran database.
> >
> > Any idea?
>
> No. I suggest you to send me privately the original header files, you
> try to wrap and your Py++ script, the whole script.
>
> I am sure you don't tell me some important detail. I need them to
> solve your problem.
>
> P.S. you don't have to wary about confidentiality
>       you really have to send me the original files and script
>
> --
>  Roman Yakovenko
> C++ Python language binding
> http://www.language-binding.net/
>

Re: [pygccxml-development] Compilation problem

[Vincent F. <vin...@gm...>]

Bad evaluation.

I have a class NastranDatabase which inherits from GenericDatabase.
When I call the constructor of the NastranDatabase, the only one constructor
called is the GenericDatabase one... not both.

I tried to make a very simple example with this two classes and it works
perfectly fine.

Here is the file database.cpp :
#include "database.h"
#include <iomanip>
#include <iostream>
using namespace std ;
using namespace postLib;
using namespace generic;
database::database(void) {
 cout << "Constructeur de la Generic Database." << endl;
}


Here is the file nastranDatabase.cpp :
#include "nastranDatabase.h"
#include <iomanip>
#include <iostream>
using namespace std ;
using namespace postLib;
using namespace nastran;
database::database(void) : generic::database() {
 cout << "Constructeur de la Nastran Database." << endl;
}

My code generator :

import os
import pyplusplus
import common_utils
from environment import settings
from pyplusplus import code_creators
from pyplusplus import module_builder
from pyplusplus import messages
from pygccxml import declarations
from pyplusplus.module_builder import call_policies
from pyplusplus import function_transformers as FT
license = \
"""
/*
 * My program license
 */
"""
def export():
  global license
  header_files = [os.path.join(settings.ferespost_path, "pyferespost.h")]
  # Create configuration for GCC-XML parser
  # Initialize module builder
  mb = module_builder.module_builder_t(header_files,
gccxml_path=settings.gccxml_path, working_directory=settings.ferespost_path,
include_paths=[settings.ferespost_path], define_symbols=[])
  #Well, don't you want to see what is going on?
  # Please be quiet... I'll be grateful
  # mb.print_declarations()

  mb.classes().exclude()
  genericDatabase =
mb.namespace('postLib').namespace('generic').class_('database')
  genericDatabase.include()

  nastranDatabase =
mb.namespace('postLib').namespace('nastran').class_('database')
  nastranDatabase.include()

  genericDatabase.rename('Generic' + genericDatabase.name.capitalize())
  nastranDatabase.rename('Nastran' + nastranDatabase.name.capitalize())

  #Creating code creator. After this step you should not modify/customize
declarations.
  mb.build_code_creator(settings.module_name)
  mb.code_creator.license = license
  mb.code_creator.user_defined_directories.append(settings.ferespost_path)
  mb.code_creator.precompiled_header = 'boost/python.hpp'
  #Writing code to multiple files, much easier to add missing call_policies.
  mb.split_module(settings.generated_files_dir)
# Main generation fonction
if __name__ == '__main__':
  export()
  print 'done'

The test program and its output :
import pyferespost
print "Generic Database : "
pyferespost.GenericDatabase()
print "Nastran Database : "
pyferespost.NastranDatabase()

Generic Database :
Constructeur de la Generic Database.
Nastran Database :
Constructeur de la Generic Database.
Constructeur de la Nastran Database.



So for now, all seems to be ok.
If I do the same things in my whole application, when I instanciate a
NastranDatabase, the only constructor called is the GenericDatabase one.

Here is the corresponding generated code for the constructor definition :

GenericDatabase :
#include "boost/python.hpp"
#include "pyferespost.h"
#include "GenericDatabase.pypp.hpp"
namespace bp = boost::python;
struct dataBase_wrapper : postLib::generic::dataBase, bp::wrapper<
postLib::generic::dataBase > {
    dataBase_wrapper( )
    : postLib::generic::dataBase( )
      , bp::wrapper< postLib::generic::dataBase >(){
        // null constructor
    }
    // A LOT OF FUNCTION DEFINITIONS HERE
};

void register_GenericDatabase_class(){
    { //::postLib::generic::dataBase
        typedef bp::class_< dataBase_wrapper, boost::noncopyable >
GenericDatabase_exposer_t;
        GenericDatabase_exposer_t GenericDatabase_exposer =
GenericDatabase_exposer_t( "GenericDatabase", bp::init< >() );
        bp::scope GenericDatabase_scope( GenericDatabase_exposer );
      // A LOT OF FUNCTION DEFINITIONS HERE
}

NastranDatabase :

#include "boost/python.hpp"
#include "pyferespost.h"
#include "NastranDatabase.pypp.hpp"
namespace bp = boost::python;
struct dataBase_wrapper : postLib::nastran::dataBase, bp::wrapper<
postLib::nastran::dataBase > {
    dataBase_wrapper( )
    : postLib::nastran::dataBase( )
      , bp::wrapper< postLib::nastran::dataBase >(){
        // null constructor
    }
    // A LOT OF FUNCTION DEFINITIONS HERE
};


void register_NastranDatabase_class(){
    bp::class_< dataBase_wrapper, bp::bases< postLib::generic::dataBase >,
boost::noncopyable >( "NastranDatabase")
 .def(bp::init< >() )
  // A LOT OF .def HERE
}


Is there a problem in my wrappers?
Why is the NastranDatabase constructor never called (it should call both)?

Any idea?

Thanks in advance.

Re: [pygccxml-development] Compilation problem

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

On Thu, Sep 18, 2008 at 3:41 PM, Vincent Ferries
<vin...@gm...> wrote:
> Bad evaluation.
>
> I have a class NastranDatabase which inherits from GenericDatabase.
> When I call the constructor of the NastranDatabase, the only one constructor
> called is the GenericDatabase one... not both.
>
> I tried to make a very simple example with this two classes and it works
> perfectly fine.
>
> Here is the file database.cpp :
> #include "database.h"
> #include <iomanip>
> #include <iostream>
> using namespace std ;
> using namespace postLib;
> using namespace generic;
> database::database(void) {
>  cout << "Constructeur de la Generic Database." << endl;
> }
>
>
> Here is the file nastranDatabase.cpp :
> #include "nastranDatabase.h"
> #include <iomanip>
> #include <iostream>
> using namespace std ;
> using namespace postLib;
> using namespace nastran;
> database::database(void) : generic::database() {
>  cout << "Constructeur de la Nastran Database." << endl;
> }
>
> My code generator :
> import os
> import pyplusplus
> import common_utils
> from environment import settings
> from pyplusplus import code_creators
> from pyplusplus import module_builder
> from pyplusplus import messages
> from pygccxml import declarations
> from pyplusplus.module_builder import call_policies
> from pyplusplus import function_transformers as FT
> license = \
> """
> /*
>  * My program license
>  */
> """
> def export():
>   global license
>   header_files = [os.path.join(settings.ferespost_path, "pyferespost.h")]
>   # Create configuration for GCC-XML parser
>   # Initialize module builder
>   mb = module_builder.module_builder_t(header_files,
> gccxml_path=settings.gccxml_path, working_directory=settings.ferespost_path,
> include_paths=[settings.ferespost_path], define_symbols=[])
>   #Well, don't you want to see what is going on?
>   # Please be quiet... I'll be grateful
>   # mb.print_declarations()
>
>   mb.classes().exclude()
>   genericDatabase =
> mb.namespace('postLib').namespace('generic').class_('database')
>   genericDatabase.include()
>
>   nastranDatabase =
> mb.namespace('postLib').namespace('nastran').class_('database')
>   nastranDatabase.include()
>
>   genericDatabase.rename('Generic' + genericDatabase.name.capitalize())
>   nastranDatabase.rename('Nastran' + nastranDatabase.name.capitalize())
>
>   #Creating code creator. After this step you should not modify/customize
> declarations.
>   mb.build_code_creator(settings.module_name)
>   mb.code_creator.license = license
>   mb.code_creator.user_defined_directories.append(settings.ferespost_path)
>   mb.code_creator.precompiled_header = 'boost/python.hpp'
>   #Writing code to multiple files, much easier to add missing call_policies.
>   mb.split_module(settings.generated_files_dir)
> # Main generation fonction
> if __name__ == '__main__':
>   export()
>   print 'done'
>
> The test program and its output :
> import pyferespost
> print "Generic Database : "
> pyferespost.GenericDatabase()
> print "Nastran Database : "
> pyferespost.NastranDatabase()
>
> Generic Database :
> Constructeur de la Generic Database.
> Nastran Database :
> Constructeur de la Generic Database.
> Constructeur de la Nastran Database.
>
>
>
> So for now, all seems to be ok.
> If I do the same things in my whole application, when I instanciate a
> NastranDatabase, the only constructor called is the GenericDatabase one.
>
> Here is the corresponding generated code for the constructor definition :
>
> GenericDatabase :
> #include "boost/python.hpp"
> #include "pyferespost.h"
> #include "GenericDatabase.pypp.hpp"
> namespace bp = boost::python;
> struct dataBase_wrapper : postLib::generic::dataBase, bp::wrapper<
> postLib::generic::dataBase > {
>     dataBase_wrapper( )
>     : postLib::generic::dataBase( )
>       , bp::wrapper< postLib::generic::dataBase >(){
>         // null constructor
>     }
>     // A LOT OF FUNCTION DEFINITIONS HERE
> };
>
> void register_GenericDatabase_class(){
>     { //::postLib::generic::dataBase
>         typedef bp::class_< dataBase_wrapper, boost::noncopyable >
> GenericDatabase_exposer_t;
>         GenericDatabase_exposer_t GenericDatabase_exposer =
> GenericDatabase_exposer_t( "GenericDatabase", bp::init< >() );
>         bp::scope GenericDatabase_scope( GenericDatabase_exposer );
>       // A LOT OF FUNCTION DEFINITIONS HERE
> }
>
> NastranDatabase :
>
> #include "boost/python.hpp"
> #include "pyferespost.h"
> #include "NastranDatabase.pypp.hpp"
> namespace bp = boost::python;
> struct dataBase_wrapper : postLib::nastran::dataBase, bp::wrapper<
> postLib::nastran::dataBase > {
>     dataBase_wrapper( )
>     : postLib::nastran::dataBase( )
>       , bp::wrapper< postLib::nastran::dataBase >(){
>         // null constructor
>     }
>     // A LOT OF FUNCTION DEFINITIONS HERE
> };
>
>
> void register_NastranDatabase_class(){
>
>     bp::class_< dataBase_wrapper, bp::bases< postLib::generic::dataBase >,
> boost::noncopyable >( "NastranDatabase")
>  .def(bp::init< >() )
>   // A LOT OF .def HERE
> }
>
>
> Is there a problem in my wrappers?
> Why is the NastranDatabase constructor never called (it should call both)?
>
> Any idea?

May be. Can you send me Py++ warnings you get?

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

Re: [pygccxml-development] skipping base classes

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

On Wed, Sep 17, 2008 at 5:26 PM, Ken McGaugh <ke...@dn...> wrote:
> The way I imagine it working is that Py++ would list as the base class
> the first ancestor which has not been excluded.

My view is different: if you exclude base class, in this case you want
to "remove" it from hierarchy.
Obviously the choice is arguable.

> Thanks, I'll give that a try.  My main concern is getting the size of
> the module down, and I imaging a class with no members should be fairly
> light-weight.

I think you are right. The binary size, heavily depends on number and
complexity of template instantiations.

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

Re: [pygccxml-development] skipping base classes

[Ken M. <ke...@dn...>]

Roman Yakovenko wrote:
> On Wed, Sep 17, 2008 at 4:06 PM, Ken McGaugh <ke...@dn...> wrote:
>   
>> Hello all,
>>
>> After reading through the archives, docs, and the source code I cannot
>> find out a way to do the following.
>>
>> Say I have a class hierarchy like this:
>>
>>    class A
>>      [...]
>>
>>    class B : public A
>>      [...]
>>
>>    class C : public B
>>      [...]
>>
>> I need to expose to python the classes A and C, but not B.  When writing
>> the boost::python code manually I do this:
>>
>>    bp::class_<C, bp::bases<A> >("C")
>>
>> So that in python it thinks that C inherits directly from A and it all
>> works.  But now that I'm using Py++ I cannot figure out a way to achieve
>> the same thing and I have to expose the intermediate classes, which for
>> various reasons I really don't want to do.
>>
>> So is there a way to do what I want in Py++?
>>     
>
> I am not sure. I never tested such case. Try to exclude "B" and see
> what happens.
>   

When "B" is excluded then Py++ wraps the node with no bases listed 
whatsoever.

> If it doesn't work I will have to tweak Py++ to support such case. It
> should not be too difficult.
>   

The way I imagine it working is that Py++ would list as the base class 
the first ancestor which has not been excluded.
> One possible work around is to export class "B", but without any
> members and to give it pretty ugly alias, starting with '__'.
>   

Thanks, I'll give that a try.  My main concern is getting the size of 
the module down, and I imaging a class with no members should be fairly 
light-weight.

Thanks again.
--Ken