pygccxml-development

[pygccxml-development] Indexing suite exception

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

Hi,

after being too busy the last couple of weeks to check out the new 
pyplusplus stuff (and move the experimental stuff to the contrib 
directory) I finally did an update on the code and now I get the below 
exception when I try to create the Maya bindings. My script is still 
unchanged and has worked with previous versions. I also haven't 
specified anything that has to do with the indexing suite, so I would 
have expected not to trigger anything that is related to this feature.

Is this a bug in pyplusplus or do I have to specify anything related to 
this in my driver script?

- Matthias -


Traceback (most recent call last):
   File "pypp_setup.py", line 1174, in ?
     mod.writeModule()
   File "...pyplusplus/experimental/pypp_api.py", line 456, in writeModule
     mfs.write(write_main=multiCreateMain)
   File "...pyplusplus/file_writers/multiple_files.py", line 253, in write
     map( self.split_class, class_creators )
   File "...pyplusplus/file_writers/multiple_files.py", line 171, in 
split_class
     self.__split_class_impl( class_creator )
   File "...pyplusplus/file_writers/multiple_files.py", line 148, in 
__split_class_impl
     , [class_creator] ))
   File "...pyplusplus/file_writers/multiple_files.py", line 132, in 
create_source
     answer.append( code_creators.code_creator_t.indent( 
creator.create() ) )
   File "...pyplusplus/code_creators/code_creator.py", line 93, in create
     code = self._create_impl()
   File "...pyplusplus/code_creators/class_declaration.py", line 308, in 
_create_impl
     return self._generate_code_no_scope()
   File "...pyplusplus/code_creators/class_declaration.py", line 226, in 
_generate_code_no_scope
     class_constructor, used_init = self._generate_constructor()
   File "...pyplusplus/code_creators/class_declaration.py", line 210, in 
_generate_constructor
     elif self.declaration.indexing_suite:
   File "...pyplusplus/decl_wrappers/class_wrapper.py", line 108, in 
_get_indexing_suite
     if self._indexing_suite is None:
AttributeError: 'class_t' object has no attribute '_indexing_suite'

Re: [pygccxml-development] Can held_type be an abstract class?

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

On 6/18/06, Roman Yakovenko <rom...@gm...> wrote:
> Another comment for the Resource class: you did not set held_type. It should
> be set to Ogre::SharedPtr< Ogre::Resource >.

Sorry, I was wrong here: held type should be unchanged. There is something
I don't understand. I will try to find out this tomorrow.


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

Re: [pygccxml-development] Can held_type be an abstract class?

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

On 6/18/06, Roman Yakovenko <rom...@gm...> wrote:
> On 6/18/06, Lakin Wecker <lak...@gm...> wrote:
> > Hi,
> >
> > I've applied some code that Roman and I came up with to wrap and
> > appropriately use the Ogre::SharedPtr class.  In one case I'm setting
> > the held_type of Ogre::Resource to be Ogre::SharedPtr <Ogre::Resource>
> >  ..  However when I try to compile the generated code, I get the
> > following error.
> >
> > /home/lakin/code_personal/python-ogre/build/Resource.pypp.cpp:284:
> > instantiated from here
> > /usr/include/boost/python/object/pointer_holder.hpp:179: error: cannot
> > allocate an object of abstract type 'Ogre::Resource'
> > /home/lakin/.local//include/OGRE/OgreResource.h:68: note:   because
> > the following virtual functions are pure within 'Ogre::Resource':
> > /home/lakin/.local//include/OGRE/OgreResource.h:101: note:  virtual
> > void Ogre::Resource::loadImpl()
> > /home/lakin/.local//include/OGRE/OgreResource.h:105: note:  virtual
> > void Ogre::Resource::unloadImpl()
> > /home/lakin/.local//include/OGRE/OgreResource.h:107: note:  virtual
> > size_t Ogre::Resource::calculateSize() const
> > /usr/include/boost/python/object/pointer_holder.hpp: In constructor
> > 'boost::python::objects::pointer_holder<Pointer,
> > Value>::pointer_holder(PyObject*, A0, A1, A2, A3, A4, A5) [with A0 =
> > Ogre::ResourceManager*, A1 =
> > boost::python::objects::reference_to_value<const Ogre::String&>, A2 =
> > long unsigned int, A3 =
> > boost::python::objects::reference_to_value<const Ogre::String&>, A4 =
> > bool, A5 = Ogre::ManualResourceLoader*, Pointer =
> > Ogre::SharedPtr<Ogre::Resource>, Value = Ogre::Resource]':
> >
> > Anyone with ideas?

Yes, I took a look on the problem. Now I understand it. First of all
gcc is right
Resource_wrapper is abstract class: loadImpl, unloadImpl and calculateSize
were not defined. Why those functions were not defined - because they are
declared as protected and we excluded them:

ogre_ns.calldefs( ~access_type_matcher_t ('public')).exclude ()

There are few problems here:
1. In this case I would expect from pyplusplus to give a warning
2. User should decide whether he want to give a Python programmer to ability
    to create new resource type or not.
    if the answer is yes, then those functions should not be excluded
    if the answer is no, then you should say to pyplusplus to finalize
the class.
    Right now pyplusplus does not support this.
    See next link for more information about "finalize" functionality
          http://www.boost.org/libs/python/pyste/doc/renaming_and_excluding.html
So, the short advise to you is: comment that line.

