pygccxml-development

Re: [pygccxml-development] Re: TypeError: No to_python (by-value) converter found for C++ type: Ogre::ColourValue

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

On 6/1/06, Lakin Wecker <lak...@gm...> wrote:
> Well, this approach solved it for me for ColourValue, Vector3 and a
> few other classes, but I am now getting an error regarding an Enum:
>
> File "CameraTrackingDemo.py", line 2, in ?
>
>     import Ogre as ogre
>
> TypeError: No to_python (by-value) converter found for C++ type:
> Ogre::HardwareBuffer::Usage
>
> I first tried just setting:
>   ogre_ns.class_ ('HardwareBuffer').enumerations
> ('Usage').always_expose_using_scope = True
>
> Then I tried:
>
>   ogre_ns.class_ ('HardwareBuffer').enumerations ('Usage').exclude()
>
> Neither seem to work and I still get the error message.
>
> The situation is as follows:
>
> class Ogre::HardwareBuffer {
> public:
>     enum Usage { ... };
> };
>
> HardwareBuffer is excluded for the time being until I get void *
> wrapped appropriately, but there are other methods on other classes
> that use Ogre::HardwareBuffer::Usage ...
>
> I figure that excluding the HardwareBuffer class should also exclude
> the HardwareBuffer::Usage enumeration. Regardless, I've tried
> excluding it specifically, and still run into that problem ...
>
> As a workaround, I plan on excluding each individual method that uses Usage ...

Wait a minute, you can do something else

HB = mb.class_( 'HardwareBuffer' )
HB.include()
HB.decls().exclude()
HB.enum( 'Usage' ).include()

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

Re: [pygccxml-development] Re: TypeError: No to_python (by-value) converter found for C++ type: Ogre::ColourValue

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

Well, this approach solved it for me for ColourValue, Vector3 and a
few other classes, but I am now getting an error regarding an Enum:

File "CameraTrackingDemo.py", line 2, in ?

    import Ogre as ogre

TypeError: No to_python (by-value) converter found for C++ type:
Ogre::HardwareBuffer::Usage

I first tried just setting:
  ogre_ns.class_ ('HardwareBuffer').enumerations
('Usage').always_expose_using_scope = True

Then I tried:

  ogre_ns.class_ ('HardwareBuffer').enumerations ('Usage').exclude()

Neither seem to work and I still get the error message.

The situation is as follows:

class Ogre::HardwareBuffer {
public:
    enum Usage { ... };
};

HardwareBuffer is excluded for the time being until I get void *
wrapped appropriately, but there are other methods on other classes
that use Ogre::HardwareBuffer::Usage ...

I figure that excluding the HardwareBuffer class should also exclude
the HardwareBuffer::Usage enumeration. Regardless, I've tried
excluding it specifically, and still run into that problem ...

As a workaround, I plan on excluding each individual method that uses Usage ...

Lakin


On 5/31/06, Roman Yakovenko <rom...@gm...> wrote:
> On 5/30/06, Roman Yakovenko <rom...@gm...> wrote:
> > On 5/30/06, Lakin Wecker <lak...@gm...> wrote:
> > > I haven't tried your fix with SVN, I am going to do that right now.
> > > But I had just written this letter, so I'll send it to the list
> > > anyways.  But stay tuned for an update on this situation as well.
> > >
> > > Now, I'm getting this error:
> > >
> > > TypeError: No to_python (by-value) converter found for C++ type: Ogre::Vector3
>
> Solved.
> Error description:
>
> struct Color{
>     static const Color red;
>     ...
>     void do_smth( const Color& other = red );
>     //The error was raised from the line that register this function,
>     //because boost.python tries to create an python object from "red"
>     //but Color class is not registered.
>
> }
>
> Solution
>
> mb = module_builder_t( ... )
> mb.class_( 'Color' ).always_expose_using_scope = True
>
> This will fix the problem. In future py++ will find this situation and
> will generate
> proper code.
>
> --
> Roman Yakovenko
> C++ Python language binding
> http://www.language-binding.net/
>

Re: [pygccxml-development] pyplusplus usage

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

Thanks.  I never mind when people correct my code.  It helps me learn things. :)

Lakin

On 6/1/06, Roman Yakovenko <rom...@gm...> wrote:
> On 6/1/06, Lakin Wecker <lak...@gm...> wrote:
> > I've been trying things like:
> >
> >     Matrix4 = ogre_ns.classes('Matrix4').member_operators('operator[]').exclude()
>
> You don't mind I correct your code a little, right?
>
> ogre_ns.classes('Matrix4').member_operators(symbol='[]').exclude()
>
> > and
> >     ogre_ns.classes('HardwareBuffer').enumerations ('Usage').exclude()
> >
> > But:
> >     ogre_ns.classes('HardwareBuffer').enumerations ('Usage')
> > and
> >     Matrix4 = ogre_ns.classes('Matrix4').member_operators('operator[]')
> >
> > both return a NoneType.  And the result is that the only way I can
> > achieve this effect is:
> >
> >     def exclude_operator_index (decl):
> >         value = decl.name.startswith('operator[]')
> >         if value: decl.exclude()
> >         return value
> >     ogre_ns.classes('Matrix4').member_operators (exclude_operator_index)
> >     ogre_ns.classes('Matrix3').member_operators (exclude_operator_index)
> >
> >     def exclude_usage (decl):
> >         value = decl.name.startswith('Usage')
> >         if value: decl.exclude()
> >         return value
> >     ogre_ns.classes('HardwareBuffer').enumerations (exclude_usage)
> >
> >
> > I'm not sure if this is a similar issue to one of the ones that Allen
> > was talking about, but it would be nice to be able to use the first
> > way.
>
> Yes, it is the same issue. But in you case you have simple work around.
> The first query don't have to be multiple query:
>
> ogre_ns.class_('Matrix4').member_operators(symbol='[]').exclude()
> ogre_ns.class_('HardwareBuffer').enumerations ('Usage')
> -------------^^^^^^ class_ instead of classes
>
> This will work for you.
>
> > Lakin
>
>
> --
> Roman Yakovenko
> C++ Python language binding
> http://www.language-binding.net/
>

