Mailman 3 September 2000 - Cplusplus-sig

Re: [c++-sig] Digest Number 36
by David Abrahams Sept. 24, 2000

Sept. 24, 2000

----- Original Message ----- > Message: 1 > Date: Sat, 23 Sep 2000 13:31:10 -0700 > From: Jonathan Greene <jgreene(a)adaptivesilicon.com> > Subject: Python classes with methods that are C extensions? > > I know one can extend Python with C functions in two ways: > 1. Modules with functions that are C functions. > 2. Extension types with methods that are C functions > > Is there also a way to have true Python classes (not types) whose > methods are C functions? I've heard rumors that there have been changes > to Python since 1.5.1 that make this possible but have seen nothing in > the documentation. > > Note: It is possible to write a class method in Python that calls a C > function (as SWIG does). But I would like to avoid this approach since > it involves a 2nd function call and thus worse performance. Well, I can get you pretty close. See http://people.ne.mediaone.net/abrahams/downloads/py_cpp.html. >From the documentation: "Another obstacle that most people run into eventually when extending Python is that there's no way to make a true Python class in an extension module...Py_cpp solves this problem by taking advantage of Python's metaclass feature to provide objects which look, walk, and hiss almost exactly like regular Python classes." If you need a "class" on which just one or two methods are C functions, let me know after you've read the documentation. That's a use I hadn't thought of for this technology but which is possible without writing new code. I just didn't put a recipe in the documentation. -Dave

1 0

Python classes with methods that are C extensions?
by Jonathan Greene Sept. 23, 2000

Sept. 23, 2000

I know one can extend Python with C functions in two ways: 1. Modules with functions that are C functions. 2. Extension types with methods that are C functions Is there also a way to have true Python classes (not types) whose methods are C functions? I've heard rumors that there have been changes to Python since 1.5.1 that make this possible but have seen nothing in the documentation. Note: It is possible to write a class method in Python that calls a C function (as SWIG does). But I would like to avoid this approach since it involves a 2nd function call and thus worse performance.

1 0

RE: [C++-SIG] CXX problems on SGI
by Barry Scott Sept. 14, 2000

Sept. 14, 2000

[6] CXX developers fix CXX to work with SGI, etc, compiler One of the aims of the changes that went into 5.0b was to get the code base using std c++ syntax. I use gcc 2.95.2 on FreeBSD and Microsoft Visual C++ 6.0 SP4 to test the CXX code out. Both compile and run CXX except for FreeBSD that the exception handling does not work in one case. I suspect the root cause of the problems you see is the work to use std c++ syntax. That is where the extern "C" stuff came from. What happends if you change all the extern "C" to extern "C++"? If this fixes the problem for you we can add condition code to support none std c++ compilers into the CXX code base. Barry -----Original Message----- From: Marc Poinot [mailto:Marc.Poinot@onera.fr] Sent: 12 September 2000 13:58 To: Geoffrey Furnish Cc: Marc Poinot; Python/C++ SIG Subject: Re: [C++-SIG] CXX problems on SGI *BEWARE* (this is a constructive email ;) Geoffrey Furnish wrote: > > Marc Poinot writes: > > > > What kind of compilers are you using ? > > Again: Are you using something else than the KAI C++ ? I cannot compile CXX 5.0b on any of our compilers here (SGI,DEC,NEC,CRAY,FUJITSU, and gcc). We have Python on all these platforms, and Python is used for our C++/Fortran application. I was using CXX 4.2 for some Pythons optional extensions, but now, what can I do ? [0] Stay with CXX 4.2 [1] Leave CXX and move to another kind of C++ extensions [2] Hack into CXX to make it run, do it again for each release [3] Wait the the next good release of compiler [4] Buy the KAI C++ for every platform [5] Change to Perl^H^H^H^H Bourne shell scripts Sure your C++ is an high level one, but what if you're the only one to be able to compile it ? Who's going to use CXX ? Maybe the right platform, even if the C++ is not ISO compliant, is to take a g++ subset of ISO C++ and allow some simpler code. > Looks to me like you have a bug in your compiler. Can you upgrade? > Which version of the SGI compiler are you using? Latest is > 7.3.something. > Even without the try/catch blocks into the externs, the compiler fails. According to our support, all of our compilers are up-to-date (SGI is 7.30). Ok, now I'm starting with [2], but I'm afraid this will lead to something like a parallel branch :( (even simulated by pre-processing). The first step I'm going to do is to add a makefile with options for every of our platforms, split headers into seperate files per each class, move inlines to a compiled bodies and extend some tests (see you next year ;) Marcvs [alias I have no access to the CVS server, but I can work on a CVS workspace tarball and send it back to you?] _______________________________________________ C++-SIG maillist - C++-SIG(a)python.org http://www.python.org/mailman/listinfo/c++-sig

3 2

Re: [C++-SIG] CXX problems on SGI
by Marc Poinot Sept. 13, 2000

Sept. 13, 2000

"Paul F. Dubois" wrote: > > gcc 2.95.2 doesn't compile? Yes, it compiles on SGI with g++ 2.95.2 and lastest gcc snapshot. Sorry for the mess. At this point, my tests are: SGI g++ 2.95.2 [OK] SUN g++ 2.95.2 [OK] DEC g++ 2.95.2 [FAILED] ? (we had many problems for this gcc install) No way to compile it on other compilers (we don't have KCC). Marcvs [alias But so far, g++ is enough to make my stuff run ;) ]

