pygccxml-development

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

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

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. 
Will the implicit guess be available when the user also attaches some 
transformers?

And while we're at it, just out of curiosity, why do you initialize 
_function_transformers with None instead of an empty list? (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)

- Matthias -

Re: [pygccxml-development] Function Transformation - comments

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

On 9/4/06, Matthias Baas <ba...@ir...> wrote:
> > 1. code_creators.mem_fun_v_t and mem_fun_v_wrapper_t
> >     I think that for a time being it is better to derive another class
> > from calldef_t and
> >     calldef_wrapper_t. There are few reasons I think why it should be
> > done this way:
> >     1. safety - we can play as much as we want, without breaking
> > existing code
> >     2. you added a lot of code to the classes, I think we will better
> > understand the
> >         whole feature if it will be separated from the existing code.
> >
> >    So I did it for you. I did not add the code you send.
>
> I didn't do an update yet because I think this will lead to quite a few
> conflicts now (I've noticed that you modified calldef.py as well).
> So how do you want me to proceed? Stick all my stuff into the
> mem_fun_v_transformed_* classes?
> Are you planning on keeping those classes (transformed and
> non-transformed versions) separate permanently or is this only for as
> long as this is work in progress?

I don't know. Right now it seems that I will keep them forever, but
tomorrow we could
be smarter and than we will make some refactoring.

> By the way, I think the "standard" way to approach this problem would
> have been to create a branch
> (http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html). But the
> repository layout doesn't seem to be prepared for this option.

You are right, it is not prepared. We will see how it works and if
needed will create a
branch.

> > 2. I don't understand the role of substitution_manager_t, but I'd like
> > to comment
> >    on it's implementation. Why don't you use dictionary and standard
> > Python string
> >    substitution mechanism?
> >
> >    "%(return_)s" % dict( return_="123" )
>
> I didn't use this because there are some variables that may contain an
> entire block of source code (i.e. multiple lines) and each line should
> be indented with the same depth as the variable in the template string.
> Using the Python formatting functionality only the first line would have
> been indented.

If this is the only reason, than I have a solution to it - start every
variable from new
line and format its code before you pass it to the dict. After this
remove duplicate lines.

> > 3. I don't understand subst_t hierarchy.  For example code_manager_t
> > derives from
> >     subst_t.  subst_t class perform text substitutions, while
> > code_manager_t manages
> >     pieces of source code for a C++ function. It seems that subst_t
> > class should be an
> >     implementation details of code_manager_t class.
>
> You mean I should have used delegation instead of derivation?
> Well, I was considering this for a moment and decided for derivation
> because...
>
> - ...the code manager is also supposed to do substitutions but with a
> specialized set of variables. So the "is a" relationship is given.

I don't argue that they both works on strings. I argue that they have different
responcibilities and thus have to be separated.

> - ...I would have to duplicate the definition of substitute() when using
> delegation.

Implementation details.

> - ...the user still has the option to attach variables right to the code
> manager and use those for substitutions (it's a rather special case but
> who knows when it might be handy).

I am a fun of "agile software development" methodology. In our case it
means next:
we don't have use case, we don't write a code.

> > 4. function_transformer_t completely operates on string level. It does
> > not even contain
> >     reference to declaration it works on.
>
> Yes?
> (at least in my cases, I never needed to know the declaration)

And the main problem with it is that user can not understand what
transformation
does. I expected function_transformation to expose "transformed_function_type".
Thus it could be very clear what is done.

> > I expected to see something completely different. I thought about
> > defining hierarchy of
> > "transformation" classes, then the role of function_transformer_t could
> > be an
> > aggregation of all transformations that user want to do for the function
> > to convert it
> > to another function ( 1:1 ).
>
> The function transformers are individual and independent pieces of code.
> The aggregation is done by the substitution manager.

I could be wrong, but it seems that you think about function_transformer_t as
argument_policy. I will try to write a document that explains my
vision of the feature.
(Not a code, I am not going to write single line of code)

Also another problem is that you mix "configuration" classes with
classes that create
a code.

> > Obviously, user will have to write some
> > "glue code" to help
> > all these transformations to work together and we should find the right
> > place to it.
>
> What "glue code" do you mean? As mentioned above, it's the substitution
> manager that "glues" together the individual pieces.

I am not sure. I will try to explain it in the document.

> > Also, what I did not see is responsibilities and contracts. I mean you
> > wrote documentation
> > but it is not clear from the class interfaces.
>
> What parts of the interfaces didn't you understand?
>
> > 1. Why do you start to count arguments from 1 and not from zero?
>
> An index of 0 occasionally refers to the return value.

Problematic: 0 argument in Python is "self", in C++ it could be
"this". This is something
you have to explain and people will have to become accustomed.

> > 2. Why Output is not according to coding convention?
>
> Well, I left this one for the time being as this is actually a class
> that belongs into the "high level" realm and the conclusion in the wiki
> on this topic was to use the Python style guide.

I don't remember that. This is not what is written here:
https://realityforge.vrsource.org/view/PyppApi/DslDiscussion

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

Re: [pygccxml-development] Function Transformation - comments

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

Roman Yakovenko wrote:
> 0. small but important issue: in some places within code you use
>     next convention: wrapperfunc or virtualfunc. Can you separate words 
> by '_'? Thanks.

ok

> 1. code_creators.mem_fun_v_t and mem_fun_v_wrapper_t
>     I think that for a time being it is better to derive another class 
> from calldef_t and
>     calldef_wrapper_t. There are few reasons I think why it should be 
> done this way:
>     1. safety - we can play as much as we want, without breaking 
> existing code
>     2. you added a lot of code to the classes, I think we will better 
> understand the
>         whole feature if it will be separated from the existing code.
> 
>    So I did it for you. I did not add the code you send.

I didn't do an update yet because I think this will lead to quite a few 
conflicts now (I've noticed that you modified calldef.py as well).
So how do you want me to proceed? Stick all my stuff into the 
mem_fun_v_transformed_* classes?
Are you planning on keeping those classes (transformed and 
non-transformed versions) separate permanently or is this only for as 
long as this is work in progress?

By the way, I think the "standard" way to approach this problem would 
have been to create a branch 
(http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html). But the 
repository layout doesn't seem to be prepared for this option.

> 2. I don't understand the role of substitution_manager_t, but I'd like 
> to comment
>    on it's implementation. Why don't you use dictionary and standard 
> Python string
>    substitution mechanism?
> 
>    "%(return_)s" % dict( return_="123" )

I didn't use this because there are some variables that may contain an 
entire block of source code (i.e. multiple lines) and each line should 
be indented with the same depth as the variable in the template string.
Using the Python formatting functionality only the first line would have 
been indented.

> 3. I don't understand subst_t hierarchy.  For example code_manager_t 
> derives from
>     subst_t.  subst_t class perform text substitutions, while 
> code_manager_t manages
>     pieces of source code for a C++ function. It seems that subst_t 
> class should be an
>     implementation details of code_manager_t class.

You mean I should have used delegation instead of derivation?
Well, I was considering this for a moment and decided for derivation 
because...

- ...the code manager is also supposed to do substitutions but with a 
specialized set of variables. So the "is a" relationship is given.
- ...I would have to duplicate the definition of substitute() when using 
delegation.
- ...the user still has the option to attach variables right to the code 
manager and use those for substitutions (it's a rather special case but 
who knows when it might be handy). With delegation this option would 
have to be provided explicitly (with additional code).

> 4. function_transformer_t completely operates on string level. It does 
> not even contain
>     reference to declaration it works on.

Yes?
(at least in my cases, I never needed to know the declaration)

> I expected to see something completely different. I thought about 
> defining hierarchy of
> "transformation" classes, then the role of function_transformer_t could 
> be an
> aggregation of all transformations that user want to do for the function 
> to convert it
> to another function ( 1:1 ). 

The function transformers are individual and independent pieces of code. 
The aggregation is done by the substitution manager.

> Obviously, user will have to write some 
> "glue code" to help
> all these transformations to work together and we should find the right 
> place to it.

What "glue code" do you mean? As mentioned above, it's the substitution 
manager that "glues" together the individual pieces.

> Also, what I did not see is responsibilities and contracts. I mean you 
> wrote documentation
> but it is not clear from the class interfaces.

What parts of the interfaces didn't you understand?

> 1. Why do you start to count arguments from 1 and not from zero?

An index of 0 occasionally refers to the return value.

> 2. Why Output is not according to coding convention?

Well, I left this one for the time being as this is actually a class 
that belongs into the "high level" realm and the conclusion in the wiki 
on this topic was to use the Python style guide.


- Matthias -

Re: [pygccxml-development] Function transformation unit tests

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

On 9/4/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > Hi Matthias. I just added function transformation unit test. Can you
> > add the code that uses FT
> > feature to it. Thus I will be able to work on code and to commit it
> > and to be sure I did not break
> > something.
>
> I've just updated and committed the test, but currently it won't pass
> anyway. There's still the problem of obtaining the result of an override
> that returns several values (see one of my previous mails).
> And apart from that I noticed that the test takes another code path in
> mem_fun_v_t.create_function_ref_code() and that path isn't updated to
> the new feature yet. By the way, Roman, could you please explain the
> differences between those three paths? I didn't fully grasp when each
> one has to be used.
>

Now I can complain about it too :-)

1. Why do you start to count arguments from 1 and not from zero?
2. Why Output is not according to coding convention?
3. I suggest to leave class output_t, but to add convenience function
   output_only_arg( name or index ). I suggest to change output name, because
   the word "output" is over abused in programming and it is not clear
from reading
   the source code what you are trying to achieve.



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

Re: [pygccxml-development] Function transformation unit tests

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

Roman Yakovenko wrote:
> Hi Matthias. I just added function transformation unit test. Can you
> add the code that uses FT
> feature to it. Thus I will be able to work on code and to commit it
> and to be sure I did not break
> something.

I've just updated and committed the test, but currently it won't pass 
anyway. There's still the problem of obtaining the result of an override 
that returns several values (see one of my previous mails).
And apart from that I noticed that the test takes another code path in 
mem_fun_v_t.create_function_ref_code() and that path isn't updated to 
the new feature yet. By the way, Roman, could you please explain the 
differences between those three paths? I didn't fully grasp when each 
one has to be used.

- Matthias -

[pygccxml-development] Function Transformation - comments

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

Good morning.

Matthias I reviewed the code and here is my comments.

0. small but important issue: in some places within code you use
    next convention: wrapperfunc or virtualfunc. Can you separate words by
'_'? Thanks.

1. code_creators.mem_fun_v_t and mem_fun_v_wrapper_t
    I think that for a time being it is better to derive another class from
calldef_t and
    calldef_wrapper_t. There are few reasons I think why it should be done
this way:
    1. safety - we can play as much as we want, without breaking existing
code
    2. you added a lot of code to the classes, I think we will better
understand the
        whole feature if it will be separated from the existing code.

   So I did it for you. I did not add the code you send.

2. I don't understand the role of substitution_manager_t, but I'd like to
comment
   on it's implementation. Why don't you use dictionary and standard Python
string
   substitution mechanism?

   "%(return_)s" % dict( return_="123" )

   Or "..." % self.__dict__ pretty simple, less code and users already knows
this
   technique.

3. I don't understand subst_t hierarchy.  For example code_manager_t derives
from
    subst_t.  subst_t class perform text substitutions, while code_manager_t
manages
    pieces of source code for a C++ function. It seems that subst_t class
should be an
    implementation details of code_manager_t class.

4. function_transformer_t completely operates on string level. It does not
even contain
    reference to declaration it works on.

I expected to see something completely different. I thought about defining
hierarchy of
"transformation" classes, then the role of function_transformer_t could be
an
aggregation of all transformations that user want to do for the function to
convert it
to another function ( 1:1 ). Obviously, user will have to write some "glue
code" to help
all these transformations to work together and we should find the right
place to it.
I thought we will define few useful transformations and let the user to
extend them.

Also, what I did not see is responsibilities and contracts. I mean you wrote
documentation
but it is not clear from the class interfaces.

I hope you will be able to explain me all these things. Please don't stop
working on the feature.
It is very important and useful. I will try to help as much as I can. Also I
will complain and ask
stupid questions all the way :-)

