pygccxml-development

Re: [pygccxml-development] FT - open issues

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

Does this mean that the current svn version should be stable enough 
right now to start using/testing.  I must admit that with all the 
changes you and Matthias have been introducing I have not updated my 
checked out copies for several weeks.  I have been waiting for things to 
stabilize so I didn't break my development system. :)

I am more then happy to help test things though if the time has come.

-Allen


Roman Yakovenko wrote:
> Hi. I think Py++ accumulated enough changes, so we can start on
> preparing it to be released. Before we do this, I prefer to see few
> issues fixed in FT:
> 
> 1. Better formatting of generated code.
> 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.
> 
> 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.
> 
> 4. Base class for all transformations should be introduced.
> 
> 5. Class that represents "final" transformation should be introduced.
> 
> 6. Generated code should be different. I mean we should introduce more
> convenience
>     functions in code repository.
> 
> I can help with 4,5,6 items.
> 
> --
> Roman Yakovenko
> C++ Python language binding
> http://www.language-binding.net/
> 
> -------------------------------------------------------------------------
> 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
> 

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

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

Roman Yakovenko wrote:
>> >> So how can I check the access type of a member variable?
>> >
>> > mem_var.parent.find_out_member_access_type( mem_var )
>>
>> Is this going to change in the future (so that there's a property
>> access_type)? I think it's not intuitive that member variables have to
>> be treated differently than member functions (after all, they are both
>> members and the access type is a property of a member).
> 
> Done

Thanks! (this reduced the number of warnings from 511 to 389! :)

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

- Matthias -

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

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

On 10/4/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> >> I just noticed a slight problem with Py++. I tried to ignore private
> >> member variables
> >
> > Py++ should ignore them by default, so I don't understand what you are
> > trying to do.
>
> Well, don't worry, I guess this is just an "artifact" of using
> pypp_api... ;)
> (I was just trying to get rid of some warnings)
>
> >> but the class variable_t doesn't have a property
> >> "access_type". It seems that property is only available on classes
> >> derived from member_calldef_t.
> >
> > Right, because I don't have global_variable_t and member_variable_t classes
> >
> >> So how can I check the access type of a member variable?
> >
> > mem_var.parent.find_out_member_access_type( mem_var )
>
> Is this going to change in the future (so that there's a property
> access_type)? I think it's not intuitive that member variables have to
> be treated differently than member functions (after all, they are both
> members and the access type is a property of a member).

Done


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

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

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

Roman Yakovenko wrote:
>> I just noticed a slight problem with Py++. I tried to ignore private
>> member variables
> 
> Py++ should ignore them by default, so I don't understand what you are
> trying to do.

Well, don't worry, I guess this is just an "artifact" of using 
pypp_api... ;)
(I was just trying to get rid of some warnings)

>> but the class variable_t doesn't have a property
>> "access_type". It seems that property is only available on classes
>> derived from member_calldef_t.
> 
> Right, because I don't have global_variable_t and member_variable_t classes
> 
>> So how can I check the access type of a member variable?
> 
> mem_var.parent.find_out_member_access_type( mem_var )

Is this going to change in the future (so that there's a property 
access_type)? I think it's not intuitive that member variables have to 
be treated differently than member functions (after all, they are both 
members and the access type is a property of a member).

- Matthias -

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

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

On 10/4/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> I just noticed a slight problem with Py++. I tried to ignore private
> member variables

Py++ should ignore them by default, so I don't understand what you are
trying to do.

> but the class variable_t doesn't have a property
> "access_type". It seems that property is only available on classes
> derived from member_calldef_t.

Right, because I don't have global_variable_t and member_variable_t classes

> So how can I check the access type of a member variable?

mem_var.parent.find_out_member_access_type( mem_var )

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

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

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

Hi,

I just noticed a slight problem with Py++. I tried to ignore private 
member variables but the class variable_t doesn't have a property 
"access_type". It seems that property is only available on classes 
derived from member_calldef_t.
So how can I check the access type of a member variable?

