pygccxml-development

Re: [pygccxml-development] Properties vs methods

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

On 3/31/06, Matthias Baas <ba...@ir...> wrote:
> Hi,

Good evening.

> I just noticed a disadvantage of using attributes (properties) instead
> of method calls for things like decorating declarations. The problem is
> that things like typos in the source code do not get noticed because
> this will just attach a new attribute to the declaration instead of
> producing an error. A line like
>
>    m.callpolicies =3D return_self()
>
> looks as if it would assign a policy to a method m, but it doesn't
> because the attribute is misspelled. This error is quite hard to find.
> A method call on the other hand results in an attribute lookup which
> raises an exception when the attribute doesn't exist (or when it's not
> callable).

I am aware of this problem. I developed few techiques that help me to solve=
 that
problem quickly:

1. Set breakpoint on set property method. If you don't hit it - you
misspelled the
    name

2. Try to use PyChecker or something like this. It could help.

3. I think, we still can use properties, but we will make thier
get/set functions
    to be public:

class xxx:
    def set_x(...)
    def get_x(...)
    x  =3D property( set_x, get_x )

So if you want you can use functions instead of properties.

If you like 3'rd idea, we can implement the idea after this release.

> - Matthias -

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

[pygccxml-development] Properties vs methods

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

Hi,

I just noticed a disadvantage of using attributes (properties) instead 
of method calls for things like decorating declarations. The problem is 
that things like typos in the source code do not get noticed because 
this will just attach a new attribute to the declaration instead of 
producing an error. A line like

   m.callpolicies = return_self()

looks as if it would assign a policy to a method m, but it doesn't 
because the attribute is misspelled. This error is quite hard to find.
A method call on the other hand results in an attribute lookup which 
raises an exception when the attribute doesn't exist (or when it's not 
callable).

- Matthias -

Re: [pygccxml-development] Code freeze

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

On 3/30/06, Matthias Baas <ba...@ir...> wrote:
> Well, any function that has a non-const reference or pointer as argument
> is a potential problematic case that has to be reviewed by the user.
> Maybe it would be useful if pyplusplus could already give an estimate on
> whether a case is really problematic or not. One thing that could
> influence this is whether the type of the argument refers to a basic C++
> type or a compound type. I think if an argument of type "int&" is
> encountered then it is quite likely that this variable is really used as
> an output variable whereas I'd not be so sure anymore if the type is
> "MyClass&".

I think that next rule is applied:
function that returns/takes as argument non const reference/pointer to
fundamental type.

Lets start with this and will add the rules.


> >> If I find some time, I'll update my "alternative" driver script that
> >> uses the official module_builder_t class and see if I can get it to
> >> generate the bindings as well.
> >
> > If I can have Maya sdk I would like to do it. Please contact me
> > privately if you want.
>
> Well, Maya is a commercial application so I cannot pass around the SDK.
> But I could send you the current version of my driver script that
> generates the extension module if you want. You won't be able to
> actually run it, but you can see how the bindings are created and check
> how these things would have to be rewritten using module_builder_t.

Good enough.

> - Matthias -


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

Re: [pygccxml-development] Code freeze

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

Roman Yakovenko wrote:
>> that, I have only tested a fraction of the bindings so far (I'm still
>> expecting to encounter methods that have been wrapped without errors but
>> that actually cannot be called in Python (like image.getSize()).
> 
> I can help you a little. If you define the functions that could not be
> called from
> Python I will write some code, on decl_wrappers, that will identify
> such functions.
> So it will be easy to search them.

Well, any function that has a non-const reference or pointer as argument 
is a potential problematic case that has to be reviewed by the user.
Maybe it would be useful if pyplusplus could already give an estimate on 
whether a case is really problematic or not. One thing that could 
influence this is whether the type of the argument refers to a basic C++ 
type or a compound type. I think if an argument of type "int&" is 
encountered then it is quite likely that this variable is really used as 
an output variable whereas I'd not be so sure anymore if the type is 
"MyClass&".

>> If I find some time, I'll update my "alternative" driver script that
>> uses the official module_builder_t class and see if I can get it to
>> generate the bindings as well.
> 
> If I can have Maya sdk I would like to do it. Please contact me
> privately if you want.

Well, Maya is a commercial application so I cannot pass around the SDK. 
But I could send you the current version of my driver script that 
generates the extension module if you want. You won't be able to 
actually run it, but you can see how the bindings are created and check 
how these things would have to be rewritten using module_builder_t.

- Matthias -

Re: [pygccxml-development] Code freeze

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

On 3/30/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > Matthias do you agree/ready/have time to do code freeze and join our ef=
forts?
> >
> > Do you have some time for online conversation at the end of this week?
> >
> > I will try to study your code in order to prepare list of essential
> > differences.
> > Can you do the same with my code?
>
> I'm still busy getting the Maya bindings into their final shape. The
> status object to exception conversion is still missing, there are still
> some entire classes missing and some individual classes require manual
> customizations, so there's still a lot of work to do. And apart from
> that, I have only tested a fraction of the bindings so far (I'm still
> expecting to encounter methods that have been wrapped without errors but
> that actually cannot be called in Python (like image.getSize()).

I can help you a little. If you define the functions that could not be
called from
Python I will write some code, on decl_wrappers, that will identify
such functions.
So it will be easy to search them.

> At the moment, I'm fine with the current status of pyplusplus. There are
> currently no things that prevent me from going on with the Maya bindings
> (there are still a number of smaller things I'd like to see fixed for a
> 1.0 version, but at this point these are only of second priority).

I am glad to read this.

> If I find some time, I'll update my "alternative" driver script that
> uses the official module_builder_t class and see if I can get it to
> generate the bindings as well.

If I can have Maya sdk I would like to do it. Please contact me
privately if you want.

> What are the things you want to discuss before doing a release? As I
> said above, everything works fine for me at the moment, so you can just
> go ahead and do the release.

Nothing special, I just wanted to close the gaps.

>Feel free to take anything from the
> experimental module that you would also like to see in the official versi=
on.

Thank you. I will do that.

I hope next week I will release technology preview version.

> - Matthias -


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

Re: [pygccxml-development] Code freeze

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

Roman Yakovenko wrote:
> Matthias do you agree/ready/have time to do code freeze and join our efforts?
> 
> Do you have some time for online conversation at the end of this week?
> 
> I will try to study your code in order to prepare list of essential
> differences.
> Can you do the same with my code?

I'm still busy getting the Maya bindings into their final shape. The 
status object to exception conversion is still missing, there are still 
some entire classes missing and some individual classes require manual 
customizations, so there's still a lot of work to do. And apart from 
that, I have only tested a fraction of the bindings so far (I'm still 
expecting to encounter methods that have been wrapped without errors but 
that actually cannot be called in Python (like image.getSize()).

At the moment, I'm fine with the current status of pyplusplus. There are 
currently no things that prevent me from going on with the Maya bindings 
(there are still a number of smaller things I'd like to see fixed for a 
1.0 version, but at this point these are only of second priority).

If I find some time, I'll update my "alternative" driver script that 
uses the official module_builder_t class and see if I can get it to 
generate the bindings as well.

What are the things you want to discuss before doing a release? As I 
said above, everything works fine for me at the moment, so you can just 
go ahead and do the release. Feel free to take anything from the 
experimental module that you would also like to see in the official version.

- Matthias -

[pygccxml-development] Code freeze

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

Hi.

Matthias do you agree/ready/have time to do code freeze and join our effort=
s?

Do you have some time for online conversation at the end of this week?

I will try to study your code in order to prepare list of essential
differences.
Can you do the same with my code?

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

Re: [pygccxml-development] Re: Roadmap?

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

On 3/29/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > Where you will setup module name?
>
> In the constructor of the module builder (and probably with an
> appropriate "configuration method", but such a thing is still missing in
> the experimental module).

There are few reasons I want user to call method "create code creators tree=
".
One of them is that I think an user should be aware of code creators
tree, at least to the fact that after this call he can not change decl
wrapper properties. Second reason I want to guide user through the
process:

step 1: parse
step 2: configure declarations
step 3: create code creators
step 4: configure them
step 5: write module to files.

I think every step is important

> >> I *am* implementing the experimental module by using the functionality
> >> provided by pyplusplus. This has always been the case. I'm not plannin=
g
> >> on implementing my own code generation tool... :)
> >
> > Honestly, I don't see reuse of functionality except code creators.
>
> Decorating the declarations is done using the corresponding methods in
> the decl_wrappers.

:-), code creators and small part of decl_wrappers, this is not enough.

> >> But just because a piece of code is located in another directory doesn=
't
> >> mean it is more stable, does it?
> >
> > Yes it does. I have more then 40 unit testers + 3 projects ( EasyBMP,
> > boost.date_time and TnFOX ).
>
> Well, yes, the unit tests are quite impressive and already a sign of the
> quality of the software, but: the unit tests can only test an
> implementation, but not the "usability" or how intuitive an interface is.

Tomorrow I will commit "select" interface that has been updated according t=
o
your suggestions. So there will be not much difference in interface. I hope=
 we
will have same level of usability.

> >> I never said you should not do a release. I'm in favor of a new releas=
e!
> >> I'm only arguing that a new release shouldn't mean the end of the
> >> experimental module.
> >
> > Do you plan another revolution in pyplusplus :-)?
>
> Oh, I wasn't aware there has been a revolution... :)

