pygccxml-development

[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] 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] 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 -

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:
>> 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:
> 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/