pygccxml-development

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

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

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 have to give some lecture about Python next week, after this I think we w=
ill
release "technology preview" version.

There is only one point that open - how to treat overloaded function.
( By the way,
I hope I will implement tomorrow solution that will satisfy you ).

You are adding great functionality ( =3D=3D logging ) to filters/matchers.
Why not to
add it to the main source code?

> Currently, the
> API is usable and can produce code, but I'm still not entirely satisfied
> with the results and still like to improve my module. And there are
> still quite a few things that could be added to the API...

I think that you have great ideas and you can implement them directly on
main source code. There are some ideas, that we don't agree or I need some =
time
to understand you. Those ideas should be implemented on experimental branch=
.

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

Can you try module_builder_t class on your project? I think you will
like the result.
decl_wrappers are still missing some functionality ( cdef ), but I
don't think this will
be a problem.

What do you think?

> - Matthias -

P.S.1. Until end of the next week I will be busy, very busy. I will
try to response as
quick as I can.

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

Thanks

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

Re: [pygccxml-development] Default values for pointers?

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

Hi, Matthias, I think that this is your chance to try to understand
code creators.
This is really simple problem, after David Abrahams provided solution.

You need to take a look on code_creators/calldef.py file.

Good luck!

P.S.  I understand, that may be you don't have time for this task, so
I attach a file
with solution. You can replace your file with this one. I tested it.
Please place it in pyplusplus/code_creators directory. If you want,
you can commit it.
( I don't have time to learn command line args of cvs ).  Otherwise I
will commit it
and tester tomorrow.

thanks

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

[pygccxml-development] Re: [Fwd: Re: Providing a default value for a pointer argument]

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

Roman Yakovenko wrote:
>> you might have seen that mail from the c++-sig already yourself. Can
>> this be added to pyplusplus? (that is, whenever the default value for a
>> pointer is 0, it is replaced by object())
> 
> Yes, I will do it. 

Great!

> By the way why arg("...") ? Or should I replace
> "..." with actual name of argument?

Yes, of course. I was just using the "..." because I hadn't introduced 
any variable at this point in my mail, the emphasis has been on "=0". :)

- Matthias -

[pygccxml-development] Re: [Fwd: Re: Providing a default value for a pointer argument]

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

On 3/22/06, Matthias Baas <ba...@ir...> wrote:
> Hi Roman,
>
> you might have seen that mail from the c++-sig already yourself. Can
> this be added to pyplusplus? (that is, whenever the default value for a
> pointer is 0, it is replaced by object())
>
> - Matthias -

Yes, I will do it. By the way why arg("...") ? Or should I replace
"..." with actual
name of argument?


> -------- Original Message --------
> Subject: Re: Providing a default value for a pointer argument
> Date: Wed, 22 Mar 2006 07:16:46 -0800
> From: David Abrahams <da...@bo...>
> Reply-To: Development of Python/C++ integration <c+...@py...>
> Newsgroups: gmane.comp.python.c++
> References: <dvrjiv$d6j$1...@se...>
>
> Matthias Baas <ba...@ir...> writes:
>
> > Hi,
> >
> > I have a question about the "arg" class which can be used to provide
> > names for keyword arguments and their default values. Should this
> > default value also be taken into account for arguments that are actuall=
y
> > pointers?
> > I have a function that takes a pointer as input whose default value in =
C
> > is 0. When I wrap that function I provide the default value as
> > arg("...")=3D0.
>
> Try
>
>     arg("...") =3D object()
>
> object() produces a None, and None is the canonical object that's
> convertible to NULL pointers.
>


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

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

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

Roman Yakovenko wrote:
> Can you switch to new API ( == module builder ) and improve/add/update it?
> I think that now pyplusplus has all functionality you need. What do you think?
> What is the stopper?

Well, I'm hesitating because I would still like to be able to experiment 
with the API. If I give up that extra layer between the "official" 
pyplusplus code and my driver script then I cannot do quick changes to 
the API anymore. In the experimental folder I can mess around without 
being afraid of breaking something in the official code.

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. Currently, the 
API is usable and can produce code, but I'm still not entirely satisfied 
with the results and still like to improve my module. And there are 
still quite a few things that could be added to the API...

- Matthias -

Re: [pygccxml-development] Default values for pointers?

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

