pygccxml-development

[pygccxml-development] [FT] recent changes

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

Hi. Few comments on committed code:

1. rename gil_state_t to gil_controller_t
    In my opinion it is better describes what we are doing

2. to put gil_controller_t under pyplusplus::threading namespace
    pyplusplus is top level namespace, like boost. Every functionality should
    belong to it's own namespace.

3. creator_t:
    self.__extmodule.adopt_creator( code_creators.include_t(
code_repository.gil_state.file_name )
                                                         ,
self.__extmodule.first_include_index() + 1)
    Is there is a reason why do you want to put your file to be the second one?
    If not, I think you can swith to module_t.adopt_include method


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

Re: [pygccxml-development] code_repository package

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

On 9/20/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> >>>> How do I influence whether a file is considered a system header or not?
> >>> In creator_t, you add your header file using add_system_header API
> >> I suppose the header should only be created when it is required, right?
> >
> > file_writers package will do that for you.
>
> How does it do that?

writer_t class defines write_code_repository method. It is a respnocibility of
derived file writers to call this function.

>
> The responsibility of a code creator object is to create a piece of C++
> source code that will be written into one or more output files, right?
> Now my actual question probably boils down to the following question:
> Whose responsibility is it to make sure that the code that was generated
> by a particular code creator object can also be compiled without errors?

File writer + code creator. File writer answer the question: where to put the
code, while code creator "what code to put". creator_t defines
"logical" place of the code creator, by placing it in the right place
within the tree. File writers insure that the "logical"
place of code creator is preserved.

My advice: implement your feature as is all code would be written in
single file.
Only then think about multiple files.


> >> Just to see if the file gets written or not I called add_system_header()
> >> and adopt_creator() on every call to visit_member_function(), but then I
> >> get a huge list of identical include statements in the generated files.
> >
> > I don't fully understand what you are doing here.
>
> I was just doing what you were suggesting earlier, i.e. to call
> add_system_header() to have Py++ write a particular header from the code
> repository package. This did work but the file was nowhere included, so
> I added an "include" code creator using adopt_creator() on the root node
> (I was peeking at the array_1 stuff to see how it is done). But as I was
> doing that in every call to visit_member_function() the file got
> included again each time resulting in a lot of duplicate lines.

Okey. You will have to prevent this and I think you already understand
how to do this
or already did. Am I right?

> >> What I would actually like to do is to add the "include" code creator to
> >> the associated_decl_creators list of the corresponding class so that the
> >> include only shows up in the file where it is needed. But how can I
> >> check whether the file was already included or not?
> >
> > If we talk about system header than you can ask module_t code creator
> > ( creator_t.__extmodule ) is_system_header.
>
> ok, this is what I'm doing now and which does work for now. But this
> makes the include file a "project wide" include file. How should I do
> this check if I would only like to add the include code creator to the
> associated_decl_creators list? (so that it only gets included where it
> is required?)

It is not possible. I tell you more, it will not be possible for few
next versions.
Py++ is missinig one concept - "bind" or "connect". Today user is not able to
"bind" between different declarations and different pieces of generated code.

Consider next cases:
* expose get\\set function as python properties
* expose begin\\end iterator as Boost.Python range
* add code "X" to the file, where declaration Y will be generated.
* register opaque type, when function has relevant call policy

I can continue the list, but I think you understand me. The small
refactoring I do on
code creators and file writers should improve (not fix ) the situation.

> >> I wonder why there is no specific API for managing include files that
> >> handles all those stuff? It appears to me that this would be quite a
> >> useful thing to have.
> >
> > Lack of time and low priority. Users learned to leave with "non
> > optimal" generated
> > code. I mean that all include appears in all header files. But they don't like
> > Py++, when it does not support the functionality they needed.
>
> That's not what I meant. I mean, even when the current functionality is
> exactly preserved, I would rather like to have an (internal) API that
> handles the details of how an include file is added to the output files.
> This is required at several places and it's not easy to understand how
> it is properly done. An additional benefit would be that it would pave
> the way for improving the handling of include files so that they could
> be set on a file-by-file basis.

I think I answered your question. In other words the problem is
"wider" and I want
to have 1 solution for it.


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

Re: [pygccxml-development] code_repository package

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

Roman Yakovenko wrote:
>>>> How do I influence whether a file is considered a system header or not?
>>> In creator_t, you add your header file using add_system_header API
>> I suppose the header should only be created when it is required, right?
> 
> file_writers package will do that for you.

How does it do that?

