pygccxml-development

[pygccxml-development] Problem with typedefs

[Rodrigue C. <rod...@ho...>]

Hi Roman,

It seems I have found a bug with typedefs. When using typedef types in =
default arguments, the namespace qualifier gets lost on the default =
argument.=20

The following code will produce the error:
  namespace core {
   struct foo {
    foo(){}
   };
   typedef foo fooType;
  }

  void* func( const core::fooType& position =3D core::fooType() );
Will produce the following. Notice that fooType should be =
core::fooType().         =20
  bp::def( "func"
          , &func
          , ( bp::arg("arg0")=3DfooType() )
          , bp::return_value_policy< bp::return_opaque_pointer, =
bp::default_call_policies >() );

  =20
Not using the typedef produces the correct output.

  void* func2( const core::foo& position =3D core::foo()  );

  bp::def( "func2"
          , &func2
          , ( bp::arg("arg0")=3D::core::foo( ) )
          , bp::return_value_policy< bp::return_opaque_pointer, =
bp::default_call_policies >() );

I will look on my side to see if I can fix it but I am still learning =
the library :)

Thanks for the great work.

Rod

Re: [pygccxml-development] How to customize log messages?

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

Roman Yakovenko wrote:
>> I'm sorry, I'm afraid I don't understand your argument here. You only
>> seem to argue that some logging functionality is required. And of
>> course, I fully agree with that and I've never questioned that.
>> The only thing I don't understand yet is the rationale behind the
>> "_logging_" module. Where does _logging_ have advantages over the
>> standard logging module and using some standardized logger names within
>> pygccxml/pyplusplus?
> 
> Okay, I was not clear. _logging_ module solves 2 technical problems:
> 1. I want some module/package that will be independent on all other packages,
>     because I want to use it in every ( well almost every other ) module within
>     pyplusplus

This requirement is already met by the standard logging module, isn't it?
The standard logging module appears to be even better suited because it 
is even independent on pyplusplus whereas _logging_ is part of 
pyplusplus and cannot be used by pygccxml.

> 2. I want to keep code that configure the loggers in one place.

Granted. But your requirement doesn't specify where this place should be 
located, so this point would also be met if you put the configuration in 
the main __init__.py file, for example.

>> what does pygccxml use for writing log messages?.
> 
> 1. Command line used to run GCC-XML.
> 2. Report different stage: compile, link

Sorry, my question was not what messages does pygccxml output but what 
mechanism does it use to output the messages? (because it cannot use the 
_logging_ module as this one is part of pyplusplus and pygccxml is 
supposed to be independent of pyplusplus)

- Matthias -

Re: [pygccxml-development] array_t vs pointer_t

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

Roman Yakovenko wrote:
>>> An other way to solve this issue is to create small parser, that will parse all
>>> header files and will create table with relevant information. Then you
>>> can just use
>>> that information from your script.
> 
> I glad you found this solution simple and useful.

Not really simple, but definitely useful... ;)

>> Now I have the problem that the argument policy mechanism sometimes
>> produces wrapper methods that are ambiguous. Looks like I have to
>> improve my prototype so that it recognizes these cases and asks for user
>> help.
> 
> Can you post example in relevant thread? ( Where we discuss the feature ).

The problem is not in pyplusplus, it's in my own code. For example, I 
have functions like this:

  void getValue(int& val)
  void getValue(double& val)

When I apply the Output(1) policy, both wrappers look identical (except 
for their return value, but there are also examples where even the 
return value is identical):

  int getValue_wrapper()
  double getValue_wrapper()

But meanwhile, I've updated my code so that these clashes are recognized 
and reported (and can then be resolved manually).
After fixing a series of smaller issues in my code it seems to compile 
again.... (but I can only say for sure in about an hour or so when 
compilation is done)...

[contrib dir]
> Go ahead. I like this idea. I saw it in docutils.

ok. Do you already know when you will move the code over to svn? (I will 
wait until this is done. By the way, I will also wait with updating the 
setup scripts (so that they can be used for the source distributions) 
until the transition is finished)

- Matthias -

Re: [pygccxml-development] How to customize log messages?

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

On 4/20/06, Matthias Baas <ba...@ir...> wrote:
> Sorry for the delay on this topic, but other stuff has just been more
> urgent during the last couple of days...

This is okay.

> Roman Yakovenko wrote:
> >> Well, I had a look at _logging_ and noticed that it's not quite true
> >> that one cannot set the verbosity level. As the standard logging modul=
e
> >> is used I can obtain the logger and adjust the level (I don't know if
> >> setting the level to DEBUG by default is such a good idea...).
> >
> > I did not think about this a lot. But I prefer to leave it as is. You
> > are an experience
> > user of pyplusplus, other developers are not. So I think they will be g=
lad
> > to see so many log messages at least one week. After this they will inc=
rease
> > log messages level.
>
> If they will find out how to do it.... ;-)

They do, trust me. Maximum if we will see a lot of mails on this topic we w=
ill
change our default.

