cxx-users — Discuss the use and improvement of PyCXX

RE: the performance of pycxx

[<las...@si...>]

Thanks, Paul, for explain why to calculate fib in this way is bad.
I try to use pycxx, because I thought it is a tool to write py extension. And as for extension, before this example, I always thought it is used to speed the py source.
 
I tried some tools, and got a table. In this table, the speed is calculated in second. 
As we can see:
1. no matter cython, swig, pyinline or shedskin, they compiled C/C++ source into PYD. and all the PYDs give a great increase in speed 
2. pycxx compiled C++ source into PYD too, but this PYD is even slower than a pure python function heavily!
so from this example, I conclude that pycxx is only for the aim "to write python exteison in C++ easily", but not for the aim "to speed up the original pure python program". Am I right?
 
M  | pure py |cython | swig  | pycxx  | cinpy | pyinline | psyco | shedskin
---+----------+---------+------+---------+--------+---------+--------+-----------
40 | 116.64  |   3.70   | 5.40  | 789.81 |  4.00   |  4.66    |  6.22   |  3.50
30 |   0.93   |  0.03    | 0.03  |   6.35   |   0.03  |  0.03    |  0.05   |  0.03
 
I don't want to list all the source files I used here, because they are all recursion function, and have the almost same and simple source code structure as the following codes.
 
[pure py]
def fib(n):
    if n<=1:
        return 1
    else:
        return fib(n-1)+fib(n-2) 
M=30
st=time.time()
for i in range(M):
    fib(i)
et=time.time()
print fib(M)
print 'time: %.2f secs' % (et-st)
[/pure py]
 
[test_pyinline]
import time
import PyInline, __main__
m = PyInline.build(code="""
    long fib(int a) {
        if (a<2)   return 1;
        return fib(a-2)+fib(a-1);
  }""",
  targetmodule=__main__, language="C")
M=30
st=time.time()
for i in range(M):
    fib(i)
et=time.time()
print fib(M)
print 'time: %.2f secs' % (et-st)
[/test_pyinline]

RE: the performance of pycxx

[Paul K. <Pau...@ni...>]

Laserjungle,

The way you wrote it causes an explosive number of function calls for increase of n. You're computing fib(n-1)+fib(n-2) each time, but you don't need to do that, because in the process of computing each value of fib(n-1), you also need to compute fib(n-2). That causes an unnecessary doubling of the code path, for each level of recursion, meaning that it is way longer than it needs to be (I think by a factor of n**(2**n), but I haven't done a proper analysis, so complexity buffs needn't bother to shoot me down).

The whole purpose of pycxx is to provide a function wrapper. The wrapper is doing a lot, and obviously it has quite a bit of overhead. By importing this overhead into each function call of an already horribly inefficient recursive algorithm, it's not surprising you get performance numbers you don't like.

To convince yourself of this, put a counter or a print statement into your code to show you how many times you are calling fib(). Once you are sufficiently horrified, Google for alternative Fibonacci implementations to reduce the number of times you have to go between Python and C++, and you should see a dramatic improvement.

Paul Keating

From: las...@si... [mailto:las...@si...]
Sent: 22 November 2011 04:40
To: cxx-users
Subject: the performance of pycxx


I wrote a py extension to calculate fibonacci sequence (i.e. 1 1 2 3 5 ... ) as following

however, I found it is too slow as the table says



so, what is the problem? Diid I do something wrong? thanks



M    | speed for pure py | speed for pycxx

-----+-----------------------+--------------------

30    |      0.93 sec          |         6.35 sec

40    |     116.64 sec       |        789.91 sec





[py code]

import time

def fib(n):
    if n<=1:
        return 1
    else:
        return fib(n-1)+fib(n-2)

print fib(M)
st=time.time()
for i in range(M):
    fib(i)
et=time.time()
print 'pure py=%.2f secs' % (et-st)

[/py code]





[pycxx code]

#ifdef _MSC_VER

#pragma warning(disable: 4786)

#endif



#include "CXX/Objects.hxx"

#include "CXX/Extensions.hxx"



class fib_module : public Py::ExtensionModule<fib_module>{

public:

    fib_module():Py::ExtensionModule<fib_module>( "fib" ){

    add_varargs_method("fib", &fib_module::fib, "fibonacci sequence function");

    initialize( "this is the test module" );

  }



  virtual ~fib_module(){}



private:

    Py::Object fib (const Py::Tuple &args){

        args.verify_length(1);

        Py::Long res = args[0];

        if (res<=Py::Long(1))  return Py::Long(1);

        else{

            Py::Tuple a(1), b(1); a[0]=Py::Long(res-2); b[0]=Py::Long(res-1);

            return fib(a)+fib(b);

        }

    }

};



#if defined( _WIN32 )

#define EXPORT_SYMBOL __declspec( dllexport )

#else

#define EXPORT_SYMBOL

#endif



extern "C" EXPORT_SYMBOL void initfib(){

#if defined(PY_WIN32_DELAYLOAD_PYTHON_DLL)

    Py::InitialisePythonIndirectPy::Interface();

#endif

    static fib_module* fib = new fib_module;

}



extern "C" EXPORT_SYMBOL void initfib_d(){ initfib(); }


[/pycxx code]

________________________________
The information contained in this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail. Please delete this e-mail and do not disclose its contents to any person. NIBC Holding N.V. nor its subsidiaries accept liability for any errors, omissions, delays of receipt or viruses in the contents of this message which arise as a result of e-mail transmission. NIBC Holding N.V. (Chamber of commerce nr. 27282935), NIBC Bank N.V. (Chamber of commerce nr. 27032036) and NIBC Investment Management N.V. (Chamber of commerce nr. 27253909) all have their corporate seat in The Hague, The Netherlands.

De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, gelieve onmiddellijk contact op te nemen met de afzender per kerende e-mail. Wij verzoeken u dit e-mailbericht te Vernietigen en de inhoud ervan aan niemand openbaar te maken. NIBC Holding N.V. noch haar dochterondernemingen aanvaarden enige aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van een verzonden e-mailbericht, noch voor door haar daarbij overgebrachte virussen. NIBC Holding N.V. (KvK nr. 27282935), NIBC Bank N.V. (KvK nr. 27032036) en NIBC Investment Management N.V. (KvK nr. 27253909) zijn statutair gevestigd te Den Haag, Nederland.

the performance of pycxx

[<las...@si...>]

I wrote a py extension to calculate fibonacci sequence (i.e. 1 1 2 3 5 ... ) as following
however, I found it is too slow as the table says
 
so, what is the problem? Diid I do something wrong? thanks
 
M    | speed for pure py | speed for pycxx
-----+-----------------------+--------------------
30    |      0.93 sec          |         6.35 sec
40    |     116.64 sec       |        789.91 sec
 
 
[py code]
import time
def fib(n):
    if n<=1:
        return 1
    else:
        return fib(n-1)+fib(n-2)
print fib(M)
st=time.time()
for i in range(M):
    fib(i)
et=time.time()
print 'pure py=%.2f secs' % (et-st)
[/py code]
 
 
[pycxx code]





#ifdef _MSC_VER
#pragma warning(disable: 4786)
#endif
 
#include "CXX/Objects.hxx"
#include "CXX/Extensions.hxx"
 
class fib_module : public Py::ExtensionModule<fib_module>{
public:
    fib_module():Py::ExtensionModule<fib_module>( "fib" ){
    add_varargs_method("fib", &fib_module::fib, "fibonacci sequence function");
    initialize( "this is the test module" );
  }
 