Re: [pygccxml-development] pyplusplus usage

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

On 6/1/06, Lakin Wecker <lak...@gm...> wrote:
> I've been trying things like:
>
>     Matrix4 = ogre_ns.classes('Matrix4').member_operators('operator[]').exclude()

You don't mind I correct your code a little, right?

ogre_ns.classes('Matrix4').member_operators(symbol='[]').exclude()

> and
>     ogre_ns.classes('HardwareBuffer').enumerations ('Usage').exclude()
>
> But:
>     ogre_ns.classes('HardwareBuffer').enumerations ('Usage')
> and
>     Matrix4 = ogre_ns.classes('Matrix4').member_operators('operator[]')
>
> both return a NoneType.  And the result is that the only way I can
> achieve this effect is:
>
>     def exclude_operator_index (decl):
>         value = decl.name.startswith('operator[]')
>         if value: decl.exclude()
>         return value
>     ogre_ns.classes('Matrix4').member_operators (exclude_operator_index)
>     ogre_ns.classes('Matrix3').member_operators (exclude_operator_index)
>
>     def exclude_usage (decl):
>         value = decl.name.startswith('Usage')
>         if value: decl.exclude()
>         return value
>     ogre_ns.classes('HardwareBuffer').enumerations (exclude_usage)
>
>
> I'm not sure if this is a similar issue to one of the ones that Allen
> was talking about, but it would be nice to be able to use the first
> way.

Yes, it is the same issue. But in you case you have simple work around.
The first query don't have to be multiple query:

ogre_ns.class_('Matrix4').member_operators(symbol='[]').exclude()
ogre_ns.class_('HardwareBuffer').enumerations ('Usage')
-------------^^^^^^ class_ instead of classes

This will work for you.

> Lakin


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

[pygccxml-development] pyplusplus usage

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

I've been trying things like:

    Matrix4 = ogre_ns.classes('Matrix4').member_operators('operator[]').exclude()
and
    ogre_ns.classes('HardwareBuffer').enumerations ('Usage').exclude()

But:
    ogre_ns.classes('HardwareBuffer').enumerations ('Usage')
and
    Matrix4 = ogre_ns.classes('Matrix4').member_operators('operator[]')

both return a NoneType.  And the result is that the only way I can
achieve this effect is:

    def exclude_operator_index (decl):
        value = decl.name.startswith('operator[]')
        if value: decl.exclude()
        return value
    ogre_ns.classes('Matrix4').member_operators (exclude_operator_index)
    ogre_ns.classes('Matrix3').member_operators (exclude_operator_index)

    def exclude_usage (decl):
        value = decl.name.startswith('Usage')
        if value: decl.exclude()
        return value
    ogre_ns.classes('HardwareBuffer').enumerations (exclude_usage)


I'm not sure if this is a similar issue to one of the ones that Allen
was talking about, but it would be nice to be able to use the first
way.

Lakin

Re: [pygccxml-development] Two problems

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

On 6/1/06, Lakin Wecker <lak...@gm...> wrote:
> I'll look into adding the same functions to Matrix4.  I'm sure Ogre
> will accept the patch.  However, in the mean time I can avoid those
> functions ...

boost.python has nice feature. It allows you to expose free function as a class
method.

class Matrix4{...};

Vector4 get_column( Matrix4& m, int i ){...}

If you expose both declaration, then from Python you can write:

import Ogre

Ogre.Matrix4.GetColumn = Ogre.get_column

Every user of Matrix4 in Python will not note the difference.

You can take a look on pyplusplus_dev/examples/boost_dev rational example.
I use this trick there

> In the end I'd like to have a more pythonic way of accessing
> Matrix{4|3}, Vector{4|3|2}, Quaternion, and ColourValue ....
> basically by interchanging python lists/tuples etc.

I thought about this. There are few ways to achieve the result. The
idea is simple:
Every time function takes as argument M[3|4] or V[2|3|4] It should able to take
list or tuple. So you will need to write code that converts. You can
choose, where to
write the code in C++ or in Python. The C++ version will be a little
faster, but it is much convenient to develop the functionality in
Python. In Python there are 2 ways to implement what you want:
1. Simple approach: every relevant function should be redefined in Python and
implements conversion.
2. Another idea is to use decorators. In Israel, at Python user group meeting,
   somebody solve problem similar to our using generators.

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

Re: [pygccxml-development] Two problems

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

I'll look into adding the same functions to Matrix4.  I'm sure Ogre
will accept the patch.  However, in the mean time I can avoid those
functions ...

In the end I'd like to have a more pythonic way of accessing
Matrix{4|3}, Vector{4|3|2}, Quaternion, and ColourValue ....
basically by interchanging python lists/tuples etc.

