pygccxml-development

Re: [pygccxml-development] finalize yet again....

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

On 9/11/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> meanwhile it has come up a few times now in this list, but I believe the
> finalize functionality is not yet in place, is it?

Right.

> What is the current status on this? In particular, what properties will
> control this?

There are no such properties.

> As you might have read already in the other thread from today, the
> function transformation feature on non-virtual functions should
> optionally result in the creation of a wrapper class or not. I'd say
> this basically is already something that can be controlled by the
> finalize functionality. So it would be nice if I could use the same
> attributes/properties that will also be used by the other parts of Py++.

Well, obviously you can not.

Actually "finalize" functionality was never a stopper for use of Py++.
Most users treats absence of "finalize" as small inconvinience.
There are always some other problems that have higher priority. In previous
version it was documentation, indexing suite v2, class_multiplie_file writer and
user feedback. This version the main feature is FT functionality. I
also will add
"add_method" functionality. Thus Py++ will better suited for creating bindings
for project written in C.

There are few features that I have to add to the engine: properties,
iterators and
arrays support using indexing suite v2.

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

Re: [pygccxml-development] finalize yet again....

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

Matthias Baas wrote:

>Hi,
>
>meanwhile it has come up a few times now in this list, but I believe the 
>finalize functionality is not yet in place, is it?
>  
>
Last time I checked it was not.  I use a rather ugly hack in goodies to 
try to force the equivalent of a finalize but I have gotten mixed results.

-Allen

>What is the current status on this? In particular, what properties will 
>control this?
>
>As you might have read already in the other thread from today, the 
>function transformation feature on non-virtual functions should 
>optionally result in the creation of a wrapper class or not. I'd say 
>this basically is already something that can be controlled by the 
>finalize functionality. So it would be nice if I could use the same 
>attributes/properties that will also be used by the other parts of Py++.
>
>- Matthias -
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>_______________________________________________
>pygccxml-development mailing list
>pyg...@li...
>https://lists.sourceforge.net/lists/listinfo/pygccxml-development
>
>  
>

Re: [pygccxml-development] How to add a new function to an individual file?

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

Roman Yakovenko wrote:
>> - module_creator/creator.py: Modify creator_t.visit_member_function() so
>> that it adds the appropriate code creator object to the list of
>> associated creators for the current class.
> 
> Yes

Currently, it means I have to insert code like this into 
visit_member_function():

     if maker_cls==code_creators.mem_fun_transformed_t:
         ....

This doesn't feel the "right" way to me, but if it's the recommended way 
(and as long as it works) I won't complain anymore... ;)

>> When the option is turned on that Py++ should always create a wrapper
>> class I also have to modify the following places:
> 
> "Turned on" means: there is at least one FT

That's not what I meant. I meant an option that controls whether the 
presence of function transformers (on non-virtual functions) result in 
the creation of a wrapper class or not. I think that's basically the 
finalize functionality (I started a new thread about this).

>> I think this is rather complex and what I don't like about it is that
>> code that belongs together is scattered over several files (even from
>> different sub-packages).
> 
> I don't think that this code "belongs" together. Think about this:
> creator_t class solves "location" problem - where the generated code
> should be logically
> written, while code creators answer the "what" question - what code
> should be created.

Just to make sure this is not a misunderstanding: I didn't mean that 
everything has to be put into one single class. There may be any number 
of separate classes or functions, each with its own responsibility. But 
it would be great if I could keep those classes together in one file 
because I still think that conceptually, this stuff belongs together 
(even though one part solves the location problem and the other part the 
"what" question, those two parts can only exist together and both is 
required to support transformed member functions).

>> Then it would be nice if it was possible to register functions that are
>> invoked by guess_mem_fun_creator_classes() and that can check if they
>> know how to handle a particular declaration, etc.
>> So all in all, it would be great if everything would be a bit more
>> extensible so that a modification like the one that I'm currently trying
>> to do could even be done externally without having to modify internal
>> Py++ code.
> 
> If you want to extend creator_t you will have to derive from it or to
> modify its
> implementation. This is the right way to do it. 

Deriving from creator_t has a few problems:

- The module builder class instantiates the creator object and it does 
that from the builtin creator_t class, not from any derived class.

- If I wanted to modify the behavior of, say, visit_member_function() I 
would have to replace the entire method. This basically means I would 
have to copy the existing code, paste it into my derived class and do my 
modifications (after I have understood what's going on in that method 
anyway). This is not what I understand by "encapsulation".

- This might just be me, but I would have considered methods like the 
visit_*() methods to be internal methods that are an implementation 
detail of the creator class. So if I have to override those internal 
methods I run the risk that my own script will be broken when used with 
future versions of Py++ where some internal stuff has been changed.


- Matthias -

[pygccxml-development] finalize yet again....

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

