From s13361562 at bach.sun.ac.za  Sun Feb  3 12:31:54 2002
From: s13361562 at bach.sun.ac.za (Hugo van der Merwe)
Date: Sun, 3 Feb 2002 13:31:54 +0200
Subject: [C++-sig] trouble with virtual methods
In-Reply-To: <20020131111249.GA23083@vervet>
References: <20020130204728.GC13110@vervet> <20020131001355.21428.qmail@web20210.mail.yahoo.com> <20020131111249.GA23083@vervet>
Message-ID: <20020203113154.GA8981@vervet>

> Will let you know what my results are, thanks.
> Hugo

I have finally gotten round to "debugging" this issue, had enough other
things to work on before requiring virtual methods.

gdb told me the following:

(gdb) add-shared-symbol-files demeter.so
This command is not available in this configuration of GDB.

So I didn't bother with that.

As it turns out, the error was in the Python code:

>>> import demeter
>>> class boo(demeter.TextureFactory):
...   def GetTexture(a, b, c, d, e): print "gotcha:",a,b,c,d,e
...
>>> tf = boo();
here I am
>>> demeter.func(tf)
Aborted

Notice I forgot the "self" parameter in that GetTexture - GetTexture
only has 5 parameters, instead of the 6 it should have.

Another problem with this code is that it does not call return, this
also causes the program to bomb out.

>>> class boo(demeter.TextureFactory):
...   def GetTexture(a, b, c, d, e):
...     print "gotcha:",a,b,c,d,e
...     return 1

That solved it for me.

Thanks,
Hugo



From david.abrahams at rcn.com  Sun Feb  3 16:53:24 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 3 Feb 2002 10:53:24 -0500
Subject: [C++-sig] trouble with virtual methods
References: <20020130204728.GC13110@vervet> <20020131001355.21428.qmail@web20210.mail.yahoo.com> <20020131111249.GA23083@vervet> <20020203113154.GA8981@vervet>
Message-ID: <133101c1accb$72a48e10$0500a8c0@boostconsulting.com>

Looking at the Boost.Python code, it seems to me that either of these
mistakes should cause a C++ exception to be thrown. There are only two
explanations I can think of for your crash:

1. The code surrounding your use of callback<>...::call(...) isn't
exception-safe.
2. Your compiler's exception-handling implementation has a bug.

If you raise a Python exception from within your Python GetTexture method
you should see a similar crash. If you care about robustness, it would be
worth your while to track this down.

-Dave

----- Original Message -----
From: "Hugo van der Merwe" <s13361562 at bach.sun.ac.za>
To: <c++-sig at python.org>
Sent: Sunday, February 03, 2002 6:31 AM
Subject: Re: [C++-sig] trouble with virtual methods


> > Will let you know what my results are, thanks.
> > Hugo
>
> I have finally gotten round to "debugging" this issue, had enough other
> things to work on before requiring virtual methods.
>
> gdb told me the following:
>
> (gdb) add-shared-symbol-files demeter.so
> This command is not available in this configuration of GDB.
>
> So I didn't bother with that.
>
> As it turns out, the error was in the Python code:
>
> >>> import demeter
> >>> class boo(demeter.TextureFactory):
> ...   def GetTexture(a, b, c, d, e): print "gotcha:",a,b,c,d,e
> ...
> >>> tf = boo();
> here I am
> >>> demeter.func(tf)
> Aborted
>
> Notice I forgot the "self" parameter in that GetTexture - GetTexture
> only has 5 parameters, instead of the 6 it should have.
>
> Another problem with this code is that it does not call return, this
> also causes the program to bomb out.
>
> >>> class boo(demeter.TextureFactory):
> ...   def GetTexture(a, b, c, d, e):
> ...     print "gotcha:",a,b,c,d,e
> ...     return 1
>
> That solved it for me.
>
> Thanks,
> Hugo
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>




From s13361562 at bach.sun.ac.za  Sun Feb  3 23:40:54 2002
From: s13361562 at bach.sun.ac.za (Hugo van der Merwe)
Date: Mon, 4 Feb 2002 00:40:54 +0200
Subject: [C++-sig] trouble with virtual methods
In-Reply-To: <133101c1accb$72a48e10$0500a8c0@boostconsulting.com>
References: <20020130204728.GC13110@vervet> <20020131001355.21428.qmail@web20210.mail.yahoo.com> <20020131111249.GA23083@vervet> <20020203113154.GA8981@vervet> <133101c1accb$72a48e10$0500a8c0@boostconsulting.com>
Message-ID: <20020203224054.GA14310@vervet>

> Looking at the Boost.Python code, it seems to me that either of these
> mistakes should cause a C++ exception to be thrown. There are only two
> explanations I can think of for your crash:
> 
> 1. The code surrounding your use of callback<>...::call(...) isn't
> exception-safe.
> 2. Your compiler's exception-handling implementation has a bug.
> 
> If you raise a Python exception from within your Python GetTexture method
> you should see a similar crash. If you care about robustness, it would be
> worth your while to track this down.
> 
> -Dave

Yes, error reporting in my current project (not really *my* project,
it's team effort and all, I'm just lending a hand) seems really abysmal
at this point. (Getting just "Aborted", most of the time.) For one the
C++ exceptions are not derived from std::exception yet, so C++
exceptions are not reaching Python. This is next on my TODO list, just
after finishing implementing what I'm currently implementing. (Which is
just redoing some algorithms in the lib, doesn't have anything to do
with Python and exceptions.)

The compiler I'm currently using:

$ g++ -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011006 (Debian prerelease)

I will write back again when I've put some effort into sorting out the
exception stuff. This might be a while though, a busy week or two coming
up, may keep me away from this project for a while.

Thanks a lot,
Hugo



From s13361562 at bach.sun.ac.za  Sun Feb  3 23:47:00 2002
From: s13361562 at bach.sun.ac.za (Hugo van der Merwe)
Date: Mon, 4 Feb 2002 00:47:00 +0200
Subject: [C++-sig] trouble with virtual methods
In-Reply-To: <20020203224054.GA14310@vervet>
References: <20020130204728.GC13110@vervet> <20020131001355.21428.qmail@web20210.mail.yahoo.com> <20020131111249.GA23083@vervet> <20020203113154.GA8981@vervet> <133101c1accb$72a48e10$0500a8c0@boostconsulting.com> <20020203224054.GA14310@vervet>
Message-ID: <20020203224700.GC14310@vervet>

On Mon, Feb 04, 2002 at 12:40:54AM +0200, Hugo van der Merwe wrote:
> Yes, error reporting in my current project (not really *my* project,
> it's team effort and all, I'm just lending a hand) seems really abysmal
> at this point. (Getting just "Aborted", most of the time.) For one the

Now that didn't sound right. It's as if I'm saying that it's other
people's fault there's bad error reporting. I'm doing the Python
wrapper, and it's in the Python wrapper that the error reporting is
abysmal. Just didn't want to say the project is "mine" when I didn't do
most of the work. ;)

Later,
Hugo



From david.abrahams at rcn.com  Mon Feb  4 21:45:03 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 4 Feb 2002 15:45:03 -0500
Subject: [C++-sig] [ANN] Preview of Boost.Python V2
Message-ID: <02bc01c1adbc$f7c87150$0500a8c0@boostconsulting.com>

A preview of Boost.Python V2 code is now available in the Boost CVS
repository (http://sourceforge.net/cvs/?group_id=7586).

You can find a Jamfile for building and testing the new material in
<boost-root>/libs/python. To build and run it, you will need to check out
the <boost-root>/boost/mpl directory on the mpl-development branch. To do
that, after getting the main trunk revision of boost, go to <boost-root> and
type:

    cvs update -dRP -rmpl-development boost/mpl


Test drivers and example material are available in the libs/python/test
directory:

test_builtin_converters.py/cpp
    tests for conversions of native types and std::string

test_pointer_adoption.py/cpp
    demonstrates the ability to deal with pointer/reference
    return types and transfer of ownership.

m1.cpp, m2.cpp, newtest.py
    general test showing class definitions, the abilty
    to specify how C++ class instances are held in the
    corresponding Python objects, and the ability
    to define converters for classic extension types.

The library is evolving into a framework with high- and low-level
components. The test files above demonstrate some of each.


There is no documentation yet; That's coming soon.

Regards,
Dave





From arnaldur at decode.is  Tue Feb  5 20:50:05 2002
From: arnaldur at decode.is (Arnaldur Gylfason)
Date: Tue, 5 Feb 2002 19:50:05 +0000
Subject: [C++-sig] Re: Preview of Boost.Python V2 (David Abrahams)
Message-ID: <OF69A39A22.D35038C9-ON00256B57.006C9960@decode.is>

Dave,

I'm getting many error messages because
some files are using the Python API without #include -ing "Python.h"
Is it supposed to be included in just one place or should it be included in
all those files.
E.g. :
     object/class_wrapper.hpp
     to_python_indirect.hpp
     and more

cheers

Arnaldur







From david.abrahams at rcn.com  Tue Feb  5 21:47:20 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 5 Feb 2002 15:47:20 -0500
Subject: [C++-sig] Re: Preview of Boost.Python V2 (David Abrahams)
References: <OF69A39A22.D35038C9-ON00256B57.006C9960@decode.is>
Message-ID: <00b901c1ae86$5bee5040$479dbba7@boostconsulting.com>

All of these files (should) eventually indirectly #include
<boost/python/detail/wrap_python.hpp>, which includes <Python.h>.

I've compiled this code with 6 or 7 different compilers on three different
OSes, so I'll be really surprised if Python.h was actually not properly
referenced... (famous last words, I know)

-Dave
----- Original Message -----
From: "Arnaldur Gylfason" <arnaldur at decode.is>
To: <c++-sig at python.org>
Sent: Tuesday, February 05, 2002 2:50 PM
Subject: [C++-sig] Re: Preview of Boost.Python V2 (David Abrahams)


>
> Dave,
>
> I'm getting many error messages because
> some files are using the Python API without #include -ing "Python.h"
> Is it supposed to be included in just one place or should it be included
in
> all those files.
> E.g. :
>      object/class_wrapper.hpp
>      to_python_indirect.hpp
>      and more
>
> cheers
>
> Arnaldur
>
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig




From peter.bienstman at rug.ac.be  Wed Feb  6 02:01:50 2002
From: peter.bienstman at rug.ac.be (Peter Bienstman)
Date: 05 Feb 2002 20:01:50 -0500
Subject: [C++-sig] preliminary V2 feedback
Message-ID: <1012957312.1936.0.camel@h00d0597a1e9f>

Hi,

This is some very preliminary feedback from trying to use the V2 preview
as a drop-in replacement for V1.

Using the intel compiler, I cannot compile any wrapper function that
returns a string:

 "../boost_cvs/boost/boost/python/detail/extension_class.hpp", line 393:
error: no instance of overloaded function
"boost::python::py_extension_class_converters" matches the argument list
            argument types are: (boost::python::type<std::string>)
      return
py_extension_class_converters(boost::python::type<T>()).to_python(x);

Also no luck with statements like

Expression_.def(operators<op_mul>(), right_operand<unsigned int>()

This gives the same error, in addition to

"../boost_cvs/boost/boost/python/detail/extension_class.hpp", line 393:
error: no instance of overloaded function
"boost::python::py_extension_class_converters" matches the argument list
            argument types are:
(boost::python::type<boost::python::tuple>)
      return
py_extension_class_converters(boost::python::type<T>()).to_python(x);


gcc compiles everthing without problems.

As far as linking is concerned, I will wait for the documentation,
because it seems I have to link with more than bpl.so...

Peter




From david.abrahams at rcn.com  Wed Feb  6 06:58:46 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 6 Feb 2002 00:58:46 -0500
Subject: [C++-sig] preliminary V2 feedback
References: <1012957312.1936.0.camel@h00d0597a1e9f>
Message-ID: <015501c1aed3$75606a70$479dbba7@boostconsulting.com>

You're still not using the V2 preview.
There is no py_extension_class_converters in the V2 codebase.
The V2 codebase is also not a drop-in replacement for V1; far from it.

I repeat: to preview V2, Jam must be invoked in <boost-root>/libs/python.
The example code which demonstrates usage is in the following
<boost-root>/libs/python/test/ files:

m1.cpp m2.cpp newtest.py
test_builtin_converters.* test_pointer_adoption.*


----- Original Message -----
From: "Peter Bienstman" <peter.bienstman at rug.ac.be>
To: <c++-sig at python.org>
Sent: Tuesday, February 05, 2002 8:01 PM
Subject: [C++-sig] preliminary V2 feedback


> Hi,
>
> This is some very preliminary feedback from trying to use the V2 preview
> as a drop-in replacement for V1.
>
> Using the intel compiler, I cannot compile any wrapper function that
> returns a string:
>
>  "../boost_cvs/boost/boost/python/detail/extension_class.hpp", line 393:
> error: no instance of overloaded function
> "boost::python::py_extension_class_converters" matches the argument list
>             argument types are: (boost::python::type<std::string>)
>       return
> py_extension_class_converters(boost::python::type<T>()).to_python(x);
>
> Also no luck with statements like
>
> Expression_.def(operators<op_mul>(), right_operand<unsigned int>()
>
> This gives the same error, in addition to
>
> "../boost_cvs/boost/boost/python/detail/extension_class.hpp", line 393:
> error: no instance of overloaded function
> "boost::python::py_extension_class_converters" matches the argument list
>             argument types are:
> (boost::python::type<boost::python::tuple>)
>       return
> py_extension_class_converters(boost::python::type<T>()).to_python(x);
>
>
> gcc compiles everthing without problems.
>
> As far as linking is concerned, I will wait for the documentation,
> because it seems I have to link with more than bpl.so...
>
> Peter
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>




From arnaldur at decode.is  Wed Feb  6 11:04:19 2002
From: arnaldur at decode.is (Arnaldur Gylfason)
Date: Wed, 6 Feb 2002 10:04:19 +0000
Subject: [C++-sig] Re: Preview of Boost.Python V2 (David Abrahams)
Message-ID: <OF4AA915C8.2F997E50-ON00256B58.0036CB71@decode.is>

> I've compiled this code with 6 or 7 different compilers on three
different
> OSes,

Pretty good!

> so I'll be really surprised if Python.h was actually not properly
> referenced... (famous last words, I know)

Well, not this time. It was the wrong Python version.
I edited PYTHON_VERSION in python.jam, but discovered it is specified in 2
places. I failed
to edit the first place.
Everything compiles and links now.
This is actually the first time I use boost.jam. Looks good.
(I decided to go with regular jam when I looked into this half a year ago)

cheers

Arnaldur





From arnaldur at decode.is  Wed Feb  6 12:49:28 2002
From: arnaldur at decode.is (Arnaldur Gylfason)
Date: Wed, 6 Feb 2002 11:49:28 +0000
Subject: [C++-sig] Preview of Boost.Python V2  problems
Message-ID: <OF2215AEC7.E2080C6F-ON00256B58.00403766@decode.is>

I tried importing 1 of the test modules and got the following error:

>>> import m1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError:
../../libs/python/bin/bpl/gcc/debug-python/runtime-link-dynamic/shared-linkable-true/bpl.so:

undefined symbol: _Py_RefTotal


Another thing, the modules specify a relative path to bpl.so.
When importing e.g. m1, it can't find bpl.so unlessit it is in
[prefix]/libs/python since it always looks for
../../libs/python/bin/bpl/gcc/debug-python/runtime-link-dynamic/shared-linkable-true/bpl.so

(I tried i)using -Wl,-rpath,dir , ii) specifying LD_LIBRARY_PATH , but to
no avail)

jam should be able to figure out the absolute path so couldn't it specify
an absolute path to the shared library file?

cheers

Arnaldur





From david.abrahams at rcn.com  Wed Feb  6 14:40:07 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 6 Feb 2002 08:40:07 -0500
Subject: [C++-sig] Re: Preview of Boost.Python V2 (David Abrahams)
References: <OF4AA915C8.2F997E50-ON00256B58.0036CB71@decode.is>
Message-ID: <01a401c1af14$2809eb70$479dbba7@boostconsulting.com>

----- Original Message -----
From: "Arnaldur Gylfason" <arnaldur at decode.is>


> > I've compiled this code with 6 or 7 different compilers on three
> different
> > OSes,
>
> Pretty good!
>
> > so I'll be really surprised if Python.h was actually not properly
> > referenced... (famous last words, I know)
>
> Well, not this time. It was the wrong Python version.
> I edited PYTHON_VERSION in python.jam, but discovered it is specified in 2
> places. I failed
> to edit the first place.
> Everything compiles and links now.
> This is actually the first time I use boost.jam. Looks good.
> (I decided to go with regular jam when I looked into this half a year ago)

You shouldn't have to edit python.jam. Those are only default settings. If
you set the PYTHON_VERSION variable in your environment or on your Jam
command-line, it will use that version instead.

-Dave




From david.abrahams at rcn.com  Wed Feb  6 14:43:29 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 6 Feb 2002 08:43:29 -0500
Subject: [C++-sig] Preview of Boost.Python V2  problems
References: <OF2215AEC7.E2080C6F-ON00256B58.00403766@decode.is>
Message-ID: <01a501c1af14$446ee6d0$479dbba7@boostconsulting.com>

----- Original Message -----
From: "Arnaldur Gylfason" <arnaldur at decode.is>
To: <c++-sig at python.org>
Sent: Wednesday, February 06, 2002 6:49 AM
Subject: [C++-sig] Preview of Boost.Python V2 problems


> I tried importing 1 of the test modules and got the following error:
>
> >>> import m1
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ImportError:
>
../../libs/python/bin/bpl/gcc/debug-python/runtime-link-dynamic/shared-linka
ble-true/bpl.so:
>
> undefined symbol: _Py_RefTotal


Wow, I guess I left out some important information!
The default build is a debug-python build, which requires a special build of
Python (configured with --with-pydebug). You want a regular debug build,
which you can achieve with -sBUILD=debug on your Jam command-line.

> Another thing, the modules specify a relative path to bpl.so.
> When importing e.g. m1, it can't find bpl.so unlessit it is in
> [prefix]/libs/python since it always looks for
>
../../libs/python/bin/bpl/gcc/debug-python/runtime-link-dynamic/shared-linka
ble-true/bpl.so
>
> (I tried i)using -Wl,-rpath,dir , ii) specifying LD_LIBRARY_PATH , but to
> no avail)
>
> jam should be able to figure out the absolute path so couldn't it specify
> an absolute path to the shared library file?