Thanks

Lakin

On 5/31/06, Roman Yakovenko <rom...@gm...> wrote:
> On 5/31/06, Lakin Wecker <lak...@gm...> wrote:
> > In finishing the Ogre bindings, I have run into two problems (one is
> > caused by the other).
> >
> > 1. First, I get an error when compiling Matrix4.cpp ..
>
> I think, that the error caused by exported operator[].
>
> By the way in this case call policies could be
> return_inernal_reference, but ....
> There is another problem here:  those functions have next return type:
> [const] float *. The expression float* could not be translated to
> Python and manual
> wrapper is required. I took a look on Matrix3 class, it defines [S|G]etColumn.
> functions that returns Vector3 class. May be it will be possible to
> add such functions
> to Matrix4 class [G|S]Column and [G|S]Row?
>
> ( By the way I commeted the fix right now )
>
> --
> Roman Yakovenko
> C++ Python language binding
> http://www.language-binding.net/
>

Re: [pygccxml-development] Two problems

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

On 5/31/06, Lakin Wecker <lak...@gm...> wrote:
> In finishing the Ogre bindings, I have run into two problems (one is
> caused by the other).
>
> 1. First, I get an error when compiling Matrix4.cpp ..

I think, that the error caused by exported operator[].

By the way in this case call policies could be
return_inernal_reference, but ....
There is another problem here:  those functions have next return type:
[const] float *. The expression float* could not be translated to
Python and manual
wrapper is required. I took a look on Matrix3 class, it defines [S|G]etColumn.
functions that returns Vector3 class. May be it will be possible to
add such functions
to Matrix4 class [G|S]Column and [G|S]Row?

( By the way I commeted the fix right now )

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

Re: [pygccxml-development] Two problems

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

On 5/31/06, Lakin Wecker <lak...@gm...> wrote:
> In finishing the Ogre bindings, I have run into two problems (one is
> caused by the other).
>
> 1. First, I get an error when compiling Matrix4.cpp ..

I will take a look and give you an answer

> 2.  But if I take Matrix4 out, (just so I can test the basics of the
> bindings), I get the following:
> build/TagPoint.pypp.cpp:94:   instantiated from here
> /usr/include/boost/python/detail/invoke.hpp:88: error: no match for
> call to '(const
> boost::python::detail::specify_a_return_value_policy_to_wrap_functions_returning<const
> Ogre::Matrix4&>) (const Ogre::Matrix4&)'

If you does not register Matrix4 you can use API that takes it as argument
or returns it.

> but, I have the following python code in my generate script, which (if
> I understand correctly) should take care of it:
>
> This code doesn't work, it returns 0 results:
>    matrix4 = ogre_ns.calldefs(return_type="const Ogre::Matrix4&")
----------------------------------------------------------^^^^^^^^^^^^^

I am not sure about this. The best way to do this is to find some function that
return const Ogre::Matrix4& and then
    print func.return_type.decl_string

After this you can use the printed text in queries. In this case I
guess it will
be written "Ogre::Matrix const &", but I could be wrong


>    matrix4.call_policies = call_policies.return_value_policy(
>                 call_policies.reference_existing_object )
>
> This code works for nearly all other pointer/reference types, but I
> still get that error?!
>     mem_funs = ogre_ns.calldefs()
>     for mem_fun in mem_funs:
>         if mem_fun.call_policies:
>             continue
>         if declarations.is_pointer (mem_fun.return_type) \
>             or declarations.is_reference (mem_fun.return_type):
>             mem_fun.call_policies = call_policies.return_value_policy(
>                 call_policies.reference_existing_object )

I don't see any problem with the code.

> Lakin

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

Re: [pygccxml-development] Re: Two problems

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

On 5/31/06, Lakin Wecker <lak...@gm...> wrote:
> Sorry, my mistake,  the following code produces an exception:
> > This code doesn't work, it returns 0 results:
> >    matrix4 = ogre_ns.calldefs(return_type="const Ogre::Matrix4&")
> >    matrix4.call_policies = call_policies.return_value_policy(
> >                 call_policies.reference_existing_object )
> Traceback (most recent call last):
>   File "generate_code.py", line 140, in ?
>     set_call_policies (mb)
>   File "generate_code.py", line 118, in set_call_policies
>     matrix4 = ogre_ns.calldefs(return_type="Ogre::Matrix4& const")
>   File "/home/lakin/Documents/non-backup/Software/Compile/pygccxml/pygccxml_dev/pygccxml/declarations/scopedef.py",
> line 384, in calldefs
>     , allow_empty=allow_empty)
>   File "/home/lakin/Documents/non-backup/Software/Compile/pygccxml/pygccxml_dev/pygccxml/declarations/scopedef.py",
> line 295, in _find_multiple
>     found = matcher_module.matcher.find( matcher, decls, False )
>   File "/home/lakin/Documents/non-backup/Software/Compile/pygccxml/pygccxml_dev/pygccxml/declarations/matcher.py",
> line 35, in find
>     return filter( decl_matcher, where )
>   File "/home/lakin/Documents/non-backup/Software/Compile/pygccxml/pygccxml_dev/pygccxml/declarations/filters.py",
> line 339, in __call__
>     if not None is self.return_type \
>   File "/home/lakin/Documents/non-backup/Software/Compile/pygccxml/pygccxml_dev/pygccxml/declarations/filters.py",
> line 360, in __compare_types
>     if type_or_str != type.decl_string:
> AttributeError: 'NoneType' object has no attribute 'decl_string'

