pygccxml-development

Re: [pygccxml-development] type_traits problem

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

On 5/12/06, Allen Bierbaum <al...@vr...> wrote:
> I have attached a patch that adds a test case.

Thanks. I will fix it.

> I think all the is_* tests suffer from a similar problem.  They only
> seem to examine the "outside" most type information and ignore the
> internal data.
>
> For example, shouldn't is_float return true for a "const float" type?

The behaviour should be same as with boost.type_traits. It is possible I mi=
ssed
something. I will check it and fix.

> -Allen


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

Re: [pygccxml-development] type_traits problem

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

I have attached a patch that adds a test case.

I think all the is_* tests suffer from a similar problem.  They only 
seem to examine the "outside" most type information and ignore the 
internal data.

For example, shouldn't is_float return true for a "const float" type?

-Allen

Roman Yakovenko wrote:

> On 5/12/06, Allen Bierbaum <al...@vr...> wrote:
>
>> I just ran into an annoyance that I had seen before bug forgot to post.
>>
>> I am checking a return_type from a method to see if it is a const
>> reference and the type traits are not working well.
>>
>> The problem is that is_const and is_reference only check the most
>> external portion of a composed type.  So if you want to check if
>> something is really a const ref you have do write code something like
>> this (please correct me if I am wrong).
>>
>> ret_type = method.return_type
>> is_ref = True in map(declarations.is_reference,
>> declarations.decompose_type(ret_type))
>> is_const = True in map(declarations.is_const,
>> declarations.decompose_type(ret_type))
>> is_const_ref = (is_ref and not is_const)
>>
>> Boost type traits and other libraries like it automatically do the
>> decomposition so you could check a const reference type and it will
>> return true to both is_reference and is_const.
>>
>> Is there any reason that we shouldn't make pygccxml work similarly?
>
>
> Yes. I did not have test case for this. If you can send me test case I 
> will make
> sure it works as expected.
>
>> -Allen
>>
>>
>> -------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services, 
>> security?
>> Get stuff done quickly with pre-integrated technology to make your 
>> job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache 
>> Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> pygccxml-development mailing list
>> pyg...@li...
>> https://lists.sourceforge.net/lists/listinfo/pygccxml-development
>>
>
>

Re: [pygccxml-development] type_traits problem

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

On 5/12/06, Allen Bierbaum <al...@vr...> wrote:
> I just ran into an annoyance that I had seen before bug forgot to post.
>
> I am checking a return_type from a method to see if it is a const
> reference and the type traits are not working well.
>
> The problem is that is_const and is_reference only check the most
> external portion of a composed type.  So if you want to check if
> something is really a const ref you have do write code something like
> this (please correct me if I am wrong).
>
> ret_type =3D method.return_type
> is_ref =3D True in map(declarations.is_reference,
> declarations.decompose_type(ret_type))
> is_const =3D True in map(declarations.is_const,
> declarations.decompose_type(ret_type))
> is_const_ref =3D (is_ref and not is_const)
>
> Boost type traits and other libraries like it automatically do the
> decomposition so you could check a const reference type and it will
> return true to both is_reference and is_const.
>
> Is there any reason that we shouldn't make pygccxml work similarly?

Yes. I did not have test case for this. If you can send me test case I will=
 make
sure it works as expected.

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


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

[pygccxml-development] Problem and comments

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

I have run into two more things.

First, the matcher's are pretty nice now that (I think) I understand 
them.  It would be nice to have some documentation somewhere that lists 
all the matchers and what can be done with them (for example how to 
compose them using and, or, not :)  I think I know how to do this now 
but I only know because I was trying to understand the find_single and 
find_multiple methods in scopedef_t.  I still don't understand how the 
code in those finds is working (it could really use some comments to 
help with understanding and maintencance) but at least I found the 
matchers. :)

Second, I think I ran into a bug in the wrapper generation.

I have a class with a virtual method that has an exception 
specification.  Imagine something like:

class MyClass
{
public:
   virtual void doSomething() throw myException;
}

When the class gets wrapped, the wrapper class (MyClass_wrapper) doesn't 
use any exception specifications for the method wrapper.  Thus the code 
generated won't compile because the derived class (the wrapper) uses a 
looser exception specification.

Is this supposed to be handled?

-Allen

[pygccxml-development] type_traits problem

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

I just ran into an annoyance that I had seen before bug forgot to post.