I just commited few changes that will allow you to continue your work.

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

> > 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?


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


> 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?

-Allen

Re: [pygccxml-development] Splitting main

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

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();' )

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?

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

[pygccxml-development] Splitting main

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

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.

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.

Any suggestions on how to do either of these things?

Thanks,
Allen

[pygccxml-development] Function transformation unit tests

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

Hi Matthias. I just added function transformation unit test. Can you
add the code that uses FT
feature to it. Thus I will be able to work on code and to commit it
and to be sure I did not break
something.

Thanks.

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

Re: [pygccxml-development] Status of code inserters

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

Hi Matthias. I saw your code and I have few comments. Can you add small usage
example ( == unit test :-), that shows how I should use the feature.

I will review calldefs.py code you posted this evening and will assure
it will run only if there is
function_transformations defined after this I will commit it.

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

Re: [pygccxml-development] Status of code inserters

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

Roman Yakovenko wrote:
>> I haven't committed the code yet because I also did changes to Py++
>> itself (and not only pypp_api or the independent sub-package) and
>> committing everything would put Py++ into an inconsistent state where it
>> would probably break everyone else's projects.
> 
> If I understand right, you have to change: decl_wrappers,
> code_creators packages, right?

Exactly.

> If I don't use new functionality my code should continue to work, right?