> >> The presence of the _logging_ module suggests that you already have so=
me
> >> plans concerning log messages in pygccxml/pyplusplus. What plans do yo=
u
> >> have how logging should be done? (or if there are no plans, why didn't
> >> you use the logging module directly?)
> >
> > Tool chain. I would like to see people start integrate code generation =
within
> > their build process. Thus dedicating some logger to pygccxml/pyplusplus=
 will
> > allow them better control on process.
> >
> > As I already said, in future we will add under main/root project
> > logger, loggers for
> > some specific packages. Thus you will have only one point to configure
> > all loggers
> > for whole code generator.
> >
> > Does it make sense? Do you agree with this. If so, I will add to "todo.=
txt" this
> > explanation. So someone will be ale to implement this.
>
> I'm sorry, I'm afraid I don't understand your argument here. You only
> seem to argue that some logging functionality is required. And of
> course, I fully agree with that and I've never questioned that.
> The only thing I don't understand yet is the rationale behind the
> "_logging_" module. Where does _logging_ have advantages over the
> standard logging module and using some standardized logger names within
> pygccxml/pyplusplus?

Okay, I was not clear. _logging_ module solves 2 technical problems:
1. I want some module/package that will be independent on all other package=
s,
    because I want to use it in every ( well almost every other ) module wi=
thin
    pyplusplus
2. I want to keep code that configure the loggers in one place.

That is why I introduced _logging_ package. This is the best name I had.
I am not going to reinvent the wheel and use Python build in logging module=
.

> I even think using the Python logging module directly has the advantage
> that pygccxml/pyplusplus can use one common logging mechanism whereas so
> far, _logging_ is only available in pyplusplus

If user wants pyplusplus/pygccxml to write into his logger, it is very simp=
le:
_logging_.logger =3D custom_logger

That's all

>what does pygccxml use for writing log messages?.

1. Command line used to run GCC-XML.
2. Report different stage: compile, link

> - Matthias -
>

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

Re: [pygccxml-development] array_t vs pointer_t

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

On 4/20/06, Matthias Baas <ba...@ir...> wrote:
> > An other way to solve this issue is to create small parser, that will p=
arse all
> > header files and will create table with relevant information. Then you
> > can just use
> > that information from your script.

I glad you found this solution simple and useful.

> I took this route and meanwhile I've implemented it. So obtaining the
> array size is no problem anymore and I could assign argument policies
> automatically to most methods.

Those are good news. But as for me, the better news is that you did it
using some custom program and then share this knowledge with code generator=
.
This is really grate. This was one of my goals.

> Now I have the problem that the argument policy mechanism sometimes
> produces wrapper methods that are ambiguous. Looks like I have to
> improve my prototype so that it recognizes these cases and asks for user
> help.

Can you post example in relevant thread? ( Where we discuss the feature ).

> But at least obtaining the array size (what this thread was actually
> about) works fine.
> By the way, maybe this code might be useful to some users at some point,
> so I think it might be worth sharing eventually. But I don't think it's
> really general and stable enough to be part of the official pyplusplus
> package, so how about adding a "contrib" directory when the code is
> moved to svn (maybe pyplusplus_dev/contrib) where contributions from
> users could be put that is not "good enough" yet for the official
> package but that might still be useful to the community either as an
> example for something or as a basis for tailoring it to their own
> projects? This will be code that does not have to be maintained or
> supported by yourself (Roman) but users have the option to use it "at
> their own risk".
> Such a scheme is used by ODE (Open Dynamics Engine) and only
> occasionally is code from contrib moved to the main branch when it
> proves to be useful and becomes stable.

Go ahead. I like this idea. I saw it in docutils.

> - Matthias -

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

Re: [pygccxml-development] How to customize log messages?

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

Sorry for the delay on this topic, but other stuff has just been more 
urgent during the last couple of days...

Roman Yakovenko wrote:
>> Well, I had a look at _logging_ and noticed that it's not quite true
>> that one cannot set the verbosity level. As the standard logging module
>> is used I can obtain the logger and adjust the level (I don't know if
>> setting the level to DEBUG by default is such a good idea...).
> 
> I did not think about this a lot. But I prefer to leave it as is. You
> are an experience
> user of pyplusplus, other developers are not. So I think they will be glad
> to see so many log messages at least one week. After this they will increase
> log messages level.

If they will find out how to do it.... ;-)

>> The presence of the _logging_ module suggests that you already have some
>> plans concerning log messages in pygccxml/pyplusplus. What plans do you
>> have how logging should be done? (or if there are no plans, why didn't
>> you use the logging module directly?)
> 
> Tool chain. I would like to see people start integrate code generation within
> their build process. Thus dedicating some logger to pygccxml/pyplusplus will
> allow them better control on process.
> 
> As I already said, in future we will add under main/root project
> logger, loggers for
> some specific packages. Thus you will have only one point to configure
> all loggers
> for whole code generator.
> 
> Does it make sense? Do you agree with this. If so, I will add to "todo.txt" this
> explanation. So someone will be ale to implement this.