- Matthias -

Re: [pygccxml-development] FT - open issues

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

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.

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

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

[pygccxml-development] [new feature]add_properties

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

Hi. I added new future - add_properties.
The idea behind this functionality is to automatically recognize and
add properties to the class.
The "add_properties" functionality aware of few coding conventions:
    UpperCamel
    lowCamel
    words_separated_with_underscore
And also it is aware of common prefixes: get, is, has, <<empty prefix>>, set.
It is possible to configure to exclude functions that has been used
for properties.

Usage example:
mb = module_builder_t( ... )
my_class = mb.class_( ... )
my_class.add_properties()
or
my_class.add_properties( exclude_accessors=True )

The implementation of algorithm could be found here:
http://svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/pyplusplus/decl_wrappers/properties.py?view=markup

Your comments, suggestions, bugs are welcome.

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

Re: [pygccxml-development] AttributeError in r598

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

On 10/3/06, Kevin Bluck <kev...@gm...> wrote:
> Starting with SVN r598, I began getting this error:
>
> Traceback (most recent call last):
>   File "./test.py", line 56, in <module>
>     builder.build_code_creator(module_name='test')
>   File "C:\Program
> Files\Python\lib\site-packages\pyplusplus\module_builder\builder.py",
> line 247, in build_code_creator
>     self.__code_creator = creator.create()
>   File "C:\Program
> Files\Python\lib\site-packages\pyplusplus\module_creator\creator.py",
> line 461, in create
>     declarations.apply_visitor( self, decl )
>   File "C:\Program
> Files\Python\Lib\site-packages\pygccxml\declarations\algorithm.py", line
> 263, in apply_visitor
>     getattr( visitor, fname )()
>   File "C:\Program
> Files\Python\lib\site-packages\pyplusplus\module_creator\creator.py",
> line 687, in visit_class
>     for redefined_func in cls_decl.redefined_funcs():
>   File "C:\Program
> Files\Python\lib\site-packages\pyplusplus\decl_wrappers\class_wrapper.py",
> line 386, in redefined_funcs
>     is_same_function = declarations.is_same_function
> AttributeError: 'module' object has no attribute 'is_same_function'
>
> The error sticks all the way from 598 to HEAD. 597 and earlier don't
> have this error. I verified that it's not my previous cache upgrade
> problem. :-)

May be you did not check out the latest source code of pygccxml?


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

[pygccxml-development] AttributeError in r598

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

Starting with SVN r598, I began getting this error:

Traceback (most recent call last):
  File "./test.py", line 56, in <module>
    builder.build_code_creator(module_name='test')
  File "C:\Program 
Files\Python\lib\site-packages\pyplusplus\module_builder\builder.py", 
line 247, in build_code_creator
    self.__code_creator = creator.create()
  File "C:\Program 
Files\Python\lib\site-packages\pyplusplus\module_creator\creator.py", 
line 461, in create
    declarations.apply_visitor( self, decl )
  File "C:\Program 
Files\Python\Lib\site-packages\pygccxml\declarations\algorithm.py", line 
263, in apply_visitor
    getattr( visitor, fname )()
  File "C:\Program 
Files\Python\lib\site-packages\pyplusplus\module_creator\creator.py", 
line 687, in visit_class
    for redefined_func in cls_decl.redefined_funcs():
  File "C:\Program 
Files\Python\lib\site-packages\pyplusplus\decl_wrappers\class_wrapper.py", 
line 386, in redefined_funcs
    is_same_function = declarations.is_same_function
AttributeError: 'module' object has no attribute 'is_same_function'

The error sticks all the way from 598 to HEAD. 597 and earlier don't 
have this error. I verified that it's not my previous cache upgrade 
problem. :-)

Thanks,

--- kevin

[pygccxml-development] FT - open issues

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