Another comment for the Resource class: you did not set held_type. It should
be set to Ogre::SharedPtr< Ogre::Resource >.

Hope I was clear.

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

Re: [pygccxml-development] Python Property Generation

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

I am in the process of creating a small web page for this project.  I
will update the code and post some screenshots.  In the mean time,
here is the current version of the script.

Lakin

On 6/18/06, Roman Yakovenko <rom...@gm...> wrote:
> On 6/18/06, Lakin Wecker <lak...@gm...> wrote:
> > Hi all,
> >
> > In working on my python-ogre bindings using pyplusplus, I wanted to
> > generate properties for the Ogre API.   Roman had directed me towards
> > the custom code creators included with pyplusplus:
> > pygccxml/pyplusplus_dev/examples/custom_code_creator/generate_code.py
> >
> > The following code is heavily based on this example, however the Ogre
> > API is not quite as rigorous as the cpp-code used in the examples, so
> > it is also heavily modified:
> >
> > 1) Read Only properties are generated when there is no setter.
> > 2) The method type is also included in the generated cpp code to
> > distinguish between overloaded method names.
> > 3) Extra checking is done to ensure that the methods found are indeed
> > getters and setters. (Only one argument and void return type for
> > setters.  No arguments and non-void return type for getter. The getter
> > return type and the setter argument type should match).
> > 4) In Ogre, there are some cases where a base class initially defines
> > the getter and setter, and the inheriting class overrides _only_ the
> > getter(See the Ogre::Frustum, Ogre::Camera classes for an example).
> > In this case, the above code was generating a read only property for
> > the inheriting class.  I've enhanced the code to look at base classes
> > to complete the properties.  IE, if there is no setter, an appropriate
> > setter is searched for (recursively) along the bases, the same is done
> > if there is no getter.
> > 5) In Ogre, pointers and references returned are always internal
> > references, and many of the properties return pointers and references.
> >  If the getters return a reference or a pointer the call_policies are
> > set on the property.  (this could be refactored to be more flexible).
> >
> > I made a best-effort to find the easiest way to do some of these
> > things using the provided API, but I may have missed items.  So I'm
> > open to criticisms, or suggestions of how to improve the code by using
> > pygccxml/pyplusplus API's.
>
> Cool! I'd like to review the code, but it is very difficult, can you
> attach the file with the
> code or may be to update the web site?
>
> Thanks
>
>
> --
> Roman Yakovenko
> C++ Python language binding
> http://www.language-binding.net/
>

[pygccxml-development] indexing suite support

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

Hi. I implemented and tested indexing suite support.

In order to get an idea what I am talking about please read this:
http://language-binding.net/pyplusplus/peps/indexing_suite.html.

Right now the only supported container is std::vector. It will take
only few hours to add
support to other containers( map and set ).

It could be nice if you can test the latest code. Next link will give
you an idea how to find
vector class:

http://svn.sourceforge.net/viewcvs.cgi/pygccxml/pyplusplus_dev/unittests/indexing_suites_tester.py?view=markup

Also there is new type traits functionality:
class vector_traits:
     is_vector( type ) returns true if type is std::vector instantiation
     class_declaration( type ) returns reference to vector class declaration
     value_type( type ) returns reference to type/class that is value
type of the vector


NOTE: The previous interface has been removed from source code.

Enjoy.

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

Re: [pygccxml-development] Can held_type be an abstract class?

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

On 6/18/06, Lakin Wecker <lak...@gm...> wrote:
> Hi,
>
> I've applied some code that Roman and I came up with to wrap and
> appropriately use the Ogre::SharedPtr class.  In one case I'm setting
> the held_type of Ogre::Resource to be Ogre::SharedPtr <Ogre::Resource>
>  ..  However when I try to compile the generated code, I get the
> following error.
>
> /home/lakin/code_personal/python-ogre/build/Resource.pypp.cpp:284:
> instantiated from here
> /usr/include/boost/python/object/pointer_holder.hpp:179: error: cannot
> allocate an object of abstract type 'Ogre::Resource'
> /home/lakin/.local//include/OGRE/OgreResource.h:68: note:   because
> the following virtual functions are pure within 'Ogre::Resource':
> /home/lakin/.local//include/OGRE/OgreResource.h:101: note:  virtual
> void Ogre::Resource::loadImpl()
> /home/lakin/.local//include/OGRE/OgreResource.h:105: note:  virtual
> void Ogre::Resource::unloadImpl()
> /home/lakin/.local//include/OGRE/OgreResource.h:107: note:  virtual
> size_t Ogre::Resource::calculateSize() const
> /usr/include/boost/python/object/pointer_holder.hpp: In constructor
> 'boost::python::objects::pointer_holder<Pointer,
> Value>::pointer_holder(PyObject*, A0, A1, A2, A3, A4, A5) [with A0 =
> Ogre::ResourceManager*, A1 =
> boost::python::objects::reference_to_value<const Ogre::String&>, A2 =
> long unsigned int, A3 =
> boost::python::objects::reference_to_value<const Ogre::String&>, A4 =
> bool, A5 = Ogre::ManualResourceLoader*, Pointer =
> Ogre::SharedPtr<Ogre::Resource>, Value = Ogre::Resource]':
>
> Anyone with ideas?

Yes.

Held type could not be abstract. SharedPtr<Resource> is not abstract.
I guess, that pyplusplus does not generates no_init or something like
this. I will check
this evening, okay?

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