Yes, this was only recently brought to my attention by Rene Rivera. I
believe he has a patch for this problem, but I'm not sure he's appplied it
yet. Rene?







From arnaldur at decode.is  Wed Feb  6 16:25:34 2002
From: arnaldur at decode.is (Arnaldur Gylfason)
Date: Wed, 6 Feb 2002 15:25:34 +0000
Subject: [C++-sig] Re: Preview of Boost.Python V2 problems
Message-ID: <OFA33E79B4.8F3DE04A-ON00256B58.0054973D@decode.is>

> Wow, I guess I left out some important information!
> The default build is a debug-python build, which requires a special build
of
> Python (configured with --with-pydebug). You want a regular debug build,
> which you can achieve with -sBUILD=debug on your Jam command-line.

OK. That did it. The tests run and pass now.
Time to experiment then.

cheers

Arnaldur




From david.abrahams at rcn.com  Fri Feb  8 18:04:58 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 8 Feb 2002 12:04:58 -0500
Subject: [C++-sig] Python10 experience report
Message-ID: <05ec01c1b0c3$4f3d1900$479dbba7@boostconsulting.com>

Hi Everybody,

I just got back from the Python 10 conference in Alexandria, VA. Some of
what I write below is of general interest to each of the three communities
where I'm cross-posting this report, so some of it is also sure to be of no
interest at all. I hope you'll forgive the waste of bandwidth ;-)

---

Andy Koenig, of all people, was the keynote speaker of this year's opening
plenary session. He presented his "impressions of a polyglot outsider",
which studiously avoided any mention of C++ until the end of his talk, when
he was asked about standardization. I was surprised to learn that the C++
community at large wanted a few more years before beginning but when ANSI
accepted HP's request for a standard, the process was forced to start: it
was a matter of participating or having standardization proceed without
one's input. Andy managed to highlight very effectively the balance of
strengths in Python, one of the most important being its support for
extension via libraries. In many ways that makes Python a good analogue for
C++ in the interpreted world

There were several kind mentions of the Boost.Python library from people who
found it indispensable. I was particularly happy that Karl MacMillan,
Michael Droettboom, and Ichiro Fujinaga from Johns Hopkins is using it to do
OCR on a vast library of music notation, since in a previous life I was an
author of music notation software. These guys are also drawing on Ullrich
Koethe's VIGRA library for image manipulation (Ullrich has been a major
contributor to Boost.Python). They also have a system for writing the
Boost.Python wrapper code in C++ comments, which allows them to keep all of
the code in one place. I've asked them to send me some information on that.

The development of Swig has been gaining momentum again (the basic
description at www.boost.org/libs/python/doc/comparisons.html still
applies). The talk given about it by David Beazly was very well-attended,
and they appear to have quite a few users. Swig's strengths (coverage of
many langauages) and weaknesses (incomplete C++ language support) haven't
changed, although the C++ support seems to have improved considerably - they
now claim to have a complete model of the C++ type system. It seems to be
mostly geared at wrapping what Walter Landry calls "C-Tran": C++ code which
traffics in built-in types with little use of abstraction. I'm not knocking
that, either: I'm sure a lot of that code exists, so it's a valuable
service. One feature Swig has which I'd like to steal is the ability to
unwrap a single Python argument into multiple C++ arguments, for example, by
converting a Python string into a pointer and length. When his talk was
over, David approached me about a possible joint workshop on language
binding, which sounds like a fun idea to me.


I spent some considerable time talking with Steven Knight, the leader of the
Scons build tool effort. We had a lot to share with one another, and I
gained a much better appreciation for many of the Scons design decisions.
Scons seems to be concentrating on being the ultimate build system
substrate, and Steve seemed to think that we were on the right track with
our high-level design. We both hope that the Boost.Build V2 high-level
architecture can eventually be ported to run on top of Scons.

They also have a highly-refined and successful development procedure which
I'd like to emulate for Boost.Build V2. Among many other things they do,
their source-control system automatically ensures that when you check in a
new test, it is automatically run on the currently checked-in state of the
code, and is expected to fail -- a relatively obvious good idea which I've
never heard before.


Guido Van Rossum's "State of the Python Union" address was full of questions
for the community about what should be done next, but the one idea Guido
seemed to stress was that core language stability and continuing library
development would be a good idea (sound familiar?) I mentioned the Boost
model as a counterpoint to the idea of something like CPAN (the massive Perl
library archives), and it seemed to generate some significant interest. I've
offered to work with anyone from the Python community who wants to set up
something like Boost.

There was some discussion of "string interpolation" (variable substitution
in strings), and Guido mentioned that he had some thoughts about the
strengths/weaknesses of Python's formatting interface. It might be useful
for those working on formatting for boost to contact him and find out what
he has to say.

Ka-Ping Yee demoed a Mailman discussion thread weaver. This tool weaves the
various messages in a discussion thread into a single document so you can
follow the entire conversation. Since we're looking very seriously at moving
Boost to Mailman, this could be a really useful thing for us to have. If we
do this, we'll move the yahoogroups discussions into the mailman archive so
old discussions can be easily accessed in the same fashion.

And, just because it's cool, though perhaps not relevant:
http://homepages.ulb.ac.be/~arigo/psyco/ is a promising effort to accelerate
the execution of Python code to speeds approaching those of compiled
languages. It reminded me a lot of Todd Veldhuizen's research into moving
parts of C++ template compilation to runtime, only coming from the opposite
end of things. If you're the sort of hardcore type that is fascinated by
that stuff, they could use some help.


-Dave




From david.abrahams at rcn.com  Fri Feb 15 20:52:42 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 15 Feb 2002 14:52:42 -0500
Subject: [C++-sig] Boost.Python V2 Documentation Preview
Message-ID: <0e7801c1b65a$a7709650$0500a8c0@boostconsulting.com>

You can find the evolving documentation for Boost.Python V2 in the
libs/python/doc/V2 module of the Boost CVS repository, or you can browse the
current CVS state on-line at http://makeashorterlink.com/?F25052C6. There
are still many broken links, and as with the code, there are lots of details
not yet filled in, but it could still be useful to anyone trying to form a
mental picture of the V2 design.

Regards,
Dave

