From phil at geog.ubc.ca  Fri May  5 20:57:08 2000
From: phil at geog.ubc.ca (Phil Austin)
Date: Fri, 5 May 2000 11:57:08 -0700 (PDT)
Subject: [C++-SIG] setattr and CXX-4.2
In-Reply-To: <000001bfb14a$12a7db30$060210ac@private>
References: <14596.45049.483478.431140@brant.geog.ubc.ca>
	<000001bfb14a$12a7db30$060210ac@private>
Message-ID: <14611.6532.303619.869769@brant.geog.ubc.ca>

I'm curious about the asymmetry between getattr and setattr in
CXX_Extensions.h: I don't see the setattr equivalent to

	virtual Object getattr_methods( const char *_name )

Is this because it hasn't been implemented or because it isn't needed?
I'm asking mainly to see whether I understand what's going on with
CXX, rather than from any immediate need to get/set member data.

Thanks, Phil




From sharris at primus.com  Tue May  9 01:07:31 2000
From: sharris at primus.com (Steve Harris)
Date: 08 May 2000 16:07:31 -0700
Subject: [C++-SIG] Problems building and testing CXX demo
Message-ID: <sv7ld4tzd8.fsf@hodge.primus.com>

[g++ 2.95.2 on solaris 2.5.1]

I'm trying to build the latest CXX demonstration module 'example' and
run its test suite. Seeing that CXX ships with a 'setup.py' file, I
used Distutils to build and install the module. I was also careful to
follow the Readme file's warnings about first building Python with the
LINKCC and LDSHARED environmental variables set.

Python built fine, and the 'example' module builds fine - though it
takes about 30 minutes to build! Once I install the built 'example'
module, I can fire up the python interpreter and type

>>> from example import *
... (an 'r' gets created and destroyed)
>>> test()

At that point, python aborts and dumps core. The stack trace looks
like a thrown exception is leaking out and aborting the program.

Has anyone else noticed this problem? I can provide a stack trace if
necessary.

Can anyone provide some advice on how to build the 'python.cxx' sample
interpreter that's supposed to link with the 'example' module?

I've tried to work through adding this module to a 'Setup.in' file and
going through the 'Makefile.pre.in' steps to build an embedded
interpreter, but that all seems like overkill for such a deceptively
simple task.

Any input would be appreciated.

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com



From phil at geog.ubc.ca  Tue May  9 01:53:36 2000
From: phil at geog.ubc.ca (Phil Austin)
Date: Mon, 8 May 2000 16:53:36 -0700 (PDT)
Subject: [C++-SIG] Problems building and testing CXX demo
In-Reply-To: <sv7ld4tzd8.fsf@hodge.primus.com>
References: <sv7ld4tzd8.fsf@hodge.primus.com>
Message-ID: <14615.21376.427611.860881@brant.geog.ubc.ca>

Steve Harris writes:

[snip]

 > Can anyone provide some advice on how to build the 'python.cxx' sample
 > interpreter that's supposed to link with the 'example' module?

I can't help with most of this, but here's an example of
a successful build of python.o using KCC under solaris 2.6
(note that this takes less that 2 minutes on an Ultra 1 --
anyone know whether recent gcc snapshots are doing a better
job on templates?)


<peacock ~/mail/cxx-barry-2000-04-30/CXX> time bash -v testit.sh
KCC -c -I/nfs/brant/local1/lib/python/solaris/include/python1.5 -IInclude \
        -I/nfs/brant/local1/lib/python/include/python1.5 -O Demo/python.cxx -o python.o

KCC -c -I/nfs/brant/local1/lib/python/solaris/include/python1.5 -IInclude \
        -I/nfs/brant/local1/lib/python/include/python1.5 -O Src/cxxsupport.cxx  -o cxxsupport.o

KCC -c -I/nfs/brant/local1/lib/python/solaris/include/python1.5 -IInclude  \
        -I/nfs/brant/local1/lib/python/include/python1.5 -O Demo/example.cxx -o example.o

KCC -c -I/nfs/brant/local1/lib/python/solaris/include/python1.5 -IInclude \
        -I/nfs/brant/local1/lib/python/include/python1.5 -O Demo/rtest.cxx -o rtest.o

KCC -c -I/nfs/brant/local1/lib/python/solaris/include/python1.5 -IInclude \
        -I/nfs/brant/local1/lib/python/include/python1.5 -O Demo/r.cxx -o r.o

KCC -c -I/nfs/brant/local1/lib/python/solaris/include/python1.5 -IInclude \
        -I/nfs/brant/local1/lib/python/include/python1.5 -O Src/cxx_extensions.cxx -o cxx_extensions.o

cc -c -I/nfs/brant/local1/lib/python/solaris/include/python1.5 -IInclude \
        -I/nfs/brant/local1/lib/python/include/python1.5 -O Src/cxxextensions.c  -o cxxextensions.o 

KCC -G example.o cxxsupport.o cxx_extensions.o cxxextensions.o  r.o rtest.o -o libcxx.so
C++ prelinker: Recompiling Demo/example.cxx
C++ prelinker: Recompiling Src/cxx_extensions.cxx

KCC  python.o -o mypython  -L/nfs/brant/local1/lib/python/solaris/lib/python1.5/config \
          -lpython1.5 -lm -lnsl -lsocket -ldl ./libcxx.so

71.57u 4.94s 1:33.04 82.2%

<peacock ~/mail/cxx-barry-2000-04-30/CXX> mypython
Greetings. Type from example import *; test()
Python 1.5.2 (#2, Aug 26 1999, 22:59:52) [C] on sunos5
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> from example import *
>>> test()
Correctly caught CXX: type error.
  Exception value: CXX: type error.
  Exception traceback: None
Numbers: ok
String: ok
List: ok
Dict: ok
Tuple: ok
STL test: ok
Extension object test: ok.
Module test ok.



From sharris at primus.com  Tue May  9 07:17:30 2000
From: sharris at primus.com (Steve Harris)
Date: 08 May 2000 22:17:30 -0700
Subject: [C++-SIG] Re: Problems building and testing CXX demo
In-Reply-To: Phil Austin's message of "Mon, 8 May 2000 16:53:36 -0700 (PDT)"
References: <sv7ld4tzd8.fsf@hodge.primus.com>
	<14615.21376.427611.860881@brant.geog.ubc.ca>
Message-ID: <svbt2gcnf9.fsf_-_@hodge.primus.com>

Phil Austin <phil at geog.ubc.ca> writes:

> I can't help with most of this, but here's an example of a
> successful build of python.o using KCC under solaris 2.6

[...]

If I replace your KCC invocations with g++, I can get to this point by
occasionally including a '-g' to overcome some problems with Sun's
assembler. So I can get all of the object files compiled. This is
where I get in trouble:


> KCC  python.o -o mypython  -L/nfs/brant/local1/lib/python/solaris/lib/python1.5/config \
>           -lpython1.5 -lm -lnsl -lsocket -ldl ./libcxx.so


In my case, I translate this to look like:


> g++ python.o -o mypython -L ~/usr/local/lib/python1.5/config \
  -lpython1.5 -lm -lnsl -lsocket -ldl ./libcxx.so
Undefined                       first referenced
 symbol                             in file
in                                  ./libcxx.so
ld: fatal: Symbol referencing errors. No output written to mypython
collect2: ld returned 1 exit status


Note that there's a symbol "in" that's missing. I can use 'nm' to
isolate that symbol:


> nm ./libcxx.so | egrep '\|in$'
[873]   |         0|       0|NOTY |GLOB |0    |UNDEF  |in


At this point, I'm stumped. I can't find any such variable in the
code. Any ideas what this could mean?

[...]

Thanks for your help so far.

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com



From Marc.Poinot at onera.fr  Tue May  9 13:50:08 2000
From: Marc.Poinot at onera.fr (Marc Poinot)
Date: Tue, 09 May 2000 13:50:08 +0200
Subject: [C++-SIG] Problems building and testing CXX demo
References: <sv7ld4tzd8.fsf@hodge.primus.com>
Message-ID: <3917FB70.17C6A130@onera.fr>

Steve Harris wrote:
> 
> [g++ 2.95.2 on solaris 2.5.1]
> 
I used to fail to compile CXX with Gcc 2.95.2 ;)
It fails either on Sun/Solaris and SGI/Irix.

The first Gcc snapshot that can compile CXX is 20/03/2000
you can find it (and newer snapshots) at

http://www.fsf.org/software/gcc/gcc.html

This leads to no problem, AFAIK...

> 
> Any input would be appreciated.
> 
Here's the makefile, with both Gcc and 
SGI compiler (you have to set your own paths):

#
#
INCS=-I./Include -I/tools/py/include/python1.5
#
CCC=g++
#CCC=CC -64 -LANG:std -woff 1401,1069
# use special ar to instanciate templates (pre-linker)
AR=ar clq 
#AR=CC -woff 1401 -ar -o
#
OBJST=Demo/arraytest.o Demo/example.o Demo/python.o Demo/r.o Demo/rtest.o
OBJSL=Src/cxx_extensions.o Src/cxxextensions.o Src/cxxsupport.o
LIBS=libCXX.a -L/tools/py/64/lib/python1.5/config -lpython1.5
#
#
.c.o:
	$(CCC) $(INCS) -c $< -o $@

.cxx.o:
	$(CCC) $(INCS) -c $< -o $@

all: libs demos

demos: libs $(OBJST)
	$(CCC) $(LIBS) $(OBJS) -o rtest 