Hi. I think Py++ accumulated enough changes, so we can start on
preparing it to be released. Before we do this, I prefer to see few
issues fixed in FT:

1. Better formatting of generated code.
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.

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.

4. Base class for all transformations should be introduced.

5. Class that represents "final" transformation should be introduced.

6. Generated code should be different. I mean we should introduce more
convenience
    functions in code repository.

I can help with 4,5,6 items.

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

Re: [pygccxml-development] __getitem__ / __setitem__

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

Roman Yakovenko wrote:
> If you write test code I can spend few hours on adding this functionality.
> Test cases ( instead of double ):
>    1. fundamental type ( double is good )
>    2. pointer to some struct
>    3. reference to some struct
>    4. reference to noncopyable object ( in this case __setitem__
> should not be generated )
>    5. other use cases I missed :-)

I have written some sample code that contains a few test scenarios (see 
below).
I could imagine that something like the below double_array_2 class could 
be problematic because it has a single operator that should generate two 
separate Python methods.
(Each of the below cases could also be extended by adding a function 
transformer that checks the range of the index, for example)

- Matthias -



/*
   This class only provides an index operator that does not return a 
reference.

   The wrapper class should only contain a __getitem__() method and
   no __setitem__() method.
  */
struct double_array_1
{
   double dummy_array[2];

   double_array_1() { dummy_array[0] = 0; dummy_array[1] = 0; }
   double operator[](unsigned int i) const { return dummy_array[i]; }
};

/*
   This class only provides a single index operator that returns a 
reference.

   The index operator can be used for both, reading and writing values,
   so the wrapper class should contain __getitem__ and __setitem__.
  */
struct double_array_2
{
   double dummy_array[2];

   double_array_2() { dummy_array[0] = 0; dummy_array[1] = 0; }
   double& operator[](unsigned int i) { return dummy_array[i]; }
};

/*
   This class provides two index operators.

   The wrapper class should be the same as in double_array_2, the
   additional operator doesn't have a visible effect to the Python
   bindings (in particular, there should not be two __getitem__ methods).
  */
struct double_array_3
{
   double dummy_array[2];

   double_array_3() { dummy_array[0] = 0; dummy_array[1] = 0; }
   double& operator[](unsigned int i) { return dummy_array[i]; }
   double operator[](unsigned int i) const { return dummy_array[i]; }
};

//////////////////////////////////////////////////////////////////////

/*
   The following two array classes use a custom defined item class
   (instead of a fundamental type).
  */
struct item
{
   double value;
   item(double val=0) : value(val) {}
};

struct item_array_1
{
   item dummy_array[2];

   item& operator[](unsigned int i) { return dummy_array[i]; }
};

struct item_array_2
{
   item dummy_array[2];

   // Return a const item. This can not (!) be used for __setitem__
   const item& operator[](unsigned int i) { return dummy_array[i]; }
};

//////////////////////////////////////////////////////////////////////

/*
   The following item defines a private assignment operator, so
   __setitem__ is not possible.
  */

struct item2
{
   double value;
   item2(double val=0) : value(val) {}
   private:
   item2& operator=(const item2& other) { std::cout<<"FOO"<<std::endl; 
return *this; }
};

struct item2_array_1
{
   item2 dummy_array[2];

   item2& operator[](unsigned int i) { return dummy_array[i]; }
};

[pygccxml-development] static variable and noncopyable question

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

I have a problem with my code generator.  When wrapping a vector class 
defined here: 
http://opensg.vrsource.org/trac/browser/trunk/Source/Base/Base/OSGVector.h#L601

The "Null" variable makes the noncopoyable test fail because it isn't 
detected as static for some reason (ie. the test 
mvar.type_qualifiers.has_static in __is_noncopyable_single returns 
false).  Any clues as to what may cause this or how to track it down?

I ran into something while trying to track down a bug...