Thanks for bug reporting. I think I found it and fixed. I will commit
the change in few
minutes.

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

[pygccxml-development] Two problems

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

In finishing the Ogre bindings, I have run into two problems (one is
caused by the other).

1. First, I get an error when compiling Matrix4.cpp ..

 lakin@zedd:~/Desktop/OgrePython$ g++ `pkg-config --cflags OGRE`
-I/usr/include/python2.4 -D"BOOST_PYTHON_MAX_ARITY=17" -O0 -g -I./
-fPIC -Ibuild -c -o build/Matrix4.pypp.os build/Matrix4.pypp.cpp
/usr/include/boost/python/object/make_instance.hpp: In static member
function 'static PyObject*
boost::python::objects::make_instance_impl<T, Holder,
Derived>::execute(Arg&) [with Arg = float*, T = float, Holder =
boost::python::objects::pointer_holder<float*, float>, Derived =
boost::python::objects::make_ptr_instance<float,
boost::python::objects::pointer_holder<float*, float> >]':
/usr/include/boost/python/to_python_indirect.hpp:96:   instantiated
from 'static PyObject*
boost::python::detail::make_reference_holder::execute(T*) [with T =
float]'
/usr/include/boost/python/to_python_indirect.hpp:60:   instantiated
from 'PyObject* boost::python::to_python_indirect<T,
MakeHolder>::execute(const U&, mpl_::false_) const [with U = float, T
= const Ogre::Real* const, MakeHolder =
boost::python::detail::make_reference_holder]'
/usr/include/boost/python/to_python_indirect.hpp:48:   instantiated
from 'PyObject* boost::python::to_python_indirect<T,
MakeHolder>::execute(U*, mpl_::true_) const [with U = const
Ogre::Real, T = const Ogre::Real* const, MakeHolder =
boost::python::detail::make_reference_holder]'
/usr/include/boost/python/to_python_indirect.hpp:37:   instantiated
from 'PyObject* boost::python::to_python_indirect<T,
MakeHolder>::operator()(const U&) const [with U = const Ogre::Real*, T
= const Ogre::Real* const, MakeHolder =
boost::python::detail::make_reference_holder]'
/usr/include/boost/python/detail/invoke.hpp:88:   instantiated from
'PyObject* boost::python::detail::invoke(boost::python::detail::invoke_tag_<false,
true>, const RC&, F&, TC&, AC0&) [with RC =
boost::python::to_python_indirect<const Ogre::Real* const,
boost::python::detail::make_reference_holder>, F = const Ogre::Real*
const (Ogre::Matrix4::*)(size_t)const, TC =
boost::python::arg_from_python<Ogre::Matrix4&>, AC0 =
boost::python::arg_from_python<long unsigned int>]'
/usr/include/boost/python/detail/caller.hpp:199:   instantiated from
'PyObject* boost::python::detail::caller_arity<2u>::impl<F, Policies,
Sig>::operator()(PyObject*, PyObject*) [with F = const Ogre::Real*
const (Ogre::Matrix4::*)(size_t)const, Policies =
boost::python::return_internal_reference<1ul,
boost::python::default_call_policies>, Sig = boost::mpl::vector3<const
Ogre::Real* const, Ogre::Matrix4&, long unsigned int>]'
/usr/include/boost/python/object/py_function.hpp:38:   instantiated
from 'PyObject*
boost::python::objects::caller_py_function_impl<Caller>::operator()(PyObject*,
PyObject*) [with Caller = boost::python::detail::caller<const
Ogre::Real* const (Ogre::Matrix4::*)(size_t)const,
boost::python::return_internal_reference<1ul,
boost::python::default_call_policies>, boost::mpl::vector3<const
Ogre::Real* const, Ogre::Matrix4&, long unsigned int> >]'
build/Matrix4.pypp.cpp:113:   instantiated from here
/usr/include/boost/python/object/make_instance.hpp:24: error: invalid
application of 'sizeof' to incomplete type
'boost::STATIC_ASSERTION_FAILURE<false>'


2.  But if I take Matrix4 out, (just so I can test the basics of the
bindings), I get the following:
build/TagPoint.pypp.cpp:94:   instantiated from here
/usr/include/boost/python/detail/invoke.hpp:88: error: no match for
call to '(const
boost::python::detail::specify_a_return_value_policy_to_wrap_functions_returning<const
Ogre::Matrix4&>) (const Ogre::Matrix4&)'

but, I have the following python code in my generate script, which (if
I understand correctly) should take care of it:

This code doesn't work, it returns 0 results:
   matrix4 = ogre_ns.calldefs(return_type="const Ogre::Matrix4&")
   matrix4.call_policies = call_policies.return_value_policy(
                call_policies.reference_existing_object )

This code works for nearly all other pointer/reference types, but I
still get that error?!
    mem_funs = ogre_ns.calldefs()
    for mem_fun in mem_funs:
        if mem_fun.call_policies:
            continue
        if declarations.is_pointer (mem_fun.return_type) \
            or declarations.is_reference (mem_fun.return_type):
            mem_fun.call_policies = call_policies.return_value_policy(
                call_policies.reference_existing_object )

Lakin

[pygccxml-development] Re: Two problems

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