Re: [pygccxml-development] Python Property Generation

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

On 6/18/06, Lakin Wecker <lak...@gm...> wrote:
> Hi all,
>
> In working on my python-ogre bindings using pyplusplus, I wanted to
> generate properties for the Ogre API.   Roman had directed me towards
> the custom code creators included with pyplusplus:
> pygccxml/pyplusplus_dev/examples/custom_code_creator/generate_code.py
>
> The following code is heavily based on this example, however the Ogre
> API is not quite as rigorous as the cpp-code used in the examples, so
> it is also heavily modified:
>
> 1) Read Only properties are generated when there is no setter.
> 2) The method type is also included in the generated cpp code to
> distinguish between overloaded method names.
> 3) Extra checking is done to ensure that the methods found are indeed
> getters and setters. (Only one argument and void return type for
> setters.  No arguments and non-void return type for getter. The getter
> return type and the setter argument type should match).
> 4) In Ogre, there are some cases where a base class initially defines
> the getter and setter, and the inheriting class overrides _only_ the
> getter(See the Ogre::Frustum, Ogre::Camera classes for an example).
> In this case, the above code was generating a read only property for
> the inheriting class.  I've enhanced the code to look at base classes
> to complete the properties.  IE, if there is no setter, an appropriate
> setter is searched for (recursively) along the bases, the same is done
> if there is no getter.
> 5) In Ogre, pointers and references returned are always internal
> references, and many of the properties return pointers and references.
>  If the getters return a reference or a pointer the call_policies are
> set on the property.  (this could be refactored to be more flexible).
>
> I made a best-effort to find the easiest way to do some of these
> things using the provided API, but I may have missed items.  So I'm
> open to criticisms, or suggestions of how to improve the code by using
> pygccxml/pyplusplus API's.

Cool! I'd like to review the code, but it is very difficult, can you
attach the file with the
code or may be to update the web site?

Thanks


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

[pygccxml-development] Can held_type be an abstract class?

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

Hi,

I've applied some code that Roman and I came up with to wrap and
appropriately use the Ogre::SharedPtr class.  In one case I'm setting
the held_type of Ogre::Resource to be Ogre::SharedPtr <Ogre::Resource>
 ..  However when I try to compile the generated code, I get the
following error.

/home/lakin/code_personal/python-ogre/build/Resource.pypp.cpp:284:
instantiated from here
/usr/include/boost/python/object/pointer_holder.hpp:179: error: cannot
allocate an object of abstract type 'Ogre::Resource'
/home/lakin/.local//include/OGRE/OgreResource.h:68: note:   because
the following virtual functions are pure within 'Ogre::Resource':
/home/lakin/.local//include/OGRE/OgreResource.h:101: note:  virtual
void Ogre::Resource::loadImpl()
/home/lakin/.local//include/OGRE/OgreResource.h:105: note:  virtual
void Ogre::Resource::unloadImpl()
/home/lakin/.local//include/OGRE/OgreResource.h:107: note:  virtual
size_t Ogre::Resource::calculateSize() const
/usr/include/boost/python/object/pointer_holder.hpp: In constructor
'boost::python::objects::pointer_holder<Pointer,
Value>::pointer_holder(PyObject*, A0, A1, A2, A3, A4, A5) [with A0 =
Ogre::ResourceManager*, A1 =
boost::python::objects::reference_to_value<const Ogre::String&>, A2 =
long unsigned int, A3 =
boost::python::objects::reference_to_value<const Ogre::String&>, A4 =
bool, A5 = Ogre::ManualResourceLoader*, Pointer =
Ogre::SharedPtr<Ogre::Resource>, Value = Ogre::Resource]':

Anyone with ideas?

Lakin

[pygccxml-development] Python Property Generation

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

Hi all,

In working on my python-ogre bindings using pyplusplus, I wanted to
generate properties for the Ogre API.   Roman had directed me towards
the custom code creators included with pyplusplus:
pygccxml/pyplusplus_dev/examples/custom_code_creator/generate_code.py

The following code is heavily based on this example, however the Ogre
API is not quite as rigorous as the cpp-code used in the examples, so
it is also heavily modified:

1) Read Only properties are generated when there is no setter.
2) The method type is also included in the generated cpp code to
distinguish between overloaded method names.
3) Extra checking is done to ensure that the methods found are indeed
getters and setters. (Only one argument and void return type for
setters.  No arguments and non-void return type for getter. The getter
return type and the setter argument type should match).
4) In Ogre, there are some cases where a base class initially defines
the getter and setter, and the inheriting class overrides _only_ the
getter(See the Ogre::Frustum, Ogre::Camera classes for an example).
In this case, the above code was generating a read only property for
the inheriting class.  I've enhanced the code to look at base classes
to complete the properties.  IE, if there is no setter, an appropriate
setter is searched for (recursively) along the bases, the same is done
if there is no getter.
5) In Ogre, pointers and references returned are always internal
references, and many of the properties return pointers and references.
 If the getters return a reference or a pointer the call_policies are
set on the property.  (this could be refactored to be more flexible).

I made a best-effort to find the easiest way to do some of these
things using the provided API, but I may have missed items.  So I'm
open to criticisms, or suggestions of how to improve the code by using
pygccxml/pyplusplus API's.

Lakin