Hi,

meanwhile it has come up a few times now in this list, but I believe the 
finalize functionality is not yet in place, is it?

What is the current status on this? In particular, what properties will 
control this?

As you might have read already in the other thread from today, the 
function transformation feature on non-virtual functions should 
optionally result in the creation of a wrapper class or not. I'd say 
this basically is already something that can be controlled by the 
finalize functionality. So it would be nice if I could use the same 
attributes/properties that will also be used by the other parts of Py++.

- Matthias -

Re: [pygccxml-development] How to add a new function to an individual file?

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

On 9/11/06, Matthias Baas <ba...@ir...> wrote:
> Hm, so in addition to implementing the actual mem_fun_transformed_t and
> mem_fun_transformed_wrapper_t classes I have to modify code at the
> following locations:
>
> - code_creators/__init__.py: Modify guess_mem_fun_creator_classes() so
> that it returns the transformed versions when appropriate.

This function should me moved to create module_creator package and yes,
you will have to modify it

> - module_creator/creator.py: Modify creator_t.visit_member_function() so
> that it adds the appropriate code creator object to the list of
> associated creators for the current class.

Yes

> When the option is turned on that Py++ should always create a wrapper
> class I also have to modify the following places:

"Turned on" means: there is at least one FT

> - module_creator/creator.py: Modify either creator_t.visit_class() or
> creator_t._is_wrapper_needed() (or both?) so that a wrapper class is
> created when there's a member function that has function transformers
> assigned to it.

I think _is_wrapper_needed will be enough. Although I should move this function
to decl_wrappers package with explanation, why wrapper is needed.

> I think this is rather complex and what I don't like about it is that
> code that belongs together is scattered over several files (even from
> different sub-packages).

I don't think that this code "belongs" together. Think about this:
creator_t class solves "location" problem - where the generated code
should be logically
written, while code creators answer the "what" question - what code
should be created.

> I would really prefer if I could keep all my
> code local to the place where the member function code creators are
> implemented. This would simplify maintenance.

Not for me, because the responsibilities will be less clear more over
it will be difficult
to diagnose the problems.

> For example, the visit_member_function() method could invoke an
> initialization method on the code creator that allows that method to do
> the work that would otherwise be located in visit_member_function().

1. Every code creator has __init__ function
2. The only job any code creator should do is generate code. It is not
allowed to modify
    the tree, more over it is not allowed to do something else.

> Then it would be nice if it was possible to register functions that are
> invoked by guess_mem_fun_creator_classes() and that can check if they
> know how to handle a particular declaration, etc.
> So all in all, it would be great if everything would be a bit more
> extensible so that a modification like the one that I'm currently trying
> to do could even be done externally without having to modify internal
> Py++ code.

If you want to extend creator_t you will have to derive from it or to
modify its
implementation. This is the right way to do it. Please read one more
time the document,
that describes the architecture. Py++ consists from few simple and
dummy concepts. This
is the real power of it. This is your first time you add feature that
works with code creators.
I am sure that in few days you will appreciate the design.

> Or in my case where it actually is an internal modification,
> everything could be kept local to one file (or at least one sub-package).

After moving guess_... to module_creator everything will be in a
single sub-package.

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

Re: [pygccxml-development] How to add a new function to an individual file?

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

Roman Yakovenko wrote:
>> or rather: *when* can it do that?
> 
> Every function transformation consist from 2 parts: function wrapper 
> definition
> and registration, right. Take a closer look on creator_t class. When you 
> create
> relevant code creators you have to inject them to the right position.
> In your case you will
> have to add wrapper to the tree and to the associated_decl_creators.

Hm, so in addition to implementing the actual mem_fun_transformed_t and 
mem_fun_transformed_wrapper_t classes I have to modify code at the 
following locations:

- code_creators/__init__.py: Modify guess_mem_fun_creator_classes() so 
that it returns the transformed versions when appropriate.

- module_creator/creator.py: Modify creator_t.visit_member_function() so 
that it adds the appropriate code creator object to the list of 
associated creators for the current class.

When the option is turned on that Py++ should always create a wrapper 
class I also have to modify the following places:

- module_creator/creator.py: Modify either creator_t.visit_class() or 
creator_t._is_wrapper_needed() (or both?) so that a wrapper class is 
created when there's a member function that has function transformers 
assigned to it.

I think this is rather complex and what I don't like about it is that 
code that belongs together is scattered over several files (even from 
different sub-packages). I would really prefer if I could keep all my 
code local to the place where the member function code creators are 
implemented. This would simplify maintenance.
For example, the visit_member_function() method could invoke an 
initialization method on the code creator that allows that method to do 
the work that would otherwise be located in visit_member_function(). 
Then it would be nice if it was possible to register functions that are 
invoked by guess_mem_fun_creator_classes() and that can check if they 
know how to handle a particular declaration, etc.
So all in all, it would be great if everything would be a bit more 
extensible so that a modification like the one that I'm currently trying 
to do could even be done externally without having to modify internal 
Py++ code. Or in my case where it actually is an internal modification, 
everything could be kept local to one file (or at least one sub-package).