I'm sorry, I'm afraid I don't understand your argument here. You only 
seem to argue that some logging functionality is required. And of 
course, I fully agree with that and I've never questioned that.
The only thing I don't understand yet is the rationale behind the 
"_logging_" module. Where does _logging_ have advantages over the 
standard logging module and using some standardized logger names within 
pygccxml/pyplusplus?

I even think using the Python logging module directly has the advantage 
that pygccxml/pyplusplus can use one common logging mechanism whereas so 
far, _logging_ is only available in pyplusplus (what does pygccxml use 
for writing log messages?).

- Matthias -

Re: [pygccxml-development] array_t vs pointer_t

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

Roman Yakovenko wrote:
>>>> I'm wrapping a method that takes one single argument of type "double
>>>> scale[3]". In the argument list of the corresponding declaration object
>>>> this appears as a pointer_t object with a double_t object as base. What
>>>> I'm missing is the '3'.
>>>> I noticed that pyplusplus defines a type array_t. Shouldn't the above
>>>> argument be an array_t instead of a pointer_t to a double? Is this a bug
>>>> in pyplusplus, in gccxml or something else?
>>> I could be wrong, but this is how C/C++ works. Array is passed by pointers.
>>> Am I wrong? Even if I wrong, GCC-XML reports this.
>> That's too bad. :( The array size would have been a valuable piece of
>> information for creating the wrappers. Without them I have to wade
>> through ~250 methods manually to check if the arguments are really plain
>> pointers or fixed size arrays as above (which seems to be the majority
>> of cases in the Maya SDK)...
> 
> [...]
> An other way to solve this issue is to create small parser, that will parse all
> header files and will create table with relevant information. Then you
> can just use
> that information from your script. 

I took this route and meanwhile I've implemented it. So obtaining the 
array size is no problem anymore and I could assign argument policies 
automatically to most methods.

Now I have the problem that the argument policy mechanism sometimes 
produces wrapper methods that are ambiguous. Looks like I have to 
improve my prototype so that it recognizes these cases and asks for user 
help.

But at least obtaining the array size (what this thread was actually 
about) works fine.
By the way, maybe this code might be useful to some users at some point, 
so I think it might be worth sharing eventually. But I don't think it's 
really general and stable enough to be part of the official pyplusplus 
package, so how about adding a "contrib" directory when the code is 
moved to svn (maybe pyplusplus_dev/contrib) where contributions from 
users could be put that is not "good enough" yet for the official 
package but that might still be useful to the community either as an 
example for something or as a basis for tailoring it to their own 
projects? This will be code that does not have to be maintained or 
supported by yourself (Roman) but users have the option to use it "at 
their own risk".
Such a scheme is used by ODE (Open Dynamics Engine) and only 
occasionally is code from contrib moved to the main branch when it 
proves to be useful and becomes stable.

- Matthias -

Re: [pygccxml-development] Feature proposal: "Argument policies"

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

Matthias Baas wrote:
> More policies can be defined as appropriate. For example, variants of 
> the InputArray/OutputArray policies could take the array size from an 
> additional argument.

Roman Yakovenko wrote:
> I'd like to add next example, from what you can see that argument
> policies should be able to deal with more complex case:
> 
> //read from some file
> int read( byte* buffer, unsigned int buffer_size );
> 
> This is very interesting use case for "argument policies", because we
> should deal
> with two arguments at the same time. The generated code will not be
> very different
> from code generated by using OutputArray/InputArray policies.

This is an example of what I meant with the above statement from my 
initial mail.
My current prototype allows that already. An argument policy isn't 
restricted to a single argument but it can deal with as many arguments 
as it likes.

The interface of the argument policy class has four methods that each 
policy has to implement:

- prepareWrapper(wm): This method can do changes to the signature of the 
wrapper function (like adding or removing arguments, for example).

- preCall(wm): This method has to return C++ source code that is put 
before the original function invocation

- postCall(wm): This method has to return C++ source code that is put 
after the original function invocation