On 3/22/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> this is probably a general Boost.Python question but anyway...
>
> I have a couple of classes that have methods like the following:
>
>    bool isDone(MStatus* ReturnStatus=3DNULL) const;
>
> The MStatus object is just used for error reporting. When the user
> passes a MStatus object it will be filled with data specifying whether
> an error has occurred or not, but the user can also decide not to pass
> anything if he isn't interested in the error code.
> pyplusplus generates the following code:
>
>          MItDag_exposer.def( "isDone"
>                  , &MItDag::isDone
>                  , ( bp::arg("ReturnStatus")=3D0 )
>                  , bp::default_call_policies() );
>
> The module compiles fine, I can use it, but why isn't the argument not
> optional anymore? When I try to invoke the method without arguments I
> get an error by Boost.Python:
>
> Boost.Python.ArgumentError: Python argument types in
>      MItDag.isDone(MItDag)
> did not match C++ signature:
>      isDone(class MItDag {lvalue}, class MStatus * ReturnStatus=3D0)
>
>
> Shouldn't the argument be optional as there is the "=3D0" in
> bp::arg("ReturnStatus")=3D0? Or should pyplusplus generate some other cod=
e?

1. I don't know
2. I will take a look what Pyste does
3. Can you try Google
4. boost.python - we always can ask for help there

> - Matthias -

Roman

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

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

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

On 3/22/06, Matthias Baas <ba...@ir...> wrote:
> I added some notes to the doc string of the decl_printer and the default
> __str__ method in declaration_t.

Thanks

> >>> 4. How you configure the a amount of printed information.
> >> It's ok to be able to configure decl_printer_t, but in my opinion
> >> __str__ doesn't need to be configured.
> >
> > Right
> >
> > Thanks. I understand what you want/need. I think that this is a good
> > functionality.
> > Can you add it to pygccxml.declarations class hierarchy? I will add som=
e test
> > code for it.
>
> I've just committed the changes. I hope I didn't miss any declaration.

I just run 113 pygccxml test cases. All works as expected