- Matthias -

Re: [pygccxml-development] How to add a new function to an individual file?

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

On 9/11/06, Matthias Baas <ba...@ir...> wrote:
> So the associated_decl_creators property seems to be what I meant above
> (a way to specify that a particular code creator belongs to the same
> file than a particular class). :)

Yes

> But there's another problem now. How can the member function creator
> obtain a reference to its parent class creator (so that it can access
> the associated_decl_creators property)

using parent property :-)

> or rather: *when* can it do that?

Every function transformation consist from 2 parts: function wrapper definition
and registration, right. Take a closer look on creator_t class. When you create
relevant code creators you have to inject them to the right position.
In your case you will
have to add wrapper to the tree and to the associated_decl_creators.

But still I prefer you to add it to the class wrapper. Please do it this way.

> During construction of the member function creator it is not yet added
> to the code creator tree, so its "parent" property isn't initialized
> yet. And when it is added later on it doesn't get notified about this
> and I haven't seen another place where it could do initializations

parent is initialized when you call adopt_creator method.

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

Re: [pygccxml-development] How to add a new function to an individual file?

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

Roman Yakovenko wrote:
>> way to specify the file that a particular code creator object belongs to
>> (personally, I think the latter would be more intuitive and fit the
>> framework better as we're already dealing with code that happens after
>> the decoration stage).
> 
> Not a best solution. I think you missed the trivial solution. Please
> read this document
> http://language-binding.net/pyplusplus/documentation/architecture.html
> and then search for associated_decl_creators string within the package.

So the associated_decl_creators property seems to be what I meant above 
(a way to specify that a particular code creator belongs to the same 
file than a particular class). :)

But there's another problem now. How can the member function creator 
obtain a reference to its parent class creator (so that it can access 
the associated_decl_creators property) or rather: *when* can it do that?
During construction of the member function creator it is not yet added 
to the code creator tree, so its "parent" property isn't initialized 
yet. And when it is added later on it doesn't get notified about this 
and I haven't seen another place where it could do initializations. The 
only methods I've seen are called after create() has been called and at 
that time we're already at the stage when the files are written, so 
that's too late for adding something to associated_decl_creators.

- Matthias -

Re: [pygccxml-development] How to add a new function to an individual file?

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

On 9/11/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> >> I'm currently trying to support the function transformers on non-virtual
> >> functions (i.e. mem_fun_t). It works fine when the corresponding class
> >> also has virtual functions so that a wrapper class gets created anyway
> >> and there's a place where I can stick the wrapper for the non-virtual
> >> function. But if Py++ does not create a wrapper then there's no "hook"
> >> where I could add the wrapper function.
> >
> > In this case Py++ should create wrapper.
>
> You mean a wrapper class, not a wrapper function, right?

Yes.

> > The code that finds out
> > whether wrapper is
> > needed or not should be moved from the factory (
> > module_creator.creator_t ) to the decl_wrapper.class_t. This is a
> > re-factoring that should be done.
>
> I agree that this refactoring is desirable and should be done, but it
> won't provide a solution to my current problem (only a workaround).
> I only want to make the wrapper function (i.e. a free function, not a
> member function) available in the corresponding source file so that it
> can be referenced in the registration function for the class. I don't
> want to force Py++ to create a wrapper class when it's not absolutely
> necessary.

I prefer to create class wrapper:
1. This will be the consistent behaviour. There are a lot of places,
where Py++ creates
    class wrapper, even if it is not absolutely necessary
2. This behaviour very easy to explain.
3. There is at least one important use-case when this behaviour makes
it easier to
    work with Py++ - integration with already existen code.

> So this either requires something like class_t.add_declaration_code()
> that is also available at the time the code creator tree is built

This is not the way design pattern "factory" works. So the answer is not.

> or a
> way to specify the file that a particular code creator object belongs to
> (personally, I think the latter would be more intuitive and fit the
> framework better as we're already dealing with code that happens after
> the decoration stage).

Not a best solution. I think you missed the trivial solution. Please
read this document
http://language-binding.net/pyplusplus/documentation/architecture.html
and then search for associated_decl_creators string within the package.

Come back  if you need more tips :-).

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

Re: [pygccxml-development] How to add a new function to an individual file?

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

Roman Yakovenko wrote:
>> I'm currently trying to support the function transformers on non-virtual
>> functions (i.e. mem_fun_t). It works fine when the corresponding class
>> also has virtual functions so that a wrapper class gets created anyway
>> and there's a place where I can stick the wrapper for the non-virtual
>> function. But if Py++ does not create a wrapper then there's no "hook"
>> where I could add the wrapper function.
> 
> In this case Py++ should create wrapper. 

