pygccxml-development

Re: [pygccxml-development] Order of enum values

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

On 7/6/06, Matthias Baas <ba...@ir...> wrote:
> - A comment in the source code says that the value part is stored as an
> int but obviously it's a unicode string containing an int. Is this a
> bug?

Yes, It could be fixed in scanner_t class.

> Could the value actually also be something else than an int?

I am not sure. May be it possible to create an enum, with some expression as
value. And may be in this case gccxml will dump it as a string. I don't know.
So, small investigation is needed. If it could be expression, then
'int' in comment
should be replaced to 'string'

> - Are those integer values ever used?

They don't.

> The generated code looks like this:
>
>          bp::enum_<MColor::MColorType>("MColorType")
>              .value("kCMY", MColor::kCMY)
>              .value("kHSV", MColor::kHSV)
>              .value("kRGB", MColor::kRGB)
>              .value("kCMYK", MColor::kCMYK)
>              .export_values()
>              ;
>
> Now what I'd like to have is a scheme that always produces the same
> order. There are several options how this could be implemented:

Me too.

> - Store the values inside a list instead of a dict. The items can be
> either just the enum names or tuples (name, value) if the value is still
> required somewhen.

You loose a convenience of dictionary: value = x[name].

> - The code creator could sort the enum names according to their value
> and then use this order to write them out.
>
>
> To me the first option seems to be the right one as an enum actually
> *is* an ordered construct.

If gccxml reports enums, using the order from source file, you can
replace dict with
a list, otherwise any order you define will surprise a user.

> But I don't know the entire pyplusplus code,
> so maybe there are cases where a value has to be looked up quickly which
> justifies using a dict.

There is no such place.

> So, Roman, which approach would you prefer? (I might have a go at fixing
> it myself then)

I prefer to make a change in pygccxml, but I am not sure, that it will
be enough.
Please take a look on decl_wrappers.enumeration_t. It also defines few
containers,
may be you will have to change those containers too. Please take a look also
on code_creators.enum_t and code_creators.unnamed_enum_t. They generate
the code, I think you will have to fix them too :-(.

Please, implement what ever you think is right and I try to help you as much
as I can.

Thanks

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

[pygccxml-development] Order of enum values

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

Hi,

as I still have the problem that the order of enum values changes 
between two identical runs of pyplusplus (when the cache is used) I had 
a closer look at why this is the case. The problem is that the values of 
an enum are stored inside a dict and the order of those values may 
change when the dict is pickled and unpickled (usually this is ok as 
there is no order defined on the values of a dict).

Now I'm not sure what the best way to fix this is. The values in 
enumeration_t are stored as a dict: name(str) -> value(int). For 
example, the enum

   enum MColorType { kRGB, kHSV, kCMY, kCMYK };

is stored as the following dict (in an arbitrary order):

   {u'kCMY': u'2', u'kHSV': u'1', u'kRGB': u'0', u'kCMYK': u'3'}

Now I have several questions:

- A comment in the source code says that the value part is stored as an 
int but obviously it's a unicode string containing an int. Is this a 
bug? Could the value actually also be something else than an int?

- Are those integer values ever used? The generated code looks like this:

         bp::enum_<MColor::MColorType>("MColorType")
             .value("kCMY", MColor::kCMY)
             .value("kHSV", MColor::kHSV)
             .value("kRGB", MColor::kRGB)
             .value("kCMYK", MColor::kCMYK)
             .export_values()
             ;

Now what I'd like to have is a scheme that always produces the same 
order. There are several options how this could be implemented:

- Store the values inside a list instead of a dict. The items can be 
either just the enum names or tuples (name, value) if the value is still 
required somewhen.

- The code creator could sort the enum names according to their value 
and then use this order to write them out.


To me the first option seems to be the right one as an enum actually 
*is* an ordered construct. But I don't know the entire pyplusplus code, 
so maybe there are cases where a value has to be looked up quickly which 
justifies using a dict.
So, Roman, which approach would you prefer? (I might have a go at fixing 
it myself then)

- Matthias -

Re: [pygccxml-development] Method taking function pointer not showing up in the generated code

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

Roman Yakovenko wrote:
> Do you mind to review and correct py++ messages?

How should messages be handled internally? There are the loggers but 
where do the messages for the source files come from (and go)? (also see 
the other thread)

- Matthias -

Re: [pygccxml-development] improving user experience

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

Roman Yakovenko wrote:
> 1. Every declaration that user asked to export will be exported. Those
> declarations
>    that could not be exported will be commented out and description of the
>    problem will be provided. Thus when developer will get question from a user:
>    why you did not exported declaration "X", developer will be able to go to
>    generated file and to read an explanation.

Good idea! In my case this would have answered my question before I was 
even posing it (as the first thing I did was to have a look in the 
generated source file to check if the method is there).

> 2. The monolithic loggers were a mistake. Both pygccxml and py++ will have
>     loggers hierarchy:
>     pygccxml logger as root + gccxml logger, performance or query logger
>     pyplusplus will also has additional loggers.
> 
>     Thus developer will have better control on information, he wants to get from
>     py++.

Agreed! Now the question is how many loggers are needed, what is their 
name, where can we get away with separate log levels instead of separate 
loggers, etc.?

- Matthias -

Re: [pygccxml-development] Method taking function pointer not showing up in the generated code

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

On 7/5/06, Matthias Baas <ba...@ir...> wrote:
> ok, I could add a loop at the end of my script that iterates over all
> declarations and checks if readme() returns anything else than an empty
> list and then report those messages.... which is not really ideal.

I agree with you!

> > The problem is that, I still looking for a good way to give this
> > information to the user.

I just posted the idea, how to solve this problem in another thread :-)

