From gregc at cgl.ucsf.EDU Fri Sep 1 20:07:34 2000 From: gregc at cgl.ucsf.EDU (Greg Couch) Date: Fri, 1 Sep 2000 11:07:34 -0700 (PDT) Subject: [C++-SIG] Re: --with-cxx patch to build process Message-ID: <200009011807.LAA103707@socrates.cgl.ucsf.edu> 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 at cgl.ucsf.edu From dubois1 at llnl.gov Tue Sep 5 23:51:01 2000 From: dubois1 at llnl.gov (Paul F. Dubois) Date: Tue, 5 Sep 2000 14:51:01 -0700 Subject: [C++-SIG] Re: --with-cxx patch to build process In-Reply-To: <200009011807.LAA103707@socrates.cgl.ucsf.edu> Message-ID: So is this now really a non-issue (hope, hope) for everyone? > -----Original Message----- > From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On > Behalf Of Greg Couch > Sent: Friday, September 01, 2000 11:08 AM > To: c++-sig at python.org > Subject: [C++-SIG] Re: --with-cxx patch to build process > > > 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 at cgl.ucsf.edu > > _______________________________________________ > C++-SIG maillist - C++-SIG at python.org > http://www.python.org/mailman/listinfo/c++-sig > From barry at scottb.demon.co.uk Thu Sep 7 00:42:29 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Wed, 6 Sep 2000 23:42:29 +0100 Subject: [C++-SIG] 5.0b : CXX.example throws exception. In-Reply-To: <39AA9DDA.D108EA0C@atd.ucar.edu> Message-ID: <000901c01853$bca50f20$060210ac@private> Here is what I know from CXX on FreeBSD. If python 1.5.2 is not compiled and linked correctly you cannot import C++ code. This was fixed for FreeBSD a few months back. Maybe the port to Linux has the same problem. In spite of a good python I get the following SEGV under FReeBSD with the lastest code. Under FreeBSD I get: Python 1.5.2 (#2, May 22 2000, 20:03:56) [GCC 2.95.2 19991024 (release)] on freebsd4 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import example >>> example.test() Example Test starting Trying to convert a String to an Int Segmentation fault (core dumped) I cannot find a reason that the throw in this case is not trapped by the enclosing try. Under Windows/NT and MSVC 6 + SP3 it all works as expected. I use the following script to compile CXX on FreeBSD. g++ -fpic -ansi -I. -I./Demo -O -D_THREAD_SAFE -I/usr/local/include/python1.5 -I/usr/local/include/python1.5 -DHAVE_CONFIG_H -c ./Demo/r.cxx g++ -fpic -ansi -I. -I./Demo -O -D_THREAD_SAFE -I/usr/local/include/python1.5 -I/usr/local/include/python1.5 -DHAVE_CONFIG_H -c ./Demo/example.cxx g++ -fpic -ansi -I. -I./Demo -O -D_THREAD_SAFE -I/usr/local/include/python1.5 -I/usr/local/include/python1.5 -DHAVE_CONFIG_H -c ./Demo/rtest.cxx g++ -fpic -ansi -I. -I./Demo -O -D_THREAD_SAFE -I/usr/local/include/python1.5 -I/usr/local/include/python1.5 -DHAVE_CONFIG_H -c ./Src/cxxsupport.cxx cc -fpic -ansi -I. -I./Demo -O -D_THREAD_SAFE -I/usr/local/include/python1.5 -I/usr/local/include/python1.5 -DHAVE_CONFIG_H -c ./Src/cxxextensions.c g++ -fpic -ansi -I. -I./Demo -O -D_THREAD_SAFE -I/usr/local/include/python1.5 -I/usr/local/include/python1.5 -DHAVE_CONFIG_H -c ./Src/cxx_extensions.cxx g++ -shared -pthread r.o example.o rtest.o cxxsupport.o cxxextensions.o cxx_extensions.o -lgcc -lstdc++ -o example.so Hope some of this helps. BArry > -----Original Message----- > From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On > Behalf Of Joe Van Andel > Sent: 28 August 2000 18:14 > To: Python/C++ SIG > Subject: [C++-SIG] 5.0b : CXX.example throws exception. > > > 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::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 at ucar.edu From Marc.Poinot at onera.fr Fri Sep 8 11:33:51 2000 From: Marc.Poinot at onera.fr (Marc Poinot) Date: Fri, 08 Sep 2000 11:33:51 +0200 Subject: [C++-SIG] New CXX release (5.0) Message-ID: <39B8B27F.5351379A@onera.fr> CXX/Array.hxx line 3, header include should be now: #include "CXX/Objects.hxx" Marcvs [alias Shortest email in the world] From barry at scottb.demon.co.uk Sun Sep 10 23:48:56 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Sun, 10 Sep 2000 22:48:56 +0100 Subject: [C++-SIG] Problem with Array.hxx declaring global functions - proposed solution. Message-ID: <000001c01b70$eb17da70$060210ac@private> 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 From barry at scottb.demon.co.uk Sun Sep 10 23:53:07 2000 From: barry at scottb.demon.co.uk (Barry Scott) Date: Sun, 10 Sep 2000 22:53:07 +0100 Subject: [C++-SIG] New CXX release (5.0) In-Reply-To: <39B8B27F.5351379A@onera.fr> Message-ID: <000101c01b71$8132d320$060210ac@private> Agreed. I'll fix on SOurceForge once I have the other array.hxx problem solved. BArry > -----Original Message----- > From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On > Behalf Of Marc Poinot > Sent: 08 September 2000 10:34 > To: Python/C++ SIG > Subject: [C++-SIG] New CXX release (5.0) > > > CXX/Array.hxx line 3, header include should be now: #include "CXX/Objects.hxx" > > Marcvs [alias Shortest email in the world] > > _______________________________________________ > C++-SIG maillist - C++-SIG at python.org > http://www.python.org/mailman/listinfo/c++-sig > From Marc.Poinot at onera.fr Mon Sep 11 11:24:02 2000 From: Marc.Poinot at onera.fr (Marc Poinot) Date: Mon, 11 Sep 2000 11:24:02 +0200 Subject: [C++-SIG] CXX problems on SGI Message-ID: <39BCA4B2.6BA570B9@onera.fr> 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( 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- From furnish at actel.com Mon Sep 11 23:15:36 2000 From: furnish at actel.com (Geoffrey Furnish) Date: Mon, 11 Sep 2000 14:15:36 -0700 (PDT) Subject: [C++-SIG] CXX problems on SGI In-Reply-To: <39BCA4B2.6BA570B9@onera.fr> References: <39BCA4B2.6BA570B9@onera.fr> Message-ID: <14781.19320.114371.620232@zork.amer.actel.com> Marc Poinot writes: > > 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. zork[26] cat extern_try.cc extern "C" int f() { try { int x = 2; return x; } catch(...) { return -1; } } zork[27] KCC --strict -c extern_try.cc zork[28] 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. I don't think it would be a good idea to remove the try block. Instead, if there is no way to fix your compiler, I'd suggest moving the return out of the try/catch block. The code could set an int return value code to p->compare(...) in the try block, and to -1 in the catch block, and then the final statement of the routine, not in an exception region, could just return this value. > extern "C" int compare_handler( PyObject *self, PyObject *other ) > { > // try > // { > PythonExtensionBase *p = static_cast( 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- From Marc.Poinot at onera.fr Tue Sep 12 14:57:39 2000 From: Marc.Poinot at onera.fr (Marc Poinot) Date: Tue, 12 Sep 2000 14:57:39 +0200 Subject: [C++-SIG] CXX problems on SGI References: <39BCA4B2.6BA570B9@onera.fr> <14781.19320.114371.620232@zork.amer.actel.com> Message-ID: <39BE2843.41BECB@onera.fr> *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?] From Marc.Poinot at onera.fr Wed Sep 13 14:23:04 2000 From: Marc.Poinot at onera.fr (Marc Poinot) Date: Wed, 13 Sep 2000 14:23:04 +0200 Subject: [C++-SIG] CXX problems on SGI References: Message-ID: <39BF71A8.2E6486C2@onera.fr> "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 ;) ] From bscott at Ridgeway-Sys.com Thu Sep 14 13:41:52 2000 From: bscott at Ridgeway-Sys.com (Barry Scott) Date: Thu, 14 Sep 2000 12:41:52 +0100 Subject: [C++-SIG] CXX problems on SGI Message-ID: <00533D13955AD411AF3800A0C9B426390EBF96@RIDGEWAY> [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 at 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 at python.org http://www.python.org/mailman/listinfo/c++-sig From dubois1 at llnl.gov Thu Sep 14 14:44:41 2000 From: dubois1 at llnl.gov (Paul F. Dubois) Date: Thu, 14 Sep 2000 05:44:41 -0700 Subject: [C++-SIG] CXX problems on SGI In-Reply-To: <00533D13955AD411AF3800A0C9B426390EBF96@RIDGEWAY> Message-ID: Danger, Will Robinson. Not serious, but: The init method of a module has to stay extern "C" or Python won't load it. > -----Original Message----- > From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On > Behalf Of Barry Scott > Sent: Thursday, September 14, 2000 4:42 AM > To: 'Marc Poinot'; Geoffrey Furnish > Cc: Python/C++ SIG > Subject: RE: [C++-SIG] CXX problems on SGI > > > [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 at 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 at python.org > http://www.python.org/mailman/listinfo/c++-sig > > _______________________________________________ > C++-SIG maillist - C++-SIG at python.org > http://www.python.org/mailman/listinfo/c++-sig > From Marc.Poinot at onera.fr Thu Sep 14 16:14:59 2000 From: Marc.Poinot at onera.fr (Marc Poinot) Date: Thu, 14 Sep 2000 16:14:59 +0200 Subject: [C++-SIG] CXX problems on SGI References: <00533D13955AD411AF3800A0C9B426390EBF96@RIDGEWAY> Message-ID: <39C0DD63.628407B1@onera.fr> Barry Scott wrote: > > [6] CXX developers fix CXX to work with SGI, etc, compiler > I will Sir... My first contribution has been to split the files into per-classes classes and add a Makefile. What ? This is not a contribution, it is a I've decided to do this in order to point out which parts where problematic for some compilers. This also leads to a library of objects (classes) where headers are isolated from bodies. I also plan to add some class unit tests, to check wether my modifications have some impact to the original behavior of CXX... or not. I've stored my "parallel" version into a home-made-cvs-repository, so that I can merge we "your" version. I can explain with 150 lines my work, perhaps it's better for all of us to have a look at my work and tell me what you think. I have a 2 tarballs: [1] with the complete CVS repository, you can have a look a some tagged versions I've done. [2] the tarball of my current version. I can give you an anonymous ftp adresse to get it if you mind. The is NO real source modification, all is re-structuration of files and production. Marcvs [alias And at this point, it looks like the problem IS the exception into an extern] From jgreene at adaptivesilicon.com Sat Sep 23 22:31:10 2000 From: jgreene at adaptivesilicon.com (Jonathan Greene) Date: Sat, 23 Sep 2000 13:31:10 -0700 Subject: [C++-SIG] Python classes with methods that are C extensions? Message-ID: <39CD130E.F6350F86@adaptivesilicon.com> 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. From abrahams at mediaone.net Sun Sep 24 13:43:15 2000 From: abrahams at mediaone.net (David Abrahams) Date: Sun, 24 Sep 2000 07:43:15 -0400 Subject: [c++-sig] Digest Number 36 References: <969779490.14667@egroups.com> Message-ID: <025301c0261c$a05049d0$0500a8c0@dragonsys.com> ----- Original Message ----- > Message: 1 > Date: Sat, 23 Sep 2000 13:31:10 -0700 > From: Jonathan Greene > 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.