- cleanup(wm): This method has to return C++ source code that contains 
cleanup code in the case an error has occurred somewhen after the 
preCall() code but before the postCall() code (which won't get executed).

The argumen 'wm' is an instance of a "WrapperManager" class that can be 
seen as the code creator for the entire wrapper function. It has some 
attributes and methods that can be used by the policies, such as:

- removeArg(index): Removes an argument from the wrapper function

- insertArg(index, arg): Adds a new argument to the wrapper function

- appendResult(varname): Adds a particular variable to the result tuple

- removeResult(varname): Removes a variable from the result tuple

- replaceCallArg(index, callstr): Replaces a variable that is used for 
the original function invocation.

- declareLocal(name, type, size=None, default=None): Declares a local 
variable and returns its actual name. To prevent name clashes, every 
variable that a policy uses must be declared.

For example, the Output class simply has to implement the 
prepareWrapper() method and only do three things:

- Remove the given argument: wm.removeArg(index)
- Declare a local variable that takes over the part of the input 
variable (the variable has the same name and base type than the original 
input variable): wm.declareLocal(name, type)
- Add the new local variable to the result: wm.appendResult(name)

> I want to say that "argument policies" feature should be rename. New
> feature should deal
> with an examples I showed. So it does not deal any more with single
> argument, but with
> whole function.
> 
> Bottom line - new name needed.
> 
> Suggestions:
> 
> [ function ] wrapper call policies
> 
> Comments?

At the beginning, I was calling them "argument transformers" and only 
later noticed that they were quite similar to "call policies" and then 
called them "argument policies" to express this similarity.
The main purpose of those classes is still to do something with the 
arguments (which includes the return value), so I don't see the 
necessity to rename them.

I'm against using "call policies" in their name because they actually 
have nothing to do with Boost.Python's call policies, so I think this 
would just lead to confusion.

- Matthias -

Re: [pygccxml-development] Feature proposal: "Argument policies"

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

On 4/19/06, Roman Yakovenko <rom...@gm...> wrote:

I'd like to add next example, from what you can see that argument
policies should be able to deal with more complex case:

//read from some file
int read( byte* buffer, unsigned int buffer_size );

This is very interesting use case for "argument policies", because we
should deal
with two arguments at the same time. The generated code will not be
very different
from code generated by using OutputArray/InputArray policies.

I can create an example, that binds between return value and some argument.

I want to say that "argument policies" feature should be rename. New
feature should deal
with an examples I showed. So it does not deal any more with single
argument, but with
whole function.

Bottom line - new name needed.

Suggestions:

[ function ] wrapper call policies

Comments?

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

Re: [pygccxml-development] Feature request

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

On Wednesday 19 April 2006 1:02 pm, Roman Yakovenko wrote:
> On 4/19/06, Neal Becker <ndb...@gm...> wrote:
> > AFAIK, these features are not already implemented.
> >
> > 1. keyword arguments
>
> It had been implemented and worked until your use case. Can you create
> small test that reproduces the problem. I'd like to fix it.

Sorry for confusion.  I haven't tried any of these features yet.  Where are 
they documented?

> Also every function has "use_keywords" property, try to set it to True
> and see what happens.
>
> > 1a. default values
>
> Same as above
>
> > 2. docstrings
>
> This the only not implemented feature. I plan to add it, but it is not
> my top priority.
> ( Hint: contribute :-) )
>

Re: [pygccxml-development] Phisical (re)design

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

On 4/19/06, Matthias Baas <ba...@ir...> wrote:
> Having some sort of config file for the unit tests is ok. The question
> is, if this file should be under cvs control or not. Personally, I think
> it should not be in cvs because the contents of that file depend on the
> user's environment and every user who wants to run the unit tests needs
> a different file anyway.

1. I think, that this file should be svn( :-) ) control:
    every user developer should see what he/she should change in order
to run unit tests

2. I think, that this file will contain my and your settings, so you
will be able to run
    unit tests too.

> >> What is this file used for?
> >>> |    |    |----scripts/
> >> Currently, this directory is not a sub-package and the files in this
> >> directory are not meant to be imported. That's why I'd suggest to move
> >> this directory up one level.
> >
> > May be I missed that, so scripts will sit in the same directory where s=
etup.py?
>
> That's what I would do. (You may put it into some other directory if you
> want, the point is just that it is not inside the 'pyplusplus' directory)

I've got it. Thanks

> > I have question. pyplusplus depends on other software: boost, EasyBMP,
> > TnFOX and I can add something in the future.
>
> When you say 'pyplusplus' you obviously mean the entire contents of the
> cvs repository, right? (whereas when I read 'pyplusplus' I only think of
> the actual Python package (including pygccxml))
> The above are not required for users of pyplusplus who create their own
> bindings. It's only required if someone wants to run the examples you
> provided (or if someone really wants those libraries in Python).
>
> > I expose whole functionality found in
> > that libraries, except TnFOX ) to Python. So, those packages become
> > useful and valuable on their own.
> >
> > How I should manage ( location within directory tree, for example )
> > those 3rd party libraries?
>
> Is the main intention of those bindings to serve as an example for
> pyplusplus or to create bindings that are really meant to be used on
> their own (and that are maintained by yourself)?

The second one.

> In the former case I would suggest to leave them in an examples
> directory and in the latter case I would argue that they don't belong
> into the pyplusplus repository and you might instead consider
> registering one or more new SF projects for them.

I will think about this.

> - Matthias -


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

Re: [pygccxml-development] Feature request

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

On 4/19/06, Neal Becker <ndb...@gm...> wrote:
> AFAIK, these features are not already implemented.
>
> 1. keyword arguments

It had been implemented and worked until your use case. Can you create
small test that reproduces the problem. I'd like to fix it.

Also every function has "use_keywords" property, try to set it to True
and see what happens.

> 1a. default values

Same as above

> 2. docstrings

This the only not implemented feature. I plan to add it, but it is not
my top priority.
( Hint: contribute :-) )

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

Re: [pygccxml-development] Phisical (re)design

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

