pygccxml-development

[pygccxml-development] Comments on code in FT package

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

Hi. I started to work on FT package, please don't work on it.
I just want to comment some code I saw, I fill this is important.

reftype = arg.type

if not (isinstance(reftype, declarations.reference_t) or
            isinstance(reftype, declarations.pointer_t) ):
    ...

This is  the wrong way to test for type  being pointer or reference(
hint typedef ).
The right way is to use type traits functionality  from declarations package:

reftype = arg.type
if not( declarations.is_reference( reftype ) \

           or declarations.is_pointer( reftype ) ):
    ...




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

Re: [pygccxml-development] Another way to speed up the generation process...

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

On 10/20/06, Allen Bierbaum <al...@vr...> wrote:
> >
> >While remove_declarations works as you expect, the functionality is broken.
> >For example: base and derived classes. if you remove base class from the
> >declaration tree, base class still will be accessible from the derived "bases"
> >property. Or if some function takes as argument instance of some class
> >and you remove the class from the declaration tree, the type of argument will
> >continue to keep reference to the class.
> >
> >
> I may be missing something, but those references will still be valid
> correct?  Python won't garbage collect them so it should be fine if
> Matthias removes something from the tree that doesn't need to be
> wrapped.  In the process of wrapping the remaining decls, if there is a
> reference to a removed decl it will still be there it just won't ever be
> wrapped which should be fine since those are the ones being removed
> anyway right. :)

Obviously I am not talking about "dangling references". The order of generated
code and it's correctness could be changed. Just scan decl_wrappers package
and take a look how many times Py++ is scanning the declarations tree.

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

Re: [pygccxml-development] Another way to speed up the generation process...

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

Roman Yakovenko wrote:

>On 10/20/06, Matthias Baas <ba...@ir...> wrote:
>  
>
>>Hi,
>>
>>I just thought I'd share a little code snippet that can be useful to
>>speed up the bindings generation process. The below function simply
>>removes all declaration nodes that do not originate from the specified
>>directories (i.e. it removes all the system chunk that is not going to
>>be wrapped anyway). So you should call that function right after the
>>parsing step.
>>I noticed that these extra nodes can eat up a lot of time as I was
>>porting my script over to OSX where a lot more system headers are read.
>>On Linux the running time was reduced from about 4:40 minutes to around
>>3:20 minutes and on OSX it went down from 7:20 minutes to 4:10 minutes.
>>
>>On OSX the top-level namespace contained more than 20000 nodes whereas
>>on Linux it was only about 4700 nodes. What I still have to investigate
>>is how the cache can be modified so that it stores the data *after*
>>pruning. It's a bit odd that reading the cache on OSX (14MB) takes more
>>than a minute whereas on Linux (6MB) it only takes 7 seconds. Obviously,
>>the algorithms used in the pickle module are far from being O(n).... ;)
>>    
>>
>
>I appreciate your efforts to speed up cod generation process. This
>specific patch
>will not find its way to Py++ :-(. It is too dangerous:
>
>While remove_declarations works as you expect, the functionality is broken.
>For example: base and derived classes. if you remove base class from the
>declaration tree, base class still will be accessible from the derived "bases"
>property. Or if some function takes as argument instance of some class
>and you remove the class from the declaration tree, the type of argument will
>continue to keep reference to the class.
>  
>
I may be missing something, but those references will still be valid 
correct?  Python won't garbage collect them so it should be fine if 
Matthias removes something from the tree that doesn't need to be 
wrapped.  In the process of wrapping the remaining decls, if there is a 
reference to a removed decl it will still be there it just won't ever be 
wrapped which should be fine since those are the ones being removed 
anyway right. :)

>To make the long story short, after you modify the declaration tree Py++ is
>responsible for generated code :-).
>
>If it works for you fine, otherwise ...
>
>Can you post your profiler results? May be we can find something that
>could\should be fixed.
>  
>
I am all for tuning performance for any profiler results.  Py++ is fast 
but it could always be faster. :)