> With those changes my query log file has become much more readable. For
> example, a line like the following in my pyplusplus script:
>
> mod.Methods("operator()", retval=3D["float &", "double &"]).exclude()
>
> will produce the following snippet in the log file:
>
> ----------------------------------------------------------------------
> pypp_setup.py, 417: mod.Methods("operator()", retval=3D["float &", "doubl=
e
> &"]).exclude()
> Filter: (name=3D=3D'operator()') & ((retval=3D=3Dfloat &) | (retval=3D=3D=
double &))
> & (type=3D=3DMETHOD|FUNCTION|CONSTRUCTOR) & (anyparent=3D=3D'::')
>   -> float & MFloatPoint::operator()(unsigned int i) [member_operator]
>   -> float & MFloatMatrix::operator()(unsigned int row, unsigned int
> col) [member_operator]
>   -> float & MFloatVector::operator()(unsigned int i) [member_operator]
>   -> float & MColor::operator()(unsigned int i) [member_operator]
>   -> double & MMatrix::operator()(unsigned int row, unsigned int col)
> [member_operator]
>   -> double & MVector::operator()(unsigned int i) [member_operator]
>   -> double & MPoint::operator()(unsigned int i) [member_operator]
>   (7 declarations)
> ----------------------------------------------------------------------

> Here the user can exactly see how pyplusplus has interpreted a
> particular query. The first line is a reference to the user's source
> script. The second line is the generated filter expression and the
> remaining lines show the result of the query.

I am envy you a little :-). Do you want to port that code to matchers?

> I'm still planning on adding another similar log file that is not based
> on queries but on decoration operations. Each such operation will then
> output a line for each declaration it was applied to. Then you can just
> grep for a particular declaration to obtain a "history" on what has
> happened to that declaration.

Can you switch to new API ( =3D=3D module builder ) and improve/add/update =
it?
I think that now pyplusplus has all functionality you need. What do you thi=
nk?
What is the stopper?

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

[pygccxml-development] Default values for pointers?

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

Hi,

this is probably a general Boost.Python question but anyway...

I have a couple of classes that have methods like the following:

   bool isDone(MStatus* ReturnStatus=NULL) const;

The MStatus object is just used for error reporting. When the user 
passes a MStatus object it will be filled with data specifying whether 
an error has occurred or not, but the user can also decide not to pass 
anything if he isn't interested in the error code.
pyplusplus generates the following code:

         MItDag_exposer.def( "isDone"
                 , &MItDag::isDone
                 , ( bp::arg("ReturnStatus")=0 )
                 , bp::default_call_policies() );

The module compiles fine, I can use it, but why isn't the argument not 
optional anymore? When I try to invoke the method without arguments I 
get an error by Boost.Python:

Boost.Python.ArgumentError: Python argument types in
     MItDag.isDone(MItDag)
did not match C++ signature:
     isDone(class MItDag {lvalue}, class MStatus * ReturnStatus=0)


Shouldn't the argument be optional as there is the "=0" in 
bp::arg("ReturnStatus")=0? Or should pyplusplus generate some other code?


- Matthias -

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

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

Roman Yakovenko wrote:
>>> 3. is decl_printer_t should be implemented in terms of __str__ method, or may be
>>>    __str__ method should be implemented in terms of decl_printer_t
>> I think they serve different purposes. __str__ should yield a short but
>> unique human-readable representation of the object (like an id so that
>> the user knows where to find this declaration in his source code)
>> whereas decl_printer_t can be used to inspect an entire declaration
>> tree. The decl_printer can be used by a new user to find out how
>> pyplusplus works and how it stores its data.
> 
> Clear. Can you put this paragraph somewhere in documentation?

I added some notes to the doc string of the decl_printer and the default 
__str__ method in declaration_t.

>>> 4. How you configure the a amount of printed information.
>> It's ok to be able to configure decl_printer_t, but in my opinion
>> __str__ doesn't need to be configured.
> 
> Right
> 
> Thanks. I understand what you want/need. I think that this is a good
> functionality.
> Can you add it to pygccxml.declarations class hierarchy? I will add some test
> code for it.

I've just committed the changes. I hope I didn't miss any declaration.

With those changes my query log file has become much more readable. For 
example, a line like the following in my pyplusplus script:

mod.Methods("operator()", retval=["float &", "double &"]).exclude()

will produce the following snippet in the log file:

----------------------------------------------------------------------
pypp_setup.py, 417: mod.Methods("operator()", retval=["float &", "double 
&"]).exclude()
Filter: (name=='operator()') & ((retval==float &) | (retval==double &)) 
& (type==METHOD|FUNCTION|CONSTRUCTOR) & (anyparent=='::')
  -> float & MFloatPoint::operator()(unsigned int i) [member_operator]
  -> float & MFloatMatrix::operator()(unsigned int row, unsigned int 
col) [member_operator]
  -> float & MFloatVector::operator()(unsigned int i) [member_operator]
  -> float & MColor::operator()(unsigned int i) [member_operator]
  -> double & MMatrix::operator()(unsigned int row, unsigned int col) 
[member_operator]
  -> double & MVector::operator()(unsigned int i) [member_operator]
  -> double & MPoint::operator()(unsigned int i) [member_operator]
  (7 declarations)
----------------------------------------------------------------------

Here the user can exactly see how pyplusplus has interpreted a 
particular query. The first line is a reference to the user's source 
script. The second line is the generated filter expression and the 
remaining lines show the result of the query.

I'm still planning on adding another similar log file that is not based 
on queries but on decoration operations. Each such operation will then 
output a line for each declaration it was applied to. Then you can just 
grep for a particular declaration to obtain a "history" on what has 
happened to that declaration.

- Matthias -

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

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

On 3/21/06, Matthias Baas <ba...@ir...> wrote:
> > Before you do it, please ask your self next questions:
> > 1. What is the difference between output of decl_printer_t?
>
> decl_printer_t is a more advanced way to output a declaration (or an
> entire tree) whereas I'd expect the __str__ method to return a concise
> version of the declaration (preferably in one line) so that it can be
> uniquely identified by the user.
>
> For example, I have a method that the decl_printer_t outputs like this:
>
> member_function_t: 'selectByName'
>      Signature: [u'::MStatus', [u'::MString const &',
> u'::MGlobal::ListAdjustment']]
>
> The __str__ method could instead return something like:
>
> MStatus MGlobal::selectByName(MString const &, MGlobal::ListAdjustment)
> [member_function]

Okay

> That is, it is almost C++ source code.
> The advantage of having only one line is that you can use 'grep' to find
>   a particular declaration in a log file.
>
> By the way, in the case of a class, I don't expect the entire class to
> be printed (including members) but only the class name.
> If I really want to inspect the contents of the class I can still use
> the decl_printer.

Okay

> > 2. Why we need 2 implementation of __str__ methods
>
> I don't understand. So far, there is no __str__ method. When I print a
> declaration I get something like:
>
> <pyplusplus.decl_wrappers.calldef_wrapper.member_function_t object at
> 0xb75b826c>

I meant why we need decl_printer_t and __str__. In answer to first question
you explained this.

> > 3. is decl_printer_t should be implemented in terms of __str__ method, =
or may be
> >    __str__ method should be implemented in terms of decl_printer_t
>
> I think they serve different purposes. __str__ should yield a short but
> unique human-readable representation of the object (like an id so that
> the user knows where to find this declaration in his source code)
> whereas decl_printer_t can be used to inspect an entire declaration
> tree. The decl_printer can be used by a new user to find out how
> pyplusplus works and how it stores its data.

Clear. Can you put this paragraph somewhere in documentation?

> > 4. How you configure the a amount of printed information.
>
> It's ok to be able to configure decl_printer_t, but in my opinion
> __str__ doesn't need to be configured.

Right

Thanks. I understand what you want/need. I think that this is a good
functionality.
Can you add it to pygccxml.declarations class hierarchy? I will add some te=
st
code for it.

Thanks.

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

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

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

Roman Yakovenko wrote:
>>>> Almost, the signature is there but the actual method name is missing.
>>> Okay, I give up :-). I understand what you want, but I don't
>>> understand the format.
>> The more it resembles the original source code the better. I'm dumping
>> the declarations into a log file that the user can inspect. For example,
>> he could just grep for a particular function name to find out what
>> decorations have been applied to that function.
> 
>>> Also, why do you need this from framework. You have all tools to
>>> create almost any format by your own?
>> Well, yes, but it seems that recreating the source code doesn't look
>> that easy to me (and I don't know how much of the original source code
>> (which could be reused here) has survived in the output from gccxml).
>> When I have some time left I can have a look at it. Would you like the
>> idea to add __str__() methods to the declaration_t classes? (then a user
>> could just print a declaration and see exactly what it is)
> 
> Before you do it, please ask your self next questions:
> 1. What is the difference between output of decl_printer_t?

decl_printer_t is a more advanced way to output a declaration (or an 
entire tree) whereas I'd expect the __str__ method to return a concise 
version of the declaration (preferably in one line) so that it can be 
uniquely identified by the user.

For example, I have a method that the decl_printer_t outputs like this:

member_function_t: 'selectByName'
     Signature: [u'::MStatus', [u'::MString const &', 
u'::MGlobal::ListAdjustment']]

The __str__ method could instead return something like:

MStatus MGlobal::selectByName(MString const &, MGlobal::ListAdjustment) 
[member_function]

That is, it is almost C++ source code.
The advantage of having only one line is that you can use 'grep' to find 
  a particular declaration in a log file.

By the way, in the case of a class, I don't expect the entire class to 
be printed (including members) but only the class name.
If I really want to inspect the contents of the class I can still use 
the decl_printer.

> 2. Why we need 2 implementation of __str__ methods

I don't understand. So far, there is no __str__ method. When I print a 
declaration I get something like:

<pyplusplus.decl_wrappers.calldef_wrapper.member_function_t object at 
0xb75b826c>

> 3. is decl_printer_t should be implemented in terms of __str__ method, or may be
>    __str__ method should be implemented in terms of decl_printer_t

I think they serve different purposes. __str__ should yield a short but 
unique human-readable representation of the object (like an id so that 
the user knows where to find this declaration in his source code) 
whereas decl_printer_t can be used to inspect an entire declaration 
tree. The decl_printer can be used by a new user to find out how 
pyplusplus works and how it stores its data.

> 4. How you configure the a amount of printed information.

It's ok to be able to configure decl_printer_t, but in my opinion 
__str__ doesn't need to be configured.


- Matthias -

Re: [pygccxml-development] Terminology - help needed

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

Roman Yakovenko wrote:
> property has_wrapper
>     property, that indicates whether pyplusplus should create wrapper or not.
>     For example virtual function has_wrapper, but user can set it to false, to
>     disable generation of it
> 
> def enable_wrapper
> def disable_wrapper
>     sets has_wrapper to true/false
> 
> def requires_wrapper
>     returns true if the only way to expose declaration is to create
> some wrapper for it.
>     For example pure virtual function, protected function or function
> that takes as argument
>     non const reference to fundamental type.
> 
> relevant functionality of decl_wrappers.class_t is implemented in
> terms of child declarations.
> 
> Is it clear description of what is going on?

So far it looks clear to me (but I didn't need wrappers for the Maya SDK 
yet (there are only a few classes that are actually meant to be derived 
from by the user), so it may well be that I overlook some issues...).

- Matthias -

Re: [pygccxml-development] Status:

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

Roman Yakovenko wrote:
>>> 2. resolving function overload issues
>>>
>>> Matthias, I would like to see your solution before I make any decision. Thanks.
>> So far, I would simply suggest that a set of overloaded functions is
>> actually treated like one single function.
> 
> Can you explain me? Or can you write small code that show how woould
> you like to use that feature?

For example, if I write

rotateBy = mb.class_("MVector").member_function("rotateBy")

and rotateBy is actually implemented as a set of overloaded methods (as 
it is the case in the Maya SDK), then this call could be made so that it 
does not create an error even though the result references more than one 
declaration (note that I was using "member_function" and not 
"member_functions").
Then I could just treat these collection of overloaded functions as if 
it was only one single function:

rotateBy.include()          # includes all overloaded functions
rotateBy.rename("rotate")   # renames all overloaded functions


- Matthias -

Re: [pygccxml-development] Terminology - help needed

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

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

Thanks a lot. :-)

property has_wrapper
    property, that indicates whether pyplusplus should create wrapper or no=
t.
    For example virtual function has_wrapper, but user can set it to false,=
 to
    disable generation of it

def enable_wrapper
def disable_wrapper
    sets has_wrapper to true/false

def requires_wrapper
    returns true if the only way to expose declaration is to create
some wrapper for it.
    For example pure virtual function, protected function or function
that takes as argument
    non const reference to fundamental type.

relevant functionality of decl_wrappers.class_t is implemented in
terms of child declarations.

Is it clear description of what is going on?

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

Re: [pygccxml-development] Terminology - help needed

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

Roman Yakovenko wrote:
> Please give a name to the next functionality:

How about:

> does declaration have wrapper?

bool = has_wrapper()

> should declaration have wrapper?

create_wrapper(bool=True)
enable_wrapper(bool=True)

or do you mean:

bool = requires_wrapper()

> do not create wrapper.

create_wrapper(False)
enable_wrapper(False)
disable_wrapper(bool=True)

> Also for example in order to expose protected member function pyplusplus
> creates wrapper, in this case user can just set ignore  flag to true and it will
> not be exposed. Do you think I should call helper function as "wrapper" too?

At least, this sounds reasonable to me.

> Constructors also have wrappers, but the only reason for their
> existence is that I should create them correctly if I want to wrap
> some another function. Should I call those constructor in wrapper
> class  "wrappers" too?

As they are the constructors of a wrapper class I think it makes sense 
to call them "wrappers", too.

- Matthias -

Re: [pygccxml-development] High level API

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

On 3/20/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > And you was right here. The only mistake is that I did is that
> > "Errors should never pass silently". We need to raise an error, when
> > user tries to
> > do it, or at least to print some warning to him.
>
> I agree (I added this behavior to the experimental module).

Good. I will take a look on it and move relevant code to the main branch.
Thanks

> - Matthias -


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

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

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

On 3/20/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> >>    typedef double (::MVector::*bracket_op)(unsigned int i) const;
> >>
> >> and then rewrite the above as
> >>
> >>          MVector_exposer.def( "__call__"
> >>                  , (bracket_op)(&MVector::operator())
> >>                  , ( bp::arg("i") )
> >>                  , bp::default_call_policies() );
> >>
> >> then it compiles fine. Could this scheme be incorporated in pyplusplus=
?
> >
> > Yes. I need it also for template functions too. Do you think we need to
> > implement this before release or after?
>
> Whenever you have some time you can spend on it. In the above case, the
> call operator is not that important, so I can wait.

I took a look and it seems, that I need 3 - 4 hours to fix the
problem, may be less.
So, I will wait with this a little.

> > Also, untill I add this code to pyplusplus and you don't have an other
> > operator ()
> > on MVector you can set create_with_signature to false.
>
> I didn't notice a difference in the generated code....?

I think this is because you have an other overload, right?

> >> Almost, the signature is there but the actual method name is missing.
> >
> > Okay, I give up :-). I understand what you want, but I don't
> > understand the format.
>
> The more it resembles the original source code the better. I'm dumping
> the declarations into a log file that the user can inspect. For example,
> he could just grep for a particular function name to find out what
> decorations have been applied to that function.