You mean a wrapper class, not a wrapper function, right?

> The code that finds out
> whether wrapper is
> needed or not should be moved from the factory (
> module_creator.creator_t ) to the decl_wrapper.class_t. This is a
> re-factoring that should be done.

I agree that this refactoring is desirable and should be done, but it 
won't provide a solution to my current problem (only a workaround).
I only want to make the wrapper function (i.e. a free function, not a 
member function) available in the corresponding source file so that it 
can be referenced in the registration function for the class. I don't 
want to force Py++ to create a wrapper class when it's not absolutely 
necessary.

So this either requires something like class_t.add_declaration_code() 
that is also available at the time the code creator tree is built or a 
way to specify the file that a particular code creator object belongs to 
(personally, I think the latter would be more intuitive and fit the 
framework better as we're already dealing with code that happens after 
the decoration stage).

- Matthias -

Re: [pygccxml-development] How to add a new function to an individual file?

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

On 9/11/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > Read documentation please :-)
> > http://language-binding.net/pyplusplus/documentation/inserting_code.html#insert-code-to-class
>
> Ah, oops, sorry, I missed that one...
>
> class_t.add_declaration_code() can be considered a decoration function,
> right? So until what stage is it valid to call this function? Is it ok
> to call it *after* the actual decoration stage? I think the time when
> I'll be calling it will be while the code creator tree is just being built.

You can only call this function before code creators tree construction.


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

Re: [pygccxml-development] How to add a new function to an individual file?

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

Roman Yakovenko wrote:
> Read documentation please :-)
> http://language-binding.net/pyplusplus/documentation/inserting_code.html#insert-code-to-class 

Ah, oops, sorry, I missed that one...

class_t.add_declaration_code() can be considered a decoration function, 
right? So until what stage is it valid to call this function? Is it ok 
to call it *after* the actual decoration stage? I think the time when 
I'll be calling it will be while the code creator tree is just being built.

- Matthias -

Re: [pygccxml-development] How to add a new function to an individual file?

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

On 9/10/06, Matthias Baas <ba...@ir...> wrote:
>
> Hi,
>
> I'm currently trying to support the function transformers on non-virtual
> functions (i.e. mem_fun_t). It works fine when the corresponding class
> also has virtual functions so that a wrapper class gets created anyway
> and there's a place where I can stick the wrapper for the non-virtual
> function. But if Py++ does not create a wrapper then there's no "hook"
> where I could add the wrapper function. As far as I can tell there
> doesn't seem to be a way to add a node to the code creator tree that
> will only appear in the source file for one specific class.


Read documentation please :-)
http://language-binding.net/pyplusplus/documentation/inserting_code.html#insert-code-to-class

Would it be possible that during the creation of the code creator tree
> Py++ also creates special nodes such as, for example, translation_unit_t
> which marks the root of everything that goes into a particular file?
> Each wrapper class node would then be a children of the corresponding
> translation unit node.
> Instead of filtering out class nodes the multiple file writer would then
> have to filter out the translation unit nodes and stick everything
> beneath such a node into one file. That way, the user would have the
> option to put arbitrary nodes into one specific file.


This will not work. Take a few minutes to think about and if you don't
understand
why, I will provide the answer.


Or is there already a simple workaround to get the above behavior?


Yes, it is described in documentation.



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

[pygccxml-development] How to add a new function to an individual file?

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

Hi,

I'm currently trying to support the function transformers on non-virtual 
functions (i.e. mem_fun_t). It works fine when the corresponding class 
also has virtual functions so that a wrapper class gets created anyway 
and there's a place where I can stick the wrapper for the non-virtual 
function. But if Py++ does not create a wrapper then there's no "hook" 
where I could add the wrapper function. As far as I can tell there 
doesn't seem to be a way to add a node to the code creator tree that 
will only appear in the source file for one specific class.

Would it be possible that during the creation of the code creator tree 
Py++ also creates special nodes such as, for example, translation_unit_t 
which marks the root of everything that goes into a particular file? 
Each wrapper class node would then be a children of the corresponding 
translation unit node.
Instead of filtering out class nodes the multiple file writer would then 
have to filter out the translation unit nodes and stick everything 
beneath such a node into one file. That way, the user would have the 
option to put arbitrary nodes into one specific file.

Or is there already a simple workaround to get the above behavior?

- Matthias -

Re: [pygccxml-development] function transformation - design & implementation

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

On 9/7/06, Matthias Baas <ba...@ir...> wrote:
>
> Now that the output_arg_t example is available I have some more comments:
>
> - Is the check() method also used outside the class? The example
> suggests that it is only supposed to be used internally by
> signature_changes(). But if signature_changes() has to call that method
> explicitly anyway then why is it part of the public API?