-Allen

Re: [pygccxml-development] Another way to speed up the generation process...

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

On 10/20/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> I just thought I'd share a little code snippet that can be useful to
> speed up the bindings generation process. The below function simply
> removes all declaration nodes that do not originate from the specified
> directories (i.e. it removes all the system chunk that is not going to
> be wrapped anyway). So you should call that function right after the
> parsing step.
> I noticed that these extra nodes can eat up a lot of time as I was
> porting my script over to OSX where a lot more system headers are read.
> On Linux the running time was reduced from about 4:40 minutes to around
> 3:20 minutes and on OSX it went down from 7:20 minutes to 4:10 minutes.
>
> On OSX the top-level namespace contained more than 20000 nodes whereas
> on Linux it was only about 4700 nodes. What I still have to investigate
> is how the cache can be modified so that it stores the data *after*
> pruning. It's a bit odd that reading the cache on OSX (14MB) takes more
> than a minute whereas on Linux (6MB) it only takes 7 seconds. Obviously,
> the algorithms used in the pickle module are far from being O(n).... ;)

I appreciate your efforts to speed up cod generation process. This
specific patch
will not find its way to Py++ :-(. It is too dangerous:

While remove_declarations works as you expect, the functionality is broken.
For example: base and derived classes. if you remove base class from the
declaration tree, base class still will be accessible from the derived "bases"
property. Or if some function takes as argument instance of some class
and you remove the class from the declaration tree, the type of argument will
continue to keep reference to the class.

To make the long story short, after you modify the declaration tree Py++ is
responsible for generated code :-).

If it works for you fine, otherwise ...

Can you post your profiler results? May be we can find something that
could\should be fixed.

Thanks

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

[pygccxml-development] Another way to speed up the generation process...

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

Hi,

I just thought I'd share a little code snippet that can be useful to 
speed up the bindings generation process. The below function simply 
removes all declaration nodes that do not originate from the specified 
directories (i.e. it removes all the system chunk that is not going to 
be wrapped anyway). So you should call that function right after the 
parsing step.
I noticed that these extra nodes can eat up a lot of time as I was 
porting my script over to OSX where a lot more system headers are read.
On Linux the running time was reduced from about 4:40 minutes to around 
3:20 minutes and on OSX it went down from 7:20 minutes to 4:10 minutes.

On OSX the top-level namespace contained more than 20000 nodes whereas 
on Linux it was only about 4700 nodes. What I still have to investigate 
is how the cache can be modified so that it stores the data *after* 
pruning. It's a bit odd that reading the cache on OSX (14MB) takes more 
than a minute whereas on Linux (6MB) it only takes 7 seconds. Obviously, 
the algorithms used in the pickle module are far from being O(n).... ;)

- Matthias -


def pruneByHeader(rootdecl, includedirs):
     """Remove all nodes that don't originate from the specified 
directories.

     rootdecl must be the root node of the declaration tree (as a pygccxml
     namespace_t object). All nodes right beneath the root who do not
     originate from any directory in the list includedirs are removed
     from the tree.
     This operation is just meant to speed up subsequent queries
     by removing anything that will not get wrapped anyway.
     """
     includedirs = map(lambda x: os.path.abspath(x), includedirs)
     num_decls = len(rootdecl.declarations)
     num_removed = 0
     for decl in rootdecl.declarations[:]:
         header = getattr(decl.location, "file_name", None)
         # Check if the decl should be kept. If it should, then continue
         # the loop...
         if header!=None:
             header = os.path.abspath(header)
             keep_it = False
             for dir in includedirs:
                 if header.startswith(dir):
                     keep_it = True
                     break
             if keep_it:
                 continue
         # Remove the declaration
         decl.parent.remove_declaration(decl)
         num_removed += 1

     print "%d out of %d top-level declarations removed (%d 
