pygccxml-development

Re: [pygccxml-development] FT -subst_t

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

Roman Yakovenko wrote:
> I propose to delete subst_t class. Main reason:
> Method substitute defines some logic, according to which this it decides how to
> indent the code. This is just wrong. code_manager_t class understands
> the meaning of
> the variables, so it is its respocibility to indent the code. Without
> subsitute method this class is pretty useless.

This proposal doesn't mention how to get back the actual functionality 
after removing subst_t. So I take it you suggest to move the 
substitute() method into the code_manager_t class?

- Matthias -

Re: [pygccxml-development] FT -subst_t

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

On 10/10/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > On 10/8/06, Matthias Baas <ba...@ir... <mailto:ba...@ir...>> wrote:
> >  > Roman Yakovenko wrote:
> >  > > I don't understand why derived class code_manager_t should have
> > ugly variable
> >  > > names: ARG_LIST_DEF,  ARG_LIST_TYPES and etc. This is not coding
> > convention
> >  > > of Py++.
> >  >
> >  > I was using upper case variables for sort of "low level" variables that
> >  > are usually initialized by corresponding lower case variables.
> >  > From the
> >  > point of view of the function transformer class these variables can be
> >  > regarded as internal variables that the transformers usually don't get
> >  > in touch with.
> >  > But from the point of view of the code creator these are the variables
> >  > that it has to use for substitution.
> >
> > I don't understand "low level" variables. If I understand the code right
> > you have these variables and few methods that modifies them, right?
> > So what is "low level" in this? This pattern is widely used in Py++.
>
> Well, with "low level" I just meant that they are 1) always of type
> string and used directly for substitution and 2) that the function
> transformers will usually not manipulate those variables directly.

I will post about this in different thread.

> I just went over it again and actually you're only making comments
> instead of posing questions. So, erm, there's actually nothing to
> answer... ;) Please rephrase any questions that are important for you to
> move the functionality forward.

Fair enough.

I propose to delete subst_t class. Main reason:
Method substitute defines some logic, according to which this it decides how to
indent the code. This is just wrong. code_manager_t class understands
the meaning of
the variables, so it is its respocibility to indent the code. Without
subsitute method this
class is pretty useless.

Do you agree with me?

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

Re: [pygccxml-development] FT - name uniqueness

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

On 10/10/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > Hi. I would like to propose solution for function name uniqueness problems.
> >
> > Problem description:
> >
> > void do_smth( int& );
> > void do_smth( int&, int& );
> >
> > If user will specify output_t transformer for both functions the
> > generate code will
> > not compile, because Py++ will generate 2 functions with the same signature.
> >
> > In order to solve this problem, we have to mangle into function name next data:
> > 1. full name ( namespaces, class names )
> > 2. return type information
> > 3. arguments type information
> > 4. template arguments type information
>
> Assuming that the name has been mangled, how do you invoke those two
> functions from Python?

I don't change the "alias" of the function, only its wrapper name.
Python will see
the original function name.


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

Re: [pygccxml-development] FT - name uniqueness

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

Roman Yakovenko wrote:
> Hi. I would like to propose solution for function name uniqueness problems.
> 
> Problem description:
> 
> void do_smth( int& );
> void do_smth( int&, int& );
> 
> If user will specify output_t transformer for both functions the
> generate code will
> not compile, because Py++ will generate 2 functions with the same signature.
> 
> In order to solve this problem, we have to mangle into function name next data:
> 1. full name ( namespaces, class names )
> 2. return type information
> 3. arguments type information
> 4. template arguments type information

Assuming that the name has been mangled, how do you invoke those two 
functions from Python?

- Matthias -

Re: [pygccxml-development] FT -subst_t

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