>1) it will teach new users how Boost.Python and
> pyplusplus work and what they do about particular C++ constructs

This is one of the goals of py++ and this is why it has small and simple GUI!
New comers to boost can use it as a guide to boost.python library.

> and 2)
> a user can look up why something didn't turn out to be as he had expected.

I learned, that "surprise" is the last thing that users want, when they use code
generator, so writing the information into source file is a good idea.

> Whenever the result of running pyplusplus is not as expected, the user
> has questions about it. In my case, the question was "Why didn't
> addEventCallback() show up in the generated code?". Now we have to find
> a way how questions like this can be answered quickly by pyplusplus
> itself. There are certainly more types of questions a user can have, but
> I think most of them will all have in common that they refer to one
> particular (or a group of) declarations that are usually given by name.
> So given the name of a declaration it should be possible to quickly
> determine all "interesting" things that pyplusplus has to say about that
> declaration. One straightforward possibility would be using 'grep' on a
> log file that contains the full declaration string and a corresponding
> message. Each such message should be entirely contained within one line
> (otherwise it would be awkward to use grep) and there might be more such
> lines in the log file. This is already how I can filter out the
> decorations that have been applied to a particular declaration by using
> the log file that's generated in the experimental version. And so far,
> this method has proven to be useful for me.

Do you mind to review and correct py++ messages?
Thanks

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

[pygccxml-development] improving user experience

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

Hi. I think I found the solution to the problem.
The problem is that there is a lot of information, that pyplusplus has
to say to user,
while it generates the code.

The solution I found is pretty simple and consist from few improvements:

1. Every declaration that user asked to export will be exported. Those
declarations
   that could not be exported will be commented out and description of the
   problem will be provided. Thus when developer will get question from a user:
   why you did not exported declaration "X", developer will be able to go to
   generated file and to read an explanation.

2. The monolithic loggers were a mistake. Both pygccxml and py++ will have
    loggers hierarchy:
    pygccxml logger as root + gccxml logger, performance or query logger
    pyplusplus will also has additional loggers.

    Thus developer will have better control on information, he wants to get from
    py++.

Thoughts?



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

Re: [pygccxml-development] Method taking function pointer not showing up in the generated code

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

