pygccxml-development

[pygccxml-development] [FT] not exception safe generated code

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

Hi Matthias. I did quick review to part of the code and this is what I found:
mem_fun_v_transformed_wrapper_t.create_virtual_body method:

PyGILState_STATE gstate;

gstate = PyGILState_Ensure();



$DECLARATIONS



PyGILState_Release(gstate);


Obviously the code you generate here is not exception safe. I think
you should use
RIIA principle.

class gil_lock_t{
public:
    gil_lock_t( bool lock=true )
    : m_locked( lock )
    {
        if( m_locked )
            m_gstate = PyGILState_Ensure();
    }

    ~gil_lock_t(){
        if( m_locked )
            PyGILState_Release(m_gstate);
    }

     void lock(){
         if( !m_locked )
             m_gstate = PyGILState_Ensure();
     }

     void unlock(){
         if( m_locked )
             PyGILState_Release(m_gstate);
     }
private:
    bool m_locked;
    PyGILState_STATE m_gstate;
};

With this class you can change the code in create_virtual_body method.
Py++ has all functionality needed to add this code Take a look on
code_repository package.

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

Re: [pygccxml-development] Question about calldef_wrapper_t.argument_name()

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

On 9/14/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> while going through the Py++ sources I wondered about the method
> argument_name() in class calldef_wrapper_t. Here is its definition:
>
>      def argument_name( self, index ):
>          arg = self.declaration.arguments[ index ]
>          if arg.name:
>              return arg.name
>          else:
>              return 'p%d' % index
>
> What I wondered is if the 'else' block is ever reached? I searched in
> scanner.py where the argument_t class is actually used and found this:
>
>      argument = argument_t()
>      argument.name = attrs.get( XML_AN_NAME, 'arg%d' %
> len(self.__inst.arguments) )
>
> So the name can only be empty if gccxml reports it as such. I don't know
> if this can ever happen or not, but even if it can happen, why is the
> test from calldef_wrapper_t not moved to the scanner? For example:
>
>     if not argument.name:
>        argument.name = 'arg%d' % len(self.__inst.arguments)
>
> Then an argument_t object read from a C++ file would always have a valid
> name and the method argument_name() wouldn't be required anymore (and
> other parts of the code would actually also be able to know the name of
> an argument).

You can not do it. If you set argument names from the scanner, than Py++
will generate wrong code - keyword arguments. Take a look on
code_creators.calldef_t.keywords_args method. Now the answer to your
question
should be clear. In order to call function I have to pass arguments to
it, so I just created names for them.

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

Re: [pygccxml-development] [FT]input_t class - new vision.

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

On 9/14/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > So how it is related to "input_t" ? "input_t" transformer removes
> > reference or pointer
> > from the argument type. In my case I want to modify the argument type
> > too, but I also
> > want to specify the new type. Same logic is applied on return type.
> >
> > May be we can change\extend input_t class ( and rename it ) so it will
> > provide this functionality?
>
> What name and new construction arguments do you suggest?
>
> This might also be an example where it could actually be useful to apply
> several transformers to one argument (I haven't had such a case yet).
> For example, if there would be a policy remove_const_t you could apply
> both, input_t and remove_const_t, to the same argument. I think this
> should even work already with the current version.

from pygccxml import declarations
type_transformation_t ?

def __init__( self, arg_id, transformation=None ):
    self.arg_id = arg_id
    if None is self.transformation:
        #by default just remove reference
        #because I expect this will be applied to immutable passed by ref
        self.transformation = lambda type_:
declarations.remove_reference( type_ )
    elif is_callable( transformation ):
        #let user define the transformation
        self.transformation = transformation
    else:
        #user already knows what he wants, so we will just use it
        assert isinstance( transformation, declarations.type_t )
        self.transformation = lambda type_: transformation

transf = type_transformation_t( 1
                  , lambda type_: declarations.remove_reference(

declarations.remove_const( type_ ) ) )

Something like this.

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

[pygccxml-development] Question about calldef_wrapper_t.argument_name()

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

Hi,

while going through the Py++ sources I wondered about the method 
argument_name() in class calldef_wrapper_t. Here is its definition:

     def argument_name( self, index ):
         arg = self.declaration.arguments[ index ]
         if arg.name:
             return arg.name
         else:
             return 'p%d' % index

What I wondered is if the 'else' block is ever reached? I searched in 
scanner.py where the argument_t class is actually used and found this:

     argument = argument_t()
     argument.name = attrs.get( XML_AN_NAME, 'arg%d' % 
len(self.__inst.arguments) )

So the name can only be empty if gccxml reports it as such. I don't know 
if this can ever happen or not, but even if it can happen, why is the 
test from calldef_wrapper_t not moved to the scanner? For example:

    if not argument.name:
       argument.name = 'arg%d' % len(self.__inst.arguments)

Then an argument_t object read from a C++ file would always have a valid 
name and the method argument_name() wouldn't be required anymore (and 
other parts of the code would actually also be able to know the name of 
an argument).