I am checking a return_type from a method to see if it is a const 
reference and the type traits are not working well.

The problem is that is_const and is_reference only check the most 
external portion of a composed type.  So if you want to check if 
something is really a const ref you have do write code something like 
this (please correct me if I am wrong).

ret_type = method.return_type
is_ref = True in map(declarations.is_reference, 
declarations.decompose_type(ret_type))
is_const = True in map(declarations.is_const, 
declarations.decompose_type(ret_type))
is_const_ref = (is_ref and not is_const)

Boost type traits and other libraries like it automatically do the 
decomposition so you could check a const reference type and it will 
return true to both is_reference and is_const.

Is there any reason that we shouldn't make pygccxml work similarly?

-Allen

Re: [pygccxml-development] Trying to ramp up again

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

On 5/11/06, Allen Bierbaum <al...@vr...> wrote:
> Roman Yakovenko wrote:
>
> > On 5/11/06, Allen Bierbaum <al...@vr...> wrote:
> >
> >> All of my libraries use boost::shared_ptr's.
> >>
> >> How do I:
> >>
> >> - register held types for a class.  The experimental pypp_api I did ha=
d
> >> a .setHeldType() method, is there something similar still.
> >
> >
> > In most cases pyplusplus will find out this automatically. Any way,
> > pyplusplus/decl_wrappers class_t has held_type property.
> >
> >> - How do I generate "register_ptr_to_python" calls?
> >
> >
> > Same as above. If it does not work for you you will need to modify
> > code creators tree directly. So, if it will not work for you, I will
> > show you the code.
>
> Ok.  I know that in my case this will not be automatically determined,
> so how would I do this.

When you will have more time, I would like to make sure that pyplusplus tre=
ats
your case.

> I was hoping that I would never have to search through the code creator t=
ree.

There are use case where you will have to.

> Would it be possible for me to just add custom text to the decl wrapper
> class?  I think there was some functionality like this in an early
> version of the API that effectively allowed users to add any custom
> calls they needed inside the class scope of the generated code.

Yes, just use an API I gave you:

add_code( your code, works_on_instance=3DFalse )

It should do the trick

> -Allen

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

Re: [pygccxml-development] Trying to ramp up again

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

Roman Yakovenko wrote:

> On 5/11/06, Allen Bierbaum <al...@vr...> wrote:
>
>> All of my libraries use boost::shared_ptr's.
>>
>> How do I:
>>
>> - register held types for a class.  The experimental pypp_api I did had
>> a .setHeldType() method, is there something similar still.
>
>
> In most cases pyplusplus will find out this automatically. Any way,
> pyplusplus/decl_wrappers class_t has held_type property.
>
>> - How do I generate "register_ptr_to_python" calls?
>
>
> Same as above. If it does not work for you you will need to modify
> code creators tree directly. So, if it will not work for you, I will
> show you the code.

Ok.  I know that in my case this will not be automatically determined, 
so how would I do this.  I was hoping that I would never have to search 
through the code creator tree. 

Would it be possible for me to just add custom text to the decl wrapper 
class?  I think there was some functionality like this in an early 
version of the API that effectively allowed users to add any custom 
calls they needed inside the class scope of the generated code.

-Allen

>
>> - How do I generate "implicitly_convertible" calls?
>
>
> Same as above
>
>> - How do I add custom text (or the code creator for custom text) to a
>> decl wrapper?  (I could probably find this in the code, but thought I
>> would ask first)
>
>
> You can use 2 methods defined on decl_wrapper.class_t class:
>
> add_code( code, works_on_instance=True )
> add_wrapper_code( code ).
>
>> Thanks,
>> Allen
>
>
> P.S. Pay attention I redirect my answer to mailing list too. I want
> this information
> available to other people too.
>

Re: [pygccxml-development] Trying to ramp up again

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

On 5/11/06, Allen Bierbaum <al...@vr...> wrote:
> All of my libraries use boost::shared_ptr's.
>
> How do I:
>
> - register held types for a class.  The experimental pypp_api I did had
> a .setHeldType() method, is there something similar still.

In most cases pyplusplus will find out this automatically. Any way,
pyplusplus/decl_wrappers class_t has held_type property.

> - How do I generate "register_ptr_to_python" calls?

Same as above. If it does not work for you you will need to modify
code creators tree directly. So, if it will not work for you, I will
show you the code.

