pygccxml-development

[pygccxml-development] argument policies

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

Hi. Matthias I am ready to start working on argument policies.
I think we should start with "array" argument policies.

What do you think?

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

Re: [pygccxml-development] argument policies

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

On Tuesday 02 May 2006 2:26 am, Roman Yakovenko wrote:
> Hi. Matthias I am ready to start working on argument policies.
> I think we should start with "array" argument policies.
>
> What do you think?
>
> --

Personally, I don't need argument policies much.  The one I do need is:

typedef boost::mt19937 rng_t;
  class_<WrappedClass> (python_typename, desc,
			python::init<rng_t&, double>((python::arg("rng"),python::arg("var")),
						     "__init__(r,var)\n"
						     "Construct a normal deviate generator\n"
						     "@param r: Mersenne Twister\n"
						     "@type r: L{rng}\n"
						     "@param var: variance\n"
						     "@type var: float\n"
						     )
			[python::with_custodian_and_ward<1,2>()])

Here, rng_t is boost::mersenne_twister.  The wrapped object needs to hold a 
reference to a rng_t object, so we need "with_custodian_and_ward".

Re: [pygccxml-development] argument policies

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

On 5/2/06, Neal Becker <ndb...@gm...> wrote:
> Personally, I don't need argument policies much.  The one I do need is:
>
> typedef boost::mt19937 rng_t;
>   class_<WrappedClass> (python_typename, desc,
>                         python::init<rng_t&, double>((python::arg("rng"),=
python::arg("var")),
>                                                      "__init__(r,var)\n"
>                                                      "Construct a normal =
deviate generator\n"
>                                                      "@param r: Mersenne =
Twister\n"
>                                                      "@type r: L{rng}\n"
>                                                      "@param var: varianc=
e\n"
>                                                      "@type var: float\n"
>                                                      )
>                         [python::with_custodian_and_ward<1,2>()])
>
> Here, rng_t is boost::mersenne_twister.  The wrapped object needs to hold=
 a
> reference to a rng_t object, so we need "with_custodian_and_ward".

mb =3D module_builder_t( ... )
wc_constructor \
  =3D mb.constructor( name=3D"WrappedClass", arg_types=3D[None, 'double'] )
#None is used as any type, size of arg_types list used to indicate the
#number of function arguments
wc_constructor =3D module_builder.call_policies.with_custodian_and_ward()


P.S. I also creates wrapper for boost.random library. I think I will
have it ready
in week or two. Also I will expose another boost libraries.
So if you want to join efforts you are welcome.

Here http://tinyurl.com/m5puo you can find my initial script.

Roman

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

Re: [pygccxml-development] argument policies

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

Roman Yakovenko wrote:
> Hi. Matthias I am ready to start working on argument policies.
> I think we should start with "array" argument policies.
> 
> What do you think?

Can you outline how you are going to implement all this. What features 
are available? How will they be used? etc.. (sort of a design document)

Maybe I should brush up my stuff and check it back in somewhen during 
the next couple of days. Now that the new repository is in place, maybe 
it would be a good idea to move the "experimental" stuff to the 
"contrib" directory. Is that ok?
(I also have to brush up my other stuff for the contrib directory that 
determines array sizes in signatures...)