To be on the safe side, the _get_name() method of argument_t could also 
create a name if the argument doesn't already have a valid name.

- Matthias -

Re: [pygccxml-development] [FT]input_t class - new vision.

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

Roman Yakovenko wrote:
> So how it is related to "input_t" ? "input_t" transformer removes
> reference or pointer
> from the argument type. In my case I want to modify the argument type
> too, but I also
> want to specify the new type. Same logic is applied on return type.
> 
> May be we can change\extend input_t class ( and rename it ) so it will
> provide this functionality?

What name and new construction arguments do you suggest?

This might also be an example where it could actually be useful to apply 
several transformers to one argument (I haven't had such a case yet). 
For example, if there would be a policy remove_const_t you could apply 
both, input_t and remove_const_t, to the same argument. I think this 
should even work already with the current version.

- Matthias -

[pygccxml-development] [FT]input_t class - new vision.

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

Hi. I am sure you know that I have small problem with custom smart pointer.
The problem introduced new use case to FT - input_t class.

Consider next use case

template<T>
smart_ptr_t{...};

struct Y{

    const smart_ptr_t<X>& do_smth( const smart_ptr_t<Z>& z );

};

For some reason, I am not able to expose do_smth function as is, but rather
its trivial wrapper:

smart_ptr_t<X> do_smth( smart_ptr_t<Z> z );

Consider another problem that Allen had few weeks/month ago:

void do_smth( const class_with_private_destructor_t& x )

The solution was to remove const from the argument.

So how it is related to "input_t" ? "input_t" transformer removes
reference or pointer
from the argument type. In my case I want to modify the argument type
too, but I also
want to specify the new type. Same logic is applied on return type.

May be we can change\extend input_t class ( and rename it ) so it will
provide this
functionality?

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

Re: [pygccxml-development] serialization support?

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

On 9/13/06, Neal Becker <ndb...@gm...> wrote:
> The technique I have used is not really elegant, but works.  First serialize
> with boost::serializatoin into a string, then pickle the string:
>
> struct mt_pickle_suite : python::pickle_suite {
>
>   static python::object getstate (const rng_t& rng) {
>     std::ostringstream os;
>     boost::archive::binary_oarchive oa(os);
>     oa << rng;
>     return python::str (os.str());
>   }
>
>   static void
>   setstate(rng_t& rng, python::object entries) {
>     python::str s = python::extract<python::str> (entries)();
>     std::string st = python::extract<std::string> (s)();
>     std::istringstream is (st);
>
>     boost::archive::binary_iarchive ia (is);
>     ia >> rng;
>   }
> };
>
> [...]
> class_<rng_t> ("rng", "Mersenne Twister", python::init<rng_t::result_type>(
>                                                                              (python::arg ("seed")=4357),
>                                                                              "__init__(seed=4357)\n"
>                                                                              "Construct with optional seed\n"
>                                                                              "@param seed: initial seed\n"
>                                                                              ))
>     .def_pickle(mt_pickle_suite())
>     .def ("getstate", &mt_pickle_suite::getstate)
>     .def ("setstate", &mt_pickle_suite::setstate)
> [...]
>

Few comments:

1. This implementation will surprize any Python user. You don't
preserve references
    between objects.

2. I think you can make this code to be template on Pickled class.

3. I think this code belongs to goodies. Do you want to work a little
bit on it and contribute?
   ( test, few lines of documentation)

   from goodies import pickle
   pickle( module builder, list of classes )

   Something like this.

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

Re: [pygccxml-development] serialization support?

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

On Wednesday 13 September 2006 6:52 am, Roman Yakovenko wrote:
> On 9/13/06, Neal Becker <ndb...@gm...> wrote:
> > On Wednesday 13 September 2006 12:58 am, Roman Yakovenko wrote:
> > > On 9/13/06, Neal Becker <ndb...@gm...> wrote:
> > > > Has any work been done on adding boost::serialization support?
> > >
> > > What do you mean?
> >
> > Automatic generation of pickle support.  Probably using
> > boost::serialization.
>
> That what I thought. No we don't work on this functionality. Moreover
> I think, that Py++
> can not implement it. The primary reason is that Py++ deals with class
> interface
> and not with its state. Py++ can provide some convinience API that
> will make the task
> to be easier to implement. Tell me what you need and I will check how
> I can integrate
> your ideas.

The technique I have used is not really elegant, but works.  First serialize 
with boost::serializatoin into a string, then pickle the string:

struct mt_pickle_suite : python::pickle_suite {
    
  static python::object getstate (const rng_t& rng) {
    std::ostringstream os;
    boost::archive::binary_oarchive oa(os);
    oa << rng;
    return python::str (os.str());
  }

  static void
  setstate(rng_t& rng, python::object entries) {
    python::str s = python::extract<python::str> (entries)();
    std::string st = python::extract<std::string> (s)();
    std::istringstream is (st);
    
    boost::archive::binary_iarchive ia (is);
    ia >> rng;
  }
};

[...]
class_<rng_t> ("rng", "Mersenne Twister", python::init<rng_t::result_type>(
									     (python::arg ("seed")=4357),
									     "__init__(seed=4357)\n"
									     "Construct with optional seed\n"
									     "@param seed: initial seed\n"
									     ))
    .def_pickle(mt_pickle_suite())
    .def ("getstate", &mt_pickle_suite::getstate)
    .def ("setstate", &mt_pickle_suite::setstate)
[...]

Re: [pygccxml-development] serialization support?

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

On 9/13/06, Neal Becker <ndb...@gm...> wrote:
> On Wednesday 13 September 2006 12:58 am, Roman Yakovenko wrote:
> > On 9/13/06, Neal Becker <ndb...@gm...> wrote:
> > > Has any work been done on adding boost::serialization support?
> >
> > What do you mean?
>
> Automatic generation of pickle support.  Probably using boost::serialization.

That what I thought. No we don't work on this functionality. Moreover
I think, that Py++
can not implement it. The primary reason is that Py++ deals with class
interface
and not with its state. Py++ can provide some convinience API that
will make the task
to be easier to implement. Tell me what you need and I will check how
I can integrate
your ideas.


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

Re: [pygccxml-development] serialization support?

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

On Wednesday 13 September 2006 12:58 am, Roman Yakovenko wrote:
> On 9/13/06, Neal Becker <ndb...@gm...> wrote:
> > Has any work been done on adding boost::serialization support?
>
> What do you mean?

Automatic generation of pickle support.  Probably using boost::serialization.

Re: [pygccxml-development] serialization support?

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

On 9/13/06, Neal Becker <ndb...@gm...> wrote:
> Has any work been done on adding boost::serialization support?

What do you mean?

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

[pygccxml-development] serialization support?

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

Has any work been done on adding boost::serialization support?

Re: [pygccxml-development] 2 Questions

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

On 9/12/06, Allen Bierbaum <al...@vr...> wrote:
> Ok, this didn't work out so well.  I found a way to ignore these methods
> but this made it so the wrapper didn't generate a function at all.
> Which in turn makes the wrapper a pure class that can be instantiated
> and thus the compile fails.  It seems like what I would want here is for
> the wrapper class to generate a method but then for the exposer for the
> real class to not generate bindings for that method.  Unfortunately I
> don't see a way to do this right now. :(

You mean in class wrapper to create the function, but after this in class_<...>
not to register it right? Well the function is registered only in base class

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

Re: [pygccxml-development] 2 Questions

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

Allen Bierbaum wrote:

>Roman Yakovenko wrote:
>
>  
>
>>On 9/12/06, Allen Bierbaum <al...@vr...> wrote:
>>
>>    
>>
>>>I have two questions that I am surprised I haven't run into before. I
>>>hope that both have easy answers.
>>>
>>>1. Base class virtual ignored, but coming in inside derived class 
>>>wrappers.
>>>
>>>I have a base class and derived class like:
>>>
>>>struct Base
>>>{
>>>   virtual const int* getData() const = 0;
>>>};
>>>
>>>struct Child : public Base
>>>{ }
>>>
>>>struct GrandChild : public Child
>>>{
>>>   virtual const int* getData() const;
>>>}
>>>
>>>In my py++ generation script I ignore the getData decl in the Base class
>>>(and the GrandChild).  But py++ still ends up generating wrapper code
>>>for getData for the Child class.  To make matters worse, since it is not
>>>a decl for getData in the Child class I can not ignore it there.  It is
>>>almost like Py++ is seeing the virtual method and deciding that it needs
>>>to provide a wrapper for it in Child even though it is ignored in Base.
>>>Is this a bug in Py++ or is there some way that I can take care of this.
>>>      
>>>
>>Do you know how hard I work to implement this? Basically this is because
>>wrapper classes could not be abstract. Also untill now I didn't have 
>>use case
>>where user ignore some method. May be I will have to take a look on it.
>>    
>>
>
>Can you give me a pointer to where the logic for this is so I can take a 
>look at fixing it?
>  
>
Ok, this didn't work out so well.  I found a way to ignore these methods 
but this made it so the wrapper didn't generate a function at all.  
Which in turn makes the wrapper a pure class that can be instantiated 
and thus the compile fails.  It seems like what I would want here is for 
the wrapper class to generate a method but then for the exposer for the 
real class to not generate bindings for that method.  Unfortunately I 
don't see a way to do this right now. :(

-Allen

>  
>
>>>2. The alternative option would be to just wrap the method correctly,
>>>but how can I wrap returning a memory buffer (array) of arbitrary 
>>>length?
>>>
>>>Is there a way to wrap this method so it will return a const wrapper
>>>around this data buffer to make it look like a python list?  If so what
>>>is the easiest way to do it and do I really need to wait for MB's method
>>>transformer code to do it right?
>>>      
>>>
>>You don't have to wait, you can join and help :-). Take a look on 
>>TnFOX Python
>>bindings, they deal with the same problem ( image classes ). It uses 
>>indexing
>>suite v2 to solve the problem.
>>
>>    
>>
>This will probably be the long term solution for me.  Right now I just 
>need to get my bindings compiling again so I can get some short term 
>work done.
>
>Thanks,
>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] 2 Questions

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