> - How do I generate "implicitly_convertible" calls?

Same as above

> - How do I add custom text (or the code creator for custom text) to a
> decl wrapper?  (I could probably find this in the code, but thought I
> would ask first)

You can use 2 methods defined on decl_wrapper.class_t class:

add_code( code, works_on_instance=3DTrue )
add_wrapper_code( code ).

> Thanks,
> Allen

P.S. Pay attention I redirect my answer to mailing list too. I want
this information
available to other people too.

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

Re: [pygccxml-development] Trying to ramp up again

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

On 5/11/06, Allen Bierbaum <al...@vr...> wrote:
> Hello all.  I am back at it and trying to wrap some libraries that used
> to use Pyste.

It is nice to read from you again :-).

> Anyway, I have been out of the loop for a while and I wondered if
> someone could point me in the direction of what to look at to get back
> into things.

I will try to do it. I re-wrote date_time tester. So may be it is a good id=
ea
to look at it, after tutorial example.

> I see there is a tutorial on the website for a module_builder
> interface.  I assume that this is the high-level interface.  Am I correct=
?

Yes, you are.

> The tutorial shows how to do some basic things but it does not explain
> things like are the classes searched for recursively, mutli-matching,
> and all that stuff we were talking about the last time I was here.

I did not want to insert that staffs into tutorials.

> What is the best way to get up to speed on this stuff?

Just start working, I think that API is simple and intuitive. If you don't =
mind
I prefer you to use version from SVN. It is much better, then last release.

> Should I be reading API documentation?

Yes. In order to understand how selection API works, please read
pygccxml/declarations/scopedef.py module.

The short version is next:

The are 2 sets of API: one set returns single object and raises
exception if object
not found. Another API set selects multiple objects.

Lets learn member_function and member_functions api:

def member_function ( self, name=3DNone, function=3DNone,
return_type=3DNone, arg_types=3DNone, header_dir=3DNone, header_file=3DNone=
,
recursive=3DNone ):

def member_functions( self, name=3DNone, function=3DNone,
return_type=3DNone, arg_types=3DNone, header_dir=3DNone, header_file=3DNone=
,
recursive=3DNone, allow_empty=3DNone ):

As you can see, they are almost identical. The only difference is "allow_em=
pty"
argument in "multi select" function.

Now how does it works? Because those methods are defined on scopedef_t
class, both class_t and namespace_t classes have them. It allows you
to write next code

mb =3D module_builder_t(...)
my_class =3D mb.class_( "xxxx" )
my_class.member_functions( "do_smth", recursive=3DFalse ).exclude()

If you just pass one argument to the "select" functions scopedef_t class wi=
ll
correctly find out what it is: name or custom function.

my_class.member_functions( lambda decl: decl.name.endswith( '_impl' ) )

In all other cases you have to use keywords arguments.

Now about defaults for recursive and allow_empty. As you can see in
both functions
this is None. The algorithm is simple:

if allow_empty is None:
    use scopedef_t.ALLOW_EMPTY_MDECL_WRAPPER
else:
    use it as is.

The same is true for recursive argument.
So, you are able to redefine behaviour for the whole project in one place.

Now multi select functions return instance of "mdecl_wrapper_t" class. It a=
llows
you to "set" some attribute or call some function on all object in one line=
:

my_class.member_functions( "do_smth", recursive=3DFalse ).exclude()

All member functions that match the criteria will be excluded. There is no =
need
to travel on them using loop.

>How do I generate it?

If you use SVN version, then it is very simple. Install epydoc. You have to
install latest version of epydoc ( 3.0 alpha 2 ).

python setup.py sdist

or

if you want to generate documentation only

python setup.py doc

> Sorry for all the questions, I just want to get back up to speed as
> quickly as I can and I am sure you guys can point me in the right
> direction. :)

I hope, that was the right direction. Any way if you need more help
we can talk on some IRC channel.

> Thanks,
> Allen

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

[pygccxml-development] Trying to ramp up again

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

Hello all.  I am back at it and trying to wrap some libraries that used 
to use Pyste.

Anyway, I have been out of the loop for a while and I wondered if 
someone could point me in the direction of what to look at to get back 
into things.

I see there is a tutorial on the website for a module_builder 
interface.  I assume that this is the high-level interface.  Am I correct?