Roman Yakovenko wrote:
> Please take a look on decl_wrappers.calldef_t._exportable_impl function
> (http://svn.sourceforge.net/viewcvs.cgi/pygccxml/pyplusplus_dev/pyplusplus/decl_wrappers/calldef_wrapper.py?view=markup) 
> 
> It contains code, that checks different conditions, whether function
> exportable or not.
> And if not it returns the reason.
> 
> Using decl_wrapper.decl_wrapper_t.why_not_exportable method, you can 
> find out
> why a declaration could not be exported.
> ( 
> http://svn.sourceforge.net/viewcvs.cgi/pygccxml/pyplusplus_dev/pyplusplus/decl_wrappers/decl_wrapper.py?view=markup 
> 
> )

ok, I could add a loop at the end of my script that iterates over all 
declarations and checks if readme() returns anything else than an empty 
list and then report those messages.... which is not really ideal.

> The problem is that, I still looking for a good way to give this
> information to the user.

In the above example of _exportable_impl() you already have implemented 
a second way of reporting issues which I would prefer. The message about 
the MAX_ARITY thing is not returned but is written to a logger. In my 
opinion, the other messages should also be directed into some logger so 
that they appear in the console or in a file.

In general, pyplusplus should tell the user about every built-in logic 
it has applied to some situation (like the above, for example). Or at 
least the user should have the chance to be informed about them. This 
has the advantage that 1) it will teach new users how Boost.Python and 
pyplusplus work and what they do about particular C++ constructs and 2) 
a user can look up why something didn't turn out to be as he had expected.

Whenever the result of running pyplusplus is not as expected, the user 
has questions about it. In my case, the question was "Why didn't 
addEventCallback() show up in the generated code?". Now we have to find 
a way how questions like this can be answered quickly by pyplusplus 
itself. There are certainly more types of questions a user can have, but 
I think most of them will all have in common that they refer to one 
particular (or a group of) declarations that are usually given by name. 
So given the name of a declaration it should be possible to quickly 
determine all "interesting" things that pyplusplus has to say about that 
declaration. One straightforward possibility would be using 'grep' on a 
log file that contains the full declaration string and a corresponding 
message. Each such message should be entirely contained within one line 
(otherwise it would be awkward to use grep) and there might be more such 
lines in the log file. This is already how I can filter out the 
decorations that have been applied to a particular declaration by using 
the log file that's generated in the experimental version. And so far, 
this method has proven to be useful for me.

- Matthias -

Re: [pygccxml-development] Method taking function pointer not showing up in the generated code

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