On 9/12/06, Allen Bierbaum <al...@vr...> wrote:
> Can you give me a pointer to where the logic for this is so I can take a
> look at fixing it?

creator_t.redefine_funcs
Please post the fix to the list. The code in this specific function is
too fragile.

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

Re: [pygccxml-development] 2 Questions

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

Roman Yakovenko wrote:

> On 9/12/06, Allen Bierbaum <al...@vr...> wrote:
>
>> I have two questions that I am surprised I haven't run into before. I
>> hope that both have easy answers.
>>
>> 1. Base class virtual ignored, but coming in inside derived class 
>> wrappers.
>>
>> I have a base class and derived class like:
>>
>> struct Base
>> {
>>    virtual const int* getData() const = 0;
>> };
>>
>> struct Child : public Base
>> { }
>>
>> struct GrandChild : public Child
>> {
>>    virtual const int* getData() const;
>> }
>>
>> In my py++ generation script I ignore the getData decl in the Base class
>> (and the GrandChild).  But py++ still ends up generating wrapper code
>> for getData for the Child class.  To make matters worse, since it is not
>> a decl for getData in the Child class I can not ignore it there.  It is
>> almost like Py++ is seeing the virtual method and deciding that it needs
>> to provide a wrapper for it in Child even though it is ignored in Base.
>> Is this a bug in Py++ or is there some way that I can take care of this.
>
>
> Do you know how hard I work to implement this? Basically this is because
> wrapper classes could not be abstract. Also untill now I didn't have 
> use case
> where user ignore some method. May be I will have to take a look on it.