This may be a limit to my C++ knowledge, but why does the 
type_traits.__is_noncopyable_single method consider a class non-copyable 
if it has const member variables.  It seems to me that the class could 
still be copyable.

-Allen

Re: [pygccxml-development] MAC OS X Support?

[Darren G. <ga...@MI...>]

Hmm.. I think that this message got bounced.

Anyhow, I can confirm that installation of Py++ from the SVN works as  
expected in the normal way.

pygccxml runs and passes all unittests.

I haven't gotten the unittests in pyplusplus to run since I don't  
have Scons setup quite right...  But I can run the example programs  
and have gotten my own code to work.

So, the instructions are very simple...

get fink, so you can get "cmake" so you can install gccxml.... (this  
is the hard part.... but if you are desperate, I could make a  
universal binary installer for you....)

get boost...  I downloaded the binary boost-jam and then made boost  
from the source.  This won't work if you have an intel mac though.   
You'll have to build boost-jam as well. (The latest release... not  
the cvs).

get Py++  and do the "python setup.py install" thing.

Cheers,
Darren.


On Sep 26, 2006, at 6:42 PM, Darren Garnier wrote:

> Hi all,
>
> Long time lurker...  first time poster.  I have used Py++ on the  
> mac.  I used v. 0.80 from back in June and had minimal problems  
> "porting" it to the mac.  (Like 2 lines that I sent a patch to  
> Roman with).   I used it for a quick project and haven't gotten  
> back to trying it since all the numerous improvements.
>
> Anyway, its just to say, if it doesn't just work  the python setup  
> install way, it won't be hard to fix any issues.  If I get a chance  
> to update, I'll send specific instructions... in the meantime  
> "Courage".
>
> Darren.
> Levitated Dipole Experiment
> http://www.psfc.mit.edu/ldx/
>
>
> On Sep 26, 2006, at 2:25 PM, Roman Yakovenko wrote:
>
>> On 9/26/06, Brian OBrien <bob...@ya...> wrote:
>>> If I gave you an account on my system... Do you think
>>> you could help to get this running?
>>
>> To tell you the true I never used MAC computer. More over I fill  
>> better when
>> I use Windows than Linux. So, sorry I can help you. May be you can  
>> ask for
>> help at Boost.Python mailing list. I am sure there are few MAC  
>> users there.
>>
>>> Is this even the
>>> right group to be dicussing py++
>>
>> Yes this is a right group to discuss Py++, actually this is the  
>> only thing we do
>> in this group :-)
>>
>> -- 
>> Roman Yakovenko
>> C++ Python language binding
>> http://www.language-binding.net/
>>
>> --------------------------------------------------------------------- 
>> ----
>> 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
>

Re: [pygccxml-development] __getitem__ / __setitem__

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

Roman Yakovenko wrote:
>> Py++ turns index operators into a __getitem__() method. Now I was just
>> wondering if it should also create a __setitem__() method when there's
>> an operator that returns a reference?
>> [...]
> 
> double& operator[]( unsinged i )
> 
> ==>
> 
> void __setitem__( unsigned i, double value ){
>    this->operator[]( i ) = value;
> }
> 
> This is what you mean, right? 

Yes.

> It could be done, it should not be a problem.
> If you write test code I can spend few hours on adding this functionality.
> Test cases ( instead of double ):
>    1. fundamental type ( double is good )
>    2. pointer to some struct
>    3. reference to some struct
>    4. reference to noncopyable object ( in this case __setitem__
> should not be generated )
>    5. other use cases I missed :-)

Well, my own use-cases are of the first type, so they are among the 
easier ones. I'm not so sure about the other cases when the values are 
actual objects.
Has anybody else here had to wrap index operators? Did you do it 
manually and have there been any special situations? What are your 
thoughts about such a feature?

- Matthias -

[pygccxml-development] __getitem__ / __setitem__

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

Hi,