Well, I cannot guarantee that because the code generated for public 
virtual member functions would definitely be different than before, even 
if you don't use function transformers. I'm not aware that it would 
break anything but I haven't tested it, so I can't say for sure.

I have just committed those parts that are just additions to Py++ (i.e. 
the new package + the decl_wrapper modification), so this shouldn't 
break anything. The missing part now is code_creators/calldef.py which I 
have attached to this mail. Currently, I have only modified the classes 
mem_fun_v_wrapper_t and mem_fun_v_t (I hope it goes through to the 
list). These classes will now produce the code from the wiki (option 3) 
which is different from the previous code, even when no function 
transformers are in use.

- Matthias -

Re: [pygccxml-development] Status of code inserters

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

Roman Yakovenko wrote:
> Matthias where is the code you are talking about? Do you want to create
> function_transformers package under pyplusplus and move all relevant code
> to it?

I haven't committed the code yet because I also did changes to Py++ 
itself (and not only pypp_api or the independent sub-package) and 
committing everything would put Py++ into an inconsistent state where it 
would probably break everyone else's projects.

Well, I could already commit the new sub-package which is currently 
called "wrapper_substitution" (would you like me to rename it to 
"function_transformers"?) and which contains the base functionality 
(i.e. the base function transformer mechanism + substitution services).
This definitely won't break any existing code. Committing calldef_t is 
also safe as it only adds features but for code_creators/calldef.py I 
would rather suggest to post that file here so that you can inspect them 
without that we get a broken version of Py++ inside the repository.