+---------------------------------------------------------------+
                  David Abrahams
      C++ Booster (http://www.boost.org)               O__  ==
      Pythonista (http://www.python.org)              c/ /'_ ==
  resume: http://users.rcn.com/abrahams/resume.html  (*) \(*) ==
          email: david.abrahams at rcn.com
+---------------------------------------------------------------+




From minxu at sci.ccny.cuny.edu  Sat Feb 16 16:57:01 2002
From: minxu at sci.ccny.cuny.edu (Min Xu)
Date: 16 Feb 2002 10:57:01 -0500
Subject: [C++-sig] Lifetime of Python object for a pointer argument
Message-ID: <1013875021.1078.17.camel@inspiron>

Hi, 

I am a newbie of boost python. In the process of converting a SWIG
wrapping of a C++ library to boost python, I encounter the following
problem:

// C++ part
class grid
{
public:
   grid() { ... }
   ...
};

class geometry 
{ 
public:
    geometry(const grid * gd) : gd(gd) {}
    const grid* getGrid() const { return gd; }
private:
    const grid* gd;
};

// Wrapper
#include <boost/python/class_builder.hpp>
namespace python = boost::python;

PyObject* to_python(const grid* g) {
     return to_python(*g); // convert const grid* in terms of const 
grid&
}

BOOST_PYTHON_MODULE_INIT(ngf2)
{
  try
  {
    python::module_builder this_module("ngf2");
    python::class_builder<grid> grid_class(this_module, "grid");
    grid_class.def(python::constructor<>());
    python::class_builder<geometry> geometry_class(this_module,
"geometry");
    geometry_class.def(python::constructor<const grid*>());
  }
  ...
}

The compilation works well (the newest CVS version of boost python).
In python:
>>> from ngf2 import *
>>> a=geometry (grid())
>>> a.getGrid ().a()
8.6723632812500586   # corrupted as grid() is deleted automatically? 
>>> g=grid()
>>> b=geometry (g)
>>> b.getGrid ().a() 
1.0                  # expected.
>>> del g
>>> b.getGrid ().a()
1.3285421879284814e-269 # corrupted 

I understand it may be a ref counting problem. Is there any way to make
the first idiom work? 

Thanks!


Min Xu

 





From achim.domma at syynx.de  Sat Feb 16 17:14:12 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sat, 16 Feb 2002 17:14:12 +0100
Subject: [C++-sig] Lifetime of Python object for a pointer argument
In-Reply-To: <1013875021.1078.17.camel@inspiron>
Message-ID: <FCEMIEFBFOIDAOJDEPIAMELJDAAA.achim.domma@syynx.de>

Hi,

I'm also not an expert, so hopefully Dave will correct my if I'm wrong. As
far as I know it's in general not an good idea to pass objekts as pointers
in the current version of boost.python, so you should prefer passing
parameters by value.

> // C++ part
> class grid
> {
> public:
>    grid() { ... }
>    ...
> };

Do you allocate dynamic memory in grid ? If yes, is the copy-constructor
implemented ?

greetings
Achim






From minxu at sci.ccny.cuny.edu  Sat Feb 16 17:40:50 2002
From: minxu at sci.ccny.cuny.edu (Min Xu)
Date: 16 Feb 2002 11:40:50 -0500
Subject: [C++-sig] Lifetime of Python object for a pointer argument
In-Reply-To: <FCEMIEFBFOIDAOJDEPIAMELJDAAA.achim.domma@syynx.de>
References: <FCEMIEFBFOIDAOJDEPIAMELJDAAA.achim.domma@syynx.de>
Message-ID: <1013877650.5363.55.camel@inspiron>

On Sat, 2002-02-16 at 11:14, Achim Domma wrote:
> Hi,
> 
> I'm also not an expert, so hopefully Dave will correct my if I'm wrong. As
> far as I know it's in general not an good idea to pass objekts as pointers
> in the current version of boost.python, so you should prefer passing
> parameters by value.
According to the document section on pointers and smart pointers, the
const ptr* as an argument is handled automatically. 

An return value of type const ptr* does work in this code. See

>>> g=grid()
>>> a=geometry (g)
>>> b=a.getGrid ()
>>> del a
>>> b.a()
1.0 	# Expected. b has a separate life from a as the copy constructor is
used in b=a.getGrid()

> 
> > // C++ part
> > class grid
> > {
> > public:
> >    grid() { ... }
> >    ...
> > };
> 
> Do you allocate dynamic memory in grid ? If yes, is the copy-constructor
> implemented ?
> 
The grid class does not dynamic allocate memory and the copy constructor
is implemented. 

The simplified class of grid is like this:

class grid
{
public: 
	grid() : _a(1) {...}
	grid(double a, ...) : _a(a) {...}
        grid(const grid& g) {...}
	double a() const { return _a; }
private:
	double _a;
};

> greetings
> Achim
Thanks.

> 
> 
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 





From david.abrahams at rcn.com  Sat Feb 16 17:41:20 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 16 Feb 2002 11:41:20 -0500
Subject: [C++-sig] Lifetime of Python object for a pointer argument
References: <1013875021.1078.17.camel@inspiron>
Message-ID: <017101c1b709$75a0ddb0$0500a8c0@boostconsulting.com>

Your analysis of what's going wrong here is correct. There is a way to make
what you're doing "work" with Boost.Python V1, but it's ugly. You have to
wrap geometry with a "callback" class as though it had virtual
functions(www.boost.org/libs/python/doc/overriding.html):

// Warning: off-the-cuff, untested

struct geometry_callback : geometry
{
    geometry(PyObject* self, PyObject* grid_obj)
        : grid_obj(grid_obj)
    { Py_XINCREF(grid_obj); }

    ~geometry() { Py_XDECREF(grid_obj); }

    PyObject* grid_obj;
};

python::class_builder<geometry, geometry_callback>
geometry_class(this_module, "geometry");
...

but note, that your to_python(const grid*) function also results in the grid
being /copied/ (probably not what you want). Boost.Python V2 (currently in
prerelease) provides a better approach:

BOOST_PYTHON_MODULE_INIT(ngf2)
{
   python::module("ngf2)
      .add(
           class<grid>("grid")
               .def_init()
          )
      .add(
           class<geometry>("geometry")

              .def_init(args<const grid*>()
              // Keep the grid alive as long as the geometry is.
                        , python::with_custodian_and_ward<1,2>())

              .def("getGrid", &geometry::getGrid
              // keep the geometry object alive as long as the result is
                   , python::return_internal_reference<>())
          );
}

----- Original Message -----
From: "Min Xu" <minxu at sci.ccny.cuny.edu>
> Hi,
>
> I am a newbie of boost python. In the process of converting a SWIG
> wrapping of a C++ library to boost python, I encounter the following
> problem:
>
> // C++ part
> class grid
> {
> public:
>    grid() { ... }
>    ...
> };
>
> class geometry
>

> public:
>     geometry(const grid * gd) : gd(gd) {}
>     const grid* getGrid() const { return gd; }
> private:
>     const grid* gd;
> };
>
> // Wrapper
> #include <boost/python/class_builder.hpp>
> namespace python = boost::python;
>
> PyObject* to_python(const grid* g) {
>      return to_python(*g); // convert const grid* in terms of const
> grid&
> }
>
> BOOST_PYTHON_MODULE_INIT(ngf2)
> {
>   try
>   {
>     python::module_builder this_module("ngf2");
>     python::class_builder<grid> grid_class(this_module, "grid");
>     grid_class.def(python::constructor<>());
>     python::class_builder<geometry> geometry_class(this_module,
> "geometry");
>     geometry_class.def(python::constructor<const grid*>());
>   }
>   ...
> }
>
> The compilation works well (the newest CVS version of boost python).
> In python:
> >>> from ngf2 import *
> >>> a=geometry (grid())
> >>> a.getGrid ().a()
> 8.6723632812500586   # corrupted as grid() is deleted automatically?
> >>> g=grid()
> >>> b=geometry (g)
> >>> b.getGrid ().a()
> 1.0                  # expected.
> >>> del g
> >>> b.getGrid ().a()
> 1.3285421879284814e-269 # corrupted
>
> I understand it may be a ref counting problem. Is there any way to make
> the first idiom work?
>
> Thanks!
>
>
> Min Xu
>
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>




From david.abrahams at rcn.com  Sat Feb 16 17:54:14 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 16 Feb 2002 11:54:14 -0500
Subject: [C++-sig] Lifetime of Python object for a pointer argument
References: <FCEMIEFBFOIDAOJDEPIAMELJDAAA.achim.domma@syynx.de>
Message-ID: <018301c1b70a$ae359e30$0500a8c0@boostconsulting.com>

----- Original Message -----
From: "Achim Domma" <achim.domma at syynx.de>
To: <c++-sig at python.org>
Sent: Saturday, February 16, 2002 11:14 AM
Subject: RE: [C++-sig] Lifetime of Python object for a pointer argument


> Hi,
>
> I'm also not an expert, so hopefully Dave will correct my if I'm wrong. As
> far as I know it's in general not an good idea to pass objekts as pointers
> in the current version of boost.python, so you should prefer passing
> parameters by value.

You can pass them, but it's usually a bad idea to hang onto them since as
Min's code demonstrates, there's no way of managing the lifetime of the
referent. Returning pointers is even more problematic.

Smart pointers provide the information you need to manage things properly if
you need reference semantics.


> > // C++ part
> > class grid
> > {
> > public:
> >    grid() { ... }
> >    ...
> > };
>
> Do you allocate dynamic memory in grid ? If yes, is the copy-constructor
> implemented ?

It was my first instinct to ask about that, too, but I don't think that's
his problem.

-Dave




From minxu at sci.ccny.cuny.edu  Sat Feb 16 18:51:25 2002
From: minxu at sci.ccny.cuny.edu (Min Xu)
Date: 16 Feb 2002 12:51:25 -0500
Subject: [C++-sig] Lifetime of Python object for a pointer argument
In-Reply-To: <017101c1b709$75a0ddb0$0500a8c0@boostconsulting.com>
References: <1013875021.1078.17.camel@inspiron> 
	<017101c1b709$75a0ddb0$0500a8c0@boostconsulting.com>
Message-ID: <1013881885.1078.61.camel@inspiron>

Thank you for the nice and quick reply. I downloaded the v2. However in
<boost_root>/libs/python
# jam -sBOOST_ROOT=/usr/local/src/boost -sTOOLS="gcc" -sBUILD=debug 
unknown target type for <libs!python>libbpl.a

The machine is a linux box with gcc and python2.1. How can I compile it?

On Sat, 2002-02-16 at 11:41, David Abrahams wrote:
> Your analysis of what's going wrong here is correct. There is a way to make
> what you're doing "work" with Boost.Python V1, but it's ugly. You have to
> wrap geometry with a "callback" class as though it had virtual
> functions(www.boost.org/libs/python/doc/overriding.html):
> 
> // Warning: off-the-cuff, untested
> 
> struct geometry_callback : geometry
> {
>     geometry(PyObject* self, PyObject* grid_obj)
>         : grid_obj(grid_obj)
>     { Py_XINCREF(grid_obj); }
> 
>     ~geometry() { Py_XDECREF(grid_obj); }
> 
>     PyObject* grid_obj;
> };
> 
> python::class_builder<geometry, geometry_callback>
> geometry_class(this_module, "geometry");
> ...
> 
> but note, that your to_python(const grid*) function also results in the grid
> being /copied/ (probably not what you want). Boost.Python V2 (currently in
> prerelease) provides a better approach:
> 
> BOOST_PYTHON_MODULE_INIT(ngf2)
> {
>    python::module("ngf2)
>       .add(
>            class<grid>("grid")
>                .def_init()
>           )
>       .add(
>            class<geometry>("geometry")
> 
>               .def_init(args<const grid*>()
>               // Keep the grid alive as long as the geometry is.
>                         , python::with_custodian_and_ward<1,2>())
> 
>               .def("getGrid", &geometry::getGrid
>               // keep the geometry object alive as long as the result is
>                    , python::return_internal_reference<>())
>           );
> }
> 
> ----- Original Message -----
> From: "Min Xu" <minxu at sci.ccny.cuny.edu>
> > Hi,
> >
> > I am a newbie of boost python. In the process of converting a SWIG
> > wrapping of a C++ library to boost python, I encounter the following
> > problem:
> >
> > // C++ part
> > class grid
> > {
> > public:
> >    grid() { ... }
> >    ...
> > };
> >
> > class geometry
> >
> 
> > public:
> >     geometry(const grid * gd) : gd(gd) {}
> >     const grid* getGrid() const { return gd; }
> > private:
> >     const grid* gd;
> > };
> >
> > // Wrapper
> > #include <boost/python/class_builder.hpp>
> > namespace python = boost::python;
> >
> > PyObject* to_python(const grid* g) {
> >      return to_python(*g); // convert const grid* in terms of const
> > grid&
> > }
> >
> > BOOST_PYTHON_MODULE_INIT(ngf2)
> > {
> >   try
> >   {
> >     python::module_builder this_module("ngf2");
> >     python::class_builder<grid> grid_class(this_module, "grid");
> >     grid_class.def(python::constructor<>());
> >     python::class_builder<geometry> geometry_class(this_module,
> > "geometry");
> >     geometry_class.def(python::constructor<const grid*>());
> >   }
> >   ...
> > }
> >
> > The compilation works well (the newest CVS version of boost python).
> > In python:
> > >>> from ngf2 import *
> > >>> a=geometry (grid())
> > >>> a.getGrid ().a()
> > 8.6723632812500586   # corrupted as grid() is deleted automatically?
> > >>> g=grid()
> > >>> b=geometry (g)
> > >>> b.getGrid ().a()
> > 1.0                  # expected.
> > >>> del g
> > >>> b.getGrid ().a()
> > 1.3285421879284814e-269 # corrupted
> >
> > I understand it may be a ref counting problem. Is there any way to make
> > the first idiom work?
> >
> > Thanks!
> >
> >
> > Min Xu
> >
> >
> >
> >
> >
> > _______________________________________________
> > C++-sig mailing list
> > C++-sig at python.org
> > http://mail.python.org/mailman/listinfo/c++-sig
> >
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 





From david.abrahams at rcn.com  Sat Feb 16 19:19:02 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 16 Feb 2002 13:19:02 -0500
Subject: [C++-sig] Lifetime of Python object for a pointer argument
References: <1013875021.1078.17.camel@inspiron> <017101c1b709$75a0ddb0$0500a8c0@boostconsulting.com> <1013881885.1078.61.camel@inspiron>
Message-ID: <019501c1b716$6d392670$0500a8c0@boostconsulting.com>

----- Original Message -----
From: "Min Xu" <minxu at sci.ccny.cuny.edu>
To: <c++-sig at python.org>
Sent: Saturday, February 16, 2002 12:51 PM
Subject: Re: [C++-sig] Lifetime of Python object for a pointer argument


> Thank you for the nice and quick reply. I downloaded the v2. However in
> <boost_root>/libs/python
> # jam -sBOOST_ROOT=/usr/local/src/boost -sTOOLS="gcc" -sBUILD=debug
> unknown target type for <libs!python>libbpl.a
>
> The machine is a linux box with gcc and python2.1. How can I compile it?

Firstly, Python 2.2 is required for Boost.Python V2 (so you'll
need -sPYTHON_VERSION=2.2 in the command-line)

Secondly, I've seen that bug, but I just fixed it and tested it on linux
with gcc last night.
Are you sure you are using the current CVS state?





From minxu at sci.ccny.cuny.edu  Sat Feb 16 22:03:09 2002
From: minxu at sci.ccny.cuny.edu (Min Xu)
Date: 16 Feb 2002 16:03:09 -0500
Subject: [C++-sig] Lifetime of Python object for a pointer argument
In-Reply-To: <019501c1b716$6d392670$0500a8c0@boostconsulting.com>
References: <1013875021.1078.17.camel@inspiron>
	<017101c1b709$75a0ddb0$0500a8c0@boostconsulting.com>
	<1013881885.1078.61.camel@inspiron> 
	<019501c1b716$6d392670$0500a8c0@boostconsulting.com>
Message-ID: <1013893390.5363.181.camel@inspiron>

On Sat, 2002-02-16 at 13:19, David Abrahams wrote:
> 
> ----- Original Message -----
> From: "Min Xu" <minxu at sci.ccny.cuny.edu>
> To: <c++-sig at python.org>
> Sent: Saturday, February 16, 2002 12:51 PM
> Subject: Re: [C++-sig] Lifetime of Python object for a pointer argument
> 
> 
> > Thank you for the nice and quick reply. I downloaded the v2. However in
> > <boost_root>/libs/python
> > # jam -sBOOST_ROOT=/usr/local/src/boost -sTOOLS="gcc" -sBUILD=debug
> > unknown target type for <libs!python>libbpl.a
> >
> > The machine is a linux box with gcc and python2.1. How can I compile it?
> 
> Firstly, Python 2.2 is required for Boost.Python V2 (so you'll
> need -sPYTHON_VERSION=2.2 in the command-line)
> 
> Secondly, I've seen that bug, but I just fixed it and tested it on linux
> with gcc last night.
> Are you sure you are using the current CVS state?
> 
I deleted my old tree (downloaded yesterday) and reget the source:

 cvs -z3 -d:pserver:anonymous at cvs.boost.sourceforge.net:/cvsroot/boost
co boost

and then in boost-root:
 cvs update -dRP -rmpl-development boost/mpl

This time it works. And m1.so m2.so etc are also ok.

Howerver, I have enum and operators (op_add, op_sub etc) in the library
which are handled correctly in boost.python v1. What is the right way in
v2 for them?

Thanks again.




> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 





From david.abrahams at rcn.com  Sat Feb 16 22:45:55 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 16 Feb 2002 16:45:55 -0500
Subject: [C++-sig] Lifetime of Python object for a pointer argument
References: <1013875021.1078.17.camel@inspiron><017101c1b709$75a0ddb0$0500a8c0@boostconsulting.com><1013881885.1078.61.camel@inspiron> <019501c1b716$6d392670$0500a8c0@boostconsulting.com> <1013893390.5363.181.camel@inspiron>
Message-ID: <01b301c1b733$52ed19d0$0500a8c0@boostconsulting.com>

----- Original Message -----
From: "Min Xu" <minxu at sci.ccny.cuny.edu>
To: <c++-sig at python.org>
Sent: Saturday, February 16, 2002 4:03 PM
Subject: Re: [C++-sig] Lifetime of Python object for a pointer argument


> On Sat, 2002-02-16 at 13:19, David Abrahams wrote:
> >
> > ----- Original Message -----
> > From: "Min Xu" <minxu at sci.ccny.cuny.edu>
> > To: <c++-sig at python.org>
> > Sent: Saturday, February 16, 2002 12:51 PM
> > Subject: Re: [C++-sig] Lifetime of Python object for a pointer argument
> >
> >
> > > Thank you for the nice and quick reply. I downloaded the v2. However
in
> > > <boost_root>/libs/python
> > > # jam -sBOOST_ROOT=/usr/local/src/boost -sTOOLS="gcc" -sBUILD=debug
> > > unknown target type for <libs!python>libbpl.a
> > >
> > > The machine is a linux box with gcc and python2.1. How can I compile
it?
> >
> > Firstly, Python 2.2 is required for Boost.Python V2 (so you'll
> > need -sPYTHON_VERSION=2.2 in the command-line)
> >
> > Secondly, I've seen that bug, but I just fixed it and tested it on linux
> > with gcc last night.
> > Are you sure you are using the current CVS state?
> >
> I deleted my old tree (downloaded yesterday) and reget the source:
>
>  cvs -z3 -d:pserver:anonymous at cvs.boost.sourceforge.net:/cvsroot/boost
> co boost
>
> and then in boost-root:
>  cvs update -dRP -rmpl-development boost/mpl
>
> This time it works. And m1.so m2.so etc are also ok.
>
> Howerver, I have enum and operators (op_add, op_sub etc) in the library
> which are handled correctly in boost.python v1. What is the right way in
> v2 for them?

Unfortunately, those features aren't specifically implemented in v2 yet.
Operators are supported in the usual Python way (i.e. you can expose an
__add__ function), but the automatic wrapping features of v1 are not yet
available. I have not yet decided where this fits in the development plan.
If you wanted to contribute some code it would be very much appreciated, of
course.

Enums can be exposed as ints using the techniques with which scalars are
exposed in libs/python/src/converter/builtin_converters.cpp, but that code
was mostly written to be implementation detail. I guess I need to clean up
and document most of those classes so that users can take advantage of them.

However, I think I've come to *yet another* realization about how the
low-level from_python conversion mechanism should work, so I guess I will be
re-engineering most of what's in builtin_converters.cpp at some point in the
next month or so; you might not want to invest in understanding that.

Finally, <redfaced>I just realized that I haven't yet implemented the use of
CallPolicies in __init__ functions</redfaced>, so this won't compile:

              .def_init(args<const grid*>()
              // Keep the grid alive as long as the geometry is.
                        , python::with_custodian_and_ward<1,2>())

Give me at least until Monday to take care of that.

Anyway, thanks for looking at v2. ;-)

-Dave





From minxu at sci.ccny.cuny.edu  Sun Feb 17 17:26:25 2002
From: minxu at sci.ccny.cuny.edu (Min Xu)
Date: 17 Feb 2002 11:26:25 -0500
Subject: class derivation in boost.python v2. Was Re: [C++-sig] Lifetime of
	Python object for a pointer argument
In-Reply-To: <01b301c1b733$52ed19d0$0500a8c0@boostconsulting.com>
References: 
	<1013875021.1078.17.camel@inspiron><017101c1b709$75a0ddb0$0500a8c0@boostcons
	 ulting.com><1013881885.1078.61.camel@inspiron>
	<019501c1b716$6d392670$0500a8c0@boostconsulting.com>
	<1013893390.5363.181.camel@inspiron> 
	<01b301c1b733$52ed19d0$0500a8c0@boostconsulting.com>
Message-ID: <1013963187.5363.196.camel@inspiron>

> Unfortunately, those features aren't specifically implemented in v2 yet.
> Operators are supported in the usual Python way (i.e. you can expose an
> __add__ function), but the automatic wrapping features of v1 are not yet
> available. I have not yet decided where this fits in the development plan.
> If you wanted to contribute some code it would be very much appreciated, of
> course.
I hope so.

> 
> Enums can be exposed as ints using the techniques with which scalars are
> exposed in libs/python/src/converter/builtin_converters.cpp, but that code
> was mostly written to be implementation detail. I guess I need to clean up
> and document most of those classes so that users can take advantage of them.
> 
> However, I think I've come to *yet another* realization about how the
> low-level from_python conversion mechanism should work, so I guess I will be
> re-engineering most of what's in builtin_converters.cpp at some point in the
> next month or so; you might not want to invest in understanding that.
> 
I redefine the enumeration as int as a temporal solution.

> Finally, <redfaced>I just realized that I haven't yet implemented the use of
> CallPolicies in __init__ functions</redfaced>, so this won't compile:
> 
>               .def_init(args<const grid*>()
>               // Keep the grid alive as long as the geometry is.
>                         , python::with_custodian_and_ward<1,2>())
> 
> Give me at least until Monday to take care of that.
> 
Thanks. However the following bug may be more severe. A very simple code
is as following. It compiles yet makes python2.2 core dump.

#include <boost/python/module.hpp>
#include <boost/python/class.hpp>

class A
{
public:
	A() : x(0) {}
	A(const A& a) : x(a.x) {}
private:
	double x;
};

class AA : public A
{
public:
	AA(const A& a) : A(a) {}
};

namespace python = boost::python;

BOOST_PYTHON_MODULE_INIT(AA)
{
  try
  {
      python::module("AA")
	  .add(
	      python::class_<A>("A")
	      .def_init(args<>())
	      )
	  .add(
	      python::class_<AA, bases<A> >("AA")
	      .def_init(args<const A&>())
	      );
  }
  catch(...)
  {
      //python::handle_exception(); // Deal with the exception for Python
  }
}

g++ -I/usr/local/include -I/usr/include/python2.2  -c -Wall
-ftemplate-depth-100  -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_V2  -g
-O0 -fno-inline -fPIC tst.C
g++ -g -fpic -shared -o AA.so -L/usr/lib/python2.2/config
-I/usr/include/python2.2 -I/usr/local/include tst.o -lutil  -lbpl

And in python2.2:
>>> import AA
Segmentation fault (core dumped)


Min Xu




From david.abrahams at rcn.com  Sun Feb 17 23:39:15 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sun, 17 Feb 2002 17:39:15 -0500
Subject: class derivation in boost.python v2. Was Re: [C++-sig] Lifetime ofPython object for a pointer argument
References: <1013875021.1078.17.camel@inspiron><017101c1b709$75a0ddb0$0500a8c0@boostcons ulting.com><1013881885.1078.61.camel@inspiron><019501c1b716$6d392670$0500a8c0@boostconsulting.com><1013893390.5363.181.camel@inspiron> <01b301c1b733$52ed19d0$0500a8c0@boostconsulting.com> <1013963187.5363.196.camel@inspiron>
Message-ID: <02ed01c1b804$577463b0$0500a8c0@boostconsulting.com>

Thanks, that's one bug of mine and one of yours. I've fixed mine -- it was
crashing instead of properly reporting your error. You need to wrap the base
class (A) before you wrap the derived (AA). I know it looks like you are,
but don't forget there's no sequence point in that chain of calls to
guarantee argument initialization order in C++. The correct module is:

BOOST_PYTHON_MODULE_INIT(AA)
{
    python::module m("AA");

    m.add(
        python::class_<A>("A")
        .def_init()
        );

    m.add(
        python::class_<AA, bases<A> >("AA")
        .def_init(args<const A&>())
        )
        ;
}

You don't need the try/catch block ;-)

(Aside) How did you build bpl.so? If you use the debug-python build (the
default in libs/python/Jamfile), you need a Python configured
with --with-pydebug. Otherwise, you need the "debug" or "release" builds of
bpl.

----- Original Message -----
From: "Min Xu" <minxu at sci.ccny.cuny.edu>
To: <c++-sig at python.org>
Sent: Sunday, February 17, 2002 11:26 AM
Subject: class derivation in boost.python v2. Was Re: [C++-sig] Lifetime
ofPython object for a pointer argument


> > Unfortunately, those features aren't specifically implemented in v2 yet.
> > Operators are supported in the usual Python way (i.e. you can expose an
> > __add__ function), but the automatic wrapping features of v1 are not yet
> > available. I have not yet decided where this fits in the development
plan.
> > If you wanted to contribute some code it would be very much appreciated,
of
> > course.
> I hope so.
>
> >
> > Enums can be exposed as ints using the techniques with which scalars are
> > exposed in libs/python/src/converter/builtin_converters.cpp, but that
code
> > was mostly written to be implementation detail. I guess I need to clean
up
> > and document most of those classes so that users can take advantage of
them.
> >
> > However, I think I've come to *yet another* realization about how the
> > low-level from_python conversion mechanism should work, so I guess I
will be
> > re-engineering most of what's in builtin_converters.cpp at some point in
the
> > next month or so; you might not want to invest in understanding that.
> >
> I redefine the enumeration as int as a temporal solution.
>
> > Finally, <redfaced>I just realized that I haven't yet implemented the
use of
> > CallPolicies in __init__ functions</redfaced>, so this won't compile:
> >
> >               .def_init(args<const grid*>()
> >               // Keep the grid alive as long as the geometry is.
> >                         , python::with_custodian_and_ward<1,2>())
> >
> > Give me at least until Monday to take care of that.
> >
> Thanks. However the following bug may be more severe. A very simple code
> is as following. It compiles yet makes python2.2 core dump.
>
> #include <boost/python/module.hpp>
> #include <boost/python/class.hpp>
>
> class A
> {
> public:
> A() : x(0) {}
> A(const A& a) : x(a.x) {}
> private:
> double x;
> };
>
> class AA : public A
> {
> public:
> AA(const A& a) : A(a) {}
> };
>
> namespace python = boost::python;
>
> BOOST_PYTHON_MODULE_INIT(AA)
> {
>   try
>   {
>       python::module("AA")
>   .add(
>       python::class_<A>("A")
>       .def_init(args<>())
>       )
>   .add(
>       python::class_<AA, bases<A> >("AA")
>       .def_init(args<const A&>())
>       );
>   }
>   catch(...)
>   {
>       file://python::handle_exception(); // Deal with the exception for
Python
>   }
> }
>
> g++ -I/usr/local/include -I/usr/include/python2.2  -c -Wall
> -ftemplate-depth-100  -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_V2  -g
> -O0 -fno-inline -fPIC tst.C
> g++ -g -fpic -shared -o AA.so -L/usr/lib/python2.2/config
> -I/usr/include/python2.2 -I/usr/local/include tst.o -lutil  -lbpl
>
> And in python2.2:
> >>> import AA
> Segmentation fault (core dumped)
>
>
> Min Xu
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig




From franke at ableton.com  Mon Feb 18 18:23:43 2002
From: franke at ableton.com (Stefan Franke)
Date: Mon, 18 Feb 2002 18:23:43 +0100
Subject: [C++-sig] Wrapping already refcounted C++ types
Message-ID: <6FB30F72F5FF9145B785936278BC25C802B6A4@exserver.ouroffice.de>

Dear group,

I would like to wrap a couple of C++ classes in a library that
already implements its own reference counting.

The instances are never copied by value but referenced either

(a) by plain C pointers or
(b) by their respective smart pointer class

So I have to write to_python() and from_python() conversions 
for these pointer types.

The behaviour I'd like to implement for case (a) is that the
wrapper object increments the original instance's refcount when 
created and releases the reference on destruction.

My questions are:

- Where are the right places to put the respective incref/decrefs?
- What to do in case (b)


Best regards
Stefan Franke




From franke at ableton.com  Mon Feb 18 19:57:09 2002
From: franke at ableton.com (Stefan Franke)
Date: Mon, 18 Feb 2002 19:57:09 +0100
Subject: [C++-sig] First time pointers, first crash...
Message-ID: <6FB30F72F5FF9145B785936278BC25C802B6A5@exserver.ouroffice.de>

I've just started trying to wrap a few of my class with Boost.Python.
While the first toy examples worked well, trying to use raw pointers
leads to the following problem.

I don't think that the problem depends on the wrapped classes since
it appears with following example as well:

	struct foo { int i; };

	// create one global instance for the whole lifetime of the program
	foo *pFoo = new foo();
	foo *GetFoo() { return pFoo; }

	BOOST_PYTHON_BEGIN_CONVERSION_NAMESPACE
	  PyObject* to_python(foo* p)
	  {
	      return
boost::python::python_extension_class_converters<foo>::smart_ptr_to_python(p
);
	  }
	  PyObject* to_python(const foo* p)
	  {
	      return to_python(const_cast<foo*>(p));
	  }
	BOOST_PYTHON_END_CONVERSION_NAMESPACE


	BOOST_PYTHON_MODULE_INIT(CompoundModule)
	{
	  py::module_builder this_module("compound2");

	  py::class_builder<foo> FooWrapper(this_module, "foo");
	  this_module.def(GetFoo, "getfoo");
	}

If I compile & run run this in debug mode (with BOOST_DEBUG_PYTHON enabled)
and then type

>>> from compound2 import *
>>> getfoo()
>>> 2         # to release the reference that _ holds to the last result

it gives the following error on my Win2k/Visual Studio 6 SP5 box:

	HEAP[boosttest.exe]: Invalid Address specified to RtlValidateHeap( b60000,
3213ac0 )

I've attached the call stack below. In release mode it works, since there
are
propably no heap checks.

What I don't understand is if the foo wrapper calls foo's destructor when
the wrapper object is destroyed. As far as I understand the doc, it only
says that I have to take care that the object is not accidently deleted
in C++ while the wrapper is still alive?

Can you help me?
Stefan


--------------------------------------------------------------------------
Call Stack:

NTDLL! 77f9f9df()
NTDLL! 77fb4966()
NTDLL! 77f8b3d2()
KERNEL32! 77e844cd()
_CrtIsValidHeapPointer(const void * 0x03213ae0) line 1697
_free_dbg_lk(void * 0x03213ae0, int 1) line 1044 + 9 bytes
_free_dbg(void * 0x03213ae0, int 1) line 1001 + 13 bytes
free(void * 0x03213ae0) line 956 + 11 bytes
operator delete(void * 0x03213ae0) line 7 + 9 bytes
boost::python::detail::extension_instance::`scalar deleting
destructor'(unsigned int 1) + 56 bytes
boost::python::class_t<boost::python::detail::extension_instance>::delete_in
stance(_object * 0x03213ae0) line 278 + 44 bytes
boost::python::detail::class_base::instance_dealloc(_object * 0x03213ae0)
line 345 + 20 bytes
boost::_mfi::mf<void>::inner_cmf1<void,boost::python::detail::type_object_ba
se,_object *,void (__thiscall
boost::python::detail::type_object_base::*)(_object *)const >::call() line
166 + 35 bytes
boost::_mfi::mf<void>::inner_cmf1<void,boost::python::detail::type_object_ba
se,_object *,void (__thiscall
boost::python::detail::type_object_base::*)(_object *)const >::operator()()
line 176
boost::_bi::evaluator2<void>::eval(const
boost::_bi::list2<boost::_bi::value<boost::python::detail::type_object_base
*>,boost::_bi::value<_object *> > & {...},
boost::_mfi::cmf1<void,boost::python::detail::type_object_base,_object *>
{...}, boost::_bi::list0 & {...}) line 698
boost::_bi::bind_t_generator<void>::implementation<boost::_mfi::cmf1<void,bo
ost::python::detail::type_object_base,_object
*>,boost::_bi::list2<boost::_bi::value<boost::python::detail::type_object_ba
se *>,boost::_bi::value<_object *> > >::operator()() line 21 + 26 bytes
boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void,
boost::_mfi::cmf1<void,boost::python::detail::type_object_base,_object
*>,boost::_bi::list2<boost::_bi::value<boost::python::detail::type_object_ba
se *>,boost::_bi::value<813e4f84(boost::detail::function::any_pointer {...})
line 129
boost::function0<void,boost::empty_function_policy,boost::empty_function_mix
in,int>::operator()() line 302 + 19 bytes
boost::python::handle_exception_impl(boost::function0<void,boost::empty_func
tion_policy,boost::empty_function_mixin,int> {...}) line 21
boost::python::handle_exception(boost::_bi::bind_t<void,boost::_mfi::cmf1<vo
id,boost::python::detail::type_object_base,_object
*>,boost::_bi::list2<boost::_bi::value<boost::python::detail::type_object_ba
se *>,boost::_bi::value<_object *> > > {...}) line 30 + 35 bytes
do_instance_dealloc(_object * 0x03213ae0) line 182 + 101 bytes
_Py_Dealloc(_object * 0x03213ae0) line 1820 + 7 bytes
insertdict(_dictobject * 0x01bc0188, _object * 0x01c9b3c0, long -724865314,
_object * 0x1e172aa8 __Py_NoneStruct) line 373 + 59 bytes
PyDict_SetItem(_object * 0x01bc0188, _object * 0x01c9b3c0, _object *
0x1e172aa8 __Py_NoneStruct) line 541 + 21 bytes
PyObject_GenericSetAttr(_object * 0x01bc00b8, _object * 0x01c9b3c0, _object
* 0x1e172aa8 __Py_NoneStruct) line 1335 + 17 bytes
PyObject_SetAttr(_object * 0x01bc00b8, _object * 0x01c9b3c0, _object *
0x1e172aa8 __Py_NoneStruct) line 1153 + 18 bytes
PyObject_SetAttrString(_object * 0x01bc00b8, char * 0x1e18d0a4, _object *
0x1e172aa8 __Py_NoneStruct) line 1078 + 17 bytes
sys_displayhook(_object * 0x00000000, _object * 0x01bbd1ac) line 90 + 19
bytes
PyCFunction_Call(_object * 0x019b4a88, _object * 0x01d0d778, _object *
0x00000000) line 90 + 14 bytes
PyObject_Call(_object * 0x019b4a88, _object * 0x01d0d778, _object *
0x00000000) line 1665 + 15 bytes
PyEval_CallObjectWithKeywords(_object * 0x019b4a88, _object * 0x01d0d778,
_object * 0x00000000) line 3038 + 17 bytes
eval_frame(_frame * 0x0320b9d0) line 1330 + 15 bytes
PyEval_EvalCodeEx(PyCodeObject * 0x032184e8, _object * 0x01bd56d0, _object *
0x01bd56d0, _object * * 0x00000000, int 0, _object * * 0x00000000, int 0,
_object * * 0x00000000, int 0, _object * 0x00000000) line 2574 + 9 bytes
PyEval_EvalCode(PyCodeObject * 0x032184e8, _object * 0x01bd56d0, _object *
0x01bd56d0) line 488 + 31 bytes
run_node(_node * 0x03208850, char * 0x1e17d9b0, _object * 0x01bd56d0,
_object * 0x01bd56d0, PyCompilerFlags * 0x0076e274 struct PyCompilerFlags
flags) line 1083 + 17 bytes
run_err_node(_node * 0x03208850, char * 0x1e17d9b0, _object * 0x01bd56d0,
_object * 0x01bd56d0, PyCompilerFlags * 0x0076e274 struct PyCompilerFlags
flags) line 1070 + 25 bytes
PyRun_StringFlags(char * 0x01bf4838, int 256, _object * 0x01bd56d0, _object
* 0x01bd56d0, PyCompilerFlags * 0x0076e274 struct PyCompilerFlags  flags)
line 1041 + 80 bytes



Stefan Franke
www.ableton.com




From david.abrahams at rcn.com  Mon Feb 18 20:24:30 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 18 Feb 2002 14:24:30 -0500
Subject: [C++-sig] First time pointers, first crash...
References: <6FB30F72F5FF9145B785936278BC25C802B6A5@exserver.ouroffice.de>
Message-ID: <051e01c1b8b2$1fb52820$0500a8c0@boostconsulting.com>

Is this the whole code?
Where's the cla
Your exact example works for me (Python-2.2, MSVC6Sp4, Win2K).

----- Original Message -----
From: "Stefan Franke" <franke at ableton.com>
To: <c++-sig at python.org>
Sent: Monday, February 18, 2002 1:57 PM
Subject: [C++-sig] First time pointers, first crash...


> I've just started trying to wrap a few of my class with Boost.Python.
> While the first toy examples worked well, trying to use raw pointers
> leads to the following problem.
>
> I don't think that the problem depends on the wrapped classes since
> it appears with following example as well:
>
> struct foo { int i; };
>
> // create one global instance for the whole lifetime of the program
> foo *pFoo = new foo();
> foo *GetFoo() { return pFoo; }
>
> BOOST_PYTHON_BEGIN_CONVERSION_NAMESPACE
>   PyObject* to_python(foo* p)
>   {
>       return
>
boost::python::python_extension_class_converters<foo>::smart_ptr_to_python(p
> );
>   }
>   PyObject* to_python(const foo* p)
>   {
>       return to_python(const_cast<foo*>(p));
>   }
> BOOST_PYTHON_END_CONVERSION_NAMESPACE
>
>
> BOOST_PYTHON_MODULE_INIT(CompoundModule)
> {
>   py::module_builder this_module("compound2");
>
>   py::class_builder<foo> FooWrapper(this_module, "foo");
>   this_module.def(GetFoo, "getfoo");
> }
>
> If I compile & run run this in debug mode (with BOOST_DEBUG_PYTHON
enabled)
> and then type
>
> >>> from compound2 import *
> >>> getfoo()
> >>> 2         # to release the reference that _ holds to the last result
>
> it gives the following error on my Win2k/Visual Studio 6 SP5 box:
>
> HEAP[boosttest.exe]: Invalid Address specified to RtlValidateHeap( b60000,
> 3213ac0 )
>
> I've attached the call stack below. In release mode it works, since there
> are
> propably no heap checks.
>
> What I don't understand is if the foo wrapper calls foo's destructor when
> the wrapper object is destroyed. As far as I understand the doc, it only
> says that I have to take care that the object is not accidently deleted
> in C++ while the wrapper is still alive?
>
> Can you help me?
> Stefan
>
>
> --------------------------------------------------------------------------
> Call Stack:
>
> NTDLL! 77f9f9df()
> NTDLL! 77fb4966()
> NTDLL! 77f8b3d2()
> KERNEL32! 77e844cd()
> _CrtIsValidHeapPointer(const void * 0x03213ae0) line 1697
> _free_dbg_lk(void * 0x03213ae0, int 1) line 1044 + 9 bytes
> _free_dbg(void * 0x03213ae0, int 1) line 1001 + 13 bytes
> free(void * 0x03213ae0) line 956 + 11 bytes
> operator delete(void * 0x03213ae0) line 7 + 9 bytes
> boost::python::detail::extension_instance::`scalar deleting
> destructor'(unsigned int 1) + 56 bytes
>
boost::python::class_t<boost::python::detail::extension_instance>::delete_in
> stance(_object * 0x03213ae0) line 278 + 44 bytes
> boost::python::detail::class_base::instance_dealloc(_object * 0x03213ae0)
> line 345 + 20 bytes
>
boost::_mfi::mf<void>::inner_cmf1<void,boost::python::detail::type_object_ba
> se,_object *,void (__thiscall
> boost::python::detail::type_object_base::*)(_object *)const >::call() line
> 166 + 35 bytes
>
boost::_mfi::mf<void>::inner_cmf1<void,boost::python::detail::type_object_ba
> se,_object *,void (__thiscall
> boost::python::detail::type_object_base::*)(_object *)const
>::operator()()
> line 176
> boost::_bi::evaluator2<void>::eval(const
>
boost::_bi::list2<boost::_bi::value<boost::python::detail::type_object_base
> *>,boost::_bi::value<_object *> > & {...},
> boost::_mfi::cmf1<void,boost::python::detail::type_object_base,_object *>
> {...}, boost::_bi::list0 & {...}) line 698
>
boost::_bi::bind_t_generator<void>::implementation<boost::_mfi::cmf1<void,bo
> ost::python::detail::type_object_base,_object
>
*>,boost::_bi::list2<boost::_bi::value<boost::python::detail::type_object_ba
> se *>,boost::_bi::value<_object *> > >::operator()() line 21 + 26 bytes
>
boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void,
> boost::_mfi::cmf1<void,boost::python::detail::type_object_base,_object
>
*>,boost::_bi::list2<boost::_bi::value<boost::python::detail::type_object_ba
> se *>,boost::_bi::value<813e4f84(boost::detail::function::any_pointer
{...})
> line 129
>
boost::function0<void,boost::empty_function_policy,boost::empty_function_mix
> in,int>::operator()() line 302 + 19 bytes
>
boost::python::handle_exception_impl(boost::function0<void,boost::empty_func
> tion_policy,boost::empty_function_mixin,int> {...}) line 21
>
boost::python::handle_exception(boost::_bi::bind_t<void,boost::_mfi::cmf1<vo
> id,boost::python::detail::type_object_base,_object
>
*>,boost::_bi::list2<boost::_bi::value<boost::python::detail::type_object_ba
> se *>,boost::_bi::value<_object *> > > {...}) line 30 + 35 bytes
> do_instance_dealloc(_object * 0x03213ae0) line 182 + 101 bytes
> _Py_Dealloc(_object * 0x03213ae0) line 1820 + 7 bytes
> insertdict(_dictobject * 0x01bc0188, _object * 0x01c9b3c0,
long -724865314,
> _object * 0x1e172aa8 __Py_NoneStruct) line 373 + 59 bytes
> PyDict_SetItem(_object * 0x01bc0188, _object * 0x01c9b3c0, _object *
> 0x1e172aa8 __Py_NoneStruct) line 541 + 21 bytes
> PyObject_GenericSetAttr(_object * 0x01bc00b8, _object * 0x01c9b3c0,
_object
> * 0x1e172aa8 __Py_NoneStruct) line 1335 + 17 bytes
> PyObject_SetAttr(_object * 0x01bc00b8, _object * 0x01c9b3c0, _object *
> 0x1e172aa8 __Py_NoneStruct) line 1153 + 18 bytes
> PyObject_SetAttrString(_object * 0x01bc00b8, char * 0x1e18d0a4, _object *
> 0x1e172aa8 __Py_NoneStruct) line 1078 + 17 bytes
> sys_displayhook(_object * 0x00000000, _object * 0x01bbd1ac) line 90 + 19
> bytes
> PyCFunction_Call(_object * 0x019b4a88, _object * 0x01d0d778, _object *
> 0x00000000) line 90 + 14 bytes
> PyObject_Call(_object * 0x019b4a88, _object * 0x01d0d778, _object *
> 0x00000000) line 1665 + 15 bytes
> PyEval_CallObjectWithKeywords(_object * 0x019b4a88, _object * 0x01d0d778,
> _object * 0x00000000) line 3038 + 17 bytes
> eval_frame(_frame * 0x0320b9d0) line 1330 + 15 bytes
> PyEval_EvalCodeEx(PyCodeObject * 0x032184e8, _object * 0x01bd56d0, _object
*
> 0x01bd56d0, _object * * 0x00000000, int 0, _object * * 0x00000000, int 0,
> _object * * 0x00000000, int 0, _object * 0x00000000) line 2574 + 9 bytes
> PyEval_EvalCode(PyCodeObject * 0x032184e8, _object * 0x01bd56d0, _object *
> 0x01bd56d0) line 488 + 31 bytes
> run_node(_node * 0x03208850, char * 0x1e17d9b0, _object * 0x01bd56d0,
> _object * 0x01bd56d0, PyCompilerFlags * 0x0076e274 struct PyCompilerFlags
> flags) line 1083 + 17 bytes
> run_err_node(_node * 0x03208850, char * 0x1e17d9b0, _object * 0x01bd56d0,
> _object * 0x01bd56d0, PyCompilerFlags * 0x0076e274 struct PyCompilerFlags
> flags) line 1070 + 25 bytes
> PyRun_StringFlags(char * 0x01bf4838, int 256, _object * 0x01bd56d0,
_object
> * 0x01bd56d0, PyCompilerFlags * 0x0076e274 struct PyCompilerFlags  flags)
> line 1041 + 80 bytes
>
>
>
> Stefan Franke
> www.ableton.com
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig




From franke at ableton.com  Mon Feb 18 21:05:18 2002
From: franke at ableton.com (Stefan Franke)
Date: Mon, 18 Feb 2002 21:05:18 +0100
Subject: [C++-sig] First time pointers, first crash...
In-Reply-To: <6FB30F72F5FF9145B785936278BC25C80B77CD@exserver.ouroffice.de>
Message-ID: <6FB30F72F5FF9145B785936278BC25C802B6A6@exserver.ouroffice.de>

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams
> Sent: Monday, February 18, 2002 8:25 PM
> To: c++-sig at python.org
> Subject: Re: [C++-sig] First time pointers, first crash...
> 
> 
> Is this the whole code?
> Where's the cla
> Your exact example works for me (Python-2.2, MSVC6Sp4, Win2K).

Does it run even in debug version with BOOST_DEBUG_PYTHON enabled?
If so it's very strange and I have no clue what's going on here.

Stefan




From david.abrahams at rcn.com  Mon Feb 18 22:26:36 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 18 Feb 2002 16:26:36 -0500
Subject: [C++-sig] First time pointers, first crash...
References: <6FB30F72F5FF9145B785936278BC25C802B6A6@exserver.ouroffice.de>
Message-ID: <05d201c1b8c3$2d227150$0500a8c0@boostconsulting.com>

----- Original Message -----
From: "Stefan Franke" <franke at ableton.com>
To: <c++-sig at python.org>
Sent: Monday, February 18, 2002 3:05 PM
Subject: RE: [C++-sig] First time pointers, first crash...


> > -----Original Message-----
> > From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> > Behalf Of David Abrahams
> > Sent: Monday, February 18, 2002 8:25 PM
> > To: c++-sig at python.org
> > Subject: Re: [C++-sig] First time pointers, first crash...
> >
> >
> > Is this the whole code?
> > Where's the cla
> > Your exact example works for me (Python-2.2, MSVC6Sp4, Win2K).
>
> Does it run even in debug version with BOOST_DEBUG_PYTHON enabled?

Yes. I presume you know that BOOST_DEBUG_PYTHON requires _DEBUG and a
specially-compiled version of Python with reference-count tracking enabled.
I built and ran your example with Boost.Build, which takes care of all
configuration issues for me.

> If so it's very strange and I have no clue what's going on here.

If you're also using Boost.Build, then neither do I.





From minxu at sci.ccny.cuny.edu  Tue Feb 19 05:07:05 2002
From: minxu at sci.ccny.cuny.edu (Min Xu)
Date: 18 Feb 2002 23:07:05 -0500
Subject: class derivation in boost.python v2. Was Re: [C++-sig] Lifetime
	ofPython object for a pointer argument
In-Reply-To: <02ed01c1b804$577463b0$0500a8c0@boostconsulting.com>
References: 
	<1013875021.1078.17.camel@inspiron><017101c1b709$75a0ddb0$0500a8c0@boostcons
	 
	ulting.com><1013881885.1078.61.camel@inspiron><019501c1b716$6d392670$0500a8c
	 0@boostconsulting.com><1013893390.5363.181.camel@inspiron>
	<01b301c1b733$52ed19d0$0500a8c0@boostconsulting.com>
	<1013963187.5363.196.camel@inspiron> 
	<02ed01c1b804$577463b0$0500a8c0@boostconsulting.com>
Message-ID: <1014091634.15265.4.camel@inspiron>

Thanks.

Your fix is great. It now reports the uninitialized base class though
with the name prefixed by a digit such as 8geometry. -:)