Common, you did it! :-)

> > If no I see no point in experimental module.
>
> Well, it's for experimenting (and sharing that)... ;-)

:-)

> - Matthias -


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

Re: [pygccxml-development] Re: Roadmap?

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

Roman Yakovenko wrote:
>>>> - I think making the step to create code creators explicit is not
>>>> necessary. To me, code creators are rather an implementation detail a
>>>> user doesn't really have to know about (maybe this will change with more
>>>> advanced features...?).
>>> Here I am semi agree with you. I understand your point, but access to powerful
>>> features of pyplusplus( code creators ) should be also easy.
>> When the user needs it he can of course call the function, I'm only
>> arguing that it is not necessary to enforce such a call when it is not
>> required by the user (which I think is the common case).
> 
> Where you will setup module name?

In the constructor of the module builder (and probably with an 
appropriate "configuration method", but such a thing is still missing in 
the experimental module).

>> I *am* implementing the experimental module by using the functionality
>> provided by pyplusplus. This has always been the case. I'm not planning
>> on implementing my own code generation tool... :)
> 
> Honestly, I don't see reuse of functionality except code creators.

Decorating the declarations is done using the corresponding methods in 
the decl_wrappers.

>> But just because a piece of code is located in another directory doesn't
>> mean it is more stable, does it?
> 
> Yes it does. I have more then 40 unit testers + 3 projects ( EasyBMP,
> boost.date_time and TnFOX ).

Well, yes, the unit tests are quite impressive and already a sign of the 
quality of the software, but: the unit tests can only test an 
implementation, but not the "usability" or how intuitive an interface is.

>> I never said you should not do a release. I'm in favor of a new release!
>> I'm only arguing that a new release shouldn't mean the end of the
>> experimental module.
> 
> Do you plan another revolution in pyplusplus :-)? 

Oh, I wasn't aware there has been a revolution... :)

> If no I see no point in experimental module.

Well, it's for experimenting (and sharing that)... ;-)

- Matthias -

Re: [pygccxml-development] Re: Roadmap?

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

On 3/24/06, Matthias Baas <ba...@ir...> wrote:
> I even think it only takes a couple of minutes. But I think this would
> have been an important thing as it affects the user's script.

module_builder/__init__.py module now imports all necessary functionality.

> In my view there are three "layers" of software involved in the process
> of creating bindings. Here's some ASCII art that shows the layers (make
> sure to use a fixed pitch font for viewing):
>
> +------------------------------+
> |  The user's "driver" script  |
> +---------------------------+  |
> |  High level API           |  |
> +---------------------------+--+
> |  pygccxml/pyplusplus "core"  |
> +------------------------------+

Matthias, I don't want to start theoretical discussion, really.
In general I agree with you.

> Above you say that sticking the relevant stuff into one module is just
> "polishing" the implementation. Here I disagree! This "polishing"
> directly affects the user's script on the very top of those layers and
> as such, I consider it to be a very important issue.

I agree with you, but for me very important issue is something that will ta=
ke
few days to implement. Documentation is one of them, for example.

>Whereas if you
> modify something in the pyplusplus core or within the implementation of
> the high level API, but this modification is not "visible" in the user's
> script then there's actually nothing that needs discussion anyway.

I think you should understand that high level script and user api is
tightly coupled.
Second, sometimes implementation details important - for example performanc=
e.

> > There are few ways to go:
> > 1. You can pass all arguments needed for parsing to module_builder_t.__=
init__
> >     method.

Done.

> >> - The selection functions accept *any* keyword argument even when that
> >> argument is not used/valid at all.
> >
> > Well, all you say is that my implementation has not been polished and y=
ou are
> > right. It is just a concept.
>
> Yes, but missing documentation and missing warning/error message make it
> rather difficult to use. You can neither read how it works nor can you
> apply "trial and error" attempts.

Work in progress

> >> - I think making the step to create code creators explicit is not
> >> necessary. To me, code creators are rather an implementation detail a
> >> user doesn't really have to know about (maybe this will change with mo=
re
> >> advanced features...?).
> >
> > Here I am semi agree with you. I understand your point, but access to p=
owerful
> > features of pyplusplus( code creators ) should be also easy.
>
> When the user needs it he can of course call the function, I'm only
> arguing that it is not necessary to enforce such a call when it is not
> required by the user (which I think is the common case).

Where you will setup module name?

> I *am* implementing the experimental module by using the functionality
> provided by pyplusplus. This has always been the case. I'm not planning
> on implementing my own code generation tool... :)

Honestly, I don't see reuse of functionality except code creators.

> > I am sure your code will find the way into main branch in few hours.
>
> But I never said I wanted the high level API to be part of the main
> branch *as quickly as possible*. It has always been my point in the
> previous mails that I actually like it to be independent and separate
> from the core (as long as the API is still under heavy construction).

I consider API found in pyplusplus as stable. So I would like to insert you=
r
functionality inside. I would like to talk with you and explain every corne=
r
of pyplusplus.