Py++ turns index operators into a __getitem__() method. Now I was just 
wondering if it should also create a __setitem__() method when there's 
an operator that returns a reference?

I have some cases where this would be desirable (but I don't know if 
it's desirable in every case). For example, the Maya vector classes 
define operators like these:

double& operator[] ( unsigned i );
double operator[] ( unsigned i ) const;

So far, I was ignoring the first one and only wrapped the second one 
which was correctly turned into a __getitem__() method (but of course, 
this meant I couldn't assign values via the index operator).
In this case, the first operator could actually spawn a __setitem__() 
method as well. I have no problems with doing that manually, but I was 
just wondering if this could/should be made an (optional?) builtin 
functionality of Py++ and so I'm just throwing in the idea...

- Matthias -

Re: [pygccxml-development] Chaining calls

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

Roman Yakovenko wrote:
>> For example, I think it would be great if in addition to writing this:
>>
>> myclass = mb.class_('myclass')
>> ...
>> myclass_foo = myclass.member_function('goo')
>> myclass_foo.rename('foo')
>> myclass_foo.include()
>>
>> ... you could also write this:
>>
>> myclass = mb.class_('myclass')
>> ...
>> myclass.member_function('goo').rename('foo').include()
> 
> I don't see a problem with it. Matthias what do you think?

Of course, that's fine with me (pypp_api does that already anyway... 
(but I just noticed that I had to fix some methods)).

- Matthias -

Re: [pygccxml-development] [new feature]add_property add_static_property

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

On 9/27/06, Kevin Bluck <kev...@gm...> wrote:
>
> > Actually it was my bug. Fix in svn. Unit test has been updated.
> >
>
> Thanks, SVN rev. 595 fixed the AttributeError.
>
> I notice that add_property causes the generated C++ to go from IDL
> syntax to exposer_t syntax even in the simplest of cases. Is this
> intended behavior?

Yes. There are few reasons for this:
1. readability - I think that generated code is more readable. If you
stay with IDL like
   syntax you will get very very long line.
2. compilation errors - it is much easier to understand what compiler says
3. For MSVC 7.1 compiler, for template classes instantiations you have to
    define function type and than to use it within expression,
otherwise the generated
    code will not compile.
4. Lack of time - I can implement IDL like syntax, but it will
complicate the code.
    I don't have enough time to implement and test it.

If you think that this should be fixed - consider to contribute your
time and efforts :-)

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

Re: [pygccxml-development] [new feature]add_property add_static_property

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

> Actually it was my bug. Fix in svn. Unit test has been updated.
>

Thanks, SVN rev. 595 fixed the AttributeError.

I notice that add_property causes the generated C++ to go from IDL 
syntax to exposer_t syntax even in the simplest of cases. Is this 
intended behavior?

Thanks,

--- Kevin

Re: [pygccxml-development] [new feature]add_property add_static_property

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

On 9/26/06, Kevin Bluck <kev...@gm...> wrote:
> Roman Yakovenko wrote:
> > data.add_property( "count", count, set_count )
> >
> Should it be possible to leave out the 'set' function to make a
> read-only property?

Yes of course. By default 'set' is None

> When I tried something like:
>
> data.add_property( "count", count )
>
>
>  I got:
>
>   File "C:\Program
> Files\Python\lib\site-packages\pyplusplus\code_creators\properties.py",
> line 56, in has_long_line
>     elif pd.fset or pd.fset.call_policies or not
> pd.fset.call_policies.is_default():
> AttributeError: 'NoneType' object has no attribute 'call_policies'
>

Actually it was my bug. Fix in svn. Unit test has been updated.

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

Re: [pygccxml-development] [new feature]add_property add_static_property

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

Roman Yakovenko wrote:
> data.add_property( "count", count, set_count )
>   
Should it be possible to leave out the 'set' function to make a 
read-only property? When I tried something like:

data.add_property( "count", count )


 I got:

  File "C:\Program 