The tutorial shows how to do some basic things but it does explain 
things like are the classes searched for recursively, mutli-matching, 
and all that stuff we were talking about the last time I was here.

What is the best way to get up to speed on this stuff? Should I be 
reading API documentation?  How do I generate it?

Sorry for all the questions, I just want to get back up to speed as 
quickly as I can and I am sure you guys can point me in the right 
direction. :)

Thanks,
Allen

[pygccxml-development] Argument policies

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

Hi. First of all I created some draft about what functionality is going to =
be
implemented/ignored.  I would like to read your opinion about it.

Also I would like to change the feature name, once again. I prefer
"call wrapper policies".  There are few reasons for this:

1. feature deals with the whole function
2. there are use cases that doesn't deals with argument/return value
3. feature enables to split one function declaration to multiple wrappers

The main idea is to tell the user, that if boost.python call policies deals=
 with
objects/values life time management, call-wrapper policies deals with
code, that
should be generated in order to expose a function.

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

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:
>> 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/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:
>> > 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] Re: [pygccxml-commit] SF.net SVN: pygccxml: [55] pyplusplus_dev/docs/apidocs/

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

On 5/3/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > I thought, that directory structure should be fully prepared for distut=
ils
> > module.
>
> Yes, but only at the time the distutils are running. And at that time,
> epydoc has already been invoked and the directory will exist. It doesn't
> matter who actually created the directory, so it doesn't have to be
> stored in svn.

Okay. Do you want to remove it?

> - Matthias -


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

Re: [pygccxml-development] Recent changes

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

On 5/3/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > On 5/2/06, Matthias Baas <ba...@ir...> wrote:
> >> Roman Yakovenko wrote:
> >> > 5. New bugs! Please test py++.
> >>
> >> Maybe here is one, I get the following error when I run my script with
> >> latest pyplusplus:
> >>
> >>    File "pypp_setup.py", line 538, in autoArgPolicies
> >>      if decl.ignore:
> >>    File ".../pyplusplus/decl_wrappers/decl_wrapper.py", line 67, in
> >> _get_ignore
> >>      return self._ignore or not self.exportable
> >>    File ".../pyplusplus/decl_wrappers/decl_wrapper.py", line 91, in
> >> get_exportable
> >>      if self._exportable is None:
> >> AttributeError: 'constructor_t' object has no attribute '_exportable'
> >
> > I need help with the problem. I don't understand how it could happen.
> > ( I am sure you are current on the whole source tree, right ? )
>
> Yes, but it only struck me when I was reading this. The problem was I
> forgot to delete the cache before running the new version and the cache
> still contained the old code.... sorry...

:-). Funny. At work I deal a lot with backward computability of saved data.
And here I forgot about it completely. Some day I will fix it. It means tha=
t we
should save some "version" number within archive.

> After some more modifications here and there I think it works again.

Good

> One more thing though, in pygccxml/declarations/scopedef.py (and maybe
> other places as well) there are log messages like the following:
>
>     utils.logger.info( 'running query: %s and <user defined function>' %
> str( matcher ) )
>
> These messages are issued as "info" messages and I get flooded with
> those messages when I run my script. Could those be changed to "debug"
> messages so that I can disable them without having to disable the entire
> log stream?

Go ahead. Please fix it and commit the change.

> - Matthias -

Thanks

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

Re: [pygccxml-development] Re: [pygccxml-commit] SF.net SVN: pygccxml: [55] pyplusplus_dev/docs/apidocs/

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

Roman Yakovenko wrote:
>> because it is a directory that gets created automatically. If the
>> directory exists, calling "svn status" reports all the (generated) files
>> in the directory as files that have not been added yet. This list can
>> get rather large and makes it difficult to spot the files that have
>> really changed.
>> Whereas if the directory is not part of the repository we only have to
>> add this single directory to the ignore list and "svn status" produces a
>> clean result.
> 
> I thought, that directory structure should be fully prepared for distutils
> module. 

Yes, but only at the time the distutils are running. And at that time, 
epydoc has already been invoked and the directory will exist. It doesn't 
matter who actually created the directory, so it doesn't have to be 
stored in svn.

- Matthias -

Re: [pygccxml-development] Recent changes

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

