pygccxml-development

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

[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] protected/private member functions

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

Roman Yakovenko wrote:
> Hi. I need your ( user - developer ) input on next problem:
> what do you expect from py++, when it deals with class/class hierarchy
> that has protected/private (pure)virtual functions.

I don't have much experience with this yet. Most classes in the Maya SDK 
aren't meant to be derived from and I simply ignored all protected 
methods. There are a couple of classes the user may derive from but so 
far, I haven't had the case that I needed a non-public method.
I'll get back to you once the situation arises... ;)

- Matthias -

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

[pygccxml-development] Recent changes

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

Hi. Last week I work on re-factoring. Code that deal with exposing
functions and
operators was not as good, as I want. It means, that it was very
difficult to read
and understand it. So I fix it. There are few nice side effects and one not=
 so.

1. module_creator.creator_t class is now simpler that it was.
2. decl_wrapper_t class has new functionality:
    exportable - boolean property, that tells user whether this
declaration can be
                      exported to Python or not
    why_not_exportable - function, that will explain the reason why
the declaration
                                   can not be exported. Sometimes link
to the relevant piece of
                                   documentation will be provided.
3. function_t and function_wrapper_t code creators are deleted.
4. There are new code creators:
    free_function_t
    mem_fun_t

    mem_fun_pv_t
    mem_fun_pv_wrapper_t
    mem_fun_v_t
    mem_fun_v_wrapper_t

    mem_fun_protected_t
    mem_fun_protected_wrapper_t
    mem_fun_protected_s_t
    mem_fun_protected_s_wrapper_t
    mem_fun_protected_v_t
    mem_fun_protected_v_wrapper_t
    mem_fun_protected_pv_t
    mem_fun_protected_pv_wrapper_t

    mem_fun_private_v_wrapper_t
    mem_fun_private_pv_wrapper_t

    This approach is much better.

5. New bugs! Please test py++.

6. I did some changes to allow easy configuration of pygccxml/py++ unittest=
s.
    For pygccxml, please take a look on pygccxml_dev/unittests/autoconfig.p=
y.
    For py++, please take a look on pyplusplus_dev/environment.py

7. decl_wrappers.calldef_t has new functionality - overridable (
better name is needed )
    Not all virtual functions could be redefined in Python. Functions
that returns reference
    to some object in 99% cases will return reference to local
variable, just causing access
    violation. In case of pure virtual functions, py++ must redefine
those functions.
    In run time user will get nice error with explanation, why he can
not redefine
    the function.


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

[pygccxml-development] protected/private member functions

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

Hi. I need your ( user - developer ) input on next problem:
what do you expect from py++, when it deals with class/class hierarchy
that has protected/private (pure)virtual functions.

protected function?

static protected function?

virtual protected function?

pure virtual protected function?

virtual private function?

pure virtual private function?


Why do I care about non public [pure] virtual functions?
( First of all I have some code that uses them :- ).

1. Template method design pattern.

2. There are cases when protected methods provide some useful functionality=
 and
    I think it should be available for Python classes.

Thoughts, comments suggestions are welcome.

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

Re: [pygccxml-development] Error after updating pyplusplus...

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

On 4/27/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> the latest version of pyplusplus now turns a member variable like
> "float* depthArr" into a property which won't compile. During
> compilation you get a weird error from Boost that's pretty much useless.
> For now, I don't need those variables so I just ignore them explicitly
> now and everything is fine again.
> But I just thought I mention it here anyway as in my opinion, pyplusplus
> should never generate code that won't compile.

You are right. My opinion is: pyplusplus should generate code that
actually works.
If it can do it - skip it.

The problem you are talking about. Recently there were few mails about how =
to
expose member variable pointers. I implemented solution for this. Obviously
I did not take into account some use cases. ( pointer to fundamental
type I think )

So, thank you for your input. I will fix it next week.


> - Matthias -

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

Re: [pygccxml-development] Error after updating pyplusplus...

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

Hi,

the latest version of pyplusplus now turns a member variable like 
"float* depthArr" into a property which won't compile. During 
compilation you get a weird error from Boost that's pretty much useless.
For now, I don't need those variables so I just ignore them explicitly 
now and everything is fine again.
But I just thought I mention it here anyway as in my opinion, pyplusplus 
should never generate code that won't compile.