Files\Python\lib\site-packages\pyplusplus\code_creators\properties.py", 
line 56, in has_long_line
    elif pd.fset or pd.fset.call_policies or not 
pd.fset.call_policies.is_default():
AttributeError: 'NoneType' object has no attribute 'call_policies'

Thanks,

--- Kevin

Re: [pygccxml-development] AttributeError for member_function_t during build_code_creator()

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

> Are you using a cache? Have you removed the cache file/directory prior to running the updated version of Py++? The cache contains old objects that might not yet have attributes 
> introduced in a newer version.
>   
Yes, that was apparently the problem. Thanks.

> I think we should introduce some solution to the problem. Ideas?
I guess you'd have to introduce a version identifier into the cache data 
format. Perhaps SVN revision number. If not equal, then delete cache.

--- Kevin

Re: [pygccxml-development] [pygccxml-commit] SF.net SVN: pygccxml: [570] pyplusplus_dev/pyplusplus

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

On 9/24/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > On 9/23/06, Matthias Baas <ba...@ir...> wrote:
> >> Roman Yakovenko wrote:
> >> > They should. Can you give me few good reasons to not create wrappers?
> >>
> >> I've just stumbled over another problem as I compiled the bindings on
> >> Linux. Compilation fails because of a class that has a private
> >> destructor. This class only provides static members and a few enums, it
> >> isn't meant to be instantiated (let alone sub-classed).
> >
> > Sometimes static members need wrapper, for example arrays.
> > Can you post small code that reproduce the problem?
>
> class Foo
> {
>    public:
>    static void get_value(int& n) { n = 12; }
>
>    private:
>    ~Foo() {}
> };
>
> In your generation script you have to assign the output transformer to
> get_value:
>
> Foo.member_function("get_value").function_transformers.append(output_t(1))
>
> Compilation will then produce the following error:
>
> testlib.h: In constructor `Foo_wrapper::Foo_wrapper()':
> testlib.h:14: error: `Foo::~Foo()' is private
> testlib/Foo.pypp.cpp:13: error: within this context
> error: command 'gcc' failed with exit status 1
>
>
> Tested on Linux with gcc 3.3.4 (whereas MSVC 7.1 obviously ignores that
> the destructor is private and compiles the above code without problems,
> so you have to test with gcc as well).

I test generated code on two compilers: MSVC 7.1 and gcc 4.0.3.

The generated code does not work. Also I don't see other choice but not to
generate wrapper in this specific case. I will try to fix it in next few days.

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

Re: [pygccxml-development] create_castinig_constructor=True (sic)

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

On 9/26/06, Kevin Bluck <kev...@gm...> wrote:
> At line 206 of module_builder/buildper.py, argument
> create_castinig_constructor is defaulted to True.
>
> I see at line 234 a deprecation warning: "create_castinig_constructor
> argument is deprecated and should not be used."
>
> Shouldn't that argument be defaulted to False

The default value was True, if I change it to False I will break users code.

> Also, if you didn't notice, the argument should be spelled:
> 'create_casting_constructor'.

No, I am not. If you find such errors please report them.
Thank you.

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

Re: [pygccxml-development] Chaining calls

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

On 9/26/06, Kevin Bluck <kev...@gm...> wrote:
> In general, I think it would be helpful if methods that modify an object
> instance would return a reference to the modified instance instead of
> 'None'. This would allow calls to be chained if desired rather than
> having to assign an explicit named reference whenever more than one
> operation is desired.
>
> For example, I think it would be great if in addition to writing this:
>
> myclass = mb.class_('myclass')
> ...
> myclass_foo = myclass.member_function('goo')
> myclass_foo.rename('foo')
> myclass_foo.include()
>
> ... you could also write this:
>
> myclass = mb.class_('myclass')
> ...
> myclass.member_function('goo').rename('foo').include()

I don't see a problem with it. Matthias what do you think?

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