No it is user API. Before applying some FT he can check whether it is
legal or not.

> - The code in signature_changes() looks brittle to me.

The code works only on function signature, as such it modifies the signature.

> It requests an
> operation to remove an argument and then another operation to add a
> variable with the same name as the removed argument to the result tuple.

Name is not important for return variable. The only important thing is the
number of return variables:
0 - void
1 - cpp type
1 < - tuple

>   But this looks somewhat illogical to me because the variable that is
> added to the result does not exist at that time, it was just removed by
> the previous operation. So this code depends on another operation
> (namely that a variable with a particular name gets added again) which
> is located in a separate method that is executed sometime later.

singature_changes has nothing to do with function body implementation.
( I mean variables declaration )


> - In apply() there's the line "sm. add variable to return expression".
> Isn't that the same as was already done in signature_changes()?

No

> - In the "else" block of the apply method: How does the method know
> which item of the tuple it has to access? How does it obtain the name of
> the argument? Which part of the code specified that the extraction code
> has to be put after the wrapper function call?
>
> - Obviously, apply() is called twice and receives different instances in
> "sm". It seems as if *every* implementation of apply() will require the
> if...else construct. So why isn't the method split into two methods then?

Look we have problem, that your API does not solve it too:
sometimes user works on preparing call for Python, sometimes he works
on parsing Python tuple. API should stay explicitly what user works on.

> > I did not find better names. You are right - every transformation is a
> > function transformation.
>
>  From your definitions, it's the opposite...

No. Function transformation has different role: it provides an interface for
code creators.  Simple transformation has nothing to do with code creators

> > Obviously the composition of transformations is still a
> > transformation. May you can suggest a better name?
>
> I think all is said by mentioning that transformations can be
> composed/concatenated. I don't think this requires a special name.

Yes it it. Because it provides different interface.


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

Re: [pygccxml-development] Status of code inserters

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

Allen Bierbaum wrote:
> Sounds like a well thought out plan to me.  I would be more then happy 
> to help test it out once you have it implemented and integrated into py++.

If you still want to do some initial tests you could do so with the 
current svn version. However, only public (non-pure) virtual member 
functions currently support the function transformers, all other member 
types ignore them.

There's no convenience method to add transformers to the decl_wrapper so 
you just have to manipulate the new list attribute 
"function_transformers" directly. Example:

image.member_function("get_size").function_transformers.extend([output_t(1), 
output_t(2)])

The attribute "function_transformers" is just a list that contains all 
transformers/policies that should be applied.

For the time being you also have to import the transformer objects 
explicitly:

from pyplusplus.function_transformers.arg_policies import *

After that, the following four policies are available:

- output_t(index): Argument index (1-based) is an output variable
   Example:
   C++: void getValue(int& v) or void getValue(int* v)
   Policy: output_t(1)
   -> Python: v = getValue()

- input_t(index): Argument index is an input variable
   Example:
   C++: void setValue(int& v)  or void setValue(int* v)
   Policy: input_t(1)
   -> Python: setValue(v)

- input_array_t(index, size): Handles an input array of a fixed size.
   Example:
   C++: void setVec3(double* v)
   Policy: input_array_t(1,3)
   -> Python: setVec3([x,y,z])

- output_array_t(index, size): Handles an output array of a fixed size.
   Example:
   C++: void getVec3(double* v)
   Policy: output_array_t(1,3)
   -> Python: x,y,z = getVec3()


- Matthias -

Re: [pygccxml-development] function transformation - design & implementation

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

Roman Yakovenko wrote:
> On 9/5/06, Matthias Baas <ba...@ir...> wrote:
>> Roman Yakovenko wrote:
>> > Hi. Finally I reviewed Matthias design and implementation. I propose
>> > to make some changes
>> > in its implementation. I described my thoughts in the document.
>> > 
>> http://svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/docs/peps/function_transformation.rest?view=markup 
>>
>> > Comments are welcome.

Now that the output_arg_t example is available I have some more comments:

- Is the check() method also used outside the class? The example 
suggests that it is only supposed to be used internally by 
signature_changes(). But if signature_changes() has to call that method 
explicitly anyway then why is it part of the public API?

- The code in signature_changes() looks brittle to me. It requests an 
operation to remove an argument and then another operation to add a 
variable with the same name as the removed argument to the result tuple. 
  But this looks somewhat illogical to me because the variable that is 
added to the result does not exist at that time, it was just removed by 
the previous operation. So this code depends on another operation 
(namely that a variable with a particular name gets added again) which 
is located in a separate method that is executed sometime later. But who 
guarantees that a variable with this name can actually be added at that 
later time? What if another transformer has already added a variable 
that incidentally used the same name?