On 7/5/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> I have a class with the following static method which can be used to
> register a callback function "func":
>
> static MCallbackId addEventCallback(const MString& event, void (*func)(
> void* clientData ), void* clientData = NULL, MStatus* ReturnStatus = NULL);
>
>
> Pyplusplus does not generate code for this one even so I did not exclude
> it explicitly. Basically, this is ok as the function pointer wouldn't
> work in Python anyway. The thing is just that I don't know *why* it was
> excluded. Actually I did expect it to show up and that I had to remove
> it manually (that's what I was about to do) but pyplusplus did something
> different and I'd just like to know why.
> So is this a "bug" that it doesn't show up in the generated code or is
> there some built-in rule that removed it from the output?

Please take a look on decl_wrappers.calldef_t._exportable_impl function
(http://svn.sourceforge.net/viewcvs.cgi/pygccxml/pyplusplus_dev/pyplusplus/decl_wrappers/calldef_wrapper.py?view=markup)
It contains code, that checks different conditions, whether function
exportable or not.
And if not it returns the reason.

Using decl_wrapper.decl_wrapper_t.why_not_exportable method, you can find out
why a declaration could not be exported.
( http://svn.sourceforge.net/viewcvs.cgi/pygccxml/pyplusplus_dev/pyplusplus/decl_wrappers/decl_wrapper.py?view=markup
)

decl_wrapper.decl_wrapper_t.ignore is calculated property, so when
declaration is
not exportable, it returns True, thus forcing pyplusplus to skip the
declaration.

The problem is that, I still looking for a good way to give this
information to the user.

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

[pygccxml-development] Method taking function pointer not showing up in the generated code

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

Hi,

I have a class with the following static method which can be used to 
register a callback function "func":

static MCallbackId addEventCallback(const MString& event, void (*func)( 
void* clientData ), void* clientData = NULL, MStatus* ReturnStatus = NULL);


Pyplusplus does not generate code for this one even so I did not exclude 
it explicitly. Basically, this is ok as the function pointer wouldn't 
work in Python anyway. The thing is just that I don't know *why* it was 
excluded. Actually I did expect it to show up and that I had to remove 
it manually (that's what I was about to do) but pyplusplus did something 
different and I'd just like to know why.
So is this a "bug" that it doesn't show up in the generated code or is 
there some built-in rule that removed it from the output?

- Matthias -

[pygccxml-development] Help wanted

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

Hi. I am working on adding new indexing suite support  for py++.

There is an interesting "sub-project" here - adding functionality that
will export
iterators. I think, that this "sub-project" can help you to learn more
about py++.
Missing functionality:
pygccxml:
    iterator_traits - type traits
pypluslus:
    1. find out best interface to connect between "begin" and "end"
functions, that
        returns begin, end iterator to the same sequence
    2. create new code creators

I think, I will be able to help using IRC and not only mailing list.

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

Re: [pygccxml-development] Current Vector Indexing Suite

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

On 6/24/06, Lakin Wecker <lak...@gm...> wrote:
> I asked around in the #C++ channel on irc.freenode.net, and found out that
> you are right. It is scope issues, however you can still define the operator
> in the namespace(like you suggested) and it will find it appropriately, even
> for nested classes.  For my case I simply wrap them in
> namespace Ogre {
>         inline bool
> operator==(::Ogre::CompositorInstance::TargetOperation
> const &lhs, ::Ogre::CompositorInstance::TargetOperation
> const &rhs) {
>             throw
> std::runtime_error("::Ogre::CompositorInstance::TargetOperation
> has no comparison operator, using contains has no meaning.");
>         }
> }
>
> and it begins to compile.

:-). I am glad I was wrong!

> Perhaps we can do the same thing in pyplusplus.
> In my mind, there are two issues.
>
> 1)  if we don't issue a warning about it,

py++ writes the warning in the generated code.

> users may be unsuspecting about
> the error, so we should still issue a warning when running pyplusplus.

This still should be done!

> Additionally, maybe we can issue the same warning via a compiler directive
> such as #warning for g++?  Of course, all of these warnings should be
> disabled via the option that we previously discussed on the mailing list.

I will check boost. I am sure they have such functionality, that works on all
compilers.

> 2) We should still provide a way to completely disable the indexing suite (I
> think this is already done?)

Yes

mb.build_code_creators( ..., enable_indexing_suite=False )

> In my mind, an exception thrown is an appropriate pythonic way of handling
> this.  An exception would also be thrown if the __contains__ method was not
> provided for a pythonic list-like object.

It seems that you are right. I am not sure whether I want to fix this or not.
I spent my time learning new indexing suite. It will take only few hours to
implement it, really. A lot of functionality is already there.



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

Re: [pygccxml-development] Current Vector Indexing Suite

[Lakin W. <lak...@gm...>]

I asked around in the #C++ channel on irc.freenode.net, and found out that
you are right. It is scope issues, however you can still define the operator
in the namespace(like you suggested) and it will find it appropriately, even
for nested classes.  For my case I simply wrap them in
namespace Ogre {
        inline bool operator==(::Ogre::CompositorInstance::TargetOperation
const &lhs, ::Ogre::CompositorInstance::TargetOperation const &rhs) {
            throw
std::runtime_error("::Ogre::CompositorInstance::TargetOperation has no
comparison operator, using contains has no meaning.");
        }
}

and it begins to compile.  Perhaps we can do the same thing in pyplusplus.
In my mind, there are two issues.

1)  if we don't issue a warning about it, users may be unsuspecting about
the error, so we should still issue a warning when running pyplusplus.
Additionally, maybe we can issue the same warning via a compiler directive
such as #warning for g++?  Of course, all of these warnings should be
disabled via the option that we previously discussed on the mailing list.
2) We should still provide a way to completely disable the indexing suite (I
think this is already done?)

In my mind, an exception thrown is an appropriate pythonic way of handling
this.  An exception would also be thrown if the __contains__ method was not
provided for a pythonic list-like object.

Lakin