Roman Yakovenko wrote:
> On 4/18/06, Matthias Baas <ba...@ir...> wrote:
>> Roman Yakovenko wrote:
>>> pyplusplus_dev/
>>> |    |----environment.py #containes paths to boost  and pygccxml
> 
> pyplusplus unit tests have external dependencies: boost libraries,
> scons, location
> of header files. This file should contain this information. I don't
> like this approach.
> The second approach I considered was environment variables - I hate
> it. So I am going
> with the first one. If you have better idea, and obvious you do, then
> share it :-)

Having some sort of config file for the unit tests is ok. The question 
is, if this file should be under cvs control or not. Personally, I think 
it should not be in cvs because the contents of that file depend on the 
user's environment and every user who wants to run the unit tests needs 
a different file anyway.

>> What is this file used for?
>>> |    |    |----scripts/
>> Currently, this directory is not a sub-package and the files in this
>> directory are not meant to be imported. That's why I'd suggest to move
>> this directory up one level.
> 
> May be I missed that, so scripts will sit in the same directory where setup.py?

That's what I would do. (You may put it into some other directory if you 
want, the point is just that it is not inside the 'pyplusplus' directory)

>> What's the difference between docs/tutorials and tutorials?
> 
> I want to create full separation between code and documentation.
> 
> docs directory contains documentation for whole project, including
> examples, tutorials and
> whatever.
> 
> All other directories contains code.

ok, I see.

> I have question. pyplusplus depends on other software: boost, EasyBMP,
> TnFOX and I can add something in the future. 

When you say 'pyplusplus' you obviously mean the entire contents of the 
cvs repository, right? (whereas when I read 'pyplusplus' I only think of 
the actual Python package (including pygccxml))
The above are not required for users of pyplusplus who create their own 
bindings. It's only required if someone wants to run the examples you 
provided (or if someone really wants those libraries in Python).

> I expose whole functionality found in
> that libraries, except TnFOX ) to Python. So, those packages become
> useful and valuable on their own.
> 
> How I should manage ( location within directory tree, for example )
> those 3rd party libraries?

Is the main intention of those bindings to serve as an example for 
pyplusplus or to create bindings that are really meant to be used on 
their own (and that are maintained by yourself)?
In the former case I would suggest to leave them in an examples 
directory and in the latter case I would argue that they don't belong 
into the pyplusplus repository and you might instead consider 
registering one or more new SF projects for them.

- Matthias -

[pygccxml-development] Feature request

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

AFAIK, these features are not already implemented.

1. keyword arguments

1a. default values

2. docstrings

Typically, when I write a python wrapper for a function, I enhance it by 
adding keyword arguments and maybe default values.

Here is an example:

template<typename in_cont_t, typename coef_cont_t, typename out_cont_t>
out_cont_t inline do_Corr (in_cont_t const& in, coef_cont_t const& coef, 
size_t size, int stride) {
  out_cont_t out (size);
  Corr (boost::begin(in), boost::begin (coef), boost::end (coef), boost::begin 
(out), boost::end (out), stride);

  return out;
}

BOOST_PYTHON_MODULE(corr_wrap) {
  def ("Corr", 
&do_Corr<ublas::vector<Complex>,ublas::vector<Complex>,ublas::vector<Complex> 
>,
       default_call_policies(), 
       (
	arg ("in"),
	arg ("coef"),
	arg ("size"),
	arg ("stride")=1
	)
       );

  def ("Corr", 
&do_Corr<ublas::vector<double>,ublas::vector<double>,ublas::vector<double> >,
       default_call_policies(), 
       (
	arg ("in"),
	arg ("coef"),
	arg ("size"),
	arg ("stride")=1
	)
       );
}

Re: [pygccxml-development] Feature proposal: "Argument policies"

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

On 4/18/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
> So my suggestion is to introduce something similar to call
> policies, that's why I called it "argument policies". The idea is just
> that for each "problematic" argument you specify that it needs special
> treatment.

I like the idea and the name you gave it. It is easy to understand and expl=
ain.
I think, this will be the focus of next release.

Before we proceed to technical details, I suggest everyone, who is
interested in this
should review two code creators: function_t and function_wrapper_t
within code_creators/calldefs.py file.

> I have already implemented a prototype version of this in the
> experimental module. So far, it has worked quite fine for my Maya
> bindings (by the way, I have just released a first "preview" version of
> those bindings, so if anybody wants to have a look how I create them,
> have a look at the 'maya' package over here: http://cgkit.sourceforge.net=
/)

:-). I will definitely take a look. It seems that we can start "who is
using pyplusplus?" list.
Who does want to contribute :-) ?

> Currently, my implementation would not work when a class already
> receives wrappers generated by pyplusplus. But I think this could be
> changed so that the wrappers created by pyplusplus use the same
> framework for specifying wrapper source code (but this needs
> modification inside pyplusplus).
>
> The above argument policies use the same "code creator" concept that
> pyplusplus already uses, the interface of those code creators is just
> different because there are actually two places where code can be
> placed, either before or after the original function invocation. And in
> addition to creating code, those special code creators can also modify
> the signature of a function. So pyplusplus would have to use those
> special code creators instead of just creating one static block of C++
> source code for the entire wrapper function.