Roman Yakovenko wrote:
> On 10/8/06, Matthias Baas <ba...@ir... <mailto:ba...@ir...>> wrote:
>  > Roman Yakovenko wrote:
>  > > I don't understand why derived class code_manager_t should have 
> ugly variable
>  > > names: ARG_LIST_DEF,  ARG_LIST_TYPES and etc. This is not coding 
> convention
>  > > of Py++.
>  >
>  > I was using upper case variables for sort of "low level" variables that
>  > are usually initialized by corresponding lower case variables.
>  > From the
>  > point of view of the function transformer class these variables can be
>  > regarded as internal variables that the transformers usually don't get
>  > in touch with.
>  > But from the point of view of the code creator these are the variables
>  > that it has to use for substitution.
> 
> I don't understand "low level" variables. If I understand the code right
> you have these variables and few methods that modifies them, right?
> So what is "low level" in this? This pattern is widely used in Py++.

Well, with "low level" I just meant that they are 1) always of type 
string and used directly for substitution and 2) that the function 
transformers will usually not manipulate those variables directly.

>  > As to the rest of your mail, I'd rather like to begin at the top instead
>  > of the bottom and see if we can get to a consensus about the API that
>  > function transformer classes can access.
> 
> I read the rest of the mail. Trust me, I understand your idea.
> Please answer the question I post in the initial mail.

I just went over it again and actually you're only making comments 
instead of posing questions. So, erm, there's actually nothing to 
answer... ;) Please rephrase any questions that are important for you to 
move the functionality forward.

- Matthias -

Re: [pygccxml-development] Py++: Potentially nasty little template method problem

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

On 10/10/06, Allen Bierbaum <al...@vr...> wrote:
> Okay, so my problem is that I am wrapping a class you can see here:

I just commited the answer to your question. Take a look on
how_to.rest document,
last question: How to deal with template on return type functions?

> PS. I just tried the latest svn version of Py++ on my largest project
> and things seem to be working fine.

Can you provide feedback on add_properties algorithms? The
documentation in properties.rest
 document?

Also can you read and correct the documentation the project has?

Thank you.

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

Re: [pygccxml-development] Future freeze

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

On 10/10/06, Allen Bierbaum <al...@vr...> wrote:
> Will this version of Py++ have a helper method that can completely
> finalize a class?

Do you mean to not create wrapper for other cases than virtual and
pure virtual member
functions? If so than the answer is not, it will not contain such feature.


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

Re: [pygccxml-development] Future freeze

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

Roman Yakovenko wrote:

>Hi. I would like to freeze Py++ & pygccxml code for introducing new features.
>The only exception to this is FT feature. I think Py++ accumulated
>enough changes and we should release them.
>
>I ask you to test the source code and to report any bug you have. Also another
>very important task is documentation. Please read the documentation and report
>any problem you have with it( spelling errors, not good enough, not
>clear enough ... ).
>It could be nice if you say what area of Py++ is still undocumented
>and should be.
>
>Thank you.
>
>  
>
Roman:

Will this version of Py++ have a helper method that can completely 
finalize a class?

-Allen

[pygccxml-development] FT - name uniqueness

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

Hi. I would like to propose solution for function name uniqueness problems.

Problem description:

void do_smth( int& );
void do_smth( int&, int& );

If user will specify output_t transformer for both functions the
generate code will
not compile, because Py++ will generate 2 functions with the same signature.

In order to solve this problem, we have to mangle into function name next data:
1. full name ( namespaces, class names )
2. return type information
3. arguments type information
4. template arguments type information