On 6/24/06, Roman Yakovenko <rom...@gm...> wrote:
>
> On 6/24/06, Lakin Wecker <lak...@gm...> wrote:
> > In order to handle the situation of a class that is missing operator==,
> but
> > is being exported using the current vector indexing suite, I wrote
> something
> > which writes code similar to:
> >
> > inline bool
> > operator==(::Ogre::CompositorInstance::TargetOperation lhs,
> > ::Ogre::CompositorInstance::TargetOperation rhs) {
> >     throw
> > std::runtime_error("::Ogre::CompositorInstance::TargetOperation
> > has no comparison operator.");
> > }
> >
> > for each class.  This file is then included in the pyplusplus generated
> > code.  From my understanding of C++, this should be enough.  However, I
> > still get the same compiler error.  If I add the appropriate member
> function
> > directly to class' header file, the generated code compiles.
> >
> > What am I missing?
>
> I think scope. Compiler does not look for operator== where you think
> it looks for.
> I am afraid, that for classes that defined within other classes you don't
> have
> solution. ( I hope somebody will say that I am wrong and show the solution
> ).
> For classes that defined in the namespace, you can define operator==
> in that namespace.
>
> --
> Roman Yakovenko
> C++ Python language binding
> http://www.language-binding.net/
>

Re: [pygccxml-development] Current Vector Indexing Suite

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

On 6/24/06, Lakin Wecker <lak...@gm...> wrote:
> In order to handle the situation of a class that is missing operator==, but
> is being exported using the current vector indexing suite, I wrote something
> which writes code similar to:
>
> inline bool
> operator==(::Ogre::CompositorInstance::TargetOperation lhs,
> ::Ogre::CompositorInstance::TargetOperation rhs) {
>     throw
> std::runtime_error("::Ogre::CompositorInstance::TargetOperation
> has no comparison operator.");
> }
>
> for each class.  This file is then included in the pyplusplus generated
> code.  From my understanding of C++, this should be enough.  However, I
> still get the same compiler error.  If I add the appropriate member function
> directly to class' header file, the generated code compiles.
>
> What am I missing?

I think scope. Compiler does not look for operator== where you think
it looks for.
I am afraid, that for classes that defined within other classes you don't have
solution. ( I hope somebody will say that I am wrong and show the solution ).
For classes that defined in the namespace, you can define operator==
in that namespace.

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

[pygccxml-development] Current Vector Indexing Suite

[Lakin W. <lak...@gm...>]

In order to handle the situation of a class that is missing operator==, but
is being exported using the current vector indexing suite, I wrote something
which writes code similar to:

inline bool operator==(::Ogre::CompositorInstance::TargetOperation lhs,
::Ogre::CompositorInstance::TargetOperation rhs) {
    throw std::runtime_error("::Ogre::CompositorInstance::TargetOperation
has no comparison operator.");
}

for each class.  This file is then included in the pyplusplus generated
code.  From my understanding of C++, this should be enough.  However, I
still get the same compiler error.  If I add the appropriate member function
directly to class' header file, the generated code compiles.

What am I missing?

Lakin

Re: [pygccxml-development] A way to turn off indexing suite?

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

Roman Yakovenko wrote:

>On 6/22/06, Allen Bierbaum <al...@vr...> wrote:
>  
>
>>Also
>>the generated code has a comment that says it should not compile.  This
>>worries me because it does compile.
>>    
>>
>
>You don't have to worry. This is new functionality and I think I have bug. The
>comment says that py++ can not find operator==, right. If the code compiles
>than your class do has operator==. Can you contribute the test case, so I can
>find and fix the bug.
>  
>
I don't have an easy way to get a test case out of this one but I will 
try to look into it.

On a related note, I took your advice and I am keeping track of any 
issues, missing features, problems, etc I run into while porting some 
projects to use pyplusplus.  My list is getting pretty long.  Once I get 
done with the porting I promise that I will send out an e-mail with a 
description of the things I have run into.

>  
>
>>But for now since the old manual
>>code works I would rather just keep using it until I have time to learn
>>how to use the indexing suite support in pypp.
>>    
>>
>
>If it works, don't touch! :-)
>  
>
Exactly.  Especially when trying to meet deadlines. :)

-A

[pygccxml-development] Indexing suite v2

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

Good evening.
I am working on adding indexing suite support to py++. Few days ago I thought,
that I done. I was wrong. Why? py++ support current version of Boost.Python
indexing suite. But this indexing suite is too limited. Basically it
can work with: vector,
map and hash_map. Niall Douglas pointed me to another indexing suite.

http://mail.python.org/pipermail/c++-sig/2003-October/005802.html
http://boost.cvs.sourceforge.net/*checkout*/boost/boost/libs/python/doc/v2/containers.html?revision=1.1.2.8&pathrev=indexing_v2

This new suite is more powerful and according to Niall, it has better
performance.
I decided to add support to this suite to py++. ( In order to create
Python bindings
for OGRE we, Lakin Wecker and I, need a functionality found in the suite ).

The good news, is that most functionality already exists in py++ and
it should take
only few hours ( 10 - 15, including unit tests ) to add support to new suite.

This new suite is not mentioned any where in boost.python documentation.
So, I think I will distribute it with py++ with detailed instructions
how to install it.
I am sure this suite contains bugs. I will try to maintain the suite,
until it will become officially supported.

Thoughts?

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

Re: [pygccxml-development] A way to turn off indexing suite?

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

On 6/22/06, Allen Bierbaum <al...@vr...> wrote:
> Also
> the generated code has a comment that says it should not compile.  This
> worries me because it does compile.

You don't have to worry. This is new functionality and I think I have bug. The
comment says that py++ can not find operator==, right. If the code compiles
than your class do has operator==. Can you contribute the test case, so I can
find and fix the bug.

> But for now since the old manual
> code works I would rather just keep using it until I have time to learn
> how to use the indexing suite support in pypp.

If it works, don't touch! :-)

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

Re: [pygccxml-development] A way to turn off indexing suite?

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

Roman Yakovenko wrote:

>On 6/22/06, Allen Bierbaum <al...@vr...> wrote:
>  
>
>>Is there a way to disable the new code that automagically generated
>>indexing suite wrappers?
>>    
>>
>
>I just committed some changes that allow this.
>
>mb.build_code_creator( ..., enable_indexing_suite=False )
>
>  
>
>>It has broken all my modules where I used to
>>do this manually and the generated code says it can't compile anyway.
>>    
>>
>
>If I understand you right, the manual code that you added worked okay, but
>code generated by py++ is not? What do you mean "It has broken all my
>modules where I used to do this manually"? May be you find a bug? Do
>you care to explain?
>  
>
The combination of code generated manually and automatically now tries 
to register the same class twice which makes boost.python assert.  Also 
the generated code has a comment that says it should not compile.  This 
worries me because it does compile.  But for now since the old manual 
code works I would rather just keep using it until I have time to learn 
how to use the indexing suite support in pypp.

-Allen

>Thanks
>
>  
>

Re: [pygccxml-development] A way to turn off indexing suite?

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

On 6/22/06, Allen Bierbaum <al...@vr...> wrote:
> Is there a way to disable the new code that automagically generated
> indexing suite wrappers?

I just committed some changes that allow this.

mb.build_code_creator( ..., enable_indexing_suite=False )

> It has broken all my modules where I used to
> do this manually and the generated code says it can't compile anyway.

If I understand you right, the manual code that you added worked okay, but
code generated by py++ is not? What do you mean "It has broken all my
modules where I used to do this manually"? May be you find a bug? Do
you care to explain?

Thanks

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

[pygccxml-development] A way to turn off indexing suite?

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

Is there a way to disable the new code that automagically generated 
indexing suite wrappers?  It has broken all my modules where I used to 
do this manually and the generated code says it can't compile anyway.  
How can I remove it?

-Allen

Re: [pygccxml-development] Indexing suite exception

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

On 6/22/06, Matthias Baas <ba...@ir...> wrote:
> > Do you want/have time to make pyplusplus messages really useful? Can you
> > fix current situation?
>
> I'll have a look at it when I have some time left...

Thanks

> As it turned out the max arity is not so important anymore as I thought
> (see my previous mail). But in general, I think the important messages
> are those that are supposed to trigger some user action (e.g. missing
> policies where a user must provide additional information to be able to
> get source code that compiles).


Good definition.

> Right. :)

Yesterday I committed the patch that fixed the situation.

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

Re: [pygccxml-development] Indexing suite exception

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

Roman Yakovenko wrote:
>> I have that already in my script, but I still get a line for each
>> individual file that is written. Maybe these messages should be debug
>> messages instead of info messages (I think a summary of the time it took
>> to write the files and maybe how many files were actually updated would
>> be enough in the standard case).
>> (But apart from that there is still a lot of output from my own script
>> that would drown the message anyway)
> 
> Do you want/have time to make pyplusplus messages really useful? Can you
> fix current situation?

I'll have a look at it when I have some time left...

>> I think it's not so much of a problem
>> that pyplusplus generated invalid code but it's more serious that I
>> missed the warnings about that (if I had seen them I wouldn't have tried
>> compiling the code in the first place).
> 
> Would it be helpful, if pyplusplus will dump the information to the
> generated source
> files, too? So when you see compilation error you also can read an 
> explanation.

So far, I wouldn't have looked into the generated source code to find 
documentation text explaining why something failed but I like the idea. 
I think it wouldn't do any harm putting some extra comments into the 
source files if pyplusplus knows in advance that a particular construct 
might cause problems in some situations.

>> default, namely the console window). My suggestion would be to write the
>> really important messages (like the max arity thing) into a separate log
>> file in addition to writing to stdout (or actually it should be stderr).
> 
> What is your definition/guide line of "really important"? Also I agree 
> with you.