Right

> Any comments? Do you already see cases where this could not work or how
> it could be improved?

I hope next week, I will write some PEP. Now I just want to comment the fea=
ture.

Please take a look on the classes ( function_t and function_wrapper_t ).
They are tightly coupled and contains code that treat a lot of use cases:

When generating code pyplusplus should consider

1. [ virtual | pure virtual | not virtual ]
    Different code should be generated for different access types/

2. [ public | protected | private ]
Yes, private pure virtual and private virtual functions should/could
be exposed. See
"template method" design pattern.

3. [ static | free | member ] functions

4. operators( call (), index [] and may be something else  )

5. class hierarchy with deep more then 2 abstract classes:

struct base_abstract{
void do_smth() =3D 0;
};

struct middle_abstract : public abstract{
void do_smth_else() =3D 0;
};

Class wrapper that is built for middle_abstract should define also
"function wrappers" for
do_smth function. I can explain, why but lets leave it.

6. function return value: for example virtual function, that returns
reference to some object,
could not be overridden from Python - access violation is guaranteed.

7. template functions on broken compilers ( msvc 7.1 )
    When your expose some instantiation of template class that has
template function
    pyplusplus should define few typedefs in order to generate code,
that takes address
    of the function. It does do it right now, but this should be fixed.

8. difference between fundamental types and user defined
   ( boost::ref and boost::python::ptr ).

I am sure this is not the full list. Now we should add here argument
policies. This is not going
to be easy. I see few challenges here:

0. simple user interface

1. orthogonality, it is obvious to me, that our solution should be
constructed from
    few blocks

2. use cases enumeration

3. implementation

4. testing

It is not going to be easy, but we will have a lot of fun, I am sure.

Contribution: we can start now to create comprehensive unit tests for this.
It would be grate, If some one can write C++ code that will cover all
those use case.

> - Matthias -

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

Re: [pygccxml-development] MJ:diverses

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

On 4/18/06, Janes, Matthias <mat...@si...> wrote:
> Hi roman,
>
> 1.) First: thank you for the final
>
> pygccxml-0.7.2          April 17, 2006
> pyplusplus-0.7.1  April 17, 2006
>
> releases.
>
>
> JUST A small thought: I would prefer if the files would be having also a
> - between version number in the future.
>
> NOT like now:   pygccxml0.7.2.zip
> BUT:                    pygccxml-0.7.2.zip

This is more readable. I will try to follow this guideline.

> I will definitly need some initial help from you and maybe others like
> Matthias Baas if you both have some little time ;-)

Go ahead. I am sure you will provide some good use cases and unit tests :-)=
.

> 3.) on a personal note: I'm just installing the new free VMWARE server
> (http://www.vmware.com/) on XP (working place ;-)
>     with a copy of 'Gentoo Linux'.
>
>     if this works out fine - will not have to go through the pain of
> supporting Windows in my 'Python Integration Wrapper'
>     project. (https://sourceforge.net/projects/piw)
>
>     I will also be able to do a pit more on it next to my usual work ;-)

Good luck :-)

>
> Greetings Matthias Janes

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

Re: [pygccxml-development] Phisical (re)design

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

On 4/18/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > pyplusplus_dev/
> > |    |----environment.py #containes paths to boost  and pygccxml

pyplusplus unit tests have external dependencies: boost libraries,
scons, location
of header files. This file should contain this information. I don't
like this approach.
The second approach I considered was environment variables - I hate
it. So I am going
with the first one. If you have better idea, and obvious you do, then
share it :-)

> What is this file used for?
> > |    |    |----scripts/
>
> Currently, this directory is not a sub-package and the files in this
> directory are not meant to be imported. That's why I'd suggest to move
> this directory up one level.

May be I missed that, so scripts will sit in the same directory where setup=
.py?

\>
> What's the difference between docs/tutorials and tutorials?
>
> > |    |    |----module_builder/
> > |    |    |----...

I want to create full separation between code and documentation.

docs directory contains documentation for whole project, including
examples, tutorials and
whatever.

All other directories contains code.

> Apart from the scripts directory, everything else looks fine to me.

I have question. pyplusplus depends on other software: boost, EasyBMP,
TnFOX and I can
add something in the future. I expose whole functionality found in
that libraries, except TnFOX ) to Python. So, those packages become
useful and valuable on their own.

How I should manage ( location within directory tree, for example )
those 3rd party libraries?

> - Matthias -


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

Re: [pygccxml-development] pyplusplus is a bit too optimistic?

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

On 4/18/06, Neal Becker <ndb...@gm...> wrote:
> I used the attached .hpp file to generate the attached .cpp.
>
> I believe this .cpp would not compile.  The problem is that it includes .=
def
> of "Copy" function.  This is a template - only an explicit instantiation =
of
> it could be exposed to python.

And you are right.

> I guess I need to tell pyplusplus what functions I want exposed?

This is up to you. You can rename this function: Copy<int, int> and
then you can
succesfuly export this function.