#-------------------------------------------------------------------------------
class property_creator_t (code_creators.code_creator_t):
    '''A property creator which has support for generating readonly properties,
if no set_function is provided. As well as adding a policy to
reference_existing_object if the return type of the function is a reference or
pointer.'''

    def __init__( self, get_function, set_function, parent=None ):
        #get/set functions are references to relevant declarations
        code_creators.code_creator_t.__init__ (self, parent)
        self.__get_function = get_function and get_function.declaration
        self.__set_function = set_function and set_function.declaration

    def _create_template (self, function):
        '''Use this function to create the reference to the function with the
appropriate policy.'''
        if not function: return ''

        impl = '(%(type)s)( &%(function)s )' % dict (
                function = declarations.full_name (function),
                type = function.function_type ().decl_string)

        if declarations.is_pointer (function.return_type) \
            or declarations.is_reference (function.return_type):
            # Ogre's default is to return internal references
            impl = '''bp::make_function (%s,
                bp::return_value_policy <bp::reference_existing_object,
                    bp::default_call_policies>())''' % impl

        return ', %s' % impl


    def _create_impl(self):
        template = '''add_property ("%(name)s" %(properties)s)'''
        properties_template = self._create_template (self.__get_function)
        properties_template += self._create_template (self.__set_function)
        property_name = self.__get_function.name[3:]
        property_name = property_name[0].lower() + property_name[1:]
        return template % dict (name=property_name,
properties=properties_template)

improper_getters = 0
improper_setters = 0

#-------------------------------------------------------------------------------
def create_properties (mb):
    '''Ogre typically uses getX and setX for properties.
However, we have to be careful because there are methods names setX and getX
which are not true properties (in a pythonic sense), as sometimes a getX will
take one or more arguments, or the setX will take more than one argument.
TODO: there are probably exceptions to the naming scheme which should be found
and documented.'''

    # First, some helper functions
    def is_relevant (code_creator):
        '''Ensures that we're looking at methods that start with get/set and
are public member functions.'''
        if not isinstance (code_creator, code_creators.declaration_based_t):
            #We are looking for code creator, that has to export some
declaration
            return False
        if not isinstance (code_creator.declaration,
module_builder.member_function_t):
            #declaration should be member function
            return False
        decl = code_creator.declaration

        if decl.access_type != "public":
            # allow only public members.
            return False

        #member function name should start from "get" or "set"
        return decl.name.startswith ('get') or decl.name.startswith ('set')

    def is_property (getter, setter):
        '''Checks that we have at least a getter function and that the form
of the functions is appropriate: getter has no arguments and returns the same
type of object as the type of the only argument to the setter function.'''
        global improper_setters, improper_getters

        # Ignore these, as set-only properties don't make of sense.
        if not getter: return False
        get_decl = getter.declaration

        if len (get_decl.arguments) > 0 or get_decl.return_type == 'void':
            # Make sure it has a non-void return type.
            improper_getters += 1
            return False

        # We're ok with read only properties
        if not setter: return True
        set_decl = setter.declaration

        if len(set_decl.arguments) != 1:
            # Getter has no args, and setter has one arg improper_setters += 1
            improper_setters += 1
            return False

        if get_decl.return_type != set_decl.arguments[0].type:
            # Make sure their types match up.
            improper_setters += 1
            return False

        return True

    classes = filter (lambda creator: isinstance (creator,
code_creators.class_t),
        code_creators.make_flatten(mb.code_creator))

    code_creator_dict = {}
    for class_creator in classes:
        code_creator_dict[class_creator.declaration.name] = class_creator

    for class_creator in classes:
        print class_creator.declaration.name, "_"*80
        accessor_list = filter (is_relevant, class_creator.creators)
        # get only the relevant code_creators

        accessors_db = {} # name : {'get':get creator, 'set':set
creator]

        #Filling accessors_db
        for creator in accessor_list:
            type = creator.declaration.name[:3]
            property_name = creator.declaration.name[3:]
            print type, property_name
            if not accessors_db.has_key (property_name):
                accessors_db [property_name] = {'set':None,'get':None}
            if accessors_db[property_name][type]:
                # If we already have this type of creator we will prefer
                # ones without a const, or the first one
                if hasattr
(accessors_db[property_name][type].declaration,'has_const') and \
                    accessors_db[property_name][type].declaration.has_const:
                    print "SWITCHING:", creator.declaration.name,
"instead of", accessors_db [property_name][type].declaration.name
                    accessors_db [property_name][type] = creator
            else:
                accessors_db [property_name][type] = creator



        def find_accessor_in_base (code_creator, name, type):
            '''Searches in the base classes for the accessor with the
right type and name.'''
            bases = code_creator.declaration.bases[:] # make a copy of
direct bases

            while len(bases) > 0:
                base_class = bases.pop(0)
                print "Searching in:", base_class.related_class.name, "_"*80
                if not code_creator_dict.has_key
(base_class.related_class.name): continue
                accessor_list = filter (is_relevant,
code_creator_dict[base_class.related_class.name].creators)

                for creator in accessor_list:
                    if not hasattr (creator,"declaration"): continue
                    foundType = creator.declaration.name[:3]
                    property_name = creator.declaration.name[3:]
                    if type == foundType and property_name == name:
                        return creator

                # add indirect bases of this class.
                bases.extend (base_class.related_class.bases)
            return None

        for name,accessors in accessors_db.items():
            # If we're missing an accessor, try to find it in the parent class
            accessors['get'] = accessors['get'] or