As it turned out the max arity is not so important anymore as I thought 
(see my previous mail). But in general, I think the important messages 
are those that are supposed to trigger some user action (e.g. missing 
policies where a user must provide additional information to be able to 
get source code that compiles).

>> > Then he will update decl_wrappers.calldef_t.BOOST_PYTHON_MAX_ARITY 
>> to the
>> > actual number and will get rid of warning :-)
>>
>> Aha, there we are... :)
>> (though I'd recommend to add functionality to the high level API to
>> read/write this value so that the details of where the attribute is
>> actually stored in pyplusplus are encapsulated)
> 
> :-) I will add new property to module_builder_t. That is what you meant, 
> right?

Right. :)

- Matthias -

Re: [pygccxml-development] Indexing suite exception

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

Lakin Wecker wrote:
>> information is passed to the user. I think it's not so much of a problem
>> that pyplusplus generated invalid code
> 
> I know that I'm just arguing semantics, but I disagree.  The code
> _does_ compile and is therefore _not_ invalid.  It just requires you
> to pass an extra switch the compiler, in this case:
> -DBOOST_PYTHON_MAX_ARITY=19 or somesuch.

Oops, I just noticed I misunderstood the whole thing. I thought I had to 
set the max arity when compiling *Boost.Python* instead of my own code.
Now that I know I have to set this when compiling my own module, it's 
not so much of an issue anymore. And yes, the code generated by 
pyplusplus is not invalid in this case.
But as you suggested, there could be an option so that pyplusplus just 
puts the appropriate #define right inside the file.