> It would be nice if pyplusplus detected this error.  When it writes "&Cop=
y" it
> should realize there is no such function.

I thought about this and it seems to me that I have a solution. Please
comment it:
Every function contains "mangled" string. From this string, I think, I
can get all information
I need. Thus I will be able to change function name to the full one.

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

[pygccxml-development] pyplusplus is a bit too optimistic?

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

I used the attached .hpp file to generate the attached .cpp.

I believe this .cpp would not compile.  The problem is that it includes .def 
of "Copy" function.  This is a template - only an explicit instantiation of 
it could be exposed to python.

I guess I need to tell pyplusplus what functions I want exposed?

It would be nice if pyplusplus detected this error.  When it writes "&Copy" it 
should realize there is no such function.

Re: [pygccxml-development] What am I doing wrong?

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

On Tuesday 18 April 2006 2:32 pm, Roman Yakovenko wrote:
> I hope this time I provides almost complete fix for the bug.
> Description:
>
> First of all I missed some index operator on attrs - in Python
> function, that read C++ function
> declaration.
> So what happened? For some constructors GCC-XML does not generates
> "name" attribute.
> I guess he does it for compiler generated constructors or may be for
> something else.
> I still need to find out. Until now about the problem. Now about a
> solution.
>
> The solution consist from 2 parts:
> 1. to modify scanner_t.__read_calldef function:
>     calldef.name = attrs[ XML_AN_NAME ] ==> calldef.name =
> attrs.get(XML_AN_NAME, '')
> 2. to modify linker_t.visit_class member function. In this function,
> for unnamed constructors
>     pygccxml will assign class name.
>
> So why almost? Because I want to play on safe-side :-)
>
> Neal, please try it and report the problems.
>

Thanks!

At least the previous test now runs to completion.  Now on to bigger tests...

Re: [pygccxml-development] What am I doing wrong?

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

I hope this time I provides almost complete fix for the bug.
Description:

First of all I missed some index operator on attrs - in Python
function, that read C++ function
declaration.
So what happened? For some constructors GCC-XML does not generates
"name" attribute.
I guess he does it for compiler generated constructors or may be for
something else.
I still need to find out. Until now about the problem. Now about a solution=
.

The solution consist from 2 parts:
1. to modify scanner_t.__read_calldef function:
    calldef.name =3D attrs[ XML_AN_NAME ] =3D=3D> calldef.name =3D
attrs.get(XML_AN_NAME, '')
2. to modify linker_t.visit_class member function. In this function,
for unnamed constructors
    pygccxml will assign class name.

So why almost? Because I want to play on safe-side :-)

Neal, please try it and report the problems.

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

[pygccxml-development] Feature proposal: "Argument policies"

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

Hi,

here's a suggestion for a new feature that should deal with the problem 
that C++ functions that have more than just one output (by taking 
references) cannot be translated literally to Python. Even worse, they 
compile without errors but they are plain useless in Python because 
there's no way to invoke such functions.

One example of such a function is the already mentioned getSize(int& 
width, int& height) method that returns the resolution of an image.
It is my understanding that such a function requires a wrapper function 
that changes the signature so that the function takes no arguments and 
returns a Python tuple with the result.
Having to write those wrappers manually is quite a repetitive and 
tedious task. So my suggestion is to introduce something similar to call 
policies, that's why I called it "argument policies". The idea is just 
that for each "problematic" argument you specify that it needs special 
treatment. In the above case, pyplusplus needs to know that the 
arguments are actually used for output values instead of input values. 
This could be specified like this:

Image.Method("getSize").setArgPolicy(Output(1), Output(2))

setArgPolicy() is a new decorator that takes an arbitrary number of 
"argument policies" as input. The "Output" policy takes one integer as 
argument which is the index of the argument it applies to. So by writing 
"Output(1)", the user specifies that the first argument is actually an 
output value. This is already enough information so that a wrapper 
function can be created automatically. The wrapper function would take 
no arguments anymore and return two integers with the result.

Another example is a function that takes a pointer to a double as input. 
For example:

void getTranslation(double t[3])
void setTranslation(double t[3])

In the first case, 't' is an ouput argument used to store the result 
whereas in the second case 't' is an input argument. The above Output 
policy cannot be used because Python has no double[3] type. Instead, the 
wrapper needs some additional code to copy a Python sequence into a 
double array or vice versa:

cls.Method("getTranslation").setArgPolicy(OutputArray(1,3))
cls.Method("setTranslation").setArgPolicy(InputArray(1,3))

The first argument to the OutputArray/InputArray class is again the 
index of the argument this policy applies to. The second argument is the 
size of the array. These policies will then also take care of converting 
between Python sequences and C arrays.

More policies can be defined as appropriate. For example, variants of 
the InputArray/OutputArray policies could take the array size from an 
additional argument.

The nice thing about this framework is that another thing I wanted to 
have fits nicely into it. For the Maya SDK, I wanted to convert Status 
objects into exceptions. This can also be expressed with those policies 
by using a custom policy such as "MStatusToException" that adds code 
that throws an exception when an error has occurred. There can also be 
policies that do something with the return value, etc.