- In apply() there's the line "sm. add variable to return expression". 
Isn't that the same as was already done in signature_changes()?

- In the "else" block of the apply method: How does the method know 
which item of the tuple it has to access? How does it obtain the name of 
the argument? Which part of the code specified that the extraction code 
has to be put after the wrapper function call?

- Obviously, apply() is called twice and receives different instances in 
"sm". It seems as if *every* implementation of apply() will require the 
if...else construct. So why isn't the method split into two methods then?

> I did not find better names. You are right - every transformation is a 
> function transformation.  

 From your definitions, it's the opposite...

> Obviously the composition of transformations is still a
> transformation. May you can suggest a better name?

I think all is said by mentioning that transformations can be 
composed/concatenated. I don't think this requires a special name.


- Matthias -

Re: [pygccxml-development] [To Allen] Custom smart pointers

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

Roman Yakovenko wrote:

>Hi Allen. May I ask your help with custom smart pointers?
>The Py++ unittests directory contains tester for custom smart
>pointers. I can not
>make it to work. It seems that I am missing something fundamental. Can you take
>a look on it?
>
>Thanks
>
>  
>
I haven't had time to look into this yet, but you can see everything 
that I am using for my smart pointer handling.  Just take a look at:

https://realityforge.vrsource.org/viewvc/pyopensg/trunk/src/osg_module2/OsgPtrHelpers.h?view=markup

If you still have problems I may be able to help out late this week once 
things settle down a bit.

-Allen

Re: [pygccxml-development] function transformation - design & implementation

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

On 9/5/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > Hi. Finally I reviewed Matthias design and implementation. I propose
> > to make some changes
> > in its implementation. I described my thoughts in the document.
> >
> > http://svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/docs/peps/function_transformation.rest?view=markup
> >
> > Comments are welcome.
>
> I couldn't follow all of the argumentation that is done in the first
> part, but as it was already your own conclusion that this would lead to
> a design that is too complicated anyway I don't think we have to discuss
> this any further, except for the things that also appear in the second part.

It was important for me to see "the right" solution. After this I was
able to estimate
your solution.

> I don't understand the rationale behind the separation into
> "transformation" and "function transformation" (by the way, it's also a
> bit unfortunate that they both use almost the same name. And sometimes
> the name "transformer" is used).
> Your definition of "transformation" doesn't separate it from "function
> transformation", so from reading the definitions it seems that "function
> transformation" is just a special case of a "transformation", i.e. one
> that is created by doing a composition of several transformations. But
> the result of doing this composition is still in compliance with the
> definition of "transformation".

I did not find better names. You are right - every transformation is a function
transformation.  Obviously the composition of transformations is still a
transformation. May you can suggest a better name?

> The section about function transformations in the second part of the
> document suggests that this class is just an internal helper class for
> the object that manages the application of the individual transformers.
> It seems that this class is neither directly used by the transformation
> objects

It should not be used by transformation object, the opposite is right.

>nor by the actual code creators that use this service.

Right now, but I propose to change this.

> The document is not yet detailed enough to get an overview on how the
> transformation process is done, so I can't comment on that one. From
> looking at the interface of transformer_t alone I can't see how it
> works, and the interface of the substitution manager is not given (but
> obviously it has to be different than in my implementation). Maybe an
> example would be helpful (e.g. how the "output" transformation would
> look like).

Do you want to discus this on IRC?


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

Re: [pygccxml-development] function transformation - design & implementation

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

Roman Yakovenko wrote:
> Hi. Finally I reviewed Matthias design and implementation. I propose
> to make some changes
> in its implementation. I described my thoughts in the document.
> 
> http://svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/docs/peps/function_transformation.rest?view=markup
> 
> Comments are welcome.

I couldn't follow all of the argumentation that is done in the first 
part, but as it was already your own conclusion that this would lead to 
a design that is too complicated anyway I don't think we have to discuss 
this any further, except for the things that also appear in the second part.

I don't understand the rationale behind the separation into 
"transformation" and "function transformation" (by the way, it's also a 
bit unfortunate that they both use almost the same name. And sometimes 
the name "transformer" is used).
Your definition of "transformation" doesn't separate it from "function 
transformation", so from reading the definitions it seems that "function 
transformation" is just a special case of a "transformation", i.e. one 
that is created by doing a composition of several transformations. But 
the result of doing this composition is still in compliance with the 
definition of "transformation".

The section about function transformations in the second part of the 
document suggests that this class is just an internal helper class for 
the object that manages the application of the individual transformers. 
It seems that this class is neither directly used by the transformation 
objects nor by the actual code creators that use this service.