>> I want to use it for the class that can acquire/release the Python GIL
>> (as you have suggested earlier).
>> So the actual decision whether the header is required or not is done by
>> the code creator (mem_fun_v_transformed_wrapper_t). What is your
>> recommendation how the code in creator_t (this is
>> visit_member_function(), right?) will know about this decision?
> 
> It can search for "thread safe" transformer. The better idea to
> introduce next class:
> 
> class ftransformer_t:
>     keeps a list of all transformations that should be applied on the
> function at once
> 
>     provides some additional functionality:
>         function signature
>         has_thread_safe_transformer
>         ...
> 
> Than
> 1. Creator will use it to ask the right question
> 2. It will be possible to have more than 1 "f" transformation applied
> on the same
>     function: for example "status as exception"
> 
>     struct status{};
>     void do_smth( status& )
> 
>     In some cases it makes sence to expose "do_smth" function as is and to
>     expose some convinience function that will raise an exception.

I'm sorry, obviously I got misunderstood as this doesn't answer my
question. My question was actually related to the code repository
package and its usage, the function transformers and thread safety stuff 
was just an example. Sorry for any confusion. Maybe I should rephrase my
question:

The responsibility of a code creator object is to create a piece of C++ 
source code that will be written into one or more output files, right? 
Now my actual question probably boils down to the following question: 
Whose responsibility is it to make sure that the code that was generated 
by a particular code creator object can also be compiled without errors?

>> Just to see if the file gets written or not I called add_system_header()
>> and adopt_creator() on every call to visit_member_function(), but then I
>> get a huge list of identical include statements in the generated files.
> 
> I don't fully understand what you are doing here.

I was just doing what you were suggesting earlier, i.e. to call
add_system_header() to have Py++ write a particular header from the code
repository package. This did work but the file was nowhere included, so
I added an "include" code creator using adopt_creator() on the root node
(I was peeking at the array_1 stuff to see how it is done). But as I was
doing that in every call to visit_member_function() the file got
included again each time resulting in a lot of duplicate lines.

>> What I would actually like to do is to add the "include" code creator to
>> the associated_decl_creators list of the corresponding class so that the
>> include only shows up in the file where it is needed. But how can I
>> check whether the file was already included or not?
> 
> If we talk about system header than you can ask module_t code creator
> ( creator_t.__extmodule ) is_system_header. 

ok, this is what I'm doing now and which does work for now. But this 
makes the include file a "project wide" include file. How should I do 
this check if I would only like to add the include code creator to the 
associated_decl_creators list? (so that it only gets included where it 
is required?)

>> I wonder why there is no specific API for managing include files that
>> handles all those stuff? It appears to me that this would be quite a
>> useful thing to have.
> 
> Lack of time and low priority. Users learned to leave with "non
> optimal" generated
> code. I mean that all include appears in all header files. But they don't like
> Py++, when it does not support the functionality they needed.

That's not what I meant. I mean, even when the current functionality is 
exactly preserved, I would rather like to have an (internal) API that 
handles the details of how an include file is added to the output files. 
This is required at several places and it's not easy to understand how 
it is properly done. An additional benefit would be that it would pave 
the way for improving the handling of include files so that they could 
be set on a file-by-file basis.

- Matthias -

Re: [pygccxml-development] Pulling methods from base class without exposing base class

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