>> Yesterday and today I have already done the following things:
>>
>> - Added a property "function_transformers" to calldef_t
> 
> Do you mean decl_wrappers.calldef_t, right

Right.

>> (and while I was
>> at it I already added the property "thread_safe" as well)
> 
> Please, remove thread_safe. We will add this later.

Well, my thinking was that even though the features are mostly 
independent from each other they affect the same source code and doing 
them separately means that the very same code has to be touched twice.
Another reason is that this is rather high priority for me because it 
prevents me from doing another release of the Maya bindings (Python 
plugins currently don't work at all when multi-threading is enabled).
But I can leave this attribute only in my local copy for now, that's no 
problem.

- Matthias -

[pygccxml-development] [new feature]treatment of unused previously generated files

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

Hi. I just added new feature to Py++ - treatment to previously
generated file, that not in use
anymore.

module_builder_t.split_module function interface was changed:

def split_module(self, dir_name, huge_classes=None,
on_unused_file_found=os.remove):
    ...
    return list of written files

By default the method will delete all unused files. It also will print
to the logger every file name
it deletes. The return value of the method is a list of all written files.

Comments, bug and suggestions are welcome.

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

[pygccxml-development] [new feature]function overload macros

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

Hi. Few days ago I added support for
BOOST_PYTHON_FUNCTION_OVERLOADS
BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS
macros member and free functions.

By default this feature is off. In order to enable it you have to set
"use_overload_macro"
to True.

In most cases you should not use this feature, but when you see that
you can not load
your module because some type is still unregistered, this feature can help.

Comments, bug and suggestions are welcome.

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

Re: [pygccxml-development] Status of code inserters

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

On 9/1/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > Does it mean that you agree with proposed name?
>
> I've already started renaming the code blocks to function transformers.
> So yes, when referring to the general mechanism I have no objections to
> use the name "function transformers".

Matthias where is the code you are talking about? Do you want to create
function_transformers package under pyplusplus and move all relevant code
to it?

> > So, the whole feature is to create plug-ins into ( calldefs ) code
> > creators?
> > Nice :-)
>
> I haven't seen it that way yet, but yes, it's a valid way to look at it.
> The function transformers correspond to plugins then.