But first, I have to fix my code as it got broken by the latest check in 
(because function_t is missing)... :(

- Matthias -

Re: [pygccxml-development] argument policies

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

On 5/2/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > Hi. Matthias I am ready to start working on argument policies.
> > I think we should start with "array" argument policies.
> >
> > What do you think?
>
> Can you outline how you are going to implement all this. What features
> are available? How will they be used? etc.. (sort of a design document)

I still don't know. I am going to write a lot of C++ code - test cases.
To see how it should be wrapped. What user need/have to customize, define.
After this I hope it will be clear to me what should be done and how

> Maybe I should brush up my stuff and check it back in somewhen during
> the next couple of days. Now that the new repository is in place, maybe
> it would be a good idea to move the "experimental" stuff to the
> "contrib" directory. Is that ok?

Yes. If you don't mind I'd like next structure of the directory:
contrib
|----your name
|    | all your files/directories goes here.

> (I also have to brush up my other stuff for the contrib directory that
> determines array sizes in signatures...)

It could be nice, cause I think I will be able to integrate the code
with pygccxml

> But first, I have to fix my code as it got broken by the latest check in
> (because function_t is missing)... :(

I am really sorry for inconvenience, but it was absolutely necessary.
I think you should replace it with mem_fun_[v|pv]_t or free_function_t.


> - Matthias -
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job ea=
sier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim=
o
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> pygccxml-development mailing list
> pyg...@li...
> https://lists.sourceforge.net/lists/listinfo/pygccxml-development
>


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

Re: [pygccxml-development] argument policies

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

Roman Yakovenko wrote:
>> > Hi. Matthias I am ready to start working on argument policies.
>> > I think we should start with "array" argument policies.
>> >
>> > What do you think?
>>
>> Can you outline how you are going to implement all this. What features
>> are available? How will they be used? etc.. (sort of a design document)
> 
> I still don't know. I am going to write a lot of C++ code - test cases.
> To see how it should be wrapped. What user need/have to customize, define.
> After this I hope it will be clear to me what should be done and how

ok, of course a design document can be postponed until the actual 
problem is better understood... :)

One thing that might be useful for me at the moment would be the 
possibility for an arg policy to actually spawn another wrapper so that 
there'll be two wrappers with different signatures. For example, I have 
C++ methods that look like this:

   void get(double*)

They just return an array of a predefined size. With my current arg 
policies I can turn that into a Python method that takes no arguments 
and returns a list of floats. But meanwhile I'm also toying with the 
idea to provide an additional version of the method that takes a list as 
argument and that will fill that list with the return values. This will 
be less "Pythonic" but it's closer to the original C++ API.
I don't know if it should really be the arg policy that creates the 
additional wrapper or if it should be done by the user. For example, I 
could also imagine a way where the user can "clone" a declaration and 
then just apply a different arg policy to the clone.

> Yes. If you don't mind I'd like next structure of the directory:
> contrib
> |----your name

Do you really insist on this? What name would that be? The experimental 
stuff is not by myself alone, it's also by Allen. Personally, I would 
much prefer a directory name that's chosen after the *functionality* of 
its contents and not after its initial author(s). The latter would 
rather look as if the directory contains my private stuff, but of 
course, the directory is open to anyone and people should rather be 
encouraged to contribute to it (would we then have to rename the 
directory? ;) The authors can be mentioned in a file inside the 
directory, then it will also be clear that you are not responsible for 
that code and the list of authors can be extended if necessary.

- Matthias -

Re: [pygccxml-development] argument policies

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

On 5/3/06, Matthias Baas <ba...@ir...> wrote:
> ok, of course a design document can be postponed until the actual
> problem is better understood... :)

-:)

> One thing that might be useful for me at the moment would be the
> possibility for an arg policy to actually spawn another wrapper so that
> there'll be two wrappers with different signatures.

I think a little bit different. I think that pyplusplus should
generate only 1 wrapper
for the function. But it should be fully functional. All other
customization/conveniences should be done from Python.

For example "return status as exception" arg policies could be solved in Py=
thon.
This will also improve compilation time.

> For example, I have
> C++ methods that look like this:
>
>    void get(double*)
>
> They just return an array of a predefined size. With my current arg
> policies I can turn that into a Python method that takes no arguments
> and returns a list of floats. But meanwhile I'm also toying with the
> idea to provide an additional version of the method that takes a list as
> argument and that will fill that list with the return values. This will
> be less "Pythonic" but it's closer to the original C++ API.
> I don't know if it should really be the arg policy that creates the
> additional wrapper or if it should be done by the user. For example, I
> could also imagine a way where the user can "clone" a declaration and
> then just apply a different arg policy to the clone.