My build goes like this for bpl

jam -sBOOST_ROOT=/usr/local/src/boost -sTOOLS=gcc -sBUILD=debug 
-sPYTHON_VERSION=2.2 -sPYTHON_ROOT=/usr
jam -sBOOST_ROOT=/usr/local/src/boost -sTOOLS=gcc -sBUILD=debug 
-sPYTHON_VERSION=2.2 -sPYTHON_ROOT=/usr test

> 
> You don't need the try/catch block ;-)
> 
> (Aside) How did you build bpl.so? If you use the debug-python build (the
> default in libs/python/Jamfile), you need a Python configured
> with --with-pydebug. Otherwise, you need the "debug" or "release" builds of
> bpl.
> 





From david.abrahams at rcn.com  Tue Feb 19 14:44:39 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 19 Feb 2002 08:44:39 -0500
Subject: class derivation in boost.python v2. Was Re: [C++-sig] LifetimeofPython object for a pointer argument
References: <1013875021.1078.17.camel@inspiron><017101c1b709$75a0ddb0$0500a8c0@boostcons ulting.com><1013881885.1078.61.camel@inspiron><019501c1b716$6d392670$0500a8c 0@boostconsulting.com><1013893390.5363.181.camel@inspiron><01b301c1b733$52ed19d0$0500a8c0@boostconsulting.com><1013963187.5363.196.camel@inspiron> <02ed01c1b804$577463b0$0500a8c0@boostconsulting.com> <1014091634.15265.4.camel@inspiron>
Message-ID: <06e201c1b94b$f6fa9e70$0500a8c0@boostconsulting.com>