> Didn't I mention that in a mail once? (hm, maybe I wanted to mention it
> but there were more important things at that time...) Anyway, after the
> introduction of the decl_wrappers it took me a while to get the basics
> working again, so during that period of time the more advanced features
> haven't been that important. That's going to change now... ;)

:-). Yes we will merge our efforts.

> >> But there are certainly features missing in the API. See for example,
> >> the section "What capabilites are not supported by the current API tha=
t
> >> we should have?" in the wiki.
> >
> > May be I am looking in a wrong place, can you post the link? Thanks
>
> https://realityforge.vrsource.org/view/PyOpenSG/PyppApiDiscussion

Yes, we will add missing features in next releases.

> But just because a piece of code is located in another directory doesn't
> mean it is more stable, does it?

Yes it does. I have more then 40 unit testers + 3 projects ( EasyBMP,
boost.date_time and TnFOX ).

>Wouldn't that be kind of a "false
> security" to think that this API couldn't change anymore?

This is not the message I pass to an user. Even API in main branch could be
changed. The main message is that API in main branch has been tested and it=
 is
useful.

>
> > If  I would wait, while I have "perfect" API, I
> > wouldn't get your and
> > Allen help. So lets go for release.
>
> I never said you should not do a release. I'm in favor of a new release!
> I'm only arguing that a new release shouldn't mean the end of the
> experimental module.

Do you plan another revolution in pyplusplus :-)? If no I see no point
in experimental
module.

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

Re: [pygccxml-development] Bug: Wrapper class constructor args without default values

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