find_accessor_in_base (class_creator,name,'get')
            accessors['set'] = accessors['set'] or
find_accessor_in_base (class_creator,name,'set')

            if is_property (accessors['get'], accessors['set']):
                prop_creator = property_creator_t (accessors['get'],
accessors['set'])
                class_creator.adopt_creator (prop_creator)



    print "-"*80
    print "Improper Getters", improper_getters
    print "Improper Setters", improper_setters

Re: [pygccxml-development] Finalizing a class?

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

On 6/15/06, Allen Bierbaum <al...@vr...> wrote:
> Roman:
>
> Was there ever any progress on this?  I am back to wrapping my original
> library now and I really need the ability to finalize classes.

There is no progress, but there is pretty simple work around: set
member functions
virtuality to NOT_VIRTUAL. In this case py++ will generate wrappers
only when it is
absolutely needed:
    arrays
    bit fields
    member variable that has pointer or reference type
    may be something else

Be careful with pure virtual functions.

Also If you want to implement this, I will try to find time and to
explain you how to
do that.

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

Re: [pygccxml-development] Finalizing a class?

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

Roman:

Was there ever any progress on this?  I am back to wrapping my original 
library now and I really need the ability to finalize classes.

-Allen

Roman Yakovenko wrote:

> On 5/17/06, Allen Bierbaum <al...@vr...> wrote:
>
>> Roman Yakovenko wrote:
>>
>> > On 5/17/06, Allen Bierbaum <al...@vr...> wrote:
>> >
>> >> This seems like something that should be made easier for the user.
>> >>
>> >> Perhaps something like:
>> >>
>> >> my_ns.class_("ClassA").finalize()
>> >>
>> >> class_a.member_function("my_method").finalize()
>> >>
>> >> Is there any reason pyplusplus can't provide a more simple interface
>> >> like this for the user?
>> >
>> >
>> > What should do pyplusplus if the only way to export declaration is to
>> > create some
>> > wrapper for it? For example class with pure virtual function:
>> >   raise an error?
>> >   create wrapper?
>> >   try to export without wrapper and let to the user to understand
>> > what he did
>> >   wrong?
>>
>> I think it should raise an error and explain to the user why pyplusplus
>> can't honor their request.
>>
>> If it is ever possible to detect that they user is doing something that
>> is invalid and can be detected, then the system should tell the user and
>> ask them to correct it.
>
>
> It is not convinient, I think we should have next functionality:
> finalize if possible
>
>>  For example I would like the option to turn on
>> a warning or even error message for cases where pyplusplus knows the
>> user should specify a calling policy but hasn't.  The system already
>> puts a comment in the code to that effect, it may as well warn the user
>> as well.
>
>
> I will print a message to log.
>
>> -Allen
>>
>>
>
>

Re: [pygccxml-development] pyplusplus support will be limited next few days ( may be weeks )

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

Congratulations Roman!

Lakin

On 6/6/06, Roman Yakovenko <rom...@gm...> wrote:
> Hi. This night my son was born. As the subject says, the support will
> be limited.
>
> If you have something urgent, please send email with a subject, that
> starts from word
> URGENT.
>
>
> --
> Roman Yakovenko
> C++ Python language binding
> http://www.language-binding.net/
>
>
> _______________________________________________
> pygccxml-development mailing list
> pyg...@li...
> https://lists.sourceforge.net/lists/listinfo/pygccxml-development
>

[pygccxml-development] pyplusplus support will be limited next few days ( may be weeks )

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

Hi. This night my son was born. As the subject says, the support will
be limited.

If you have something urgent, please send email with a subject, that
starts from word
URGENT.


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

Re: [pygccxml-development] boost.python _can_ expose functions with more than 10 arguments

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

On 6/5/06, Lakin Wecker <lak...@gm...> wrote:
> Last night I investigated why py++ wasn't exporting some methods for
> me, and I came across the following code, which I promptly commented
> out:
>
> pyplusplus_dev/pyplusplus/decl_wrappers/calldef_wrapper.py:100ish
>     def _exportable_impl( self ):
>         #see http://www.boost.org/libs/python/doc/v2/faq.html#funcptr
>         #if len( self.arguments ) > 10:
>             #return "boost.python can not expose function with more
> then 10 arguments. ( impl details: boost.tuple is limited to 10 args
> )."
>
> If you define BOOST_PYTHON_MAX_ARITY=19 or some such, it allows you to
> up the maximum number of arguments that Boost.Python can handle.
> Indeed, I was able to export and use the method.

I will update the code. It will print a message to user what should be
done in order to
compile generated code.

Thanks

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

[pygccxml-development] boost.python _can_ expose functions with more than 10 arguments

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

Last night I investigated why py++ wasn't exporting some methods for
me, and I came across the following code, which I promptly commented
out:

pyplusplus_dev/pyplusplus/decl_wrappers/calldef_wrapper.py:100ish
    def _exportable_impl( self ):
        #see http://www.boost.org/libs/python/doc/v2/faq.html#funcptr
        #if len( self.arguments ) > 10:
            #return "boost.python can not expose function with more
then 10 arguments. ( impl details: boost.tuple is limited to 10 args
)."

If you define BOOST_PYTHON_MAX_ARITY=19 or some such, it allows you to
up the maximum number of arguments that Boost.Python can handle.
Indeed, I was able to export and use the method.