Sorry, my mistake,  the following code produces an exception:
> This code doesn't work, it returns 0 results:
>    matrix4 = ogre_ns.calldefs(return_type="const Ogre::Matrix4&")
>    matrix4.call_policies = call_policies.return_value_policy(
>                 call_policies.reference_existing_object )
Traceback (most recent call last):
  File "generate_code.py", line 140, in ?
    set_call_policies (mb)
  File "generate_code.py", line 118, in set_call_policies
    matrix4 = ogre_ns.calldefs(return_type="Ogre::Matrix4& const")
  File "/home/lakin/Documents/non-backup/Software/Compile/pygccxml/pygccxml_dev/pygccxml/declarations/scopedef.py",
line 384, in calldefs
    , allow_empty=allow_empty)
  File "/home/lakin/Documents/non-backup/Software/Compile/pygccxml/pygccxml_dev/pygccxml/declarations/scopedef.py",
line 295, in _find_multiple
    found = matcher_module.matcher.find( matcher, decls, False )
  File "/home/lakin/Documents/non-backup/Software/Compile/pygccxml/pygccxml_dev/pygccxml/declarations/matcher.py",
line 35, in find
    return filter( decl_matcher, where )
  File "/home/lakin/Documents/non-backup/Software/Compile/pygccxml/pygccxml_dev/pygccxml/declarations/filters.py",
line 339, in __call__
    if not None is self.return_type \
  File "/home/lakin/Documents/non-backup/Software/Compile/pygccxml/pygccxml_dev/pygccxml/declarations/filters.py",
line 360, in __compare_types
    if type_or_str != type.decl_string:
AttributeError: 'NoneType' object has no attribute 'decl_string'

Lakin

Re: [pygccxml-development] Abstract Classes

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

On 5/31/06, Lakin Wecker <lak...@gm...> wrote:
> My bad.  It _does_ seem to work out of the box.  The problem was that
> I had excluded a parent class which had pure virtual functions,
> because it had some void* stuff that I was going to deal with later
> ...
>
> Sorry for the confusion and noise.

You are not completly wrong. In most cases, py++ guide-line - "user
knows better".
But there are cases, when py++ say - "no way, he made a mistake". Your use case
is a second one. In this case py++ should at least generate some
warning in source
file. Can you post small example of code? I will add it to my todo list.

Thanks

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

Re: [pygccxml-development] mdecl and methods that return values

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

On 5/31/06, Allen Bierbaum <al...@vr...> wrote:
> > class X{ X(){} };
> >
> > global_ns['X'].meber_functions()
> >
> > Will raise an error: AttributeError: 'constructor_t' object has no
> > attribute '__getitem__'
>
> I would have to look into this further, but what is calling __getitem__
> on a constructor_t object?

call_redirector_t.__call__, because: global_ns['X'] is equivalent to
get all declarations
that have name 'X' class and its constructors match the query
I suggest you to debug small example and see what happens.