----- Original Message -----
From: "Min Xu" <minxu at sci.ccny.cuny.edu>

> Thanks.
>
> Your fix is great. It now reports the uninitialized base class though
> with the name prefixed by a digit such as 8geometry. -:)

Are you volunteering to follow up on the attached message to get better
error reports from GCC?

----------

There are a few places where error reporting in Boost.Python depends on
being able to show users a reasonable representation of a C++ type name.
Currently, we use typeid(x).name() to get the name. Most compilers produce a
good result, however g++ does not. I just ran a small experiment to see if
the type encoding scheme used by G++ could easily be deciphered, and it
appears that it can. If we want to improve error reporting with G++, it
should be relatively easy.

The enclosed program indicates the following encoding information:

v void
c char
h unsigned char
a signed char
i int
j unsigned int
i signed int
s short
l long
x long long
f float
d double
e long double
P% %*
R% %&
K% % const
V% %volatile
A##_% %[##]                an array of ## %s, e.g. A4_c => char[4]
##...                      A name of length ##, e.g. 3foo => foo
N%1%2...%nE   %1::%2::...%n    A qualified name, e.g. N3foo3barE => foo::bar
F%1%2...%nE   %1 ()(%2,...%n)  A function, e.g. PFicE => int (*)(char)

S_    Back-reference to the first name spelled ##..., e.g. PF3fooS_E => foo
(*)(foo)

S##_    Back-reference to the ##+2'th name, e.g. PF3foo3barS0_E => foo
(*)(bar,bar)

        Note that back-references increase the count, so:
            PF3fooS_3barS1_E => foo (*)(foo, bar, bar)
  not S0_ --------------^^^

M%1%2 %2 (%1::*)  Member pointer, e.g.  M3fooi => int (foo::*)
                                        M3fooFvvE => void (foo::*)(void)

%1I%2%3...%nE  %1<%2,%3...%n> class template, e.g. 3fooIilE => foo<int,long>
L%##   ##     non-type template parameter of type L and value ##, e.g.
                    3fooILi42E => foo<42>, where 42 is an int

I got stumped at function non-type template parameters:

3fooIXadL_Z1fvEEE => foo<f>, with template<void (*)()> class foo / void f()

     ^^^^^^^^^^^
3fooIXadsr6foobarNS0_1fEvEE => foo<foobar::f>,
     ^^^^^^^^^^^^^^^^^^^^^
    with template<void (foobar::*)()> class foo, void foobar::f()

---------

Anyway, if someone would like to translate this information into code (and
complete the job for non-type template parameters, if possible), we could
easily have better error reporting for g++ users.


-Dave

-------------


// Copyright David Abrahams 2002. Permission to copy, use,
// modify, sell and distribute this software is granted provided this
// copyright notice appears in all copies. This software is provided
// "as is" without express or implied warranty, and with no claim as
// to its suitability for any purpose.
#include <typeinfo>
#include <cstdio>
#include <utility>

#define DUMP(type) std::printf("%s %s\n", typeid(type).name(), #type)

namespace foo
{
  namespace young
  {
    struct egg {};
  }
  struct bar {};
  enum baz {};
}

struct foobar {
    struct baz {};
    void f();
};

template <class T, class U, long, int> struct Template {};

struct x {};
struct xx {};
struct xxx {};
struct xxxx {};

void f();

template <void (*)()> struct TemplateTwo {};
template <void (foobar::*)()> struct TemplateThree {};

int main()
{
    DUMP(char);
    DUMP(char*);
    DUMP(char const*);
    DUMP(char const volatile*);
    DUMP(char[20]);
    DUMP(unsigned char);
    DUMP(signed char);
    DUMP(int);
    DUMP(unsigned int);
    DUMP(unsigned int*);
    DUMP(unsigned int const*);
    DUMP(unsigned int volatile*);
    DUMP(unsigned int const volatile*);
    DUMP(signed int);
    DUMP(short);
    DUMP(long);
    DUMP(long long);
    DUMP(float);
    DUMP(double);
    DUMP(long double);
    DUMP(foobar);
    DUMP(foobar::baz);
    DUMP(foo::bar);
    DUMP(foo::baz);
    DUMP(foo::young::egg);

    DUMP(x (*)(x));
    DUMP(x (*)(xx,xx));
    DUMP(x (*)(xx,xxx,xxx));
    DUMP(x (*)(xx,xxx,xxxx,xxxx));

    DUMP(void (*)());
    DUMP(int (*)());
    DUMP(int& (*)());
    DUMP(void (*)(int));
    DUMP(void (*)(int&));
    DUMP(void (*)(int const&));
    DUMP(void (*)(int const volatile&));
    DUMP(void (*)(int,foobar));
    DUMP(foo::baz (foobar::*)(int,foobar));

    // work around macro issues
    typedef Template<long,char*,42,99> template_foobar_3;
    DUMP(template_foobar_3);
    typedef std::pair<int,std::pair<long,char> > pair_int_pair_long_char;
    DUMP(pair_int_pair_long_char);
    typedef std::pair<foobar,std::pair<foobar,std::pair<foo::baz,foo::baz> >
> pair_foobar_pair_foobar_pair_foobaz_foobaz;
    DUMP(pair_foobar_pair_foobar_pair_foobaz_foobaz);

    typedef TemplateTwo<f> template_two_f;
    DUMP(template_two_f);
    typedef TemplateThree<&foobar::f> template_three_f;
    DUMP(template_three_f);
}