- Matthias -

Re: [pygccxml-development] Error after updating pyplusplus...

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

Roman Yakovenko wrote:
> I attach new implementation. If this fix the error, can you commit it.

It works again. Thanks!

- Matthias -

Re: [pygccxml-development] Error after updating pyplusplus...

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

On 4/26/06, Matthias Baas <ba...@ir...> wrote:
Hi.
> Any ideas?

Actually yes. I don't know what I thought about that moment, really!

I attach new implementation. If this fix the error, can you commit it.
Thanks


> - Matthias -

P.S. Sorry for inconvenience

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

[pygccxml-development] Error after updating pyplusplus...

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

Hi,

I've just switched to the svn version and now I get the following error 
when I try to recreate the Maya bindings:

   File "pypp_setup.py", line 637, in ?
     root = mod.parse()
   File "...pyplusplus/experimental/pypp_api.py", line 273, in parse
     parser.project_reader.COMPILATION_MODE.FILE_BY_FILE)
   File "...pygccxml/parser/project_reader.py", line 149, in read_files
     return self.__parse_file_by_file(files)
   File "...pygccxml/parser/project_reader.py", line 174, in 
__parse_file_by_file
     decls = reader.read_file( header )
   File "...pygccxml/parser/source_reader.py", line 190, in read_file
     raise error
AttributeError: 'NoneType' object has no attribute 'name'

I had a quick look in the code, but because the exception is actually 
caught and then raised again the true source of the error is obfuscated.
After changing the except statement so that it does not catch the 
exception I get:

   File "...pygccxml/parser/project_reader.py", line 174, in 
__parse_file_by_file
     decls = reader.read_file( header )
   File "...pygccxml/parser/source_reader.py", line 181, in read_file
     declarations, files = self.__parse_gccxml_created_file( gccxml_file )
   File "...pygccxml/parser/source_reader.py", line 256, in 
__parse_gccxml_created_file
     apply_visitor( linker_, decl )
   File "...pygccxml/declarations/algorithm.py", line 263, in apply_visitor
     getattr( visitor, fname )()
   File "...pygccxml/parser/linker.py", line 107, in visit_class
     new_name = self.__inst.parent.name
AttributeError: 'NoneType' object has no attribute 'name'


Any ideas?

- Matthias -

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

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

On 4/24/06, Matthias Baas <ba...@ir...> wrote:
> > If so, what interface you give to the user? Direct access to the code c=
reator?
> > I am not talking about wm.declare_local( ... ), as for me this is too
> > low-level.
>
> Policies that are independent of a particular project (such as Output,
> OutputArray, InputArray, etc) can be made part of pyplusplus and a user
> can use them for his own project. In this case, the user doesn't have to
> know how argument policies work internally.
> If the standard policies don't fit the bill of the user, he has the
> option to write his own policies. Now the user must be familiar with the
> internals of the policy mechanism.
>
> > Small comment about clean_up( :-) ) state.
> > In C++ developers can use RIIA technique. So I think, that clean up
> > state is nessecary.
>
> Should that read "is not necessary"...?

Yes of course.

>
> > I don't want to force developers to use it, but I
> > also don't want to provide "too mach" help with hand written clean up a=
ctions.
>
> What do you mean? Are you for or against the cleanup() method? (by the
> way, currently I don't have this implemented yet anyway as my current
> policies don't need any cleanup. But as soon as you have to allocate
> memory it might get necessary)

std::auto_ptr, boost::scoped_ptr, boost::shared_ptr ( with custom deleter )
should work


Okay. I glad we understand each other and has an agreement.
Can you start working on this. I mean prepare use-cases and what code shoul=
d
be generated. I think we will start with one common use-case:

int read( int size, char* buffer )

and

simple use case:  error status translated to exception.

I am working on function_t function_wrapper_t code creators. If you
don't mind can you create:
- C++ code for unit test
- C++ generated code ( this will guide us what code creators should do )
- configuration pseudo code. I mean from user point of view:

  mb =3D module_builder_t( ... )
  mf =3D mb.member_function( ... )
  mf.args_policies =3D ????????