On 3/28/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> when pyplusplus creates a wrapper class it doesn't apply the original
> default values to the arguments of the constructors. Because of that I
> got an error during compilation somewhere in a Boost.Python header
> because Boost.Python wanted to instantiate the class without providing
> all arguments (and that particular constructor didn't exist then).
> When I manually added the default values to the constructor in the
> generated files everything compiled fine.

Hi, I am aware of this bug. I found it and fixed. Tomorrow I will
commit it to CVS.
( I found it when I ported TnFOX pyplusplus script to new api ).

Thanks

> - Matthias -

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

[pygccxml-development] Bug: Wrapper class constructor args without default values

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

Hi,

when pyplusplus creates a wrapper class it doesn't apply the original 
default values to the arguments of the constructors. Because of that I 
got an error during compilation somewhere in a Boost.Python header 
because Boost.Python wanted to instantiate the class without providing 
all arguments (and that particular constructor didn't exist then).
When I manually added the default values to the constructor in the 
generated files everything compiled fine.

- Matthias -

Re: [pygccxml-development] finalize?

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

On 3/28/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> I'm not sure whether the finalize functionality should already be
> available or whether it's still missing. The function is available in
> the decl_wrappers but it doesn't seem to have an effect.
> So is this still on the todo list or should it already work?

It is missing. I think I will do it next week. Before this I should
address one of your
mails ( pyplusplus roadmap ). I hope we will find some time in the end
of the week
to merge our efforts/code

> - Matthias -


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

[pygccxml-development] finalize?

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

Hi,

I'm not sure whether the finalize functionality should already be 
available or whether it's still missing. The function is available in 
the decl_wrappers but it doesn't seem to have an effect.
So is this still on the todo list or should it already work?

- Matthias -

Re: [pygccxml-development] How to manage wrapper classes?

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

On 3/27/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > First of all I think you should be able to create custom call policies.
> > Take a look on this link:
> > http://boost.org/libs/python/doc/v2/CallPolicies.html#CallPolicies-conc=
ept
> >
> > May be, this will be enough, I am not sure.
>
> Interesting idea. From reading the above page I couldn't say if it is
> possible or not. precall() and postcall() are supposed to manage Python
> tuples which might indicate that they cannot access the original
> arguments....? Well, anyway, I posted a message to the c++-sig list,
> let's see what the "experts" have to say about this.
>
> >> So how should that be accomplished?
> >
> > There are 2 other ways to solve this problem.
> > 1. Create small wrappers in Python. I do not know exactly how it should=
 be done.
> >     But, I feel that this is the right way to go. I hope some days
> > pyplusplus will have
> >     3'rd tree - Python code creators ( they will generate Python code )=
.
>
> I have also thought about that and I might even get away with this for
> the Maya SDK, but in general, I think the problem would be that those
> Python wrappers would only be active when the object was created on the
> Python side and not on the C++ side.
>
> > 2. Create small wrapper in C++, in the way you did it. Just put that de=
claration
> >     in some namespace and add it to using add_code functions.
>
> But as I don't want to create the wrappers manually, how could I add
> wrappers that I generate automatically to the generated source files
> (not the main file)?

You don't have to create them manually. pygccxml is your friend. You
can find those
functions and generate 2 files: header and source with wrappers for
them. You just build
your own small code generator.

> > Using this
> >     approach you should be carefull. There are so many cases, while exp=
orting
> >     some function to Python. By the way, do we talk about pure virtual
> > functions or overloaded ones?
>
> What do you mean? The functions are not pure virtual, they are already
> implemented in the Maya SDK and I only need to access them. They are
> neither overloaded.... maybe I didn't understand the actual question...?

If you would deal with pure virtual or overloaded function the
solution would be much
complex.

> >> (and how can it be guaranteed that
> >> the user's wrapper code doesn't interfere with the wrapper code that
> >> might already get generated by pyplusplus?)
> >
> > 1. Do you still want to expose functions that returns, take by
> > reference MStatus object?
>
> Uhm, yes? (that's what my mail was about...?)

Sorry, I meant whether you want to expose original functions and
wrappers, or you want to
expose only wrappers?

> > If the answer is not then we can add replace_code function to decl_wrap=
per_t
> > class. Then pyplusplus will generate that code.
>
> What code would replace_code() replace?

pyplusplus generates code from declaration, right. We could add next
feature: instead
of creating code from declaration it will generate code provided by user.
Example: instead of doing next steps

my_class =3D mb.class_( 'X' )
mstatus_funcs =3D my_class.member_functions( all functions that has MStatus=
 )
for func in mstatus_funcs:
    func.exclude()
    my_class.add_code( wrapper function reference )

You would write something like:

my_class =3D mb.class_( 'X' )
mstatus_funcs =3D my_class.member_functions( all functions that has MStatus=
 )
for func in mstatus_funcs:
    func.replace_code( wrapper function reference )

This approach has few advances over first one.

I hope now I was clear.



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

Re: [pygccxml-development] How to manage wrapper classes?

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

Roman Yakovenko wrote:
> First of all I think you should be able to create custom call policies.
> Take a look on this link:
> http://boost.org/libs/python/doc/v2/CallPolicies.html#CallPolicies-concept
> 
> May be, this will be enough, I am not sure.

Interesting idea. From reading the above page I couldn't say if it is 
possible or not. precall() and postcall() are supposed to manage Python 
tuples which might indicate that they cannot access the original 
arguments....? Well, anyway, I posted a message to the c++-sig list, 
let's see what the "experts" have to say about this.

>> So how should that be accomplished?
> 
> There are 2 other ways to solve this problem.
> 1. Create small wrappers in Python. I do not know exactly how it should be done.
>     But, I feel that this is the right way to go. I hope some days
> pyplusplus will have
>     3'rd tree - Python code creators ( they will generate Python code ).

I have also thought about that and I might even get away with this for 
the Maya SDK, but in general, I think the problem would be that those 
Python wrappers would only be active when the object was created on the 
Python side and not on the C++ side.

> 2. Create small wrapper in C++, in the way you did it. Just put that declaration
>     in some namespace and add it to using add_code functions. 

But as I don't want to create the wrappers manually, how could I add 
wrappers that I generate automatically to the generated source files 
(not the main file)?

> Using this
>     approach you should be carefull. There are so many cases, while exporting
>     some function to Python. By the way, do we talk about pure virtual
> functions or overloaded ones?

What do you mean? The functions are not pure virtual, they are already 
implemented in the Maya SDK and I only need to access them. They are 
neither overloaded.... maybe I didn't understand the actual question...?

>> (and how can it be guaranteed that
>> the user's wrapper code doesn't interfere with the wrapper code that
>> might already get generated by pyplusplus?)
> 
> 1. Do you still want to expose functions that returns, take by
> reference MStatus object?

Uhm, yes? (that's what my mail was about...?)

> If the answer is not then we can add replace_code function to decl_wrapper_t
> class. Then pyplusplus will generate that code.

What code would replace_code() replace?

> If the answer is yes, then you have a problem. It seems to me that pyplusplus
> contains all tools in order to solve this problem, may be it does not
> expose good interface ( we will find out, right :-) ).

I hope so. :)

Well, I hope I'll get an answer to my mail on the c++-sig list so that 
we'll see if explicit wrappers are definitely required or not.

- Matthias -

Re: [pygccxml-development] How to manage wrapper classes?

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

On 3/26/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > Lets skip the rest. Here is what I propouse to you:
> > http://boost.org/libs/python/doc/v2/faq.html#custom_string
>
> Oops, I missed that one!
> I've just tried it out and it works like a charm. Thanks!

My pleasure.

> In the Maya SDK error handling is done with MStatus objects which carry
> error information (C++ exceptions are never used). There are two
> possibilities how a SDK function returns a result object. It either
> returns a MStatus object as in the following example:
>
> MStatus select(MObject& object);
>
> or it expects an optional pointer to a MStatus object as input which it
> uses to set its status information:
>
> bool isSelected(MObject& object, MStatus* ReturnStatus=3DNULL);
>
> So far, the Python bindings just work like the C++ version. But what I
> would actually like to have is that the Python version may raise an
> exception when an error occurs, no matter if the user provided a MStatus
> object or not.
> I suppose in the first case where the function returns a MStatus object
> I could probably "abuse" a result converter to check for an error
> instead of converting the value (I haven't tried that out yet). But for
> the second case I think it requires a wrapper because I need to place
> code before and after the actual function call, something like:
>
> bool isSelected_wrapped(MObject& object, MStatus* ReturnStatus=3DNULL)
> {
>    MStatus internalstat;
>    MStatus* finalstat=3D&internalstat;
>    // If the user provided a MStatus object then use this one...
>    if (ReturnStatus!=3DNULL)
>    {
>      finalstat =3D ReturnStatus;
>    }
>
>    // Call the original function...
>    bool res =3D isSelected(object, finalstat);
>
>    // Check for errors...
>    if (exceptions_enabled && finalstat->error())
>    {
>      throw AnAppropriateException();
>    }
>    return res;
> }

First of all I think you should be able to create custom call policies.
Take a look on this link:
http://boost.org/libs/python/doc/v2/CallPolicies.html#CallPolicies-concept

May be, this will be enough, I am not sure.

> So how should that be accomplished?

There are 2 other ways to solve this problem.
1. Create small wrappers in Python. I do not know exactly how it should be =
done.
    But, I feel that this is the right way to go. I hope some days
pyplusplus will have
    3'rd tree - Python code creators ( they will generate Python code ).

2. Create small wrapper in C++, in the way you did it. Just put that declar=
ation
    in some namespace and add it to using add_code functions. Using this
    approach you should be carefull. There are so many cases, while exporti=
ng
    some function to Python. By the way, do we talk about pure virtual
functions or
    overloaded ones?

>(and how can it be guaranteed that
> the user's wrapper code doesn't interfere with the wrapper code that
> might already get generated by pyplusplus?)

1. Do you still want to expose functions that returns, take by
reference MStatus
    object?

If the answer is not then we can add replace_code function to decl_wrapper_=
t
class. Then pyplusplus will generate that code.

If the answer is yes, then you have a problem. It seems to me that pypluspl=
us
contains all tools in order to solve this problem, may be it does not
expose good
interface ( we will find out, right :-) ).

If I were you I'd ask on boost.python mailing list about this problem
and it's solution
using call policies.

> - Matthias -


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

Re: [pygccxml-development] How to manage wrapper classes?

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

Roman Yakovenko wrote:
> Lets skip the rest. Here is what I propouse to you:
> http://boost.org/libs/python/doc/v2/faq.html#custom_string

Oops, I missed that one!
I've just tried it out and it works like a charm. Thanks!

Now that this problem is solved there's already the next one which is 
somewhat related and which, I believe, needs a different solution.

In the Maya SDK error handling is done with MStatus objects which carry 
error information (C++ exceptions are never used). There are two 
possibilities how a SDK function returns a result object. It either 
returns a MStatus object as in the following example:

MStatus select(MObject& object);

or it expects an optional pointer to a MStatus object as input which it 
uses to set its status information:

bool isSelected(MObject& object, MStatus* ReturnStatus=NULL);

So far, the Python bindings just work like the C++ version. But what I 
would actually like to have is that the Python version may raise an 
exception when an error occurs, no matter if the user provided a MStatus 
object or not.
I suppose in the first case where the function returns a MStatus object 
I could probably "abuse" a result converter to check for an error 
instead of converting the value (I haven't tried that out yet). But for 
the second case I think it requires a wrapper because I need to place 
code before and after the actual function call, something like:

bool isSelected_wrapped(MObject& object, MStatus* ReturnStatus=NULL)
{
   MStatus internalstat;
   MStatus* finalstat=&internalstat;
   // If the user provided a MStatus object then use this one...
   if (ReturnStatus!=NULL)
   {
     finalstat = ReturnStatus;
   }

   // Call the original function...
   bool res = isSelected(object, finalstat);

   // Check for errors...
   if (exceptions_enabled && finalstat->error())
   {
     throw AnAppropriateException();
   }
   return res;
}

So how should that be accomplished? (and how can it be guaranteed that 
the user's wrapper code doesn't interfere with the wrapper code that 
might already get generated by pyplusplus?)

- Matthias -

Re: [pygccxml-development] How to manage wrapper classes?

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

On 3/24/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> let me first state the problem I'm currently trying to solve. The Maya
> SDK defines its own string class MString which is part of my bindings.
> Any function that expects a string as input actually expects a MString
> object. But for the Python version I would also like the functions to
> accept regular Python strings as well (and maybe even return Python
> strings instead of MStrings but I leave that up for later). I tried to
> use the implicitly_convertible construct but it didn't work. I could get
> it to work with a string class that also accepts a std::string in its
> constructor but the MString class only accepts const char* which didn't
> work for me.

Lets skip the rest. Here is what I propouse to you:
http://boost.org/libs/python/doc/v2/faq.html#custom_string
and take a look on pyplusplus QtXML example. If it does not help you
then we will discuss the rest.

If you decide to use this solution, than you have few choices how to integr=
ate
that solution with pyplusplus.

Hope this was helpful.


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

[pygccxml-development] How to manage wrapper classes?

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

Hi,

let me first state the problem I'm currently trying to solve. The Maya 
SDK defines its own string class MString which is part of my bindings. 
Any function that expects a string as input actually expects a MString 
object. But for the Python version I would also like the functions to 
accept regular Python strings as well (and maybe even return Python 
strings instead of MStrings but I leave that up for later). I tried to 
use the implicitly_convertible construct but it didn't work. I could get 
it to work with a string class that also accepts a std::string in its 
constructor but the MString class only accepts const char* which didn't 
work for me.

My conclusion was that I need to write wrappers for those functions that 
expect an MString as input so that they also accept a str object. I'm 
not liking the idea of having to do that manually on each function, so I 
wonder if there's an easy way to specify that in my script and have 
pyplusplus do the real work.

I think it's easy to identify the functions that need those wrappers as 
I can just inspect the argument list of those functions. But what then?
If I could add new C++ functions to a generated source file then I think 
I could create automatic wrappers and use cdef to add those "overloaded" 
functions to the original object. But what if a function already has a 
wrapper generated by pyplusplus? How are they concatenated? Could 
pyplusplus handle that automatically?

Any ideas?

- Matthias -

[pygccxml-development] Re: Roadmap?

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

Roman Yakovenko wrote:
>> - There's no single module from which the user can import all the
>> required stuff but instead he has to know where everything is located.
> 
> I did not want to polish my implementation. I think it is very easy to
> add aliases
> to relevant classes in module_builder/__init__.py file. I think it
> should take 1 hour.
> Am I wrong?

I even think it only takes a couple of minutes. But I think this would 
have been an important thing as it affects the user's script.

In my view there are three "layers" of software involved in the process 
of creating bindings. Here's some ASCII art that shows the layers (make 
sure to use a fixed pitch font for viewing):

+------------------------------+
|  The user's "driver" script  |
+---------------------------+  |
|  High level API           |  |
+---------------------------+--+
|  pygccxml/pyplusplus "core"  |
+------------------------------+

On top there's the script written by the user that controls pyplusplus 
and creates the final bindings. It should be "easy" (whatever that 
means) for the user to write and maintain this script. The script will 
most likely stick to the high level API but it can also use the "core" 
directly if this is of any advantage.
The second layer is the high level API that handles all the internals of 
pyplusplus and provides the main interface for the driver script so that 
the user's script can concentrate on tailoring the bindings to the 
user's needs. Internally, the high level API uses the "core" just as if 
it was another user script.
The bottom layer is the actual "core" of pyplusplus. It does all the 
work and contains everything that is required to write the final C++ 
source code. It also provides an API but at a lower level (basically 
this is what pyplusplus has already been a month ago).

A few noteworthy points:

- The purpose of the high level API is to make the user's life easier 
and his script more "manageable". The API is not vital for the results. 
The script could produce the very same extension module by using the 
core directly.

- The core is entirely independent of the high level API. From the 
core's point of view the high level API is just another "user script". 
As a consequence, for every piece of code in pyplusplus it should be 
clear whether this code conceptually belongs to the core or to the high 
level API.

- The high level API may still contain "logic" and functionality that is 
not part of the core if this functionality is not strictly required for 
writing extension source code.

Now, in my opinion, when we talk about the interface our main focus 
should be the topmost layer, that is, how should the user's script look 
like? Whereas it seems to me that this thread currently rather focuses 
on the implementation of the middle and bottom layer (which is not that 
relevant at this point).

Above you say that sticking the relevant stuff into one module is just 
"polishing" the implementation. Here I disagree! This "polishing" 
directly affects the user's script on the very top of those layers and 
as such, I consider it to be a very important issue. Whereas if you 
modify something in the pyplusplus core or within the implementation of 
the high level API, but this modification is not "visible" in the user's 
script then there's actually nothing that needs discussion anyway.


>> - The module builder still requires the config object (which I would
>> rather regard as an internal pyplusplus object).
> 
> There are few ways to go:
> 1. You can pass all arguments needed for parsing to module_builder_t.__init__
>     method.
> 
>     I prefer this method
> 
> 2. You can create some class that will aggregate all needed settings and user
>     will pass it to module_builder_t.__init__
> 
>    If you like this approach, we will implement it.

I prefer 1 as well (maybe in addition to some specific config methods) 
and this is already how the experimental ModuleBuilder works. Your 
version uses method 2 which is why I was complaining.

>> - The selection functions accept *any* keyword argument even when that
>> argument is not used/valid at all.
> 
> Well, all you say is that my implementation has not been polished and you are
> right. It is just a concept.

Yes, but missing documentation and missing warning/error message make it 
rather difficult to use. You can neither read how it works nor can you 
apply "trial and error" attempts.

>> - I think making the step to create code creators explicit is not
>> necessary. To me, code creators are rather an implementation detail a
>> user doesn't really have to know about (maybe this will change with more
>> advanced features...?).
> 
> Here I am semi agree with you. I understand your point, but access to powerful
> features of pyplusplus( code creators ) should be also easy. 

When the user needs it he can of course call the function, I'm only 
arguing that it is not necessary to enforce such a call when it is not 
required by the user (which I think is the common case).

> When user call this
> function the only parameter he should give is module name. Also we talk with
> you that every step after parsing should be done explicitly, don't we?

Uhm, I don't remember having said that every step should be explicit. 
Maybe this was just a misunderstanding then...

>>> We can discuss them in few mails and I think we could implement
>>> them on main branch.
>> But if you would now implement everything so that it conforms to my
>> opinion, then you would basically end up with the experimental module.
>> So what's the point of doing that?
> 
> Implementation details. If you are going to implement experimental branch
> using functionality provided by pyplusplus 

I *am* implementing the experimental module by using the functionality 
provided by pyplusplus. This has always been the case. I'm not planning 
on implementing my own code generation tool... :)