Finally I understand the feature. Thanks.

> >> By the way, yesterday I renamed the "wrapper manager" class and now I'm
> >> calling it "substitution manager" class. I think this describes the
> >> functionality better. The actual class name in the implementation is
> >> "subst_manager_t". The entire sub-package is currently called
> >> "wrapper_subst".
> >
> > This is the name I looked for! "substitution manager". One comment: do you
> > mind to write full package and class names? We always can introduce aliases
> > in Python. I think that full names are easy for maintenance.
>
> ok, I'll rename as follows:
>
> subst_manager_t -> substitution_manager_t
> wrapper_subst -> wrapper_substitution
>
> (It's just that there's usually a typo when I try to type
> "subsi^Htiut^H^Htui^Htion"... ;)

You are not alone. This is one of the reasons I use properties every where.
If I see that my script does not works as expected I can put break point
in "get" and see whether it is called or not.

> >> - The modified code might require additional include files. The caller
> >> (i.e. the Py++ code creators) must ensure that these include files
> >> actually get included.
> >
> > I plan something different here: I want to associate include files with
> > classes
>
> Sounds like a good idea!

Thanks. I will implement it before next release.

> > and other global declarations. Thus Py++ will generate better code(
> > right now
> > all cpp files contains includes of the whole project ). This feature
> > will work for our case too.
>
> Yes, my above point is still the same though. The function transformer
> will just tell the code creator that it is going to create code that
> requires include file "strawberry.h" and now it's the code creator's
> responsibility to make sure that "strawberry.h" gets included at the
> right place.

My points are:

1. creating function transformer is a task that requieres user attention to be
    concentrated on types and function imlementation. Adding something
    else to it will disturb to the user

2. Py++ will have only one way to control included files from declarations.

We can discuss this point later. The first implementation could be done as you
propose. But I propmise you we will back to it later :-)

>How this is done is up to the code creator, it may create
> another include code creator or it may use the new scheme from above.

Only code creators factory creates them. In most cases code creators
does not know about each other.

> Yesterday and today I have already done the following things:
>
> - Added a property "function_transformers" to calldef_t

Do you mean decl_wrappers.calldef_t, right

> (and while I was
> at it I already added the property "thread_safe" as well)

Please, remove thread_safe. We will add this later.

> - I modified mem_fun_v_wrapper_t and mem_fun_v_t so that the function
> transformers are used. Now the code from the wiki (option 3) is created
> for public virtual member functions. So far everything looks fine, but I
> have a slight problem with Boost.Python's override. For example, we
> might have the following code:
>
>    virtual void spam( int & n ) {
>        if( bp::override func_spam = this->get_override( "spam" ) )
>        {
>            // The Python method will return an integer
>           n = func_spam();
>        }
>        else
>        {
>          Viking::spam( n );
>        }
>    }
>
> This function will work and in this example everything is fine. But
> there might be other Python functions that return several values so the line
>
>            n = func_spam();
>
> doesn't work. So how can I invoke the function and just receive a
> boost::python::object object as result without that Boost.Python tries
> to convert it to a C++ value?
>
> I tried the following which doesn't work:
>
>            boost::python::object result = func_spam();
>
> When I run this code I get the following error:
>
> TypeError: No registered converter was able to extract a C++ reference
> to type boost::python::api::object from this Python object of type tuple
>
> Any ideas?

Please commit all your code :-).

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

Re: [pygccxml-development] Status of code inserters

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

Roman Yakovenko wrote:
> Does it mean that you agree with proposed name?

I've already started renaming the code blocks to function transformers. 
So yes, when referring to the general mechanism I have no objections to 
use the name "function transformers".

In pypp_api however, I will still keep the function setArgPolicy() for 
now as I believe this describes and documents better what the user is doing.

>> Previously, the only
>> exception would have been the thread-safety stuff, but meanwhile I think
>> this should not be implemented using the "arg policy" mechanism anyway
>> because this is not straightforward to do. Instead, I'd recommend to
>> implement that separately.
> 
> Can we put "thread safe" aside for a time being? We will come back to it.

Right, it's not a use-case for the function transformers anyway.

> So, the whole feature is to create plug-ins into ( calldefs ) code 
> creators?
> Nice :-)

I haven't seen it that way yet, but yes, it's a valid way to look at it. 
The function transformers correspond to plugins then.