I hope, I will finish with my task in the middle of next week. After
this we can start to work
on code generation. What do you think? Do you agree with the plan? May
be you prefer to
do something else?

> - Matthias -


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

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

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

Roman Yakovenko wrote:
> Okay lets see if I understand you right.
> 
> class wrapper{
> 
> return_type function( arguments ) <== here user can modify function signature
> 
>     variables <== here user declares few variables and can bind them
> with arguments
>                           and/or return value
> 
>     make "native" call ( mix of variables and arguments ) <== here I
> think he should
>                          be able to bind return argument to some variable
> 
>     construct return value  <== here user can check result of "native" call and
>                          throw exception or construct return value.
> 
> }

I think you mostly got it. Just to clarify, here's the basic layout of 
the wrapper functions as they are currently generated (assuming there 
are n argument policies):

return_type wrapper_function_name( [self,] arguments )
{
   <local variable declarations>

   <precall code 1>
   <precall code 2>
   ...
   <precall code n>

   result = original_function( args );

   <postcall code 1>
   <postcall code 2>
   ...
   <postcall code n>

   return single_result_or_result_tuple;
}

- By default, the wrapper function has the same signature than the 
original function but the argument policies can modify the signature. 
When the function is supposed to be a class method the "self" argument 
is added as first argument.

- When more than 1 result variables get registered the return type 
automatically turns to "boost::python::tuple" and the return statement 
becomes a "return boost::python::make_tuple(args)" statement.

- The local variables are those that the arg policies have declared + a 
variable for the original return value (if there is one).

- The argument list for the original function call is a list of variable 
names. The arg policies can modify this list to "redirect" input or 
output (this includes the name of the result variable).

> If so, what interface you give to the user? Direct access to the code creator?
> I am not talking about wm.declare_local( ... ), as for me this is too
> low-level.

Policies that are independent of a particular project (such as Output, 
OutputArray, InputArray, etc) can be made part of pyplusplus and a user 
can use them for his own project. In this case, the user doesn't have to 
know how argument policies work internally.
If the standard policies don't fit the bill of the user, he has the 
option to write his own policies. Now the user must be familiar with the 
internals of the policy mechanism.

> Small comment about clean_up( :-) ) state.
> In C++ developers can use RIIA technique. So I think, that clean up
> state is nessecary. 

Should that read "is not necessary"...?

> I don't want to force developers to use it, but I
> also don't want to provide "too mach" help with hand written clean up actions.

What do you mean? Are you for or against the cleanup() method? (by the 
way, currently I don't have this implemented yet anyway as my current 
policies don't need any cleanup. But as soon as you have to allocate 
memory it might get necessary)

- Matthias -

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

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

Roman Yakovenko wrote:
>> 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, may be I can not explain my self or I don't understand you.
> Both projects use Python logging module, I am not going to reinvent the wheel!
> py++ creates/configures logger in _logging_ package, while pygccxml in
> utils package.

ok, I think now I got it that the main purpose of the _logging_ module 
is to initialize/configure the logger and maybe not to so much to 
provide the loggers.
I think I was mainly confused because in pyplusplus the logger was also 
obtained via _logging_ whereas pygccxml cannot do this and instead 
initializes its logger in an __init__ module. It was just the presence 
of two different approaches that has confused me.

- Matthias -

[pygccxml-development] Work plan for next few week or two

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

Hi. I am going to prepare relevant code creators for "argument policies".
To be more specific: I am going to work on function_t and
function_wrapper_t code creators. I am going to split those classes to
few classes

function_base_t
function_wrapper_base_t
    those classes will contain code that is shared between all derived clas=
sed
    user will be able to find all "function" code creators using those clas=
ses

Derived classes will be divided by access type and vitality:
s - static
v - virtual
pv - pure virtual
mem_fun - member function, the short name is taken from C++ std

public:

    mem_fun_t

    mem_fun_v_t
    mem_fun_v_wrapper_t

    mem_fun_pv_t
    mem_fun_pv_wrapper_t