> I am sure your code will find the way into main branch in few hours.

But I never said I wanted the high level API to be part of the main 
branch *as quickly as possible*. It has always been my point in the 
previous mails that I actually like it to be independent and separate 
from the core (as long as the API is still under heavy construction).

>> We have that already.
>> Instead we should try to get the core of pyplusplus stable and flexible
>> enough (one area which I still think is a weak point in pyplusplus is
>> the ability to customize the individual output files. I still don't know
>> how/if I could add source code at the declaration level in a particular
>> output file or modify the include files from one particular file).
> 
> Until now, no one requested this functionality. 

Didn't I mention that in a mail once? (hm, maybe I wanted to mention it 
but there were more important things at that time...) Anyway, after the 
introduction of the decl_wrappers it took me a while to get the basics 
working again, so during that period of time the more advanced features 
haven't been that important. That's going to change now... ;)

>> But there are certainly features missing in the API. See for example,
>> the section "What capabilites are not supported by the current API that
>> we should have?" in the wiki.
> 
> May be I am looking in a wrong place, can you post the link? Thanks

https://realityforge.vrsource.org/view/PyOpenSG/PyppApiDiscussion

>>> Matthias, I want people to start using pyplusplus.
>> I see that you're eager to get out a new release, and this is fine with
>> me. :) But what's the problem with releasing pyplusplus and referring to
>> the experimental module which the people can try out and provide
>> feedback? This is not going to be the 1.0 release, is it? ;)
> 
> There is one problem:I think people will not start to use it, until you can say
> explicitly: only small parts of this API could be change. And we can
> not say this on experimental branch :-(

But just because a piece of code is located in another directory doesn't 
mean it is more stable, does it? Wouldn't that be kind of a "false 
security" to think that this API couldn't change anymore?

>>> code. What do you think about next plan: this and next week you are
>>> going to develop
>>> missing functionality.From the 1/04 we close experimental branch and
>>> start merging almost all functionality to main  branch.
>> I cannot guarantee that in a week or two the experimental API will be
>> finished. Actually, I'm pretty much sure that it won't be finished by
>> then as there are still a lot of areas we haven't addressed yet.
> 
> Matthias, I think that this is okay, really. You started to use pyplusplus when
> it was a pain. 

:)