On 9/19/06, Allen Bierbaum <al...@vr...> wrote:
> Roman Yakovenko wrote:
>
> > On 9/19/06, Allen Bierbaum <al...@vr...> wrote:
> >
> >> I am having trouble wrapping a class right now.  The problem is that the
> >> class uses template base classes to mixin functionality.  This makes it
> >> appear to pygccxml that the class has a half-dozen base classes.  But I
> >> don't want to expose these base classes, all I want to expose is the
> >> class that is composed from the mixin functionality.
> >
> >
> > I understand.
> >
> >>  To make matters
> >> worse there is something in the handling of these mixins that is making
> >> pyplusplus code creators expose them all as having the same name
> >> ("Inherited").  I think this is because each mixin class uses a typedef
> >> called Inherited to keep track of the class that it is inheriting from.
> >
> >
> > This is the right guess.
> >
> >> (I have attached a file that shows the basic idea, but it is a vast
> >> simplification of the case I am really trying to handle)
> >>
> >> Anyway, to make a long story short, what I would like to do is just tell
> >> pyplusplus to ignore the base classes (ie. don't expose them) but to
> >> instead pull all of the methods defined in those base classes into the
> >> derived class I am trying to expose.  Then the generated code would only
> >> create a wrapper for the derived class and would just create "def"'s
> >> that reference the methods from the mixins.
> >>
> >> Is this possible?
> >
> >
> > What do you think? Before I answer the question, I would like to make
> > it clear:
> > this is not  "the main success scenario", so you will have to touch
> > here and there
> > few low level details.
> >
> > 1. create module_builder_t object and pass  "optimize_queries=False"
> > as a parameter.
> > 2. Using adopt_declaration and remove_declaration methods of
> > declarations.class_t
> >    put the method into right place. Be careful! Declaration can have
> > only 1 parent.
> >    So if you have few derived classes you will have to "copy"
> > declaration and to
> >    add the copy to every derived class.
> > 3. after you finished to modify the declarations tree, run query
> > optimizer
> >    mb.run_query_optimizer()
> > 4. don't forget to exclude the base classes.
> >
> > I think this should work and it does not require too much work.
> >
> Step 2 may be the problem.  To do step 2 I would have to still find and
> reference all the mixin base classes in the system and use them.  Are
> you thinking I should/could build this using the recursive_bases property?

Yes, you also have recursive_derived property.

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

Re: [pygccxml-development] Pulling methods from base class without exposing base class

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

Roman Yakovenko wrote:

> On 9/19/06, Allen Bierbaum <al...@vr...> wrote:
>
>> I am having trouble wrapping a class right now.  The problem is that the
>> class uses template base classes to mixin functionality.  This makes it
>> appear to pygccxml that the class has a half-dozen base classes.  But I
>> don't want to expose these base classes, all I want to expose is the
>> class that is composed from the mixin functionality.
>
>
> I understand.
>
>>  To make matters
>> worse there is something in the handling of these mixins that is making
>> pyplusplus code creators expose them all as having the same name
>> ("Inherited").  I think this is because each mixin class uses a typedef
>> called Inherited to keep track of the class that it is inheriting from.
>
>
> This is the right guess.
>
>> (I have attached a file that shows the basic idea, but it is a vast
>> simplification of the case I am really trying to handle)
>>
>> Anyway, to make a long story short, what I would like to do is just tell
>> pyplusplus to ignore the base classes (ie. don't expose them) but to
>> instead pull all of the methods defined in those base classes into the
>> derived class I am trying to expose.  Then the generated code would only
>> create a wrapper for the derived class and would just create "def"'s
>> that reference the methods from the mixins.
>>
>> Is this possible?
>
>
> What do you think? Before I answer the question, I would like to make 
> it clear:
> this is not  "the main success scenario", so you will have to touch
> here and there
> few low level details.
>
> 1. create module_builder_t object and pass  "optimize_queries=False"
> as a parameter.
> 2. Using adopt_declaration and remove_declaration methods of
> declarations.class_t
>    put the method into right place. Be careful! Declaration can have
> only 1 parent.
>    So if you have few derived classes you will have to "copy"
> declaration and to
>    add the copy to every derived class.
> 3. after you finished to modify the declarations tree, run query 
> optimizer
>    mb.run_query_optimizer()
> 4. don't forget to exclude the base classes.
>
> I think this should work and it does not require too much work.
>
Step 2 may be the problem.  To do step 2 I would have to still find and 
reference all the mixin base classes in the system and use them.  Are 
you thinking I should/could build this using the recursive_bases property?

-Allen

Re: [pygccxml-development] Pulling methods from base class without exposing base class

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

On 9/19/06, Allen Bierbaum <al...@vr...> wrote:
> I am having trouble wrapping a class right now.  The problem is that the
> class uses template base classes to mixin functionality.  This makes it
> appear to pygccxml that the class has a half-dozen base classes.  But I
> don't want to expose these base classes, all I want to expose is the
> class that is composed from the mixin functionality.

I understand.

>  To make matters
> worse there is something in the handling of these mixins that is making
> pyplusplus code creators expose them all as having the same name
> ("Inherited").  I think this is because each mixin class uses a typedef
> called Inherited to keep track of the class that it is inheriting from.

This is the right guess.

> (I have attached a file that shows the basic idea, but it is a vast
> simplification of the case I am really trying to handle)
>
> Anyway, to make a long story short, what I would like to do is just tell
> pyplusplus to ignore the base classes (ie. don't expose them) but to
> instead pull all of the methods defined in those base classes into the
> derived class I am trying to expose.  Then the generated code would only
> create a wrapper for the derived class and would just create "def"'s
> that reference the methods from the mixins.
>
> Is this possible?

What do you think? Before I answer the question, I would like to make it clear:
this is not  "the main success scenario", so you will have to touch
here and there
few low level details.

1. create module_builder_t object and pass  "optimize_queries=False"
as a parameter.
2. Using adopt_declaration and remove_declaration methods of
declarations.class_t
    put the method into right place. Be careful! Declaration can have
only 1 parent.
    So if you have few derived classes you will have to "copy"
declaration and to
    add the copy to every derived class.
3. after you finished to modify the declarations tree, run query optimizer
    mb.run_query_optimizer()
4. don't forget to exclude the base classes.

I think this should work and it does not require too much work.

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

Re: [pygccxml-development] code_repository package

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

On 9/19/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> >> How do I influence whether a file is considered a system header or not?
> >
> > In creator_t, you add your header file using add_system_header API
>
> I suppose the header should only be created when it is required, right?

file_writers package will do that for you.

> I want to use it for the class that can acquire/release the Python GIL
> (as you have suggested earlier).
> So the actual decision whether the header is required or not is done by
> the code creator (mem_fun_v_transformed_wrapper_t). What is your
> recommendation how the code in creator_t (this is
> visit_member_function(), right?) will know about this decision?

It can search for "thread safe" transformer. The better idea to
introduce next class:

class ftransformer_t:
    keeps a list of all transformations that should be applied on the
function at once

    provides some additional functionality:
        function signature
        has_thread_safe_transformer
        ...

Than
1. Creator will use it to ask the right question
2. It will be possible to have more than 1 "f" transformation applied
on the same
    function: for example "status as exception"

    struct status{};
    void do_smth( status& )

    In some cases it makes sence to expose "do_smth" function as is and to
    expose some convinience function that will raise an exception.


> Just to see if the file gets written or not I called add_system_header()
> and adopt_creator() on every call to visit_member_function(), but then I
> get a huge list of identical include statements in the generated files.

I don't fully understand what you are doing here.

> What I would actually like to do is to add the "include" code creator to
> the associated_decl_creators list of the corresponding class so that the
> include only shows up in the file where it is needed. But how can I
> check whether the file was already included or not?

If we talk about system header than you can ask module_t code creator
( creator_t.__extmodule ) is_system_header. You can also "include"
the header from "_create_includes" method.

> I wonder why there is no specific API for managing include files that
> handles all those stuff? It appears to me that this would be quite a
> useful thing to have.

Lack of time and low priority. Users learned to leave with "non
optimal" generated
code. I mean that all include appears in all header files. But they don't like
Py++, when it does not support the functionality they needed.

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

[pygccxml-development] Pulling methods from base class without exposing base class

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

I am having trouble wrapping a class right now.  The problem is that the 
class uses template base classes to mixin functionality.  This makes it 
appear to pygccxml that the class has a half-dozen base classes.  But I 
don't want to expose these base classes, all I want to expose is the 
class that is composed from the mixin functionality.  To make matters 
worse there is something in the handling of these mixins that is making 
pyplusplus code creators expose them all as having the same name 
("Inherited").  I think this is because each mixin class uses a typedef 
called Inherited to keep track of the class that it is inheriting from.  
(I have attached a file that shows the basic idea, but it is a vast 
simplification of the case I am really trying to handle)

Anyway, to make a long story short, what I would like to do is just tell 
pyplusplus to ignore the base classes (ie. don't expose them) but to 
instead pull all of the methods defined in those base classes into the 
derived class I am trying to expose.  Then the generated code would only 
create a wrapper for the derived class and would just create "def"'s 
that reference the methods from the mixins. 

Is this possible?

-Allen

Re: [pygccxml-development] code_repository package

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

Roman Yakovenko wrote:
>> How do I influence whether a file is considered a system header or not?
> 
> In creator_t, you add your header file using add_system_header API

I suppose the header should only be created when it is required, right?
I want to use it for the class that can acquire/release the Python GIL 
(as you have suggested earlier).
So the actual decision whether the header is required or not is done by 
the code creator (mem_fun_v_transformed_wrapper_t). What is your 
recommendation how the code in creator_t (this is 
visit_member_function(), right?) will know about this decision?

Just to see if the file gets written or not I called add_system_header() 
and adopt_creator() on every call to visit_member_function(), but then I 
get a huge list of identical include statements in the generated files.
What I would actually like to do is to add the "include" code creator to 
the associated_decl_creators list of the corresponding class so that the 
include only shows up in the file where it is needed. But how can I 
check whether the file was already included or not?

I wonder why there is no specific API for managing include files that 
handles all those stuff? It appears to me that this would be quite a 
useful thing to have.

- Matthias -

Re: [pygccxml-development] code_repository package

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

On 9/19/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> >> I've seen that those files get written in
> >> writer_t.write_code_repository(). But what does this line do:
> >>
> >>       if self.__extmodule.is_system_header( cr.file_name ):
> >>
> >> What exactly is a "system header" in this context?
> >
> > In whole context "system header" defined as header file that belongs to
> > Boost.Python or to Py++.
>
> Aren't then all files from the code_repository package "system headers"?

Yes they are

> How do I influence whether a file is considered a system header or not?

In creator_t, you add your header file using add_system_header API

> I tried adding a new file to the code_repository package, but it doesn't
> get written.

1. May be you did not add it as system header in creator_t class
2. May be you did not modified code_repository.__init__.py file

You can commit your code and I will take a look on it this evening.

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

Re: [pygccxml-development] code_repository package

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

Roman Yakovenko wrote:
>> I've seen that those files get written in
>> writer_t.write_code_repository(). But what does this line do:
>>
>>       if self.__extmodule.is_system_header( cr.file_name ):
>>
>> What exactly is a "system header" in this context?
> 
> In whole context "system header" defined as header file that belongs to
> Boost.Python or to Py++. 

Aren't then all files from the code_repository package "system headers"?
How do I influence whether a file is considered a system header or not? 
I tried adding a new file to the code_repository package, but it doesn't 
get written.

- Matthias -

Re: [pygccxml-development] code_repository package

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

On 9/19/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > With this class you can change the code in create_virtual_body method.
> > Py++ has all functionality needed to add this code Take a look on
> > code_repository package.
>
> I've seen that those files get written in
> writer_t.write_code_repository(). But what does this line do:
>
>       if self.__extmodule.is_system_header( cr.file_name ):
>
> What exactly is a "system header" in this context?

In whole context "system header" defined as header file that belongs to
Boost.Python or to Py++. When I build code creators tree, in creator_t, I add
"include" directives to the module_t code creator. In all cases I know
whether they are
system headers or

> And a second question: Where is the 'namespace' variable used?

When you use the functionality defined in the repository.

Take a look on array_1_registrator_t code creator and its construction
in creator_t class.

The namespace solves few problems:
1. pollution of global namespace
2. prevents Py++ functionality to conflict with user defined one
3. to say explicitly to the user that this code has been written by
Py++ developers and not
   by Boost.Python ( be careful :-) )


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

[pygccxml-development] code_repository package

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

Roman Yakovenko wrote:
> With this class you can change the code in create_virtual_body method.
> Py++ has all functionality needed to add this code Take a look on
> code_repository package.

I've seen that those files get written in 
writer_t.write_code_repository(). But what does this line do:

      if self.__extmodule.is_system_header( cr.file_name ):

What exactly is a "system header" in this context?

And a second question: Where is the 'namespace' variable used?

- Matthias -

Re: [pygccxml-development] [FT]subst_t class - do we really need to reinvent the wheel?

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

Roman Yakovenko wrote:
> http://docs.python.org/lib/node109.html
> 
> Matthias I think you can use the class from the standard library.

Ah, I wasn't aware of that class. Thanks. I've just committed a version 
that makes use of the class.

Unfortunately, there is no easy way to modify the behavior for undefined 
variables. So the semantics of the substitution has slightly changed 
now. Previously, undefined variables were substituted with an empty 
string, now they won't get substituted at all. This probably won't be an 
issue in practice, but I had to update some parts in the code because of 
that. Now the raw line count is 2 lines less than before (but at least 
it *is* less :) but I agree that the new code is easier to grasp.

- Matthias -

Re: [pygccxml-development] Recent Py++ modifications...

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

On 9/18/06, Matthias Baas <ba...@ir...> wrote:
> I created a small test file that demonstrates the problem. While doing
> so, I noticed that the problem only exists when I manually add the copy
> constructor to the bindings (which is what I'm doing for the Maya bindings).

Thank you for small test case. I was able to reproduce the bug. To
tell you the true
I don't know what I should do and how I should fix the situation. The
changes we are
talking about does not change the logic of creation "implicitly_convertible".

This is the code that has been used to find out whether Py++ needs to generate
i.c.:
if not self._is_constructor_of_abstract_class( self.curr_decl ) \
   and 1 == len( self.curr_decl.arguments ) \
   and self.__create_castinig_constructor \
   and self.curr_decl.access_type == ACCESS_TYPES.PUBLIC:
    maker = code_creators.casting_constructor_t( constructor=self.curr_decl )
    self.__module_body.adopt_creator( maker )

Now it looks a little bit different:

if self.curr_decl.allow_implicit_conversion:
    maker = code_creators.casting_constructor_t( constructor=self.curr_decl )
    self.__module_body.adopt_creator( maker )

where allow_implicit_conversion defined as :
def _get_allow_implicit_conversion(self):
    return self._allow_implicit_conversion and
self.does_define_implicit_conversion()

def does_define_implicit_conversion( self ):
    if self.parent.is_abstract: #user is not able to create an
instance of the class
       return False
    if self.is_copy_constructor:
       return False
    if 1 != len( self.arguments ):
       return False
    if self.parent.find_out_member_access_type( self ) !=
declarations.ACCESS_TYPES.PUBLIC:
       return False
    return True

I don't see the change in a logic, may you do? Anyway I think that the
problem is
in Boost.Python. I will report it the mailing list.

The solution to your problem is simple: don't allow implicit conversion:
constr.allow_implicit_conversion = False
This should solve it.
If you have any ideas, what I should to - please tell me.
-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] Recent Py++ modifications...

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

Roman Yakovenko wrote:
>> I've checked out Py++ from last week and gradually did updates to check
>> which one was responsible for the failure. The problematic modification
>> was done in revision 539:
>> http://svn.sourceforge.net/viewvc/pygccxml?view=rev&revision=539
>>
>> With this modification Py++ generates much more
>> implicitly_convertible<>() statements in the main function. For example,
>> I now have the following line which I think is responsible for the 
>> failure:
>>
>>      bp::implicitly_convertible< MFloatVector const &, MVector >();
>>
>> I can't say for sure what is going on inside of Boost.Python and why it
>> fails, but at least I know that everything has worked before this
>> modification.
>> What kind of problems was this modification supposed to fix?
> 
> I moved the logic whether to create "implicitly_convertible" code to
> decl_wrapper
> constructor class, where it should be.
> 
>> And how do
>> I get back to the previous behavior?
> 
> This test 
> http://svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/unittests/casting_tester.py?view=markup&pathrev=539 
> 
> shows that it should work by default. Can you modify test case in a
> such way it will fail?

I created a small test file that demonstrates the problem. While doing 
so, I noticed that the problem only exists when I manually add the copy 
constructor to the bindings (which is what I'm doing for the Maya bindings).

Here's the C++ code:

struct Vector
{
   double val;

   Vector() : val(0) {}
   Vector(const Vector& v) : val(v.val) {}
   Vector(double x) : val(x) {}
};

struct FloatVector
{
   double val;

   FloatVector() : val(0) {}
   FloatVector(const FloatVector& v) : val(v.val) {}
   FloatVector(const Vector& v) : val(v.val) {}
   FloatVector(float x) : val(x) {}
};

Py++ doesn't wrap the copy constructor, so I do that manually for the 
FloatVector class:

root.Class("FloatVector").cdef("bp::init< const FloatVector& >()")

This adds the line

   bp::init< const FloatVector& >()

to the registration code of the FloatVector class.

The generated main function looks like this:

BOOST_PYTHON_MODULE(testlib){
     register_FloatVector_class();

     bp::implicitly_convertible< Vector const &, FloatVector >();

     bp::implicitly_convertible< float, FloatVector >();

     register_Vector_class();

     bp::implicitly_convertible< double, Vector >();
}


After compilation I try to create a FloatVector instance like this:

   fv = FloatVector(5.0)

The result of this is the following exception:

TypeError: No registered converter was able to extract a C++ reference 
to type Vector from this Python object of type float

When I remove the line

   bp::implicitly_convertible< Vector const &, FloatVector >();

then the above instantiation works.

- Matthias -

Re: [pygccxml-development] Recent Py++ modifications...

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

On 9/18/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> >> One of the tests contains those two lines:
> >>
> >>          fv = MFloatVector(0.6, 0.7, 0.8)
> >>          p = MPoint(fv)
> >>
> >> When this code is executed, the second line produces the following error:
> >>
> >> TypeError: No registered converter was able to extract a C++ reference
> >> to type class MVector from this Python object of type MFloatVector
> >> [...]
> >
> > It is not you. I did small code clean up. Basically I moved some code from
> > creator_t to relevant decl_wrapper classes. May be I broke somthing. Can
> > you
> > create small test case?  Do you use latest version from Subversion?
>
> I've checked out Py++ from last week and gradually did updates to check
> which one was responsible for the failure. The problematic modification
> was done in revision 539:
> http://svn.sourceforge.net/viewvc/pygccxml?view=rev&revision=539
>
> With this modification Py++ generates much more
> implicitly_convertible<>() statements in the main function. For example,
> I now have the following line which I think is responsible for the failure:
>
>      bp::implicitly_convertible< MFloatVector const &, MVector >();
>
> I can't say for sure what is going on inside of Boost.Python and why it
> fails, but at least I know that everything has worked before this
> modification.
> What kind of problems was this modification supposed to fix?

I moved the logic whether to create "implicitly_convertible" code to
decl_wrapper
constructor class, where it should be.

> And how do
> I get back to the previous behavior?

This test http://svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/unittests/casting_tester.py?view=markup&pathrev=539
shows that it should work by default. Can you modify test case in a
such way it will fail?
I will fix it this evening.

Sorry for inconvenience.


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

Re: [pygccxml-development] Recent Py++ modifications...

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

Roman Yakovenko wrote:
>> One of the tests contains those two lines:
>>
>>          fv = MFloatVector(0.6, 0.7, 0.8)
>>          p = MPoint(fv)
>>
>> When this code is executed, the second line produces the following error:
>>
>> TypeError: No registered converter was able to extract a C++ reference
>> to type class MVector from this Python object of type MFloatVector
>> [...]
> 
> It is not you. I did small code clean up. Basically I moved some code from
> creator_t to relevant decl_wrapper classes. May be I broke somthing. Can 
> you
> create small test case?  Do you use latest version from Subversion?

I've checked out Py++ from last week and gradually did updates to check 
which one was responsible for the failure. The problematic modification 
was done in revision 539: 
http://svn.sourceforge.net/viewvc/pygccxml?view=rev&revision=539

With this modification Py++ generates much more 
implicitly_convertible<>() statements in the main function. For example, 
I now have the following line which I think is responsible for the failure:

     bp::implicitly_convertible< MFloatVector const &, MVector >();

I can't say for sure what is going on inside of Boost.Python and why it 
fails, but at least I know that everything has worked before this 
modification.
What kind of problems was this modification supposed to fix? And how do 
I get back to the previous behavior?

- Matthias -

[pygccxml-development] [FT]subst_t class - do we really need to reinvent the wheel?

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

Good morning.
http://docs.python.org/lib/node109.html

Matthias I think you can use the class from the standard library.
Objections?

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

Re: [pygccxml-development] Recent Py++ modifications...

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

On 9/15/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> today I noticed that I get a few failures when I run the unit tests for
> my Maya bindings. Earlier this week these failures have not been there,
> and I actually don't know what's going on here.
>
> One of the tests contains those two lines:
>
>          fv = MFloatVector(0.6, 0.7, 0.8)
>          p = MPoint(fv)
>
> When this code is executed, the second line produces the following error:
>
> TypeError: No registered converter was able to extract a C++ reference
> to type class MVector from this Python object of type MFloatVector
>
>
> The MPoint class is registered like this:
>
>      bp::class_< MPoint >( "MPoint" )
>          .def( bp::init< >() )
>          .def( bp::init< MVector const & >() )
>          .def( bp::init< MFloatVector const & >() )
>          ...
>
> So why does Boost.Python attempt to convert the MFloatVector object into
> a MVector object even though there is a constructor that takes an
> MFloatVector directly?
>
> I'm not aware that I have done any changes to Py++ that could influence
> this behavior, so is it possible that one of the other recent
> modifications to Py++ have caused this? Or does anybody have an idea
> where I would have to look for the source of this problem?
> As I said, a couple of days ago I haven't had those failures....(?)

It is not you. I did small code clean up. Basically I moved some code from
creator_t to relevant decl_wrapper classes. May be I broke somthing. Can you
create small test case?  Do you use latest version from Subversion?

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

Re: [pygccxml-development] [FT]input_t class - new vision.

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

On 9/15/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > from pygccxml import declarations
> > type_transformation_t ?
> >
> > def __init__( self, arg_id, transformation=None ):
> >    self.arg_id = arg_id
> >    if None is self.transformation:
> >        #by default just remove reference
> >        #because I expect this will be applied to immutable passed by ref
> >        self.transformation = lambda type_:
> > declarations.remove_reference( type_ )
> >    elif is_callable( transformation ):
> >        #let user define the transformation
> >        self.transformation = transformation
> >    else:
> >        #user already knows what he wants, so we will just use it
> >        assert isinstance( transformation, declarations.type_t )
> >        self.transformation = lambda type_: transformation
> >
> > transf = type_transformation_t( 1
> >                  , lambda type_: declarations.remove_reference(
> >
> > declarations.remove_const( type_ ) ) )
> >
> > Something like this.
>
> Your example uses an entirely different interface than what is currently
> implemented, but I guess I can see what you want to have.
>
> I agree that functionality like this could be useful, I'd suggest to
> implement it as an additional transformer though and keep input_t still
> around.

As I showed you can implement input_t in terms of
type_transformation_t, but as you
wish.

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

[pygccxml-development] Recent Py++ modifications...

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

Hi,

today I noticed that I get a few failures when I run the unit tests for 
my Maya bindings. Earlier this week these failures have not been there, 
and I actually don't know what's going on here.

One of the tests contains those two lines:

         fv = MFloatVector(0.6, 0.7, 0.8)
         p = MPoint(fv)

When this code is executed, the second line produces the following error:

TypeError: No registered converter was able to extract a C++ reference 
to type class MVector from this Python object of type MFloatVector


The MPoint class is registered like this:

     bp::class_< MPoint >( "MPoint" )
         .def( bp::init< >() )
         .def( bp::init< MVector const & >() )
         .def( bp::init< MFloatVector const & >() )
         ...

So why does Boost.Python attempt to convert the MFloatVector object into 
a MVector object even though there is a constructor that takes an 
MFloatVector directly?

I'm not aware that I have done any changes to Py++ that could influence 
this behavior, so is it possible that one of the other recent 
modifications to Py++ have caused this? Or does anybody have an idea 
where I would have to look for the source of this problem?
As I said, a couple of days ago I haven't had those failures....(?)

- Matthias -

Re: [pygccxml-development] [FT] not exception safe generated code

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

Roman Yakovenko wrote:
> Obviously the code you generate here is not exception safe. I think

You're right. But that code doesn't get generated anyway unless you 
explicitly enable it in the source code. I'm using this just to test 
whether it will work for the Maya bindings at all (I actually just got 
it working today :)
I agree that the final implementation should be more careful and using 
your proposed class for this looks like it might be a good choice.

- Matthias -

Re: [pygccxml-development] [FT]input_t class - new vision.

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

Roman Yakovenko wrote:
> from pygccxml import declarations
> type_transformation_t ?
> 
> def __init__( self, arg_id, transformation=None ):
>    self.arg_id = arg_id
>    if None is self.transformation:
>        #by default just remove reference
>        #because I expect this will be applied to immutable passed by ref
>        self.transformation = lambda type_:
> declarations.remove_reference( type_ )
>    elif is_callable( transformation ):
>        #let user define the transformation
>        self.transformation = transformation
>    else:
>        #user already knows what he wants, so we will just use it
>        assert isinstance( transformation, declarations.type_t )
>        self.transformation = lambda type_: transformation
> 
> transf = type_transformation_t( 1
>                  , lambda type_: declarations.remove_reference(
> 
> declarations.remove_const( type_ ) ) )
> 
> Something like this.

Your example uses an entirely different interface than what is currently 
implemented, but I guess I can see what you want to have.

I agree that functionality like this could be useful, I'd suggest to 
implement it as an additional transformer though and keep input_t still 
around.

- Matthias -

Re: [pygccxml-development] Question about calldef_wrapper_t.argument_name()

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

Roman Yakovenko wrote:
>> So the name can only be empty if gccxml reports it as such. I don't know
>> if this can ever happen or not, but even if it can happen, why is the
>> test from calldef_wrapper_t not moved to the scanner? For example:
>>
>>     if not argument.name:
>>        argument.name = 'arg%d' % len(self.__inst.arguments)
>>
>> Then an argument_t object read from a C++ file would always have a valid
>> name and the method argument_name() wouldn't be required anymore (and
>> other parts of the code would actually also be able to know the name of
>> an argument).
> 
> You can not do it. If you set argument names from the scanner, than Py++
> will generate wrong code - keyword arguments. Take a look on
> code_creators.calldef_t.keywords_args method. Now the answer to your
> question should be clear. 

Uhm, well, sorry, it didn't get clear. What part of keywords_args() 
depends on gccxml producing empty strings? This method just uses the 
'name' attribute without checking if it is empty or not:

       result.append( '("%s")' % arg.name )

But if arg.name is empty, the wrapper code creator replaces it with 
p0,p1,p2, etc. So shouldn't keywords_args() do the same thing instead of 
leaving the string empty? (which is not a valid name for a keyword 
argument anyway)

- Matthias -