This will never work ( reliably ). py++ assumes that code is 100% correct.
Another way to solve this is to parse files, generate C++ wrapper for
the functions,
and then to parse again with generated functions wrappers.

> > Yes. If you don't mind I'd like next structure of the directory:
> > contrib
> > |----your name
>
> Do you really insist on this? What name would that be? The experimental
> stuff is not by myself alone, it's also by Allen. Personally, I would
> much prefer a directory name that's chosen after the *functionality* of
> its contents and not after its initial author(s). The latter would
> rather look as if the directory contains my private stuff, but of
> course, the directory is open to anyone and people should rather be
> encouraged to contribute to it (would we then have to rename the
> directory? ;) The authors can be mentioned in a file inside the
> directory, then it will also be clear that you are not responsible for
> that code and the list of authors can be extended if necessary.

I don't insist on this at all. I saw this structure in docutils
project. If you have
something different in mind, that is perfectly okay with me.

> - Matthias -


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

Re: [pygccxml-development] argument policies

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

Roman Yakovenko wrote:
>> One thing that might be useful for me at the moment would be the
>> possibility for an arg policy to actually spawn another wrapper so that
>> there'll be two wrappers with different signatures.
> 
> I think a little bit different. I think that pyplusplus should
> generate only 1 wrapper
> for the function. But it should be fully functional. All other
> customization/conveniences should be done from Python.
> 
> For example "return status as exception" arg policies could be solved in 
> Python.

But then it would only work on classes instantiated from Python and not 
on classes returned from wrapped C++ functions. So it's not equivalent 
to implementing the above right inside the C++ wrappers.

>> For example, I have
>> C++ methods that look like this:
>>
>>    void get(double*)
>>
>> They just return an array of a predefined size. With my current arg
>> policies I can turn that into a Python method that takes no arguments
>> and returns a list of floats. But meanwhile I'm also toying with the
>> idea to provide an additional version of the method that takes a list as
>> argument and that will fill that list with the return values. This will
>> be less "Pythonic" but it's closer to the original C++ API.
>> I don't know if it should really be the arg policy that creates the
>> additional wrapper or if it should be done by the user. For example, I
>> could also imagine a way where the user can "clone" a declaration and
>> then just apply a different arg policy to the clone.
> 
> This will never work ( reliably ). py++ assumes that code is 100% correct.

I don't understand those two sentences. What exactly are you referring 
to that will never work? And which code is not correct?

> Another way to solve this is to parse files, generate C++ wrapper for
> the functions,
> and then to parse again with generated functions wrappers.

But all the information is already there after one parsing step, so why 
is it better to do another pass?

>> > Yes. If you don't mind I'd like next structure of the directory:
>> > contrib
>> > |----your name
>>
>> Do you really insist on this? What name would that be? The experimental
>> stuff is not by myself alone, it's also by Allen. Personally, I would
>> much prefer a directory name that's chosen after the *functionality* of
>> its contents and not after its initial author(s). The latter would
>> rather look as if the directory contains my private stuff, but of
>> course, the directory is open to anyone and people should rather be
>> encouraged to contribute to it (would we then have to rename the
>> directory? ;) The authors can be mentioned in a file inside the
>> directory, then it will also be clear that you are not responsible for
>> that code and the list of authors can be extended if necessary.
> 
> I don't insist on this at all. I saw this structure in docutils
> project. If you have
> something different in mind, that is perfectly okay with me.

I just would have put the stuff from the experimental directory into 
"contrib/pypp_api" and the array stuff in, say, "contrib/arrayinfo"...

- Matthias -

Re: [pygccxml-development] argument policies

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

On 5/4/06, Matthias Baas <ba...@ir...> wrote:
> > For example "return status as exception" arg policies could be solved i=
n
> > Python.
>
> But then it would only work on classes instantiated from Python and not
> on classes returned from wrapped C++ functions. So it's not equivalent
> to implementing the above right inside the C++ wrappers.