I have already implemented a prototype version of this in the 
experimental module. So far, it has worked quite fine for my Maya 
bindings (by the way, I have just released a first "preview" version of 
those bindings, so if anybody wants to have a look how I create them, 
have a look at the 'maya' package over here: http://cgkit.sourceforge.net/)

Currently, my implementation would not work when a class already 
receives wrappers generated by pyplusplus. But I think this could be 
changed so that the wrappers created by pyplusplus use the same 
framework for specifying wrapper source code (but this needs 
modification inside pyplusplus).
The above argument policies use the same "code creator" concept that 
pyplusplus already uses, the interface of those code creators is just 
different because there are actually two places where code can be 
placed, either before or after the original function invocation. And in 
addition to creating code, those special code creators can also modify 
the signature of a function. So pyplusplus would have to use those 
special code creators instead of just creating one static block of C++ 
source code for the entire wrapper function.

Any comments? Do you already see cases where this could not work or how 
it could be improved?

- Matthias -

Re: [pygccxml-development] Phisical (re)design

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

Roman Yakovenko wrote:
> pygccxml_dev/
> |    |----setup.py
> |    |----docs/
> |    |    |----apidocs/
> |    |----pygccxml/
> |    |    |----declarations/
> |    |    |----parser/
> |    |    |----utils/
> |    |----unittests/
> |    |    |----data/
> pyplusplus_dev/
> |    |----environment.py #containes paths to boost  and pygccxml

What is this file used for?

> |    |----setup.py
> |    |----docs/
> |    |    |----apidocs/
> |    |    |----examples/
> |    |    |----tutorials/
> |    |----pyplusplus/
> |    |    |----code_creators/
> |    |    |----code_repository/
> |    |    |----decl_wrappers/
> |    |    |----file_writers/
> |    |    |----gui/
> |    |    |----_logging_/
> |    |    |----module_builder/
> |    |    |----module_creator/
> |    |    |----scripts/

Currently, this directory is not a sub-package and the files in this 
directory are not meant to be imported. That's why I'd suggest to move 
this directory up one level.

> |    |    |----utils/
> |    |----unittests/
> |    |     |----data/
> |    |     |----generated/
> |    |----examples/
> |    |    |----pyboost_dev/
> |    |    |    |----setup.py
> |    |    |    |----pyboost/
> |    |    |    |    |----date_time/
> |    |    |    |    |    |----generated/
> |    |    |    |    |----....
> |    |    |----pyeasybmp_dev/
> |    |    |    |----setup.py
> |    |    |    |----environment.py
> |    |    |    |----pyeasybmp/
> |    |    |    |    |----generated/
> |    |    |----custom_code_creator/
> |    |    |----unittests/
> |    |----tutorials/

What's the difference between docs/tutorials and tutorials?

> |    |    |----module_builder/
> |    |    |----...
> 
> What do you think?

Apart from the scripts directory, everything else looks fine to me.

- Matthias -

[pygccxml-development] MJ:diverses

[Janes, M. <mat...@si...>]

Hi roman,

1.) First: thank you for the final

pygccxml-0.7.2  	April 17, 2006
pyplusplus-0.7.1  April 17, 2006

releases.  =20


JUST A small thought: I would prefer if the files would be having also a
- between version number in the future. =20

NOT like now: 	pygccxml0.7.2.zip    =20
BUT: 			pygccxml-0.7.2.zip



2.) in my caseI will soon be in the position to start testing the JAVA -
Pyplusplus - boost.python process.

I have finished my first project layout and are getting to the most
important question: is this with the present tools
possible at all - or do I have to switch to a 'swig' approach (with
there new version they have some initial build in java gcj support).

Personally I would prefer to stay with pyplusplus and boost.python.

I will definitly need some initial help from you and maybe others like
Matthias Baas if you both have some little time ;-)


3.) on a personal note: I'm just installing the new free VMWARE server
(http://www.vmware.com/) on XP (working place ;-)=20
    with a copy of 'Gentoo Linux'.=20

    if this works out fine - will not have to go through the pain of
supporting Windows in my 'Python Integration Wrapper'
    project. (https://sourceforge.net/projects/piw)

    I will also be able to do a pit more on it next to my usual work ;-)



Greetings Matthias Janes















>=20
> --__--__--
>=20
> Message: 1
> Date: Mon, 17 Apr 2006 15:33:48 +0300
> From: "Roman Yakovenko" <rom...@gm...>
> To: pyg...@li...
> Subject: [pygccxml-development] Phisical (re)design
>=20
> Hi. As decided, development of pyplusplus is going to switch to SVN.
>=20
> Here is a proposed phisical design for the packages. Please=20
> comment it.
> The main goal of redesign is to use Python distutils package.
>=20

Re: [pygccxml-development] What am I doing wrong?

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

Neal, I found another set of problems with GCCXML. I will fix
pygccxml/pyplusplus
and will send the patches to the list.

Sorry for inconvenience

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