> > Also, why do you need this from framework. You have all tools to
> > create almost any format by your own?
>
> Well, yes, but it seems that recreating the source code doesn't look
> that easy to me (and I don't know how much of the original source code
> (which could be reused here) has survived in the output from gccxml).
> When I have some time left I can have a look at it. Would you like the
> idea to add __str__() methods to the declaration_t classes? (then a user
> could just print a declaration and see exactly what it is)

Before you do it, please ask your self next questions:
1. What is the difference between output of decl_printer_t?
2. Why we need 2 implementation of __str__ methods
3. is decl_printer_t should be implemented in terms of __str__ method, or m=
ay be
   __str__ method should be implemented in terms of decl_printer_t
4. How you configure the a amount of printed information.

I would like to see the answers to those question, after this, I think
we will have
better understanding of what you are actually want. I think we do add
__str__ method
to declarations, but I need to know the rule.

Thanks

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

Re: [pygccxml-development] High level API

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

Roman Yakovenko wrote:
> And you was right here. The only mistake is that I did is that
> "Errors should never pass silently". We need to raise an error, when
> user tries to
> do it, or at least to print some warning to him.

I agree (I added this behavior to the experimental module).

- Matthias -

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

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

Roman Yakovenko wrote:
>>    typedef double (::MVector::*bracket_op)(unsigned int i) const;
>>
>> and then rewrite the above as
>>
>>          MVector_exposer.def( "__call__"
>>                  , (bracket_op)(&MVector::operator())
>>                  , ( bp::arg("i") )
>>                  , bp::default_call_policies() );
>>
>> then it compiles fine. Could this scheme be incorporated in pyplusplus?
> 
> Yes. I need it also for template functions too. Do you think we need to
> implement this before release or after?