  virtual ~fib_module(){}
 
private:
    Py::Object fib (const Py::Tuple &args){
        args.verify_length(1);
        Py::Long res = args[0];
        if (res<=Py::Long(1))  return Py::Long(1);
        else{
            Py::Tuple a(1), b(1); a[0]=Py::Long(res-2); b[0]=Py::Long(res-1);
            return fib(a)+fib(b);
        }
    }
};
 
#if defined( _WIN32 )
#define EXPORT_SYMBOL __declspec( dllexport )
#else
#define EXPORT_SYMBOL
#endif
 
extern "C" EXPORT_SYMBOL void initfib(){
#if defined(PY_WIN32_DELAYLOAD_PYTHON_DLL)
    Py::InitialisePythonIndirectPy::Interface();
#endif
    static fib_module* fib = new fib_module;
}
 
extern "C" EXPORT_SYMBOL void initfib_d(){ initfib(); }
[/pycxx code]

Re: Memory leak after 5.4.1->6.2.3 upgrade.

[Mateusz K. <mat...@an...>]

On Saturday 30 of July 2011, Barry Scott wrote:
> On 25 Jul 2011, at 23:54, Barry Scott wrote:
> > On 30 Jun 2011, at 11:32, Mateusz Korniak wrote:
> >> On Thursday 30 of June 2011, Mateusz Korniak wrote:
> >>> We recently tried to upgrade from ancient PyCXX version we used (5.4.1)
> >>> to newest 6.2.3 but we faced big memory leak after that change and
> >>> forced to switch back to 5.4.1.
> > 
> > The following patch I was sent may fix the problem you are seeing.
> > I think the patch is good. But I did see it cause pysvn to crash
> > that I have not had time to investigate yet.
> > Could you try this and let me know if it works for you?

Yes, after few days of testing it works great. Thanks !

> I have checked in the fix for the memory leak as r267
> on trunk. This will make it in to 6.2.4.

Great !

-- 
Mateusz Korniak

Re: Memory leak after 5.4.1->6.2.3 upgrade.

[Barry S. <ba...@ba...>]

I have checked in the fix for the memory leak as r267
on trunk. This will make it in to 6.2.4.


Barry


On 25 Jul 2011, at 23:54, Barry Scott wrote:

> 
> On 30 Jun 2011, at 11:32, Mateusz Korniak wrote:
> 
>> On Thursday 30 of June 2011, Mateusz Korniak wrote:
>>> Hi !
>>> We recently tried to upgrade from ancient PyCXX version we used (5.4.1) to
>>> newest 6.2.3 but we faced big memory leak after that change and forced to
>>> switch back to 5.4.1.
>> 
>> One more note:
>> We checked python object counts, and they stay constans while memory usage 
>> raises rapidly leading to OOM kills under Linux.
> 
> The following patch I was sent may fix the problem you are seeing.
> I think the patch is good. But I did see it cause pysvn to crash
> that I have not had time to investigate yet.
> 
> Could you try this and let me know if it works for you?
> 
> Barry
> 
> Index: /Users/barry/wc/svn/PyCXX-Clean/CXX/Python2/ExtensionOldType.hxx
> ===================================================================
> --- /Users/barry/wc/svn/PyCXX-Clean/CXX/Python2/ExtensionOldType.hxx	(revision 266)
> +++ /Users/barry/wc/svn/PyCXX-Clean/CXX/Python2/ExtensionOldType.hxx	(working copy)
> @@ -178,7 +178,7 @@
>             Tuple self( 2 );
> 
>             self[0] = Object( this );
> -            self[1] = Object( PyCObject_FromVoidPtr( method_def, do_not_dealloc ) );
> +            self[1] = Object( PyCObject_FromVoidPtr( method_def, do_not_dealloc ), true );
> 
>             PyObject *func = PyCFunction_New( &method_def->ext_meth_def, self.ptr() );
> 
> Index: /Users/barry/wc/svn/PyCXX-Clean/CXX/Python2/ExtensionModule.hxx
> ===================================================================
> --- /Users/barry/wc/svn/PyCXX-Clean/CXX/Python2/ExtensionModule.hxx	(revision 266)
> +++ /Users/barry/wc/svn/PyCXX-Clean/CXX/Python2/ExtensionModule.hxx	(working copy)
> @@ -139,8 +139,8 @@
>                 static PyObject *self = PyCObject_FromVoidPtr( this, do_not_dealloc );
> 
>                 Tuple args( 2 );
> -                args[0] = Object( self );
> -                args[1] = Object( PyCObject_FromVoidPtr( method_def, do_not_dealloc ) );
> +                args[0] = Object( self, true );
> +                args[1] = Object( PyCObject_FromVoidPtr( method_def, do_not_dealloc ), true );
> 
>                 PyObject *func = PyCFunction_New
>                                     (
> Index: /Users/barry/wc/svn/PyCXX-Clean/CXX/Python3/ExtensionOldType.hxx
> ===================================================================
> --- /Users/barry/wc/svn/PyCXX-Clean/CXX/Python3/ExtensionOldType.hxx	(revision 266)
> +++ /Users/barry/wc/svn/PyCXX-Clean/CXX/Python3/ExtensionOldType.hxx	(working copy)
> @@ -178,7 +178,7 @@
>             Tuple self( 2 );
> 
>             self[0] = Object( this );
> -            self[1] = Object( PyCapsule_New( method_def, NULL, NULL ) );
> +            self[1] = Object( PyCapsule_New( method_def, NULL, NULL ), true );
> 
>             PyObject *func = PyCFunction_New( &method_def->ext_meth_def, self.ptr() );
> 
> Index: /Users/barry/wc/svn/PyCXX-Clean/CXX/Python3/ExtensionModule.hxx
> ===================================================================
> --- /Users/barry/wc/svn/PyCXX-Clean/CXX/Python3/ExtensionModule.hxx	(revision 266)
> +++ /Users/barry/wc/svn/PyCXX-Clean/CXX/Python3/ExtensionModule.hxx	(working copy)
> @@ -135,8 +135,8 @@
>                 static PyObject *self = PyCapsule_New( this, NULL, NULL );
> 
>                 Tuple args( 2 );
> -                args[0] = Object( self );
> -                args[1] = Object( PyCapsule_New( method_def, NULL, NULL ) );
> +                args[0] = Object( self, true );
> +                args[1] = Object( PyCapsule_New( method_def, NULL, NULL ), true );
> 
>                 PyObject *func = PyCFunction_New
>                                     (
> 
> 
> ------------------------------------------------------------------------------
> Storage Efficiency Calculator
> This modeling tool is based on patent-pending intellectual property that
> has been used successfully in hundreds of IBM storage optimization engage-
> ments, worldwide.  Store less, Store more with what you own, Move data to 
> the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/
> _______________________________________________
> CXX-Users mailing list
> CXX...@li...
> https://lists.sourceforge.net/lists/listinfo/cxx-users
> 

Re: Memory leak after 5.4.1->6.2.3 upgrade.

[Barry S. <ba...@ba...>]

On 30 Jun 2011, at 11:32, Mateusz Korniak wrote:

> On Thursday 30 of June 2011, Mateusz Korniak wrote:
>> Hi !
>> We recently tried to upgrade from ancient PyCXX version we used (5.4.1) to
>> newest 6.2.3 but we faced big memory leak after that change and forced to
>> switch back to 5.4.1.
> 
> One more note:
> We checked python object counts, and they stay constans while memory usage 
> raises rapidly leading to OOM kills under Linux.

The following patch I was sent may fix the problem you are seeing.
I think the patch is good. But I did see it cause pysvn to crash
that I have not had time to investigate yet.

Could you try this and let me know if it works for you?

Barry

Index: /Users/barry/wc/svn/PyCXX-Clean/CXX/Python2/ExtensionOldType.hxx
===================================================================
--- /Users/barry/wc/svn/PyCXX-Clean/CXX/Python2/ExtensionOldType.hxx	(revision 266)
+++ /Users/barry/wc/svn/PyCXX-Clean/CXX/Python2/ExtensionOldType.hxx	(working copy)
@@ -178,7 +178,7 @@
             Tuple self( 2 );
 
             self[0] = Object( this );
-            self[1] = Object( PyCObject_FromVoidPtr( method_def, do_not_dealloc ) );
+            self[1] = Object( PyCObject_FromVoidPtr( method_def, do_not_dealloc ), true );
 
             PyObject *func = PyCFunction_New( &method_def->ext_meth_def, self.ptr() );
 
Index: /Users/barry/wc/svn/PyCXX-Clean/CXX/Python2/ExtensionModule.hxx
===================================================================
--- /Users/barry/wc/svn/PyCXX-Clean/CXX/Python2/ExtensionModule.hxx	(revision 266)
+++ /Users/barry/wc/svn/PyCXX-Clean/CXX/Python2/ExtensionModule.hxx	(working copy)
@@ -139,8 +139,8 @@
                 static PyObject *self = PyCObject_FromVoidPtr( this, do_not_dealloc );
 
                 Tuple args( 2 );
-                args[0] = Object( self );
-                args[1] = Object( PyCObject_FromVoidPtr( method_def, do_not_dealloc ) );
+                args[0] = Object( self, true );
+                args[1] = Object( PyCObject_FromVoidPtr( method_def, do_not_dealloc ), true );
 
                 PyObject *func = PyCFunction_New
                                     (
Index: /Users/barry/wc/svn/PyCXX-Clean/CXX/Python3/ExtensionOldType.hxx
===================================================================
--- /Users/barry/wc/svn/PyCXX-Clean/CXX/Python3/ExtensionOldType.hxx	(revision 266)
+++ /Users/barry/wc/svn/PyCXX-Clean/CXX/Python3/ExtensionOldType.hxx	(working copy)
@@ -178,7 +178,7 @@
             Tuple self( 2 );
 
             self[0] = Object( this );
-            self[1] = Object( PyCapsule_New( method_def, NULL, NULL ) );
+            self[1] = Object( PyCapsule_New( method_def, NULL, NULL ), true );
 
             PyObject *func = PyCFunction_New( &method_def->ext_meth_def, self.ptr() );
 
Index: /Users/barry/wc/svn/PyCXX-Clean/CXX/Python3/ExtensionModule.hxx
===================================================================
--- /Users/barry/wc/svn/PyCXX-Clean/CXX/Python3/ExtensionModule.hxx	(revision 266)
+++ /Users/barry/wc/svn/PyCXX-Clean/CXX/Python3/ExtensionModule.hxx	(working copy)
@@ -135,8 +135,8 @@
                 static PyObject *self = PyCapsule_New( this, NULL, NULL );
 
                 Tuple args( 2 );
-                args[0] = Object( self );
-                args[1] = Object( PyCapsule_New( method_def, NULL, NULL ) );
+                args[0] = Object( self, true );
+                args[1] = Object( PyCapsule_New( method_def, NULL, NULL ), true );
 
                 PyObject *func = PyCFunction_New
                                     (

Re: Memory leak after 5.4.1->6.2.3 upgrade.

[Mateusz K. <mat...@an...>]

On Thursday 30 of June 2011, Mateusz Korniak wrote:
> Hi !
> We recently tried to upgrade from ancient PyCXX version we used (5.4.1) to
> newest 6.2.3 but we faced big memory leak after that change and forced to
> switch back to 5.4.1.

One more note:
We checked python object counts, and they stay constans while memory usage 
raises rapidly leading to OOM kills under Linux.


-- 
Mateusz Korniak

Memory leak after 5.4.1->6.2.3 upgrade.

[Mateusz K. <mat...@an...>]

Hi !
We recently tried to upgrade from ancient PyCXX version we used (5.4.1) to 
newest 6.2.3 but we faced big memory leak after that change and forced to 
switch back to 5.4.1.
We have complex multithread C++/STL application running for hours, exposing 
it's calculation results via interface in Python.
What would be best way to find where is source of memory leak is?

Thanks in advance, regards,
-- 
Mateusz Korniak

Re: MemLeak in decode/encode function

[Barry S. <ba...@ba...>]

Fixed in r260

Barry

Re: MemLeak in decode/encode function

[Barry S. <ba...@ba...>]

On 28 Dec 2010, at 14:59, Barry Scott wrote:

> 
> On 15 Dec 2010, at 15:18, Нестеров Евгений wrote:
> 
>> Hello!
>> 
>> It seems that I have found a potential MemLeak. I post bug in tracker:
>> https://sourceforge.net/tracker/?func=detail&aid=3137322&group_id=3180&atid=103180
>> and today found why.
>> 
>> String decode( const char *encoding, const char *error="strict" )
>>        {
>>            return Object( PyString_AsDecodedObject( ptr(), encoding, 
>> error ) );
>>        }
>> Py::Object must be owner of new reference, second attr of counstructor 
>> must be true:
>> 
>> String decode( const char *encoding, const char *error="strict" )
>>        {
>>            return Object( PyString_AsDecodedObject( ptr(), encoding, 
>> error ), true );
>>        }
>> 
>> What you think about this?
>> 
>> -- 
>> Нестеров Евгений
> 
> I have reproduced the leak but there are oddities. In that not all calls to encode and decode
> cause a leak between python 2.x and 3.1.
> 
> I need to review and test deeper to see what is wrong here.

With the fix in place I do not see any issues.
But I failed to have a detectable memory leak with the decode calls,
however the docs are clear so I'm coding against the docs.

Barry

Re: MemLeak in decode/encode function

[Barry S. <ba...@ba...>]

On 15 Dec 2010, at 15:18, Нестеров Евгений wrote:

> Hello!
> 
> It seems that I have found a potential MemLeak. I post bug in tracker:
>  https://sourceforge.net/tracker/?func=detail&aid=3137322&group_id=3180&atid=103180
> and today found why.
> 
> String decode( const char *encoding, const char *error="strict" )
>         {
>             return Object( PyString_AsDecodedObject( ptr(), encoding, 
> error ) );
>         }
> Py::Object must be owner of new reference, second attr of counstructor 
> must be true:
> 
> String decode( const char *encoding, const char *error="strict" )
>         {
>             return Object( PyString_AsDecodedObject( ptr(), encoding, 
> error ), true );
>         }
> 
> What you think about this?
> 
> -- 
> Нестеров Евгений

I have reproduced the leak but there are oddities. In that not all calls to encode and decode
cause a leak between python 2.x and 3.1.

I need to review and test deeper to see what is wrong here.

Barry

MemLeak in decode/encode function

[Нестеров Е. <zb...@ro...>]

Hello!

It seems that I have found a potential MemLeak. I post bug in tracker:
  https://sourceforge.net/tracker/?func=detail&aid=3137322&group_id=3180&atid=103180
and today found why.

String decode( const char *encoding, const char *error="strict" )
         {
             return Object( PyString_AsDecodedObject( ptr(), encoding, 
error ) );
         }
Py::Object must be owner of new reference, second attr of counstructor 
must be true:

String decode( const char *encoding, const char *error="strict" )
         {
             return Object( PyString_AsDecodedObject( ptr(), encoding, 
error ), true );
         }

What you think about this?

-- 
Нестеров Евгений

Re: PyCXX and new style classes

[Barry S. <ba...@ba...>]

On 31 Oct 2010, at 23:59, Murali Donthireddy wrote:

> Thank  you, Barry! I will modify my code as you suggest.
> 
> >> Python may try to delete this instance and that may fail.
> fwiw,
> I did some testing by having my python code assign the result of this method to a variable and then set the variable to None.
> At first it wasn't calling the destructor of my new style class. I printed out reference counts of various objects in python and I noticed that these objects created in C++ code had reference counts one higher than other objects. That is when I added the "owned" argument to self() so that I could get an object with the right reference count. After that, my destructors were being called and I had no problems. I take that to mean Python is deleting the instance successfully. Of course there could be other things wrong that I haven't tested, and it is possible I have been lucky not to run into problems.

I was seeing some strange crashes getting the new style class support working.

The way new style classes work in python is that there is a python self object that
is extended by PyCXX. In the extension I put a pointer to the C++ class instance.
Because you need this special self from python just wrapping a C++ pointer will
not work.

Barry

Re: PyCXX and new style classes

[Murali D. <don...@ya...>]

Thank  you, Barry! I will modify my code as you suggest.

>> Python may try to delete this instance and that may fail.
fwiw,
I did some testing by having my python code assign the result of this method to 
a variable and then set the variable to None.
At first it wasn't calling the destructor of my new style class. I printed out 
reference counts of various objects in python and I noticed that these objects 
created in C++ code had reference counts one higher than other objects. That is 
when I added the "owned" argument to self() so that I could get an object with 
the right reference count. After that, my destructors were being called and I 
had no problems. I take that to mean Python is deleting the instance 
successfully. Of course there could be other things wrong that I haven't tested, 
and it is possible I have been lucky not to run into problems.

Murali



________________________________
From: Barry Scott <ba...@ba...>
To: Murali Donthireddy <don...@ya...>
Cc: PyCXX and improvement <cxx...@li...>
Sent: Sun, October 31, 2010 6:23:32 AM
Subject: Re: PyCXX and new style classes



On 29 Oct 2010, at 00:24, Murali Donthireddy wrote:

Barry,
>
>Thanks for the reply.
>
>BTW, I am using Python2 parts of version 2.6.1 of PyCXX.
>
>I used simple.cxx as my starting point. But all of the methods in 
>"new_style_class" return Py::None. How do I create and return an instance of 
>new_style_class to the python code?  (In my application, I have more than one 
>class, and a method of one class needs to return an instance of another class.)
>
>With some help from someone who knows c++ better than me, I managed to do what I 
>needed and it seems to work. But it felt like a herculean effort.
>

It would do. You cannot do this from C++ on its own.
You have to create instances of your new style class using python calls.
Python does a lot of house keeping for new style classes that using raw C++
will bypass and lead to who knows what problems.

In pure python you would do this:

class new_style_class:
def __init__( self ):
...

instance = new_style_class()

"new_style_class" is in fact a type. You can call the type to create instances 
of that type.

In PyCXX the type is available as new_style_class::type().
In simple.cxx you can see that being exposed as the "new_style_class" in the 
module dictionary.

To create an instance in C++ you need code like this:

        Py::Callable class_type( new_style_class::type() );

        Py::PythonClassObject<new_style_class> new_style_obj( class_type.apply( 
args, kwds ) );

I have updated the simple.cxx to include a new function (make_instance) that 
shows this.

https://cxx.svn.sourceforge.net/svnroot/cxx/trunk/CXX/Demo/Python2/simple.cxx



>I added a second constructor to PythonClass and modified its self() to take an 
>optional "owned" flag. I give all the code further down. 
>

I think this will lead to problems.


>Let us call my subclasses of PythonClass A and B, they each wrap a pre-existing 
>C++ class and hold a shared pointer to instances of those wrapped classes. Let 
>us call the pointers a and b.
>
>I am now able to return  a  PythonClassInstance of B from a method A as 
follows:
>    const WrappedClass* x =  < something that returns an instance of 
>WrappedClass>;
>    return (new B(x))->self(true);
>

Python may try to delete this instance and that may fail.


>I must be being monumentally stupid because there is a vast gap between what I 
>had to do and your comment "simple.cxx is all you need". I don't see how that 
>can be the case when simple.cxx doesn't have a single method that returns 
>anything, let alone instances of user defined classes.
>
>Regardless of whether I did more than what was necessary, my extension works 
>beautifully. I think PyCXX is a very nice tool. The fact that I could make 
>changes to it is an indication of how well written it is. I am grateful for your 
>work on PyCXX.
>


>thanks,
>Murali
>
>My changes to PythonClass, in header file CXX/Python2/ExtensionType.hxx:
>
>    template<TEMPLATE_TYPENAME T> class PythonClass
>    : public PythonExtensionBase
>    {
>    protected:
>[...]
>        static PythonClassInstance* alloc_empty() {
>            PyObject *py_optlib_expr = extension_object_new(type_object(), 
>Tuple().ptr(), Dict().ptr());
>            return reinterpret_cast<PythonClassInstance*>(py_optlib_expr);
>        }
>
>        PythonClass()
>            : PythonExtensionBase()
>            , m_class_instance( alloc_empty() )
>        {
>            reinterpret_cast< Py::PythonClassInstance * 
>>(selfPtr())->m_pycxx_object = 
>                static_cast<PythonExtensionBase*>(this);
>        }
>public:
>        static const T* obj_from_arg(Object arg) {
>            PythonClassInstance * b = reinterpret_cast<PythonClassInstance *> 
>(arg.ptr());
>            const T *val = static_cast<T *>(b->m_pycxx_object);
>

Any time you see reinterpret_cast in C++ is often a good sign that the code has 
a problem.
(Deep library code will need to do this).

Here is a type safe way to do what you want (take from func() in simple.cxx):

                Py::PythonClassObject<new_style_class> x2( x );
                std::cout << "C++ pointer " << x2.getCxxObject() << std::endl;


            return val;
>        }
>        
>        virtual Object self(bool owned = false) // customization: Add optional 
>argument owned.
>        {
>            return Object( reinterpret_cast<PyObject *>( m_class_instance 
>), owned );
>        }
>

Because python did not create the class for you you do not have a "self" that is 
sane.

Given the changes you'll make to get python to create your objects this is not 
needed.

Barry


      

Re: PyCXX and new style classes

[Barry S. <ba...@ba...>]

On 29 Oct 2010, at 00:24, Murali Donthireddy wrote:

> Barry,
> 
> Thanks for the reply.
> 
> BTW, I am using Python2 parts of version 2.6.1 of PyCXX.
> 
> I used simple.cxx as my starting point. But all of the methods in "new_style_class" return Py::None. How do I create and return an instance of new_style_class to the python code?  (In my application, I have more than one class, and a method of one class needs to return an instance of another class.)
> 
> With some help from someone who knows c++ better than me, I managed to do what I needed and it seems to work. But it felt like a herculean effort.

It would do. You cannot do this from C++ on its own.
You have to create instances of your new style class using python calls.
Python does a lot of house keeping for new style classes that using raw C++
will bypass and lead to who knows what problems.

In pure python you would do this:

class new_style_class:
	def __init__( self ):
		...

instance = new_style_class()

"new_style_class" is in fact a type. You can call the type to create instances of that type.

In PyCXX the type is available as new_style_class::type().
In simple.cxx you can see that being exposed as the "new_style_class" in the module dictionary.

To create an instance in C++ you need code like this:

        Py::Callable class_type( new_style_class::type() );

        Py::PythonClassObject<new_style_class> new_style_obj( class_type.apply( args, kwds ) );

I have updated the simple.cxx to include a new function (make_instance) that shows this.

https://cxx.svn.sourceforge.net/svnroot/cxx/trunk/CXX/Demo/Python2/simple.cxx


> 
> I added a second constructor to PythonClass and modified its self() to take an optional "owned" flag. I give all the code further down. 

I think this will lead to problems.

> 
> Let us call my subclasses of PythonClass A and B, they each wrap a pre-existing C++ class and hold a shared pointer to instances of those wrapped classes. Let us call the pointers a and b.
> 
> I am now able to return  a  PythonClassInstance of B from a method A as follows:
>     const WrappedClass* x =  < something that returns an instance of WrappedClass>;
>     return (new B(x))->self(true);

Python may try to delete this instance and that may fail.

> 
> I must be being monumentally stupid because there is a vast gap between what I had to do and your comment "simple.cxx is all you need". I don't see how that can be the case when simple.cxx doesn't have a single method that returns anything, let alone instances of user defined classes.
> 
> Regardless of whether I did more than what was necessary, my extension works beautifully. I think PyCXX is a very nice tool. The fact that I could make changes to it is an indication of how well written it is. I am grateful for your work on PyCXX.

> 
> thanks,
> Murali
> 
> My changes to PythonClass, in header file CXX/Python2/ExtensionType.hxx:
> 
>     template<TEMPLATE_TYPENAME T> class PythonClass
>     : public PythonExtensionBase
>     {
>     protected:
> [...]
>         static PythonClassInstance* alloc_empty() {
>             PyObject *py_optlib_expr = extension_object_new(type_object(), Tuple().ptr(), Dict().ptr());
>             return reinterpret_cast<PythonClassInstance*>(py_optlib_expr);
>         }
> 
>         PythonClass()
>             : PythonExtensionBase()
>             , m_class_instance( alloc_empty() )
>         {
>             reinterpret_cast< Py::PythonClassInstance * >(selfPtr())->m_pycxx_object = 
>                 static_cast<PythonExtensionBase*>(this);
>         }
> public:
>         static const T* obj_from_arg(Object arg) {
>             PythonClassInstance * b = reinterpret_cast<PythonClassInstance *> (arg.ptr());
>             const T *val = static_cast<T *>(b->m_pycxx_object);

Any time you see reinterpret_cast in C++ is often a good sign that the code has a problem.
(Deep library code will need to do this).

Here is a type safe way to do what you want (take from func() in simple.cxx):

                Py::PythonClassObject<new_style_class> x2( x );
                std::cout << "C++ pointer " << x2.getCxxObject() << std::endl;


>             return val;
>         }
>         
>         virtual Object self(bool owned = false) // customization: Add optional argument owned.
>         {
>             return Object( reinterpret_cast<PyObject *>( m_class_instance ), owned );
>         }

Because python did not create the class for you you do not have a "self" that is sane.

Given the changes you'll make to get python to create your objects this is not needed.

Barry

Re: PyCXX and new style classes

[Murali D. <don...@ya...>]

I also added a constructor in my class B:
B( const WrappedClass* x )  :  m_wrapped_obj(*x) {}


Murali



________________________________
From: Murali Donthireddy <don...@ya...>
To: Barry Scott <ba...@ba...>
Cc: PyCXX and improvement <cxx...@li...>
Sent: Thu, October 28, 2010 7:24:18 PM
Subject: Re: PyCXX and new style classes


Barry,

Thanks for the reply.

BTW, I am using Python2 parts of version 2.6.1 of PyCXX.

I used simple.cxx as my starting point. But all of the methods in 
"new_style_class" return Py::None. How do I create and return an instance of 
new_style_class to the python code?  (In my application, I have more than one 
class, and a method of one class needs to return an instance of another class.)

With some help from someone who knows c++ better than me, I managed to do what I 
needed and it seems to work. But it felt like a herculean effort.

I added a second constructor to PythonClass and modified its self() to take an 
optional "owned" flag. I give all the code further down. 


Let us call my subclasses of PythonClass A and B, they each wrap a pre-existing 
C++ class and hold a shared pointer to instances of those wrapped classes. Let 
us call the pointers a and b.

I am now able to return  a  PythonClassInstance of B from a method A as follows:
    const WrappedClass* x =  < something  that returns an instance of 
WrappedClass>;
    return (new B(x))->self(true);

I must be being monumentally stupid because there is a vast gap between what I 
had to do and your comment "simple.cxx is all you need". I don't see how that 
can be the case when simple.cxx doesn't have a single method that returns 
anything, let alone instances of user defined classes.

Regardless of whether I did more than what was necessary, my extension works 
beautifully. I think PyCXX is a very nice tool. The fact that I could make 
changes to it is an indication of how well written it is. I am grateful for your 
work on PyCXX.

thanks,
Murali

My changes to PythonClass, in header file CXX/Python2/ExtensionType.hxx:

    template<TEMPLATE_TYPENAME T> class PythonClass
    : public PythonExtensionBase
    {
    protected:
[...]
        static PythonClassInstance* alloc_empty() {
            PyObject *py_optlib_expr = extension_object_new(type_object(), 
Tuple().ptr(), Dict().ptr());
            return reinterpret_cast<PythonClassInstance*>(py_optlib_expr);
        }

        PythonClass()
            :  PythonExtensionBase()
            , m_class_instance( alloc_empty() )
        {
            reinterpret_cast< Py::PythonClassInstance * 
>(selfPtr())->m_pycxx_object = 

                static_cast<PythonExtensionBase*>(this);
        }
public:
        static const T* obj_from_arg(Object arg) {
            PythonClassInstance * b = reinterpret_cast<PythonClassInstance *> 
(arg.ptr());
            const T *val = static_cast<T  *>(b->m_pycxx_object);
            return val;
        }
        
        virtual Object self(bool owned = false) // customization: Add optional 
argument owned.
        {
            return Object( reinterpret_cast<PyObject *>( m_class_instance ), 
owned );
        }
[...]


Murali




________________________________
From: Barry Scott <ba...@ba...>
To: Murali Donthireddy <don...@ya...>
Cc: PyCXX and improvement <cxx...@li...>
Sent: Thu, October 28, 2010 4:59:03 PM
Subject: Re: PyCXX and new style classes



On 20 Oct 2010, at 19:14, Murali Donthireddy wrote:

Hi Barry,
>
>I apologize for directly emailing you with a question. Completely understandable 
>if you don't reply.
>


We have a user list that I'm CC'ing.


>I am unable to figure out how to create, in C++ code, an instance of a new style 
>class. The constructor requires a mysterious Py::PythonClassInstance* that I 
>don't know how to generate.
>

You do not call the c'tor directly to create a instance.
You have to create instances using python methods.


>The example simple.cxx seems to be the only source of info on about new style 
>classes anywhere on the Internet, short of reading the implementation of PyCXX, 
>but my C++ isn't good enough for that. 
>

Have you tried compiling and running simple? It shows the new style class stuff 
all working.


>Any pointer or example code would be great.
>

simple.cxx is all you need. It shows you how to do most of the interesting 
stuff.

What exactly are you trying to do that simple.cxx does not do?

Barry


      

Re: PyCXX and new style classes

[Murali D. <don...@ya...>]

Barry,

Thanks for the reply.

BTW, I am using Python2 parts of version 2.6.1 of PyCXX.

I used simple.cxx as my starting point. But all of the methods in 
"new_style_class" return Py::None. How do I create and return an instance of 
new_style_class to the python code?  (In my application, I have more than one 
class, and a method of one class needs to return an instance of another class.)

With some help from someone who knows c++ better than me, I managed to do what I 
needed and it seems to work. But it felt like a herculean effort.

I added a second constructor to PythonClass and modified its self() to take an 
optional "owned" flag. I give all the code further down. 


Let us call my subclasses of PythonClass A and B, they each wrap a pre-existing 
C++ class and hold a shared pointer to instances of those wrapped classes. Let 
us call the pointers a and b.

I am now able to return  a  PythonClassInstance of B from a method A as follows:
    const WrappedClass* x =  < something that returns an instance of 
WrappedClass>;
    return (new B(x))->self(true);

I must be being monumentally stupid because there is a vast gap between what I 
had to do and your comment "simple.cxx is all you need". I don't see how that 
can be the case when simple.cxx doesn't have a single method that returns 
anything, let alone instances of user defined classes.

Regardless of whether I did more than what was necessary, my extension works 
beautifully. I think PyCXX is a very nice tool. The fact that I could make 
changes to it is an indication of how well written it is. I am grateful for your 
work on PyCXX.

thanks,
Murali

My changes to PythonClass, in header file CXX/Python2/ExtensionType.hxx:

    template<TEMPLATE_TYPENAME T> class PythonClass
    : public PythonExtensionBase
    {
    protected:
[...]
        static PythonClassInstance* alloc_empty() {
            PyObject *py_optlib_expr = extension_object_new(type_object(), 
Tuple().ptr(), Dict().ptr());
            return reinterpret_cast<PythonClassInstance*>(py_optlib_expr);
        }

        PythonClass()
            : PythonExtensionBase()
            , m_class_instance( alloc_empty() )
        {
            reinterpret_cast< Py::PythonClassInstance * 
>(selfPtr())->m_pycxx_object = 

                static_cast<PythonExtensionBase*>(this);
        }
public:
        static const T* obj_from_arg(Object arg) {
            PythonClassInstance * b = reinterpret_cast<PythonClassInstance *> 
(arg.ptr());
            const T *val = static_cast<T *>(b->m_pycxx_object);
            return val;
        }
        
        virtual Object self(bool owned = false) // customization: Add optional 
argument owned.
        {
            return Object( reinterpret_cast<PyObject *>( m_class_instance ), 
owned );
        }
[...]


Murali




________________________________
From: Barry Scott <ba...@ba...>
To: Murali Donthireddy <don...@ya...>
Cc: PyCXX and improvement <cxx...@li...>
Sent: Thu, October 28, 2010 4:59:03 PM
Subject: Re: PyCXX and new style classes



On 20 Oct 2010, at 19:14, Murali Donthireddy wrote:

Hi Barry,
>
>I apologize for directly emailing you with a question. Completely understandable 
>if you don't reply.
>


We have a user list that I'm CC'ing.


>I am unable to figure out how to create, in C++ code, an instance of a new style 
>class. The constructor requires a mysterious Py::PythonClassInstance* that I 
>don't know how to generate.
>

You do not call the c'tor directly to create a instance.
You have to create instances using python methods.


>The example simple.cxx seems to be the only source of info on about new style 
>classes anywhere on the Internet, short of reading the implementation of PyCXX, 
>but my C++ isn't good enough for that. 
>

Have you tried compiling and running simple? It shows the new style class stuff 
all working.


>Any pointer or example code would be great.
>

simple.cxx is all you need. It shows you how to do most of the interesting 
stuff.

What exactly are you trying to do that simple.cxx does not do?

Barry


      

Re: PyCXX and new style classes

[Barry S. <ba...@ba...>]

On 20 Oct 2010, at 19:14, Murali Donthireddy wrote:

> Hi Barry,
> 
> I apologize for directly emailing you with a question. Completely understandable if you don't reply.


We have a user list that I'm CC'ing.

> 
> I am unable to figure out how to create, in C++ code, an instance of a new style class. The constructor requires a mysterious Py::PythonClassInstance* that I don't know how to generate.

You do not call the c'tor directly to create a instance.
You have to create instances using python methods.

> 
> The example simple.cxx seems to be the only source of info on about new style classes anywhere on the Internet, short of reading the implementation of PyCXX, but my C++ isn't good enough for that. 

Have you tried compiling and running simple? It shows the new style class stuff all working.

> 
> Any pointer or example code would be great.

simple.cxx is all you need. It shows you how to do most of the interesting stuff.

What exactly are you trying to do that simple.cxx does not do?

Barry

RE: Compiling PyCXX 6.1.1 for 64-bit

[Paul K. <Pau...@ni...>]

>> You don't need to install pycxx to build pysvn. Pysvn compiles it from the Imports folder.

Yes, but I didn't know that. It isn't obvious that PyCxx does what it does just via #includes. I suppose that someone planning to become a PyCxx user would work that out pretty quickly, but all I wanted was to get PySvn to compile. I didn't know how PyCxx worked. Any good intentions I had about trying to learn how it worked evaporated when the demo wouldn't compile, with an error message that was way beyond my abilities to resolve.

The PySvn documentation said I need PyCxx 5 for Python 2, which wasn't in the package, so I downloaded that first. When that didn't compile under 64-bit I turned my attention to the PyCxx 6 that was in the Imports folder and tried to compile that. I even downloaded PyCxx 6 afresh in case the issue with the demo had been fixed in a later version. It took a while, but I began to suspect that the problem was with only the demo, which I didn't need unless I wanted to understand how PyCxx works, so I gave up on that and tried to compile PySvn.

When that failed with a bunch of "cannot open include file" messages I decided I needed to install PyCxx before trying to compile PySvn.

But then PyCxx wouldn't install because the PyCxx files weren't in the folders that its own #includes expected them to be in. It was only after a couple of days that I realized that it was nothing to do with 64-bit, or the different compiler, or something in the prerequisites that I had missed, or a macro I hadn't adjusted, but that PyCxx wouldn't install because

-- The install wasn't copying the Python2 and Python3 subfolders to where the #includes expected them to be. It copies files in pycxx-6.1.1\CXX to %python%\include\CXX but it doesn't copy the subfolders . It copies files in pycxx-6.1.1\Src to %python%\share\python2.6\CXX but again it doesn't copy the subfolders.

-- The redirecting #includes pointing at the Python2 and Python3 subfolders in Src/IndirectPythonInterface.cxx, Src/cxxextensions.c and Src/cxxsupport.cxx implied a folder structure different from the one I had: either they should not be in the Src folder, but one level up; or else there should be a folder Src/Src/Python2.

It was only when I saw that Src/cxx_extensions.cxx had a different (and correct) path in the #include from the others that I realized I needed to fix the PyCxx code if I was going to get PySvn to compile. These are the fixes:

Index: IndirectPythonInterface.cxx
===================================================================
--- IndirectPythonInterface.cxx (revision 6682)
+++ IndirectPythonInterface.cxx              (revision 6683)
@@ -37,7 +37,7 @@
 #include "CXX/WrapPython.h"

 #if PY_MAJOR_VERSION == 2
-#include "Src/Python2/IndirectPythonInterface.cxx"
+#include "Python2/IndirectPythonInterface.cxx"
 #else
-#include "Src/Python3/IndirectPythonInterface.cxx"
+#include "Python3/IndirectPythonInterface.cxx"
 #endif

Index: cxxextensions.c
===================================================================
--- cxxextensions.c          (revision 6682)
+++ cxxextensions.c       (revision 6683)
@@ -37,7 +37,7 @@
 #include "CXX/WrapPython.h"

 #if PY_MAJOR_VERSION == 2
-#include "Src/Python2/cxxextensions.c"
+#include "Python2/cxxextensions.c"
 #else
-#include "Src/Python3/cxxextensions.c"
+#include "Python3/cxxextensions.c"
 #endif

Index: cxxsupport.cxx
===================================================================
--- cxxsupport.cxx           (revision 6682)
+++ cxxsupport.cxx        (revision 6683)
@@ -37,7 +37,7 @@
 #include "CXX/WrapPython.h"

 #if PY_MAJOR_VERSION == 2
-#include "Src/Python2/cxxsupport.cxx"
+#include "Python2/cxxsupport.cxx"
 #else
-#include "Src/Python3/cxxsupport.cxx"
+#include "Python3/cxxsupport.cxx"
 #endif

So, it's compiled now, but that doesn't help me much, because I need 64-bit Subversion .lib files to link-edit it to.

Regards




________________________________
The information contained in this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail. Please delete this e-mail and do not disclose its contents to any person. NIBC Holding N.V. nor its subsidiaries accept liability for any errors, omissions, delays of receipt or viruses in the contents of this message which arise as a result of e-mail transmission. NIBC Holding N.V. (Chamber of commerce nr. 27282935), NIBC Bank N.V. (Chamber of commerce nr. 27032036) and NIBC Investment Management N.V. (Chamber of commerce nr. 27253909) all have their corporate seat in The Hague, The Netherlands.

De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, gelieve onmiddellijk contact op te nemen met de afzender per kerende e-mail. Wij verzoeken u dit e-mailbericht te Vernietigen en de inhoud ervan aan niemand openbaar te maken. NIBC Holding N.V. noch haar dochterondernemingen aanvaarden enige aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van een verzonden e-mailbericht, noch voor door haar daarbij overgebrachte virussen. NIBC Holding N.V. (KvK nr. 27282935), NIBC Bank N.V. (KvK nr. 27032036) and NIBC Investment Management N.V. (KvK nr. 27253909) zijn statutair gevestigd te Den Haag, Nederland.

Re: Compiling PyCXX 6.1.1 for 64-bit

[Barry S. <ba...@ba...>]

On 27 Sep 2010, at 08:52, Paul Keating wrote:

> Python 2.6
>  
> I think it is only in the demo code, because I got what I needed to compile, eventually.
>  
> The version of PyCxx 6.1.1 that is delivered in the PySvn 1.7.2 project needed some changes though. The installer hasn't been brought into line with the unification of Python2 and Python 3 support in subfolders of include\CXX and %python%\share\python2.6\CXX. It doesn't know to copy the subfolders. The include files do know about the Python2/3 subfolders, but don't agree on the subfolder structure. PyCXX.RTF has a full description, and there is a patch for the include files in PySvn-patch.txt.


You don't need to install pycxx to build pysvn. Pysvn compiles it from the Imports folder.

Barry



>  
> I still can't link-edit PySvn though, because of dependencies on Subversion binaries. I really can't face compiling Subversion from scratch. Even the Subversion developers say that they think it's a bit much for an end-user to attempt.
>  
> Regards
>  
> From: Barry Scott [mailto:ba...@ba...] 
> Sent: 25 September 2010 10:58
> To: Discuss PyCXX use and improvement
> Subject: Re: Compiling PyCXX 6.1.1 for 64-bit
>  
>  
> On 1 Sep 2010, at 15:42, Paul Keating wrote:
> 
> 
> I need to deploy PySvn 1.7.2 on a 64-bit Windows platform, even though my own workstation isn't 64-bit. So I need 64-bit DLLs, which aren't packaged, so I need to compile them myself from source. But first…
>  
>  
> Which version of python are you using?
>  
>  
>  
> I'm compiling PyCXX 6.1.1 because it is a dependency of PySvn 1.7.2. But first…
>  
> I'm running into this error:
>  
> 2>d:\visual studio 2008 projects\pysvn-1.7.2\import\pycxx-6.1.1\demo\python2\range.hxx(115) : error C2440: '<function-style-cast>' : cannot convert from 'Py_ssize_t' to 'Py::Int'
> 2>        No constructor could take the source type, or constructor overload resolution was ambiguous
>  
> I'll have to test this and see what happens. It may only be a bug in the demo code.
> 
> 
>  
> My preprocessor directives include  
>  
> /D "_WIN64" /D "_M_X64"
>  
>  
> Do you have a 64 bit C++ compiler? 
>  
> I have "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64\cl.exe"
> But I'm not sure how this was installed. Its from with the Windows SDK or
> the Visual C++ Express.
>  
> These defines will not help on their own and my not be needed at all.
>  
>  
> (I'm fairly sure these are correct, because I copied them from the Python source project, which does compile) and this in turn causes ssize_t to be defined as __int64.  I don't know what else to change to get this to compile. I'm a Python programmer who last programmed in C on OS/2 version 1.2 so I'm afraid the solution isn't obvious. I tried overloading the Int() constructor to accept a Py_ssize_t argument, but that just moved (and multiplied) the problem.
>  
> CHanging to Py::Long is probable the way to go.
> 
> 
>  
> (And, before you ask, I can’t continue to use 32-bit Python on the 64-bit machines. I have no choice about the Python interpreter because it is embedded in a 64-bit application and so needs a 64-bit PySvn .pyd file.)
>  
>  
> Barry
>  
> 
> The information contained in this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail. Please delete this e-mail and do not disclose its contents to any person. NIBC Holding N.V. nor its subsidiaries accept liability for any errors, omissions, delays of receipt or viruses in the contents of this message which arise as a result of e-mail transmission. NIBC Holding N.V. (Chamber of commerce nr. 27282935), NIBC Bank N.V. (Chamber of commerce nr. 27032036) and NIBC Investment Management N.V. (Chamber of commerce nr. 27253909) all have their corporate seat in The Hague, The Netherlands.
> 
> De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, gelieve onmiddellijk contact op te nemen met de afzender per kerende e-mail. Wij verzoeken u dit e-mailbericht te Vernietigen en de inhoud ervan aan niemand openbaar te maken. NIBC Holding N.V. noch haar dochterondernemingen aanvaarden enige aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van een verzonden e-mailbericht, noch voor door haar daarbij overgebrachte virussen. NIBC Holding N.V. (KvK nr. 27282935), NIBC Bank N.V. (KvK nr. 27032036) and NIBC Investment Management N.V. (KvK nr. 27253909) zijn statutair gevestigd te Den Haag, Nederland.
> <PyCXX.RTF>------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev_______________________________________________
> CXX-Users mailing list
> CXX...@li...
> https://lists.sourceforge.net/lists/listinfo/cxx-users

Re: Compiling PyCXX 6.1.1 for 64-bit

[Barry S. <ba...@ba...>]

On 1 Sep 2010, at 15:42, Paul Keating wrote:

> I need to deploy PySvn 1.7.2 on a 64-bit Windows platform, even though my own workstation isn't 64-bit. So I need 64-bit DLLs, which aren't packaged, so I need to compile them myself from source. But first…


Which version of python are you using?


>  
> I'm compiling PyCXX 6.1.1 because it is a dependency of PySvn 1.7.2. But first…
>  
> I'm running into this error:
>  
> 2>d:\visual studio 2008 projects\pysvn-1.7.2\import\pycxx-6.1.1\demo\python2\range.hxx(115) : error C2440: '<function-style-cast>' : cannot convert from 'Py_ssize_t' to 'Py::Int'
> 2>        No constructor could take the source type, or constructor overload resolution was ambiguous

I'll have to test this and see what happens. It may only be a bug in the demo code.

>  
> My preprocessor directives include  
>  
> /D "_WIN64" /D "_M_X64"


Do you have a 64 bit C++ compiler? 

I have "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64\cl.exe"
But I'm not sure how this was installed. Its from with the Windows SDK or
the Visual C++ Express.

These defines will not help on their own and my not be needed at all.

>  
> (I'm fairly sure these are correct, because I copied them from the Python source project, which does compile) and this in turn causes ssize_t to be defined as __int64.  I don't know what else to change to get this to compile. I'm a Python programmer who last programmed in C on OS/2 version 1.2 so I'm afraid the solution isn't obvious. I tried overloading the Int() constructor to accept a Py_ssize_t argument, but that just moved (and multiplied) the problem.

CHanging to Py::Long is probable the way to go.

>  
> (And, before you ask, I can’t continue to use 32-bit Python on the 64-bit machines. I have no choice about the Python interpreter because it is embedded in a 64-bit application and so needs a 64-bit PySvn .pyd file.)


Barry

Compiling PyCXX 6.1.1 for 64-bit

[Paul K. <Pau...@ni...>]

I need to deploy PySvn 1.7.2 on a 64-bit Windows platform, even though my own workstation isn't 64-bit. So I need 64-bit DLLs, which aren't packaged, so I need to compile them myself from source. But first...

I'm compiling PyCXX 6.1.1 because it is a dependency of PySvn 1.7.2. But first...

I'm running into this error:

2>d:\visual studio 2008 projects\pysvn-1.7.2\import\pycxx-6.1.1\demo\python2\range.hxx(115) : error C2440: '<function-style-cast>' : cannot convert from 'Py_ssize_t' to 'Py::Int'
2>        No constructor could take the source type, or constructor overload resolution was ambiguous

My preprocessor directives include

/D "_WIN64" /D "_M_X64"

(I'm fairly sure these are correct, because I copied them from the Python source project, which does compile) and this in turn causes ssize_t to be defined as __int64.  I don't know what else to change to get this to compile. I'm a Python programmer who last programmed in C on OS/2 version 1.2 so I'm afraid the solution isn't obvious. I tried overloading the Int() constructor to accept a Py_ssize_t argument, but that just moved (and multiplied) the problem.

(And, before you ask, I can't continue to use 32-bit Python on the 64-bit machines. I have no choice about the Python interpreter because it is embedded in a 64-bit application and so needs a 64-bit PySvn .pyd file.)



________________________________
The information contained in this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail. Please delete this e-mail and do not disclose its contents to any person. NIBC Holding N.V. nor its subsidiaries accept liability for any errors, omissions, delays of receipt or viruses in the contents of this message which arise as a result of e-mail transmission. NIBC Holding N.V. (Chamber of commerce nr. 27282935), NIBC Bank N.V. (Chamber of commerce nr. 27032036) and NIBC Investment Management N.V. (Chamber of commerce nr. 27253909) all have their corporate seat in The Hague, The Netherlands.

De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, gelieve onmiddellijk contact op te nemen met de afzender per kerende e-mail. Wij verzoeken u dit e-mailbericht te Vernietigen en de inhoud ervan aan niemand openbaar te maken. NIBC Holding N.V. noch haar dochterondernemingen aanvaarden enige aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van een verzonden e-mailbericht, noch voor door haar daarbij overgebrachte virussen. NIBC Holding N.V. (KvK nr. 27282935), NIBC Bank N.V. (KvK nr. 27032036) and NIBC Investment Management N.V. (KvK nr. 27253909) zijn statutair gevestigd te Den Haag, Nederland.

Announce: PyCXX V6.2.1 Released

[Barry S. <ba...@ba...>]

Version 6.2.1 (15-Aug-2010)

* Add support for NotImplementedError
* Remove String() and Byte() c'tors that are not allowed by ISO C++ and where ambigous

Barry

Re: Derived class getattro

[Barry S. <ba...@ba...>]

On 13 Apr 2010, at 00:29, Fernando Libonati wrote:

> But derivarion works fine with old Style classes.

No it does not. You just have not encounter a problem yet.
But I expect you will.

I must admit it never occurred to me derive the way you are
trying to do. Python's needs do not allow this to work.

If you read the template code for PythonClass and PythonExtension
you will see that both create a lot of static methods and data structures.

You cannot just derive in C++ and expect the Python glue to work,
except by accident.


> 
> Today i was thinking in make the whole class hierarchy with old style
> ones and restrict new style to some particular aspects of the
> simulator (e.g. a system container that doesn't derive from Block)

As I said you need to organise your class's so that you turn the
leafs into Python objects.

Are you deriving for code reuse or relationships?

Barry

Re: Derived class getattro

[Fernando L. <fer...@gm...>]

But derivarion works fine with old Style classes.

Today i was thinking in make the whole class hierarchy with old style
ones and restrict new style to some particular aspects of the
simulator (e.g. a system container that doesn't derive from Block)

Best regards
Fernando

2010/4/12, Barry Scott <ba...@ba...>:
>
> On 10 Apr 2010, at 19:34, Fernando Libonati wrote:
>
>> In cxx_extensions.cxx
>>
>> extern "C" PyObject *getattro_handler( PyObject *self, PyObject *name )
>> {
>>     try
>>     {
>>         PythonExtensionBase *p = getPythonExtensionBase( self );
>>         return new_reference_to( p->getattro( Py::String( name ) ) );
>>     }
>>     catch( Py::Exception &)
>>     {
>>         return NULL;    // indicate error
>>     }
>> }
>>
>> In a derived class this always call the getattro of the base class, and
>> never get the derived class attributes visible.
>> How can I access a derived class attro?
>>
>> I've attached the test system, base.h and base.cxx.
>> When compiled, it is possible to create a g = base.Gain("b",1,None,2.43)
>> object, and access name,number and parent attributes, but doesn't reach
>> the gain attribute.
>> Python says
>> """Traceback (most recent call last):
>>   File "<stdin>", line 1, in <module>
>> AttributeError: 'Gain' object has no attribute 'gain'
>> """
>>
>> It would be possible to call first the derived class method, and inside it
>> call the base class method (under the user responsibility)?
>
> You cannot use C++ derivation to create a set of Python types.
>
> When Block is setup there are a lot of python data structures created and
> initialise to make Block available to Python.
>
> Gain has none of these python data structures.
>
> If you want  a hierarchy of classes then only the leafs can be turned into
> Python classes.
>
> Barry
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> CXX-Users mailing list
> CXX...@li...
> https://lists.sourceforge.net/lists/listinfo/cxx-users
>


-- 
Fernando Libonati
fernando.libonati at gmail.com