>> By the way, yesterday I renamed the "wrapper manager" class and now I'm
>> calling it "substitution manager" class. I think this describes the
>> functionality better. The actual class name in the implementation is
>> "subst_manager_t". The entire sub-package is currently called
>> "wrapper_subst".
> 
> This is the name I looked for! "substitution manager". One comment: do you
> mind to write full package and class names? We always can introduce aliases
> in Python. I think that full names are easy for maintenance.

ok, I'll rename as follows:

subst_manager_t -> substitution_manager_t
wrapper_subst -> wrapper_substitution

(It's just that there's usually a typo when I try to type 
"subsi^Htiut^H^Htui^Htion"... ;)

>> - The modified code might require additional include files. The caller
>> (i.e. the Py++ code creators) must ensure that these include files
>> actually get included.
> 
> I plan something different here: I want to associate include files with 
> classes

Sounds like a good idea!

> and other global declarations. Thus Py++ will generate better code( 
> right now
> all cpp files contains includes of the whole project ). This feature
> will work for our case too.

Yes, my above point is still the same though. The function transformer 
will just tell the code creator that it is going to create code that 
requires include file "strawberry.h" and now it's the code creator's 
responsibility to make sure that "strawberry.h" gets included at the 
right place. How this is done is up to the code creator, it may create 
another include code creator or it may use the new scheme from above.

Yesterday and today I have already done the following things:

- Added a property "function_transformers" to calldef_t (and while I was 
at it I already added the property "thread_safe" as well)

- I modified mem_fun_v_wrapper_t and mem_fun_v_t so that the function 
transformers are used. Now the code from the wiki (option 3) is created 
for public virtual member functions. So far everything looks fine, but I 
have a slight problem with Boost.Python's override. For example, we 
might have the following code:

   virtual void spam( int & n ) {
       if( bp::override func_spam = this->get_override( "spam" ) )
       {
           // The Python method will return an integer
	  n = func_spam();
       }
       else
       {
         Viking::spam( n );
       }
   }

This function will work and in this example everything is fine. But 
there might be other Python functions that return several values so the line

           n = func_spam();

doesn't work. So how can I invoke the function and just receive a 
boost::python::object object as result without that Boost.Python tries 
to convert it to a C++ value?

I tried the following which doesn't work:

           boost::python::object result = func_spam();

When I run this code I get the following error:

TypeError: No registered converter was able to extract a C++ reference 
to type boost::python::api::object from this Python object of type tuple

Any ideas?

- Matthias -

Re: [pygccxml-development] [patch] import re in pyplusplus_dev/contrib/goodies/goodie_utils.py

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

Applied.  Thanks.

-Allen

Neal Becker wrote:

>Index: pyplusplus_dev/contrib/goodies/goodie_utils.py
>===================================================================
>--- pyplusplus_dev/contrib/goodies/goodie_utils.py      (revision 504)
>+++ pyplusplus_dev/contrib/goodies/goodie_utils.py      (working copy)
>@@ -14,8 +14,8 @@
> import pyplusplus.code_creators as code_creators
> import pyplusplus.decl_wrappers as decl_wrappers
> import copy
>+import re
>
>-
>
>-------------------------------------------------------------------------
>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
>
>  
>

[pygccxml-development] [patch] import re in pyplusplus_dev/contrib/goodies/goodie_utils.py

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

Index: pyplusplus_dev/contrib/goodies/goodie_utils.py
===================================================================
--- pyplusplus_dev/contrib/goodies/goodie_utils.py      (revision 504)
+++ pyplusplus_dev/contrib/goodies/goodie_utils.py      (working copy)
@@ -14,8 +14,8 @@
 import pyplusplus.code_creators as code_creators
 import pyplusplus.decl_wrappers as decl_wrappers
 import copy
+import re

-

Re: [pygccxml-development] Status of code inserters

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

On 8/31/06, Matthias Baas <ba...@ir...> wrote:
> In my current implementation the "base" class for the "arg policy"
> objects is called code_block_base_t. But something like
> func_transformer_t or similar is fine with me as well. After all, this
> class is more or less an internal class that doesn't have to be used by
> the end user, its main purpose is to document the interface that the
> user has to implement.
>
> As to the name that is exposed to the user, in the wiki and doc strings
> I'm still using the name "argument policy" as I found it still describes
> the main usages best. All the cases where I want to use this feature for
> my Maya bindings deal with arguments (including the return value =
> output argument), see the use-cases in the wiki.