> I don't mind the current behavior as it would be easy for the user to
> hook into the logging module and write out messages above a certain
> importance to a separate log file.

Right, but why should I do that if I don't suspect any problems in the 
first place? My point is just that it always makes sense to dump serious 
error messages into a file for later inspection, so why not make this 
the default behavior? But that's only a minor issue, it's more important 
that pyplusplus internally categorizes its messages properly so that the 
user can filter out what is interesting to him.

> However, having a some sort of summary printed at the end of all the
> interesting things that a User may have to take care of would be nice.

Agreed.

- Matthias -

Re: [pygccxml-development] indexing suite and operator==

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

On 6/21/06, Lakin Wecker <lak...@gm...> wrote:
> I prefer the second case with an appropriate warning message generated
> and a comment.

Me too.

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

Re: [pygccxml-development] indexing suite and operator==

[Lakin W. <lak...@gm...>]

On 6/21/06, Roman Yakovenko <rom...@gm...> wrote:
> Good evening. I need some help. I don't know what is preferred behaviour of
> py++ in next situation. In order to use indexing suite, class X should
> define operator==. What py++ should do when it found usage of
> std::vector< X >?
>
> The generated code
> class_< vector< X > >( "Xs" )
>     .def( vector_indexing_suite< vector<X> > );
>
> will not compile.
> There are 2 options:
> 1. py++ will not generate that code. Very bad option, because user
> will get wrong
>     filling, that created bindings just work. All functions that use
> vector< X > are
>     non-callable from Python.
>
> 2. Generate code. The bad side of this approach is compiler error
> message - it is
>     pretty big and scaring. It can confuse any user, but at least he
> will aware of
>     the problem. py++ can generate some comment within source code that will
>     help the user to understand the problem quickly.

I prefer the second case with an appropriate warning message generated
and a comment.

Lakin