Can you give me a pointer to where the logic for this is so I can take a 
look at fixing it?

>
>>
>> 2. The alternative option would be to just wrap the method correctly,
>> but how can I wrap returning a memory buffer (array) of arbitrary 
>> length?
>>
>> Is there a way to wrap this method so it will return a const wrapper
>> around this data buffer to make it look like a python list?  If so what
>> is the easiest way to do it and do I really need to wait for MB's method
>> transformer code to do it right?
>
>
> You don't have to wait, you can join and help :-). Take a look on 
> TnFOX Python
> bindings, they deal with the same problem ( image classes ). It uses 
> indexing
> suite v2 to solve the problem.
>
This will probably be the long term solution for me.  Right now I just 
need to get my bindings compiling again so I can get some short term 
work done.

Thanks,
Allen

Re: [pygccxml-development] 2 Questions

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

On 9/12/06, Allen Bierbaum <al...@vr...> wrote:
> I have two questions that I am surprised I haven't run into before. I
> hope that both have easy answers.
>
> 1. Base class virtual ignored, but coming in inside derived class wrappers.
>
> I have a base class and derived class like:
>
> struct Base
> {
>    virtual const int* getData() const = 0;
> };
>
> struct Child : public Base
> { }
>
> struct GrandChild : public Child
> {
>    virtual const int* getData() const;
> }
>
> In my py++ generation script I ignore the getData decl in the Base class
> (and the GrandChild).  But py++ still ends up generating wrapper code
> for getData for the Child class.  To make matters worse, since it is not
> a decl for getData in the Child class I can not ignore it there.  It is
> almost like Py++ is seeing the virtual method and deciding that it needs
> to provide a wrapper for it in Child even though it is ignored in Base.
> Is this a bug in Py++ or is there some way that I can take care of this.