Roman Yakovenko wrote:
> On 5/2/06, Matthias Baas <ba...@ir...> wrote:
>> Roman Yakovenko wrote:
>> > 5. New bugs! Please test py++.
>>
>> Maybe here is one, I get the following error when I run my script with
>> latest pyplusplus:
>>
>>    File "pypp_setup.py", line 538, in autoArgPolicies
>>      if decl.ignore:
>>    File ".../pyplusplus/decl_wrappers/decl_wrapper.py", line 67, in
>> _get_ignore
>>      return self._ignore or not self.exportable
>>    File ".../pyplusplus/decl_wrappers/decl_wrapper.py", line 91, in
>> get_exportable
>>      if self._exportable is None:
>> AttributeError: 'constructor_t' object has no attribute '_exportable'
> 
> I need help with the problem. I don't understand how it could happen.
> ( I am sure you are current on the whole source tree, right ? )

Yes, but it only struck me when I was reading this. The problem was I 
forgot to delete the cache before running the new version and the cache 
still contained the old code.... sorry...

After some more modifications here and there I think it works again.

One more thing though, in pygccxml/declarations/scopedef.py (and maybe 
other places as well) there are log messages like the following:

    utils.logger.info( 'running query: %s and <user defined function>' % 
str( matcher ) )

These messages are issued as "info" messages and I get flooded with 
those messages when I run my script. Could those be changed to "debug" 
messages so that I can disable them without having to disable the entire 
log stream?

- 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

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

[pygccxml-development] Re: [pygccxml-commit] SF.net SVN: pygccxml: [55] pyplusplus_dev/docs/apidocs/

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

On 5/2/06, Matthias Baas <ba...@ir...> wrote:
> Hi Roman,
>
> > Revision: 55
> > Author:   roman_yakovenko
> > Date:     2006-05-01 22:34:40 -0700 (Mon, 01 May 2006)
> > ViewCVS:  http://svn.sourceforge.net/pygccxml/?rev=3D55&view=3Drev
> >
> > Log Message:
> > -----------
> > place holder
> >
> > Added Paths:
> > -----------
> >     pyplusplus_dev/docs/apidocs/
>
> This reminds me of something I forgot in my mails from yesterday.
> Actually, I wanted to suggest to remove the apidocs directory from the
> repository (unless you are planning on adding content to the directory)

I am not

> because it is a directory that gets created automatically. If the
> directory exists, calling "svn status" reports all the (generated) files
> in the directory as files that have not been added yet. This list can
> get rather large and makes it difficult to spot the files that have
> really changed.
> Whereas if the directory is not part of the repository we only have to
> add this single directory to the ignore list and "svn status" produces a
> clean result.

I thought, that directory structure should be fully prepared for distutils
module. But if you say that this is okay to remove them I will do that.

> - Matthias -
>
>


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

Re: [pygccxml-development] Recent changes

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

On 5/2/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > 5. New bugs! Please test py++.
>
> Maybe here is one, I get the following error when I run my script with
> latest pyplusplus:
>
>    File "pypp_setup.py", line 538, in autoArgPolicies
>      if decl.ignore:
>    File ".../pyplusplus/decl_wrappers/decl_wrapper.py", line 67, in
> _get_ignore
>      return self._ignore or not self.exportable
>    File ".../pyplusplus/decl_wrappers/decl_wrapper.py", line 91, in
> get_exportable
>      if self._exportable is None:
> AttributeError: 'constructor_t' object has no attribute '_exportable'

I need help with the problem. I don't understand how it could happen.
( I am sure you are current on the whole source tree, right ? )

It could be nice if you can track this problem. I think this can happen onl=
y if
decl_wrapper.constructor_t class does not call __init__ methods of its
base classes.

If you can not, can you send me small piece of code/xml that reproduce the
problem. I will try to solve it.

Thanks
> - Matthias -

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

Re: [pygccxml-development] Recent changes

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

Roman Yakovenko wrote:
> 5. New bugs! Please test py++.

Maybe here is one, I get the following error when I run my script with 
latest pyplusplus:

   File "pypp_setup.py", line 538, in autoArgPolicies
     if decl.ignore:
   File ".../pyplusplus/decl_wrappers/decl_wrapper.py", line 67, in 
_get_ignore
     return self._ignore or not self.exportable
   File ".../pyplusplus/decl_wrappers/decl_wrapper.py", line 91, in 
get_exportable
     if self._exportable is None:
AttributeError: 'constructor_t' object has no attribute '_exportable'


- Matthias -