kept)."%(num_removed, num_decls, num_decls-num_removed)

[pygccxml-development] [ANN] Py++ & pygccxml 0.8.2 released

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

Hi. I just uploaded new files to SF.

List of changes could be found here:
pygccxml:
http://svn.sourceforge.net/viewvc/pygccxml/pygccxml_dev/docs/history/history.rest?revision=676&view=markup
Py++
http://svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/docs/history/history.rest?revision=676&view=markup

In general it should be saved to switch to these version.

Please report any issue you have with release.

Thank you.

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

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

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

On 10/16/06, Allen Bierbaum <al...@vr...> wrote:
> I have this sort of working now, but I have run into an additional
> problem.  Because of the way the mixins work (I assume the templated
> base class), py++ is not figuring out that this class has a base class.
> Because of this I am not getting the standard support for using the
> methods of the base class that I have exposed.
>
> Is there anyway to manually tell py++ about a class's base classes?  For
> example given a class decl could I manually tell it that it is derived
> from class "Base" somehow so this would influence the code creators and
> thus the generated code?

Allen I am pretty busy, can you create small test case that reproduce the
problem? ( C++ and Py++ files ).

Boost.Date_Time uses same pattern and it works okay. May be you should take
a look on it.

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

Re: [pygccxml-development] ssize_t in __convenience.pypp.hpp

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