Do you know how hard I work to implement this? Basically this is because
wrapper classes could not be abstract. Also untill now I didn't have use case
where user ignore some method. May be I will have to take a look on it.

>
> 2. The alternative option would be to just wrap the method correctly,
> but how can I wrap returning a memory buffer (array) of arbitrary length?
>
> Is there a way to wrap this method so it will return a const wrapper
> around this data buffer to make it look like a python list?  If so what
> is the easiest way to do it and do I really need to wait for MB's method
> transformer code to do it right?

You don't have to wait, you can join and help :-). Take a look on TnFOX Python
bindings, they deal with the same problem ( image classes ). It uses indexing
suite v2 to solve the problem.


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

[pygccxml-development] 2 Questions

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

I have two questions that I am surprised I haven't run into before. I 
hope that both have easy answers.

1. Base class virtual ignored, but coming in inside derived class wrappers.

I have a base class and derived class like:

struct Base
{
   virtual const int* getData() const = 0;
};

struct Child : public Base
{ }

struct GrandChild : public Child
{
   virtual const int* getData() const;
}

In my py++ generation script I ignore the getData decl in the Base class 
(and the GrandChild).  But py++ still ends up generating wrapper code 
for getData for the Child class.  To make matters worse, since it is not 
a decl for getData in the Child class I can not ignore it there.  It is 
almost like Py++ is seeing the virtual method and deciding that it needs 
to provide a wrapper for it in Child even though it is ignored in Base.  
Is this a bug in Py++ or is there some way that I can take care of this.

2. The alternative option would be to just wrap the method correctly, 
but how can I wrap returning a memory buffer (array) of arbitrary length?

Is there a way to wrap this method so it will return a const wrapper 
around this data buffer to make it look like a python list?  If so what 
is the easiest way to do it and do I really need to wait for MB's method 
transformer code to do it right?

Thanks for you help.  I am sorry if either of these seems like a really 
basic question, I just haven't run into this before.

-Allen

Re: [pygccxml-development] How to do error checking?

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