protected:

    mem_fun_protected_t
    mem_fun_protected_wrapper_t

    mem_fun_protected_v_t
    mem_fun_protected_v_wrapper_t

    mem_fun_protected_pv_t
    mem_fun_protected_pv_wrapper_t

    mem_fun_protected_s_t
    mem_fun_protected_s_wrapper_t

private:

   #developer will be able to override, but not to call
   mem_fun_private_v_wrapper_t
   mem_fun_private_pv_wrapper_t

free function:
   free_function_t

I believe this split will improve readability and maintainability of the co=
de.
Right now it very difficult to add new use case or even to fix a bug.

Now the important thing: if you did not used code creators in your
project - your project
will continue to work.

Thoughts?

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

[pygccxml-development] SVC to SVN

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

Hi. Just wan to update you that:

1. This morning we switched to SVN. I tried to use SF services for
migration, but failed.
    Actually,  the services provided by SF failed. So I decided to
create repository from
    source tree. First of all I changed it according to our
discussion( see Phisical (re)design
    posts ).
    Please check out new tree and inspect it.

2. I leave CVS in a good state: I fixed almost all bugs that has been repor=
ted.
    There is only one problem: py++ does not exports right protected
member functions.
    This will be fixed in week or two in SVN.

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

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

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

Okay lets see if I understand you right.

class wrapper{

return_type function( arguments ) <=3D=3D here user can modify function sig=
nature

    variables <=3D=3D here user declares few variables and can bind them
with arguments
                          and/or return value

    make "native" call ( mix of variables and arguments ) <=3D=3D here I
think he should
                         be able to bind return argument to some variable

    construct return value  <=3D=3D here user can check result of "native" =
call and
                         throw exception or construct return value.

}

Now, the communication between steps done using function_wrapper_t
code creator ( =3D=3D wrapper_manager  ).
To be more precision: using variables and arguments collections.

I think, I've got you right.

If so, what interface you give to the user? Direct access to the code creat=
or?
I am not talking about wm.declare_local( ... ), as for me this is too
low-level.

Comments?

P.S.
Small comment about clean_up( :-) ) state.
In C++ developers can use RIIA technique. So I think, that clean up
state is nessecary. I don't want to force developers to use it, but I
also don't want to
provide "too mach" help with hand written clean up actions.


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

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

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

On 4/21/06, Niki Spahiev <ni...@vi...> wrote:
> Roman Yakovenko wrote:
> >> In SWIG they are called typemaps. There are input, output, exception a=
nd
> >> some other kinds of typemaps.
> >
> > Thanks for input. Can you send me link to the relevant piece of documen=
tation?
>
> Sure: http://www.swig.org/Doc1.3/Typemaps.html

Thanks

> >> IIRC SWIG can (or is a planing to)
> >> save XML.
> >
> > Do you mean that they are going to save C++ declarations as XML in file=
?
>
> http://www.rexx.com/~dkuhlman/swigxml.html
>
> Bug plus of SWIG is that it can handle incomplete sources.

pyplusplus does not depend on C++ parser at all :-). I think it will takes =
week
or two, to integrate new C++ parser with pygccxml.

Any way, it seems to me that you used both projects, right? So stay tuned :=
-)
we definitely will need your input here and there.

> Niki Spahiev

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

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

[Niki S. <ni...@vi...>]

Roman Yakovenko wrote:
>> In SWIG they are called typemaps. There are input, output, exception and
>> some other kinds of typemaps.
> 
> Thanks for input. Can you send me link to the relevant piece of documentation?

Sure: http://www.swig.org/Doc1.3/Typemaps.html

>> IIRC SWIG can (or is a planing to)
>> save XML.
> 
> Do you mean that they are going to save C++ declarations as XML in file?

http://www.rexx.com/~dkuhlman/swigxml.html

Bug plus of SWIG is that it can handle incomplete sources.

Niki Spahiev

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

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

On 4/20/06, Niki Spahiev <ni...@vi...> wrote:
> 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 );
> [...]
> > Bottom line - new name needed.
> >
> > Suggestions:
> >
> > [ function ] wrapper call policies
> >
> > Comments?
> >
>
> In SWIG they are called typemaps. There are input, output, exception and
> some other kinds of typemaps.

Thanks for input. Can you send me link to the relevant piece of documentati=
on?