> > The query breaks precondition of
> > call_redirector_t.__call__ : I assume that all functions will return
> > same type
> > We don't have list of same objects. So mdecl_wrapper_t.__getitem__ can
> > not
> > return call_redirector_t( '__getitem__', self.decls)(index) :-(.
> >
> Maybe the precondition should be modified slightly.  Maybe the
> precondition should be that all objects returned can be wrapped with in
> a mdecl.  So the preconditions would be the same as those for creating
> an mdecl.  And unless I am missing something, an mdecl can wrap objects
> of different types.
>
> For example a call like:
>
> mfs = my_class.member_functions()
>
> Will return an mdecl that wraps constructors, calldefs, and any other
> types of members.

This is how it works right now. The main problem is how to define precondition.

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

Re: [pygccxml-development] Abstract Classes

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

My bad.  It _does_ seem to work out of the box.  The problem was that
I had excluded a parent class which had pure virtual functions,
because it had some void* stuff that I was going to deal with later
...

Sorry for the confusion and noise.


lakin

On 5/31/06, Lakin Wecker <lak...@gm...> wrote:
> Maybe I was not clear.  I'm talking about pure virtual functions.  You
> had mentioned at some point that I may have to take care of these in a
> certain way.
>
> For instance:
>
> g++ `pkg-config --cflags OGRE` -I/usr/include/python2.4
> -DBOOST_PYTHON_MAX_ARITY=16 -O0 -g -I./ -fPIC -Ibuild -c -o
> build/RenderWindow.pypp.os build/RenderWindow.pypp.cpp
> /usr/include/boost/python/object/value_holder.hpp: In instantiation of
> 'boost::python::objects::value_holder<RenderWindow_wrapper>':
> /usr/include/boost/type_traits/alignment_of.hpp:52:   instantiated
> from 'const size_t
> boost::detail::alignment_of_impl<boost::python::objects::value_holder<RenderWindow_wrapper>
> >::value'
> /usr/include/boost/type_traits/alignment_of.hpp:61:   instantiated
> from 'boost::alignment_of<boost::python::objects::value_holder<RenderWindow_wrapper>
> >'
> /usr/include/boost/python/object/instance.hpp:30:   instantiated from
> 'boost::python::objects::instance<boost::python::objects::value_holder<RenderWindow_wrapper>
> >'
> /usr/include/boost/python/object/instance.hpp:44:   instantiated from
> 'const size_t boost::python::objects::additional_instance_size<boost::python::objects::value_holder<RenderWindow_wrapper>
> >::value'
> /usr/include/boost/python/class.hpp:499:   instantiated from 'void
> boost::python::class_<T, X1, X2, X3>::initialize(const DefVisitor&)
> [with DefVisitor = boost::python::init<mpl_::void_, mpl_::void_,
> mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_,
> mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_,
> mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_>, W =
> RenderWindow_wrapper, X1 = boost::noncopyable_::noncopyable, X2 =
> boost::python::detail::not_specified, X3 =
> boost::python::detail::not_specified]'
> /usr/include/boost/python/class.hpp:629:   instantiated from
> 'boost::python::class_<T, X1, X2, X3>::class_(const char*, const
> char*) [with W = RenderWindow_wrapper, X1 =
> boost::noncopyable_::noncopyable, X2 =
> boost::python::detail::not_specified, X3 =
> boost::python::detail::not_specified]'
> build/RenderWindow.pypp.cpp:158:   instantiated from here
> /usr/include/boost/python/object/value_holder.hpp:66: error: cannot
> declare field 'boost::python::objects::value_holder<RenderWindow_wrapper>::m_held'
> to be of abstract type 'RenderWindow_wrapper'
> build/RenderWindow.pypp.cpp:18: note:   because the following virtual
> functions are pure within 'RenderWindow_wrapper':
> /home/lakin/.local/include/OGRE/OgreRenderTarget.h:267: note:  virtual
> void Ogre::RenderTarget::writeContentsToFile(const Ogre::String&)
> /home/lakin/.local/include/OGRE/OgreRenderTarget.h:273: note:  virtual
> bool Ogre::RenderTarget::requiresTextureFlipping() cons
>
>
> Lakin
>
> On 5/30/06, Roman Yakovenko <rom...@gm...> wrote:
> > On 5/31/06, Lakin Wecker <lak...@gm...> wrote:
> > > In Ogre, a frequent design used is to define an abstract base class,
> > > (Say RenderWindow).  Along with a Manager/Factory that creates that
> > > window for you.  Then the platform specific implementations of those
> > > classes are built to actually do the work.
> > >
> > > However, the API dictates that you ask the Manager/Factory for an
> > > implementation of RenderWindow (you don't care which), and you then
> > > use it as a generic RenderWindow interface.
> > >
> > >
> > > In py++, how do I model this?  I don't want to expose the platform
> > > specific implementations of the classes, as they're not needed. But I
> > > do need to somehow let the python run time know about the
> > > AbstractClass so that when I ask the Manager for one, I can use it
> > > from Python.
> > >
> > > When I directly include the class in the ouput, I get a compile error
> > > because of the lack of implementations ... of some methods.
> >
> > I could be wrong, but it should work out of the box. I will check this at home.
> >
> > > Anyways, I'm going to sleep now.  See you all in a few hours.
> >
> > Good night
> >
> > > Lakin
> >
> >
> > --
> > Roman Yakovenko
> > C++ Python language binding
> > http://www.language-binding.net/
> >
>

Re: [pygccxml-development] mdecl and methods that return values

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

Roman Yakovenko wrote:

> On 5/30/06, Roman Yakovenko <rom...@gm...> wrote:
>
>> Allen, I tried the patch and there are some errors in unit tests.
>> I will try to fix it tommorrow and commit. I will let you know.
>
>
> 1. __getitem__ has been changed a little:
>
> def __getitem__( self, index ):
>        """provides access to declaration.
>           If passed a standard index, then return contained decl.
>           Else call the getitem method of contained decls.
>        """
>        if isinstance(index, ( int, slice ) ):
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>            return self.decls[index]
>        else:
>            return call_redirector_t( '__getitem__', self.decls)(index)
>
> slice has been added.
>
> But still patch does not work:
>
> class X{ X(){} };
>
> global_ns['X'].meber_functions()
>
> Will raise an error: AttributeError: 'constructor_t' object has no
> attribute '__getitem__'

I would have to look into this further, but what is calling __getitem__ 
on a constructor_t object?

It looks like __getitem__ is being called on a namespace, but that 
should be allowed since a namespace is a scopedef_t.

> The query breaks precondition of
> call_redirector_t.__call__ : I assume that all functions will return 
> same type
> We don't have list of same objects. So mdecl_wrapper_t.__getitem__ can 
> not
> return call_redirector_t( '__getitem__', self.decls)(index) :-(.
>
Maybe the precondition should be modified slightly.  Maybe the 
precondition should be that all objects returned can be wrapped with in 
a mdecl.  So the preconditions would be the same as those for creating 
an mdecl.  And unless I am missing something, an mdecl can wrap objects 
of different types. 

For example a call like:

mfs = my_class.member_functions()

Will return an mdecl that wraps constructors, calldefs, and any other 
types of members.

-Allen

> Without good definition I don't know how to fix this. So, if you don't
> mind I will not apply
> the patch.
>

Re: [pygccxml-development] Abstract Classes

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

Maybe I was not clear.  I'm talking about pure virtual functions.  You
had mentioned at some point that I may have to take care of these in a
certain way.

For instance:

g++ `pkg-config --cflags OGRE` -I/usr/include/python2.4
-DBOOST_PYTHON_MAX_ARITY=16 -O0 -g -I./ -fPIC -Ibuild -c -o
build/RenderWindow.pypp.os build/RenderWindow.pypp.cpp
/usr/include/boost/python/object/value_holder.hpp: In instantiation of
'boost::python::objects::value_holder<RenderWindow_wrapper>':
/usr/include/boost/type_traits/alignment_of.hpp:52:   instantiated
from 'const size_t
boost::detail::alignment_of_impl<boost::python::objects::value_holder<RenderWindow_wrapper>
>::value'
/usr/include/boost/type_traits/alignment_of.hpp:61:   instantiated
from 'boost::alignment_of<boost::python::objects::value_holder<RenderWindow_wrapper>
>'
/usr/include/boost/python/object/instance.hpp:30:   instantiated from
'boost::python::objects::instance<boost::python::objects::value_holder<RenderWindow_wrapper>
>'
/usr/include/boost/python/object/instance.hpp:44:   instantiated from
'const size_t boost::python::objects::additional_instance_size<boost::python::objects::value_holder<RenderWindow_wrapper>
>::value'
/usr/include/boost/python/class.hpp:499:   instantiated from 'void
boost::python::class_<T, X1, X2, X3>::initialize(const DefVisitor&)
[with DefVisitor = boost::python::init<mpl_::void_, mpl_::void_,
mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_,
mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_,
mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_>, W =
RenderWindow_wrapper, X1 = boost::noncopyable_::noncopyable, X2 =
boost::python::detail::not_specified, X3 =
boost::python::detail::not_specified]'
/usr/include/boost/python/class.hpp:629:   instantiated from
'boost::python::class_<T, X1, X2, X3>::class_(const char*, const
char*) [with W = RenderWindow_wrapper, X1 =
boost::noncopyable_::noncopyable, X2 =
boost::python::detail::not_specified, X3 =
boost::python::detail::not_specified]'
build/RenderWindow.pypp.cpp:158:   instantiated from here
/usr/include/boost/python/object/value_holder.hpp:66: error: cannot
declare field 'boost::python::objects::value_holder<RenderWindow_wrapper>::m_held'
to be of abstract type 'RenderWindow_wrapper'
build/RenderWindow.pypp.cpp:18: note:   because the following virtual
functions are pure within 'RenderWindow_wrapper':
/home/lakin/.local/include/OGRE/OgreRenderTarget.h:267: note:  virtual
void Ogre::RenderTarget::writeContentsToFile(const Ogre::String&)
/home/lakin/.local/include/OGRE/OgreRenderTarget.h:273: note:  virtual
bool Ogre::RenderTarget::requiresTextureFlipping() cons


Lakin

On 5/30/06, Roman Yakovenko <rom...@gm...> wrote:
> On 5/31/06, Lakin Wecker <lak...@gm...> wrote:
> > In Ogre, a frequent design used is to define an abstract base class,
> > (Say RenderWindow).  Along with a Manager/Factory that creates that
> > window for you.  Then the platform specific implementations of those
> > classes are built to actually do the work.
> >
> > However, the API dictates that you ask the Manager/Factory for an
> > implementation of RenderWindow (you don't care which), and you then
> > use it as a generic RenderWindow interface.
> >
> >
> > In py++, how do I model this?  I don't want to expose the platform
> > specific implementations of the classes, as they're not needed. But I
> > do need to somehow let the python run time know about the
> > AbstractClass so that when I ask the Manager for one, I can use it
> > from Python.
> >
> > When I directly include the class in the ouput, I get a compile error
> > because of the lack of implementations ... of some methods.
>
> I could be wrong, but it should work out of the box. I will check this at home.
>
> > Anyways, I'm going to sleep now.  See you all in a few hours.
>
> Good night
>
> > Lakin
>
>
> --
> Roman Yakovenko
> C++ Python language binding
> http://www.language-binding.net/
>

Re: [pygccxml-development] Re: TypeError: No to_python (by-value) converter found for C++ type: Ogre::ColourValue

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

On 5/30/06, Roman Yakovenko <rom...@gm...> wrote:
> On 5/30/06, Lakin Wecker <lak...@gm...> wrote:
> > I haven't tried your fix with SVN, I am going to do that right now.
> > But I had just written this letter, so I'll send it to the list
> > anyways.  But stay tuned for an update on this situation as well.
> >
> > Now, I'm getting this error:
> >
> > TypeError: No to_python (by-value) converter found for C++ type: Ogre::Vector3

Solved.
Error description:

struct Color{
    static const Color red;
    ...
    void do_smth( const Color& other = red );
    //The error was raised from the line that register this function,
    //because boost.python tries to create an python object from "red"
    //but Color class is not registered.

}

Solution

mb = module_builder_t( ... )
mb.class_( 'Color' ).always_expose_using_scope = True

This will fix the problem. In future py++ will find this situation and
will generate
proper code.

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

Re: [pygccxml-development] Abstract Classes

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

On 5/31/06, Lakin Wecker <lak...@gm...> wrote:
> In Ogre, a frequent design used is to define an abstract base class,
> (Say RenderWindow).  Along with a Manager/Factory that creates that
> window for you.  Then the platform specific implementations of those
> classes are built to actually do the work.
>
> However, the API dictates that you ask the Manager/Factory for an
> implementation of RenderWindow (you don't care which), and you then
> use it as a generic RenderWindow interface.
>
>
> In py++, how do I model this?  I don't want to expose the platform
> specific implementations of the classes, as they're not needed. But I
> do need to somehow let the python run time know about the
> AbstractClass so that when I ask the Manager for one, I can use it
> from Python.
>
> When I directly include the class in the ouput, I get a compile error
> because of the lack of implementations ... of some methods.

I could be wrong, but it should work out of the box. I will check this at home.

> Anyways, I'm going to sleep now.  See you all in a few hours.

Good night

> Lakin


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

[pygccxml-development] Abstract Classes

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

In Ogre, a frequent design used is to define an abstract base class,
(Say RenderWindow).  Along with a Manager/Factory that creates that
window for you.  Then the platform specific implementations of those
classes are built to actually do the work.

However, the API dictates that you ask the Manager/Factory for an
implementation of RenderWindow (you don't care which), and you then
use it as a generic RenderWindow interface.


In py++, how do I model this?  I don't want to expose the platform
specific implementations of the classes, as they're not needed. But I
do need to somehow let the python run time know about the
AbstractClass so that when I ask the Manager for one, I can use it
from Python.

When I directly include the class in the ouput, I get a compile error
because of the lack of implementations ... of some methods.

Anyways, I'm going to sleep now.  See you all in a few hours.

Lakin

Re: [pygccxml-development] mdecl and methods that return values

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

On 5/30/06, Roman Yakovenko <rom...@gm...> wrote:
> Allen, I tried the patch and there are some errors in unit tests.
> I will try to fix it tommorrow and commit. I will let you know.

1. __getitem__ has been changed a little:

def __getitem__( self, index ):
        """provides access to declaration.
           If passed a standard index, then return contained decl.
           Else call the getitem method of contained decls.
        """
        if isinstance(index, ( int, slice ) ):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            return self.decls[index]
        else:
            return call_redirector_t( '__getitem__', self.decls)(index)

slice has been added.

But still patch does not work:

class X{ X(){} };

global_ns['X'].meber_functions()

Will raise an error: AttributeError: 'constructor_t' object has no
attribute '__getitem__'
The query breaks precondition of
call_redirector_t.__call__ : I assume that all functions will return same type
We don't have list of same objects. So mdecl_wrapper_t.__getitem__ can not
return call_redirector_t( '__getitem__', self.decls)(index) :-(.

Without good definition I don't know how to fix this. So, if you don't
mind I will not apply
the patch.

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

[pygccxml-development] Re: typedef lookup feature from long ago...

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

On 5/31/06, Allen Bierbaum <al...@vr...> wrote:
> Roman:
>
> Taking into account that you will be out of contact soon, there is one
> feature I know I am going to need that I used in the old prototype API.
> I must apologize that I don't remember the exact details, but what it
> boiled down to was being able to lookup a full resolved type from a typedef.
>
> So if I had something like:
>
> typedef really_complex< nested<int>, ugly<long>, 56> simple_t;
>
> I would need to be able to look it up from simple_t to get the type
> information.  It is the mTypeDefMap inside the old pypp_api (it is still
> in experimental).
>
> The code to look at is in parse() at the end:
>
>       typedef_decls = declarations.make_flatten(parsed_decls)
>       typedef_decls = decls = filter( lambda x: (isinstance( x,
> declarations.typedef_t ) and
>                                                  not
> x.name.startswith('__') and
>                                                  x.location.file_name !=
> "<internal>")
>                                       , typedef_decls )
>
>       self.mTypeDefMap = {}
>       for d in typedef_decls:
>          type_def_name = d.name
>          full_name = declarations.full_name(d)
>          if full_name.startswith("::"):    # Remove the base namespace
>             full_name = full_name[2:]
>          real_type_name = d.type.decl_string
>          if real_type_name.startswith("::"):    # Remove base namespace
>             real_type_name = real_type_name[2:]
>          self.mTypeDefMap[full_name] = real_type_name
>
>
> So my question is, do I have another "easy" way to do this with the
> current API?

Typedef class has 2 properties: name and type. I believe type is what
you are looking for.

> I probably won't need it until this weekend or the beginning of next
> week, but if you are going to get busy I wanted to ask before you have
> better things to do then answer e-mails from pesky people like me. :)

:-)

> -Allen
>
>


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

Re: [pygccxml-development] Patch to let gccxml work

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

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

Re: [pygccxml-development] Patch to let gccxml work

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

On 5/31/06, Allen Bierbaum <al...@vr...> wrote:
>
> >
> > It could be nice to have those "nasty" things within regression.
> > I think I will implement next solution:
> > 1. you will send me a patch
> > 2. I will add new variable to config_t class:
> >    ignore_gccxml_output
> >    By default it will be false. So you will have to turn it on
> > explicitly.
> > 3. The code that actually runs gccxml will be changed, to take into
> > account
> >    this variable?
> >
> > Is this good for you? Allen, I am sorry, but it could be nice if you will
> > contribute the code.
> >
> > Thanks
> >
> I have attached a patch that implements what you are describing.  It is
> not pretty but it works for me and should allow other people to ignore
> gccxml output as well.
>
> Let me know what you think.

Looks nice, exactly what I thought. I will apply it tommorrow.

Thank you.


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

Re: [pygccxml-development] Patch to let gccxml work

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

>
> It could be nice to have those "nasty" things within regression.
> I think I will implement next solution:
> 1. you will send me a patch
> 2. I will add new variable to config_t class:
>    ignore_gccxml_output
>    By default it will be false. So you will have to turn it on 
> explicitly.
> 3. The code that actually runs gccxml will be changed, to take into 
> account
>    this variable?
>
> Is this good for you? Allen, I am sorry, but it could be nice if you will
> contribute the code.
>
> Thanks
>
I have attached a patch that implements what you are describing.  It is 
not pretty but it works for me and should allow other people to ignore 
gccxml output as well.

Let me know what you think.

-Allen