> If  I would wait, while I have "perfect" API, I
> wouldn't get your and
> Allen help. So lets go for release. 

I never said you should not do a release. I'm in favor of a new release! 
I'm only arguing that a new release shouldn't mean the end of the 
experimental module.

>> For me, one of the next things I'd like to see would be automated
>> wrapper generation.... but this is an entirely new thing that I don't
>> know yet how this could be done (and if it could be done at all). It's
>> just an area that needs some experimentation... :)
> 
> Do you know what I am thinking about? GUI. Just imagine you have tree with all
> declarations at the left. On the top you have Python interpreter or an other
> window, that will help you to select declarations set. On the center you will
> have a list of properties and explanation. Nice, ha? Almost fully automated
> solution. But ...

This might be a handy tool. But it will also take quite a bit of time to 
implement that properly...

>> So how about the following instead as the next milestone for pyplusplus:
>>
>> "Get the core of pyplusplus stable and flexible so that *any* high level
>> API could be implemented on top of that without having to modify
>> pygccxml/pyplusplus"
> 
> First of all you need to define a core. Do declaration_matcher_t class hierarchy
> and decl_wrappers are core or not. ( Pay attention select interface implemented
> on decl_wrappers )

By default, I consider everything in pyplusplus as being part of the 
core and everything beneath experimental as high level. :)
The decl_wrapper classes are core classes to me and they are actually 
used already in the experimental module, even though they are only used 
as "decorators" whereas the selection interface is not used. By the way, 
that's an example where the (builtin) high level API is intermingled 
with the core which I do not like. As I said above, I would prefer a 
modular approach where these things are strictly kept separate and where 
the core is independent from the high level API.

- Matthias -

Re: Roadmap? (was: Re: [pygccxml-development] Printing declarations...)

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

On 3/23/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> >> I noticed that the selection works differently in your version compare=
d
> >> to the experimental version. I would have only called it "stable" when
> >> the interface in both versions would have been identical as in this
> >> case, it would have shown that we all agree on one common scheme.
> >> Obviously this is not yet the case.
> >
> > Why? In my opinion our "select" interfaces are very very similar.
> > What I am missing. I do aware about differences in regex filter/matcher=
, but
> > that's all.
>
> In the date_time example you're very often using lambda functions to do
> selections. The function is passed as first argument (without using
> keyword arguments), but sometimes you also just pass a string with the
> declaration name as first argument. So obviously there is some builtin
> rule about what the argument types may look like in your version. The
> experimental version doesn't have that. So far, it is only guaranteed
> that the first argument is the name filter, all other filters must be
> specified by keyword arguments. Actually, I haven't found out yet what
> arguments your selection functions do provide (the source code is not
> that easy to read)...

:-) Now you are talking. Remember, I like when you critic me. So lets start=
.

The rule is next
  ( decl_wrappers/scopedef_wrapper.py
   relevant functions: __create_matcher, _find_single, _find_multiple )

    def __create_matcher( self, match_class, *args, **keywds ):
        if len( args ) =3D=3D 1 and callable( args[0] ):
            matcher =3D match_class( [], **keywds)
            return lambda decl: matcher( decl ) and args[0](decl)
        else:
            if 1 =3D=3D len( args ) and isinstance( args[0], str ):
                keywds['name'] =3D args[0]
                args =3D []
            return match_class(*args, **keywds)

If user pass one callable argument then I construct instance of concrete ma=
tcher
class and join it with user function.

Else, I just construct matcher with user arguments, if he passes only
one argument
then I say that this argument represents the name of decl(s) he wants to fi=
nd.
Here, there is an other difference: user don't have to specify whether name=
 is
full name or object name only. declarations.declaration_matcher_t can find =
it
by itself

What can you pass as arguments? You have to see declaration matchers class
hierarchy.

> >> So switching entirely to
> >> your version would take quite a bit of time and even with my current
> >> partial script I've noticed things that could be improved in my opinio=
n.
> >
> > What are they?
>
>  From the top of my head:
>
> - There's no single module from which the user can import all the
> required stuff but instead he has to know where everything is located.

I did not want to polish my implementation. I think it is very easy to
add aliases
to relevant classes in module_builder/__init__.py file. I think it
should take 1 hour.
Am I wrong?

> - The module builder still requires the config object (which I would
> rather regard as an internal pyplusplus object).

There are few ways to go:
1. You can pass all arguments needed for parsing to module_builder_t.__init=
__
    method.

    I prefer this method

2. You can create some class that will aggregate all needed settings and us=
er
    will pass it to module_builder_t.__init__

   If you like this approach, we will implement it.

3. Your approach is going here

   I am sure you have an other idea. So we can discuss it also.

4. module_builder_t.__init__ don't take any arguments or it could take
it does not
    matter, because module_builder_t will expose set of variables that user=
 can
    configure and only after that to call parse function.

    I am strongly against this approach. Class interface should guide user.
Although for almost every function in this class there is a precondition:
declarations tree has been extracted from sources. So lets force it in __in=
it__.
I am almost sure user don't need such flexibility.

> - The selection functions accept *any* keyword argument even when that
> argument is not used/valid at all.

Well, all you say is that my implementation has not been polished and you a=
re
right. It is just a concept.

> - I think making the step to create code creators explicit is not
> necessary. To me, code creators are rather an implementation detail a
> user doesn't really have to know about (maybe this will change with more
> advanced features...?).

Here I am semi agree with you. I understand your point, but access to power=
ful
features of pyplusplus( code creators ) should be also easy. When user call=
 this
function the only parameter he should give is module name. Also we talk wit=
h
you that every step after parsing should be done explicitly, don't we?
May be I've got you wrong?

I choose bad name. I thought about:
create_in_memory_module, but it is too long. So you can suggest something
better.

pypp_api.py also has this function.

>Apart from that, the error message that appears
> when a user forgets to do this step (as happened with me :) is confusing:
>
> "self.module is equal to None. Did you forget to call create_module
> function?"

If we could agree on previous item, I am sure we can provide better
error message.

> The first sentence refers to an internal variable the user does not know
> about and the second sentence refers to a function that does not exist.

Fixed.