The document is not yet detailed enough to get an overview on how the 
transformation process is done, so I can't comment on that one. From 
looking at the interface of transformer_t alone I can't see how it 
works, and the interface of the substitution manager is not given (but 
obviously it has to be different than in my implementation). Maybe an 
example would be helpful (e.g. how the "output" transformation would 
look like).

- Matthias -

[pygccxml-development] function transformation - design & implementation

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

Hi. Finally I reviewed Matthias design and implementation. I propose
to make some changes
in its implementation. I described my thoughts in the document.

http://svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/docs/peps/function_transformation.rest?view=markup


Comments are welcome.

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

[pygccxml-development] [To Allen] Custom smart pointers

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

Hi Allen. May I ask your help with custom smart pointers?
The Py++ unittests directory contains tester for custom smart
pointers. I can not
make it to work. It seems that I am missing something fundamental. Can you take
a look on it?

Thanks

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

Re: [pygccxml-development] Splitting main

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

On 9/4/06, Allen Bierbaum <al...@vr...> wrote:
> Roman Yakovenko wrote:
>
> > On 9/4/06, Allen Bierbaum <al...@vr...> wrote:
> >
> >> Roman Yakovenko wrote:
> >> > On 9/3/06, Allen Bierbaum <al...@vr...> wrote:
> >> >> Is there anyway to ask pyplusplus to split the module registration
> >> code
> >> >> in the module.main.cpp file?
> >> >>
> >> >> I have a huge number of implicit conversions, ptr_to_python and
> >> >> overloaded methods that need to be registered.  (5 per class in the
> >> >> library)  Right now I am registering those all in the main module
> >> >> registration section (by adding code through the module builder).
> >> The
> >> >> generated code works but it takes forever to compile this file.
> >> >
> >> > You can generate some cpp and header file and add the call to the
> >> main.
> >> >
> >> > mb.add_declaration_code( 'extern void register_my_xxx();' )
> >> > mb.add_registration_code( ' register_my_xxx();' )
> >>
> >> Although this would work I would rather generate all the code at the
> >> same time from the same generation script using py++.  As I understand
> >> this option I would have to generate the global scope methods
> >> separately.
> >
> >
> > No. See this document:
> > http://www.boost.org/libs/python/doc/tutorial/doc/html/python/techniques.html#python.reducing_compiling_time


> What is causing a performance problem currently is that I have to do the
> following code for every class (about 170 classes).
>
>  bp::register_ptr_to_python< osg::LineChunkPtr >();
>  bp::implicitly_convertible< osg::LineChunkRefPtr, osg::LineChunkPtr >();
>  bp::implicitly_convertible< osg::LineChunkPtr, osg::StateChunkPtr >();

You can attach these declarations to the class. They don't have to be registered
at "global" scope.

>  bp::def("RefPtr", &pyopensg::ToRefPtr<osg::LineChunkPtr>);
>  bp::def("FCPtr", &pyopensg::ToFcPtr<osg::LineChunkPtr>);

These one are the problematic ones. You can split them to different C++ files.
You can read and apply the technique described here:
http://www.boost.org/libs/python/doc/tutorial/doc/html/python/techniques.html#python.reducing_compiling_time

> This works and compiles, but there is a performance hit during compiling
> because all of these registrations happen in the module.main.cpp file.
> I was hoping there may be some way to ask Py++ to split the
> registrations in this file across multiple .cpp files.  In a way
> basically extend the existing call hierarchy another level so that
> instead of just calling the class registration methods, the code in
> module.main.cpp could be output in a way that calls several other helper
> methods that in turn call the class registration methods and module
> scope registration methods like these.
>
> It doesn't seem that this is supported though so I will investigate some
> other options.  I had tried to register some of this code with the class
> code adders in the past and it did not work.  I will try this again and
> see if I have better luck now.

Allen, I understand your problem and I don't think I have a solution,
other I described here.
May be you can take a look on class_multiple_files.py file and to
propose a patch?

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

Re: [pygccxml-development] [pygccxml-commit] SF.net SVN: pygccxml: [517] pyplusplus_dev/pyplusplus

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