Whenever you have some time you can spend on it. In the above case, the 
call operator is not that important, so I can wait.

> Also, untill I add this code to pyplusplus and you don't have an other
> operator ()
> on MVector you can set create_with_signature to false.

I didn't notice a difference in the generated code....?

>> Almost, the signature is there but the actual method name is missing.
> 
> Okay, I give up :-). I understand what you want, but I don't
> understand the format.

The more it resembles the original source code the better. I'm dumping 
the declarations into a log file that the user can inspect. For example, 
he could just grep for a particular function name to find out what 
decorations have been applied to that function.

> Also, why do you need this from framework. You have all tools to
> create almost any format by your own?

Well, yes, but it seems that recreating the source code doesn't look 
that easy to me (and I don't know how much of the original source code 
(which could be reused here) has survived in the output from gccxml).
When I have some time left I can have a look at it. Would you like the 
idea to add __str__() methods to the declaration_t classes? (then a user 
could just print a declaration and see exactly what it is)

- Matthias -

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

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

On 3/19/06, Roman Yakovenko <rom...@gm...> wrote:
> On 3/19/06, Matthias Baas <ba...@ir...> wrote:
> > Roman Yakovenko wrote:
> > >> Should the fix for the copy constructor also be available yet? (they=
 are
> > >> still not wrapped automatically)
> > >
> > > I am doing something wrong with constructors. I do not know what :-(.
> >
> > What's wrong with the other constructors? For me, it's only the copy
> > constructor that doesn't get wrapped, all other constructors have been
> > fine so far.
>
> I don't know exactly. I have take into account constructor for
> wrapper, artificial
> constructors, private and protected and  ... .
>
> > Ahem, I forgot that I was explicitly ignoring it.....
> > The actual problem is that the generated code won't compile on Windows
> > (using VC7.1). pyplusplus generates the following code:
> >
> >          MVector_exposer.def( "__call__"
> >                  , (double ( ::MVector::* )( unsigned int )
> > const)(&MVector::operator())
> >                  , ( bp::arg("i") )
> >                  , bp::default_call_policies() );
> >
> > When I try to compile this I get a syntax error because of the
> > "operator()" (VC7.1 gets confused by the brackets). Whereas when I
> > create the following typedef
> >
> >    typedef double (::MVector::*bracket_op)(unsigned int i) const;
> >
> > and then rewrite the above as
> >
> >          MVector_exposer.def( "__call__"
> >                  , (bracket_op)(&MVector::operator())
> >                  , ( bp::arg("i") )
> >                  , bp::default_call_policies() );
> >
> > then it compiles fine. Could this scheme be incorporated in pyplusplus?

Also, untill I add this code to pyplusplus and you don't have an other
operator ()
on MVector you can set create_with_signature to false.

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

Re: [pygccxml-development] Status:

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

On 3/19/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > 2. resolving function overload issues
> >
> > Matthias, I would like to see your solution before I make any decision.=
 Thanks.
>
> So far, I would simply suggest that a set of overloaded functions is
> actually treated like one single function.

Can you explain me? Or can you write small code that show how woould
you like to use that
feature?

Thanks

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

[pygccxml-development] Terminology - help needed

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

Hi. I am working on final functionality
( Similar to Pyste one :
http://www.boost.org/libs/python/pyste/doc/renaming_and_excluding.html )

I have small/big problem. I can not create good names for functions/propert=
ies.

Please give a name to the next functionality:

does declaration have wrapper?
should declaration have wrapper?
do not create wrapper.

Also for example in order to expose protected member function pyplusplus
creates wrapper, in this case user can just set ignore  flag to true and it=
 will
not be exposed. Do you think I should call helper function as "wrapper" too=
?

Pure virtual function must have wrappers, so I want to indicate to user tha=
t
he can not remove/finalize the function and wrapper.

Constructors also have wrappers, but the only reason for their
existence is that I should create them correctly if I want to wrap
some another function. Should I call those constructor in wrapper
class  "wrappers" too?

I hope you understand my confusion. If you have some idea, any idea
you welcome to share.

If we will not find good terminology, I think I will not implement
this functionality.
In general it is very easy to implement it, but I can not find good names :=
-(

Thanks for help.

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

Re: [pygccxml-development] High level API

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

On 3/19/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > There are some customization that user can do on declarations, even
> > after code creators tree creation.
>
> So far, I was considering it more or less an error if the user modifies
> the declaration tree after the code creator tree has been created

And you was right here. The only mistake is that I did is that
"Errors should never pass silently". We need to raise an error, when
user tries to
do it, or at least to print some warning to him.

>
> > But there are set of customizations that will not have
> > effect on code creators.
> > For example ignore.
>
> I don't understand that. Ignoring a declaration has the effect that the
> corresponding code creator is not created, so it does have an effect on
> the code creators, doesn't it?

If code creators tree already created then setting ignore flag to
true, will not have
effect. And this is exactly the problem I spent more then 3 hours to find.
It drive me crazy. So I prefer to fix it in a such way, that user at least
will be aware to this.

What can you recommend?

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

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

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

On 3/19/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> >> Should the fix for the copy constructor also be available yet? (they a=
re
> >> still not wrapped automatically)
> >
> > I am doing something wrong with constructors. I do not know what :-(.
>
> What's wrong with the other constructors? For me, it's only the copy
> constructor that doesn't get wrapped, all other constructors have been
> fine so far.

I don't know exactly. I have take into account constructor for
wrapper, artificial
constructors, private and protected and  ... .

> Ahem, I forgot that I was explicitly ignoring it.....
> The actual problem is that the generated code won't compile on Windows
> (using VC7.1). pyplusplus generates the following code:
>
>          MVector_exposer.def( "__call__"
>                  , (double ( ::MVector::* )( unsigned int )
> const)(&MVector::operator())
>                  , ( bp::arg("i") )
>                  , bp::default_call_policies() );
>
> When I try to compile this I get a syntax error because of the
> "operator()" (VC7.1 gets confused by the brackets). Whereas when I
> create the following typedef
>
>    typedef double (::MVector::*bracket_op)(unsigned int i) const;
>
> and then rewrite the above as
>
>          MVector_exposer.def( "__call__"
>                  , (bracket_op)(&MVector::operator())
>                  , ( bp::arg("i") )
>                  , bp::default_call_policies() );
>
> then it compiles fine. Could this scheme be incorporated in pyplusplus?

Yes. I need it also for template functions too. Do you think we need to
implement this before release or after?

> Almost, the signature is there but the actual method name is missing.

Okay, I give up :-). I understand what you want, but I don't
understand the format.
Also, why do you need this from framework. You have all tools to
create almost any
format by your own?

> - Matthias -

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

Re: [pygccxml-development] Status:

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

Roman Yakovenko wrote:
> 2. resolving function overload issues
> 
> Matthias, I would like to see your solution before I make any decision. Thanks.

So far, I would simply suggest that a set of overloaded functions is 
actually treated like one single function.

- Matthias -