> - When I wrote the source files without doing any decorations I got an
> empty module. So far, so good, this has been the test to check whether
> declarations are ignored or exposed by default. But when I added
> include() calls for some particular classes, I actually got many more
> classes in the output (that I didn't want).

The default behaviour is next: export all declarations from file and
files that belongs
to the same directory as included file. You can suggest an other
default behaviour.
This is not the point I will argue with you.

> - There are no doc strings... ;-)

Guilty, guilty an guilty :-)

> > We can discuss them in few mails and I think we could implement
> > them on main branch.
>
> But if you would now implement everything so that it conforms to my
> opinion, then you would basically end up with the experimental module.
> So what's the point of doing that?

Implementation details. If you are going to implement experimental branch
using functionality provided by pyplusplus I am sure your code will find th=
e
way into main branch in few hours.

> We have that already.
> Instead we should try to get the core of pyplusplus stable and flexible
> enough (one area which I still think is a weak point in pyplusplus is
> the ability to customize the individual output files. I still don't know
> how/if I could add source code at the declaration level in a particular
> output file or modify the include files from one particular file).

Until now, no one requested this functionality. In general I have one rule:
I don't write code if no one needs it. If you need such functionality,
then please
start an other discussion with detailed description of your use case.
I am almost
sure we can find good solution to the problem.

> So far, I have been fine with the selection in the experimental module.
> But I guess some more filters could be useful eventually. And the
> performance could be better, of course. :)

Please don't be greedy :-). I am sure when people will start using
pyplusplus, they
will contribute a lot of filters and suggestions to improve performance.

> But there are certainly features missing in the API. See for example,
> the section "What capabilites are not supported by the current API that
> we should have?" in the wiki.

May be I am looking in a wrong place, can you post the link? Thanks
Also, there are always so many things that we could implement. I have
so many crazy ideas. I prefer to release something very usable, in order
to get users opinion

> > Matthias, I want people to start using pyplusplus.
>
> I see that you're eager to get out a new release, and this is fine with
> me. :) But what's the problem with releasing pyplusplus and referring to
> the experimental module which the people can try out and provide
> feedback? This is not going to be the 1.0 release, is it? ;)

There is one problem:I think people will not start to use it, until you can=
 say
explicitly: only small parts of this API could be change. And we can
not say this
on experimental branch :-(

Also if you re implement your high level API in terms of matchers and
decl_wrappers, I think we can release even 2 interface. They will peek what=
 ever
they like. It could be fun, don't you think so :-) ?

> > code. What do you think about next plan: this and next week you are
> > going to develop
> > missing functionality.From the 1/04 we close experimental branch and
> > start merging almost all functionality to main  branch.
>
> I cannot guarantee that in a week or two the experimental API will be
> finished. Actually, I'm pretty much sure that it won't be finished by
> then as there are still a lot of areas we haven't addressed yet.

Matthias, I think that this is okay, really. You started to use pyplusplus =
when
it was a pain. If  I would wait, while I have "perfect" API, I
wouldn't get your and
Allen help. So lets go for release. Please concentrate on major
feature and functionality. We always can add functionality here and
there. Or to fix
couple of bugs.

> For me, one of the next things I'd like to see would be automated
> wrapper generation.... but this is an entirely new thing that I don't
> know yet how this could be done (and if it could be done at all). It's
> just an area that needs some experimentation... :)

Do you know what I am thinking about? GUI. Just imagine you have tree with =
all
declarations at the left. On the top you have Python interpreter or an othe=
r
window, that will help you to select declarations set. On the center you wi=
ll
have a list of properties and explanation. Nice, ha? Almost fully automated
solution. But ...

> So how about the following instead as the next milestone for pyplusplus:
>
> "Get the core of pyplusplus stable and flexible so that *any* high level
> API could be implemented on top of that without having to modify
> pygccxml/pyplusplus"

First of all you need to define a core. Do declaration_matcher_t class hier=
archy
and decl_wrappers are core or not. ( Pay attention select interface impleme=
nted
on decl_wrappers )

After this I think that I am agree with you. Although there is only
one way to prove
that core is stable enough - to implement module_builder class.

So please make a review on your and my code, decide and at the end of next
week I hope we could talk few hours on IRC in order to close issues. I
will try to create a list of concrete open questions. I hope we will
be able to produce
something until 20/04.

> - Matthias -

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

Roadmap? (was: Re: [pygccxml-development] Printing declarations...)

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

Roman Yakovenko wrote:
>> I noticed that the selection works differently in your version compared
>> to the experimental version. I would have only called it "stable" when
>> the interface in both versions would have been identical as in this
>> case, it would have shown that we all agree on one common scheme.
>> Obviously this is not yet the case.
> 
> Why? In my opinion our "select" interfaces are very very similar.
> What I am missing. I do aware about differences in regex filter/matcher, but
> that's all.

In the date_time example you're very often using lambda functions to do 
selections. The function is passed as first argument (without using 
keyword arguments), but sometimes you also just pass a string with the 
declaration name as first argument. So obviously there is some builtin 
rule about what the argument types may look like in your version. The 
experimental version doesn't have that. So far, it is only guaranteed 
that the first argument is the name filter, all other filters must be 
specified by keyword arguments. Actually, I haven't found out yet what 
arguments your selection functions do provide (the source code is not 
that easy to read)...

>> So switching entirely to
>> your version would take quite a bit of time and even with my current
>> partial script I've noticed things that could be improved in my opinion.
> 
> What are they? 

 From the top of my head:

- There's no single module from which the user can import all the 
required stuff but instead he has to know where everything is located.

- The module builder still requires the config object (which I would 
rather regard as an internal pyplusplus object).

- The selection functions accept *any* keyword argument even when that 
argument is not used/valid at all.

- I think making the step to create code creators explicit is not 
necessary. To me, code creators are rather an implementation detail a 
user doesn't really have to know about (maybe this will change with more 
advanced features...?). Apart from that, the error message that appears 
when a user forgets to do this step (as happened with me :) is confusing:

"self.module is equal to None. Did you forget to call create_module 
function?"

The first sentence refers to an internal variable the user does not know 
about and the second sentence refers to a function that does not exist.

- When I wrote the source files without doing any decorations I got an 
empty module. So far, so good, this has been the test to check whether 
declarations are ignored or exposed by default. But when I added 
include() calls for some particular classes, I actually got many more
classes in the output (that I didn't want).

- There are no doc strings... ;-)

> We can discuss them in few mails and I think we could implement
> them on main branch.

But if you would now implement everything so that it conforms to my 
opinion, then you would basically end up with the experimental module. 
So what's the point of doing that? We have that already.
Instead we should try to get the core of pyplusplus stable and flexible 
enough (one area which I still think is a weak point in pyplusplus is 
the ability to customize the individual output files. I still don't know 
how/if I could add source code at the declaration level in a particular 
output file or modify the include files from one particular file).

>> and hopefully we can objectively
>> balance the pros and cons of each version once they're in a state that
>> the respective supporters are happy with. :)
> 
> That is exactly what I want. I think you and I developed enough. It is a time
> to move on. I think we should sit and merge our sources/ideas.
> Do you think that there are some major features that is still missing
> in my/your selection code base?

So far, I have been fine with the selection in the experimental module. 
But I guess some more filters could be useful eventually. And the 
performance could be better, of course. :)

But there are certainly features missing in the API. See for example, 
the section "What capabilites are not supported by the current API that 
we should have?" in the wiki.