It is not true. I will show you an example later.

> >> For example, I have
> >> C++ methods that look like this:
> >>
> >>    void get(double*)
> >>
> >> They just return an array of a predefined size. With my current arg
> >> policies I can turn that into a Python method that takes no arguments
> >> and returns a list of floats. But meanwhile I'm also toying with the
> >> idea to provide an additional version of the method that takes a list =
as
> >> argument and that will fill that list with the return values. This wil=
l
> >> be less "Pythonic" but it's closer to the original C++ API.
> >> I don't know if it should really be the arg policy that creates the
> >> additional wrapper or if it should be done by the user. For example, I
> >> could also imagine a way where the user can "clone" a declaration and
> >> then just apply a different arg policy to the clone.
> >
> > This will never work ( reliably ). py++ assumes that code is 100% corre=
ct.
>
> I don't understand those two sentences. What exactly are you referring
> to that will never work? And which code is not correct?

Sorry. I meant that you can not clone a declaration. You can not have
in your code to
identical declarations within the same scope. So I don't know whether
this technique will
work or not.

> > Another way to solve this is to parse files, generate C++ wrapper for
> > the functions,
> > and then to parse again with generated functions wrappers.
>
> But all the information is already there after one parsing step, so why
> is it better to do another pass?

I thought about another approach, cause the way you proposed will not work.
But right now I think I have better idea. Instead of having 1
arguments policy, function
will have a list of arguments policies. module_creator.creator_t
will split it out. It will create calldef_t and calldef_wrapper_t for
every arguments policy.

> I just would have put the stuff from the experimental directory into
> "contrib/pypp_api" and the array stuff in, say, "contrib/arrayinfo"...

Please do it.

> - Matthias -


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

Re: [pygccxml-development] argument policies

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

Roman Yakovenko wrote:
>> > For example "return status as exception" arg policies could be 
>> solved in
>> > Python.
>>
>> But then it would only work on classes instantiated from Python and not
>> on classes returned from wrapped C++ functions. So it's not equivalent
>> to implementing the above right inside the C++ wrappers.
> 
> It is not true. I will show you an example later.

ok, I'll wait...

>> > This will never work ( reliably ). py++ assumes that code is 100% 
>> correct.
>>
>> I don't understand those two sentences. What exactly are you referring
>> to that will never work? And which code is not correct?
> 
> Sorry. I meant that you can not clone a declaration. You can not have
> in your code to identical declarations within the same scope. 

Is that a limitation of the declaration tree in pyplusplus?
Of course, in the final C++ source file there cannot be two identical 
declarations. But in my example, this wouldn't have been the case 
because the declarations would have received two different arg policies 
which would have lead to different signatures (and it would also be ok 
if the name would be different).
So I'm afraid I still don't see why it couldn't work...

>> > Another way to solve this is to parse files, generate C++ wrapper for
>> > the functions,
>> > and then to parse again with generated functions wrappers.
>>
>> But all the information is already there after one parsing step, so why
>> is it better to do another pass?
> 
> I thought about another approach, cause the way you proposed will not work.
> But right now I think I have better idea. Instead of having 1
> arguments policy, function
> will have a list of arguments policies. module_creator.creator_t
> will split it out. It will create calldef_t and calldef_wrapper_t for
> every arguments policy.

One single list wouldn't be enough. In my current implementation there 
is already a list (remember the getSize() example. This one already had 
two Output arg policies). So it would require a list containing lists...
Yes, this would also be an alternative. This means, a declaration can 
have several "policy sets" and each set spawns its own wrapper function 
later on.

>> I just would have put the stuff from the experimental directory into
>> "contrib/pypp_api" and the array stuff in, say, "contrib/arrayinfo"...
> 
> Please do it.

ok, as soon as I have cleaned the code...

- Matthias -