1 0

CXX problems on SGI
by Marc Poinot Sept. 12, 2000

Sept. 12, 2000

I have some compile-time concern with CXX 5.0b It looks like it is a compiler bug, I wonder if anybody else has this problem. What kind of compilers are you using ? Here's what I get into cxx_extensions.cxx : All lines with extern "C" and a try/catch block into are rejected (compiler makes a core). I had to remove the try/catch blocks. extern "C" int compare_handler( PyObject *self, PyObject *other ) { // try // { PythonExtensionBase *p = static_cast<PythonExtensionBase *>( self ); return p->compare( Py::Object( other ) ); // } // catch( Py::Exception & ) // { // return -1; // indicate error // } } The SGI known bug is: 577506 A goto outside a region cannot jump to a label inside a region. Is there a compiler (SGI ?) expert here ? Looks like the case is we have an exception (jump) from an extern function to a namespace/class scope region ? Maybe it's possible to reduce the extern part to the simplest one? -MP-

2 2

New CXX release (5.0)
by Marc Poinot Sept. 10, 2000

Sept. 10, 2000

CXX/Array.hxx line 3, header include should be now: #include "CXX/Objects.hxx" Marcvs [alias Shortest email in the world]

2 1

Problem with Array.hxx declaring global functions - proposed solution.
by Barry Scott Sept. 10, 2000

Sept. 10, 2000

Xavier reported a bug array.hxx. It declares the following functions globally int species(const Object& ob) int species(PyObject *pyob) Array toArray(PyObject* p) Array toArray(const Object&ob) I propose to add all four to the class Array as static methods. BArry

1 0

5.0b : CXX.example throws exception.
by Joe Van Andel Sept. 6, 2000

Sept. 6, 2000

Using Python 1.52, gcc 2.95.2 on Redhat Linux 6.2 (As a minor correction, to run the example, I had to add "libraries=['stdc++']" to Demo/setup.py, in the invocation of 'Extension()' Even though I had linked Python with c++, 'cerr' was undefined until I linked the extension with std+++.) When I try to run the example (import CXX.example), it throws an exception: #0 0x80c3f64 in __throw () #1 0x40422890 in Py::Object::validate (this=0xbfffdc50) at /local/include/python1.5/CXX/Exception.hxx:19 #2 0x404031fc in Py::ExtensionModuleBase::module (this=0x811a548) at /local/include/python1.5/CXX/Objects.hxx:123 #3 0x40403525 in Py::ExtensionModuleBase::moduleDictionary (this=0x811a548) at /local/etc/CXX/cxx_extensions.cxx:108 #4 0x40424ef8 in Py::ExtensionModule<example_module>::initialize (this=0x811a548, module_doc=0x4043f820 "documentation for the example module") at /local/include/python1.5/CXX/Extensions.hxx:191 #5 0x403de46d in initexample () at example.cxx:266 #6 0x805f540 in _PyImport_LoadDynamicModule (name=0xbfffe754 "CXX.example", pathname=0xbfffe2c4 "/usr/local/lib/python1.5/site-packages/CXX/example.so", fp=0x8112828) at ./importdl.c:851 Any idea how to fix this? -- Joe VanAndel National Center for Atmospheric Research http://www.atd.ucar.edu/~vanandel/ Internet: vanandel(a)ucar.edu

2 1

Re: --with-cxx patch to build process
by Greg Couch Sept. 5, 2000

Sept. 5, 2000

FYI, this is a non-issue with us. We build all of our C++ extensions as shared libraries, on *NIX and Windows, and all of the current OS versions correctly call C++ static initializers. The only OS in the recent past that caused problems for us was Digital UNIX 4.0 and one system is easy to fix by hand. Greg Couch UCSF Computer Graphics Lab gregc(a)cgl.ucsf.edu

2 1