Lakin

Re: [pygccxml-development] type_traits problem

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

On 5/30/06, Roman Yakovenko <rom...@gm...> wrote:
> On 5/30/06, Allen Bierbaum <al...@vr...> wrote:
> > Did this ever get fixed?  (I don't think it did)

Yes, I am going to fix this.

is_xxx will report true for "xxx" and "const xxx", for all other cases
it will report false

Here is a link to relevant example:
http://boost.org/doc/html/boost_typetraits/reference.html#boost_typetraits.is_enum

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

[pygccxml-development] Announcement: pygccxml/pyplusplus 0.8.0

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

I'm glad to announce the new version of pygccxml and pyplusplus packages.

Next people contributed to the development:

    Matthias Baas
    Allen Bierbaum
    Lakin Wecker
    Georgiy Dernovoy

Thank you!

List of changes:

1. We started to use Subversion

2. Query API has been moved from pyplusplus to pygccxml. This change is fully
    backward compatible. Query API has been documented:

    http://language-binding.net/pygccxml/query_interface.html

3. pygccxml improves support for template instantiations. This is very important
    feature. Because, before this feature was introduced GCC-XML reported
    wrong names for classes and functions. Now the latest CVS version of GCCXML
    reports class name, mangled and demangled strings. pygccxml uses
    demangled string for class name.

4. pygccxml.declarations.class_t now has a list of all aliases(
typedefs) to the
    class.

    pyplusplus will use the list to guess class alias, in case the class is
    template instantiation.

5. pyplusplus has been improved a lot:

    It is knows how to export reference and pointer member variables.
    Few internal changes, that simplifies the implementation and in a near
    future those changes will allow us to introduce two very important features:

    1. call wrappers policy
        http://language-binding.net/pyplusplus/peps/call_wrapper_policies.html

    2. almost fully automated solution for std containers
        http://language-binding.net/pyplusplus/peps/indexing_suite.html

    3. Not all declarations, could be exported to Python. pyplusplus
will explain you
        why and may be will provide a link to full explanation.

     4. Not all function could be overridden in Python. pyplusplus
will explain you why.

6. Bug fixes. A lot of bugs have been fixed.

7. Documentation has been improved.

You can find more information about projects here:
http://language-binding.net/index.html

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

[pygccxml-development] Few bugs has been fixed

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

Hi. I fix few bugs, found by Lakin Wecker:
1. Functions that return/take an argument array will not be exported
2. is_noncopyable bug. Now if class contains non copyable member variable
    is will be always reported as noncopyable.

It could be nice if you can check those changes on your projects.

Thanks.


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

Re: [pygccxml-development] Ogre Binding

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

On 6/2/06, Roman Yakovenko <rom...@gm...> wrote:
> On 6/2/06, Lakin Wecker <lak...@gm...> wrote:
> > > Few comments on script:
> > > 1. For some reason you prefer to use "multiple select" functions, why?
> > >     For example:
> > >
> > >     ogre_ns.classes ('ColourValue').always_expose_using_scope = True
> >
> > This is due to my laziness, I knew that this syntax worked at some
> > point, so I continued to use it.  I will be attempting to clean up the
> > script over the next few days.
>
> Okey, I wanted you to be aware of another option.

Thanks.

> > > > 2. There are some issues for compiling the
> > >     Sorry, can not reproduce. The generated file compiles fine for me.
> > >     May I guess? You are generating XML files from one Ogre header files,
> > >     but compile python bindings with another. Or may be you use different
> > >     compilation settings.
> > >
> > >     Please put all environment variables into ogre_settings.
> >
> > For this one, are you referring to #1, #2, or both?  I will go ahead
> > and put all environment settings into ogre_settings.  As for your
> > first guess:  I'm fairly certain that I am using the exact same
> > headers for both steps.  However, I will double check.
>
> Then I have another guess: may be your cache contains xml files generated from
> old declarations?

Aaaah ... this is much more likely ....  I will check this right now.

Lakin

Re: [pygccxml-development] Ogre Binding

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

On 6/2/06, Lakin Wecker <lak...@gm...> wrote:
> On 6/2/06, Lakin Wecker <lak...@gm...> wrote:
> > > > > 1. I still have the call_policy for const Matrix4 & problem, (see the
> > > > > matrix4 scons log), even though there is code in generate_code.py that
> > > > > should specify call_policies for all references and pointer return
> > > > > types.
> > > > >
> > > > > 2. There are some issues for compiling the
> > > >     Sorry, can not reproduce. The generated file compiles fine for me.
> > > >     May I guess? You are generating XML files from one Ogre header files,
> > > >     but compile python bindings with another. Or may be you use different
> > > >     compilation settings.
>
> If you are referring to the (#1) Matrix4 problem,  it also currently
> compiles for me.   However, Then the problem arises if I comment out
> any of the following code:
>     # TODO: These function produce a compile error asking me to
> specify a call policy for
>     # const Matrix4 &, but this should be covered by the loop at the
> bottom of set_call_policies
>     ogre_ns.calldefs ('getParentEntityTransform').exclude ()
>     ogre_ns.calldefs ('_getFullTransform').exclude ()
>     ogre_ns.calldefs ('_getParentNodeFullTransform').exclude ()

I will take a look, thanks

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

Re: [pygccxml-development] Ogre Binding

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

On 6/2/06, Lakin Wecker <lak...@gm...> wrote:
> > Few comments on script:
> > 1. For some reason you prefer to use "multiple select" functions, why?
> >     For example:
> >
> >     ogre_ns.classes ('ColourValue').always_expose_using_scope = True
>
> This is due to my laziness, I knew that this syntax worked at some
> point, so I continued to use it.  I will be attempting to clean up the
> script over the next few days.

Okey, I wanted you to be aware of another option.

> > > 2. There are some issues for compiling the
> >     Sorry, can not reproduce. The generated file compiles fine for me.
> >     May I guess? You are generating XML files from one Ogre header files,
> >     but compile python bindings with another. Or may be you use different
> >     compilation settings.
> >
> >     Please put all environment variables into ogre_settings.
>
> For this one, are you referring to #1, #2, or both?  I will go ahead
> and put all environment settings into ogre_settings.  As for your
> first guess:  I'm fairly certain that I am using the exact same
> headers for both steps.  However, I will double check.

Then I have another guess: may be your cache contains xml files generated from
old declarations?

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

Re: [pygccxml-development] Ogre Binding

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

On 6/2/06, Lakin Wecker <lak...@gm...> wrote:
> > > > 1. I still have the call_policy for const Matrix4 & problem, (see the
> > > > matrix4 scons log), even though there is code in generate_code.py that
> > > > should specify call_policies for all references and pointer return
> > > > types.
> > > >
> > > > 2. There are some issues for compiling the
> > >     Sorry, can not reproduce. The generated file compiles fine for me.
> > >     May I guess? You are generating XML files from one Ogre header files,
> > >     but compile python bindings with another. Or may be you use different
> > >     compilation settings.

If you are referring to the (#1) Matrix4 problem,  it also currently
compiles for me.   However, Then the problem arises if I comment out
any of the following code:
    # TODO: These function produce a compile error asking me to
specify a call policy for
    # const Matrix4 &, but this should be covered by the loop at the
bottom of set_call_policies
    ogre_ns.calldefs ('getParentEntityTransform').exclude ()
    ogre_ns.calldefs ('_getFullTransform').exclude ()
    ogre_ns.calldefs ('_getParentNodeFullTransform').exclude ()

Lakin

Re: [pygccxml-development] Ogre Binding

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

> > > 1. I still have the call_policy for const Matrix4 & problem, (see the
> > > matrix4 scons log), even though there is code in generate_code.py that
> > > should specify call_policies for all references and pointer return
> > > types.
> > >
> > > 2. There are some issues for compiling the
> >     Sorry, can not reproduce. The generated file compiles fine for me.
> >     May I guess? You are generating XML files from one Ogre header files,
> >     but compile python bindings with another. Or may be you use different
> >     compilation settings.
> >
> >     Please put all environment variables into ogre_settings.
>
> For this one, are you referring to #1, #2, or both?  I will go ahead
> and put all environment settings into ogre_settings.  As for your
> first guess:  I'm fairly certain that I am using the exact same
> headers for both steps.  However, I will double check.
As a follow up:
lakin@zedd:~/Desktop/OgrePython$ sudo find / -iname "ogre.h"
/home/lakin/.local/include/OGRE/Ogre.h
/home/lakin/Documents/non-backup/Software/Compile/ogrenew/OgreMain/include/Ogre.h
lakin@zedd:~/Desktop/OgrePython$

There is only two copies of the ogre header file.  One is from the
build directory where I extracted the source.  And the other is from
the include directory where I installed ogre to.

Lakin

Re: [pygccxml-development] Ogre Binding

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

On 6/2/06, Roman Yakovenko <rom...@gm...> wrote:
> On 6/2/06, Lakin Wecker <lak...@gm...> wrote:
> > Good news: http://lakin.weckers.net/ogre/Screenshot.png  this is
> > rendered from python using the pyplusplus ogre bindings that I'm
> > working on.
>
> Those are really good news. You did it!
>
> > ...  only the CameraTrackingDemo.py is working)

Thanks

> First step is the most important one!
>
> I did not see SharedPtr treatment, without it a lot of functionality
> will not be
> available.

Of course, and it is high up on my TODO list.

> Few comments on script:
> 1. For some reason you prefer to use "multiple select" functions, why?
>     For example:
>
>     ogre_ns.classes ('ColourValue').always_expose_using_scope = True

This is due to my laziness, I knew that this syntax worked at some
point, so I continued to use it.  I will be attempting to clean up the
script over the next few days.

> 2. There is nothing wrong with "always_expose_using_scope". The generated code
>     is longer, but compiler is able to give better errors locations.
>     I suggest you to set "always_expose_using_scope" to True for all classes.

Will do.

> 3. StringVector
> from pyplusplus import code_creators
>
> code = """
>  class_< std::vector<Ogre::String>
>               , boost::shared_ptr<std::vector<Ogre::String> > >("StringVector")
>         .def(vector_indexing_suite<std::vector<OgreString> >())
>     ;
> """
>
> mb = module_builder_t(...)
> mb.build_code_creator(...)
> mb.code_creator.body.adopt_creator( code_creators.custom_text_t( code ), 0 )
>
> This will add code that register StringVector. I will send you the
> updated script

Thanks

> 4. generate_code.py and sconscript could  re-use ogre_settings.
>     4.1 please move gccxml location to ogre_settings
>     4.2 please move "build" dir to ogre_settings
>     4.3 import ogre_settings from sconscript. Thus you will be able to
> re-use all
>           variables and settings.
>     And of course I will don't have to change anything when I download
> your script

Yes, this is the first thing on my TODO list.   I had forgotten about
some of the variables that I still had hard coded. :(

> 5. System wide configurations better to do at the end.
>
>     ogre_ns.member_functions (lambda decl: decl.name.startswith( '_'
> )).exclude ()
>     ogre_ns.member_functions (lambda decl: decl.name == '',
>         allow_empty=True).exclude ()
>
>     Because, when you configure classes, you include them. That is why few lines
>     later you need to exclude some of the functions again.

Yes of course.  I should have figured this out.

> > 1. I still have the call_policy for const Matrix4 & problem, (see the
> > matrix4 scons log), even though there is code in generate_code.py that
> > should specify call_policies for all references and pointer return
> > types.
> >
> > 2. There are some issues for compiling the
>     Sorry, can not reproduce. The generated file compiles fine for me.
>     May I guess? You are generating XML files from one Ogre header files,
>     but compile python bindings with another. Or may be you use different
>     compilation settings.
>
>     Please put all environment variables into ogre_settings.

For this one, are you referring to #1, #2, or both?  I will go ahead
and put all environment settings into ogre_settings.  As for your
first guess:  I'm fairly certain that I am using the exact same
headers for both steps.  However, I will double check.

> > 4.  If you look through the generate_code.py, you'll notice a number
> > of TODO statements.  Some of these are simply that, things that I
> > still need to take care of, however, others are methods, or classes
> > that I've excluded because they cause problems, and I'm not sure how
> > to fix them.  As I go back through and add  them one at a time and see
> > if I can figure them out.  If not, I'll post here with more questions.
>
> I will take a look on other issuer this evening. I suggest you to ask the
> questions, if you can not find solution in 30 minutes :-)

Of course.  My general criteria for this is:  Try it.  If I have ideas
try them.  When I run out of ideas, use google, repeat.  When I've
finished trying everything that google has told me, I'll post here.

Lakin

Re: [pygccxml-development] Ogre Binding

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

On 6/2/06, Lakin Wecker <lak...@gm...> wrote:
> Good news: http://lakin.weckers.net/ogre/Screenshot.png  this is
> rendered from python using the pyplusplus ogre bindings that I'm
> working on.

Those are really good news. You did it!

> ...  only the CameraTrackingDemo.py is working)

First step is the most important one!

I did not see SharedPtr treatment, without it a lot of functionality
will not be
available.

Few comments on script:
1. For some reason you prefer to use "multiple select" functions, why?
    For example:

    ogre_ns.classes ('ColourValue').always_expose_using_scope = True

2. There is nothing wrong with "always_expose_using_scope". The generated code
    is longer, but compiler is able to give better errors locations.
    I suggest you to set "always_expose_using_scope" to True for all classes.

3. StringVector
from pyplusplus import code_creators

code = """
 class_< std::vector<Ogre::String>
              , boost::shared_ptr<std::vector<Ogre::String> > >("StringVector")
        .def(vector_indexing_suite<std::vector<OgreString> >())
    ;
"""

mb = module_builder_t(...)
mb.build_code_creator(...)
mb.code_creator.body.adopt_creator( code_creators.custom_text_t( code ), 0 )

This will add code that register StringVector. I will send you the
updated script

4. generate_code.py and sconscript could  re-use ogre_settings.
    4.1 please move gccxml location to ogre_settings
    4.2 please move "build" dir to ogre_settings
    4.3 import ogre_settings from sconscript. Thus you will be able to
re-use all
          variables and settings.
    And of course I will don't have to change anything when I download
your script

5. System wide configurations better to do at the end.

    ogre_ns.member_functions (lambda decl: decl.name.startswith( '_'
)).exclude ()
    ogre_ns.member_functions (lambda decl: decl.name == '',
        allow_empty=True).exclude ()

    Because, when you configure classes, you include them. That is why few lines
    later you need to exclude some of the functions again.

>
>
> There are quite a few things that I need to clear up.  Some of them
> may be my fault, some might be pyplusplus bugs.
>
> 1. I still have the call_policy for const Matrix4 & problem, (see the
> matrix4 scons log), even though there is code in generate_code.py that
> should specify call_policies for all references and pointer return
> types.
>
> 2. There are some issues for compiling the
    Sorry, can not reproduce. The generated file compiles fine for me.
    May I guess? You are generating XML files from one Ogre header files,
    but compile python bindings with another. Or may be you use different
    compilation settings.

    Please put all environment variables into ogre_settings.

>
>
> 3. There is some strangeness going on with Matrix3 (see
> matrix_3_scons.log), but I suspect this is because I'll need to
> manually wrap a few constructors that take Real[3] pointers.
>
> 4.  If you look through the generate_code.py, you'll notice a number
> of TODO statements.  Some of these are simply that, things that I
> still need to take care of, however, others are methods, or classes
> that I've excluded because they cause problems, and I'm not sure how
> to fix them.  As I go back through and add  them one at a time and see
> if I can figure them out.  If not, I'll post here with more questions.

I will take a look on other issuer this evening. I suggest you to ask the
questions, if you can not find solution in 30 minutes :-)

> Keep up the good work guys,
>
> pyplusplus gets better with ever new feature I learn about. :)

Thanks.

> Lakin


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