On 9/12/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > So, why don't you add to the "function ( final ) transformation_t"
> > class new method: "signature".
>
> I assume you mean the class function_transformer_t, right? This class
> cannot return the entire signature because it doesn't know it.
> Even the substitution_manager class cannot know the signature for sure
> as it just provides string substitution services. It's up to the code
> creator to determine how the final signature will look like. (Note: I'm
> describing the current implementation here, I'm not saying that this is
> the one and only way to go, it's how it currently goes)
> If you think this is not right,

We talk about this. Yes I don't agree with you. I understand that you
are talking about
current implementation. Lets try to find solution within the current code.

> then we might have to introduce an
> intermediate object that is located between the substitution manager and
> the code creator (but at least so far, I wouldn't know what the
> difference between this object and the code creator would be).

I think that substitution manger should become an implementation detail of
"[final|whole|function]_transformation_t" class.

It will provide next services:
1. signature -> returns function type
2. is_static - this is because staticmethod should be called after all
registrations
3. create_declaration_code() -> retuns string that contains FT
declaration\\definition
4. call_policies
5. optional:
        * alias -> returns function transformation alias
        * documentation -> returns documentation string
        * optional: keywords and default values


> > This method will return [member|free] function type.
>
> As a string or as a type_t object?

As a free_function_type_t or member_function_type_t type.

> > 2. In decl_wrappers.class_t you "override" _readme_impl method that
> > will check for
> >    the "problems". This method will be called from
> > creator_t.prepare_decls method
>
> You don't happen to have a call sequence diagram of all this, have you?

No :-(. Ask me questions.

> (this would probably make things clearer, because I don't understand how
> a decl_wrapper object can know things that a code creator object will be
> doing)

Hmm, now I understand why you are confused. decl_wrapper classes "understands"
what code is going to be created, by they don't know the exact details.
For example: decl_wrappers understands what operators are supported, but they
don't know what code will be created to expose them.

> > Answer to the first question: you don't have to store "the data".
>
> Well, but in contrast to the tests that are currently done by Py++ this
> test cannot be done by inspecting the current declaration alone, but it
> also needs to know information about other declarations. So where does
> this information come from?

This is your design and implementation, so please tell me? By the way I don't
understand how you are going to implement it at all( in current
implementation), string
comparison?

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

Re: [pygccxml-development] How to do error checking?

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

Roman Yakovenko wrote:
> So, why don't you add to the "function ( final ) transformation_t"
> class new method: "signature". 

I assume you mean the class function_transformer_t, right? This class 
cannot return the entire signature because it doesn't know it.
Even the substitution_manager class cannot know the signature for sure 
as it just provides string substitution services. It's up to the code 
creator to determine how the final signature will look like. (Note: I'm 
describing the current implementation here, I'm not saying that this is 
the one and only way to go, it's how it currently goes)
If you think this is not right, then we might have to introduce an 
intermediate object that is located between the substitution manager and 
the code creator (but at least so far, I wouldn't know what the 
difference between this object and the code creator would be).

> This method will return [member|free] function type. 

As a string or as a type_t object?

> 2. In decl_wrappers.class_t you "override" _readme_impl method that
> will check for
>    the "problems". This method will be called from
> creator_t.prepare_decls method

You don't happen to have a call sequence diagram of all this, have you? 
(this would probably make things clearer, because I don't understand how 
a decl_wrapper object can know things that a code creator object will be 
doing)

> Answer to the first question: you don't have to store "the data".

Well, but in contrast to the tests that are currently done by Py++ this 
test cannot be done by inspecting the current declaration alone, but it 
also needs to know information about other declarations. So where does 
this information come from?

> Answer to the second question: mem_fun_transformed_wrapper_t should 
> concern on
> code generation and nothing else. So, it is a wrong place to put this
> functionality to it.

I'll try to keep that in mind...

- Matthias -

Re: [pygccxml-development] How to do error checking?

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

On 9/12/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> I'm still at adding function transformer support to non-virtual
> functions. When transformers are applied to a set of methods, it can
> happen that several (overloaded) methods end up with an identical
> signature. Currently, this would result in an error during compilation
> because a function is redefined.
>
> So I'd like to check this and issue a warning in such cases. The check
> itself is no problem, but it requires sort of "global" data (namely a
> dictionary with the signatures that have been created so far) on a
> per-class basis.
>
> So there are two questions now:
>
> 1. Where should I store that data? (should I just add it to the class_t
> code creator instance?)
>
> 2. Does the Py++ design already specify where such a check should be
> done? (currently, I would probably do it in
> mem_fun_transformed_wrapper_t when the actual code gets generated)

I suspect that you still don't understand the design.

You need function signatures for 2 cases:
    1. to register it ( def )
    2. to check uniqueness

So, why don't you add to the "function ( final ) transformation_t"
class new method:
"signature". This method will return [member|free] function type. This
will solve you both
problems:
1. You will be able to generate code, that will include function
signature( type ) in it.
    Take a look on generated code for overloaded functions.

2. In decl_wrappers.class_t you "override" _readme_impl method that
will check for
    the "problems". This method will be called from
creator_t.prepare_decls method

Answer to the first question: you don't have to store "the data".
( Performance is not an issue ).

Answer to the second question: mem_fun_transformed_wrapper_t should concern on
code generation and nothing else. So, it is a wrong place to put this
functionality to it.

Does it sound reasonable to you?

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

[pygccxml-development] How to do error checking?

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

Hi,

I'm still at adding function transformer support to non-virtual 
functions. When transformers are applied to a set of methods, it can 
happen that several (overloaded) methods end up with an identical 
signature. Currently, this would result in an error during compilation 
because a function is redefined.
So I'd like to check this and issue a warning in such cases. The check 
itself is no problem, but it requires sort of "global" data (namely a 
dictionary with the signatures that have been created so far) on a 
per-class basis. So there are two questions now:

1. Where should I store that data? (should I just add it to the class_t 
code creator instance?)

2. Does the Py++ design already specify where such a check should be 
done? (currently, I would probably do it in 
mem_fun_transformed_wrapper_t when the actual code gets generated)


- Matthias -

Re: [pygccxml-development] [pygccxml-commit] SF.net SVN: pygccxml: [534] pygccxml_dev/pygccxml/declarations/calldef.py

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

On 9/11/06, Matthias Baas <ba...@ir...> wrote:
> Sorry again.

You don't have to be. In Russian we say( free translate ):
The only person who does not make mistakes, is the one who does nothing.

If we talk about the fault, than you can blame me: not enough documentation :-)

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

Re: [pygccxml-development] [pygccxml-commit] SF.net SVN: pygccxml: [534] pygccxml_dev/pygccxml/declarations/calldef.py

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

Roman Yakovenko wrote:
> On 9/11/06, Matthias Baas <ba...@ir...> wrote:
>> Oops, I wasn't aware that I broke that rule. Uhm, but what did I do that
>> actually broke it? I haven't used anything from pyplusplus (or other
>> external code).
> 
> Yes I know, dummy_type_t was defined in pygccxml for convenience reason.
> 
>> The only class that I've used is dummy_type_t which is defined within
>> pygccxml. And the behavior of the argument class was not changed, it was
>> just an addition so that the type argument can now also be a string. Any
>> existing code should continue to work as before.
> 
> No. I have to fix some bug. But basically consider next case
> 
> argument_t( 'x', type='const std::string&', ... )

I'm surprised to see that this was already allowed! It wasn't documented 
what type the 'type' argument was actually supposed to be, but from 
looking at the sources it seemed to be required that it was derived from 
type_t. And when I did some tests where I did pass strings I got 
exceptions somewhere inside Py++ where it tried to access the 
decl_string property, so I was pretty sure that strings had been invalid 
as arguments. And that's why I thought I wouldn't break anything when I 
do allow them.

But obviously I did break something. I don't understand why and I don't 
see how this was obvious from looking at the sources, but anyway. So my 
apologies for any inconveniences! I'll roll back my changes right away.

Sorry again.

- Matthias -

Re: [pygccxml-development] [pygccxml-commit] SF.net SVN: pygccxml: [534] pygccxml_dev/pygccxml/declarations/calldef.py

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

On 9/11/06, Matthias Baas <ba...@ir...> wrote:
> Oops, I wasn't aware that I broke that rule. Uhm, but what did I do that
> actually broke it? I haven't used anything from pyplusplus (or other
> external code).

Yes I know, dummy_type_t was defined in pygccxml for convenience reason.

> The only class that I've used is dummy_type_t which is defined within
> pygccxml. And the behavior of the argument class was not changed, it was
> just an addition so that the type argument can now also be a string. Any
> existing code should continue to work as before.

No. I have to fix some bug. But basically consider next case

argument_t( 'x', type='const std::string&', ... )

No somewhere within the Py++ code there is ( it will be tomorrow ) a condition:

if is_immutable( arg.type ):
   ...
else:
   ...

Well, it will fail and the bug is that Py++ did not meat user expectations.
So, I prefer a user to know when he works with real type and when he works with
dummy one.

You can say ( and you will be right ) that I introduce some complexity to the
user, but I think this is an important one.

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