On 9/4/06, Matthias Baas <ba...@ir...> wrote:
> rom...@us... wrote:
> > @@ -121,12 +121,16 @@
> >
> >          Returns a reference to the internal list (which may be modified).
> >          """
> > +        if None is self._function_transformers:
> > +            #TODO: for trivial cases get_size( int&, int& ) Py++ should guess
> > +            #function transformers
>
> On what information would such a guess be based? The declaration doesn't
> contain any reliable information about the intention of the programmer.

It is not true. You can treat both arguments as in_out:

boost::python::tuple get_size( int, int ){
    return make_tuple( ... )
}

The function "get_size" becomes callable. May be it have bad
interface, but still.

> Will the implicit guess be available when the user also attaches some
> transformers?

Program development is the interactive process. User\programmer will
see that the
interface is not optimal. Programmer will be able to come back and decide,
whether it leaves Py++ created transformations and add his own or replace  them.

> And while we're at it, just out of curiosity, why do you initialize
> _function_transformers with None instead of an empty list?

I will add "default( calculated )" transformers on first time. After
this I will not touch it
and user is responsible for it's management. See for example
class_t.indexing_suite
property.

> (to me it
> appears as if this only has disadvantages, mainly that you always have
> to test it against None if you want to access the attribute)

Please read the code:

 if None is self._function_transformers:
            #TODO: for trivial cases get_size( int&, int& ) Py++ should guess
            #function transformers
            self._function_transformers = []
 return self._function_transformers

None will be never returned from this function.


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

Re: [pygccxml-development] Splitting main

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

Roman Yakovenko wrote:

> On 9/4/06, Allen Bierbaum <al...@vr...> wrote:
>
>> Roman Yakovenko wrote:
>> > On 9/3/06, Allen Bierbaum <al...@vr...> wrote:
>> >> Is there anyway to ask pyplusplus to split the module registration 
>> code
>> >> in the module.main.cpp file?
>> >>
>> >> I have a huge number of implicit conversions, ptr_to_python and
>> >> overloaded methods that need to be registered.  (5 per class in the
>> >> library)  Right now I am registering those all in the main module
>> >> registration section (by adding code through the module builder).  
>> The
>> >> generated code works but it takes forever to compile this file.
>> >
>> > You can generate some cpp and header file and add the call to the 
>> main.
>> >
>> > mb.add_declaration_code( 'extern void register_my_xxx();' )
>> > mb.add_registration_code( ' register_my_xxx();' )
>>
>> Although this would work I would rather generate all the code at the
>> same time from the same generation script using py++.  As I understand
>> this option I would have to generate the global scope methods 
>> separately.
>
>
> No. See this document:
> http://www.boost.org/libs/python/doc/tutorial/doc/html/python/techniques.html#python.reducing_compiling_time 
>

I think there is some confusiong here, so I probably didn't make myself 
clear to start with.  I am wrapping a very large C++ library.  I have 
been splitting the code generation across multiple files for several 
years now.  (with pyste it was using the --multiple options and with 
Py++ I am using the split module capabilities).  This all works 
correctly and the split is happening.

What is causing a performance problem currently is that I have to do the 
following code for every class (about 170 classes).

 bp::register_ptr_to_python< osg::LineChunkPtr >();
 bp::implicitly_convertible< osg::LineChunkRefPtr, osg::LineChunkPtr >();
 bp::implicitly_convertible< osg::LineChunkPtr, osg::StateChunkPtr >();
 bp::def("RefPtr", &pyopensg::ToRefPtr<osg::LineChunkPtr>);
 bp::def("FCPtr", &pyopensg::ToFcPtr<osg::LineChunkPtr>);

I need these registrations and methods so the libraries use of multiple 
smart pointer types will be supported correctly. 

I am currently registering them with the module builder:

      mb.add_registration_code("bp::register_ptr_to_python< osg::%sPtr 
 >();"%cinfo.name)  
      mb.add_registration_code("bp::implicitly_convertible< 
osg::%sRefPtr, osg::%sPtr >();"%(cinfo.name,cinfo.name))  
      mb.add_registration_code("bp::implicitly_convertible< osg::%sPtr, 
osg::%sPtr >();"%(cinfo.name,cinfo.parent))  
      mb.add_registration_code('bp::def("RefPtr", 
&pyopensg::ToRefPtr<osg::%sPtr>);'%cinfo.name)
      mb.add_registration_code('bp::def("FCPtr", 
&pyopensg::ToFcPtr<osg::%sPtr>);'%cinfo.name)

This works and compiles, but there is a performance hit during compiling 
because all of these registrations happen in the module.main.cpp file.  
I was hoping there may be some way to ask Py++ to split the 
registrations in this file across multiple .cpp files.  In a way 
basically extend the existing call hierarchy another level so that 
instead of just calling the class registration methods, the code in 
module.main.cpp could be output in a way that calls several other helper 
methods that in turn call the class registration methods and module 
scope registration methods like these.

It doesn't seem that this is supported though so I will investigate some 
other options.  I had tried to register some of this code with the class 
code adders in the past and it did not work.  I will try this again and 
see if I have better luck now.

-Allen

>
>> > In this way you don't have to introduce include or something else.
>> >> In my specific case it would also work to register these methods 
>> inside
>> >> the register_XXX_class() method that is created for each exposed 
>> class,
>> >> but I would need a way to guarantee that the methods get registered
>> >> against the global module scope.
>> >
>> > Why?
>>
>> So the registered methods and conversions show up in the scope of the
>> main module.  Or can I register a global scope method within the class
>> registration code?
>
>
> Why do you care about conversions?
>
>