Fortunately every function in pygccxml already has property that
contains all this
information: mangled . I think we can reuse it for this purpose.
Actually we will have to apply base64(
http://docs.python.org/lib/module-base64.html ) encoding in order to
get valid C++
identifier.

Comments?

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

[pygccxml-development] FT changes [was FT -subst_t ]

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

Matthias Baas wrote:
>As to the rest of your mail, I'd rather like to begin at the top instead
>of the bottom and see if we can get to a consensus about the API that
>function transformer classes can access. From all your mails about the
>topic I take it that the function transformer functionality as you have
>it in mind is quite a bit different than what I have implemented. So I
>started adding sort of a tutorial that explains how function
>transformers are written:
>
https://realityforge.vrsource.org/view/PyppApi/WritingCustomFunctionTransformers

Thank you for the document, now I understand better your idea.

>This is what a user has to know if he wants to write his own transformer
>classes using the current implementation (the tutorial is not exhaustive
>though). I have added two example classes that demonstrate some parts of
>the API. I'm assuming that the reader also has a look on the
>corresponding parts in the epydoc manual. If the interface as it is seen
>by the user would be kept intact then, of course, I wouldn't mind if the
>underlying implementation is modified.
>
>By the way, my current situation is that the current version of Py++ can
>almost do everything I wanted to have for the Maya bindings
>(unfortunately, I have just noticed that there actually are some pure
>virtual methods in the Maya SDK, so that's what's still missing for me
>to do another release). So during the last week I could actually
>continue developing the bindings which unfortunately left me with less
>time for Py++ (the last couple of changes have just been
>bugfixes). In addition to that, meanwhile we have a new version of Maya
>and creating the bindings for the new version has highlighted some other
>problems with Py++ (namely getting an overview of the differences
>between the versions and the generated bindings) which might lead to
>some modifications to pypp_api.
>Now I'm not sure if I should add the code creator for pure virtual
>members to the existing code (using the existing "implementation
>scheme") or to pypp_api. Knowing that the implementation won't survive
>anyway in function_transformers I'm a bit reluctant to add it there.

I want to make it clear: your idea will stay but implementation will
be slightly changed. I think we can do all changes I want in a week
or two.

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

[pygccxml-development] FT - transformer changes

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

Hi. I would like to introduce next changes to the FT classes.

1. rename function_transformer_t to transformer_t and add new class
function_transformation_t
    Consider  next example:
    struct vector3{
         vector3( int, int, int ){...}
    }

    draw_dot( vector3 ){ ... }

    User can expose this function as is, but will be able also define
convenience method
    that takes tuple.

    draw_dot( tuple ){
         internally constructs vector3 from tuple and calls the original
function.
    }

    function_transformation_t will keep list of all transformers that should
be applied to the function

    decl_wrappers.member_function_t will keep a list of all
function_transformation_t

    Obviously the user code, creator_t classes will have to change, but I
think this is a good
    reason.

2. rename arg_policies.py file to transformers.py

    Get rid of old name

3. every transformer class should derive from transformer_t

    1. This will introduce "transformer" concept to the Py++. Very, very
important.

    2. This will allow us to get rid of code
        src = map(lambda cb: getattr(cb, "wrapper_pre_call", defmeth)(self),
transformers)

4. every method defined in transformer_t class should return empty string
and not None.

    It will make it clear for user that every redefined method in the
derived class should return string

Matthoas what do you think?
-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] FT -subst_t

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

On 10/8/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > I don't understand why derived class code_manager_t should have ugly
variable
> > names: ARG_LIST_DEF,  ARG_LIST_TYPES and etc. This is not coding
convention
> > of Py++.
>
> I was using upper case variables for sort of "low level" variables that
> are usually initialized by corresponding lower case variables.
> From the
> point of view of the function transformer class these variables can be
> regarded as internal variables that the transformers usually don't get
> in touch with.
> But from the point of view of the code creator these are the variables
> that it has to use for substitution.

I don't understand "low level" variables. If I understand the code right
you have these variables and few methods that modifies them, right?
So what is "low level" in this? This pattern is widely used in Py++.

> > This class uses hard coded \n character. This is a mistake. It should
use
> >  os.linesep character.
>
> Of course, I have no objections if you use os.linesep in your code, but
> I just wanted to let you know that it doesn't really make a difference.
> The following was executed in a Python shell under Windows:
>
> >>> f=file("delme.txt", "wt")
> >>> f.write("\n")
> >>> f.close()
> >>> file("delme.txt", "rb").read()
> '\r\n'
>
> Under Linux the same sequence would result in '\n'. So you see, at least
> on Windows and Linux, the string "\n" is properly translated into a
> native newline.

You are using here universal line separator. First of I read somewhere
that this feature will be deprecated. Second in next release Py++
will write text files using "codecs" module. This should be done
in order to introduce documentation in different encodings.
I could be wrong, but this module opens files in a binary mode, so this
code will not work.

> As to the rest of your mail, I'd rather like to begin at the top instead
> of the bottom and see if we can get to a consensus about the API that
> function transformer classes can access.

I read the rest of the mail. Trust me, I understand your idea.
Please answer the question I post in the initial mail.

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

[pygccxml-development] FT argument\return type\value indexing - decision

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

Hi.
I think we discuss enough this point and there is no sense to continue. I am
not
happy with the way I do it, but it seems that I have no other choice.

Problem:  how user should address\refer to function argument and return
type\value.

Current implementation: index is 1 based, in order to allow user to specify
0 as
return.

The solution:

1. Index should be 0 based.

2. Special const will be introduced to represent "reference" to return
type\value:
    return_ = None ( or -1 ).

3. function_transformation_t will have new variable - USE_1_BASED_INDEXING
    By default its value will be False. Every one who consider "more
natural" to use
    0 based indexing will set this to True.

4. function_transformation_t will introduce 2 new methods:

    def get_argument( reference, func ):
        if isinstance( reference, str ):
            found = filter( lambda arg: arg.name == reference,
func.arguments )
            if len( found ) == 1:
                return found[0]
            raise RuntimeError( "Argument with %s was not found" % reference
)
       else:
           assert isinstance( reference, int )
           if function_transformation_t.USE_1_BASED_INDEXING:
               reference += 1
           return func.arguments[ reference ]

    def get_type( reference, func ):
        if isinstance( reference, int ) and reference == return_:
            return func.return_type
        else:
            return get_argument( reference, func ).type

    As you can see new implementation allows to use argument names as
parameter
    to transformers.

5. Every built-in transformer will have to use these functions.

One more time, I prefer to make a decision, when there is a consensus.
This time we don't have it. I hope the solution provides a compromise.
We still may discuss any detail of the solution, but I would like to make it
clear:
by default indexing will be 0 ( zero ) base.

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

Re: [pygccxml-development] FT - open issues

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

On 10/8/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> >> > 3. transformers index argument from 1 and not from zero. I think we
> >> > need to discuss
> >> >     this one more time. I don't agree with this interface. This is
> >> > tooooo confusing.
> >>
> >> Here's a piece of code from the Boost.Python tutorial:
> >>
> >> def("f", f,
> >>      return_internal_reference<1,
> >>          with_custodian_and_ward<1, 2> >());
> >>
> >> The numbers 1 and 2 refer to the first and second argument. So I would
> >> find it confusing if Py++ would do it otherwise.
> >>
> >> Besides that, I've reserved the index 0 to represent the return value.
> >
> > Because 0 represents self ( this ).
>
> Well, you say yourself that 0 does not represent the first value from
> the argument list. So what's your point? (by the way, the above code
> refers to a free function so there is no self/this)