On 10/16/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > On 10/16/06, Matthias Baas <ba...@ir...> wrote:
> >> v1.33.1
> >
> > I am using "current cvs" and this is explains the problem. Is this an
> > option to switch to "current cvs"? It contains a lot of fixes.
>
> I'd rather postpone that until I really have to upgrade. It's quite a
> bit of work to do so (as I would have to compile & install it for
> several OSs and Python versions).
>
> > I will think about work around to the problem. You are welcome to
> > propose your solution too.
>
> I'm not sure how this is best dealt with. I have too little experience
> with that (and I don't have a 64bit machine available). I suppose
> whatever "automatic" solution we choose there should probably also be a
> way for the user to override this mechanism and manually provide the
> type he'd like to use.

I don't understand why, it seems to me that Python API forces us to use
some concrete type. I will check that, for a while I think it should be okay to
use int instead of ssize_t.
( I don't have time to investigate and solve this problem :-( )
I committed simple patch that temporally fix the problem
-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] ssize_t in __convenience.pypp.hpp

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

Roman Yakovenko wrote:
> On 10/16/06, Matthias Baas <ba...@ir...> wrote:
>> v1.33.1
> 
> I am using "current cvs" and this is explains the problem. Is this an
> option to switch to "current cvs"? It contains a lot of fixes.

I'd rather postpone that until I really have to upgrade. It's quite a 
bit of work to do so (as I would have to compile & install it for 
several OSs and Python versions).

> I will think about work around to the problem. You are welcome to
> propose your solution too.

I'm not sure how this is best dealt with. I have too little experience 
with that (and I don't have a 64bit machine available). I suppose 
whatever "automatic" solution we choose there should probably also be a 
way for the user to override this mechanism and manually provide the 
type he'd like to use.

- Matthias -

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

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

I have this sort of working now, but I have run into an additional 
problem.  Because of the way the mixins work (I assume the templated 
base class), py++ is not figuring out that this class has a base class.  
Because of this I am not getting the standard support for using the 
methods of the base class that I have exposed.

Is there anyway to manually tell py++ about a class's base classes?  For 
example given a class decl could I manually tell it that it is derived 
from class "Base" somehow so this would influence the code creators and 
thus the generated code?

-Allen


Allen Bierbaum wrote:

> I am having trouble wrapping a class right now.  The problem is that 
> the class uses template base classes to mixin functionality.  This 
> makes it appear to pygccxml that the class has a half-dozen base 
> classes.  But I don't want to expose these base classes, all I want to 
> expose is the class that is composed from the mixin functionality.  To 
> make matters worse there is something in the handling of these mixins 
> that is making pyplusplus code creators expose them all as having the 
> same name ("Inherited").  I think this is because each mixin class 
> uses a typedef called Inherited to keep track of the class that it is 
> inheriting from.  (I have attached a file that shows the basic idea, 
> but it is a vast simplification of the case I am really trying to handle)
>
> Anyway, to make a long story short, what I would like to do is just 
> tell pyplusplus to ignore the base classes (ie. don't expose them) but 
> to instead pull all of the methods defined in those base classes into 
> the derived class I am trying to expose.  Then the generated code 
> would only create a wrapper for the derived class and would just 
> create "def"'s that reference the methods from the mixins.
> Is this possible?
>
> -Allen
>
>------------------------------------------------------------------------
>
>
>namespace test_ns
>{
>template <class ParentT>
>class MethodAMixin : public ParentT
>{
>public:
>   void methodA();   
>};
>
>template <class ParentT>
>class MethodBMixin : public ParentT
>{
>public:
>   void methodB();
>};
>
>template <class ParentT>
>class MethodCMixin : public ParentT
>{
>public:
>   void methodC();
>};
>
>class Base
>{
>public:
>  void methodBase();
>};
>
>typedef MethodAMixin< MethodBMixin< MethodCMixin< Base > > > ParentType;
>
>
>class MyClass : public ParentType
>{
>public:
>   MyClass();
>   bool getSomething();
>};
>
>
>} // namespace test_ns
>  
>
>------------------------------------------------------------------------
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys -- and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
>------------------------------------------------------------------------
>
>_______________________________________________
>pygccxml-development mailing list
>pyg...@li...
>https://lists.sourceforge.net/lists/listinfo/pygccxml-development
>  
>

Re: [pygccxml-development] ssize_t in __convenience.pypp.hpp

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

On 10/16/06, Matthias Baas <ba...@ir...> wrote:
> v1.33.1

I am using "current cvs" and this is explains the problem. Is this an
option to switch
to "current cvs"? It contains a lot of fixes.

Any way the type is defined here:

http://boost.cvs.sourceforge.net/boost/boost/boost/python/ssize_t.hpp?view=log

Take a look on revision 1.1 comment. This is why I switched from int to ssize_t.
I will think about work around to the problem. You are welcome to
propose your solution
too.


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

Re: [pygccxml-development] ssize_t in __convenience.pypp.hpp

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

Roman Yakovenko wrote:
> On 10/16/06, Matthias Baas <ba...@ir...> wrote:
>> I've just updated my version of Py++ (from r628 to the current revision)
>> and now I get an error when I run the function transformer unit test:
>>
>> In file included from function_transformations.cpp:12:
>> __convenience.pypp.hpp:22: error: no type `ssize_t' in `boost::python'
> 
> What Boost.Python version do you use?

v1.33.1


- Matthias -

Re: [pygccxml-development] ssize_t in __convenience.pypp.hpp

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

On 10/16/06, Matthias Baas <ba...@ir...> wrote:
> I've just updated my version of Py++ (from r628 to the current revision)
> and now I get an error when I run the function transformer unit test:
>
> In file included from function_transformations.cpp:12:
> __convenience.pypp.hpp:22: error: no type `ssize_t' in `boost::python'

What Boost.Python version do you use?


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

[pygccxml-development] ssize_t in __convenience.pypp.hpp

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

I've just updated my version of Py++ (from r628 to the current revision) 
and now I get an error when I run the function transformer unit test:

In file included from function_transformations.cpp:12:
__convenience.pypp.hpp:22: error: no type `ssize_t' in `boost::python'


- Matthias -

Re: [pygccxml-development] Header file names are turned to lowercase on Windows

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

On 10/16/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> I noticed that the header file names are turned to lowercase when Py++
> is run on Windows. This makes it impossible to use the generated code on
> case-sensitive systems like Linux as well.
> After some investigation I found out that
> include_directories_t.normalize() calls os.path.normcase() on the path
> which converts the file name to lowercase. Could this be changed so that
> the original file name is preserved? (probably by using normpath()
> instead of normcase())

Not for this release sorry :-(.

The problem is that somewhere, I don't remember where, Py++ uses these
file names to
check uniqueness. The change that should be done is that: for compare
Py++ should use
the current normalize method, but for code generation it should use
the file name as is.

I think that this change could break something.

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

Re: [pygccxml-development] Dependency on Tkinter

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

On 10/16/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> I have another small feature request. When I was running Py++ on a
> system that hasn't had Tkinter installed I got an import error even
> though I wasn't using the GUI. Would it be possible to change this so
> that the non-GUI stuff can still be used even when Tkinter is not installed?

Done.

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

[pygccxml-development] Dependency on Tkinter

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

Hi,

I have another small feature request. When I was running Py++ on a 
system that hasn't had Tkinter installed I got an import error even 
though I wasn't using the GUI. Would it be possible to change this so 
that the non-GUI stuff can still be used even when Tkinter is not installed?

Cheers,

- Matthias -

[pygccxml-development] Header file names are turned to lowercase on Windows

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

Hi,

I noticed that the header file names are turned to lowercase when Py++ 
is run on Windows. This makes it impossible to use the generated code on 
case-sensitive systems like Linux as well.
After some investigation I found out that 
include_directories_t.normalize() calls os.path.normcase() on the path 
which converts the file name to lowercase. Could this be changed so that 
the original file name is preserved? (probably by using normpath() 
instead of normcase())

- Matthias -

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

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

On 10/15/06, Allen Bierbaum <al...@vr...> wrote:
> I agree that this it outside the normal usage scenario for py++, but I
> just thought of a reasonable way for the user to think about this in a
> way that may be useful to many more people.
>
> Namely, I was thinking that if the user exposes a class Derived but the
> class Base is not exposed, I think it would be reasonable for Py++ to
> automatically expose all the methods of Base in Derived.  This seems
> like a fairly reasonable usecase because there may just be some times
> that users only want to expose a couple of classes and don't want to
> expose all of their base classes.

I am not sure whether it is reasonable or not. It is very easy to
implement it in Py++.
To tell you the True the functionality like this already presents in Py++:

http://language-binding.net/pyplusplus/documentation/apidocs/pyplusplus.decl_wrappers.class_wrapper.class_t-class.html#redefine_operators

It could be extended to member functions too.

You are welcome to prepare patches and unit test and I will commit
them after this release.

> What do other people think, is this a common enough usage to make a
> feature request out of it?

There is more interesting use case, that I would like to support: Lets
say that you already
have hand written code for base class and now you want to export
derived one, using Py++.
It could be nice if Py++ would support such mixes.

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

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

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

Roman Yakovenko wrote:

> On 9/19/06, Allen Bierbaum <al...@vr...> wrote:
>
>> Roman Yakovenko wrote:
>>
>> > On 9/19/06, Allen Bierbaum <al...@vr...> wrote:
>> >
>> >> I am having trouble wrapping a class right now.  The problem is 
>> that the
>> >> class uses template base classes to mixin functionality.  This 
>> makes it
>> >> appear to pygccxml that the class has a half-dozen base classes.  
>> But I
>> >> don't want to expose these base classes, all I want to expose is the
>> >> class that is composed from the mixin functionality.
>> >
>> >
>> > I understand.
>> >
>> >>  To make matters
>> >> worse there is something in the handling of these mixins that is 
>> making
>> >> pyplusplus code creators expose them all as having the same name
>> >> ("Inherited").  I think this is because each mixin class uses a 
>> typedef
>> >> called Inherited to keep track of the class that it is inheriting 
>> from.
>> >
>> >
>> > This is the right guess.
>> >
>> >> (I have attached a file that shows the basic idea, but it is a vast
>> >> simplification of the case I am really trying to handle)
>> >>
>> >> Anyway, to make a long story short, what I would like to do is 
>> just tell
>> >> pyplusplus to ignore the base classes (ie. don't expose them) but to
>> >> instead pull all of the methods defined in those base classes into 
>> the
>> >> derived class I am trying to expose.  Then the generated code 
>> would only
>> >> create a wrapper for the derived class and would just create "def"'s
>> >> that reference the methods from the mixins.
>> >>
>> >> Is this possible?
>> >
>> >
>> > What do you think? Before I answer the question, I would like to make
>> > it clear:
>> > this is not  "the main success scenario", so you will have to touch
>> > here and there
>> > few low level details.
>
Sorry to reply to an old thread, but I was just dealing with this 
problem in another case and I started thinking about it again.

I agree that this it outside the normal usage scenario for py++, but I 
just thought of a reasonable way for the user to think about this in a 
way that may be useful to many more people.

Namely, I was thinking that if the user exposes a class Derived but the 
class Base is not exposed, I think it would be reasonable for Py++ to 
automatically expose all the methods of Base in Derived.  This seems 
like a fairly reasonable usecase because there may just be some times 
that users only want to expose a couple of classes and don't want to 
expose all of their base classes.

What do other people think, is this a common enough usage to make a 
feature request out of it?

-Allen

Re: [pygccxml-development] indexing suite

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

On 10/13/06, Neal Becker <ndb...@gm...> wrote:
> I want to try out pyplusplus to wrap boost::ublas::vector (and maybe
> eventually matrix).
>
> I was reading about indexing suite 2.  It sounds interesting.
>
> I read pygccxml/pyplusplus_dev/docs/documentation/containers.rest.  It talks
> about how py++ will automatically recognize stl containers.
>
> Can I use it for my own containers?  How?

You will have to understand few implementation details.

1. How to recognize that the class is container?
    1. pygccxml/declarations/container_traits.py file defines
functionality that
        allows Py++ to recognize std containers. You have to implement class
        with the same interface
    2. pygccxml/declarations/__init__.py defines variable -
all_container_traits. Add
        instance of your class to it. This will allow Py++ to work
with your container
        as it was one of the built-in containers

2. By default Py++ uses the indexing suite Boost.Python comes with, you will
    have to switch to next version:

    mb = module_builder_t( ..., indexing_suite_version=2 )

3. How to teach Py++ generate the right code?
    1. pyplusplus/module_creator/creator.py contains definition of
        INDEXING_SUITE_2_CONTAINERS variable. This is a dictionary, that maps
        between class name ( part of it ) to the header file that
should be included.
        You will have to add your header file to it.

That's all. Possible I missed something. If you find this technique
useful we can
work together on making it more user friendly.

By the way, containers is not the only functionality you can customize this way:
Py++ svn introduced is_immutable function - this function returns true if C++
type will be mapped to immutable type in Python. If you will tell to Py++
that this and that types are immutable, it will save you time.

Smart pointers is another area, where you can teach Py++. After this it will
be able to generate write HeldType and to generate "register_ptr_to_python"
and "implicitly_convertible" code.


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

[pygccxml-development] indexing suite

[Neal B. <ndb...@gm...>]

I want to try out pyplusplus to wrap boost::ublas::vector (and maybe 
eventually matrix).

I was reading about indexing suite 2.  It sounds interesting.

I read pygccxml/pyplusplus_dev/docs/documentation/containers.rest.  It talks 
about how py++ will automatically recognize stl containers.

Can I use it for my own containers?  How?

Re: [pygccxml-development] FT - transformer changes

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

Roman Yakovenko wrote:
> On 10/9/06, Roman Yakovenko <rom...@gm...> wrote:
>> Hi. I would like to introduce next changes to the FT classes.
>>
>> 1. rename function_transformer_t to transformer_t and add new class
>> function_transformation_t
>>     Consider  next example:
>>     struct vector3{
>>          vector3( int, int, int ){...}
>>     }
>>
>>     draw_dot( vector3 ){ ... }
>>
>>     User can expose this function as is, but will be able also define
>> convenience method
>>     that takes tuple.
>>
>>     draw_dot( tuple ){
>>          internally constructs vector3 from tuple and calls the original
>> function.
>>     }
>>
>>     function_transformation_t will keep list of all transformers that should
>> be applied to the function
>>
>>     decl_wrappers.member_function_t will keep a list of all
>> function_transformation_t
>>
>>      Obviously the user code, creator_t classes will have to change, but I
>> think this is a good
>>     reason.
>>
>> 2. rename arg_policies.py file to transformers.py
>>
>>     Get rid of old name
>>
>> 3. every transformer class should derive from transformer_t
>>
>>     1. This will introduce "transformer" concept to the Py++. Very, very
>> important.
>>
>>     2. This will allow us to get rid of code
>>         src = map(lambda cb: getattr(cb, "wrapper_pre_call", defmeth)(self),
>> transformers)
>>
>> 4. every method defined in transformer_t class should return empty string
>> and not None.
>>
>>     It will make it clear for user that every redefined method in the
>> derived class should return string
>>
> 
> Matthias what do you think about these changes?

Renaming: If you think the new names make the code clearer then just go 
ahead.

Point 4: I'm fine with that. I guess this makes the code even a bit more 
fail-safe (provided that the type of the return value is checked and a 
proper exception is raised!).

Point 1 & 3: I can't really comment on those as you don't say what 
problems these things are trying to solve and how they solve them. It 
seems to me that these suggestions would lead to a bigger modification 
of the code that also alters the way the functionality is used.


- Matthias -

Re: [pygccxml-development] FT - name uniqueness

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

Roman Yakovenko wrote:
>> Without that the user assigns an alias?
> 
> Yes, Py++ will do it for him.
> 
>>  How will you do that?
> 
> get_value1
> get_value2
> ...

And how will the user know about this? I certainly wouldn't expect the 
methods to show up under a different name.
If you're going to implement this, then please also provide a way to 
disable this feature. (Personally, I think this should actually be 
disabled by default and only be enabled when the user requests it. Then 
Py++ can at least assume that the user knows what he's doing. I suppose 
it would also be desirable to be able to customize the rules for 
generating the names as I doubt that numbering the functions is hardly 
ever what the user wants to get)

- Matthias -

Re: [pygccxml-development] FT - transformer changes

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

On 10/9/06, Roman Yakovenko <rom...@gm...> wrote:
> Hi. I would like to introduce next changes to the FT classes.
>
> 1. rename function_transformer_t to transformer_t and add new class
> function_transformation_t
>     Consider  next example:
>     struct vector3{
>          vector3( int, int, int ){...}
>     }
>
>     draw_dot( vector3 ){ ... }
>
>     User can expose this function as is, but will be able also define
> convenience method
>     that takes tuple.
>
>     draw_dot( tuple ){
>          internally constructs vector3 from tuple and calls the original
> function.
>     }
>
>     function_transformation_t will keep list of all transformers that should
> be applied to the function
>
>     decl_wrappers.member_function_t will keep a list of all
> function_transformation_t
>
>      Obviously the user code, creator_t classes will have to change, but I
> think this is a good
>     reason.
>
> 2. rename arg_policies.py file to transformers.py
>
>     Get rid of old name
>
> 3. every transformer class should derive from transformer_t
>
>     1. This will introduce "transformer" concept to the Py++. Very, very
> important.
>
>     2. This will allow us to get rid of code
>         src = map(lambda cb: getattr(cb, "wrapper_pre_call", defmeth)(self),
> transformers)
>
> 4. every method defined in transformer_t class should return empty string
> and not None.
>
>     It will make it clear for user that every redefined method in the
> derived class should return string
>

Matthias what do you think about these changes?

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