From franke at ableton.com  Tue Feb 19 15:41:44 2002
From: franke at ableton.com (Stefan Franke)
Date: Tue, 19 Feb 2002 15:41:44 +0100
Subject: [C++-sig] First time pointers, first crash...
In-Reply-To: <6FB30F72F5FF9145B785936278BC25C80B77CF@exserver.ouroffice.de>
Message-ID: <6FB30F72F5FF9145B785936278BC25C802B6A8@exserver.ouroffice.de>

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams
> Sent: Monday, February 18, 2002 10:27 PM
> To: c++-sig at python.org
> Subject: Re: [C++-sig] First time pointers, first crash...

[...]

> Yes. I presume you know that BOOST_DEBUG_PYTHON requires _DEBUG and a
> specially-compiled version of Python with reference-count 
> tracking enabled.
> I built and ran your example with Boost.Build, which takes care of all
> configuration issues for me.
> 
> > If so it's very strange and I have no clue what's going on here.
> 
> If you're also using Boost.Build, then neither do I.

No I'm not. I'm building Boost.Python as part of an MSVC workspace that 
contains 65 other subprojects -- our app is rather big. My reasons for 
not using Boost.Build are

- I don't know how to use jam. I'm able to build & run the demos like
  shown in the docs, but I don't even know how the set up and run this
  little test example like you did. Maybe you can give me a few hints.

- Our app is cross-platform (Win, Mac OS, OS-X). Jam is too, of course,
  but I don't have an idea how to manage all compile & link options for
  the various platforms within jam.

- I'm doing something experimental here. My co-workers are quite sceptical
  about "this Python thing" anyway, and expecting them (espacially or Mac 
  guys) to use yet another build tool for a simgle subproject is pretty 
  much.

One general question here: Are users of Boost in general supposed to learn
jam? Since I consider my case pretty "real-world", I hope there is - and
ever will be - a way and some documentation how to build the libs 
generically. 

Stefan




From franke at ableton.com  Tue Feb 19 15:54:28 2002
From: franke at ableton.com (Stefan Franke)
Date: Tue, 19 Feb 2002 15:54:28 +0100
Subject: [C++-sig] First time pointers, first crash...
In-Reply-To: <6FB30F72F5FF9145B785936278BC25C80B77CF@exserver.ouroffice.de>
Message-ID: <6FB30F72F5FF9145B785936278BC25C802B6A9@exserver.ouroffice.de>

As far as I understand the problem, the crash occurs because a non-matching
pair of allocator / deallocator is used and the debug heap manager complains
about an illegal address.

	HEAP[boosttest.exe]: Invalid Address specified to RtlValidateHeap( b60000,
1be9ac8 )

Of course, I thought, this is because our app uses an own global new
operator
so I took this out (I had tried this even before my first posting). But
unluckily this does not change anything.

As can be seen from the stack trace in my previous post, the problem occurs
at the following point:

	[classes.hpp: line 275]

	template <class T>
	void class_t<T>::delete_instance(PyObject* obj) const
	{
		delete downcast<T>(obj);
	}