Even global functions in Python has "self" argument.

> If the function transformers would be 0-based it could happen that one
> and the same argument has to be referred to by two different values,
> depending on the context. If the user applies a function transformer he
> would have to use the index 0 for the first argument whereas if he also
> applies a call policy he would have to use the index 1 for the very same
> argument. This is inconsistent.

It should not be consistent in this case.

> >> > 4. Base class for all transformations should be introduced.
> >>
> >> There is one already: function_transformer_t
> >> You may certainly derive from that class if you wish, it's just that you
> >> don't have to (because this class just defines/documents the interface
> >> and doesn't contain any actual code).
> >
> > Where is the code that decides what method should be called and what not?
>
> I'm not sure what "decision" you are referring to, but the methods are
> called in the substitution_manager_t class.

I will post my decision about this in another thread.

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

Re: [pygccxml-development] FT -subst_t

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

Roman Yakovenko wrote:
> I don't understand why derived class code_manager_t should have ugly variable
> names: ARG_LIST_DEF,  ARG_LIST_TYPES and etc. This is not coding convention
> of Py++.

I was using upper case variables for sort of "low level" variables that
are usually initialized by corresponding lower case variables. From the
point of view of the function transformer class these variables can be
regarded as internal variables that the transformers usually don't get
in touch with.
But from the point of view of the code creator these are the variables
that it has to use for substitution.