Does it mean that you agree with proposed name?

>Previously, the only
> exception would have been the thread-safety stuff, but meanwhile I think
> this should not be implemented using the "arg policy" mechanism anyway
> because this is not straightforward to do. Instead, I'd recommend to
> implement that separately.

Can we put "thread safe" aside for a time being? We will come back to it.

> > * Untill this feature, the only classes that generate code were code
> > creators.
> >   Py++ design\architecture is described here
> >   (
> > http://language-binding.net/pyplusplus/documentation/architecture.html ).
> >   I prefer to stay with it, hence I ask you how you see this feature
> > is integrated  within Py++.
>
> The existing Py++ calldef code creators will still remain the code
> creators for the calldefs. What would slightly change is the way *how*
> they create their code, i.e. they would have to add some variables at
> appropriate places to the code and have that variables substituted by
> the proposed text substitution services.

So, the whole feature is to create plug-ins into ( calldefs ) code creators?
Nice :-)

> > * WrapperManager. It is presented in the document as a "Template" class.
> > From my experience it is not possible to build such class without using
> > tons of if-else statements.
>
> What do you mean with "Template" class? Are you referring to the
> template string argument that is provided by the user of the class?
> (this is just an argument name)

String substitution.

> > * Coding convention. I really don't want to introduce

> Uhm, to introduce what?
> I already tried to stick to the Py++ conventions.

Thanks, I pushed "send" button to early :-)

> By the way, yesterday I renamed the "wrapper manager" class and now I'm
> calling it "substitution manager" class. I think this describes the
> functionality better. The actual class name in the implementation is
> "subst_manager_t". The entire sub-package is currently called
> "wrapper_subst".

This is the name I looked for! "substitution manager". One comment: do you
mind to write full package and class names? We always can introduce aliases
in Python. I think that full names are easy for maintenance.

> > * To create design. I'd like to see classes and methods, with
> > responcibility
> >  description. This will give us an ability to split the work. Also we
> > will be able
> >  to take a use case and to see what code user will have to write in order
> >  to apply a transformation.
>
> At the lowest level, there is the substitution manager class (formerly
> known as wrapper manager) which has to be used by the Py++ code creators
> to "enhance" their generated code (see the wiki for examples). Some
> things to note here:
>
> - The modified code might require additional include files. The caller
> (i.e. the Py++ code creators) must ensure that these include files
> actually get included.

I plan something different here: I want to associate include files with classes
and other global declarations. Thus Py++ will generate better code( right now
all cpp files contains includes of the whole project ). This feature
will work for our
case too.

> - There might be some additional support code necessary that is
> generated by the substitution manager. But I think this can probably be
> handled much in the same way as the previous point, so it's not really a
> new point.
>
> - The modified code (at least the wrapper) might have a different
> signature than the original code. The Py++ code creators have to deal
> with this. In particular, it might happen that two overloaded functions
> end up with the same signature.

Not a problem.

> - The user might add "arg policies" to methods that wouldn't have
> spawned a wrapper function otherwise. So the presence of policies is
> already a sufficient condition for the creation of a wrapper function.
>
>
> I have already implemented the substitution sub-package (see the wiki),
> but the integration into the Py++ code is not yet done.
>

I will take a look on it pretty soon.

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

Re: [pygccxml-development] Registration order issue

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

[snip]

>>
>> The problem is that the registration ordering method doesn't seem to
>> know that the wrapper for the NullFieldContainerPtr needs to be
>> registered before this default argument can be registered. (notice: the
>> type of destination is osg::ImagePtr which has an implicit conversion
>> method ,ie. constructor, that allows it to be filled from a
>> NullFieldContainerPtr)
>>
>> Any ideas?
>
>
> Yes. First of all this is the problem with boost.python library. I am
> trying to solve
> it, but it will take some time.
>
> Second, you are going to be a tester of new feature I just added:
> createMipmap.use_overload_macro = True
>
> Take a look on generated code. I am sure this will work for you.
>
That seems to have worked.  Thanks for the quick reply. :)

-Allen

Re: [pygccxml-development] Registration order issue

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