libs: $(OBJSL)
	$(AR) libCXX.a Src/*.o

clean:
	rm -f libCXX.a Src/*.o Demo/*.o


Marcvs [alias Our extensions are also working fine, but we are NOT
        using all functionnalities of CXX  4.2 ]


-----------------------------------------------------------------------
 Marc POINOT             Alias: marcvs        Email: poinot at onera.fr
 ONERA -MFE/DSNA/ELSA    Tel: 01.46.73.42.84  Info: elsa-info at onera.fr
 29, Div. Leclerc        Fax: 01.46.73.41.66  Site:     
 92322 Chatillon FRANCE  Project: elsA        Web: http://www.onera.fr



From furnish at actel.com  Tue May  9 17:18:04 2000
From: furnish at actel.com (Geoffrey Furnish)
Date: Tue, 9 May 2000 08:18:04 -0700 (PDT)
Subject: [C++-SIG] Re: Problems building and testing CXX demo
In-Reply-To: <svbt2gcnf9.fsf_-_@hodge.primus.com>
References: <sv7ld4tzd8.fsf@hodge.primus.com>
	<14615.21376.427611.860881@brant.geog.ubc.ca>
	<svbt2gcnf9.fsf_-_@hodge.primus.com>
Message-ID: <14616.11308.458462.596480@zork.amer.actel.com>

Steve Harris writes:
 > Phil Austin <phil at geog.ubc.ca> writes:
 > > KCC  python.o -o mypython  -L/nfs/brant/local1/lib/python/solaris/lib/python1.5/config \
 > >           -lpython1.5 -lm -lnsl -lsocket -ldl ./libcxx.so
 > 
 > 
 > In my case, I translate this to look like:
 > 
 > 
 > > g++ python.o -o mypython -L ~/usr/local/lib/python1.5/config \
 >   -lpython1.5 -lm -lnsl -lsocket -ldl ./libcxx.so
 > Undefined                       first referenced
 >  symbol                             in file
 > in                                  ./libcxx.so
 > ld: fatal: Symbol referencing errors. No output written to mypython
 > collect2: ld returned 1 exit status
 > 
 > 
 > Note that there's a symbol "in" that's missing. I can use 'nm' to
 > isolate that symbol:
 > 
 > 
 > > nm ./libcxx.so | egrep '\|in$'
 > [873]   |         0|       0|NOTY |GLOB |0    |UNDEF  |in
 > 
 > 
 > At this point, I'm stumped. I can't find any such variable in the
 > code. Any ideas what this could mean?

It looks to me like just a small problem with the invocation of the
loader.  The KCC driver script may be able to notice that you've
provided a library without using a library introducer token (-l), and
perhaps g++ just isn't grokiing that in the version you're using.

Try changing your g++ invocation line to:

g++ python.o -o mypython -L ~/usr/local/lib/python1.5/config \
  -lpython1.5 -lm -lnsl -lsocket -ldl -L. -lcxx

-- 
Geoffrey Furnish            Actel Corporation        furnish at actel.com
Senior Staff Engineer      955 East Arques Ave       voice: 408-522-7528
Placement & Routing     Sunnyvale, CA   94086-4533   fax:   408-522-8041

"... because only those who write the code truly control the project."
						      -- Jamie Zawinski



From sharris at primus.com  Tue May  9 17:20:02 2000
From: sharris at primus.com (Steve Harris)
Date: 09 May 2000 08:20:02 -0700
Subject: [C++-SIG] Re: Problems building and testing CXX demo
In-Reply-To: Geoffrey Furnish's message of "Tue, 9 May 2000 08:18:04 -0700 (PDT)"
References: <sv7ld4tzd8.fsf@hodge.primus.com>
	<14615.21376.427611.860881@brant.geog.ubc.ca>
	<svbt2gcnf9.fsf_-_@hodge.primus.com>
	<14616.11308.458462.596480@zork.amer.actel.com>
Message-ID: <svsnvrzr6l.fsf@hodge.primus.com>

Geoffrey Furnish <furnish at actel.com> writes:

[...]

> It looks to me like just a small problem with the invocation of the
> loader.  The KCC driver script may be able to notice that you've
> provided a library without using a library introducer token (-l), and
> perhaps g++ just isn't grokiing that in the version you're using.
> 
> Try changing your g++ invocation line to:
> 
> g++ python.o -o mypython -L ~/usr/local/lib/python1.5/config \
>   -lpython1.5 -lm -lnsl -lsocket -ldl -L. -lcxx

Thanks for the tip. Unfortunately, we're still without joy. I tried
that change and got the same error regarding the undefined symbol
"in."

I'm wondering if this is a problem with some unintended interaction
between Gnu and Sun tools.

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com



From phil at geog.ubc.ca  Tue May  9 18:16:18 2000
From: phil at geog.ubc.ca (Phil Austin)
Date: Tue, 9 May 2000 09:16:18 -0700 (PDT)
Subject: [C++-SIG] Re: Problems building and testing CXX demo
In-Reply-To: <svsnvrzr6l.fsf@hodge.primus.com>
References: <sv7ld4tzd8.fsf@hodge.primus.com>
	<14615.21376.427611.860881@brant.geog.ubc.ca>
	<svbt2gcnf9.fsf_-_@hodge.primus.com>
	<14616.11308.458462.596480@zork.amer.actel.com>
	<svsnvrzr6l.fsf@hodge.primus.com>
Message-ID: <14616.14802.757073.483588@brant.geog.ubc.ca>

Steve Harris writes:
 > Geoffrey Furnish <furnish at actel.com> writes:
 > 
 > [...]
 > 
 > > It looks to me like just a small problem with the invocation of the
 > > loader.  The KCC driver script may be able to notice that you've
 > > provided a library without using a library introducer token (-l), and
 > > perhaps g++ just isn't grokiing that in the version you're using.
 > > 
 > > Try changing your g++ invocation line to:
 > > 
 > > g++ python.o -o mypython -L ~/usr/local/lib/python1.5/config \
 > >   -lpython1.5 -lm -lnsl -lsocket -ldl -L. -lcxx
 > 
 > Thanks for the tip. Unfortunately, we're still without joy. I tried
 > that change and got the same error regarding the undefined symbol
 > "in."
 > 
 > I'm wondering if this is a problem with some unintended interaction
 > between Gnu and Sun tools.
 > 

one other thing you might check: are you able to build/run
Python-1.5.2/Demo/embed/demo.c with gcc?  That would at least
reassure you that you had the basic link sequence right.

Even if this works though, it doesn't solve your problem of
test() crashing when you import example.so -- so maybe the
next step is to install the March snapshot and reproduce
Marc Poinot's success with example.so, then tackle python.cxx.
I'd be interested in hearing if your compile time is reduced.

Regards, Phil








From sharris at primus.com  Tue May  9 18:18:59 2000
From: sharris at primus.com (Steve Harris)
Date: 09 May 2000 09:18:59 -0700
Subject: [Steve Harris <sharris@primus.com>] Re: [C++-SIG] Problems building and testing CXX demo
Message-ID: <svvh0ny9vw.fsf@hodge.primus.com>

[accidentally mailed this directly to Marc]

-------------- next part --------------
An embedded message was scrubbed...
From: Steve Harris <sharris at primus.com>
Subject: Re: [C++-SIG] Problems building and testing CXX demo
Date: 09 May 2000 08:36:53 -0700
Size: 2954
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20000509/75fbd721/attachment.eml>

From sharris at primus.com  Tue May  9 18:19:23 2000
From: sharris at primus.com (Steve Harris)
Date: 09 May 2000 09:19:23 -0700
Subject: [C++-SIG] Re: Problems building and testing CXX demo
References: <sv7ld4tzd8.fsf@hodge.primus.com>
	<14615.21376.427611.860881@brant.geog.ubc.ca>
	<svbt2gcnf9.fsf_-_@hodge.primus.com>
	<14616.11308.458462.596480@zork.amer.actel.com>
	<svsnvrzr6l.fsf@hodge.primus.com>
	<14616.14802.757073.483588@brant.geog.ubc.ca>
Message-ID: <svpuqvy9v8.fsf@hodge.primus.com>

Phil Austin <phil at geog.ubc.ca> writes:

> one other thing you might check: are you able to build/run
> Python-1.5.2/Demo/embed/demo.c with gcc?  That would at least
> reassure you that you had the basic link sequence right.

Yes, I was able to get that one working fine. That sample is so simple
and easy to follow. I figured moving on to CXX from there would be a
snap.

> Even if this works though, it doesn't solve your problem of
> test() crashing when you import example.so -- so maybe the
> next step is to install the March snapshot and reproduce
> Marc Poinot's success with example.so, then tackle python.cxx.
> I'd be interested in hearing if your compile time is reduced.

Hopefully you'll see my previous posting showing me trying to work
through Marc's suggestion. I couldn't get it to link properly at the
end.

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com



From sharris at primus.com  Tue May  9 18:42:51 2000
From: sharris at primus.com (Steve Harris)
Date: 09 May 2000 09:42:51 -0700
Subject: [C++-SIG] Re: Problems building and testing CXX demo
Message-ID: <svaehzy8s4.fsf@hodge.primus.com>

> Is this an issue with the order of things on the load line?  What if
> you move libCXX.a to follow rtest.o?

Well, after some rearranging, I did come up with this:


> g++ -L ~/usr/local/lib/python1.5/config example.o python.o r.o \
  rtest.o libCXX.a -lpython1.5 -lsocket -lnsl -ldl -o rtest
ld: warning: relocation error: R_SPARC_32: file example.o: symbol in:
        external symbolic relocation against non-allocatable section .stab;
        cannot be processed at runtime: relocation ignored
Undefined                       first referenced
 symbol                             in file
in                                  example.o
ld: fatal: Symbol referencing errors. No output written to rtest
collect2: ld returned 1 exit status


This is a little better, in the sense that most of the references get
resolved. There's still than lingering "in" symbol.

> Sorry, we're all grasping at straws here.  I'm wondering if you've
> really built g++ correctly for your platform?

I appreciate your help. At this point, perhaps a clean rebuild of
everything is in order.

I've pushed on this discussion because I figured that others may
download CXX and go through similar steps. CXX looks like a great
project. I'd just like to get it built so I can start contributing.

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com



From sharris at primus.com  Tue May  9 19:02:00 2000
From: sharris at primus.com (Steve Harris)
Date: 09 May 2000 10:02:00 -0700
Subject: [C++-SIG] Re: Problems building and testing CXX demo
Message-ID: <sv3dnry7w7.fsf@hodge.primus.com>

> Which g++ version ?

$ g++ -v
Reading specs from /usr/local/sun4/lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.2/specs
gcc version 2.95.2 19991024 (release)


> Looks like (maybe) your compiler has problem with namespaces
> (Py::blabla::blablabla) and that certainly is a lack of
> old-non-ISO-compilant compilers.
>
> The error occurs in r.cxx and example.cxx You can try an nm on the
> files and look what the compiler has generated as defined and
> expected. The mangled names may lack the Py:: prefix (?).

Here's some output:

$ nm -V
nm: Software Generation Utilities (SGU) Solaris/ELF (3.0)
$ nm example.o | egrep 'as_string'
[841]   |         0|       0|NOTY |GLOB |0    |UNDEF  |as_string__CQ22Py6Object
$ nm r.o | egrep 'number_remainder'
[303]   |         0|       0|NOTY |GLOB |0    |UNDEF  |number_remainder__Q22Py19PythonExtensionBaseRCQ22Py6Object

I can't really understand if the "Py" in there is in fact a namespace
qualifier. It's also interesting that if I use the '-C' option to nm
to de-mangle the names, I get the same results back out. Does that
mean that nm doesn't understand the name mangling?


> Then, maybe the link editor has problem with mangled names ?  Did
> you use Gnu ld or not ? (we are NOT using binutils, ld and co...)

I'm not sure. Here's the version dump:

$ ld -V
ld: Software Generation Utilities - Solaris/ELF (3.0)

I was going to try building binutils in repsonse to a Usenet post? I
found that mentioned an error message I've encountered while
compiling. That would contradict your advice here.


> As I told you in my previous email, we succeeded with a gcc
> snapshot. I mean this is NOT gcc 2.95.2, we tryed it but it fails
> with CXX.

Okay. I missed that detail. We're obviously using 2.95.2 right now.


Footnotes: 
? http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=512435895&search=thread&CONTEXT=957888607.1283653636&HIT_CONTEXT=957888588.1283325957&HIT_NUM=5&hitnum=1

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com



From dubois1 at llnl.gov  Tue May  9 21:29:01 2000
From: dubois1 at llnl.gov (Paul F. Dubois)
Date: Tue, 9 May 2000 12:29:01 -0700
Subject: [C++-SIG] Re: Problems building and testing CXX demo
In-Reply-To: <sv3dnry7w7.fsf@hodge.primus.com>
Message-ID: <NDBBIEFMILBFPMDHJIMFGEGNCFAA.dubois1@llnl.gov>

ld: warning: relocation error: R_SPARC_32: file example.o: symbol in:
        external symbolic relocation against non-allocatable section .stab;
        cannot be processed at runtime: relocation ignored

This is the key; I've never seen a message like this but it doesn't look
good!
Perhaps something being loaded was compiled with an older OS version?




From phil at geog.ubc.ca  Wed May 10 01:40:17 2000
From: phil at geog.ubc.ca (Phil Austin)
Date: Tue, 9 May 2000 16:40:17 -0700 (PDT)
Subject: [C++-SIG] Callable.apply() throws exceptions.TypeError
In-Reply-To: <000001bfb14a$12a7db30$060210ac@private>
References: <14596.45049.483478.431140@brant.geog.ubc.ca>
	<000001bfb14a$12a7db30$060210ac@private>
Message-ID: <14616.41441.557545.373103@brant.geog.ubc.ca>

In the version of CXX I have (dated 2000-4-30), calling
Callable.apply() with no arguments evokes 

!             Object apply(PyObject* pargs = 0) const {
! 				return apply (Tuple(pargs));

which produces an exceptions.TypeError on my machine 
(solaris with KCC).  My quick fix was to remove the default
argment and add another override:

*** CXX_Objects.h	2000/05/09 23:33:15	1.4
--- CXX_Objects.h	2000/05/09 23:36:23
***************
*** 1773,1786 ****
                  return pyob && PyCallable_Check (pyob);
              }
              
              // Call
              Object apply(const Tuple& args) const {
                  return asObject(PyObject_CallObject(ptr(), args.ptr()));
              }
              
!             Object apply(PyObject* pargs = 0) const {
! 				return apply (Tuple(pargs));
! 			}
          }; 
          
          class Module: public Object {
--- 1773,1792 ----
                  return pyob && PyCallable_Check (pyob);
              }
              
+ 
              // Call
              Object apply(const Tuple& args) const {
                  return asObject(PyObject_CallObject(ptr(), args.ptr()));
              }
              
!             Object apply(PyObject* pargs) const {
! 		return apply (Tuple(pargs));
! 	    }
! 
!             Object apply(void) const {
!                 return asObject(PyObject_CallObject(ptr(), (PyObject*) NULL));
! 	    }
! 
          }; 
          
          class Module: public Object {


Regards, Phil







From dubois1 at llnl.gov  Wed May 10 16:58:50 2000
From: dubois1 at llnl.gov (Paul F. Dubois)
Date: Wed, 10 May 2000 07:58:50 -0700
Subject: [C++-SIG] Callable.apply() throws exceptions.TypeError
In-Reply-To: <14616.41441.557545.373103@brant.geog.ubc.ca>
Message-ID: <NDBBIEFMILBFPMDHJIMFIEHFCFAA.dubois1@llnl.gov>

This is clearly an error, a rather famous one at that (it is in Meyer's
book). I will fix it as my penance.

Blushingly-yours-in-Python,

P.


> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of Phil Austin
> Sent: Tuesday, May 09, 2000 4:40 PM
> To: Barry Scott
> Cc: c++-sig at python.org
> Subject: [C++-SIG] Callable.apply() throws exceptions.TypeError
>
>
>
> In the version of CXX I have (dated 2000-4-30), calling
> Callable.apply() with no arguments evokes
>
> !             Object apply(PyObject* pargs = 0) const {
> ! 				return apply (Tuple(pargs));
>
> which produces an exceptions.TypeError on my machine
> (solaris with KCC).  My quick fix was to remove the default
> argment and add another override:
>
> *** CXX_Objects.h	2000/05/09 23:33:15	1.4
> --- CXX_Objects.h	2000/05/09 23:36:23
> ***************
> *** 1773,1786 ****
>                   return pyob && PyCallable_Check (pyob);
>               }
>
>               // Call
>               Object apply(const Tuple& args) const {
>                   return asObject(PyObject_CallObject(ptr(), args.ptr()));
>               }
>
> !             Object apply(PyObject* pargs = 0) const {
> ! 				return apply (Tuple(pargs));
> ! 			}
>           };
>
>           class Module: public Object {
> --- 1773,1792 ----
>                   return pyob && PyCallable_Check (pyob);
>               }
>
> +
>               // Call
>               Object apply(const Tuple& args) const {
>                   return asObject(PyObject_CallObject(ptr(), args.ptr()));
>               }
>
> !             Object apply(PyObject* pargs) const {
> ! 		return apply (Tuple(pargs));
> ! 	    }
> !
> !             Object apply(void) const {
> !                 return asObject(PyObject_CallObject(ptr(),
> (PyObject*) NULL));
> ! 	    }
> !
>           };
>
>           class Module: public Object {
>
>
> Regards, Phil
>
>
>
>
>
> _______________________________________________
> C++-SIG maillist  -  C++-SIG at python.org
> http://www.python.org/mailman/listinfo/c++-sig
>




From sharris at primus.com  Sun May 14 20:42:18 2000
From: sharris at primus.com (Steve Harris)
Date: 14 May 2000 11:42:18 -0700
Subject: [C++-SIG] Const-correctness with PythonExtensionBase/PythonExtension<T>
Message-ID: <svzopt9do5.fsf@hodge.primus.com>

Perhaps this topic has been covered before, but I just ran into it
while working on my first Python extension module using CXX.

Why are none of the virtual methods on PythonExtensionBase const? For
a particular example, consider PythonExtensionBase::sequence_length(),
defined as

  virtual int sequence_length();

It seems that the signature should be more like

  virtual int sequence_length() const;

to permit it to be called on a const PythonExtension<T>
instance. Additionally, the PythonExtension::add_varargs_method() and
friends should be able to receive a pointer to a const member
function.

I've dug into the add_varargs_method() function far enough to see that
we'd need a second map of function pointers to the const ones. Some
reworking would be required in there. But it seems like it should be
possible to make certain member functions const so that if you're
calling your Python-bound types from C++, you could still respect the
const semantics we know and love.

Yes, Python doesn't understand the distinction between const and
non-const variable, but our C++ binding should. If this debate is
already over, please point me to that discussion. If it's just a
current oversight in want of implementation improvement, then I'd like
to help with that.

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com



From barry at scottb.demon.co.uk  Wed May 17 00:07:03 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Tue, 16 May 2000 23:07:03 +0100
Subject: [C++-SIG] Const-correctness with PythonExtensionBase/PythonExtension<T>
In-Reply-To: <svzopt9do5.fsf@hodge.primus.com>
Message-ID: <000001bfbf83$111e4280$060210ac@private>

You may have a point about the const correctness however I'd
offer this perspective.

If I assume that it is Python calling the methods and Python
has no const awareness the const ness is not used. But it
might usefully prevent people from implementing
non-const algorithms for length() etc.

Adding const versions of add_varargs_method is not useful
as Python will always call the non const version. The const
version is only useful from C++ and these objects are
clumsy to use from C++. Better to add an API useful from C++
directly. (Much like COM Idispatch vs. custom interfaces on
windows)

I think the benefit of const algorithms for methods that match
Python semantics that are const is worth doing. But const
add_XXX_methods has no benefits - the add_XXX_methods only
exist to expose methods to Python, Python always calls the
non-const version.

		BArry




From barry at scottb.demon.co.uk  Wed May 17 00:20:09 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Tue, 16 May 2000 23:20:09 +0100
Subject: [C++-SIG] setattr and CXX-4.2
In-Reply-To: <14611.6532.303619.869769@brant.geog.ubc.ca>
Message-ID: <000101bfbf84$e5399e10$060210ac@private>

getattr_methods is a helper function. Its job is to return a function object
for any of the objects C++ methods that are referenced and to deal with
references to __methods__.

For objects with functions you must call getattr_methods() from your getattr()
after dealing with all the non-function attributes your object has.

Here is an example taken from CXX\Demo\r.cxx

Py::Object r::getattr( const char *name )
{
    if(std::string(name) == "c")
		return Py::Float(300.0);

    if(std::string(name) == "start")
		return Py::Int(start);

    return getattr_methods( name );
}

setattr is not allowed to create functions or mess up __methods__ so you simply
handle your non-function attributes and throw Py::NameError for all you know
nothing about.

		BArry



From sharris at primus.com  Wed May 17 01:30:38 2000
From: sharris at primus.com (Steve Harris)
Date: 16 May 2000 16:30:38 -0700
Subject: [C++-SIG] setattr and CXX-4.2
In-Reply-To: "Barry Scott"'s message of "Tue, 16 May 2000 23:20:09 +0100"
References: <000101bfbf84$e5399e10$060210ac@private>
Message-ID: <svsnvijco1.fsf@hodge.primus.com>

"Barry Scott" <barry at scottb.demon.co.uk> writes:

[...]

> Here is an example taken from CXX\Demo\r.cxx
> 
> Py::Object r::getattr( const char *name )
> {
>     if(std::string(name) == "c")
> 		return Py::Float(300.0);
> 
>     if(std::string(name) == "start")
> 		return Py::Int(start);
> 
>     return getattr_methods( name );
> }

Would it be possible to get a length argument in addition to the const
char* argument, if we're not getting a const std::string& as a
parameter? That is, if the length of the string is known "upstream,"
it would be convenient to have it here to both speed comparisons or to
construct a std::string as you've shown here. If the string hasn't
even been examined yet, then this would not be an option here.

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com



From furnish at actel.com  Wed May 17 01:43:50 2000
From: furnish at actel.com (Geoffrey Furnish)
Date: Tue, 16 May 2000 16:43:50 -0700 (PDT)
Subject: [C++-SIG] setattr and CXX-4.2
In-Reply-To: <svsnvijco1.fsf@hodge.primus.com>
References: <000101bfbf84$e5399e10$060210ac@private>
	<svsnvijco1.fsf@hodge.primus.com>
Message-ID: <14625.56630.49037.877176@zork.amer.actel.com>

The getattr signature is determined by the Python core.  We can't
really change that without reworking more of the Python guts, which
doesn't seem very feasible to me.  Also, it would just force the
caller of getattr to run strlen on the string anyway, so I don't
really see a net performance improvement coming from this.

Steve Harris writes:
 > "Barry Scott" <barry at scottb.demon.co.uk> writes:
 > 
 > [...]
 > 
 > > Here is an example taken from CXX\Demo\r.cxx
 > > 
 > > Py::Object r::getattr( const char *name )
 > > {
 > >     if(std::string(name) == "c")
 > > 		return Py::Float(300.0);
 > > 
 > >     if(std::string(name) == "start")
 > > 		return Py::Int(start);
 > > 
 > >     return getattr_methods( name );
 > > }
 > 
 > Would it be possible to get a length argument in addition to the const
 > char* argument, if we're not getting a const std::string& as a
 > parameter? That is, if the length of the string is known "upstream,"
 > it would be convenient to have it here to both speed comparisons or to
 > construct a std::string as you've shown here. If the string hasn't
 > even been examined yet, then this would not be an option here.
 > 
 > -- 
 > Steven E. Harris
 > Primus Knowledge Solutions, Inc.
 > http://www.primus.com
 > 
 > _______________________________________________
 > C++-SIG maillist  -  C++-SIG at python.org
 > http://www.python.org/mailman/listinfo/c++-sig
 > 



From sharris at primus.com  Wed May 17 02:02:04 2000
From: sharris at primus.com (Steve Harris)
Date: 16 May 2000 17:02:04 -0700
Subject: [C++-SIG] setattr and CXX-4.2
In-Reply-To: Geoffrey Furnish's message of "Tue, 16 May 2000 16:43:50 -0700 (PDT)"
References: <000101bfbf84$e5399e10$060210ac@private>
	<svsnvijco1.fsf@hodge.primus.com>
	<14625.56630.49037.877176@zork.amer.actel.com>
Message-ID: <svog66jb7n.fsf@hodge.primus.com>

Geoffrey Furnish <furnish at actel.com> writes:

[...]

> Also, it would just force the caller of getattr to run strlen on the
> string anyway, so I don't really see a net performance improvement
> coming from this.

Okay. That was the condition in my suggestion: only if _we're_ writing
the thing that calls this gettattr() function could this suggestion be
useful. Since it's Python itself, then this is fine.

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com



From barry at scottb.demon.co.uk  Wed May 17 02:26:09 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Wed, 17 May 2000 01:26:09 +0100
Subject: [C++-SIG] Const-correctness with PythonExtensionBase/PythonExtension<T>
Message-ID: <000a01bfbf96$7fc3ef10$060210ac@private>

	I think the goal of CXX is to allow Python to use objects that must be
	implemented in C++. I hope this goal is met and will be be met better
	over time.

	Should we have it as a goal to make these PyCXX extension objects easy
	to use from C++? Today I would say its not a goal.

	All the objects I've built with CXX have no need to be called from C++.

	I have needed to get at the C++ object that the PyCXX object is wrapping
	from other PyCXX code. But thats a different class of problem from the one
	you raise and has a solution.

	Going back to const. If adding const meets the goal then PyCXX should be
	changed. If it does not then I'd leave as is.

	Adding const to sequence_length will help the goal for the reasons you
	state. We should propose the adding of const to the appropiate methods.

	Adding const to add_XXX_method would add complexity without helping
	the main goal.

	I think your find that what you need to code for your example:

template <class T>
std::ostream& print_sequence(std::ostream& os, const Py::SeqBase<T>& seq)
{
  // Iterate over sequence and print each member (str()?)

  return os;
}

	Is this version that takes a sequence from python and checks that the
	elements of the sequence are of type T.

template <class T>
std::ostream& print_sequence(std::ostream& os, const Py::Sequence &seq)
{
  // Iterate over sequence and print each member (str()?)
	for( int i=0; i<seq.length(); i++ )
		{
		Py::Object o( seq[i] );
		if( T::check( o ) )
			{
			T *t = static_cast<T *>o.ptr();
			os << t.str();
			}
		else
			throw TypeError(T::name);
		}
  return os;
}

	I'm not sure that endusers are supposed to use or know about Seqbase.

	Or I'd perfer to write:

	for element in sequence:
		file.write( str(element) )

	which will call T::str() giver the sequence contains T's.

			BArry




From sharris at primus.com  Wed May 17 17:17:30 2000
From: sharris at primus.com (Steve Harris)
Date: 17 May 2000 08:17:30 -0700
Subject: [C++-SIG] Const-correctness with PythonExtensionBase/PythonExtension<T>
In-Reply-To: "Barry Scott"'s message of "Wed, 17 May 2000 01:26:09 +0100"
References: <000a01bfbf96$7fc3ef10$060210ac@private>
Message-ID: <svg0rhjjed.fsf@hodge.primus.com>

"Barry Scott" <barry at scottb.demon.co.uk> writes:

> Should we have it as a goal to make these PyCXX extension objects
> easy to use from C++? Today I would say its not a goal.

Fair enough.

> All the objects I've built with CXX have no need to be called from C++.
> 
> I have needed to get at the C++ object that the PyCXX object is
> wrapping from other PyCXX code. But thats a different class of
> problem from the one you raise and has a solution.

This is what I'm interested in. The examples in the Demo directory
present what are essentially Python types implemented in C++, not
wrappers around existing C++ types. You say that you know of "a
solution" to this class of problem. Can you share some of what you've
discovered?

At present, I'm trying to learn CXX by wrapping a hypothetical
"POD-like" C++ type that doesn't know anything about Python. Some of
the problems I'm having are:

1. Should the Python type wrap around a reference to the C++ type,
where the wrapped instance exists independently of the Python wrapper
instance, or should the Python wrapper contain the wrapped type by
value?

The former sounds realistic for cases where there's some "context"
variable existing in C++ (say, an application's open connection to a
database) that it wants to "lend" to user-provided Python script. This
reminds me of how the Active Server Pages processor binds the global
"objects" to the relevant web server request context and hands them to
script code and any invoked COM servers.

2. Should the Python type be constructible from Python? If the wrapper
holds the wrapped by reference, this construction becomes difficult,
because then you'd have to create two variables. How do you know when
you can delete the wrapped C++ variable?

3. If you're wrapping a type, you may not have access to pieces that
would be good for methods like str(). Does that just mean that the
type isn't printable in the Python sense?

4. I haven't gotten to trying to wrap containers yet. What if your C++
type has a method like
  const std::list<foo>& get_foos() const;
where the type exposes a nested container of some other type. That
looks like you could coax some Pythonic behavior out of the pattern,
but how would you go about wrapping it? Do you have to copy the whole
list for each request for the Python-wrapped sequence?


> Going back to const. If adding const meets the goal then PyCXX
> should be changed. If it does not then I'd leave as is.

I think it meets the higher-level aim of making use of wrapped Python
types "correct" in the C++ sense, which is consistent with aims like
avoiding bald pointers, casting, and such.

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com



From barry at scottb.demon.co.uk  Wed May 17 20:43:54 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Wed, 17 May 2000 19:43:54 +0100
Subject: [C++-SIG] How to use CXX...
In-Reply-To: <svg0rhjjed.fsf@hodge.primus.com>
Message-ID: <000501bfc02f$da520ef0$060210ac@private>

> This is what I'm interested in. The examples in the Demo directory
> present what are essentially Python types implemented in C++, not
> wrappers around existing C++ types. You say that you know of "a
> solution" to this class of problem. Can you share some of what you've
> discovered?

Here is the code to find out if a T object is in Py:Object o.

		if( T::check( o ) )	// is o of class T?
			{
			T *t = static_cast<T *>o.ptr(); // get the T out of the Py::Object o
			os << t.str();	// call a method on the C++ object T
			}

> At present, I'm trying to learn CXX by wrapping a hypothetical
> "POD-like" C++ type that doesn't know anything about Python. Some of
> the problems I'm having are:
> 
> 1. Should the Python type wrap around a reference to the C++ type,

	Depends on the life time of the C++ type. IF the C++ 
	lives longer then the Python object then you have to use a pointer
	or refernece.

	OTherwise you can use the Py:Object's life time to control the
	life time of the C++ type. Your wrappers d'tor will be called
	once Python is finished with the object.

> 2. Should the Python type be constructible from Python? If the wrapper
> holds the wrapped by reference, this construction becomes difficult,
> because then you'd have to create two variables. How do you know when
> you can delete the wrapped C++ variable?

	Basically you expose a method that will return instances of
	the python wrapper objects. Typically this look like a traditional
	factory.

> 3. If you're wrapping a type, you may not have access to pieces that
> would be good for methods like str(). Does that just mean that the
> type isn't printable in the Python sense?

	You control the str() method - throw an exception or return whatever
	you think is reasonable. For repr() return something even if its only
	<Steve Harris Object at 0x80012131> you will need this for debugging
	the C++ and the python code built on it.

> 4. I haven't gotten to trying to wrap containers yet. What if your C++
> type has a method like
>   const std::list<foo>& get_foos() const;
> where the type exposes a nested container of some other type. That
> looks like you could coax some Pythonic behavior out of the pattern,
> but how would you go about wrapping it? Do you have to copy the whole
> list for each request for the Python-wrapped sequence?

	No copy needed. You can implement the methods required for a
	sequence type and be a proxy between Python and the std::list.

> > Going back to const. If adding const meets the goal then PyCXX
> > should be changed. If it does not then I'd leave as is.
> 
> I think it meets the higher-level aim of making use of wrapped Python
> types "correct" in the C++ sense, which is consistent with aims like
> avoiding bald pointers, casting, and such.

	Agreed.

> -- 
> Steven E. Harris
> Primus Knowledge Solutions, Inc.
> http://www.primus.com
> 
> _______________________________________________
> C++-SIG maillist  -  C++-SIG at python.org
> http://www.python.org/mailman/listinfo/c++-sig
> 



From phil at geog.ubc.ca  Wed May 17 21:05:45 2000
From: phil at geog.ubc.ca (Phil Austin)
Date: Wed, 17 May 2000 12:05:45 -0700 (PDT)
Subject: [C++-SIG] setattr and CXX-4.2
In-Reply-To: <000101bfbf84$e5399e10$060210ac@private>
References: <14611.6532.303619.869769@brant.geog.ubc.ca>
	<000101bfbf84$e5399e10$060210ac@private>
Message-ID: <14626.60809.536767.140021@brant.geog.ubc.ca>

Barry Scott writes:
 > 
 > setattr is not allowed to create functions or mess up __methods__ so you simply
 > handle your non-function attributes and throw Py::NameError for all you know
 > nothing about.
 > 

Thanks, that lifted the fog a little.  Here's a couple of patches to
r.h and r.cxx that set an attribute, for the mailing list archive and, 
in case you want to expand the demo to exercise this:

*** r.h	2000/05/17 18:00:05	1.1
--- r.h	2000/05/17 18:20:51
***************
*** 8,13 ****
--- 8,15 ----
  
  // Making an extension object
  class r: public Py::PythonExtension<r> {
+ private:
+     Py::Object setme;  
  public:
      long	start;
      long	stop;
***************
*** 54,59 ****
--- 56,62 ----
      // override functions from PythonExtension
      virtual Py::Object repr();
      virtual Py::Object getattr( const char *name );
+     virtual int setattr( const char *name, const Py::Object & );
  
      virtual int sequence_length();
      virtual Py::Object sequence_item( int i );



*** r.cxx	2000/05/04 18:46:23	1.1
--- r.cxx	2000/05/17 18:36:18
***************
*** 43,51 ****
--- 43,66 ----
      if(std::string(name) == "start")
  		return Py::Int(start);
  
+     if(std::string(name) == "setme")
+ 		return setme;
+ 
      return getattr_methods( name );
  }
  
+ int r::setattr( const char *name,const Py::Object& rhs )
+ {
+ 
+    if(std::string(name) == "setme"){
+ 		setme=rhs;
+ 		return(0);
+    }
+ 
+    throw Py::AttributeError ("setAttr failed.");;
+ }
+ 
+ 
  // "regular" methods...
  Py::Object r::amethod( const Py::Tuple &t ) 
  {
***************
*** 81,86 ****
--- 96,102 ----
  	behaviors().doc("r objects: start, stop, step");
  	behaviors().supportRepr();
  	behaviors().supportGetattr();
+ 	behaviors().supportSetattr();
  	behaviors().supportSequenceType();
  
  	add_varargs_method("amethod", &r::amethod,


Python 1.5.2 (#2, Aug 26 1999, 22:59:52) [C] on sunos5
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import example
>>> my_r=example.r(1,12,4)
>>> my_r.setme
>>> my_r.setme=[1,2,3]
>>> my_r.setme
[1, 2, 3]



From phil at geog.ubc.ca  Wed May 17 22:41:54 2000
From: phil at geog.ubc.ca (Phil Austin)
Date: Wed, 17 May 2000 13:41:54 -0700 (PDT)
Subject: [C++-SIG] bug in setattr_handler?
In-Reply-To: <000101bfbf84$e5399e10$060210ac@private>
References: <14611.6532.303619.869769@brant.geog.ubc.ca>
	<000101bfbf84$e5399e10$060210ac@private>
Message-ID: <14627.1042.946962.536425@brant.geog.ubc.ca>

The example that I just circulated to demonstrate setattr 
threw an exception if the attribute wasn't found.  But the exception
is silently cleared in PythonType::setattr_handler:

*** cxx_extensions.cxx	2000/05/08 23:35:08	1.1
--- cxx_extensions.cxx	2000/05/17 20:38:29
***************
*** 353,359 ****
  		}
  	catch( Py::Exception & )
  		{
! 		return 0;
  		}
  	}
  
--- 353,360 ----
  		}
  	catch( Py::Exception & )
  		{
! 		  //return 0; ignore all exceptions??
! 		  return Py::Null();
  		}
  	}




From phil at geog.ubc.ca  Wed May 17 23:26:57 2000
From: phil at geog.ubc.ca (Phil Austin)
Date: Wed, 17 May 2000 14:26:57 -0700 (PDT)
Subject: [C++-SIG] Re: bug in setattr_handler?
In-Reply-To: <14627.1042.946962.536425@brant.geog.ubc.ca>
References: <14611.6532.303619.869769@brant.geog.ubc.ca>
	<000101bfbf84$e5399e10$060210ac@private>
	<14627.1042.946962.536425@brant.geog.ubc.ca>
Message-ID: <14627.3745.536762.448286@brant.geog.ubc.ca>

Phil Austin writes:
 >   		}
 >   	catch( Py::Exception & )
 >   		{
 > ! 		  //return 0; ignore all exceptions??
 > ! 		  return Py::Null();
 >   		}
 >   	}

Obviously -- this doesn't compile, given the signature
for setattr_handler. Since I don't understand why
these handlers catch the exceptions in the first place (instead
of letting them propagate), I'll let somebody
else propose the correct fix.

Regards, Phil






From barry at scottb.demon.co.uk  Wed May 17 23:47:27 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Wed, 17 May 2000 22:47:27 +0100
Subject: [C++-SIG] Re: bug in setattr_handler?
In-Reply-To: <14627.3745.536762.448286@brant.geog.ubc.ca>
Message-ID: <000d01bfc049$7e99fdb0$060210ac@private>

If we do not catch the exception Python will abort - remember that Python is C
code not C++ and cannot deal with exceptions.

The C++ exception will be converted into a Python exception.

If you test your setatr version of the example you should see the exception
in Python.

		BArry

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of Phil Austin
> Sent: 17 May 2000 22:27
> To: Barry Scott; c++-sig at python.org
> Subject: [C++-SIG] Re: bug in setattr_handler?
> 
> 
> Phil Austin writes:
>  >   		}
>  >   	catch( Py::Exception & )
>  >   		{
>  > ! 		  //return 0; ignore all exceptions??
>  > ! 		  return Py::Null();
>  >   		}
>  >   	}
> 
> Obviously -- this doesn't compile, given the signature
> for setattr_handler. Since I don't understand why
> these handlers catch the exceptions in the first place (instead
> of letting them propagate), I'll let somebody
> else propose the correct fix.
> 
> Regards, Phil
> 
> 
> 
> 
> _______________________________________________
> C++-SIG maillist  -  C++-SIG at python.org
> http://www.python.org/mailman/listinfo/c++-sig
> 



From sharris at primus.com  Thu May 18 19:49:29 2000
From: sharris at primus.com (Steve Harris)
Date: 18 May 2000 10:49:29 -0700
Subject: [C++-SIG] Py::String should be constructible from ptr and length
Message-ID: <sv3dnfhhp2.fsf@hodge.primus.com>

At present, class Py::String can be constructed from a const char* or
a const std::string&, but not from const char* and a size_t. We should
have a version available that takes advantage of
PyString_FromStringAndSize() by taking a length argument. This would
allow construction from a non-null-terminated character array
(especially a subset of such an array).

Also, the Py::String constructor taking a const std::string& as an
argument should not use the c_str() function to call
PyString_FromString(). Rather, it should call

  PyString_FromStringAndSize( str.data(), str.length() ) // or str.size()

since we've already gone through the trouble of figuring out the
length of the contained string.

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com



From phil at geog.ubc.ca  Thu May 18 20:20:16 2000
From: phil at geog.ubc.ca (Phil Austin)
Date: Thu, 18 May 2000 11:20:16 -0700 (PDT)
Subject: [C++-SIG] Re: bug in setattr_handler?
In-Reply-To: <000d01bfc049$7e99fdb0$060210ac@private>
References: <14627.3745.536762.448286@brant.geog.ubc.ca>
	<000d01bfc049$7e99fdb0$060210ac@private>
Message-ID: <14628.13408.556677.50614@brant.geog.ubc.ca>

Barry Scott writes:

 > If you test your setatr version of the example you should see the exception
 > in Python.
 > 

Right, returning -1 from setattr_handler did the trick.  I guess this
need to be changed on all the handlers that return int or long?

Regards Phil.




From sharris at nospam.primus.com  Fri May 19 18:53:19 2000
From: sharris at nospam.primus.com (Steven E. Harris)
Date: 19 May 2000 09:53:19 -0700
Subject: [C++-SIG] Re: C++ extension module crashes on Solaris
References: <BAEMJNPFHMFPEFAGBKKACEMICBAA.dan@cgsoftware.com>
Message-ID: <svaehmfpmo.fsf@hodge.primus.com>

The following message is a courtesy copy of an article
that has been posted to comp.lang.python as well.

"Daniel Berlin" <dan at cgsoftware.com> writes:

[...]

> No offense Guido, but you are probably completely off base.
> I'll put money it's a shared library problem.

[...]

Yes, well, I took Guido's advice and rebuilt Python without threading
support enabled. My goal (and problem, I belive) have nothing to do
with threading. I'll re-start from the beginning.

Following the instructions for the CXX kit, I set two environment
variables prior to configuring Python:

LINKCC    g++
LDSHARED  g++ -shared

I'm not entirely sure why this is necessary. If it's not, please
advise.

I ran the configure script as

$ ./configure --prefix=/users/sharris/usr/local

Everything configured fine, so I ran make, make test, and make
install. Next, I copied the file <pysrc>/Misc/Makefile.pre.in into my
module build directory and followed the directions in the Python
doc. called "Building C and C++ Extensions on Unix." My Setup file
looks like this (continuation lines for clarity here):

==================================================
# seh_test setup file
*shared*

CCC=g++

seh_test -I../Include \
         pod.cc \
         pypod.cc \
         seh_test.cc \
         ../Src/cxx_extensions.cxx \
         ../Src/cxxextensions.c \
         ../Src/cxxsupport.cxx
==================================================


A note about the directory structure context - it looks like this:


~/temp
      /Python-1.5.2         <== Python build tree (now installed)
      /CXX-4.2
              /Src          <== CXX source files
              /Include      <== CXX includes
              /seh_test     <== My test module stuff using CXX


My module builds okay, as evidenced here (again, line wraps are mine):

$ make
g++ -I../Include -g -O2 \
  -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
  -c./pod.cc
g++ -I../Include -g -O2 \
  -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
  -c ./pypod.cc
g++ -I../Include -g -O2 \
  -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
  -c ./seh_test.cc
g++ -I../Include -g -O2 \
  -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
  -c ./../Src/cxx_extensions.cxx
gcc -I../Include -g -O2 \
  -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
  -c ./../Src/cxxextensions.c
g++ -I../Include -g -O2 \
  -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
  -c ./../Src/cxxsupport.cxx
g++ -shared \
  pod.o pypod.o seh_test.o \
  cxx_extensions.o cxxextensions.o cxxsupport.o \
  -o seh_test.so


Next, I copy the built module into place and try to import it:

$ cp seh_test.so ~/usr/local/lib/python1.5/
$ python
Python 1.5.2 (#14, May 19 2000, 00:04:52)  [GCC 2.95.2 19991024 (release)] on sunos5
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import seh_test
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ImportError: ld.so.1: python: fatal: relocation error: file ./seh_test.so: symbol PyExc_IndexError: referenced symbol not found
>>>


Sigh. Okay, so I looked around on Deja for something relevant to this
error until I almost fell asleep, and finally found this suggestion:

Try passing the flags '-Wl,-E' to the linker.
http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=481811059&search=thread&threaded=1


So I reset the LDSHARED environment variable to 'g++ -shared -Wl,-E',
tore down the previous Python build, reconfigured it, and rebuilt it.

Python built and tested fine just like the last build. Looking over
the build output, it doesn't look like those linker options every got
used, since there weren't any shared objects getting built.

Finally, I tried rebuilding my test module, forcing the '-Wl,-E' flag
into the link line:

$ cp ~/temp/Python-1.5.2/Misc/Makefile.pre.in ./
$ make -f Makefile.pre.in boot LDSHARED='g++ -shared -Wl,-E'
$ make
g++ -I../Include -g -O2 \
  -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
  -c./pod.cc
g++ -I../Include -g -O2 \
  -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
  -c ./pypod.cc
g++ -I../Include -g -O2 \
  -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
  -c ./seh_test.cc
g++ -I../Include -g -O2 \
  -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
  -c ./../Src/cxx_extensions.cxx
gcc -I../Include -g -O2 \
  -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
  -c ./../Src/cxxextensions.c
g++ -I../Include -g -O2 \
  -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
  -c ./../Src/cxxsupport.cxx
g++ -shared -Wl,-E \
  pod.o pypod.o seh_test.o \
  cxx_extensions.o cxxextensions.o cxxsupport.o \
  -o seh_test.so


Again, I copy the (re)built module into place and try to import it:

$ cp seh_test.so ~/usr/local/lib/python1.5/
$ python
Python 1.5.2 (#1, May 19 2000, 09:34:45)  [GCC 2.95.2 19991024 (release)] on sunos5
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import seh_test
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ImportError: ld.so.1: python: fatal: relocation error: file ./seh_test.so: symbol PyExc_IndexError: referenced symbol not found
>>>


Note that I can compile and use the CXX Demo application, which uses
both extension and embedding together. I can't get extending to work
alone, though.

What additional information can I provide to get some suggestions?

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com



From phil at geog.ubc.ca  Fri May 19 19:21:47 2000
From: phil at geog.ubc.ca (Phil Austin)
Date: Fri, 19 May 2000 10:21:47 -0700 (PDT)
Subject: [C++-SIG] Re: C++ extension module crashes on Solaris
In-Reply-To: <svaehmfpmo.fsf@hodge.primus.com>
References: <BAEMJNPFHMFPEFAGBKKACEMICBAA.dan@cgsoftware.com>
	<svaehmfpmo.fsf@hodge.primus.com>
Message-ID: <14629.30763.273115.778106@brant.geog.ubc.ca>

Steven E. Harris writes:
 > 
 > What additional information can I provide to get some suggestions?
 > 
 > -- 

Did you wind up having to move to the March 2000 g++ snapshot to solve your
earlier problems with example.cxx?

Phil



From jlj at cfdrc.com  Fri May 19 20:39:14 2000
From: jlj at cfdrc.com (Lyle Johnson)
Date: Fri, 19 May 2000 13:39:14 -0500
Subject: [C++-SIG] Re: C++ extension module crashes on Solaris
In-Reply-To: <svaehmfpmo.fsf@hodge.primus.com>
Message-ID: <000201bfc1c1$88534270$4e574dc0@cfdrc.com>

Steven,

I'm coming into this thread a little late and so I hope I'm not repeating
advice you've already heard and tried. When I compile C++ in general for use
as a Python extension module, I use these flags to compile the individual
files:

	g++ -fPIC -c file1.cpp
	g++ -fPIC -c file2.cpp

and then for the link step:

	g++ -Wl,-E -shared -o seh_test.so file1.o file2.o ...

I noticed in particular that you are not using the "-fPIC" flag for the
compile step. I know that this is REQUIRED on most platforms for this to
work properly, so it might be the missing piece of the puzzle in your case.

Apologies in advance if this is a false lead. I'm not using CXX but am
(successfully) compiling C++ code into Python extensions, using g++.

Lyle

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of Steven E. Harris
> Sent: Friday, May 19, 2000 11:53 AM
> Cc: c++-sig at python.org
> Subject: [C++-SIG] Re: C++ extension module crashes on Solaris
>
>
> The following message is a courtesy copy of an article
> that has been posted to comp.lang.python as well.
>
> "Daniel Berlin" <dan at cgsoftware.com> writes:
>
> [...]
>
> > No offense Guido, but you are probably completely off base.
> > I'll put money it's a shared library problem.
>
> [...]
>
> Yes, well, I took Guido's advice and rebuilt Python without threading
> support enabled. My goal (and problem, I belive) have nothing to do
> with threading. I'll re-start from the beginning.
>
> Following the instructions for the CXX kit, I set two environment
> variables prior to configuring Python:
>
> LINKCC    g++
> LDSHARED  g++ -shared
>
> I'm not entirely sure why this is necessary. If it's not, please
> advise.
>
> I ran the configure script as
>
> $ ./configure --prefix=/users/sharris/usr/local
>
> Everything configured fine, so I ran make, make test, and make
> install. Next, I copied the file <pysrc>/Misc/Makefile.pre.in into my
> module build directory and followed the directions in the Python
> doc. called "Building C and C++ Extensions on Unix." My Setup file
> looks like this (continuation lines for clarity here):
>
> ==================================================
> # seh_test setup file
> *shared*
>
> CCC=g++
>
> seh_test -I../Include \
>          pod.cc \
>          pypod.cc \
>          seh_test.cc \
>          ../Src/cxx_extensions.cxx \
>          ../Src/cxxextensions.c \
>          ../Src/cxxsupport.cxx
> ==================================================
>
>
> A note about the directory structure context - it looks like this:
>
>
> ~/temp
>       /Python-1.5.2         <== Python build tree (now installed)
>       /CXX-4.2
>               /Src          <== CXX source files
>               /Include      <== CXX includes
>               /seh_test     <== My test module stuff using CXX
>
>
> My module builds okay, as evidenced here (again, line wraps are mine):
>
> $ make
> g++ -I../Include -g -O2 \
>   -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
>   -c./pod.cc
> g++ -I../Include -g -O2 \
>   -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
>   -c ./pypod.cc
> g++ -I../Include -g -O2 \
>   -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
>   -c ./seh_test.cc
> g++ -I../Include -g -O2 \
>   -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
>   -c ./../Src/cxx_extensions.cxx
> gcc -I../Include -g -O2 \
>   -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
>   -c ./../Src/cxxextensions.c
> g++ -I../Include -g -O2 \
>   -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
>   -c ./../Src/cxxsupport.cxx
> g++ -shared \
>   pod.o pypod.o seh_test.o \
>   cxx_extensions.o cxxextensions.o cxxsupport.o \
>   -o seh_test.so
>
>
> Next, I copy the built module into place and try to import it:
>
> $ cp seh_test.so ~/usr/local/lib/python1.5/
> $ python
> Python 1.5.2 (#14, May 19 2000, 00:04:52)  [GCC 2.95.2 19991024
> (release)] on sunos5
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> import seh_test
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> ImportError: ld.so.1: python: fatal: relocation error: file
> ./seh_test.so: symbol PyExc_IndexError: referenced symbol not found
> >>>
>
>
> Sigh. Okay, so I looked around on Deja for something relevant to this
> error until I almost fell asleep, and finally found this suggestion:
>
> Try passing the flags '-Wl,-E' to the linker.
> http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=481811059&search=threa
> d&threaded=1
>
>
> So I reset the LDSHARED environment variable to 'g++ -shared -Wl,-E',
> tore down the previous Python build, reconfigured it, and rebuilt it.
>
> Python built and tested fine just like the last build. Looking over
> the build output, it doesn't look like those linker options every got
> used, since there weren't any shared objects getting built.
>
> Finally, I tried rebuilding my test module, forcing the '-Wl,-E' flag
> into the link line:
>
> $ cp ~/temp/Python-1.5.2/Misc/Makefile.pre.in ./
> $ make -f Makefile.pre.in boot LDSHARED='g++ -shared -Wl,-E'
> $ make
> g++ -I../Include -g -O2 \
>   -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
>   -c./pod.cc
> g++ -I../Include -g -O2 \
>   -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
>   -c ./pypod.cc
> g++ -I../Include -g -O2 \
>   -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
>   -c ./seh_test.cc
> g++ -I../Include -g -O2 \
>   -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
>   -c ./../Src/cxx_extensions.cxx
> gcc -I../Include -g -O2 \
>   -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
>   -c ./../Src/cxxextensions.c
> g++ -I../Include -g -O2 \
>   -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
>   -c ./../Src/cxxsupport.cxx
> g++ -shared -Wl,-E \
>   pod.o pypod.o seh_test.o \
>   cxx_extensions.o cxxextensions.o cxxsupport.o \
>   -o seh_test.so
>
>
> Again, I copy the (re)built module into place and try to import it:
>
> $ cp seh_test.so ~/usr/local/lib/python1.5/
> $ python
> Python 1.5.2 (#1, May 19 2000, 09:34:45)  [GCC 2.95.2 19991024
> (release)] on sunos5
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> import seh_test
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> ImportError: ld.so.1: python: fatal: relocation error: file
> ./seh_test.so: symbol PyExc_IndexError: referenced symbol not found
> >>>
>
>
> Note that I can compile and use the CXX Demo application, which uses
> both extension and embedding together. I can't get extending to work
> alone, though.
>
> What additional information can I provide to get some suggestions?
>
> --
> Steven E. Harris
> Primus Knowledge Solutions, Inc.
> http://www.primus.com
>
> _______________________________________________
> C++-SIG maillist  -  C++-SIG at python.org
> http://www.python.org/mailman/listinfo/c++-sig
>




From phil at geog.ubc.ca  Fri May 19 20:45:57 2000
From: phil at geog.ubc.ca (Phil Austin)
Date: Fri, 19 May 2000 11:45:57 -0700 (PDT)
Subject: [C++-SIG] Re: C++ extension module crashes on Solaris
In-Reply-To: <000201bfc1c1$88534270$4e574dc0@cfdrc.com>
References: <svaehmfpmo.fsf@hodge.primus.com>
	<000201bfc1c1$88534270$4e574dc0@cfdrc.com>
Message-ID: <14629.35813.863361.548886@brant.geog.ubc.ca>

 > 
 > I noticed in particular that you are not using the "-fPIC" flag for the
 > compile step. I know that this is REQUIRED on most platforms for this to
 > work properly, so it might be the missing piece of the puzzle in your case.
 > 

It also might be worth checking to see whether your copy of python
really does have PyExc_IndexError defined:

<peacock ~/lib/python/solaris> nm python | grep PyExc_IndexError
[2709]	|    825580|       4|OBJT |GLOB |0    |21     |PyExc_IndexError


Phil



From sharris at primus.com  Fri May 19 22:01:35 2000
From: sharris at primus.com (Steve Harris)
Date: 19 May 2000 13:01:35 -0700
Subject: [C++-SIG] Re: C++ extension module crashes on Solaris
In-Reply-To: Phil Austin's message of "Fri, 19 May 2000 10:21:47 -0700 (PDT)"
References: <BAEMJNPFHMFPEFAGBKKACEMICBAA.dan@cgsoftware.com>
	<svaehmfpmo.fsf@hodge.primus.com>
	<14629.30763.273115.778106@brant.geog.ubc.ca>
Message-ID: <sv3dnefgww.fsf@hodge.primus.com>

Phil Austin <phil at geog.ubc.ca> writes:

[...]

> Did you wind up having to move to the March 2000 g++ snapshot to solve your
> earlier problems with example.cxx?

No, we recompiled the 2.95.2 release to use Gnu binutils, rather than
the default Solaris tools. That seemed to do the trick.

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com



From sharris at primus.com  Fri May 19 22:03:17 2000
From: sharris at primus.com (Steve Harris)
Date: 19 May 2000 13:03:17 -0700
Subject: [C++-SIG] Re: C++ extension module crashes on Solaris
In-Reply-To: Phil Austin's message of "Fri, 19 May 2000 11:45:57 -0700 (PDT)"
References: <svaehmfpmo.fsf@hodge.primus.com>
	<000201bfc1c1$88534270$4e574dc0@cfdrc.com>
	<14629.35813.863361.548886@brant.geog.ubc.ca>
Message-ID: <svya56e29m.fsf@hodge.primus.com>

Phil Austin <phil at geog.ubc.ca> writes:

[...]

> It also might be worth checking to see whether your copy of python
> really does have PyExc_IndexError defined:

$ nm ~/usr/local/bin/python | egrep 'IndexError'
[2971]  |    704664|       4|OBJT |GLOB |0    |19     |PyExc_IndexError

Yep, got that. I'm going to go try the fPIC option. Must Python be
recompiled with that option, or just my extension module?

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com



From sharris at primus.com  Fri May 19 22:22:36 2000
From: sharris at primus.com (Steve Harris)
Date: 19 May 2000 13:22:36 -0700
Subject: [C++-SIG] Re: C++ extension module crashes on Solaris
In-Reply-To: "Lyle Johnson"'s message of "Fri, 19 May 2000 13:39:14 -0500"
References: <000201bfc1c1$88534270$4e574dc0@cfdrc.com>
Message-ID: <svu2fue1df.fsf@hodge.primus.com>

"Lyle Johnson" <jlj at cfdrc.com> writes:

[...]

> I use these flags to compile the individual files:
> 
> 	g++ -fPIC -c file1.cpp
> 	g++ -fPIC -c file2.cpp
> 
> and then for the link step:
> 
> 	g++ -Wl,-E -shared -o seh_test.so file1.o file2.o ...
> 
> I noticed in particular that you are not using the "-fPIC" flag for
> the compile step. I know that this is REQUIRED on most platforms for
> this to work properly, so it might be the missing piece of the
> puzzle in your case.

I didn't recompile Python yet, but I did rebuild my extension module
and got a similar, but different result:


$ make
g++ -fPIC -I../Include -g -O2 \
  -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
  -c ./pod.cc
g++ -fPIC -I../Include -g -O2 \
  -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
  -c ./pypod.cc
g++ -fPIC -I../Include -g -O2 \
  -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
  -c ./seh_test.cc
g++ -fPIC -I../Include -g -O2 \
  -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
  -c ./../Src/cxx_extensions.cxx
gcc -I../Include -g -O2 \
  -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
  -c ./../Src/cxxextensions.c
g++ -fPIC -I../Include -g -O2 \
  -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
  -c ./../Src/cxxsupport.cxx
g++ -shared -Wl,-E  \
  pod.o pypod.o seh_test.o \
  cxx_extensions.o cxxextensions.o cxxsupport.o \
  -o seh_test.so

$ cp seh_test.so ~/usr/local/lib/python1.5/
$ python
Python 1.5.2 (#1, May 19 2000, 09:34:45)  [GCC 2.95.2 19991024 (release)] on sunos5
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import seh_test
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ImportError: ld.so.1: python: fatal: relocation error: file ./seh_test.so: symbol PyExc_RuntimeError: referenced symbol not found
>>>


Note that this time, it's the symbol PyExc_RuntimeError that's causing
the problem.

Does it matter that the gcc line above (for ../Src/cxxextensions.c)
doesn't have the 'fPIC' option on it?

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com



From furnish at actel.com  Fri May 19 22:50:24 2000
From: furnish at actel.com (Geoffrey Furnish)
Date: Fri, 19 May 2000 13:50:24 -0700 (PDT)
Subject: [C++-SIG] Re: C++ extension module crashes on Solaris
In-Reply-To: <svu2fue1df.fsf@hodge.primus.com>
References: <000201bfc1c1$88534270$4e574dc0@cfdrc.com>
	<svu2fue1df.fsf@hodge.primus.com>
Message-ID: <14629.43280.621750.626706@zork.amer.actel.com>

Okay, I'm not an expert on these issues either, but let me offer some
thoughts.

First, it is absolutely necessary that shared things (shared libs,
dynloadable modules) must be compiled with position independent code.
In this case, that means that Python itself does not have to be
compiledwith PIC, but the loadable extensions modules /do/ /have/ to
be compiled with -fPIC.  ("-fPIC" is the gcc option, some other vendor 
compilers have called this "-z" and probably other variants.)

Secondly, the loadable extesnion module itself has external symbol
references that must be bound when the module is loaded.  One way to
do this, such as is often used when building a shared library (or a "dso"
on Irix, for example), is to actually link the shared lib against
other shared libs.  Your resulting libXYZ.so in such a case, will
typically have bound into it, the information that the dynamic loader
would need in order to resolve outstanding references.  In such a
case, linking an app against this .so would implicilty result in other 
.so's (the ones your .so was linked against) getting pulled into the
client app.

This case is different.  you aren't building a shared lib, and your
link line doesn't link your extension module against any shared libs.
Instead, you are expecting to pick up your missing external symbols by 
having them bound against the symbols in the enclsoing process
context.  i.e., Python itself.

In order for this to work, some systems (I don't know whether Slowaris 
is like this or not, but some are, so it might be) require that the
host application must "export symbols" so that the dynamic loader can
consider them candidates for symbol resolution when dso's are
dynloaded. 

In other words:
   link your Python with "-Wl,-E" (but it doesn't have to 
	be compiled -fPIC)
   Compile your extension module with -fPIC, lijnke with -shared.

It seems you're now doing this last step, but I don't think we've seen 
from the info presented earlier if you're doing the first step.

BTW, some compilers call this "-export-dynamic" instead of making you
pass bizarre options to the linker as in "-Wl,-E".

Hope this helps.  Of course, I might be out to lunch on this one...  :-).

Steve Harris writes:
 > "Lyle Johnson" <jlj at cfdrc.com> writes:
 > 
 > [...]
 > 
 > > I use these flags to compile the individual files:
 > > 
 > > 	g++ -fPIC -c file1.cpp
 > > 	g++ -fPIC -c file2.cpp
 > > 
 > > and then for the link step:
 > > 
 > > 	g++ -Wl,-E -shared -o seh_test.so file1.o file2.o ...
 > > 
 > > I noticed in particular that you are not using the "-fPIC" flag for
 > > the compile step. I know that this is REQUIRED on most platforms for
 > > this to work properly, so it might be the missing piece of the
 > > puzzle in your case.
 > 
 > I didn't recompile Python yet, but I did rebuild my extension module
 > and got a similar, but different result:
 > 
 > 
 > $ make
 > g++ -fPIC -I../Include -g -O2 \
 >   -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
 >   -c ./pod.cc
 > g++ -fPIC -I../Include -g -O2 \
 >   -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
 >   -c ./pypod.cc
 > g++ -fPIC -I../Include -g -O2 \
 >   -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
 >   -c ./seh_test.cc
 > g++ -fPIC -I../Include -g -O2 \
 >   -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
 >   -c ./../Src/cxx_extensions.cxx
 > gcc -I../Include -g -O2 \
 >   -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
 >   -c ./../Src/cxxextensions.c
 > g++ -fPIC -I../Include -g -O2 \
 >   -I/users/sharris/usr/local/include/python1.5 -DHAVE_CONFIG_H \
 >   -c ./../Src/cxxsupport.cxx
 > g++ -shared -Wl,-E  \
 >   pod.o pypod.o seh_test.o \
 >   cxx_extensions.o cxxextensions.o cxxsupport.o \
 >   -o seh_test.so
 > 
 > $ cp seh_test.so ~/usr/local/lib/python1.5/
 > $ python
 > Python 1.5.2 (#1, May 19 2000, 09:34:45)  [GCC 2.95.2 19991024 (release)] on sunos5
 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
 > >>> import seh_test
 > Traceback (innermost last):
 >   File "<stdin>", line 1, in ?
 > ImportError: ld.so.1: python: fatal: relocation error: file ./seh_test.so: symbol PyExc_RuntimeError: referenced symbol not found
 > >>>
 > 
 > 
 > Note that this time, it's the symbol PyExc_RuntimeError that's causing
 > the problem.
 > 
 > Does it matter that the gcc line above (for ../Src/cxxextensions.c)
 > doesn't have the 'fPIC' option on it?
 > 
 > -- 
 > Steven E. Harris
 > Primus Knowledge Solutions, Inc.
 > http://www.primus.com
 > 
 > _______________________________________________
 > C++-SIG maillist  -  C++-SIG at python.org
 > http://www.python.org/mailman/listinfo/c++-sig
 > 



From sharris at primus.com  Fri May 19 22:54:32 2000
From: sharris at primus.com (Steve Harris)
Date: 19 May 2000 13:54:32 -0700
Subject: [C++-SIG] Re: C++ extension module crashes on Solaris
In-Reply-To: Geoffrey Furnish's message of "Fri, 19 May 2000 13:50:24 -0700 (PDT)"
References: <000201bfc1c1$88534270$4e574dc0@cfdrc.com>
	<svu2fue1df.fsf@hodge.primus.com>
	<14629.43280.621750.626706@zork.amer.actel.com>
Message-ID: <svpuqidzw7.fsf@hodge.primus.com>

Geoffrey Furnish <furnish at actel.com> writes:

[...]

> This case is different.  you aren't building a shared lib, and your
> link line doesn't link your extension module against any shared libs.
> Instead, you are expecting to pick up your missing external symbols by 
> having them bound against the symbols in the enclsoing process
> context.  i.e., Python itself.

I find the situation here a little weird too, but I'm trying to follow
the "supported Python way" by using the Setup file and
Makefile.pre.in, which apparently advocates this system.

> In order for this to work, some systems (I don't know whether Slowaris 
> is like this or not, but some are, so it might be) require that the
> host application must "export symbols" so that the dynamic loader can
> consider them candidates for symbol resolution when dso's are
> dynloaded. 
> 
> In other words:
>    link your Python with "-Wl,-E" (but it doesn't have to 
> 	be compiled -fPIC)
>    Compile your extension module with -fPIC, lijnke with -shared.
> 
> It seems you're now doing this last step, but I don't think we've seen 
> from the info presented earlier if you're doing the first step.

Maybe you didn't catch the end of my first post. I did build my Python
with the '-Wl,-E', but I never saw those options actually get used in
the build. I pushed the options into my LDSHARED environment variable
before running configure. I can tell that those options did get
captured in the Makefile. It seems that by default the Python build
doesn't create any shared objects, so maybe that's why my LDSHARED
options never came into play.

Should I be trying to get the '-Wl,-E' option crammed into some other
build-time variable? I'm sorry, but I'm not sure I understand which
parts of the system will wind up caring about those options.

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com



From furnish at actel.com  Fri May 19 23:35:37 2000
From: furnish at actel.com (Geoffrey Furnish)
Date: Fri, 19 May 2000 14:35:37 -0700 (PDT)
Subject: [C++-SIG] Re: C++ extension module crashes on Solaris
In-Reply-To: <svpuqidzw7.fsf@hodge.primus.com>
References: <000201bfc1c1$88534270$4e574dc0@cfdrc.com>
	<svu2fue1df.fsf@hodge.primus.com>
	<14629.43280.621750.626706@zork.amer.actel.com>
	<svpuqidzw7.fsf@hodge.primus.com>
Message-ID: <14629.45993.204476.322023@zork.amer.actel.com>

 > Maybe you didn't catch the end of my first post. I did build my Python
 > with the '-Wl,-E', but I never saw those options actually get used in
 > the build. I pushed the options into my LDSHARED environment variable
 > before running configure. I can tell that those options did get
 > captured in the Makefile. It seems that by default the Python build
 > doesn't create any shared objects, so maybe that's why my LDSHARED
 > options never came into play.
 > 
 > Should I be trying to get the '-Wl,-E' option crammed into some other
 > build-time variable? I'm sorry, but I'm not sure I understand which
 > parts of the system will wind up caring about those options.

You need to make sure they got used when doing the final link step of
Python.  You could check this by just rm'ing python, and then typing
make again.  This will just run the final link step, and it will be
easy to see /exactly/ what got done.  -Wl,-E needs to be there.  If
it's not, trying just pasting in the link line by hand, adding the
options, and then seeing if this python can import your .so.

I don't know how to influence the "standard stuff" very well, maybe
others can respond on this point.

-- 
Geoffrey Furnish            Actel Corporation        furnish at actel.com
Senior Staff Engineer      955 East Arques Ave       voice: 408-522-7528
Placement & Routing     Sunnyvale, CA   94086-4533   fax:   408-522-8041

"... because only those who write the code truly control the project."
						      -- Jamie Zawinski



From Thomas.Malik at t-online.de  Sat May 20 15:51:27 2000
From: Thomas.Malik at t-online.de (Thomas Malik)
Date: Sat, 20 May 2000 15:51:27 +0200
Subject: [C++-SIG] Re: C++ extension module crashes on Solaris
References: <000201bfc1c1$88534270$4e574dc0@cfdrc.com><svu2fue1df.fsf@hodge.primus.com> <14629.43280.621750.626706@zork.amer.actel.com>
Message-ID: <002001bfc262$7f179a20$71d29e3e@mjrtom>

Von: Geoffrey Furnish <furnish at actel.com>
Betreff: Re: [C++-SIG] Re: C++ extension module crashes on Solaris


> First, it is absolutely necessary that shared things (shared libs,
> dynloadable modules) must be compiled with position independent code.

That's untrue, basically. I'm using shared C++ modules without this option
happily, and it works perfectly.





From sharris at nospam.primus.com  Mon May 22 04:18:04 2000
From: sharris at nospam.primus.com (Steven E. Harris)
Date: 21 May 2000 19:18:04 -0700
Subject: [C++-SIG] Re: C++ extension module crashes on Solaris
In-Reply-To: Guido van Rossum's message of "Sat, 20 May 2000 02:42:49 GMT"
References: <BAEMJNPFHMFPEFAGBKKACEMICBAA.dan@cgsoftware.com> <svaehmfpmo.fsf@hodge.primus.com> <cpn1llvks5.fsf@cj20424-a.reston1.va.home.com>
Message-ID: <svwvknl44j.fsf@hodge.primus.com>

The following message is a courtesy copy of an article
that has been posted to comp.lang.python as well.

Guido van Rossum <guido at python.org> writes:

> It seems your shared library module doesn't see the symbols defined by
> the Python main app.  Normally, these are being exported by default.
> I wonder if the trick of using g++ for the linker breaks this?

Yes, that turned out the to be the problem. I will take some time on
Monday to prepare a more complete summary of what I learned (based
upon _lots_ of helpful contributions), but to summarize:

* Python must be linked with the option '-Wl,-E' passed to the linker.
  (That is, on Solaris, using g++, with the GNU binutils package.)

Other advice involving compiling the extension with '-fPIC' also
seemed relevant, but turned out to not make any difference. Now I'm
not sure why '-fPIC' _isn't_ required!

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com



From harri.pasanen at trema.com  Mon May 22 09:02:53 2000
From: harri.pasanen at trema.com (Harri Pasanen)
Date: Mon, 22 May 2000 09:02:53 +0200
Subject: [C++-SIG] Re: C++ extension module crashes on Solaris
References: <20000519213546.20E4B1CD27@dinsdale.python.org>
Message-ID: <3928DB9D.305A9A09@trema.com>


> 
> Message: 10
> From: Geoffrey Furnish <furnish at actel.com>
> Date: Fri, 19 May 2000 14:35:37 -0700 (PDT)
> To: Steve Harris <sharris at primus.com>
> Cc: c++-sig at python.org
> Subject: Re: [C++-SIG] Re: C++ extension module crashes on Solaris
> <svu2fue1df.fsf at hodge.primus.com>
> <14629.43280.621750.626706 at zork.amer.actel.com>
> <svpuqidzw7.fsf at hodge.primus.com>
> 
>  > Maybe you didn't catch the end of my first post. I did build my Python
>  > with the '-Wl,-E', but I never saw those options actually get used in
>  > the build. I pushed the options into my LDSHARED environment variable
>  > before running configure. I can tell that those options did get
>  > captured in the Makefile. It seems that by default the Python build
>  > doesn't create any shared objects, so maybe that's why my LDSHARED
>  > options never came into play.
>  >
>  > Should I be trying to get the '-Wl,-E' option crammed into some other
>  > build-time variable? I'm sorry, but I'm not sure I understand which
>  > parts of the system will wind up caring about those options.
> 
> You need to make sure they got used when doing the final link step of
> Python.  You could check this by just rm'ing python, and then typing
> make again.  This will just run the final link step, and it will be
> easy to see /exactly/ what got done.  -Wl,-E needs to be there.  If
> it's not, trying just pasting in the link line by hand, adding the
> options, and then seeing if this python can import your .so.
> 
> I don't know how to influence the "standard stuff" very well, maybe
> others can respond on this point.
> 

There is a buglet in the configure script for standard Python 1.5.2. If
gcc 2.95.2 is used on Solaris to build Python itself, -Wl,-E flags
indeed don't get passed to linker when python executable is linked.

I've mailed a patch against this one to Guido a couple of months ago,
which he accepted.   So if you grab the Python 1.5.2 from CVS the
problem should be solved.

Regards,

Harri



From sharris at primus.com  Mon May 22 18:52:26 2000
From: sharris at primus.com (Steve Harris)
Date: 22 May 2000 09:52:26 -0700
Subject: [C++-SIG] Re: C++ extension module crashes on Solaris
In-Reply-To: Harri Pasanen's message of "Mon, 22 May 2000 09:02:53 +0200"
References: <20000519213546.20E4B1CD27@dinsdale.python.org>
	<3928DB9D.305A9A09@trema.com>
Message-ID: <svn1lia5o5.fsf@hodge.primus.com>

Harri Pasanen <harri.pasanen at trema.com> writes:

> There is a buglet in the configure script for standard Python 1.5.2. If
> gcc 2.95.2 is used on Solaris to build Python itself, -Wl,-E flags
> indeed don't get passed to linker when python executable is linked.
> 
> I've mailed a patch against this one to Guido a couple of months ago,
> which he accepted.   So if you grab the Python 1.5.2 from CVS the
> problem should be solved.

The workaround I found is to set the LDFLAGS environment variable to
'-Wl,-E' before running configure.

I also noticed that if you don't set the CCC environment variable to
something sensible (like 'g++'), the Makefile generated by
Makefile.pre.in for extension modules will fail.

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com



From barry at scottb.demon.co.uk  Mon May 22 20:03:40 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Mon, 22 May 2000 19:03:40 +0100
Subject: [C++-SIG] Py::String should be constructible from ptr and length
In-Reply-To: <sv3dnfhhp2.fsf@hodge.primus.com>
Message-ID: <000601bfc418$0f5dd4d0$060210ac@private>

These c'tor's have been in CXX for a while but did not make it into
the first cut of checkins to SourceForge. THe c'tor's have been on
SourceForge for a couple of weeks now.

However as you suggest I should use
std::string::size() and std::string::data() rather then c_str()
and the implied strlen() call.

These improvements have been committed to SourceForge.

		Barry


> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of Steve Harris
> Sent: 18 May 2000 18:49
> To: c++-sig at python.org
> Subject: [C++-SIG] Py::String should be constructible from ptr and
> length
> 
> 
> At present, class Py::String can be constructed from a const char* or
> a const std::string&, but not from const char* and a size_t. We should
> have a version available that takes advantage of
> PyString_FromStringAndSize() by taking a length argument. This would
> allow construction from a non-null-terminated character array
> (especially a subset of such an array).
> 
> Also, the Py::String constructor taking a const std::string& as an
> argument should not use the c_str() function to call
> PyString_FromString(). Rather, it should call
> 
>   PyString_FromStringAndSize( str.data(), str.length() ) // or str.size()
> 
> since we've already gone through the trouble of figuring out the
> length of the contained string.
> 
> -- 
> Steven E. Harris
> Primus Knowledge Solutions, Inc.
> http://www.primus.com
> 
> _______________________________________________
> C++-SIG maillist  -  C++-SIG at python.org
> http://www.python.org/mailman/listinfo/c++-sig
> 



From barry at scottb.demon.co.uk  Mon May 22 20:05:44 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Mon, 22 May 2000 19:05:44 +0100
Subject: [C++-SIG] Re: bug in setattr_handler?
In-Reply-To: <14628.13408.556677.50614@brant.geog.ubc.ca>
Message-ID: <000701bfc418$5979d8c0$060210ac@private>

I have commited to SOurceForge the fixes to return values from the handler functions.

Exceptions show up straight away how.

		BArry


> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of Phil Austin
> Sent: 18 May 2000 19:20
> To: Barry Scott
> Cc: Python C++-Sig
> Subject: RE: [C++-SIG] Re: bug in setattr_handler?
> 
> 
> Barry Scott writes:
> 
>  > If you test your setatr version of the example you should see the exception
>  > in Python.
>  > 
> 
> Right, returning -1 from setattr_handler did the trick.  I guess this
> need to be changed on all the handlers that return int or long?
> 
> Regards Phil.
> 
> 
> _______________________________________________
> C++-SIG maillist  -  C++-SIG at python.org
> http://www.python.org/mailman/listinfo/c++-sig
> 



From sharris at primus.com  Mon May 22 20:53:24 2000
From: sharris at primus.com (Steve Harris)
Date: 22 May 2000 11:53:24 -0700
Subject: [C++-SIG] Trouble getting a method called
Message-ID: <svitw68li3.fsf@hodge.primus.com>

I'm confused about the interaction between add_varargs_method() and
getattr() in PythonExtension<>-derived types.

First, I tried defining a method, registering it with
add_varargs_method() in my init_type() function, then calling the
method from Python. My aim is to be as minimal as possible. Apparently
my type isn't exposing the method properly:

> python
Python 1.5.2 (#3, May 22 2000, 11:01:12)  [GCC 2.95.2 19991024 (release)] on sunos5
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> from seh_test import *  
>>> p = some_pod( "a string" )
Constructing some_pod( "a string" ): 0xd8c60
>>> p.do_it()
Traceback (innermost last):
  File "<stdin>", line 1, in ?
AttributeError: 'some_pod' object has no attribute 'do_it'
>>> ^D
Destructing some_pod: 0xd8c6


At that point, I realized that perhaps methods are just special
functors returned from getattr(), so I tried to complete that
implementation as follows:

==================================================
Py::Object py_bound_pod::do_it(const Py::Tuple& t)
{
	// ...
	t.verify_length( 0 );

	m_pod.do_it();

	return Py::Nothing();
}



// ....

Py::Object py_bound_pod::getattr(const char* pcsz)
{ return getattr_methods( pcsz ); }



void py_bound_pod::init_type()
{
	Py::PythonType& pytype = behaviors();
	pytype.name( "some_pod" );
	pytype.doc( "A test POD type constructed from a string" );

	pytype.supportRepr();
	pytype.supportGetattr();

	add_varargs_method( "do_it", &py_bound_pod::do_it,
						"dump out the nested string" );
}
==================================================


With this setup, I get a different error:

>>> p.do_it()
Traceback (innermost last):
  File "<stdin>", line 1, in ?
RuntimeError: Extension object missing a required method.


Can you see what I'm doing wrong, or do I need to post more of the
source code?

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com



From barry at scottb.demon.co.uk  Mon May 22 21:22:12 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Mon, 22 May 2000 20:22:12 +0100
Subject: [C++-SIG] just to introduce me and some comments
In-Reply-To: <005401bf856b$ad522560$dfd79e3e@mjrtom>
Message-ID: <000901bfc423$07cc9250$060210ac@private>

I realise I'm late in answer your message...

Can I assume that the current sources in SourceForge address all your issues
with CXX. If not please let me know what is missing.

I think your comments are on a version of CXX before I contributed code.

		Barry

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of Thomas Malik
> Sent: 03 March 2000 23:53
> To: c++-sig at python.org
> Subject: [C++-SIG] just to introduce me and some comments
> 
> 
> Hello, since i am new to this group, ok, i'm Thomas.
> I've taken the CXX package 3 months ago (don't know which version it was)
> and changed many things to suit my needs. My requirements were:
> - simple, homogeneous look of my wrapper classes, since i had to write a
> whole lot of them
> - use of inheritance in the wrapper classes, since the class library i had
> to incorporate into python, had it, and i didn't want to do mass copies of
> source code (every base class method in every subclass)
> - the whole thing has to run rock solid, since it's going to be used for
> interconnecting stock trading applications in a financial institute.
> - I wanted to rely on C++ exceptions as error notification mechanism.
> 
> What i did:
> I moved the inheritance of the PythonExtension template from PyObject 'one
> level up', by introducing an intermediate class
> CXXPyObject with a virtual destructor:
> 
> // The purpose of this is only to get a virtual destructor into a PyObject
> and to
> // be able to use dynamic_cast on it. PythonExtension inherits virtually
> from this.
> class CXXPyObject : public PyObject {
>   protected:
>     CXXPyObject() {}
>   public:
>     virtual ~CXXPyObject() {}
> };
> 
> CXXObject is a virtual base class for PythonExtension.
> Now, i can use dynamic_cast even in situations, where i inherit from
> PythonExtension multiple times, see below.
> Another thing i changed was to eliminate the template argument from
> PythonType. It's only purpose was to get the Object size, but you can pass
> this easily as a constructor argument, or even pass the size as a template
> argument. The downside is, you have to keep PythonExtension as a template
> class, since the constructor cannot determine the object size at
> construction time.
> 
> To do easy, safe casting in the static member functions (Python entry
> points) i introduced a template function
> T python_cast<class T>(PyObject *). This does first a static_cast to the
> CXXObject*, and then a dynamic_cast to the object i'm actually in. Of
> course, this does NOT lead me magically into the paths of the right member
> functions of the right class, but i'm using dynamic_cast & the virtual
> function table for type checking, which gives me a fairly efficient type
> safe conversion.
> 
> template<class T>
> T python_cast(PyObject *p) {
>   T result = dynamic_cast<T>(static_cast< CXXPyObject* >(p));
>   if (result == NULL) {
>     cerr << "!shit! cast failed!" << endl;
>     throw bad_cast();
>   }
>   return result;
> }
> 
> Lastly, i've added some 'standard' functionality into PythonType &
> PythonExtension, such as str(), repr(), getattr().
> I strictly obey the following rule in my source:
> - Python entry points always have a name starting with 's_' (such as
> s_str(PyObject* self, PyObject* a)  )
> - the first lines look like
> MyClassName* self=python_cast<MyClassName*>(s); // looks damn familiar,
> doesn't it ?
> Tuple args(a);
> 
> so, here's some chunk out of the PythonExtension template:
> // since CXXPyObject is a virtual Baseclass of PythonExtension, you can
> // safely use multiple inheritance with the following Scheme:
> // class A : public PythonExtension<A> {
> // };
> // class B : public A, public PythonExtension<B> {
> // }
> //
> // in A's an B's methods you may use the python_cast<A*>() thing below
> // to get a A* or B* out of a PyObject *
> template<class T>
> class PythonExtension: public virtual CXXPyObject
> {
>   private:
>     static void extension_object_deallocator(PyObject* t) {
>       CXXPyObject* o=static_cast<CXXPyObject*>(t);
>       delete o;
>       // delete t;
>     }
> 
>     explicit PythonExtension(const PythonExtension<T>& other);
>     void operator=(const PythonExtension<T>& rhs);
>   protected:
>     explicit PythonExtension() {
>       ob_refcnt = 1;
>       ob_type = type_object();
>     }
>   public:
>     virtual ~PythonExtension() {}
> 
>     static PythonType& behaviors() {
>       static PythonType* p;
>       if(!p) {
>          p = new PythonType(sizeof(T));
>          p->dealloc(extension_object_deallocator);
>          p->str(s_str);
>          p->repr(s_repr);
>       }
> ...
> }
> 
> If someone's interested; i can send the whole story(code).
> BTW, I've also implemented some huge macros for easy (and safe!) use of
> exceptions within C++ Modules. Note that you CAN'T throw exceptions
> 'through' the python interpreter. Consider this:
> 
> PyObject* mainEventLoop()
> {
>     PyObject* o=someObject;
>     try {
>         while (...)
>             // some crufty event magic going on
>             if (eventOccured())
>                 Py_CallMethod(o,"crashbang",...);
>     }
>     catch (const Exception&) {
>     }
> }
> 
> and 'crashbang()' calls a C++ method from within your module, which throws
> an exception. My experience was that the process will go wreck, with the
> default execption handler aborting the program. What i did is to write a
> macro to catch these exceptions and to return Null instead.
> 
> Ok, that's it for today. Comments are welcome.
> 
> Thomas Malik
> 
> 
> 
> 
> _______________________________________________
> C++-SIG maillist  -  C++-SIG at python.org
> http://www.python.org/mailman/listinfo/c++-sig
> 



From barry at scottb.demon.co.uk  Mon May 22 21:34:18 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Mon, 22 May 2000 20:34:18 +0100
Subject: [C++-SIG] Trouble getting a method called
In-Reply-To: <svitw68li3.fsf@hodge.primus.com>
Message-ID: <000a01bfc424$b8c52da0$060210ac@private>

Here is a check list:

1. init_type() must be static.
2. all the init_type() functions must be called from your modules constructor
	[If not you will have no attributes]
3. from python do print dir(your_module) - check for all the module attributes
4. from python do print dir(your_object) - check for all the object attributes
5. from python do print your_object.__methods__ - check for all your methods

My guess is (2).

		BArry

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of Steve Harris
> Sent: 22 May 2000 19:53
> To: c++-sig at python.org
> Subject: [C++-SIG] Trouble getting a method called
> 
> 
> I'm confused about the interaction between add_varargs_method() and
> getattr() in PythonExtension<>-derived types.
> 
> First, I tried defining a method, registering it with
> add_varargs_method() in my init_type() function, then calling the
> method from Python. My aim is to be as minimal as possible. Apparently
> my type isn't exposing the method properly:
> 
> > python
> Python 1.5.2 (#3, May 22 2000, 11:01:12)  [GCC 2.95.2 19991024 (release)] on sunos5
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> from seh_test import *  
> >>> p = some_pod( "a string" )
> Constructing some_pod( "a string" ): 0xd8c60
> >>> p.do_it()
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> AttributeError: 'some_pod' object has no attribute 'do_it'
> >>> ^D
> Destructing some_pod: 0xd8c6
> 
> 
> At that point, I realized that perhaps methods are just special
> functors returned from getattr(), so I tried to complete that
> implementation as follows:
> 
> ==================================================
> Py::Object py_bound_pod::do_it(const Py::Tuple& t)
> {
> 	// ...
> 	t.verify_length( 0 );
> 
> 	m_pod.do_it();
> 
> 	return Py::Nothing();
> }
> 
> 
> 
> // ....
> 
> Py::Object py_bound_pod::getattr(const char* pcsz)
> { return getattr_methods( pcsz ); }
> 
> 
> 
> void py_bound_pod::init_type()
> {
> 	Py::PythonType& pytype = behaviors();
> 	pytype.name( "some_pod" );
> 	pytype.doc( "A test POD type constructed from a string" );
> 
> 	pytype.supportRepr();
> 	pytype.supportGetattr();
> 
> 	add_varargs_method( "do_it", &py_bound_pod::do_it,
> 						"dump out the nested string" );
> }
> ==================================================
> 
> 
> With this setup, I get a different error:
> 
> >>> p.do_it()
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> RuntimeError: Extension object missing a required method.
> 
> 
> Can you see what I'm doing wrong, or do I need to post more of the
> source code?
> 
> -- 
> Steven E. Harris
> Primus Knowledge Solutions, Inc.
> http://www.primus.com
> 
> _______________________________________________
> C++-SIG maillist  -  C++-SIG at python.org
> http://www.python.org/mailman/listinfo/c++-sig
> 



From sharris at primus.com  Mon May 22 22:19:05 2000
From: sharris at primus.com (Steve Harris)
Date: 22 May 2000 13:19:05 -0700
Subject: [C++-SIG] Trouble getting a method called
In-Reply-To: "Barry Scott"'s message of "Mon, 22 May 2000 20:34:18 +0100"
References: <000a01bfc424$b8c52da0$060210ac@private>
Message-ID: <sv1z2u8hja.fsf@hodge.primus.com>

"Barry Scott" <barry at scottb.demon.co.uk> writes:

> Here is a check list:
> 
> 1. init_type() must be static.

Check.


> 2. all the init_type() functions must be called from your modules
>    constructor [If not you will have no attributes]

==================================================
class seh_test_module : public Py::ExtensionModule<seh_test_module>
{
public:
	seh_test_module()
		: Py::ExtensionModule<seh_test_module>( "seh_test" )
	{
		py_bound_pod::init_type();

		add_varargs_method( "some_pod", &seh_test_module::new_py_bound_pod,
							"some_pod(str)" );

		initialize( "seh_test module explores wrapping a C++ POD in a Python type" );
	}
==================================================

Check.


> 3. from python do print dir(your_module) - check for all the module
>    attributes

>>> print dir( seh_test )
['__doc__', '__file__', '__name__','some_pod']

Okay.


> 4. from python do print dir(your_object) - check for all the object
>    attributes

>>> p = some_pod( "a string" )
Constructing some_pod( "a string" ): 0xd8c60
>>> print dir( p )
[]

Uh oh.


> 5. from python do print your_object.__methods__ - check for all your
>    methods

>>> print p.__methods__
Traceback (innermost last):
  File "<stdin>", line 1, in ?
RuntimeError: Extension object missing a required method.

Uh oh.


Anything else I can check?

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com



From barry at scottb.demon.co.uk  Tue May 23 00:05:57 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Mon, 22 May 2000 23:05:57 +0100
Subject: [C++-SIG] Trouble getting a method called
In-Reply-To: <sv1z2u8hja.fsf@hodge.primus.com>
Message-ID: <000e01bfc439$e848ac40$060210ac@private>

> > 3. from python do print dir(your_module) - check for all the module
> >    attributes
> 
> >>> print dir( seh_test )
> ['__doc__', '__file__', '__name__','some_pod']
> 
> Okay.

	The module is good.

> > 4. from python do print dir(your_object) - check for all the object
> >    attributes
> 
> >>> p = some_pod( "a string" )
> Constructing some_pod( "a string" ): 0xd8c60
> >>> print dir( p )
> []
> 
> Uh oh.

	Here is the problem. The object p does not have any attributes.

	I suggest that you add cout << debug statements to confirm that
	the init_type() and getattr() are really called.

> > 5. from python do print your_object.__methods__ - check for all your
> >    methods
> 
> >>> print p.__methods__
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> RuntimeError: Extension object missing a required method.

	This is almost certainly the default getattr code running.
	Which only happens, in my experience, if init_type() is not 
	called.
> 
> Uh oh.
> 
> 
> Anything else I can check?

	Make sure you have the latest sources from SourceForge.

	Make sure that the Demo example module works.

			BArry




From sharris at primus.com  Tue May 23 01:08:21 2000
From: sharris at primus.com (Steve Harris)
Date: 22 May 2000 16:08:21 -0700
Subject: [C++-SIG] Trouble getting a method called
In-Reply-To: "Barry Scott"'s message of "Mon, 22 May 2000 23:05:57 +0100"
References: <000e01bfc439$e848ac40$060210ac@private>
Message-ID: <svog5y6v4q.fsf@hodge.primus.com>

"Barry Scott" <barry at scottb.demon.co.uk> writes:

> 	Here is the problem. The object p does not have any attributes.
> 
> 	I suggest that you add cout << debug statements to confirm that
> 	the init_type() and getattr() are really called.

I put some print statements in init_type() and verified that it is
getting called. Here's what I learned:

* You must have called supportGetattr() and implement getattr()
  for a method to be called, even if you don't care about getattr.

* You must call moduleDictionary() in your extension module's
  constructor.

Once I did those _two_ things together, my method appeared. Is this
how it's supposed to work?

If method calls are implemented in terms of getattr(), then calling
add_varargs_method() should implicitly assert that you're "supporting
getattr." Furthermore, it seems that implementing getattr shouldn't be
necessary just to support method calls. After all, all my getattr()
method does is forward a call to getattr_methods(). Can we invert this
such that if there is no method defined for a particular getattr name,
_then_ the call is (optionally) forwarded to the derived class getattr
method? That is, in pseudo-code:

Py::Object handle_getattr_call(const char* pcsz)
{
  const foo::const_iterator it = method_map.find( pcsz );
  if ( it != method_map.end() )
    return *it;  // deref it and return something callable
  else if ( bSupportsGetattr )
    return getattr();
  else
    throw something;
}


This arrangement would make more sense to me, as it better separates
the method dispatching from the getattr implementation. At present,
the add_varargs_method() function is confusing in that it doesn't do
enough to hook up all the machinery to expose the method to Python.


[...]

> 	Make sure you have the latest sources from SourceForge.

Do the latest changes address these problems?


> 	Make sure that the Demo example module works.

Yes, it does. That's where I started pulling random bits of code from
(including the "moduleDictionary()" call). Why is it necessary to call
this function in order for all of this to work?

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com



From sharris at primus.com  Tue May 23 01:23:30 2000
From: sharris at primus.com (Steve Harris)
Date: 22 May 2000 16:23:30 -0700
Subject: [C++-SIG] Trouble getting a method called
In-Reply-To: Steve Harris's message of "22 May 2000 16:08:21 -0700"
References: <000e01bfc439$e848ac40$060210ac@private>
	<svog5y6v4q.fsf@hodge.primus.com>
Message-ID: <svk8gm6ufh.fsf@hodge.primus.com>

Steve Harris <sharris at primus.com> writes:

[...]

> * You must call moduleDictionary() in your extension module's
>   constructor.

Oops, I'm wrong. This call is not necessary. I think it was a rebuild
problem that confused my association of this method call with the
solution. I see now that moduleDictionary() is called by the
initialize() function.

[...]

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com



From sharris at primus.com  Tue May 23 02:41:50 2000
From: sharris at primus.com (Steve Harris)
Date: 22 May 2000 17:41:50 -0700
Subject: [C++-SIG] How to use CXX...
In-Reply-To: "Barry Scott"'s message of "Wed, 17 May 2000 19:43:54 +0100"
References: <000501bfc02f$da520ef0$060210ac@private>
Message-ID: <svg0ra6qsx.fsf@hodge.primus.com>

"Barry Scott" <barry at scottb.demon.co.uk> writes:

[...]

> > 4. I haven't gotten to trying to wrap containers yet. What if your C++
> > type has a method like
> >   const std::list<foo>& get_foos() const;
> > where the type exposes a nested container of some other type. That
> > looks like you could coax some Pythonic behavior out of the pattern,
> > but how would you go about wrapping it? Do you have to copy the whole
> > list for each request for the Python-wrapped sequence?
> 
> 	No copy needed. You can implement the methods required for a
> 	sequence type and be a proxy between Python and the std::list.

Looking at the sequence methods more closely, it looks like Python
imposes random-access requirements on the underlying sequence. The
sequence_item() method allows the caller to fetch an element at a
particular index. Has anyone tried to adapt this to something like
std::list?

It seems like you _could_ find an item by iterating from begin() a
given number of times, making sure that you're not at end(), but
that's horribly inefficient. You could try to cache the last index
request and say, "If the requested index is just one higher than the
last one, then just bump my iterator forward by one." This could get
into some weird situations if the underlying list changed - like if
some elements got inserted before your "current" position. The list
iterators would be stable, but the indexes would not be.

An alternate idea is to copy the list iterators into a vector. That
could also be costly if the proxy sequence has to be constructed again
and again.

Has anyone tried to create such a Standard C++ container proxy?

[...]

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com



From dubois1 at llnl.gov  Tue May 23 03:21:11 2000
From: dubois1 at llnl.gov (Paul F. Dubois)
Date: Mon, 22 May 2000 18:21:11 -0700
Subject: [C++-SIG] How to use CXX...
In-Reply-To: <svg0ra6qsx.fsf@hodge.primus.com>
Message-ID: <NDBBIEFMILBFPMDHJIMFGENHCFAA.dubois1@llnl.gov>

It is clear that a Python sequence type is a random access container. The
class Sequence in CXX is too. If you want to wrap a class that is not a
random access container, then it isn't a Sequence. You can invent a new
class for it that is a child of Object in the same way that Sequence is,
with whatever access rules you think are appropriate, but if your can't do
x[i] in reasonable time it is simply deceptive to have such an operator.

One model that may work is the Eiffel LIST; in Eiffel, most containers have
a cursor as part of their state. The cursor can be moved forward, placed at
the start, tested as whether it is off the end, etc. The access is then
x.item (which would be x.item() in C++) to get the value under the cursor.




From sharris at primus.com  Tue May 23 06:00:06 2000
From: sharris at primus.com (Steve Harris)
Date: 22 May 2000 21:00:06 -0700
Subject: [C++-SIG] How to use CXX...
In-Reply-To: "Paul F. Dubois"'s message of "Mon, 22 May 2000 18:21:11 -0700"
References: <NDBBIEFMILBFPMDHJIMFGENHCFAA.dubois1@llnl.gov>
Message-ID: <svbt1x7w6x.fsf@hodge.primus.com>

"Paul F. Dubois" <dubois1 at llnl.gov> writes:

> It is clear that a Python sequence type is a random access container. The
> class Sequence in CXX is too. If you want to wrap a class that is not a
> random access container, then it isn't a Sequence. You can invent a new
> class for it that is a child of Object in the same way that Sequence is,
> with whatever access rules you think are appropriate, but if your can't do
> x[i] in reasonable time it is simply deceptive to have such an operator.

The syntax I'm looking to enable is just iteration:

  for item in seq
    print item


From sharris at primus.com  Tue May 23 20:42:48 2000
From: sharris at primus.com (Steve Harris)
Date: 23 May 2000 11:42:48 -0700
Subject: [C++-SIG] Submitting candidate changes to CXX
Message-ID: <svbt1x5crb.fsf@hodge.primus.com>

I started working a CVS checkout of CXX today and found some nits that
I'd like to fix. I've changed the code here, but I don't have write
access to the CVS tree (and nor should I). What is the process for
getting candidate changes reviewed, approved, and submitted?

The nature of my changes are:
* Tighten const-correctness where possible
* Reduce repetitive lookups into std::map
* Eliminate some (explicit named) temporary variables
* Eliminate heap-allocated static variables (that won't get cleaned up)

Please advise.

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com



From dubois1 at llnl.gov  Tue May 23 21:05:27 2000
From: dubois1 at llnl.gov (Paul F. Dubois)
Date: Tue, 23 May 2000 12:05:27 -0700
Subject: [C++-SIG] Submitting candidate changes to CXX
In-Reply-To: <svbt1x5crb.fsf@hodge.primus.com>
References: <svbt1x5crb.fsf@hodge.primus.com>
Message-ID: <00052312113700.17888@almanac>

On Tue, 23 May 2000, you wrote:
> I started working a CVS checkout of CXX today and found some nits that
> I'd like to fix. I've changed the code here, but I don't have write
> access to the CVS tree (and nor should I). What is the process for
> getting candidate changes reviewed, approved, and submitted?
> 
> The nature of my changes are:
> * Tighten const-correctness where possible
> * Reduce repetitive lookups into std::map
> * Eliminate some (explicit named) temporary variables
> * Eliminate heap-allocated static variables (that won't get cleaned up)
> 
> Please advise.
> 
> -- 
> Steven E. Harris
> Primus Knowledge Solutions, Inc.
> http://www.primus.com
> 
> _______________________________________________
> C++-SIG maillist  -  C++-SIG at python.org
> http://www.python.org/mailman/listinfo/c++-sig

There is a patch manager on the project page. You make a patch and put it
there. One of us picks it up, examines the changes and if happy installs it.

Can you explain your last point? You mean I had a memory leak?

At least one of them is on purpose: when you initialize the module you have to
make sure that the Module object has an infinite lifetime.

It shouldn't be necessary to eliminate temporaries; any good compiler will do
this.  There are some in the tests that look like temporaries but in fact are
doing Python-type checking and for debugging purposes I did things in steps.

Thanks for helping us.



From sharris at primus.com  Tue May 23 21:18:35 2000
From: sharris at primus.com (Steve Harris)
Date: 23 May 2000 12:18:35 -0700
Subject: [C++-SIG] Submitting candidate changes to CXX
In-Reply-To: "Paul F. Dubois"'s message of "Tue, 23 May 2000 12:05:27 -0700"
References: <svbt1x5crb.fsf@hodge.primus.com> <00052312113700.17888@almanac>
Message-ID: <sv3dn95b3o.fsf@hodge.primus.com>

"Paul F. Dubois" <dubois1 at llnl.gov> writes:


[...]

> Can you explain your last point? You mean I had a memory leak?
> 
> At least one of them is on purpose: when you initialize the module
> you have to make sure that the Module object has an infinite
> lifetime.

There are a few static methods that take the same basic shape, such as
Py::ExtensionModule::methods(). In the CVS version, it keeps a static
pointer which is initially null. In each call, it checks to see if the
pointer is still null. If so, it heap allocates a method_map_t
variable and returns that variable by reference. But how and when
would that pointer ever get deleted? My candidate replacement takes
this form:

	static method_map_t &methods(void)
		{
		static method_map_t map_of_methods;
		return map_of_methods;
		}

Since map_of_methods is a static local variable, it's guaranteed to be
cleaned up eventually. We know that an exiting process will likely
clean up most heap-allocated memory, but the above form seems more
trustworthy unless you're deliberately trying to control _when_ the
variable gets deleted.

> It shouldn't be necessary to eliminate temporaries; any good
> compiler will do this.  There are some in the tests that look like
> temporaries but in fact are doing Python-type checking and for
> debugging purposes I did things in steps.

Okay. Perhaps you can then veto some of the changes. Maybe it's just a
style thing. I always think of Scott Meyers' "Item" on named
temporary variables: the compiler can't take as much liberty in
eliminating them. I'll let you be the judge.

> Thanks for helping us.

No problem. It's harder to jump in when you can't just talk about a
change in the hallway. Please let me know when I'm stepping on any
assumptions or procedures so I can stop.

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com



From phil at geog.ubc.ca  Wed May 24 01:37:12 2000
From: phil at geog.ubc.ca (Phil Austin)
Date: Tue, 23 May 2000 16:37:12 -0700 (PDT)
Subject: [C++-SIG] Problems building and testing CXX demo
In-Reply-To: <sv7ld4tzd8.fsf@hodge.primus.com>
References: <sv7ld4tzd8.fsf@hodge.primus.com>
Message-ID: <14635.5672.921002.367123@brant.geog.ubc.ca>

Steve Harris writes:
 > 
 > Python built fine, and the 'example' module builds fine - though it
 > takes about 30 minutes to build!

Out of curiosity, are you still having to live with 30 minute compile
times, or did you find a way to speed things up?

Regards, Phil



From sharris at primus.com  Wed May 24 03:09:00 2000
From: sharris at primus.com (Steve Harris)
Date: 23 May 2000 18:09:00 -0700
Subject: [C++-SIG] Problems building and testing CXX demo
In-Reply-To: Phil Austin's message of "Tue, 23 May 2000 16:37:12 -0700 (PDT)"
References: <sv7ld4tzd8.fsf@hodge.primus.com>
	<14635.5672.921002.367123@brant.geog.ubc.ca>
Message-ID: <svr9asah5f.fsf@hodge.primus.com>

Phil Austin <phil at geog.ubc.ca> writes:

> Out of curiosity, are you still having to live with 30 minute compile
> times, or did you find a way to speed things up?

No, we're down to about four minutes in the worst case. I think the
problem was mixing g++/gcc with Sun's native assembler and
linker. Once we rebuilt g++ to use the Gnu binutils, everything got
faster.

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com



From barry at scottb.demon.co.uk  Sun May 28 14:47:07 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Sun, 28 May 2000 13:47:07 +0100
Subject: [C++-SIG] Submitting candidate changes to CXX
In-Reply-To: <sv3dn95b3o.fsf@hodge.primus.com>
Message-ID: <000b01bfc8a2$d4fcd5e0$060210ac@private>

> There are a few static methods that take the same basic shape, such as
> Py::ExtensionModule::methods(). In the CVS version, it keeps a static
> pointer which is initially null. In each call, it checks to see if the
> pointer is still null. If so, it heap allocates a method_map_t
> variable and returns that variable by reference. But how and when
> would that pointer ever get deleted? My candidate replacement takes
> this form:
> 
> 	static method_map_t &methods(void)
> 		{
> 		static method_map_t map_of_methods;
> 		return map_of_methods;
> 		}
> 

	I think the problem is that this change will not work as the c'tor
	will not be called on all platforms (which is a compiler/RTL/
	way-python-is built bug).

	As the memory will be in use from the moment the module is loaded
	until process exit its not a performance issue.

> Since map_of_methods is a static local variable, it's guaranteed to be
> cleaned up eventually. We know that an exiting process will likely
> clean up most heap-allocated memory, but the above form seems more
> trustworthy unless you're deliberately trying to control _when_ the
> variable gets deleted.

	The OS simply returns all resources used by a process to the OS
	free resources. Nothing in the OS bothers to look at the heap
	in an intelligent way. There may be malloc debug code loaded.

> > It shouldn't be necessary to eliminate temporaries; any good
> > compiler will do this.  There are some in the tests that look like
> > temporaries but in fact are doing Python-type checking and for
> > debugging purposes I did things in steps.
> 
> Okay. Perhaps you can then veto some of the changes. Maybe it's just a
> style thing. I always think of Scott Meyers' "Item" on named
> temporary variables: the compiler can't take as much liberty in
> eliminating them. I'll let you be the judge.

	I place intermediate values in named varables to allow me
	to debug the logic of an algorithm. I've found that this
	works well to allow me maintain code.

		BArry




From barry at scottb.demon.co.uk  Mon May 29 13:30:04 2000
From: barry at scottb.demon.co.uk (Barry Scott)
Date: Mon, 29 May 2000 12:30:04 +0100
Subject: [C++-SIG] Announcing CXX 5.0
Message-ID: <000001bfc961$3bff48e0$060210ac@private>

	CXX 5.0 is tagged on SourceForge with the name "CXX_5_0".

	The older version 4.2 source did not contain all the work
	done on CXX before creation on SourceForge. 5.0 contains
	all the work that has been done on CXX.

	We will now start working towards CXX 5.1.

	The main work items I know about are:

	* Use Geoffrey Furnish's Invoke method.
	  This method solves the problem of mixing C++ and C pointers

	* Merge David Abraham's simplified object wrapping

	* Analysis and merge the code from the patches no SourceForge

	* Fix bugs as reported

	* Improve usability

	* Ensure CXX is written in ANSI C++ as far as is practical
	  given the state of available C++ compilers.

		BArry