> This class uses hard coded \n character. This is a mistake. It should use
>  os.linesep character.

Of course, I have no objections if you use os.linesep in your code, but
I just wanted to let you know that it doesn't really make a difference.
The following was executed in a Python shell under Windows:

>>> f=file("delme.txt", "wt")
>>> f.write("\n")
>>> f.close()
>>> file("delme.txt", "rb").read()
'\r\n'

Under Linux the same sequence would result in '\n'. So you see, at least
on Windows and Linux, the string "\n" is properly translated into a
native newline.

As to the rest of your mail, I'd rather like to begin at the top instead
of the bottom and see if we can get to a consensus about the API that
function transformer classes can access. From all your mails about the
topic I take it that the function transformer functionality as you have
it in mind is quite a bit different than what I have implemented. So I
started adding sort of a tutorial that explains how function
transformers are written:
https://realityforge.vrsource.org/view/PyppApi/WritingCustomFunctionTransformers
This is what a user has to know if he wants to write his own transformer
classes using the current implementation (the tutorial is not exhaustive 
though). I have added two example classes that demonstrate some parts of 
the API. I'm assuming that the reader also has a look on the 
corresponding parts in the epydoc manual. If the interface as it is seen 
by the user would be kept intact then, of course, I wouldn't mind if the 
underlying implementation is modified.

By the way, my current situation is that the current version of Py++ can
almost do everything I wanted to have for the Maya bindings 
(unfortunately, I have just noticed that there actually are some pure 
virtual methods in the Maya SDK, so that's what's still missing for me 
to do another release). So during the last week I could actually 
continue developing the bindings which unfortunately left me with less 
time for Py++ (the last couple of changes have just been
bugfixes). In addition to that, meanwhile we have a new version of Maya
and creating the bindings for the new version has highlighted some other
problems with Py++ (namely getting an overview of the differences
between the versions and the generated bindings) which might lead to
some modifications to pypp_api.
Now I'm not sure if I should add the code creator for pure virtual 
members to the existing code (using the existing "implementation 
scheme") or to pypp_api. Knowing that the implementation won't survive 
anyway in function_transformers I'm a bit reluctant to add it there. But 
on the other hand, adding it in pypp_api would probably also require 
some modifications in Py++ as it doesn't allow that sort of flexibility 
yet (maybe I could get around that and replace the code creator nodes 
after that tree has been built, but that would be less efficient than 
adding the right nodes right from the beginning...).

- Matthias -

Re: [pygccxml-development] FT - open issues

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

Roman Yakovenko wrote:
>> > 3. transformers index argument from 1 and not from zero. I think we
>> > need to discuss
>> >     this one more time. I don't agree with this interface. This is
>> > tooooo confusing.
>>
>> Here's a piece of code from the Boost.Python tutorial:
>>
>> def("f", f,
>>      return_internal_reference<1,
>>          with_custodian_and_ward<1, 2> >());
>>
>> The numbers 1 and 2 refer to the first and second argument. So I would
>> find it confusing if Py++ would do it otherwise.
>>
>> Besides that, I've reserved the index 0 to represent the return value.
> 
> Because 0 represents self ( this ). 

Well, you say yourself that 0 does not represent the first value from
the argument list. So what's your point? (by the way, the above code
refers to a free function so there is no self/this)

If the function transformers would be 0-based it could happen that one
and the same argument has to be referred to by two different values,
depending on the context. If the user applies a function transformer he
would have to use the index 0 for the first argument whereas if he also
applies a call policy he would have to use the index 1 for the very same
argument. This is inconsistent.