On 8/31/06, Allen Bierbaum <al...@vr...> wrote:
> I think I just ran into a bug in registration ordering.
>
> I am using a library with it's own smart pointer hierarchy.  I have a
> class that is being registered.  One of the methods exposed by that
> class takes a default argument.  The type of that argument is a smart
> ptr to an instance of the same class.  The default value used with it is
> a const global variable of a type that is convertible to that type but
> represents a NULL smart ptr.
>
> So something like this:
>
> template <class T> FCPtr;
> typedef FCPtr<Image> ImagePtr;
> class NullFieldContainerPtr;
> const NullFieldContainerPtr  NullFC;
>
> --- method -----
>
>  { //::osg::Image::createMipmap
>
>             typedef bool ( ::osg::Image::*createMipmap_function_type )(
> ::osg::Int32,::osg::ImagePtr ) ;
>
>             Image_exposer.def(
>                 "createMipmap"
>                 , createMipmap_function_type( &::osg::Image::createMipmap )
>                 , ( ::boost::python::arg("level")=(int)(-1),
> ::boost::python::arg("destination")=osg::NullFC )
>                 , ::boost::python::default_call_policies() );
> }
>
> The problem is that the registration ordering method doesn't seem to
> know that the wrapper for the NullFieldContainerPtr needs to be
> registered before this default argument can be registered. (notice: the
> type of destination is osg::ImagePtr which has an implicit conversion
> method ,ie. constructor, that allows it to be filled from a
> NullFieldContainerPtr)
>
> Any ideas?

Yes. First of all this is the problem with boost.python library. I am
trying to solve
it, but it will take some time.

Second, you are going to be a tester of new feature I just added:
createMipmap.use_overload_macro = True

Take a look on generated code. I am sure this will work for you.

> -Allen



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

[pygccxml-development] Registration order issue

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

I think I just ran into a bug in registration ordering.

I am using a library with it's own smart pointer hierarchy.  I have a 
class that is being registered.  One of the methods exposed by that 
class takes a default argument.  The type of that argument is a smart 
ptr to an instance of the same class.  The default value used with it is 
a const global variable of a type that is convertible to that type but 
represents a NULL smart ptr.

So something like this:

template <class T> FCPtr;
typedef FCPtr<Image> ImagePtr;
class NullFieldContainerPtr;
const NullFieldContainerPtr  NullFC;

--- method -----

 { //::osg::Image::createMipmap
       
            typedef bool ( ::osg::Image::*createMipmap_function_type )( 
::osg::Int32,::osg::ImagePtr ) ;
           
            Image_exposer.def(
                "createMipmap"
                , createMipmap_function_type( &::osg::Image::createMipmap )
                , ( ::boost::python::arg("level")=(int)(-1), 
::boost::python::arg("destination")=osg::NullFC )
                , ::boost::python::default_call_policies() );
}

The problem is that the registration ordering method doesn't seem to 
know that the wrapper for the NullFieldContainerPtr needs to be 
registered before this default argument can be registered. (notice: the 
type of destination is osg::ImagePtr which has an implicit conversion 
method ,ie. constructor, that allows it to be filled from a 
NullFieldContainerPtr)

Any ideas?


-Allen

Re: [pygccxml-development] Feature request: Return list of files created by module builder

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

On 8/31/06, Allen Bierbaum <al...@vr...> wrote:
> I have run into a build problem that led me to a feature idea.
>
> I would like to see a way to have the module_builder_t.split_module()
> method return a list of all the files it created.
>
> I have been running into a problem lately where a later run of my
> generation script may generate a different set of source files then a
> previous run.  (for example removing a class)  Py++ correctly generates
> the new code, but the old .cpp files are still in the source tree and
> get picked up by my build.  If module builder returned a list of files,
> then I could check this against the files on disk and automatically
> remove old files that I don't need anymore.
>
> Thoughts?  Anyone else think this would be useful or do you use another
> way to achieve the same results?

I think this could be useful. Do you always want to remove/delete not in use cpp
files? I am not sure.
I propose next changes:

def split_module( ..., on_unused_file_found=os.remove ):
    ...
    find out unused files
    for f in unused_files:
        try:
            on_unused_file_found( f )
        catch exception, report to user and continue
    return list of generated files

I also want to propose how to implement this feature:
multiple_files_t should define write_my_file ( better name is needed ) function:
  def write_my_file( self, fpath, content ):
    self.generated_files.append( fpath )
    call to writer_t.write_file method

Of course multiple_files_t and class_multiple_files_t should be updated to
use new function.

Allen, I think it will take only few hours to implement this feature.

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