> As SWIG is C++ parser too, IMHO most if
> the issues to handle are the same.

I am sure they do it.

> IIRC SWIG can (or is a planing to)
> save XML.

Do you mean that they are going to save C++ declarations as XML in file?

> Niki Spahiev
>

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

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

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

On 4/20/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > Okay, I was not clear. _logging_ module solves 2 technical problems:
> > 1. I want some module/package that will be independent on all other pac=
kages,
> >     because I want to use it in every ( well almost every other ) modul=
e 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.

pygccxml should have it's own logger. pyplusplus package can re-configure i=
t
to use it's logger.

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

Okay, but how I will write to it?

import logging
logging.debug( '...' )

In this case, if I understand right the logging package and documentation,
it will write message to all loggers. This is definitely not what I want.

or may be

import logging
logging.getLogger( 'pyplusplus' ).debug('...')

In this case I should write more code and I have a chance to misspell
logger name.


> >> 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, may be I can not explain my self or I don't understand you.
Both projects use Python logging module, I am not going to reinvent the whe=
el!
py++ creates/configures logger in _logging_ package, while pygccxml in
utils package.

If I rename _logging_ package to log_config or something else, will it be c=
lear?

> - Matthias -


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

Re: [pygccxml-development] Problem with typedefs

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

On 4/21/06, Roman Yakovenko <rom...@gm...> wrote:
> On 4/21/06, Rodrigue Cloutier <rod...@ho...> wrote:
> >
> > 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.

Okay. I was able to fix this bug. I will commit the patch in few days.

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

Re: [pygccxml-development] Problem with typedefs

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

On 4/21/06, Rodrigue Cloutier <rod...@ho...> wrote:
>
> 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.

I am aware of this kinds of bugs. pyplusplus just assigns default value, th=
at
GCC-XML reported. So, basically this is not py++ bug, but GCC-XML.

Also, you are not the first person who failed on this bug. So
pygccxml, the front-end
to GCC-XML, makes an attempt to fix this situation. It seems that you find =
new
use case, I will try to fix it, based on your example. Also, if you
can not wait or just
curious, or may be you want to contribute ( :-) ) you can take a look on
pygccxml/parser/patcher.py file

> 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()=
.
>
>
> bp::def( "func"
>         , &func
>         , ( bp::arg("arg0")=3DfooType() )
>         , bp::return_value_policy< bp::return_opaque_pointer,
> bp::default_call_policies >() );
>
>
> 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 :)

Basically, if you have only few places you can fix them using next code:

mb =3D module_builder_t( ... )
func2 =3D mb.free_function( 'func2', arg_types=3D[None] )
#arg_types=3D[None] makes query more specific. It says function with one
argument of
#any type
func2.arguments[0].default_value =3D 'core::foo()'

> Thanks for the great work.

Enjoy.

> Rod


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

Re: [pygccxml-development] array_t vs pointer_t

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

Roman Yakovenko wrote:
> On 4/20/06, Matthias Baas <ba...@ir...> wrote:
>> 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)...
> 
> :-) All you need is reliable way to give function unique name. You can
> construct
> name of wrapper from from name + line number. Every declaration has
> location property. Or another option: every declaration has mangled
> property, you can use it within the name.

Actually, I do have unique names now (using id(decl)), but for different 
reasons. In the above case, this would not be a solution as long as the 
wrappers have the same name in Python (and when they do not have the 
same name, then the above problem doesn't exist anyway). Which version 
should Boost.Python pick when I call getValue() in Python? So the 
wrappers must have different names in Python.

>> [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)
> 
> Next week or two. I want to fix some bugs found by people and then to move.

ok

- Matthias -

Re: [pygccxml-development] array_t vs pointer_t

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

On 4/20/06, Matthias Baas <ba...@ir...> wrote:
> 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)...

:-) All you need is reliable way to give function unique name. You can
construct
name of wrapper from from name + line number. Every declaration has
location property. Or another option: every declaration has mangled
property, you can use
it within the name.

Please consider this idea and post the result. This is important, because p=
y++
will be able to generate less readable code, but it will compile faster.

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

Next week or two. I want to fix some bugs found by people and then to move.

> - Matthias -


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