>> > 4. Base class for all transformations should be introduced.
>>
>> There is one already: function_transformer_t
>> You may certainly derive from that class if you wish, it's just that you
>> don't have to (because this class just defines/documents the interface
>> and doesn't contain any actual code).
> 
> Where is the code that decides what method should be called and what not?

I'm not sure what "decision" you are referring to, but the methods are
called in the substitution_manager_t class.

- Matthias -

[pygccxml-development] Future freeze

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

Hi. I would like to freeze Py++ & pygccxml code for introducing new features.
The only exception to this is FT feature. I think Py++ accumulated
enough changes and we should release them.

I ask you to test the source code and to report any bug you have. Also another
very important task is documentation. Please read the documentation and report
any problem you have with it( spelling errors, not good enough, not
clear enough ... ).
It could be nice if you say what area of Py++ is still undocumented
and should be.

Thank you.

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

[pygccxml-development] FT -subst_t

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

Hi. The good new is that I started to work on FT feature. The bad news
is  that I don't agree with a lot of implementation details and
interfaces and this time
we will actually fix them.

Lets start.

subst_t we talked that this class should be implementation details and no one
should derive from it, right?  Hierachy is the wrong way to declare about
implementation details. The solution should be aggregation.

This class has ugly interface. subst_t.__init__ method takes as
parameter list of
block variables names. But when substitute function is called this class looks
for variables in self.__dict__. I don't understand why this should be that way.
I don't understand why this class has such interface that very easy to break.
I don't understand why derived class code_manager_t should have ugly variable
names: ARG_LIST_DEF,  ARG_LIST_TYPES and etc. This is not coding convention
of Py++.

This class uses hard coded \n character. This is a mistake. It should use
 os.linesep character.

code_creators_t class already defines indent function. This function should be
moved to utils package and reused from both places.

I don't understand the substitute method of this class. It defines some logic
according to which this method decidec how to indent the line of code. This
is just wrong. code_manager_t class understands the meaning of the variable,
so it is its respocibility to indent the code.

Without subsitute method this class is pretty useless. I think we
should remove it.

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

[pygccxml-development] FT - convenience functions

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

Hi. Matthias I implemented few convenience functions. Do you mind to
update transformers
to use it?

This will simplify them a little and will allow me continue to annoy you :-)

Thanks

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

Re: [pygccxml-development] [new feature]add_properties

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

On 10/5/06, Kevin Bluck <kev...@gm...> wrote:
>
> > If I am right, than I can not reproduce the bug ( behaviour ) you
> > describe, sorry.
> > Can you create small example that reproduce the problem?
> Hmm... now I can't reproduce it either. It might have been another one
> of my famous incompatibilities.
>
> Sorry. I'll let you know if I figure it out.

This is okey.

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

Re: [pygccxml-development] [new feature]add_properties

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

On 10/4/06, Kevin Bluck <kev...@gm...> wrote:
> Roman Yakovenko wrote:
> > Hi. I added new future - add_properties.
> > The idea behind this functionality is to automatically recognize and
> > add properties to the class.
> >
> Excellent idea. I was just thinking about how to script something like this.
>
> > my_class.add_properties()
> > or
> > my_class.add_properties( exclude_accessors=True )
> >
>
> I have a class with both getValue() and setValue(). setValue() is
> explicitly excluded (it happens to be a protected member and I don't
> want protected members.)
>
> I noticed that in this case add_properties() does not automatically add
> a read-only property Value for the still-visible getValue(). You have to
> specify param exclude_accessors=True.
>
> If I do not explicitly exclude member function setValue(), it binds a
> setValue() function as expected, but it still generates a read-only
> property Value regardless of exclude_accessors True or False.

This is your use case, as I understand it:

struct data_t{
    int getValue() const { return 1;}
protected:
    void setValue(int){}
};

where setValue is excluded, right?