> Matthias, I want people to start using pyplusplus. 

I see that you're eager to get out a new release, and this is fine with 
me. :) But what's the problem with releasing pyplusplus and referring to 
the experimental module which the people can try out and provide 
feedback? This is not going to be the 1.0 release, is it? ;)

> code. What do you think about next plan: this and next week you are
> going to develop
> missing functionality.From the 1/04 we close experimental branch and
> start merging almost all functionality to main  branch.

I cannot guarantee that in a week or two the experimental API will be 
finished. Actually, I'm pretty much sure that it won't be finished by 
then as there are still a lot of areas we haven't addressed yet.
For me, one of the next things I'd like to see would be automated 
wrapper generation.... but this is an entirely new thing that I don't 
know yet how this could be done (and if it could be done at all). It's 
just an area that needs some experimentation... :)

So how about the following instead as the next milestone for pyplusplus:

"Get the core of pyplusplus stable and flexible so that *any* high level 
API could be implemented on top of that without having to modify 
pygccxml/pyplusplus"



- Matthias -

Re: [pygccxml-development] Printing declarations...

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

On 3/23/06, Matthias Baas <ba...@ir...> wrote:
> I noticed that the selection works differently in your version compared
> to the experimental version. I would have only called it "stable" when
> the interface in both versions would have been identical as in this
> case, it would have shown that we all agree on one common scheme.
> Obviously this is not yet the case.

Why? In my opinion our "select" interfaces are very very similar.
What I am missing. I do aware about differences in regex filter/matcher, bu=
t
that's all.

> I just tried to write a driver script for the Maya module that only uses
>   the "official" module_builder_t class. I thought I could mainly use my
> existing script and only inject aliases for the method names in
> module_builder and decl_wrapper. But it's not only the naming convention
> but also the interface itself that differs.

You right, there are differences, but not the conceptual ones. I can be fle=
xible
( At least I believe so :-) )

> So switching entirely to
> your version would take quite a bit of time and even with my current
> partial script I've noticed things that could be improved in my opinion.

What are they? We can discuss them in few mails and I think we could implem=
ent
them on main branch.

> But at least it provides a basis for further discussion
> (as I just see it as another proposal for an API)

And you are right.

> and hopefully we can objectively
> balance the pros and cons of each version once they're in a state that
> the respective supporters are happy with. :)

That is exactly what I want. I think you and I developed enough. It is a ti=
me
to move on. I think we should sit and merge our sources/ideas.
Do you think that there are some major features that is still missing
in my/your selection code base?

> > Although your implementation is so different from my.
> > I fill a little bit uncomfortable with this.
>
> Yes, we seem to have different ways of thinking and programming... ;-)

Yes we are :-)

> But anyway, the focus is still on the *interface*, isn't it? This means,
> the actual implementation of a prototype interface is not important at
> all (as long as it works and can be used to test the interface).

Yes. So may we close at least select interface?

> For a final implementation (once the interface is stable!), we should
> find better algorithms anyway. For example, querying for declarations
> could be a lot faster (now that the parsing time is no issue anymore,
> querying for declarations has become the new bottleneck for me).
> Currently, we use a rather naive approach of iterating through all
> declarations and applying a filter function which is O(n) for a single
> query. It would be great if a final version could reduce this complexity
> to O(log(n)) or even O(1) by doing some preprocessing. By the way, such
> a thing might also have an effect on the interface itself. If you base
> selections solely on user-provided functions then there's little you can
> do to get any better than O(n). But if you provide a set of predefined
> filter functions then we know in advance how this filters work and can
> exploit that knowledge to speed up the queries.

I also saw performance problems and I think I can fix them without changing
select interface

> > P.S.2 Can you start writing some introduction/tutorial for high level A=
PI?
>
> I'll see that I gradually update the documentation of the experimental
> module. You can then take the parts that are identical and use them for
> your version as well. But I'm afraid I'm not yet able to write a
> tutorial for your version as I'm not entirely familiar with the way it's
> supposed to work and I even think that a couple of things need improvemen=
t.

Please say what are they? As I already said, I am going to be pretty
busy next week,
but at the end of the week we can chat a little, what do you think?

Matthias, I want people to start using pyplusplus. So I think that we
should stop
"code creation" and start merging. Almost all your ideas found the way
into pyplusplus
code. What do you think about next plan: this and next week you are
going to develop
missing functionality.From the 1/04 we close experimental branch and
start merging
almost all functionality to main  branch.

Thanks

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

Re: [pygccxml-development] Printing declarations...

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

Roman Yakovenko wrote:
> On 3/22/06, Matthias Baas <ba...@ir...> wrote:
>> That's what I meant in a previous mail when I said I'm in favor of
>> waiting with moving the high level API to the official code until it's
>> more or less stable and all areas have been addressed.
> 
> I don't agree with you on this point. I think that you and Allen did
> such great job,
> really. You designed completely new interface to pyplusplus. I think
> that select api is
> stable. It is not going to be changed, only in a few places we will
> add a functionality
> users missing/need. Don't you agree with me? Please, take a look on py_date_time
> example. You will see the whole power of select interface :-).

I noticed that the selection works differently in your version compared 
to the experimental version. I would have only called it "stable" when 
the interface in both versions would have been identical as in this 
case, it would have shown that we all agree on one common scheme. 
Obviously this is not yet the case.

I just tried to write a driver script for the Maya module that only uses 
  the "official" module_builder_t class. I thought I could mainly use my 
existing script and only inject aliases for the method names in 
module_builder and decl_wrapper. But it's not only the naming convention 
but also the interface itself that differs. So switching entirely to 
your version would take quite a bit of time and even with my current 
partial script I've noticed things that could be improved in my opinion. 
But at least it provides a basis for further discussion (as I just see 
it as another proposal for an API) and hopefully we can objectively 
balance the pros and cons of each version once they're in a state that 
the respective supporters are happy with. :)

> Although your implementation is so different from my.
> I fill a little bit uncomfortable with this.

Yes, we seem to have different ways of thinking and programming... ;-)
But anyway, the focus is still on the *interface*, isn't it? This means, 
the actual implementation of a prototype interface is not important at 
all (as long as it works and can be used to test the interface).

For a final implementation (once the interface is stable!), we should 
find better algorithms anyway. For example, querying for declarations 
could be a lot faster (now that the parsing time is no issue anymore, 
querying for declarations has become the new bottleneck for me). 
Currently, we use a rather naive approach of iterating through all 
declarations and applying a filter function which is O(n) for a single 
query. It would be great if a final version could reduce this complexity 
to O(log(n)) or even O(1) by doing some preprocessing. By the way, such 
a thing might also have an effect on the interface itself. If you base 
selections solely on user-provided functions then there's little you can 
do to get any better than O(n). But if you provide a set of predefined 
filter functions then we know in advance how this filters work and can 
exploit that knowledge to speed up the queries.

> P.S.2 Can you start writing some introduction/tutorial for high level API?

I'll see that I gradually update the documentation of the experimental 
module. You can then take the parts that are identical and use them for 
your version as well. But I'm afraid I'm not yet able to write a 
tutorial for your version as I'm not entirely familiar with the way it's 
supposed to work and I even think that a couple of things need improvement.

- Matthias -