I think this is the location where the wrapper object itself is deleted
(which shouldn't affect the wrapped object - does it?).

In my example, the wrapper object is created by Boost.Python for the
return value of the wrapped GetFoo() function.

	foo *GetFoo() { return myFoo; }
[...]
	this_module.def(GetFoo, "getfoo");

My question: Can you point my to the position where the new operator
for the wrapper object is called. Then I could put a breakpoint there
and see which allocator is actually used.

Thanks,
Stefan




From david.abrahams at rcn.com  Tue Feb 19 16:07:23 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 19 Feb 2002 10:07:23 -0500
Subject: [C++-sig] First time pointers, first crash...
References: <6FB30F72F5FF9145B785936278BC25C802B6A9@exserver.ouroffice.de>
Message-ID: <07a701c1b957$2dedff70$0500a8c0@boostconsulting.com>

----- Original Message -----
From: "Stefan Franke" <franke at ableton.com>

> As can be seen from the stack trace in my previous post, the problem
occurs
> at the following point:
>
> [classes.hpp: line 275]
>
> template <class T>
> void class_t<T>::delete_instance(PyObject* obj) const
> {
> delete downcast<T>(obj);
> }
>
> I think this is the location where the wrapper object itself is deleted
> (which shouldn't affect the wrapped object - does it?).

Not the way you're creating it.

> In my example, the wrapper object is created by Boost.Python for the
> return value of the wrapped GetFoo() function.
>
> foo *GetFoo() { return myFoo; }
> [...]
> this_module.def(GetFoo, "getfoo");
>
> My question: Can you point my to the position where the new operator
> for the wrapper object is called. Then I could put a breakpoint there
> and see which allocator is actually used.

line 334 of boost/python/detail/extension_class.hpp





From toon.knapen at si-lab.org  Tue Feb 19 16:02:55 2002
From: toon.knapen at si-lab.org (Toon Knapen)
Date: Tue, 19 Feb 2002 16:02:55 +0100
Subject: [C++-sig] First time pointers, first crash...
References: <6FB30F72F5FF9145B785936278BC25C802B6A8@exserver.ouroffice.de>
Message-ID: <3C72691F.4070206@si-lab.org>

>>If you're also using Boost.Build, then neither do I.
>>
> 
> No I'm not. I'm building Boost.Python as part of an MSVC workspace that 
> contains 65 other subprojects -- our app is rather big. My reasons for 
> not using Boost.Build are
> 
> - I don't know how to use jam. I'm able to build & run the demos like
>   shown in the docs, but I don't even know how the set up and run this
>   little test example like you did. Maybe you can give me a few hints.
> 
> - Our app is cross-platform (Win, Mac OS, OS-X). Jam is too, of course,
>   but I don't have an idea how to manage all compile & link options for
>   the various platforms within jam.
> 
> - I'm doing something experimental here. My co-workers are quite sceptical
>   about "this Python thing" anyway, and expecting them (espacially or Mac 
>   guys) to use yet another build tool for a simgle subproject is pretty 
>   much.
> 
> One general question here: Are users of Boost in general supposed to learn
> jam? Since I consider my case pretty "real-world", I hope there is - and
> ever will be - a way and some documentation how to build the libs 
> generically. 


I'm new to boost.python v2 but I do can comment on Jam :

I'm developing multi-platform (all unices and windows) for 5 years now 
and the only way to compile transparantly on all these platforms is 
using Jam. Now you need to keep your VC project files up to date while 
maintaining a makefile system on the unices (which all differ unless you 
use gmake). Don't know about mac but I'm sure you have yet another build 
environment there. To compile the same app on all these different 
platforms should only require calling `jam`. Managing compile and link 
options are managed by jam itself (if you are providing the necessary 
platform-independent info of course)

To start using jam, download a precompiled executable from the web, and 
try some hello-world stuff looking at the Jamfiles inside boost and the 
documentation. If in trouble, many people are picking up jam and 
boost.jam, so support guaranteed.






From david.abrahams at rcn.com  Tue Feb 19 16:23:39 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 19 Feb 2002 10:23:39 -0500
Subject: [C++-sig] First time pointers, first crash...
References: <6FB30F72F5FF9145B785936278BC25C802B6A8@exserver.ouroffice.de>
Message-ID: <080a01c1b959$fc9bc760$0500a8c0@boostconsulting.com>

----- Original Message -----
From: "Stefan Franke" <franke at ableton.com>

> No I'm not. I'm building Boost.Python as part of an MSVC workspace that
> contains 65 other subprojects -- our app is rather big. My reasons for
> not using Boost.Build are
>
> - I don't know how to use jam. I'm able to build & run the demos like
>   shown in the docs, but I don't even know how the set up and run this
>   little test example like you did. Maybe you can give me a few hints.

Have you read the documentation for Boost.Build at
www.boost.org/tools/build/build_system.htm?
If you still have questions, I suggest you post at
www.yahoogroups.com/messages/jamboost

> One general question here: Are users of Boost in general supposed to learn
> jam?

What does "supposed to" mean?

> Since I consider my case pretty "real-world", I hope there is - and
> ever will be - a way and some documentation how to build the libs
> generically.

What does "generically" mean?

We'll probably start providing pre-built libs for some platforms, and
library authors are free to provide additional means, such as makefiles, but
in general, Boost.Build is going to be the official build system for all
Boost libraries.

-Dave





From david.abrahams at rcn.com  Tue Feb 19 16:37:26 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 19 Feb 2002 10:37:26 -0500
Subject: [C++-sig] Wrapping already refcounted C++ types
References: <6FB30F72F5FF9145B785936278BC25C802B6A4@exserver.ouroffice.de>
Message-ID: <080d01c1b95b$636e9ac0$0500a8c0@boostconsulting.com>

----- Original Message -----
From: "Stefan Franke" <franke at ableton.com>


> Dear group,
>
> I would like to wrap a couple of C++ classes in a library that
> already implements its own reference counting.
>
> The instances are never copied by value but referenced either
>
> (a) by plain C pointers or
> (b) by their respective smart pointer class
>
> So I have to write to_python() and from_python() conversions
> for these pointer types.
>
> The behaviour I'd like to implement for case (a) is that the
> wrapper object increments the original instance's refcount when
> created and releases the reference on destruction.
>
> My questions are:
>
> - Where are the right places to put the respective incref/decrefs?
> - What to do in case (b)

(b) is easy. (a) is hard without Boost.Python v2.

For (b):

BOOST_PYTHON_BEGIN_CONVERSION_NAMESPACE
PyObject* to_python(smart_ptr<Foo> p)
  {
      return
boost::python::python_extension_class_converters<Foo>::smart_ptr_to_python(p
);
  }

template <class T>smart_ptr<T> from_python(PyObject*p,
boost::python::type<smart_ptr<T> >)
{
    return smart_ptr_from_python(p, boost::python::type<smart_ptr<T> >(),
boost::python::type<T>());
}
template <class T>smart_ptr<T> from_python(PyObject*p,
boost::python::type<smart_ptr<T> const&>)
{
    return from_python(p, boost::python::type<smart_ptr<T> >());
}
BOOST_PYTHON_END_CONVERSION_NAMESPACE

For (a), You'll need to creat a thin wrapper function over all of your
functions manipulating the raw pointers. The easiest way is to replace the
raw pointers in the signature with PyObject*, manipulate the reference
counts in your wrapper function, then exploit from_python(p,
boost::python::type<Foo*>()) directly to get the argument for the wrapped
function.

-Dave




From franke at ableton.com  Tue Feb 19 17:03:14 2002
From: franke at ableton.com (Stefan Franke)
Date: Tue, 19 Feb 2002 17:03:14 +0100
Subject: [C++-sig] First time pointers, first crash...
In-Reply-To: <6FB30F72F5FF9145B785936278BC25C80B77D6@exserver.ouroffice.de>
Message-ID: <6FB30F72F5FF9145B785936278BC25C802B6AA@exserver.ouroffice.de>

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams
> Sent: Tuesday, February 19, 2002 4:24 PM
> To: c++-sig at python.org
> Subject: Re: [C++-sig] First time pointers, first crash...
[...]

> What does "supposed to" mean?
> What does "generically" mean?

Excuse me if it's not clear what I meant. English is not my native
language.

I wanted to ask is just if I have to learn jam to use those parts
of Boost that consist not only of header files.

The docs for Boost.Python, for example, specify the commands to 
build the lib and to build & run the test suite. That's all.

So as a newbie I don't learn how to 
- build a single example or other test project
- pass configuration options or defines to the build process
- what the relevant files are

And the perspective of having to learn again "something like
make" is pure horror -- for an outsider, perhaps jam is really
easy to use & learn. 
Maybe a "quick intro to jam for Boost users" could help here.

Best regards,
Stefan




From franke at ableton.com  Tue Feb 19 17:12:48 2002
From: franke at ableton.com (Stefan Franke)
Date: Tue, 19 Feb 2002 17:12:48 +0100
Subject: [C++-sig] First time pointers, first crash...
In-Reply-To: <6FB30F72F5FF9145B785936278BC25C80B77D4@exserver.ouroffice.de>
Message-ID: <6FB30F72F5FF9145B785936278BC25C802B6AB@exserver.ouroffice.de>

> > My question: Can you point my to the position where the new operator
> > for the wrapper object is called. Then I could put a 
> breakpoint there
> > and see which allocator is actually used.
> 
> line 334 of boost/python/detail/extension_class.hpp
> 

Thank you very much. That helped a lot. It seems my problem is that
I have false allocator/deallocator pairs because the destructors
in <new> are inlined, whereas there's a global operator new which
is used because it is linked to the app (even if not declared in
any header file). 

In out app the latter is usually superposed by another (inlined) 
operator new, Boost.Python of course doesn't see it.

Strange, because I'm building Boost.Python as a DLL project. I have
to do more research...






From david.abrahams at rcn.com  Tue Feb 19 18:17:41 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 19 Feb 2002 12:17:41 -0500
Subject: [C++-sig] First time pointers, first crash...
References: <6FB30F72F5FF9145B785936278BC25C802B6AA@exserver.ouroffice.de>
Message-ID: <085701c1b969$58130270$0500a8c0@boostconsulting.com>

----- Original Message -----
From: "Stefan Franke" <franke at ableton.com>

> > Subject: Re: [C++-sig] First time pointers, first crash...
> [...]
>
> > What does "supposed to" mean?
> > What does "generically" mean?
>
> Excuse me if it's not clear what I meant. English is not my native
> language.

No problem.

> I wanted to ask is just if I have to learn jam to use those parts
> of Boost that consist not only of header files.

Not strictly; you could try to figure out how to build things on your own;
lots of people have done that.

> The docs for Boost.Python, for example, specify the commands to
> build the lib and to build & run the test suite. That's all.
>
> So as a newbie I don't learn how to
> - build a single example or other test project
> - pass configuration options or defines to the build process
> - what the relevant files are

The documentation for building Boost.Python V1 is a little out-of-date, and
unfortunately I don't have much time to document it right now since I'm
working on V2. V2 will have complete documentation.

> And the perspective of having to learn again "something like
> make" is pure horror -- for an outsider, perhaps jam is really
> easy to use & learn.
> Maybe a "quick intro to jam for Boost users" could help here.

Here's a quickie Jamfile.

subproject myproject/mysubproject ;

# bring in the rules for python
SEARCH on <module@>python.jam = $(BOOST_BUILD_PATH) ;
include <module@>python.jam ;

# declare a python extension module:
extension my_extension : src1.cpp src2.c src3.y ...
    : # optional additional requirements
    : # optional default build
    ;

# declare a test
boost-python-runtest my_test : my_test_driver.py <pyd>my_extension
    : <library-path>path-to-boost_python <findlibs>boost_python
    ;


HTH,
Dave




From minxu at sci.ccny.cuny.edu  Wed Feb 20 21:13:49 2002
From: minxu at sci.ccny.cuny.edu (Min Xu)
Date: 20 Feb 2002 15:13:49 -0500
Subject: A import module bug. was Re: class derivation in boost.python v2.
	Was Re: [C++-sig] LifetimeofPython object for a pointer argument
In-Reply-To: <06e201c1b94b$f6fa9e70$0500a8c0@boostconsulting.com>
References: 
	<1013875021.1078.17.camel@inspiron><017101c1b709$75a0ddb0$0500a8c0@boostcons
	 
	ulting.com><1013881885.1078.61.camel@inspiron><019501c1b716$6d392670$0500a8c
	 
	0@boostconsulting.com><1013893390.5363.181.camel@inspiron><01b301c1b733$52ed
	 19d0$0500a8c0@boostconsulting.com><1013963187.5363.196.camel@inspiron>
	<02ed01c1b804$577463b0$0500a8c0@boostconsulting.com>
	<1014091634.15265.4.camel@inspiron> 
	<06e201c1b94b$f6fa9e70$0500a8c0@boostconsulting.com>
Message-ID: <1014236029.1768.8.camel@lax6>

On Tue, 2002-02-19 at 08:44, David Abrahams wrote:
> 
> ----- Original Message -----
> From: "Min Xu" <minxu at sci.ccny.cuny.edu>
> 
> > Thanks.
> >
> > Your fix is great. It now reports the uninitialized base class though
> > with the name prefixed by a digit such as 8geometry. -:)
> 
> Are you volunteering to follow up on the attached message to get better
> error reports from GCC?
> 
I am not sure where this kind of information will fit into the
boost.python environment. It is just some sugar to shining up the
appearance. 

The AA module compiles OK and works. But python2.2 will core dump
by the following a simple line.

minxu at lax6:~/research/ngf2$ python2.2 -i -c "import AA; import Gnuplot"
Segmentation fault (core dumped)
minxu at lax6:~/research/ngf2$ python2.2 -i -c "import Gnuplot, AA"
>>> 

For your reference, the AA.cpp is included again here. It is a linux box
with gcc2.95.4 and compiled against boost.python v2 (yesterday and
today's versions).

#include <boost/python/module.hpp>
#include <boost/python/class.hpp>

class A
{
public:
	A() : x(0) {}
	A(const A& a) : x(a.x) {}
private:
	double x;
};

class AA : public A
{
public:
	AA(const A& a) : A(a) {}
};

namespace python = boost::python;

BOOST_PYTHON_MODULE_INIT(AA)
{
  try
  {
      python::module m("AA");
	  m.add(
	      python::class_<A>("A")
	      .def_init(args<>())
	      );
	  m.add(
	      python::class_<AA, bases<A> >("AA")
	      .def_init(args<const A&>())
	      );
  }
  catch(...)
  {
      python::handle_exception(); // Deal with the exception for Python
  }
}






From david.abrahams at rcn.com  Wed Feb 20 21:50:40 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 20 Feb 2002 15:50:40 -0500
Subject: A import module bug. was Re: class derivation in boost.python v2.Was Re: [C++-sig] LifetimeofPython object for a pointer argument
References: <1013875021.1078.17.camel@inspiron><017101c1b709$75a0ddb0$0500a8c0@boostcons ulting.com><1013881885.1078.61.camel@inspiron><019501c1b716$6d392670$0500a8c 0@boostconsulting.com><1013893390.5363.181.camel@inspiron><01b301c1b733$52ed 19d0$0500a8c0@boostconsulting.com><1013963187.5363.196.camel@inspiron><02ed01c1b804$577463b0$0500a8c0@boostconsulting.com><1014091634.15265.4.camel@inspiron> <06e201c1b94b$f6fa9e70$0500a8c0@boostconsulting.com> <1014236029.1768.8.camel@lax6>
Message-ID: <0e1101c1ba50$deb1d170$0500a8c0@boostconsulting.com>

----- Original Message -----
From: "Min Xu" <minxu at sci.ccny.cuny.edu>


> On Tue, 2002-02-19 at 08:44, David Abrahams wrote:
> >
> > ----- Original Message -----
> > From: "Min Xu" <minxu at sci.ccny.cuny.edu>
> >
> > > Thanks.
> > >
> > > Your fix is great. It now reports the uninitialized base class though
> > > with the name prefixed by a digit such as 8geometry. -:)
> >
> > Are you volunteering to follow up on the attached message to get better
> > error reports from GCC?
> >
> I am not sure where this kind of information will fit into the
> boost.python environment. It is just some sugar to shining up the
> appearance.

Yep. So are high-level languages.

> The AA module compiles OK and works. But python2.2 will core dump
> by the following a simple line.
>
> minxu at lax6:~/research/ngf2$ python2.2 -i -c "import AA; import Gnuplot"
> Segmentation fault (core dumped)
> minxu at lax6:~/research/ngf2$ python2.2 -i -c "import Gnuplot, AA"
> >>>

Uh-huh. So, I don't have Gnuplot. Are you sure this isn't a Gnuplot bug?
If you want me to address this, I'll need a lot more information than "it
crashes". Have you tried to look at the stack trace with a gdb?

> For your reference, the AA.cpp is included again here. It is a linux box
> with gcc2.95.4 and compiled against boost.python v2 (yesterday and
> today's versions).
>
> #include <boost/python/module.hpp>
> #include <boost/python/class.hpp>
>
> class A
> {
> public:
> A() : x(0) {}
> A(const A& a) : x(a.x) {}
> private:
> double x;
> };
>
> class AA : public A
> {
> public:
> AA(const A& a) : A(a) {}
> };
>
> namespace python = boost::python;
>
> BOOST_PYTHON_MODULE_INIT(AA)
> {
>   try
>   {
>       python::module m("AA");
>   m.add(
>       python::class_<A>("A")
>       .def_init(args<>())
>       );
>   m.add(
>       python::class_<AA, bases<A> >("AA")
>       .def_init(args<const A&>())
>       );
>   }
>   catch(...)
>   {
>       python::handle_exception(); // Deal with the exception for Python
>   }
> }

I'm not sure why you changed what I sent you. The try/catch block is
unneeded.

-Dave





From minxu at sci.ccny.cuny.edu  Wed Feb 20 22:50:34 2002
From: minxu at sci.ccny.cuny.edu (Min Xu)
Date: 20 Feb 2002 16:50:34 -0500
Subject: A import module bug. was Re: class derivation in boost.python
	v2.Was Re: [C++-sig] LifetimeofPython object for a pointer argument
In-Reply-To: <0e1101c1ba50$deb1d170$0500a8c0@boostconsulting.com>
References: 
	<1013875021.1078.17.camel@inspiron><017101c1b709$75a0ddb0$0500a8c0@boostcons
	 
	ulting.com><1013881885.1078.61.camel@inspiron><019501c1b716$6d392670$0500a8c
	 
	0@boostconsulting.com><1013893390.5363.181.camel@inspiron><01b301c1b733$52ed
	 
	19d0$0500a8c0@boostconsulting.com><1013963187.5363.196.camel@inspiron><02ed0
	
	1c1b804$577463b0$0500a8c0@boostconsulting.com><1014091634.15265.4.camel@insp
	 iron> <06e201c1b94b$f6fa9e70$0500a8c0@boostconsulting.com>
	<1014236029.1768.8.camel@lax6> 
	<0e1101c1ba50$deb1d170$0500a8c0@boostconsulting.com>
Message-ID: <1014241834.1770.16.camel@lax6>

> I'm not sure why you changed what I sent you. The try/catch block is
> unneeded.
> 

I have deleted the try/catch portion and it core dumps as before. I
think it may not be th bug of Gnuplot. See the following examples and a
back trace for "import AA, Gnuplot".


minxu at lax6:~/research/ngf2$ python2.2 -c "import AA, Numeric"
Segmentation fault (core dumped)
minxu at lax6:~/research/ngf2$ python2.2 -c "import AA, site"
minxu at lax6:~/research/ngf2$ python2.2 -c "import AA, pdb"
Segmentation fault (core dumped)

minxu at lax6:~/research/ngf2$ python2.2 -c "import AA, Gnuplot"
Segmentation fault (core dumped)
minxu at lax6:~/research/ngf2$ gdb python2.2 core
GNU gdb 5.1.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux"...(no debugging symbols found)...
Core was generated by `python2.2 -c import AA, Gnuplot'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libpython2.2.so.0.0...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libpython2.2.so.0.0
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...
done.

warning: Unable to set global thread event mask: generic error
[New Thread 1024 (LWP 2041)]
Error while reading shared library symbols:
Cannot enable thread event reporting for Thread 1024 (LWP 2041): generic error
Reading symbols from /lib/libutil.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libutil.so.1
Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from ./AA.so...done.
Loaded symbols for ./AA.so
Reading symbols from /usr/local/lib/libbpl.so...done.
Loaded symbols for /usr/local/lib/libbpl.so
Reading symbols from /usr/lib/libstdc++-libc6.2-2.so.3...done.
Loaded symbols for /usr/lib/libstdc++-libc6.2-2.so.3
Reading symbols from /usr/lib/python2.2/lib-dynload/strop.so...done.
Loaded symbols for /usr/lib/python2.2/lib-dynload/strop.so
Reading symbols from /usr/lib/python2.2/lib-dynload/cStringIO.so...done.
Loaded symbols for /usr/lib/python2.2/lib-dynload/cStringIO.so
---Type <return> to continue, or q <return> to quit---
Reading symbols from /usr/lib/python2.2/site-packages/Numeric/multiarray.so...
done.
Loaded symbols for /usr/lib/python2.2/site-packages/Numeric/multiarray.so
Reading symbols from /usr/lib/python2.2/site-packages/Numeric/_numpy.so...done.
Loaded symbols for /usr/lib/python2.2/site-packages/Numeric/_numpy.so
Reading symbols from /usr/lib/python2.2/site-packages/Numeric/umath.so...done.
Loaded symbols for /usr/lib/python2.2/site-packages/Numeric/umath.so
#0  0x00000000 in ?? ()
(gdb) backtrace
#0  0x00000000 in ?? ()
#1  0x400b33d8 in Py_GetArgcArgv () from /usr/lib/libpython2.2.so.0.0
#2  0x400b39cb in Py_GetArgcArgv () from /usr/lib/libpython2.2.so.0.0
#3  0x400b40c2 in _PyObject_GC_NewVar () from /usr/lib/libpython2.2.so.0.0
#4  0x4006dce2 in PyTuple_New () from /usr/lib/libpython2.2.so.0.0
#5  0x400a8469 in _PyImport_LoadDynamicModule ()
   from /usr/lib/libpython2.2.so.0.0
#6  0x400a8866 in _PyImport_LoadDynamicModule ()
   from /usr/lib/libpython2.2.so.0.0
#7  0x400a849d in _PyImport_LoadDynamicModule ()
   from /usr/lib/libpython2.2.so.0.0
#8  0x400a8866 in _PyImport_LoadDynamicModule ()
   from /usr/lib/libpython2.2.so.0.0
#9  0x400a9166 in PyMarshal_ReadObjectFromString ()
   from /usr/lib/libpython2.2.so.0.0
#10 0x400a8c96 in PyMarshal_ReadLastObjectFromFile ()
   from /usr/lib/libpython2.2.so.0.0
#11 0x400a2f00 in PyImport_ExecCodeModuleEx ()
   from /usr/lib/libpython2.2.so.0.0
#12 0x400a398b in PyImport_ExecCodeModuleEx ()
   from /usr/lib/libpython2.2.so.0.0
#13 0x400a4810 in PyImport_ImportModuleEx () from /usr/lib/libpython2.2.so.0.0
#14 0x400a4395 in PyImport_ImportModuleEx () from /usr/lib/libpython2.2.so.0.0
---Type <return> to continue, or q <return> to quit---
#15 0x400a3e98 in PyImport_ImportFrozenModule ()
   from /usr/lib/libpython2.2.so.0.0
#16 0x400a4057 in PyImport_ImportModuleEx () from /usr/lib/libpython2.2.so.0.0
#17 0x40087627 in _PyBuiltin_Init () from /usr/lib/libpython2.2.so.0.0
#18 0x40062aa1 in PyCFunction_Call () from /usr/lib/libpython2.2.so.0.0
#19 0x40042209 in PyObject_Call () from /usr/lib/libpython2.2.so.0.0
#20 0x4008dee2 in PyEval_CallObjectWithKeywords ()
   from /usr/lib/libpython2.2.so.0.0
#21 0x4008c0d7 in Py_MakePendingCalls () from /usr/lib/libpython2.2.so.0.0
#22 0x4008d654 in PyEval_EvalCodeEx () from /usr/lib/libpython2.2.so.0.0
#23 0x4008f95a in PyEval_EvalCode () from /usr/lib/libpython2.2.so.0.0
#24 0x400a2abb in PyImport_ExecCodeModuleEx ()
   from /usr/lib/libpython2.2.so.0.0
#25 0x400a3041 in PyImport_ExecCodeModuleEx ()
   from /usr/lib/libpython2.2.so.0.0
#26 0x400a398b in PyImport_ExecCodeModuleEx ()
   from /usr/lib/libpython2.2.so.0.0
#27 0x400a4810 in PyImport_ImportModuleEx () from /usr/lib/libpython2.2.so.0.0
#28 0x400a43d4 in PyImport_ImportModuleEx () from /usr/lib/libpython2.2.so.0.0
#29 0x400a3e98 in PyImport_ImportFrozenModule ()
   from /usr/lib/libpython2.2.so.0.0
#30 0x400a4057 in PyImport_ImportModuleEx () from /usr/lib/libpython2.2.so.0.0
#31 0x40087627 in _PyBuiltin_Init () from /usr/lib/libpython2.2.so.0.0
---Type <return> to continue, or q <return> to quit---
#32 0x40062aa1 in PyCFunction_Call () from /usr/lib/libpython2.2.so.0.0
#33 0x40042209 in PyObject_Call () from /usr/lib/libpython2.2.so.0.0
#34 0x4008dee2 in PyEval_CallObjectWithKeywords ()
   from /usr/lib/libpython2.2.so.0.0
#35 0x4008c0d7 in Py_MakePendingCalls () from /usr/lib/libpython2.2.so.0.0
#36 0x4008d654 in PyEval_EvalCodeEx () from /usr/lib/libpython2.2.so.0.0
#37 0x4008f95a in PyEval_EvalCode () from /usr/lib/libpython2.2.so.0.0
#38 0x400a2abb in PyImport_ExecCodeModuleEx ()
   from /usr/lib/libpython2.2.so.0.0
#39 0x400a3041 in PyImport_ExecCodeModuleEx ()
   from /usr/lib/libpython2.2.so.0.0
#40 0x400a398b in PyImport_ExecCodeModuleEx ()
   from /usr/lib/libpython2.2.so.0.0
#41 0x400a4810 in PyImport_ImportModuleEx () from /usr/lib/libpython2.2.so.0.0
#42 0x400a4395 in PyImport_ImportModuleEx () from /usr/lib/libpython2.2.so.0.0
#43 0x400a3e98 in PyImport_ImportFrozenModule ()
   from /usr/lib/libpython2.2.so.0.0
#44 0x400a4057 in PyImport_ImportModuleEx () from /usr/lib/libpython2.2.so.0.0
#45 0x40087627 in _PyBuiltin_Init () from /usr/lib/libpython2.2.so.0.0
#46 0x40062aa1 in PyCFunction_Call () from /usr/lib/libpython2.2.so.0.0
#47 0x40042209 in PyObject_Call () from /usr/lib/libpython2.2.so.0.0
#48 0x4008dee2 in PyEval_CallObjectWithKeywords ()
   from /usr/lib/libpython2.2.so.0.0
---Type <return> to continue, or q <return> to quit---
#49 0x4008c0d7 in Py_MakePendingCalls () from /usr/lib/libpython2.2.so.0.0
#50 0x4008d654 in PyEval_EvalCodeEx () from /usr/lib/libpython2.2.so.0.0
#51 0x4008f95a in PyEval_EvalCode () from /usr/lib/libpython2.2.so.0.0
#52 0x400a2abb in PyImport_ExecCodeModuleEx ()
   from /usr/lib/libpython2.2.so.0.0
#53 0x400a3041 in PyImport_ExecCodeModuleEx ()
   from /usr/lib/libpython2.2.so.0.0
#54 0x400a398b in PyImport_ExecCodeModuleEx ()
   from /usr/lib/libpython2.2.so.0.0
#55 0x400a31d9 in PyImport_ExecCodeModuleEx ()
   from /usr/lib/libpython2.2.so.0.0
#56 0x400a39ba in PyImport_ExecCodeModuleEx ()
   from /usr/lib/libpython2.2.so.0.0
#57 0x400a4810 in PyImport_ImportModuleEx () from /usr/lib/libpython2.2.so.0.0
#58 0x400a4395 in PyImport_ImportModuleEx () from /usr/lib/libpython2.2.so.0.0
#59 0x400a3e98 in PyImport_ImportFrozenModule ()
   from /usr/lib/libpython2.2.so.0.0
#60 0x400a4057 in PyImport_ImportModuleEx () from /usr/lib/libpython2.2.so.0.0
#61 0x40087627 in _PyBuiltin_Init () from /usr/lib/libpython2.2.so.0.0
#62 0x40062aa1 in PyCFunction_Call () from /usr/lib/libpython2.2.so.0.0
#63 0x40042209 in PyObject_Call () from /usr/lib/libpython2.2.so.0.0
#64 0x4008dee2 in PyEval_CallObjectWithKeywords ()
   from /usr/lib/libpython2.2.so.0.0
---Type <return> to continue, or q <return> to quit---
#65 0x4008c0d7 in Py_MakePendingCalls () from /usr/lib/libpython2.2.so.0.0
#66 0x4008d654 in PyEval_EvalCodeEx () from /usr/lib/libpython2.2.so.0.0
#67 0x4008f95a in PyEval_EvalCode () from /usr/lib/libpython2.2.so.0.0
#68 0x400ad5e4 in PyOS_setsig () from /usr/lib/libpython2.2.so.0.0
#69 0x400ad58f in PyOS_setsig () from /usr/lib/libpython2.2.so.0.0
#70 0x400ad179 in PyRun_StringFlags () from /usr/lib/libpython2.2.so.0.0
#71 0x400ace36 in PyRun_SimpleStringFlags () from /usr/lib/libpython2.2.so.0.0
#72 0x400b309e in Py_Main () from /usr/lib/libpython2.2.so.0.0
#73 0x08048624 in main ()
#74 0x4014f6cf in __libc_start_main () from /lib/libc.so.6
(gdb) q






From jwinkelman at movaz.com  Fri Feb 22 23:25:10 2002
From: jwinkelman at movaz.com (Winkelman, Jeff)
Date: Fri, 22 Feb 2002 17:25:10 -0500
Subject: [C++-sig] Help with Boost 1.27.0
Message-ID: <8C2541B48448364E8F103874E68426B3044D24@atlntex01.movaz.com>

I was wondering if someone could help me out.  Several months ago I wrote a Python extension using Boost, and most recently had to add some features to it.  After upgrading to version 1.27.0, and figuring out how to get the new build system operational, I rebuilt my project.

After successfully building, I then imported my module in python and attempted to use some of the exposed classes.

I have the following problem.  After creating an object, any method on that object that I try to execute fails with the following error:

>>> x.enableDebug(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
RuntimeError: Access violation - no RTTI data!

I am running Windows 2000, using Visual C++ as my development environment, and I am also running Python 2.1.

Originally I was trying this with Python 2.2.  Should Boost still work for 2.2 if I'm not trying to use any of the new typing / features in 2.2?  I re-built against 2.1 and still have the same problem.

If any one has any ideas, I'd appreciate your help.

Thanks,

Jeff



From david.abrahams at rcn.com  Fri Feb 22 23:38:25 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 22 Feb 2002 17:38:25 -0500
Subject: [C++-sig] Help with Boost 1.27.0
References: <8C2541B48448364E8F103874E68426B3044D24@atlntex01.movaz.com>
Message-ID: <00c801c1bbf1$ffbc5690$0500a8c0@boostconsulting.com>

Sounds to me as though you didn't enable RTTI in the compiler when you built
your module.

Did you compile with /GR and /GX?

----- Original Message -----
From: "Winkelman, Jeff" <jwinkelman at movaz.com>
To: <c++-sig at python.org>
Sent: Friday, February 22, 2002 5:25 PM
Subject: [C++-sig] Help with Boost 1.27.0


I was wondering if someone could help me out.  Several months ago I wrote a
Python extension using Boost, and most recently had to add some features to
it.  After upgrading to version 1.27.0, and figuring out how to get the new
build system operational, I rebuilt my project.

After successfully building, I then imported my module in python and
attempted to use some of the exposed classes.

I have the following problem.  After creating an object, any method on that
object that I try to execute fails with the following error:

>>> x.enableDebug(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
RuntimeError: Access violation - no RTTI data!

I am running Windows 2000, using Visual C++ as my development environment,
and I am also running Python 2.1.

Originally I was trying this with Python 2.2.  Should Boost still work for
2.2 if I'm not trying to use any of the new typing / features in 2.2?  I
re-built against 2.1 and still have the same problem.

If any one has any ideas, I'd appreciate your help.

Thanks,

Jeff

_______________________________________________
C++-sig mailing list
C++-sig at python.org
http://mail.python.org/mailman/listinfo/c++-sig





From minxu at sci.ccny.cuny.edu  Sat Feb 23 16:31:22 2002
From: minxu at sci.ccny.cuny.edu (Min Xu)
Date: 23 Feb 2002 10:31:22 -0500
Subject: [C++-sig] Q: wrap an abstract class in v2
Message-ID: <1014478282.3625.5.camel@inspiron>

I am wondering how can I wrap an abstract class in v2. the technique for
v1 fails. Can anyone show me an example using boost.python v2? The
abstract class has a undefined virtual function.


Thanks.

Min




From david.abrahams at rcn.com  Sat Feb 23 17:54:44 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 23 Feb 2002 11:54:44 -0500
Subject: [C++-sig] Q: wrap an abstract class in v2
References: <1014478282.3625.5.camel@inspiron>
Message-ID: <027001c1bc8a$d2d41e30$0500a8c0@boostconsulting.com>

----- Original Message -----
From: "Min Xu" <minxu at sci.ccny.cuny.edu>
To: <c++-sig at python.org>
Sent: Saturday, February 23, 2002 10:31 AM
Subject: [C++-sig] Q: wrap an abstract class in v2


> I am wondering how can I wrap an abstract class in v2. the technique for
> v1 fails. Can anyone show me an example using boost.python v2? The
> abstract class has a undefined virtual function.

I haven't implemented virtual function callbacks for v2 yet. That's planned
for next week. Can you hang on for a few days?

Also, I'd be very interested to know if you ever got your object code size
to come down. I am checking in some changes later today (I hope) which
should improve things a bit, but the numbers you quoted earlier definitely
surprised me and I expect most of them are accounted for by build options.

-Dave





From randre at pppl.gov  Tue Feb 26 23:56:20 2002
From: randre at pppl.gov (Robert Andre)
Date: Tue, 26 Feb 2002 17:56:20 -0500 (EST)
Subject: [C++-sig] to_python
Message-ID: <200202262256.RAA30890@neptune.pppl.gov>

I have a c++ array type called uarray which I would like to wrap
so that the python return type might be a double or a new uarray.

I am trying to create a helper function such as

  PyObject* uarray_getitem(const uarray&, PyObject* p) ;

to wrap as __getitem__.  But I am having trouble because I want to
call  to_python(my_uarray)  when the return type should be a uarray
but the compiler complains about not having a definition for the
to_python(uarray) function:

/usr/local/include/boost/python/detail/extension_class.hpp: In function
   `PyObject* boost::python::to_python(const T&) [with T = PPPL_RGA::uarray]':
array_boost.cc:41:   instantiated from here
/usr/local/include/boost/python/detail/extension_class.hpp:393: `py_extension_class_converters'
   undeclared (first use this function)
/usr/local/include/boost/python/detail/extension_class.hpp:393: (Each
   undeclared identifier is reported only once for each function it appears
   in.)

So, a couple of questions:
1) Is creating a helper function with PyObjects the right approach?
2) Is there a way to declare to_python() functions for user types
explicitly in a header outside of the BOOST_PYTHON_MODULE_INIT block?

thanks,

rob andre



From david.abrahams at rcn.com  Wed Feb 27 15:35:37 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 27 Feb 2002 09:35:37 -0500
Subject: [C++-sig] to_python
References: <200202262256.RAA30890@neptune.pppl.gov>
Message-ID: <127b01c1bf9c$a316ac20$0500a8c0@boostconsulting.com>

Sorry, I'm going to have to ask you to be more specific.

----- Original Message -----
From: "Robert Andre" <randre at pppl.gov>

> I have a c++ array type called uarray which I would like to wrap
> so that the python return type might be a double or a new uarray.

The python return type of what?

> I am trying to create a helper function such as
>
>   PyObject* uarray_getitem(const uarray&, PyObject* p) ;
>
> to wrap as __getitem__.

A member of some extension class, I presume?

> But I am having trouble because I want to
> call  to_python(my_uarray)  when the return type should be a uarray
> but the compiler complains about not having a definition for the
> to_python(uarray) function:
>
> /usr/local/include/boost/python/detail/extension_class.hpp: In function
>    `PyObject* boost::python::to_python(const T&) [with T =
PPPL_RGA::uarray]':
> array_boost.cc:41:   instantiated from here
> /usr/local/include/boost/python/detail/extension_class.hpp:393:
`py_extension_class_converters'
>    undeclared (first use this function)
> /usr/local/include/boost/python/detail/extension_class.hpp:393: (Each
>    undeclared identifier is reported only once for each function it
appears
>    in.)

Have you exposed uarray to python with a class_builder<uarray>?
If so, you need to be sure the class_builder instantiation is visible
/before/ def(uarray_getitem...) is called to expose uarray_getitem to
Python.

> So, a couple of questions:
> 1) Is creating a helper function with PyObjects the right approach?

Hard to say. You haven't made clear what you're trying to accomplish.

> 2) Is there a way to declare to_python() functions for user types
> explicitly in a header outside of the BOOST_PYTHON_MODULE_INIT block?

Sure, they're just C++ functions; you can declare them in the ordinary way.

-Dave





From randre at pppl.gov  Wed Feb 27 17:53:48 2002
From: randre at pppl.gov (Robert Andre)
Date: Wed, 27 Feb 2002 11:53:48 -0500 (EST)
Subject: [C++-sig] to_python part two
Message-ID: <200202271653.LAA11161@neptune.pppl.gov>

Lets see if this makes more sense.  I am including only the
relevant parts of the code below. 

I have a C++ class which is meant to act like an array and 
defined as follows,

------------- uarray.h ------------
typedef valarray<size_t> Shape ;     // set of indices, e.g. (3,5)

class uarray {
public:
  uarray(const Shape&) ;             // construction

  double operator[](const Shape&) ;  // return a single double
  uarray operator[](size_t) ;        // return a slice
}
-----------------------------------

and I have a file for mapping my Shape class to python tuples,

---------- shape.h ------------
BOOST_PYTHON_BEGIN_CONVERSION_NAMESPACE
 
BOOST_PYTHON_DECL PyObject* to_python(const Shape&) ;
BOOST_PYTHON_DECL Shape from_python(PyObject*, boost::python::type<Shape>) ;
Shape from_python(PyObject*, boost::python::type<const Shape&>) ;
 
BOOST_PYTHON_END_CONVERSION_NAMESPACE
-------------------------------

and a separate wrapping code for boost,

------------- arraymod.cc -----------------
BOOST_PYTHON_MODULE_INIT(arraymod) {
  try {
    python::module_builder arraymod("arraymod") ;
 
    // --- class builders ---
    python::class_builder<uarray> uarray_class(arraymod, "uarray") ;

    uarray_class.def((double (uarray::*)(const Shape&) const) &uarray::operator[], "__getitem__") ;

  } catch(...) {
    //    python::handle_exception() ;
    throw ;
  } ;
}
-------------------------------------------

All of this works great so that I can do the following

  >> u = uarray((5,10))
  >> print u[(2,3)]
  0.0

HOWEVER, what I can't do now but I would like to be able to do 
is the following in python

  >> u = uarray((5,10))
  >> print u[(2,3)]       # same as before
  0.0
  >> print u[3][2]        # <--NEW-- slice first then return [2] of slice
  0.0

where u[3] returns a rank one uarray using the  uarray::operator[](size_t)
method and u[3][2] returns the double value.  This requires that
the method uarray::operator[](size_t) return a double for rank 1 arrays
or a uarray if the rank>1. C++ doesn't do multiple return types for
the same argument type but python does so my solution (I hope) is to 
create a helper function which deals directly with the python argument
and return types,

-------------- uarray_helper.cc ------------------
# include <boost/python/detail/config.hpp>
# include <boost/python/detail/wrap_python.hpp>
# include <boost/python/detail/none.hpp>
# include <boost/python/detail/signatures.hpp>
# include <boost/python/detail/extension_class.hpp>
# include <boost/smart_ptr.hpp>
# include <boost/python/errors.hpp>

PyObject* uarray_getitem(const uarray& u, PyObject* p) {

  PyObject* result = 0 ;
  ... code ...

  uarray uslice = u[k] ;       // find slice, int k extracted from p
  result = to_python(uslice) ; // <-- COMPILER COMPLAINS -- convert uarray to PyObject* 

  ... more code ...
  return result ;
} ; 

--------------------------------------------------

and wrap it instead of operator[]()

------------- arraymod.cc -----------------
BOOST_PYTHON_MODULE_INIT(arraymod) {
  try {
    python::module_builder arraymod("arraymod") ;
 
    // --- class builders ---
    python::class_builder<uarray> uarray_class(arraymod,     "uarray") ;

    uarray_class.def(&uarray_helper, "__getitem__") ;  // <----- CHANGE ----

  } catch(...) {
    //    python::handle_exception() ;
    throw ;
  } ;
}
-------------------------------------------


My problem is in compiling uarray_helper.cc.  to_python(uarray) is known from
extension_class.hpp but it complains about py_extension_class_converters.  I
am unfortunately at my limit of C++ knowledge.

g++ -I/usr/local/include/python2.2 -I/usr/local/include -c  -g -ftemplate-depth-32 -o uarray_helper.o uarray_helper.cc
/usr/local/include/boost/python/detail/extension_class.hpp: In function
   `PyObject* boost::python::to_python(const T&) [with T = uarray]':
uarray_helper.cc:41:   instantiated from here
/usr/local/include/boost/python/detail/extension_class.hpp:393: `py_extension_class_converters'
   undeclared (first use this function)
/usr/local/include/boost/python/detail/extension_class.hpp:393: (Each
   undeclared identifier is reported only once for each function it appears
   in.)

Dave, thanks for any help you can provide.  Boost python is really slick and
I am hoping to be able to use it here at the princeton plasma physics lab.

rob andre



From david.abrahams at rcn.com  Wed Feb 27 20:41:46 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 27 Feb 2002 14:41:46 -0500
Subject: [C++-sig] to_python part two
References: <200202271653.LAA11161@neptune.pppl.gov>
Message-ID: <13a701c1bfc6$fc6cc0a0$0500a8c0@boostconsulting.com>

----- Original Message -----
From: "Robert Andre" <randre at pppl.gov>
To: <c++-sig at python.org>
Sent: Wednesday, February 27, 2002 11:53 AM
Subject: [C++-sig] to_python part two


>
> Lets see if this makes more sense.  I am including only the
> relevant parts of the code below.
>

<snip>
OK so far...

> -------------- uarray_helper.cc ------------------
> # include <boost/python/detail/config.hpp>
> # include <boost/python/detail/wrap_python.hpp>
> # include <boost/python/detail/none.hpp>
> # include <boost/python/detail/signatures.hpp>
> # include <boost/python/detail/extension_class.hpp>
> # include <boost/smart_ptr.hpp>
> # include <boost/python/errors.hpp>
>
> PyObject* uarray_getitem(const uarray& u, PyObject* p) {
>
>   PyObject* result = 0 ;
>   ... code ...
>
>   uarray uslice = u[k] ;       // find slice, int k extracted from p
>   result = to_python(uslice) ; // <-- COMPILER COMPLAINS -- convert uarray
to PyObject*


Right, it's like I said: the class_builder<uarray> instantiation needs to be
visible before you try this. So, add

namespace boost { namespace python {
  template class class_builder<uarray>; // explicitly instantiate
}} // namespace boost::python

at the top of this source file.

-Dave