If I am right, than I can not reproduce the bug ( behaviour ) you
describe, sorry.
Can you create small example that reproduce the problem?

Thank you

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

Re: [pygccxml-development] [new feature]add_properties

[Kevin B. <kev...@gm...>]

Roman Yakovenko wrote:
> Hi. I added new future - add_properties.
> The idea behind this functionality is to automatically recognize and
> add properties to the class.
>   
Excellent idea. I was just thinking about how to script something like this.

> my_class.add_properties()
> or
> my_class.add_properties( exclude_accessors=True )
>   

I have a class with both getValue() and setValue(). setValue() is 
explicitly excluded (it happens to be a protected member and I don't 
want protected members.)

I noticed that in this case add_properties() does not automatically add 
a read-only property Value for the still-visible getValue(). You have to 
specify param exclude_accessors=True.

If I do not explicitly exclude member function setValue(), it binds a 
setValue() function as expected, but it still generates a read-only 
property Value regardless of exclude_accessors True or False.

--- Kevin

Re: [pygccxml-development] FT - open issues

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

On 10/4/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > 2. Name uniqueness\resolution. For example:
> >     for next C++ code
> >
> >     namespace ft{
> >     struct xxx_t{
> >         static void get_value( int& x ){ x = 21; }
> >      private:
> >         ~xxx_t(){}
> >      };
> >
> >    Py++ generates next code
> >
> >    static boost::python::object _py_get_value(  ) {
> >        int x;
> >        xxx_t::get_value(x);
> >        return boost::python::object(x);
> >    }
> >
> >    Obviously if I will introduce similar class with other name, Py++
> > will not generate unique name for get_value.
>
> You're right. (On the other hand, this other class might reside in its
> own source file anyway which reduces chances for a name clash)
> I'll see what I can do. I guess it shouldn't be a problem to incorporate
> the class name into the function name.
>
> > 3. transformers index argument from 1 and not from zero. I think we
> > need to discuss
> >     this one more time. I don't agree with this interface. This is
> > tooooo confusing.
>
> Here's a piece of code from the Boost.Python tutorial:
>
> def("f", f,
>      return_internal_reference<1,
>          with_custodian_and_ward<1, 2> >());
>
> The numbers 1 and 2 refer to the first and second argument. So I would
> find it confusing if Py++ would do it otherwise.
>
> Besides that, I've reserved the index 0 to represent the return value.

Because 0 represents self ( this ). Matthias please consider to change to
0 based.

> > 4. Base class for all transformations should be introduced.
>
> There is one already: function_transformer_t
> You may certainly derive from that class if you wish, it's just that you
> don't have to (because this class just defines/documents the interface
> and doesn't contain any actual code).

Where is the code that decides what method should be called and what not?

> > 6. Generated code should be different. I mean we should introduce more
> > convenience functions in code repository.
>
> Right, I haven't had the time yet to incorporate all the stuff from that
> other thread. But speaking of which, I did try to find that
> boost::python::len function you were mentioning but couldn't find it
> anywhere.
>
> - Matthias -
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> 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] AttributeError in r598

[Kevin B. <kev...@gm...>]

Roman Yakovenko wrote:
> May be you did not check out the latest source code of pygccxml?

Ah, so I need to SVN that one as well. Thanks, that was it. I'll file 
that one next to the cache refresh.

--- Kevin

Re: [pygccxml-development] Member variables and their access type?

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

On 10/4/06, Matthias Baas <ba...@ir...> wrote:
> After updating I noticed the modification from r616 that the
> _set_arguments() method was commented out which broke the function
> transformer unit test.
> What's the reason why arguments should not be set? _get_arguments()
> still returns the internal list, so the class isn't really protected
> from being modified. I'm using this as a workaround now, but obviously
> I'm not supposed to change the list...?

No, I had a bug, that has been discovered on huge project while using
properties.
It was very difficult to find it, so I commented the _set_arguments, I
thought it will help to find
the bug.

I committed the fix.

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