From eric at enthought.com  Tue Oct  1 10:14:30 2002
From: eric at enthought.com (eric jones)
Date: Tue, 1 Oct 2002 03:14:30 -0500
Subject: [C++-sig] Anyone tried BGL with BoostPython 2 yet?
In-Reply-To: <0b2c01c267e0$10a85e00$6501a8c0@boostconsulting.com>
Message-ID: <003701c26922$91a06e10$6b01a8c0@ericlaptop>

> 
> > From: "Robert Oschler" <robertoschler at hotmail.com>
> >> Anybody been adventurous enough to try the Boost Graph Library with
> Boost
> >> Python v 2?  Just wondering what I might be getting myself into
> >> (difficulty-wise).
> >>
> >> thx
> 
> From: "David Abrahams" <dave at boost-consulting.com>
> 
> 
> > People asked about this with Boost.Python v1, too. I think the
biggest
> > problem you'll find is that BGL is about compile-time genericity and
> Python
> > is about runtime genericity. You could easily  map the BGL's
genericity
> > into Python, but that'd be best done by rewriting it in Python. Of
> course,
> > then you'd give up most of the speed.
> >
> > Wrapping individual algorithms specialized to operate on specific
graph
> > structures with Boost.Python should be easy, of course, and the
> algorithms
> > would run fast. You could think about building graphs with internal
> > property maps that contain a boost::python::object for each
edge/vertex.
> > That might be an approach which allows some compromises.
> 
> Another interesting area to explore might be some kind of weave-like
> arrangement where C++ code for specific graph configurations is
generated
> and compiled on-the-fly as different Python graph structures are
passed to
> BGL algorithms.

This is likely possible.  I haven't look at BGL at all, but the process
you describe fits weave's mode of operation.

eric




From dave at boost-consulting.com  Tue Oct  1 15:09:13 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 1 Oct 2002 09:09:13 -0400
Subject: [C++-sig] Boost.Python v2: A few small changes
Message-ID: <029201c2694b$d07075d0$6701a8c0@boostconsulting.com>

In preparation for release, I've been working on documentation. When I read
my documentation, I sometimes get an uncomfortable feeling about what I
have to write and realize it would be better to fix the implementation. A
few small changes are happening now as a result:

1. The BOOST_PYTHON_[MEMBER_]FUNCTION_OVERLOADS macros used to expose
functions with default arguments will not be available by simply #including
<boost/python/class.hpp> or <boost/python/def.hpp>. Instead they will be
moved to <boost/python/overloads.hpp>

2. The module class is officially disappearing, for real. I'm going to keep
module.hpp, but only so I can do:

    #include <boost/python/module_init.hpp>
    #define BOOST_PYTHON_MODULE BOOST_PYTHON_MODULE_INIT

BOOST_PYTHON_MODULE_INIT will continue to be available but deprecated for
Boost 1.29.0, but the "official" macro will be BOOST_PYTHON_MODULE

By the way, I've been pondering the merits of having a <boost/python.hpp>
header which exposes all of the public headers, just for ease-of-use.
Opinions?

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com






From Greg.Hawkins at softwire.co.uk  Tue Oct  1 16:09:45 2002
From: Greg.Hawkins at softwire.co.uk (Greg Hawkins)
Date: Tue, 1 Oct 2002 15:09:45 +0100
Subject: [C++-sig] Boost.Python v2: A few small changes
Message-ID: <616BE6A276E3714788D2AC35C40CD18D6B9AE7@whale.softwire.co.uk>

>> By the way, I've been pondering the merits of having a <boost/python.hpp>
>> header which exposes all of the public headers, just for ease-of-use.
>> Opinions?

Not really bothered either way.

However, on a related issue, I'd definitely like to see <boost/python/detail/wrap_python.hpp> moved up out of detail. It's useful in its own right if you're embedding and neither including a "detail/" header directly nor including an arbitrary public header to get at it are very elegant.

best,
Greg

-----Original Message-----
From: David Abrahams [mailto:dave at boost-consulting.com]
Sent: 01 October 2002 14:09
To: pysig
Subject: [C++-sig] Boost.Python v2: A few small changes

[...]



From dave at boost-consulting.com  Tue Oct  1 16:14:26 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 1 Oct 2002 10:14:26 -0400
Subject: [C++-sig] Boost.Python v2: A few small changes
References: <616BE6A276E3714788D2AC35C40CD18D6B9AE7@whale.softwire.co.uk>
Message-ID: <02e801c26955$3f0f0200$6701a8c0@boostconsulting.com>

From: "Greg Hawkins" <Greg.Hawkins at softwire.co.uk>

>However, on a related issue, I'd definitely like to see
<boost/python/detail/wrap_python.hpp> moved up out of detail. It's useful
in its own right if you're embedding and neither including a "detail/"
header directly nor including an arbitrary public header to get at it are
very elegant.

Well, embedding isn't really well-supported for 1.29.0. The problem is that
there are global objects keeping some Python objects alive, and those
Python objects need to be released before the interpreter is finalized
(preferably using Python's atexit module) or the application will crash on
exit. When we finally get that going, I'm happy to consider changes which
are specifically for embedding support.

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com





From djowel at gmx.co.uk  Tue Oct  1 17:55:20 2002
From: djowel at gmx.co.uk (Joel de Guzman)
Date: Tue, 1 Oct 2002 23:55:20 +0800
Subject: [C++-sig] Boost.Python v2: A few small changes
References: <029201c2694b$d07075d0$6701a8c0@boostconsulting.com>
Message-ID: <008701c26963$075699f0$0100a8c0@kim>

----- Original Message ----- 
From: "David Abrahams" <dave at boost-consulting.com>

> 
> By the way, I've been pondering the merits of having a <boost/python.hpp>
> header which exposes all of the public headers, just for ease-of-use.
> Opinions?

I've often wondered what people *really* think about this, not only
in the context of boost.python but all libraries in general. I'm very
interested to hear the general consensus. Modern C++ stresses
the compiler a lot and brings it to its knees. An all encompassing 
header, while easy to type, will unnecessarily add more burden on 
the already burdened compiler. OTOH, if the user is fully aware
of these issues, then it's his call. He has a choice of easy typing
vs. longer compile times.

--Joel

PS> Was this issue ever raised in boost?






From leo at hiper.com.br  Tue Oct  1 23:09:00 2002
From: leo at hiper.com.br (Leonardo Rochael Almeida)
Date: 01 Oct 2002 18:09:00 -0300
Subject: [C++-sig] char '\0' -> "\0" or ""?
In-Reply-To: <20020913171950.65231.qmail@web20206.mail.yahoo.com>
References: <20020913171950.65231.qmail@web20206.mail.yahoo.com>
Message-ID: <1033506540.26277.2.camel@spitfire>

I was rereading the archives and found this one, and since no one
answered I think I'll give my opinion :-)

On Fri, 2002-09-13 at 14:19, Ralf W. Grosse-Kunstleve wrote:
> Consider
> 
> char foo() { return '\0'; }
> 
> def("foo", foo);
> 
> Python with Boost.Python V1: foo() == ""
> Python with Boost.Python V2: foo() == "\0"
> 
> Is this difference intentional?

I don't know :-)

> I'd prefer the V1 result.
> Opinions?

If you're returning a C/C++ char in a wrapped function to python, I
think it should always return something such that len(foo()) == 1. I'd
prefer the V2 result, as I believe it sits better with the 'Explicit
better than implicit' Python rule.

Cheers, Leo

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.




From datafeed at SoftHome.net  Wed Oct  2 00:22:49 2002
From: datafeed at SoftHome.net (M. Evans)
Date: Tue, 1 Oct 2002 15:22:49 -0700
Subject: [C++-sig] Re: Boost.Python v2: A few small changes
Message-ID: <178197497.20021001152249@SoftHome.net>

> the merits of having a <boost/python.hpp> header which exposes
> all of the public headers   Opinions?

Yes by all means, since that will help BPL newbies.  Lots of people
(cf Eric of Scipy!) are scared away by BPL's complexity.

Mark




From achim.domma at syynx.de  Wed Oct  2 08:43:54 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Wed, 2 Oct 2002 08:43:54 +0200
Subject: [C++-sig] Re: Boost.Python v2: A few small changes
In-Reply-To: <178197497.20021001152249@SoftHome.net>
Message-ID: <FCEMIEFBFOIDAOJDEPIAKEADDPAA.achim.domma@syynx.de>

> > the merits of having a <boost/python.hpp> header which exposes
> > all of the public headers   Opinions?
>
> Yes by all means, since that will help BPL newbies.  Lots of people
> (cf Eric of Scipy!) are scared away by BPL's complexity.

I totaly agree. I think it should be the users choice whether he prefers
easy typing or shorter compile times.

Achim





From mtremblay at golemlabs.com  Wed Oct  2 13:52:34 2002
From: mtremblay at golemlabs.com (Mathieu Tremblay)
Date: Wed, 2 Oct 2002 07:52:34 -0400
Subject: [C++-sig] Pointer manipulation Boost.Python -  C++
Message-ID: <000801c26a0a$32aa3d30$6700a8c0@Golemlabmat>

Hello,
I am taking a look at Boost.Python and I wonder if it is possible 
to convert pointers to existing classes to PyObjects* and then be 
able to pass an existing instance of an object directly to and from
python:

 Example:
  In C++ I create a CWheel and I set its member m_diameter to 1233.  In 
 python I have a function that receives a CWheel and displays the 
 diameter (Lets suppose that Python knows the CWheel from Boost.Python
:-) )
             Ex : def printCWheelDiam(awheel):
                         print awheel.m_diameter

             What I would like to do Is to create the CWheel in C++, 
 pass its pointer to python so it can manipulate 
 it (and see that its diameter is 1233)  and then return a 
 CWheel that I could map from a PyObject to a CWheel in C++.

 In SWIG, it was easy to convert the pointers with the function :
             C++ to Python :             MYSWIG_NewPointerObj
             Python to C++:              MYSWIG_ConvertPtr

 Do you have an equivalent to these functions ? Or can you point me to 
 documentation that explains how to do it ? Thanks again,


Mathieu Tremblay
mtremblay at golemlabs.com




From dave at boost-consulting.com  Wed Oct  2 14:05:10 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 2 Oct 2002 08:05:10 -0400
Subject: [C++-sig] Pointer manipulation Boost.Python -  C++
References: <000801c26a0a$32aa3d30$6700a8c0@Golemlabmat>
Message-ID: <059c01c26a0c$43cc4ed0$6701a8c0@boostconsulting.com>

I'm going to answer this in terms of Boost.Python v2, since v1 is now
retired and won't be in the upcoming release.

From: "Mathieu Tremblay" <mtremblay at golemlabs.com>


> Hello,
> I am taking a look at Boost.Python and I wonder if it is possible
> to convert pointers to existing classes to PyObjects* and then be
> able to pass an existing instance of an object directly to and from
> python:

It is.

>  Example:
>   In C++ I create a CWheel and I set its member m_diameter to 1233.  In
>  python I have a function that receives a CWheel and displays the
>  diameter (Lets suppose that Python knows the CWheel from Boost.Python
> :-) )
>              Ex : def printCWheelDiam(awheel):
>                          print awheel.m_diameter
>
>              What I would like to do Is to create the CWheel in C++,
>  pass its pointer to python so it can manipulate
>  it (and see that its diameter is 1233)  and then return a
>  CWheel that I could map from a PyObject to a CWheel in C++.

The safest thing to do is to create the CWheel by invoking its class
wrapper:

    // Declare the CWheel extension class
    object wheel_class =
        class_<CWheel>("CWheel")
            .def_readonly("m_diameter", &CWheel::m_diameter)
            .def("some_member_function", &CWheel::some_member_function)
            ...
            ;

    object wheel_obj = wheel_class(); // construct one

Now you can pass wheel_obj back to python, and all reference counts are
nicely managed. You don't need to "map" anything between C++ and Python;
the library takes care of that for you.

If you really want to pass pointers around, it's certainly possible to tell
the library to build a Python object around the pointer, but then you need
to make sure the lifetime of the C++ object being referenced by the pointer
extends past the lifetime of all Python references to the object or your
program will crash.


-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com





From ssmith at magnet.fsu.edu  Wed Oct  2 16:02:38 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Wed, 02 Oct 2002 10:02:38 -0400
Subject: [C++-sig] std::vector
In-Reply-To: <059c01c26a0c$43cc4ed0$6701a8c0@boostconsulting.com>
Message-ID: <PCEJJPDHEECNEKDDLPNLOEEGCAAA.ssmith@magnet.fsu.edu>

Hello,

I have been reading the documentation on dealing with std::vector<> in
Boost.Python, http://www.boost.org/libs/python/doc/cross_module.html, and
this is exactly what I need for both vectors of built-in types and those
using my own classes. I have used the class builder to expose such a vector
as a Python object and now need to be able to go back and export some C++
functions that use them as arguments or as a return type.

Is there a module already in Boost.Python that has "std_vector"? I cannot
find anything on it and the html page above only supposes that one had such
a module. I think it would help me out quite a bit if I could play with some
vector<int> functions to try out what is suggested. Even more, if some of
this is already in Boost.Python I would surely like to use it rather than
begin doing so for all the class types I am using with std::vector.

For example, I have this to expose my std::vector<std::string>:

    boost::python::class_builder<std::vector<std::string> >
Vstring(PyModule, "Vstring");
    Vstring.def(boost::python::constructor<>());
    Vstring.def(Vstring_push_back, "push_back");

and this allows me to make objects of Vstring in Python just fine. The
push_back stuff is done as shown in the comprehensive test. Now, how do I
get

VS = Vstring()
VS = MyFunctionReturningStdVectorOfStrings()
MyFunctionUsingStdVectorOfStrings(VS)

by exporting C++ functions that are something like

std::vector<std::string> MyFunctionReturningStdVectorOfStrings();
void MyFunctionUsingStdVectorOfStrings(std::vector<std::string>);

to work in Python. Do I need import_converters/export_converters? Do I need
them even when everything is in the same module? Neither the "vector_double"
nor "string_map" in the comprehensive test show this and AFAIK the test does
have any code where C++ functions using and returning std::vector<double>
are exported and making use of vector_double.

Is there other documentation on this, or perhaps a place where I can easily
search for such info?

Thanks,
Scott


 =======================================
 Dr. Scott A. Smith
 Associate in Research
 National High Magnetic Field Laboratory
 1800 East Paul Dirac Drive
 Tallahassee, FL 32310

 phone: (850) 644-6348
 FAX:   (850) 644-1366
 email: ssmith at magnet.fsu.edu
 http://www.magnet.fsu.edu
 http://gamma.magnet.fsu.edu



> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams
> Sent: Wednesday, October 02, 2002 8:05 AM
> To: c++-sig at python.org
> Subject: Re: [C++-sig] Pointer manipulation Boost.Python - C++
>
>
> I'm going to answer this in terms of Boost.Python v2, since v1 is now
> retired and won't be in the upcoming release.
>
> From: "Mathieu Tremblay" <mtremblay at golemlabs.com>
>
>
> > Hello,
> > I am taking a look at Boost.Python and I wonder if it is possible
> > to convert pointers to existing classes to PyObjects* and then be
> > able to pass an existing instance of an object directly to and from
> > python:
>
> It is.
>
> >  Example:
> >   In C++ I create a CWheel and I set its member m_diameter to 1233.  In
> >  python I have a function that receives a CWheel and displays the
> >  diameter (Lets suppose that Python knows the CWheel from Boost.Python
> > :-) )
> >              Ex : def printCWheelDiam(awheel):
> >                          print awheel.m_diameter
> >
> >              What I would like to do Is to create the CWheel in C++,
> >  pass its pointer to python so it can manipulate
> >  it (and see that its diameter is 1233)  and then return a
> >  CWheel that I could map from a PyObject to a CWheel in C++.
>
> The safest thing to do is to create the CWheel by invoking its class
> wrapper:
>
>     // Declare the CWheel extension class
>     object wheel_class =
>         class_<CWheel>("CWheel")
>             .def_readonly("m_diameter", &CWheel::m_diameter)
>             .def("some_member_function", &CWheel::some_member_function)
>             ...
>             ;
>
>     object wheel_obj = wheel_class(); // construct one
>
> Now you can pass wheel_obj back to python, and all reference counts are
> nicely managed. You don't need to "map" anything between C++ and Python;
> the library takes care of that for you.
>
> If you really want to pass pointers around, it's certainly
> possible to tell
> the library to build a Python object around the pointer, but then you need
> to make sure the lifetime of the C++ object being referenced by
> the pointer
> extends past the lifetime of all Python references to the object or your
> program will crash.
>
>
> -----------------------------------------------------------
>            David Abrahams * Boost Consulting
> dave at boost-consulting.com * http://www.boost-consulting.com
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>




From dave at boost-consulting.com  Wed Oct  2 16:44:39 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 2 Oct 2002 10:44:39 -0400
Subject: [C++-sig] std::vector
References: <PCEJJPDHEECNEKDDLPNLOEEGCAAA.ssmith@magnet.fsu.edu>
Message-ID: <062001c26a22$897b32a0$6701a8c0@boostconsulting.com>

Hi Scott,

I think Ralf Grosse-Kunstleve is probably the one to answer your questions.
He's the one who implemented the import/export stuff for Boost.Python v1,
and has the most expertise in translating containers. He also has
implemented a much better mechanism for Boost.Python v2. He's been
travelling, but IIUC he might be able to get back to you by the end of the
week.

-Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com


----- Original Message -----
From: "Scott A. Smith" <ssmith at magnet.fsu.edu>
To: <c++-sig at python.org>
Sent: Wednesday, October 02, 2002 10:02 AM
Subject: [C++-sig] std::vector


> Hello,
>
> I have been reading the documentation on dealing with std::vector<> in
> Boost.Python, http://www.boost.org/libs/python/doc/cross_module.html, and
> this is exactly what I need for both vectors of built-in types and those
> using my own classes. I have used the class builder to expose such a
vector
> as a Python object and now need to be able to go back and export some C++
> functions that use them as arguments or as a return type.
>
> Is there a module already in Boost.Python that has "std_vector"? I cannot
> find anything on it and the html page above only supposes that one had
such
> a module. I think it would help me out quite a bit if I could play with
some
> vector<int> functions to try out what is suggested. Even more, if some of
> this is already in Boost.Python I would surely like to use it rather than
> begin doing so for all the class types I am using with std::vector.
>
> For example, I have this to expose my std::vector<std::string>:
>
>     boost::python::class_builder<std::vector<std::string> >
> Vstring(PyModule, "Vstring");
>     Vstring.def(boost::python::constructor<>());
>     Vstring.def(Vstring_push_back, "push_back");
>
> and this allows me to make objects of Vstring in Python just fine. The
> push_back stuff is done as shown in the comprehensive test. Now, how do I
> get
>
> VS = Vstring()
> VS = MyFunctionReturningStdVectorOfStrings()
> MyFunctionUsingStdVectorOfStrings(VS)
>
> by exporting C++ functions that are something like
>
> std::vector<std::string> MyFunctionReturningStdVectorOfStrings();
> void MyFunctionUsingStdVectorOfStrings(std::vector<std::string>);
>
> to work in Python. Do I need import_converters/export_converters? Do I
need
> them even when everything is in the same module? Neither the
"vector_double"
> nor "string_map" in the comprehensive test show this and AFAIK the test
does
> have any code where C++ functions using and returning std::vector<double>
> are exported and making use of vector_double.
>
> Is there other documentation on this, or perhaps a place where I can
easily
> search for such info?
>
> Thanks,
> Scott
>
>
>  =======================================
>  Dr. Scott A. Smith
>  Associate in Research
>  National High Magnetic Field Laboratory
>  1800 East Paul Dirac Drive
>  Tallahassee, FL 32310
>
>  phone: (850) 644-6348
>  FAX:   (850) 644-1366
>  email: ssmith at magnet.fsu.edu
>  http://www.magnet.fsu.edu
>  http://gamma.magnet.fsu.edu
>
>
>
> > -----Original Message-----
> > From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> > Behalf Of David Abrahams
> > Sent: Wednesday, October 02, 2002 8:05 AM
> > To: c++-sig at python.org
> > Subject: Re: [C++-sig] Pointer manipulation Boost.Python - C++
> >
> >
> > I'm going to answer this in terms of Boost.Python v2, since v1 is now
> > retired and won't be in the upcoming release.
> >
> > From: "Mathieu Tremblay" <mtremblay at golemlabs.com>
> >
> >
> > > Hello,
> > > I am taking a look at Boost.Python and I wonder if it is possible
> > > to convert pointers to existing classes to PyObjects* and then be
> > > able to pass an existing instance of an object directly to and from
> > > python:
> >
> > It is.
> >
> > >  Example:
> > >   In C++ I create a CWheel and I set its member m_diameter to 1233.
In
> > >  python I have a function that receives a CWheel and displays the
> > >  diameter (Lets suppose that Python knows the CWheel from
Boost.Python
> > > :-) )
> > >              Ex : def printCWheelDiam(awheel):
> > >                          print awheel.m_diameter
> > >
> > >              What I would like to do Is to create the CWheel in C++,
> > >  pass its pointer to python so it can manipulate
> > >  it (and see that its diameter is 1233)  and then return a
> > >  CWheel that I could map from a PyObject to a CWheel in C++.
> >
> > The safest thing to do is to create the CWheel by invoking its class
> > wrapper:
> >
> >     // Declare the CWheel extension class
> >     object wheel_class =
> >         class_<CWheel>("CWheel")
> >             .def_readonly("m_diameter", &CWheel::m_diameter)
> >             .def("some_member_function", &CWheel::some_member_function)
> >             ...
> >             ;
> >
> >     object wheel_obj = wheel_class(); // construct one
> >
> > Now you can pass wheel_obj back to python, and all reference counts are
> > nicely managed. You don't need to "map" anything between C++ and
Python;
> > the library takes care of that for you.
> >
> > If you really want to pass pointers around, it's certainly
> > possible to tell
> > the library to build a Python object around the pointer, but then you
need
> > to make sure the lifetime of the C++ object being referenced by
> > the pointer
> > extends past the lifetime of all Python references to the object or
your
> > program will crash.
> >
> >
> > -----------------------------------------------------------
> >            David Abrahams * Boost Consulting
> > dave at boost-consulting.com * http://www.boost-consulting.com
> >
> >
> >
> > _______________________________________________
> > 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 rwgk at yahoo.com  Wed Oct  2 23:37:17 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 2 Oct 2002 14:37:17 -0700 (PDT)
Subject: [C++-sig] std::vector
In-Reply-To: <062001c26a22$897b32a0$6701a8c0@boostconsulting.com>
Message-ID: <20021002213717.25151.qmail@web20201.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> Hi Scott,
> 
> I think Ralf Grosse-Kunstleve is probably the one to answer your questions.
> He's the one who implemented the import/export stuff for Boost.Python v1,
> and has the most expertise in translating containers. He also has
> implemented a much better mechanism for Boost.Python v2. He's been
> travelling, but IIUC he might be able to get back to you by the end of the
> week.

I could dig out some old stuff that I used with Boost.Python v1, but I highly
recommend using Boost.Python v2. Is that a possibility?
Ralf

> ----- Original Message -----
> From: "Scott A. Smith" <ssmith at magnet.fsu.edu>
> To: <c++-sig at python.org>
> Sent: Wednesday, October 02, 2002 10:02 AM
> Subject: [C++-sig] std::vector
> 
> 
> > Hello,
> >
> > I have been reading the documentation on dealing with std::vector<> in
> > Boost.Python, http://www.boost.org/libs/python/doc/cross_module.html, and
> > this is exactly what I need for both vectors of built-in types and those
> > using my own classes. I have used the class builder to expose such a
> vector
> > as a Python object and now need to be able to go back and export some C++
> > functions that use them as arguments or as a return type.
> >
> > Is there a module already in Boost.Python that has "std_vector"? I cannot
> > find anything on it and the html page above only supposes that one had
> such
> > a module. I think it would help me out quite a bit if I could play with
> some
> > vector<int> functions to try out what is suggested. Even more, if some of
> > this is already in Boost.Python I would surely like to use it rather than
> > begin doing so for all the class types I am using with std::vector.
> >
> > For example, I have this to expose my std::vector<std::string>:
> >
> >     boost::python::class_builder<std::vector<std::string> >
> > Vstring(PyModule, "Vstring");
> >     Vstring.def(boost::python::constructor<>());
> >     Vstring.def(Vstring_push_back, "push_back");
> >
> > and this allows me to make objects of Vstring in Python just fine. The
> > push_back stuff is done as shown in the comprehensive test. Now, how do I
> > get
> >
> > VS = Vstring()
> > VS = MyFunctionReturningStdVectorOfStrings()
> > MyFunctionUsingStdVectorOfStrings(VS)
> >
> > by exporting C++ functions that are something like
> >
> > std::vector<std::string> MyFunctionReturningStdVectorOfStrings();
> > void MyFunctionUsingStdVectorOfStrings(std::vector<std::string>);
> >
> > to work in Python. Do I need import_converters/export_converters? Do I
> need
> > them even when everything is in the same module? Neither the
> "vector_double"
> > nor "string_map" in the comprehensive test show this and AFAIK the test
> does
> > have any code where C++ functions using and returning std::vector<double>
> > are exported and making use of vector_double.
> >
> > Is there other documentation on this, or perhaps a place where I can
> easily
> > search for such info?
> >
> > Thanks,
> > Scott
> >
> >
> >  =======================================
> >  Dr. Scott A. Smith
> >  Associate in Research
> >  National High Magnetic Field Laboratory
> >  1800 East Paul Dirac Drive
> >  Tallahassee, FL 32310
> >
> >  phone: (850) 644-6348
> >  FAX:   (850) 644-1366
> >  email: ssmith at magnet.fsu.edu
> >  http://www.magnet.fsu.edu
> >  http://gamma.magnet.fsu.edu
> >
> >
> >
> > > -----Original Message-----
> > > From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> > > Behalf Of David Abrahams
> > > Sent: Wednesday, October 02, 2002 8:05 AM
> > > To: c++-sig at python.org
> > > Subject: Re: [C++-sig] Pointer manipulation Boost.Python - C++
> > >
> > >
> > > I'm going to answer this in terms of Boost.Python v2, since v1 is now
> > > retired and won't be in the upcoming release.
> > >
> > > From: "Mathieu Tremblay" <mtremblay at golemlabs.com>
> > >
> > >
> > > > Hello,
> > > > I am taking a look at Boost.Python and I wonder if it is possible
> > > > to convert pointers to existing classes to PyObjects* and then be
> > > > able to pass an existing instance of an object directly to and from
> > > > python:
> > >
> > > It is.
> > >
> > > >  Example:
> > > >   In C++ I create a CWheel and I set its member m_diameter to 1233.
> In
> > > >  python I have a function that receives a CWheel and displays the
> > > >  diameter (Lets suppose that Python knows the CWheel from
> Boost.Python
> > > > :-) )
> > > >              Ex : def printCWheelDiam(awheel):
> > > >                          print awheel.m_diameter
> > > >
> > > >              What I would like to do Is to create the CWheel in C++,
> > > >  pass its pointer to python so it can manipulate
> > > >  it (and see that its diameter is 1233)  and then return a
> > > >  CWheel that I could map from a PyObject to a CWheel in C++.
> > >
> > > The safest thing to do is to create the CWheel by invoking its class
> > > wrapper:
> > >
> > >     // Declare the CWheel extension class
> > >     object wheel_class =
> > >         class_<CWheel>("CWheel")
> > >             .def_readonly("m_diameter", &CWheel::m_diameter)
> > >             .def("some_member_function", &CWheel::some_member_function)
> > >             ...
> > >             ;
> > >
> > >     object wheel_obj = wheel_class(); // construct one
> > >
> > > Now you can pass wheel_obj back to python, and all reference counts are
> > > nicely managed. You don't need to "map" anything between C++ and
> Python;
> > > the library takes care of that for you.
> > >
> > > If you really want to pass pointers around, it's certainly
> > > possible to tell
> > > the library to build a Python object around the pointer, but then you
> need
> > > to make sure the lifetime of the C++ object being referenced by
> > > the pointer
> > > extends past the lifetime of all Python references to the object or
> your
> > > program will crash.
> > >
> > >
> > > -----------------------------------------------------------
> > >            David Abrahams * Boost Consulting
> > > dave at boost-consulting.com * http://www.boost-consulting.com
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
> >
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com



From ssmith at magnet.fsu.edu  Thu Oct  3 15:18:18 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Thu, 03 Oct 2002 09:18:18 -0400
Subject: [C++-sig] std::vector
In-Reply-To: <20021002213717.25151.qmail@web20201.mail.yahoo.com>
Message-ID: <PCEJJPDHEECNEKDDLPNLGEEHCAAA.ssmith@magnet.fsu.edu>

Hi Ralf,

> I could dig out some old stuff that I used with Boost.Python v1, 
> but I highly
> recommend using Boost.Python v2. Is that a possibility?

Quite frankly, I don't know. It is not clear to me how one uses/builds
version 2 versus version 1 yet. I there a way to see what version the
Boost.Python library is? I am pretty sure that at the moment I am using
1.28, but I did build the cvs version few months back. At that time
I remember I was confused over which version I was actually building.
Didn't it depend upon what directory jam was invoked from or something
like that? I'll look over the old messages to see if I can make sense out
of things, and try to build/switch to v2. Hopefully it will be
compatible with what I have done so far. I guess I need to
update my Boost stuff from CVS? Then (since I only need Boost.Python at
the moment), does it still matter what directory I start the build from?

It would be great if I can get vectors, lists, etc. working smoothly.
Your (& Dave's) help is and has been much appreciated.

Scott
 

> I have been reading the documentation on dealing with std::vector<> in
> Boost.Python, 
> http://www.boost.org/libs/python/doc/cross_module.html, and
> this is exactly what I need for both vectors of built-in 
> types and those
> using my own classes. I have used the class builder to expose such a
> vector
> as a Python object and now need to be able to go back and 
> export some C++
> functions that use them as arguments or as a return type.
>
> Is there a module already in Boost.Python that has 
> "std_vector"? I cannot
> find anything on it and the html page above only supposes that one had
> such
> a module. I think it would help me out quite a bit if I could 
> play with
> some
> vector<int> functions to try out what is suggested. Even 
> more, if some of
> this is already in Boost.Python I would surely like to use it 
> rather than
> begin doing so for all the class types I am using with std::vector.
>
> For example, I have this to expose my std::vector<std::string>:
>
>     boost::python::class_builder<std::vector<std::string> >
> Vstring(PyModule, "Vstring");
>     Vstring.def(boost::python::constructor<>());
>     Vstring.def(Vstring_push_back, "push_back");
>
> and this allows me to make objects of Vstring in Python just fine. The
> push_back stuff is done as shown in the comprehensive test. 
> Now, how do I get
>
> VS = Vstring()
> VS = MyFunctionReturningStdVectorOfStrings()
> MyFunctionUsingStdVectorOfStrings(VS)
>
> by exporting C++ functions that are something like
>
> std::vector<std::string> MyFunctionReturningStdVectorOfStrings();
> void MyFunctionUsingStdVectorOfStrings(std::vector<std::string>);
>
> to work in Python. Do I need import_converters/export_converters? Do I
> need
> them even when everything is in the same module? Neither the
> "vector_double"
> nor "string_map" in the comprehensive test show this and 
> AFAIK the test
> does
> have any code where C++ functions using and returning 
> std::vector<double>
> are exported and making use of vector_double.
>
> Is there other documentation on this, or perhaps a place where I can
> easily
> search for such info?




From rwgk at yahoo.com  Thu Oct  3 16:10:22 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 3 Oct 2002 07:10:22 -0700 (PDT)
Subject: [C++-sig] std::vector
In-Reply-To: <PCEJJPDHEECNEKDDLPNLGEEHCAAA.ssmith@magnet.fsu.edu>
Message-ID: <20021003141022.99413.qmail@web20207.mail.yahoo.com>

--- "Scott A. Smith" <ssmith at magnet.fsu.edu> wrote:
> At that time
> I remember I was confused over which version I was actually building.
> Didn't it depend upon what directory jam was invoked from or something
> like that?

Right. You have to start bjam in libs/python/test to get the V2 build.

> I'll look over the old messages to see if I can make sense out
> of things, and try to build/switch to v2. Hopefully it will be
> compatible with what I have done so far.

V2 is awesome. In comparison V1 seems like a prototype. Since V2 is so much
improved you will have to rework your Boost.Python code.

> I guess I need to
> update my Boost stuff from CVS? Then (since I only need Boost.Python at
> the moment), does it still matter what directory I start the build from?

I believe so. Unfortunately the main CVS is broken right now because of some
recent changes in the random number library. I will try the release candidate
branch to see if that works ...
 
> It would be great if I can get vectors, lists, etc. working smoothly.
> Your (& Dave's) help is and has been much appreciated.

I am sure the Boost.Python V2 facilities will help you achieving this goal. I
am planning to write a little summary of the choices that you have. But first
we have to get the CVS going again.

Ralf


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com



From dave at boost-consulting.com  Thu Oct  3 15:51:40 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 3 Oct 2002 09:51:40 -0400
Subject: [C++-sig] std::vector
References: <20021003141022.99413.qmail@web20207.mail.yahoo.com>
Message-ID: <092901c26ae4$66c35400$6701a8c0@boostconsulting.com>

From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>


> --- "Scott A. Smith" <ssmith at magnet.fsu.edu> wrote:
> > At that time
> > I remember I was confused over which version I was actually building.
> > Didn't it depend upon what directory jam was invoked from or something
> > like that?
>
> Right. You have to start bjam in libs/python/test to get the V2 build.

Well, you can do it in libs/python if all you want is the library and none
of the tests.

> I am sure the Boost.Python V2 facilities will help you achieving this
goal. I
> am planning to write a little summary of the choices that you have. But
first
> we have to get the CVS going again.

Before Jens gets to fixing the actual Boost.Random problems, Jeremy's going
to break the dependency between boost::graph::adjacency_list and
Boost.Random so that our errors disappear. I'm pretty sure the release
candidate branch will work in the meantime. Or, you can get boost as I
tagged it for my LLNL deliverable:

    cd $BOOST_ROOT
    cvs update -rboost_python_llnl_ .

Which I know to be a working version.

-Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From dave at boost-consulting.com  Thu Oct  3 16:23:21 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 3 Oct 2002 10:23:21 -0400
Subject: [C++-sig] Trunk OK?
Message-ID: <094d01c26ae9$1afba9a0$6701a8c0@boostconsulting.com>

According to my tests, things on the CVS main trunk are working again for
Boost.Python v2.

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com






From rwgk at yahoo.com  Thu Oct  3 20:35:40 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 3 Oct 2002 11:35:40 -0700 (PDT)
Subject: [C++-sig] std::vector
In-Reply-To: <20021003141022.99413.qmail@web20207.mail.yahoo.com>
Message-ID: <20021003183540.56741.qmail@web20209.mail.yahoo.com>

--- "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> wrote:
> --- "Scott A. Smith" <ssmith at magnet.fsu.edu> wrote:
> > It would be great if I can get vectors, lists, etc. working smoothly.
> > Your (& Dave's) help is and has been much appreciated.
> 
> I am sure the Boost.Python V2 facilities will help you achieving this goal. I
> am planning to write a little summary of the choices that you have. But first
> we have to get the CVS going again.

I have verified that the RC_1_29_0 branch of boost is working properly. 

Attached is the little summary that I promised earlier. Feedback is most
welcome.

Ralf

Notes on container conversions in Boost.Python V2:

1. Using the regular class_<> wrapper:

  class_<std::vector<double> >("std_vector_double")
    .def(...)
    ...
  ;

  This can be moved to a template so that several types (double, int,
  long, etc.) can be wrapped with the same code. This technique
  is used in the file

    scitbx/include/scitbx/array_family/boost_python/flex_wrapper.h

  in the "scitbx" package. The file could easily be modified for
  wrapping std::vector<> instantiations.

  This type of C++/Python binding is most suitable for containers
  that may contain a large number of elements (>10000).

2. Using custom rvalue converters.

  Boost.Python "rvalue converters" match function signatures
  such as:

    void foo(std::vector<double> const& array); // pass by const-reference
    void foo(std::vector<double> array); // pass by value

  Some custom rvalue converters are implemented in the file

    scitbx/include/scitbx/boost_python/container_conversions.h

  This code can be used to convert from C++ container types
  such as std::vector<> or std::list<> to Python tuples and
  vice versa. A few simple examples can be found in the file

    scitbx/array_family/boost_python/regression_test_module.cpp

  Automatic C++ container <-> Python tuple conversions are most
  suitable for containers of moderate size.
  These converters generate significantly less object code
  compared to alternative 1 above.

A disadvantage of using alternative 2 is that operators such as
arithmetic +,-,*,/,% are not available. It would be useful to have
custom rvalue converters that convert to a "math_array" type instead of
tuples. This is currently not implemented but is possible within
the framework of Boost.Python V2 as it will be released in the next
couple of weeks.

It would also be useful to also have "custom lvalue converters"
such as std::vector<> <-> Python list. These converters would
support the modification of the Python list from C++. For example:

  C++:

  void foo(std::vector<double>& array)
  {
    for(std::size_t i=0;i<array.size();i++) {
      array[i] *= 2;
    }
  }

  Python:

  >>> l = [1, 2, 3]
  >>> foo(l)
  >>> print l
  [2, 4, 6]

Custom lvalue converters require changes to the Boost.Python core
library and are currently not available.

P.S.:

The "scitbx" files referenced above are available via anonymous CVS:

cvs -d:pserver:anonymous at cvs.cctbx.sourceforge.net:/cvsroot/cctbx login
cvs -d:pserver:anonymous at cvs.cctbx.sourceforge.net:/cvsroot/cctbx co scitbx


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com



From dave at boost-consulting.com  Thu Oct  3 20:16:49 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 3 Oct 2002 14:16:49 -0400
Subject: [C++-sig] std::vector
References: <20021003183540.56741.qmail@web20209.mail.yahoo.com>
Message-ID: <0a2001c26b09$6ab74ab0$6701a8c0@boostconsulting.com>

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
> Attached is the little summary that I promised earlier. Feedback is most
> welcome.

Ralf,

I just added this to the v2 FAQ. If you get inspired to expand it based on
feedback, please do so in the CVS.

Thanks,
Dave


-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com





From leo at hiper.com.br  Thu Oct  3 23:38:30 2002
From: leo at hiper.com.br (Leonardo Rochael Almeida)
Date: 03 Oct 2002 18:38:30 -0300
Subject: [C++-sig] byte containers
Message-ID: <1033681111.9116.2.camel@spitfire>

I'm officially working with the TerraLib mantainers
(http://www.terralib.org/) to make Python bindings for it (Dave, you can
count this one as another boost.python project :-). 

Part of the functionality of that library concerns map tiling: large
geo-referenced images are sliced and the tiles are stored in a Database.
Later on, you can ask the library to return the map of an area and it
will reassemble the image and return it. What is the best way to pass a
lump of bytes (with nulls in it) back and forth? Something that I could
get as a Python String would be nice, but std::string doesn't seem null
friendly... Ultimately I'll probably be feeding this lump of bytes to
PIL (Python Imaging Library) to make some final tweaks to the image
before publishing it on the Web (it's actually a Zope project).

Any tips?



-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.




From dave at boost-consulting.com  Thu Oct  3 23:39:07 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 3 Oct 2002 17:39:07 -0400
Subject: [C++-sig] byte containers
References: <1033681111.9116.2.camel@spitfire>
Message-ID: <0af401c26b25$a83f2df0$6701a8c0@boostconsulting.com>

From: "Leonardo Rochael Almeida" <leo at hiper.com.br>


>
> I'm officially working with the TerraLib mantainers
> (http://www.terralib.org/) to make Python bindings for it (Dave, you can
> count this one as another boost.python project :-).
>
> Part of the functionality of that library concerns map tiling: large
> geo-referenced images are sliced and the tiles are stored in a Database.
> Later on, you can ask the library to return the map of an area and it
> will reassemble the image and return it. What is the best way to pass a
> lump of bytes (with nulls in it) back and forth? Something that I could
> get as a Python String would be nice, but std::string doesn't seem null
> friendly... Ultimately I'll probably be feeding this lump of bytes to
> PIL (Python Imaging Library) to make some final tweaks to the image
> before publishing it on the Web (it's actually a Zope project).
>
> Any tips?


How about just using boost::python::str, i.e. a Python string object?
You can always extract<char*>(...) from it. If you think that's too
semantically loose on the Python side, you could wrap a C++ class which
contains a str.

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com





From rwgk at yahoo.com  Fri Oct  4 00:24:52 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 3 Oct 2002 15:24:52 -0700 (PDT)
Subject: [C++-sig] byte containers
In-Reply-To: <1033681111.9116.2.camel@spitfire>
Message-ID: <20021003222452.38985.qmail@web20201.mail.yahoo.com>

--- Leonardo Rochael Almeida <leo at hiper.com.br> wrote:
> 
> I'm officially working with the TerraLib mantainers
> (http://www.terralib.org/) to make Python bindings for it (Dave, you can
> count this one as another boost.python project :-). 
> 
> Part of the functionality of that library concerns map tiling: large
> geo-referenced images are sliced and the tiles are stored in a Database.
> Later on, you can ask the library to return the map of an area and it
> will reassemble the image and return it. What is the best way to pass a
> lump of bytes (with nulls in it) back and forth? Something that I could
> get as a Python String would be nice, but std::string doesn't seem null
> friendly... Ultimately I'll probably be feeding this lump of bytes to
> PIL (Python Imaging Library) to make some final tweaks to the image
> before publishing it on the Web (it's actually a Zope project).
> 
> Any tips?

For prototyping you could use the "flex" type of the scitbx array family to
make pickleable 2-D arryas of "char" or "signed char" or "unsigned char",
whatever is most appropriate. If using the scitbx is to heavy-weight as a final
solution you can later rip out what you need.

To make the flex.char type:

cd scitbx/array_family/boost_python
cp flex_bool.cpp flex_char.cpp

Replace "bool" by "char". Add this near the top of flex_char.cpp (untested):

namespace scitbx { namespace boost_python { namespace pickle_single_buffered {

  inline
  char* to_string(char* start, char const& value)
  {
    *start = value;
    return start + 1;
  }

  template <>
  struct from_string<char>
  {
    from_string(const char* start) : end(start)
    {
      value = *end++;
    }

    char value;
    const char* end;
  };

}}}

Add "flex_char.cpp" to the SConscript and recompile with

libtbx_scons .

as shown in

http://cci.lbl.gov/~rwgk/scitbx/cold_start_redhat_73_csh

You might have to modify the cvs checkout of boost to use the RC_1_29_0 branch
if the trunk turns out to be broken.

HTH,
        Ralf


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com



From dave at boost-consulting.com  Thu Oct  3 23:56:51 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 3 Oct 2002 17:56:51 -0400
Subject: [C++-sig] byte containers
References: <20021003222452.38985.qmail@web20201.mail.yahoo.com>
Message-ID: <0b1401c26b28$771b0ac0$6701a8c0@boostconsulting.com>

From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>

> For prototyping you could use the "flex" type of the scitbx array family
to
> make pickleable 2-D arryas of "char" or "signed char" or "unsigned char",
> whatever is most appropriate. If using the scitbx is to heavy-weight as a
final
> solution you can later rip out what you need.

Ralf's idea is certainly better if you need in-place modification of your
buffer's contents. Might be a better approach even if you don't.


-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com






From rwgk at yahoo.com  Fri Oct  4 01:34:13 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 3 Oct 2002 16:34:13 -0700 (PDT)
Subject: [C++-sig] Boost.Python v2: A few small changes
In-Reply-To: <029201c2694b$d07075d0$6701a8c0@boostconsulting.com>
Message-ID: <20021003233413.76097.qmail@web20210.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> 1. The BOOST_PYTHON_[MEMBER_]FUNCTION_OVERLOADS macros used to expose
> functions with default arguments will not be available by simply #including
> <boost/python/class.hpp> or <boost/python/def.hpp>. Instead they will be
> moved to <boost/python/overloads.hpp>

Even though I am working with the latest RC_1_29_0 branch I do not have to
include overloads.hpp to use the OVERLOADS macros. Could this be due to an
oversight? -- Here is the preprocessor output of one of my files:

http://cci.lbl.gov/~rwgk/tmp/regression_test_module_cpp_gcc_preprocessed

> 2. The module class is officially disappearing, for real. I'm going to keep
> module.hpp, but only so I can do:
> 
>     #include <boost/python/module_init.hpp>
>     #define BOOST_PYTHON_MODULE BOOST_PYTHON_MODULE_INIT
> 
> BOOST_PYTHON_MODULE_INIT will continue to be available but deprecated for
> Boost 1.29.0, but the "official" macro will be BOOST_PYTHON_MODULE.

So which file do I have to include in the future? Like this?

#include <boost/python/module.hpp>

BOOST_PYTHON_MODULE(my_extension)
{
  ...
}

Will module_init.hpp eventually go away?

Thanks,
        Ralf


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com



From dave at boost-consulting.com  Fri Oct  4 01:00:26 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 3 Oct 2002 19:00:26 -0400
Subject: [C++-sig] Boost.Python v2: A few small changes
References: <20021003233413.76097.qmail@web20210.mail.yahoo.com>
Message-ID: <0bb901c26b30$e8dfab90$6701a8c0@boostconsulting.com>

From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>


> --- David Abrahams <dave at boost-consulting.com> wrote:
> > 1. The BOOST_PYTHON_[MEMBER_]FUNCTION_OVERLOADS macros used to expose
> > functions with default arguments will not be available by simply
#including
> > <boost/python/class.hpp> or <boost/python/def.hpp>. Instead they will
be
> > moved to <boost/python/overloads.hpp>
>
> Even though I am working with the latest RC_1_29_0 branch I do not have
to
> include overloads.hpp to use the OVERLOADS macros. Could this be due to
an
> oversight?

No, it's due to the fact that I've been making a few changes on the trunk
which haven't been moved to the release candidate branch yet.
>
> > 2. The module class is officially disappearing, for real. I'm going to
keep
> > module.hpp, but only so I can do:
> >
> >     #include <boost/python/module_init.hpp>
> >     #define BOOST_PYTHON_MODULE BOOST_PYTHON_MODULE_INIT
> >
> > BOOST_PYTHON_MODULE_INIT will continue to be available but deprecated
for
> > Boost 1.29.0, but the "official" macro will be BOOST_PYTHON_MODULE.
>
> So which file do I have to include in the future? Like this?
>
> #include <boost/python/module.hpp>
>
> BOOST_PYTHON_MODULE(my_extension)
> {
>   ...
> }

Good. See any of libs/python/test/*.cpp on the main trunk for examples.

> Will module_init.hpp eventually go away?

In the distant future, yes.


-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com





From rwgk at yahoo.com  Fri Oct  4 02:10:42 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 3 Oct 2002 17:10:42 -0700 (PDT)
Subject: [C++-sig] Trunk OK?
In-Reply-To: <094d01c26ae9$1afba9a0$6701a8c0@boostconsulting.com>
Message-ID: <20021004001042.23127.qmail@web20206.mail.yahoo.com>

The Tru64 cxx compiler still has a problem:

http://cci.lbl.gov/boost/results/1033686001/dailylog_tru64_cxx_test

--- David Abrahams <dave at boost-consulting.com> wrote:
> According to my tests, things on the CVS main trunk are working again for
> Boost.Python v2.


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com



From ssmith at magnet.fsu.edu  Fri Oct  4 16:44:53 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Fri, 04 Oct 2002 10:44:53 -0400
Subject: [C++-sig] std::vector
In-Reply-To: <20021003183540.56741.qmail@web20209.mail.yahoo.com>
Message-ID: <PCEJJPDHEECNEKDDLPNLAEEKCAAA.ssmith@magnet.fsu.edu>

Hi Ralf,

I just made my intial attempts to look at the std::vector stuff you sent.
Unfortunately, I am stuck at the beginning, checking out a specific
(or any) branch. I am not too good at CVS apparently.

> I have verified that the RC_1_29_0 branch of boost is working properly.

I would be glad to try and get/build both 1.29.0 and 2.0. After looking
over the last 4 months of these messages, at Source Forge, and at Yahoo I
still
don't know the simple means to do this. I know enough to do the following:

cvs -d:pserver:anonymous at cvs.boost.sourceforge.net:/cvsroot/boost login
cvs -z3 -d:pserver:anonymous at cvs.boost.sourceforge.net:/cvsroot/boost
checkout boost
... a couple more commands
cvs -d:pserver:anonymous at cvs.boost.sourceforge.net:/cvsroot/boost logout

At least I was able to obtain scitbx!

But what are the commands to get only RC_1_29_0 or 2.0 or develop?
Do you (locally) keep these in different directories?
What does RC stand for?
Is is better or just as easy to just copy things from a browser from Source
Forge?

I'll give vectors & lists a go today if I can get a version of Boost.Python
that
can handle the stuff you wrote about earlier.

Thanks,
Scott





From rwgk at yahoo.com  Fri Oct  4 17:54:43 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 4 Oct 2002 08:54:43 -0700 (PDT)
Subject: [C++-sig] std::vector
In-Reply-To: <PCEJJPDHEECNEKDDLPNLAEEKCAAA.ssmith@magnet.fsu.edu>
Message-ID: <20021004155443.3741.qmail@web20210.mail.yahoo.com>

--- "Scott A. Smith" <ssmith at magnet.fsu.edu> wrote:
> I would be glad to try and get/build both 1.29.0 and 2.0. After looking
> over the last 4 months of these messages, at Source Forge, and at Yahoo I
> still
> don't know the simple means to do this.
> But what are the commands to get only RC_1_29_0 or 2.0 or develop?
> What does RC stand for?

RC_1_29_0 stands for "Release Candidate for 1.29.0" .
Boost.Python Version 2 is part of boost 1.29.0 . Our use of "V2" does not
correspond to a package V2, it is just a subset of the upcoming boost 1.29.0
release.

> Do you (locally) keep these in different directories?

I have indeed one "CVS working copy" of the CVS trunk, and another copy of the
RC_1_29_0 branch. For people who do not wish to endure the pains of being at
the forefront of the development, right now working with the RC_1_29_0 branch
might be the best approach.

> Is is better or just as easy to just copy things from a browser from Source
> Forge?

I don't think so. Can you check out entire directory hierarchies through the
browser?
To check out the release candidate branch:

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

> I'll give vectors & lists a go today if I can get a version of Boost.Python
> that can handle the stuff you wrote about earlier.

Right now both the main trunk and the RC branch appear to be in perfect shape
for Boost.Python compilation. But I'd recommend using the branch, and then the
next release as soon as it becomes available.

Ralf


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com



From dave at boost-consulting.com  Fri Oct  4 23:45:44 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 4 Oct 2002 17:45:44 -0400
Subject: [C++-sig] Boost.Python v2: MinGW-2.0 support
Message-ID: <044f01c26bef$dd6fe990$6701a8c0@boostconsulting.com>

I have just checked in the changes to the main trunk neccessary to support
MinGW-2.0.
All tests are passing.

Enjoy,
Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com






From robertoschler at hotmail.com  Sat Oct  5 00:52:55 2002
From: robertoschler at hotmail.com (Robert Oschler)
Date: Fri, 4 Oct 2002 18:52:55 -0400
Subject: [C++-sig] Latest ETA for formal Boost Python 2 release?
Message-ID: <OE35vbKmuyz9qcrO3lo0000c5ea@hotmail.com>

Just checking in. What's the latest ETA for formal Boost Python 2 release?

thx

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20021004/d768fcc3/attachment.htm>

From dave at boost-consulting.com  Sat Oct  5 00:58:34 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 4 Oct 2002 18:58:34 -0400
Subject: [C++-sig] Latest ETA for formal Boost Python 2 release?
References: <OE35vbKmuyz9qcrO3lo0000c5ea@hotmail.com>
Message-ID: <001001c26bfa$25be9c00$6701a8c0@boostconsulting.com>

From: "Robert Oschler" <robertoschler at hotmail.com>


> Just checking in. What's the latest ETA for formal Boost Python 2
release?

It's going out with Boost 1.29.0, expected early next week.

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com





From paustin at eos.ubc.ca  Sat Oct  5 03:24:13 2002
From: paustin at eos.ubc.ca (Philip Austin)
Date: Fri, 4 Oct 2002 18:24:13 -0700
Subject: [C++-sig] numeric.hpp: copying raw data
In-Reply-To: <001001c26bfa$25be9c00$6701a8c0@boostconsulting.com>
References: <OE35vbKmuyz9qcrO3lo0000c5ea@hotmail.com>
	<001001c26bfa$25be9c00$6701a8c0@boostconsulting.com>
Message-ID: <15774.16189.157867.214799@gull.eos.ubc.ca>

Hi, we've been playing around with numeric.hpp and it's working well.
I'm uncertain, however, about the best way to move data from C to
python using numeric::array -- it looks like users with large arrays coming
from C need to bite the bullet and call import_libnumarray()?  I
wanted to check to make sure we aren't missing something before we
start implementing our own functions, like:

numeric::array ptrToNum(int* data, int n=0){
  NDInfo info;
  object obj(detail::new_reference(NA_Empty(1, &n, tInt32)));
  get_info(&obj, &info);
  memcpy(info.data, data, 4*n);
  return numeric::array(obj, "Int", n, false);
}

Regards, Phil Austin




From dave at boost-consulting.com  Sat Oct  5 06:11:09 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 5 Oct 2002 00:11:09 -0400
Subject: [C++-sig] numeric.hpp: copying raw data
References: <OE35vbKmuyz9qcrO3lo0000c5ea@hotmail.com><001001c26bfa$25be9c00$6701a8c0@boostconsulting.com> <15774.16189.157867.214799@gull.eos.ubc.ca>
Message-ID: <00ed01c26c25$a4f25590$6701a8c0@boostconsulting.com>

----- Original Message -----
From: "Philip Austin" <paustin at eos.ubc.ca>


>
> Hi, we've been playing around with numeric.hpp and it's working well.
> I'm uncertain, however, about the best way to move data from C to
> python using numeric::array -- it looks like users with large arrays
coming
> from C need to bite the bullet and call import_libnumarray()?  I
> wanted to check to make sure we aren't missing something before we
> start implementing our own functions, like:
>
> numeric::array ptrToNum(int* data, int n=0){
>   NDInfo info;
>   object obj(detail::new_reference(NA_Empty(1, &n, tInt32)));
>   get_info(&obj, &info);
>   memcpy(info.data, data, 4*n);
>   return numeric::array(obj, "Int", n, false);
> }
>
> Regards, Phil Austin

The truth about the numeric support is this:

I discussed what to do with Paul Dubois, and he said, roughly, "what we
want is something that can be used as an argument to a wrapped function,
and which will match anything that you can construct a numarray with". I
countered with, "what about something that only matches numarrays -- you
can always use python::object if you want to match anything, and then you
can construct the numarray with that? It would be more consistent with the
other type wrappers". He said "great!" and we had a deal. We never
discussed the things we'd need to do to actually make it useful ;-)

Anyway, about the above code: is there a way to do the equivalent of

    NA_Empty(1, &n, tInt32)

from Python?

If so, you should be able to construct a numeric::array that way, right?
In that case, if you needed to touch the underlying data you could always
use its ptr() function instead of relying on implementation detail::s.

Lastly, though I could be wrong since I'm no Numeric expert, is there any
point to constructing numeric::array in the last line? I mean, don't you
already have one? It seems you could just return obj.

-Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From ssmith at magnet.fsu.edu  Sat Oct  5 15:04:57 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Sat, 05 Oct 2002 09:04:57 -0400
Subject: [C++-sig] std::vector
In-Reply-To: <20021004155443.3741.qmail@web20210.mail.yahoo.com>
Message-ID: <PCEJJPDHEECNEKDDLPNLEEELCAAA.ssmith@magnet.fsu.edu>

Hi Ralf,

> (RK) Boost.Python Version 2 is part of boost 1.29.0 . Our use of "V2" does
not
> correspond to a package V2, it is just a subset of the upcoming boost
1.29.0
> release.

> (RK) You have to start bjam in libs/python/test to get the V2 build.

> (DA) Well, you can do it in libs/python if all you want is the library and
none
> of the tests.

Right, David had already told me about the versioning but I forgot. I
downloaded the
RC_1_29_0 branch and it compiled fine from libs/python to produce a bpl.dll.
I think David also told me that name alone (vs. boost_python.dll) indicates
V2?
I assume compiling from libs/python/test would do the same (but also compile
the
test sources therein).

I guess it will be a while before I get to try out std::vector because none
of my
currently used BP headers are working with V2 (e.g.
boost/python/reference.hpp,
boost/python/class_builder.hpp). Since they seem to be completely gone & I
cannot
find any documentation about which are used when, I guess that leaves going
through
the codes in libs/python/test to determine how things work? Probably a good
idea
in general anyway. Not that I am complaining, I know this is in flux. But is
that
what I should be doing or is there some other means available for finding
such
things out, akin to the examples stemming off of the current Boost.Python
WWW page
perhaps? After a glance through some files in /test it looks as things are
now
radically different & I have a lot of work ahead of me just to switch to
V2......

Thanks,
Scott






From paustin at eos.ubc.ca  Sat Oct  5 17:30:25 2002
From: paustin at eos.ubc.ca (Philip Austin)
Date: Sat, 5 Oct 2002 08:30:25 -0700
Subject: [C++-sig] numeric.hpp: copying raw data
In-Reply-To: <00ed01c26c25$a4f25590$6701a8c0@boostconsulting.com>
References: <OE35vbKmuyz9qcrO3lo0000c5ea@hotmail.com>
	<001001c26bfa$25be9c00$6701a8c0@boostconsulting.com>
	<15774.16189.157867.214799@gull.eos.ubc.ca>
	<00ed01c26c25$a4f25590$6701a8c0@boostconsulting.com>
Message-ID: <15775.1425.753525.842108@gull.eos.ubc.ca>

(Paul, I've cc'd you in case you aren't following the c++-sig.
Briefly, Dave has implemented a boost wrapper for both Numeric and
numarray that avoids the need to load the C api, using
PyObject_CallObject.  Since Numeric allows a cast to 
PyArrayObject*, this provides access to the data pointer
and to all of Numeric except PyArray_FromDimsAndData.  I
can't figure out how to make this work for numarray,
because the only way to get at the void* data pointer is
through the get_info function call.  Am I missing something?)

Dave, a couple of points extracted from below:

 > Anyway, about the above code: is there a way to do the equivalent of
 > 
 >     NA_Empty(1, &n, tInt32)
 > 
 > from Python?

There are two calls (zeros() and ones()) that are missing from your
interface that would make this work for Numeric (but not from
numarray, unless I'm missing something).  They will be slower than
NA_empty, since they initialize the arrays, but I don't think many
users will notice.  As I mention above, this still excludes the
constructors that use existing C data without a copy:
PyArray_FromDimsAndData in Numeric, and NA_New in numarray.  
These calls are especially useful for embedding, when there's
a Fortran main program that's allocating the memory.


 > Lastly, though I could be wrong since I'm no Numeric expert, is there any
 > point to constructing numeric::array in the last line? I mean, don't you
 > already have one? It seems you could just return obj.

We use some of the member functions (resizing, etc.) later in the
program, so it seemed clearer to keep it a numarray.

Regards, Phil

David Abrahams writes:
 > 
 > ----- Original Message -----
 > From: "Philip Austin" <paustin at eos.ubc.ca>
 > 
 > 
 > >
 > > Hi, we've been playing around with numeric.hpp and it's working well.
 > > I'm uncertain, however, about the best way to move data from C to
 > > python using numeric::array -- it looks like users with large arrays
 > coming
 > > from C need to bite the bullet and call import_libnumarray()?  I
 > > wanted to check to make sure we aren't missing something before we
 > > start implementing our own functions, like:
 > >
 > > numeric::array ptrToNum(int* data, int n=0){
 > >   NDInfo info;
 > >   object obj(detail::new_reference(NA_Empty(1, &n, tInt32)));
 > >   get_info(&obj, &info);
 > >   memcpy(info.data, data, 4*n);
 > >   return numeric::array(obj, "Int", n, false);
 > > }
 > >
 > > Regards, Phil Austin
 > 
 > The truth about the numeric support is this:
 > 
 > I discussed what to do with Paul Dubois, and he said, roughly, "what we
 > want is something that can be used as an argument to a wrapped function,
 > and which will match anything that you can construct a numarray with". I
 > countered with, "what about something that only matches numarrays -- you
 > can always use python::object if you want to match anything, and then you
 > can construct the numarray with that? It would be more consistent with the
 > other type wrappers". He said "great!" and we had a deal. We never
 > discussed the things we'd need to do to actually make it useful ;-)
 > 
 > Anyway, about the above code: is there a way to do the equivalent of
 > 
 >     NA_Empty(1, &n, tInt32)
 > 
 > from Python?
 > 
 > If so, you should be able to construct a numeric::array that way, right?
 > In that case, if you needed to touch the underlying data you could always
 > use its ptr() function instead of relying on implementation detail::s.
 > 
 > Lastly, though I could be wrong since I'm no Numeric expert, is there any
 > point to constructing numeric::array in the last line? I mean, don't you
 > already have one? It seems you could just return obj.
 > 
 > -Dave
 > 
 > -----------------------------------------------------------
 >            David Abrahams * Boost Consulting
 > dave at boost-consulting.com * http://www.boost-consulting.com
 > 
 > 
 > _______________________________________________
 > C++-sig mailing list
 > C++-sig at python.org
 > http://mail.python.org/mailman/listinfo/c++-sig




From dave at boost-consulting.com  Sat Oct  5 19:11:56 2002
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 5 Oct 2002 13:11:56 -0400
Subject: [C++-sig] std::vector
References: <PCEJJPDHEECNEKDDLPNLEEELCAAA.ssmith@magnet.fsu.edu>
Message-ID: <01d501c26c92$90e3d2f0$6701a8c0@boostconsulting.com>

From: "Scott A. Smith" <ssmith at magnet.fsu.edu>

> Right, David had already told me about the versioning but I forgot. I
> downloaded the
> RC_1_29_0 branch and it compiled fine from libs/python to produce a
bpl.dll.
> I think David also told me that name alone (vs. boost_python.dll)
indicates
> V2?
> I assume compiling from libs/python/test would do the same (but also
compile
> the
> test sources therein).


It's now impossible to be confused about which version you're using because
v1 is no longer in the CVS repository, neither on the main trunk nor on the
RC_1_29_0 branch.

> I guess it will be a while before I get to try out std::vector because
none
> of my
> currently used BP headers are working with V2 (e.g.
> boost/python/reference.hpp,
> boost/python/class_builder.hpp). Since they seem to be completely gone

Those were v1 interfaces, which are now dead.

> & I
> cannot
> find any documentation about which are used when,

There is fairly complete and up-to-date reference documentation in
libs/python/doc/v2/reference.html

(also
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/
python/doc/v2/index.html?rev=HEAD&content-type=text/html)

> I guess that leaves going
> through
> the codes in libs/python/test to determine how things work? Probably a
good
> idea
> in general anyway.

Probably.

> Not that I am complaining, I know this is in flux. But is
> that
> what I should be doing

Reading the docs and looking at the examples it contains, as well as the
tests in libs/python/test/*.cpp, is a good approach.

> or is there some other means available for finding
> such
> things out, akin to the examples stemming off of the current Boost.Python
> WWW page
> perhaps?

There are also v2 examples in libs/python/example now.

> After a glance through some files in /test it looks as things are
> now
> radically different & I have a lot of work ahead of me just to switch to
> V2......

Yes, things are radically different. The new library is a complete rewrite
with a new interface. You should find it much easier to use, but it is
going to require some adjustments.

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com





From rwgk at yahoo.com  Mon Oct  7 05:11:38 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 6 Oct 2002 20:11:38 -0700 (PDT)
Subject: [C++-sig] deepcopy
Message-ID: <20021007031138.2669.qmail@web20206.mail.yahoo.com>

Sometimes I need to make a copy of a wrapped C++ object in Python. Python's
copy.deepcopy() will only work for objects that are pickleable. I am wondering
if it wouldn't be easy to make the C++ copy constructor available by default in
Python, for example through the member functon .copy(). That would be much more
convenient than .def'ing copy for everything explicitly. Similar to "no_init"
there could be a "no_copy" to suppress the automatic generation of .copy().
Ralf


__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com



From dave at boost-consulting.com  Mon Oct  7 05:58:35 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 06 Oct 2002 23:58:35 -0400
Subject: [C++-sig] deepcopy
In-Reply-To: <20021007031138.2669.qmail@web20206.mail.yahoo.com>
References: <20021007031138.2669.qmail@web20206.mail.yahoo.com>
Message-ID: <uelb2hpck.fsf@boost-consulting.com>

"Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:

> Sometimes I need to make a copy of a wrapped C++ object in Python. Python's
> copy.deepcopy() will only work for objects that are pickleable. I am wondering
> if it wouldn't be easy to make the C++ copy constructor available by default in
> Python, for example through the member functon .copy(). That would be much more
> convenient than .def'ing copy for everything explicitly. Similar to "no_init"
> there could be a "no_copy" to suppress the automatic generation of .copy().

We already have boost::noncopyable for that purpose.

I'm not sure we should generate .copy() automatically, but maybe we
should have a def_copy() method.

Food for thought.

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From Mark.Charsley at radioscape.com  Mon Oct  7 16:28:10 2002
From: Mark.Charsley at radioscape.com (Charsley, Mark)
Date: Mon, 7 Oct 2002 15:28:10 +0100 
Subject: [C++-sig] Leaked reference when putting an extension object in a tuple
Message-ID: <3190BC9FA8F6D3119508009027E5B33EBA5340@MORSE>

I appear to be leaking a reference in my C++ extension. The general gist of
what I'm trying to achieve is to create a C++ python extension that
a) defines a new class (MyClass)
b) provides a way for python to register callback functions

When a callback becomes necessary, my extension creates a MyClass object,
puts it in a tuple and then calls PyEval_CallObject with the callback
function and the tuple. Unfortunately it seems to leak references when I put
my object in a tuple. The source for a very cut down version of the
extension is given below. Running it in a debug build of python gives the
following...

ActivePython 2.2.1 Build 222 (ActiveState Corp.) based on
Python 2.2.1 (#34, Apr 10 2002, 11:35:50) [MSC 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import PyObjectPasser
[8031 refs]
>>> PyObjectPasser.RequestCallback()
[8034 refs]
>>> PyObjectPasser.RequestCallback()
[8035 refs]
>>> PyObjectPasser.RequestCallback()
[8036 refs]
>>> PyObjectPasser.RequestCallback()
[8037 refs]
>>>

Putting an integer into the tuple instead of a MyClass object gives a
constant count of 8033 refs. So is there something wrong with
a) my code
b) python's reference counting
c) the boot.python library

In the probable case of a), what am I doing wrong?

Many thanks in advance

Mark

code follows...

8<-------------------------------------------------------------------

#include <boost/python/class_builder.hpp>
#include <boost/python/objects.hpp>

struct MyClass
{
    MyClass()
    {
        m_priority = 0;
    }

    MyClass(int priority)
    {
        m_priority;
    }

    int m_priority;
};

void RequestCallback();

namespace {
    BOOST_PYTHON_MODULE_INIT(PyObjectPasser)
    {
        boost::python::module_builder this_module("PyObjectPasser");

        boost::python::class_builder<MyClass> MyClassBuilder(this_module,
"MessageInfo");
        MyClassBuilder.def(boost::python::constructor<>());
        MyClassBuilder.def(boost::python::constructor<int>());
        MyClassBuilder.def_readonly(&MyClass::m_priority, "priority");

        this_module.def(RequestCallback,"RequestCallback");
    
    }
}

void RequestCallback()
{
    // create an object of our class
    MyClass obj(1);

    // we call a python function in the real code, so build up a tuple
    // of arguments
    boost::python::tuple args(1);
    
    // put our object in the tuple
    args.set_item(0,obj);

    // would now call the callback here

}



8<-------------------------------------------------------------------




**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
postmaster at radioscape.com.

This footnote also confirms that this email message has been scanned
for the presence of computer viruses known at the time of sending.

www.radioscape.com
**********************************************************************




From stefan.seefeld at orthosoft.ca  Mon Oct  7 17:01:07 2002
From: stefan.seefeld at orthosoft.ca (Stefan Seefeld)
Date: Mon, 07 Oct 2002 11:01:07 -0400
Subject: [C++-sig] compiling boost.python v2 on IRIX
Message-ID: <d2cd3967080c6f0508c3aca5e8685eba3da1a2c7@>

hi there,

I just tried to compile boost.python v2 on irix using the 'mipspro'
toolset. The compilation failed on the file 'pickle_support.o' with
the error(s)

cc-3354 CC: ERROR File = 
/homes/Developer/sseefel/boost/boost/mpl/aux_/preprocessed/plain/arg.hpp, 
Line = 18
   A non-integral operation is not allowed in a nontype template argument.

           BOOST_STATIC_ASSERT(!is_void_<type>::value);
           ^

cc-1070 CC: ERROR File = 
/homes/Developer/sseefel/boost/boost/mpl/aux_/preprocessed/plain/arg.hpp, 
Line = 18
   The indicated type is incomplete.

           BOOST_STATIC_ASSERT(!is_void_<type>::value);


Beside that, I find the build system not very transparent, so tracking
things down is non-obvious. The use of jam isn't particularly helpful.
For example I just realized from the error logs that it is using the
"-mips3" compiler flag, while I'd like "-mips4". I couldn't find either
docs nor code that made clear how to change that flag.

Any help would be highly appreciated !

Regards,
		Stefan




From grafik666 at redshift-software.com  Mon Oct  7 17:31:36 2002
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Mon,  7 Oct 2002 10:31:36 -0500
Subject: [C++-sig] compiling boost.python v2 on IRIX
In-Reply-To: <d2cd3967080c6f0508c3aca5e8685eba3da1a2c7@>
Message-ID: <20021007103137-r01010800-e13c777b-0860-0108@12.100.89.43>

[2002-10-07] Stefan Seefeld wrote:
>hi there,
>
>Beside that, I find the build system not very transparent, so tracking
>things down is non-obvious. The use of jam isn't particularly helpful.
>For example I just realized from the error logs that it is using the
>"-mips3" compiler flag, while I'd like "-mips4". I couldn't find either
>docs nor code that made clear how to change that flag.
>
>Any help would be highly appreciated !

bjam ... "-sBUILD=<architecture>mips4"

If you look at the *-tools.jam files the build system looks fairly
transparent. All the commands and mapping for flags are right there. But if
you look at other *.jam files it certainly is not transparent, and it wasn't
meant to be.


-- grafik - Don't Assume Anything
-- rrivera at acm.org - grafik at redshift-software.com
-- 102708583 at icq - Grafik666 at AIM - Grafik at jabber.org



From seefeld at sympatico.ca  Mon Oct  7 17:40:48 2002
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Mon, 07 Oct 2002 11:40:48 -0400
Subject: [C++-sig] compiling boost.python v2 on IRIX
References: <20021007103137-r01010800-e13c777b-0860-0108@12.100.89.43>
Message-ID: <edaf4476cbb31c075cbdaf44929b77663da1ac15@>

Rene Rivera wrote:

> bjam ... "-sBUILD=<architecture>mips4"

thanks !


> If you look at the *-tools.jam files the build system looks fairly
> transparent.

you are assuming that people know jam syntax, aren't you ?

> All the commands and mapping for flags are right there. But if
> you look at other *.jam files it certainly is not transparent, and it wasn't
> meant to be.

Well, with transparency I meant (among others) that it should be
easy to see that the current build uses '-mips3'. Beside, most people
are trained with 'make', so every deviation should be well documented
somewhere (jam files vs. Makefiles). But may be I just didn't look hard
enough...

In my own ('make' based) build systems I make sure all commands
are dumped to stdout (as is the default anyways) when I invoke 'make',
and something like in your build system, i.e. messages of the form
'compiling foobar.cc' if I invoke 'make -s', where I explicitely ask
the build to be less verbose.


Best regards,
		Stefan




From grafik666 at redshift-software.com  Mon Oct  7 17:53:23 2002
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Mon,  7 Oct 2002 10:53:23 -0500
Subject: [C++-sig] compiling boost.python v2 on IRIX
In-Reply-To: <edaf4476cbb31c075cbdaf44929b77663da1ac15@>
Message-ID: <20021007105324-r01010800-6e79e9da-0860-0108@12.100.89.43>

[2002-10-07] Stefan Seefeld wrote:

>Rene Rivera wrote:
>
>> bjam ... "-sBUILD=<architecture>mips4"
>
>thanks !
>
>
>> If you look at the *-tools.jam files the build system looks fairly
>> transparent.
>
>you are assuming that people know jam syntax, aren't you ?

No. Just that they know how to use the compiler they are intrested in.
Because most things in Boost.Build are fairly wordy it's fairly easy to see
which flags are used depending on the circumstances. Like the -mips4 vs.
-mips3 flags. In the toolset file you have:

    flags mipspro CFLAGS <architecture>mips3 : -mips3 ;
    flags mipspro CFLAGS <architecture>mips4 : -mips4 ;

That seems very clear where the flags come from. Now yes I must say that
knowing that to specify that you use the "-sBUILD=..." is another problem,
which requires reading way more build system docs. We know the doc problem,
I pointed it the first time I got involved with the build system. But we
don't have the time to be complete :-(

>> All the commands and mapping for flags are right there. But if
>> you look at other *.jam files it certainly is not transparent, and it
wasn't
>> meant to be.
>
>Well, with transparency I meant (among others) that it should be
>easy to see that the current build uses '-mips3'. Beside, most people
>are trained with 'make', so every deviation should be well documented
>somewhere (jam files vs. Makefiles). But may be I just didn't look hard
>enough...

    flags mipspro CFLAGS <architecture>native : -mips3 ;

>In my own ('make' based) build systems I make sure all commands
>are dumped to stdout (as is the default anyways) when I invoke 'make',
>and something like in your build system, i.e. messages of the form
>'compiling foobar.cc' if I invoke 'make -s', where I explicitely ask
>the build to be less verbose.

Jam and Boost.Build take the opposite approach. The reason is simple...
after you know how to use the system you don't care about what commands it
executes anymore. So we default to less verbosity at the outset. If you want
to see the commands it's going to execute try the "-n" flag.


-- grafik - Don't Assume Anything
-- rrivera at acm.org - grafik at redshift-software.com
-- 102708583 at icq - Grafik666 at AIM - Grafik at jabber.org



From dave at boost-consulting.com  Mon Oct  7 17:49:05 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 07 Oct 2002 11:49:05 -0400
Subject: [C++-sig] compiling boost.python v2 on IRIX
In-Reply-To: <d2cd3967080c6f0508c3aca5e8685eba3da1a2c7@>
References: <d2cd3967080c6f0508c3aca5e8685eba3da1a2c7@>
Message-ID: <u4rby6yha.fsf@boost-consulting.com>

Stefan Seefeld <stefan.seefeld at orthosoft.ca> writes:

> hi there,
> 
> I just tried to compile boost.python v2 on irix using the 'mipspro'
> toolset. The compilation failed on the file 'pickle_support.o' with
> the error(s)
> 
> cc-3354 CC: ERROR File =
> /homes/Developer/sseefel/boost/boost/mpl/aux_/preprocessed/plain/arg.hpp,
> Line = 18
>    A non-integral operation is not allowed in a nontype template argument.
> 
>            BOOST_STATIC_ASSERT(!is_void_<type>::value);
>            ^
> 
> cc-1070 CC: ERROR File =
> /homes/Developer/sseefel/boost/boost/mpl/aux_/preprocessed/plain/arg.hpp,
> Line = 18
>    The indicated type is incomplete.
> 
>            BOOST_STATIC_ASSERT(!is_void_<type>::value);

This was working on that compiler a few days ago. I'll see about a workaround.

> Beside that, I find the build system not very transparent, so tracking
> things down is non-obvious. The use of jam isn't particularly helpful.
> For example I just realized from the error logs that it is using the
> "-mips3" compiler flag, while I'd like "-mips4". I couldn't find either
> docs nor code that made clear how to change that flag.

Yeah, we know there are some doc limitations we need to address. It's
a tension between investing resources in the current system and
developing the next one. We'll try to help out as best we can in the
meantime.

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From rwgk at yahoo.com  Mon Oct  7 17:58:08 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 7 Oct 2002 08:58:08 -0700 (PDT)
Subject: [C++-sig] compiling boost.python v2 on IRIX
In-Reply-To: <d2cd3967080c6f0508c3aca5e8685eba3da1a2c7@>
Message-ID: <20021007155808.48198.qmail@web20205.mail.yahoo.com>

--- Stefan Seefeld <stefan.seefeld at orthosoft.ca> wrote:
> I just tried to compile boost.python v2 on irix using the 'mipspro'
> toolset. The compilation failed on the file 'pickle_support.o' with
> the error(s)
> 
> cc-3354 CC: ERROR File = 
> /homes/Developer/sseefel/boost/boost/mpl/aux_/preprocessed/plain/arg.hpp, 
> Line = 18
>    A non-integral operation is not allowed in a nontype template argument.
> 
>            BOOST_STATIC_ASSERT(!is_void_<type>::value);
>            ^

We are very actively maintaining the MIPSpro builds. As of 00:00PDT the build
with a fresh CVS was successful (http://cci.lbl.gov/boost/). When did you check
out your copy of the code?
We are using MIPSpro versions 7.3.1.2m and 7.3.1.3m. What are you using?
Ralf


__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com



From rwgk at yahoo.com  Mon Oct  7 18:09:32 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 7 Oct 2002 09:09:32 -0700 (PDT)
Subject: [C++-sig] compiling boost.python v2 on IRIX
In-Reply-To: <20021007155808.48198.qmail@web20205.mail.yahoo.com>
Message-ID: <20021007160932.55274.qmail@web20210.mail.yahoo.com>

The 8am build shows that the current CVS does indeed not work with IRIX. Until
we have a work-around you can use the cvs -D option to check out the cvs from
0am PDT (see man cvs).
Ralf

--- "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> wrote:
> --- Stefan Seefeld <stefan.seefeld at orthosoft.ca> wrote:
> > I just tried to compile boost.python v2 on irix using the 'mipspro'
> > toolset. The compilation failed on the file 'pickle_support.o' with
> > the error(s)


__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com



From seefeld at sympatico.ca  Mon Oct  7 18:17:19 2002
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Mon, 07 Oct 2002 12:17:19 -0400
Subject: [C++-sig] compiling boost.python v2 on IRIX
References: <20021007155808.48198.qmail@web20205.mail.yahoo.com>
Message-ID: <7d52399e8fdee4085e29d1bc92c9e49f3da1b4a9@>

Ralf W. Grosse-Kunstleve wrote:

> We are very actively maintaining the MIPSpro builds. As of 00:00PDT the build
> with a fresh CVS was successful (http://cci.lbl.gov/boost/). When did you check
> out your copy of the code?

just before compiling (and mailing to you) this morning.

> We are using MIPSpro versions 7.3.1.2m and 7.3.1.3m. What are you using?

MIPSpro 7.3.1.3m too, here.

And here are some more errors:

I removed the pickling module from the Jam file (hopefully it isn't
needed by any other module), and it stops at :

Chmod1 
libs/python/build/bin/libboost_python.so/mipspro/release/libboost_python.so
FileClone libs/python/build/bin-stage/libboost_python.so
Illegal option -- d
Usage: cp [-aDfirRp] [-b size] [-tP -[e size]] file1 file2
        cp [-aDfirRp] [-b size] [-tP -[e size]] file1 ... file2 dir

     cp -fdp 
libs/python/build/bin/libboost_python.so/mipspro/release/libboost_python.so 
  libs/python/build/bin-stage/libboost_python.so

Then I started on my own code, adding a Makefile...It stopped because
it was looking for <cstdlib> et al. I compiled the examples using bjam,
and was lucky to get some errors, since that permitted me to see what
flags you use, i.e. I discovered by chance that you provide C++ 
compatibility headers. My transparency argument again...

Regards,
		Stefan




From dave at boost-consulting.com  Mon Oct  7 18:17:59 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 07 Oct 2002 12:17:59 -0400
Subject: [C++-sig] compiling boost.python v2 on IRIX
In-Reply-To: <d2cd3967080c6f0508c3aca5e8685eba3da1a2c7@>
References: <d2cd3967080c6f0508c3aca5e8685eba3da1a2c7@>
Message-ID: <ulm5a5iko.fsf@boost-consulting.com>

Stefan Seefeld <stefan.seefeld at orthosoft.ca> writes:

> hi there,
> 
> I just tried to compile boost.python v2 on irix using the 'mipspro'
> toolset. The compilation failed on the file 'pickle_support.o' with
> the error(s)
> 
> cc-3354 CC: ERROR File =
> /homes/Developer/sseefel/boost/boost/mpl/aux_/preprocessed/plain/arg.hpp,
> Line = 18
>    A non-integral operation is not allowed in a nontype template argument.
> 
>            BOOST_STATIC_ASSERT(!is_void_<type>::value);
>            ^
> 
> cc-1070 CC: ERROR File =
> /homes/Developer/sseefel/boost/boost/mpl/aux_/preprocessed/plain/arg.hpp,
> Line = 18
>    The indicated type is incomplete.
> 
>            BOOST_STATIC_ASSERT(!is_void_<type>::value);

OK, this should be working now. Please give it a shot.

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From dave at boost-consulting.com  Mon Oct  7 18:22:49 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 07 Oct 2002 12:22:49 -0400
Subject: [C++-sig] compiling boost.python v2 on IRIX
In-Reply-To: <7d52399e8fdee4085e29d1bc92c9e49f3da1b4a9@>
References: <20021007155808.48198.qmail@web20205.mail.yahoo.com>
	<7d52399e8fdee4085e29d1bc92c9e49f3da1b4a9@>
Message-ID: <ufzvi5icm.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> I removed the pickling module from the Jam file (hopefully it isn't
> needed by any other module), and it stops at :
> 
> Chmod1
> libs/python/build/bin/libboost_python.so/mipspro/release/libboost_python.so
> FileClone libs/python/build/bin-stage/libboost_python.so
> Illegal option -- d
> Usage: cp [-aDfirRp] [-b size] [-tP -[e size]] file1 file2
>         cp [-aDfirRp] [-b size] [-tP -[e size]] file1 ... file2 dir
> 
>      cp -fdp
> libs/python/build/bin/libboost_python.so/mipspro/release/libboost_python.so
> libs/python/build/bin-stage/libboost_python.so

Hmm, this part is due to Rene's new tagging stuff. Rene?

In the meantime, you should have no problems with the RC_1_29_0 branch
of the boost CVS using Boost.Build.

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From grafik666 at redshift-software.com  Mon Oct  7 18:41:21 2002
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Mon,  7 Oct 2002 11:41:21 -0500
Subject: [C++-sig] compiling boost.python v2 on IRIX
In-Reply-To: <ufzvi5icm.fsf@boost-consulting.com>
Message-ID: <20021007114122-r01010800-cd287df1-0860-0108@12.100.89.43>

[2002-10-07] David Abrahams wrote:

>Stefan Seefeld <seefeld at sympatico.ca> writes:
>
>> I removed the pickling module from the Jam file (hopefully it isn't
>> needed by any other module), and it stops at :
>> 
>> Chmod1
>>
libs/python/build/bin/libboost_python.so/mipspro/release/libboost_python.so
>> FileClone libs/python/build/bin-stage/libboost_python.so
>> Illegal option -- d
>> Usage: cp [-aDfirRp] [-b size] [-tP -[e size]] file1 file2
>>         cp [-aDfirRp] [-b size] [-tP -[e size]] file1 ... file2 dir
>> 
>>      cp -fdp
>>
libs/python/build/bin/libboost_python.so/mipspro/release/libboost_python.so
>> libs/python/build/bin-stage/libboost_python.so
>
>Hmm, this part is due to Rene's new tagging stuff. Rene?

It definately is... but not really new, just the use of FileClone by the
stage rule.

>In the meantime, you should have no problems with the RC_1_29_0 branch
>of the boost CVS using Boost.Build.

Beg to differ ;-) -- Those changes are also in the RC branch.

Question that I need to answer is: What are the flags to "cp" so that it
also copies symbolic links as is?


-- grafik - Don't Assume Anything
-- rrivera at acm.org - grafik at redshift-software.com
-- 102708583 at icq - Grafik666 at AIM - Grafik at jabber.org



From dave at boost-consulting.com  Mon Oct  7 19:02:11 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 07 Oct 2002 13:02:11 -0400
Subject: [C++-sig] compiling boost.python v2 on IRIX
In-Reply-To: <20021007114122-r01010800-cd287df1-0860-0108@12.100.89.43>
References: <20021007114122-r01010800-cd287df1-0860-0108@12.100.89.43>
Message-ID: <uadlq5gj0.fsf@boost-consulting.com>

Rene Rivera <grafik666 at redshift-software.com> writes:

> libs/python/build/bin/libboost_python.so/mipspro/release/libboost_python.so
> >> libs/python/build/bin-stage/libboost_python.so
> >
> >Hmm, this part is due to Rene's new tagging stuff. Rene?
> 
> It definately is... but not really new, just the use of FileClone by the
> stage rule.
> 
> >In the meantime, you should have no problems with the RC_1_29_0 branch
> >of the boost CVS using Boost.Build.
> 
> Beg to differ ;-) -- Those changes are also in the RC branch.

?? I thought you were going to wait 'till I had tried this stuff
before putting it in the release candidate. Or am I thinking of some
other feature?

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From seefeld at sympatico.ca  Mon Oct  7 19:22:42 2002
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Mon, 07 Oct 2002 13:22:42 -0400
Subject: [C++-sig] compiling boost.python v2 on IRIX
References: <d2cd3967080c6f0508c3aca5e8685eba3da1a2c7@> <ulm5a5iko.fsf@boost-consulting.com>
Message-ID: <4017275ad802d41b1d319c05fc18210b3da1c3fa@>

David Abrahams wrote:

> OK, this should be working now. Please give it a shot.

it does indeed, thanks a lot !

		Stefan







From rwgk at yahoo.com  Mon Oct  7 19:23:48 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 7 Oct 2002 10:23:48 -0700 (PDT)
Subject: [C++-sig] mac os x
Message-ID: <20021007172348.84277.qmail@web20207.mail.yahoo.com>

I am trying to install the latest Boost.Python code on a freshly installed Mac
OS 10.2 with the Jun or Jul developer's kit + Aug patch. With a very minor fix
compilation of the core library goes smoothly, but my first attempt at linking
libbpl.dylib failed miserably. See attached log. I'd be grateful if any of the
Apple experts out there could help figuring out what is wrong.
Ralf

c++ -fno-common -no-cpp-precomp -ftemplate-depth-50 -w -g -DNDEBUG
-DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_V2 -DBOOST_PYTHON_SOURCE
-I/net/cci/rwgk/mpl2/boost -I/usr/include/python2.2 -c -o
boost/libs/python/src/tuple.o
/net/cci/rwgk/mpl2/boost/libs/python/src/tuple.cpp
c++ -dynamiclib -o libtbx/libbpl.dylib boost/libs/python/src/list.o
boost/libs/python/src/long.o boost/libs/python/src/dict.o
boost/libs/python/src/tuple.o boost/libs/python/src/str.o
boost/libs/python/src/aix_init_module.o
boost/libs/python/src/converter/from_python.o
boost/libs/python/src/converter/registry.o
boost/libs/python/src/converter/type_id.o boost/libs/python/src/object/enum.o
boost/libs/python/src/object/class.o boost/libs/python/src/object/function.o
boost/libs/python/src/object/inheritance.o
boost/libs/python/src/object/life_support.o
boost/libs/python/src/object/pickle_support.o boost/libs/python/src/errors.o
boost/libs/python/src/module.o
boost/libs/python/src/converter/builtin_converters.o
boost/libs/python/src/converter/arg_to_python_base.o
boost/libs/python/src/object/iterator.o boost/libs/python/src/object_protocol.o
boost/libs/python/src/object_operators.o
ld: multiple definitions of symbol
_ZZN5boost6python6detail11upcast_implI7_objectS3_EEPT0_PT_S5_E4same
boost/libs/python/src/list.o definition of
_ZZN5boost6python6detail11upcast_implI7_objectS3_EEPT0_PT_S5_E4same in section
(__TEXT,__const)
boost/libs/python/src/dict.o definition of
_ZZN5boost6python6detail11upcast_implI7_objectS3_EEPT0_PT_S5_E4same in section
(__TEXT,__const)
boost/libs/python/src/str.o definition of
_ZZN5boost6python6detail11upcast_implI7_objectS3_EEPT0_PT_S5_E4same in section
(__TEXT,__const)
boost/libs/python/src/converter/from_python.o definition of
_ZZN5boost6python6detail11upcast_implI7_objectS3_EEPT0_PT_S5_E4same in section
(__TEXT,__const)
ld: multiple definitions of symbol
_ZZN5boost6python6detail11upcast_implI11_typeobject7_objectEEPT0_PT_S6_E4same
boost/libs/python/src/converter/from_python.o definition of
_ZZN5boost6python6detail11upcast_implI11_typeobject7_objectEEPT0_PT_S6_E4same
in section (__TEXT,__const)
boost/libs/python/src/object/enum.o definition of
_ZZN5boost6python6detail11upcast_implI11_typeobject7_objectEEPT0_PT_S6_E4same
in section (__TEXT,__const)
boost/libs/python/src/object/enum.o definition of
_ZZN5boost6python6detail11upcast_implI7_objectS3_EEPT0_PT_S5_E4same in section
(__TEXT,__const)
boost/libs/python/src/object/class.o definition of
_ZZN5boost6python6detail11upcast_implI11_typeobject7_objectEEPT0_PT_S6_E4same
in section (__TEXT,__const)
ld: multiple definitions of symbol
_ZZN5boost6python6detail11upcast_implI11_typeobjectS3_EEPT0_PT_S5_E4same
boost/libs/python/src/object/enum.o definition of
_ZZN5boost6python6detail11upcast_implI11_typeobjectS3_EEPT0_PT_S5_E4same in
section (__TEXT,__const)
boost/libs/python/src/object/class.o definition of
_ZZN5boost6python6detail11upcast_implI11_typeobjectS3_EEPT0_PT_S5_E4same in
section (__TEXT,__const)
boost/libs/python/src/object/class.o definition of
_ZZN5boost6python6detail11upcast_implI7_objectS3_EEPT0_PT_S5_E4same in section
(__TEXT,__const)
boost/libs/python/src/object/function.o definition of
_ZZN5boost6python6detail11upcast_implI7_objectS3_EEPT0_PT_S5_E4same in section
(__TEXT,__const)
boost/libs/python/src/object/life_support.o definition of
_ZZN5boost6python6detail11upcast_implI7_objectS3_EEPT0_PT_S5_E4same in section
(__TEXT,__const)
boost/libs/python/src/object/pickle_support.o definition of
_ZZN5boost6python6detail11upcast_implI7_objectS3_EEPT0_PT_S5_E4same in section
(__TEXT,__const)
boost/libs/python/src/module.o definition of
_ZZN5boost6python6detail11upcast_implI11_typeobject7_objectEEPT0_PT_S6_E4same
in section (__TEXT,__const)
boost/libs/python/src/module.o definition of
_ZZN5boost6python6detail11upcast_implI7_objectS3_EEPT0_PT_S5_E4same in section
(__TEXT,__const)
boost/libs/python/src/converter/builtin_converters.o definition of
_ZZN5boost6python6detail11upcast_implI7_objectS3_EEPT0_PT_S5_E4same in section
(__TEXT,__const)
boost/libs/python/src/converter/arg_to_python_base.o definition of
_ZZN5boost6python6detail11upcast_implI7_objectS3_EEPT0_PT_S5_E4same in section
(__TEXT,__const)
boost/libs/python/src/object_protocol.o definition of
_ZZN5boost6python6detail11upcast_implI7_objectS3_EEPT0_PT_S5_E4same in section
(__TEXT,__const)
boost/libs/python/src/object_operators.o definition of
_ZZN5boost6python6detail11upcast_implI7_objectS3_EEPT0_PT_S5_E4same in section
(__TEXT,__const)
/usr/bin/libtool: internal link edit command failed


__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com



From grafik666 at redshift-software.com  Mon Oct  7 19:31:12 2002
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Mon,  7 Oct 2002 12:31:12 -0500
Subject: [C++-sig] compiling boost.python v2 on IRIX
In-Reply-To: <uadlq5gj0.fsf@boost-consulting.com>
Message-ID: <20021007123112-r01010800-cb62fefb-0860-0108@12.100.89.43>

[2002-10-07] David Abrahams wrote:

>Rene Rivera <grafik666 at redshift-software.com> writes:
>
>>
libs/python/build/bin/libboost_python.so/mipspro/release/libboost_python.so
>> >> libs/python/build/bin-stage/libboost_python.so
>> >
>> >Hmm, this part is due to Rene's new tagging stuff. Rene?
>> 
>> It definately is... but not really new, just the use of FileClone by the
>> stage rule.
>> 
>> >In the meantime, you should have no problems with the RC_1_29_0 branch
>> >of the boost CVS using Boost.Build.
>> 
>> Beg to differ ;-) -- Those changes are also in the RC branch.
>
>?? I thought you were going to wait 'till I had tried this stuff
>before putting it in the release candidate. Or am I thinking of some
>other feature?

You are thinking of some other feature... The FileClone is what stage uses
to copy the files. So if you use stage you'll see that problem. It's been
that way for a while. It's the change that I did put into the RC before the
main, because of the release instructions.


-- grafik - Don't Assume Anything
-- rrivera at acm.org - grafik at redshift-software.com
-- 102708583 at icq - Grafik666 at AIM - Grafik at jabber.org



From dave at boost-consulting.com  Mon Oct  7 19:50:20 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 07 Oct 2002 13:50:20 -0400
Subject: [C++-sig] compiling boost.python v2 on IRIX
In-Reply-To: <20021007123112-r01010800-cb62fefb-0860-0108@12.100.89.43>
References: <20021007123112-r01010800-cb62fefb-0860-0108@12.100.89.43>
Message-ID: <ur8f22l5v.fsf@boost-consulting.com>

Rene Rivera <grafik666 at redshift-software.com> writes:

> [2002-10-07] David Abrahams wrote:
> 
> >Rene Rivera <grafik666 at redshift-software.com> writes:
> >
> >>
> libs/python/build/bin/libboost_python.so/mipspro/release/libboost_python.so
> >> >> libs/python/build/bin-stage/libboost_python.so
> >> >
> >> >Hmm, this part is due to Rene's new tagging stuff. Rene?
> >> 
> >> It definately is... but not really new, just the use of FileClone by the
> >> stage rule.
> >> 
> >> >In the meantime, you should have no problems with the RC_1_29_0 branch
> >> >of the boost CVS using Boost.Build.
> >> 
> >> Beg to differ ;-) -- Those changes are also in the RC branch.
> >
> >?? I thought you were going to wait 'till I had tried this stuff
> >before putting it in the release candidate. Or am I thinking of some
> >other feature?
> 
> You are thinking of some other feature... The FileClone is what stage uses
> to copy the files. So if you use stage you'll see that problem. It's been
> that way for a while. It's the change that I did put into the RC before the
> main, because of the release instructions.

Ah, OK. Well I attached the IRIX man page for cp here:
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mancp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20021007/fcf1b1a6/attachment.txt>
-------------- next part --------------


-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com

From stefan.seefeld at orthosoft.ca  Mon Oct  7 20:03:33 2002
From: stefan.seefeld at orthosoft.ca (Stefan Seefeld)
Date: Mon, 07 Oct 2002 14:03:33 -0400
Subject: [C++-sig] newbie questions
Message-ID: <fc999c50aa7f4ceba734d6205e1f48e13da1cd8e@>

hi there,

now that I have taken the first hurdles, I come back
with more questions :)

I want to create a python frontend for a set of libraries /
modules I'm working with.

I'v got an interface ('Foo') that is implemented
at a couple of places ('FooImpl1', 'FooImpl2', etc.),
and I have a factory that instantiates them depending
on a string argument.

It looks like the natural thing to do would be to make the python
front end expose the interface 'Foo', but instead of exposing
Foo's constructor, the Foo factory is used:

 > foo1 = Foo("FooImpl1")
 > foo2 = Foo("FooImpl2")

How is this to be done ? It looks like I should play with
'HeldType', but I could't get it working yet. Also, If I use
a 'class_' where the HeldType is a pointer type, how should
I manage ownership ?

Thanks a lot,
		Stefan




From dave at boost-consulting.com  Mon Oct  7 20:04:25 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 07 Oct 2002 14:04:25 -0400
Subject: [C++-sig] newbie questions
In-Reply-To: <fc999c50aa7f4ceba734d6205e1f48e13da1cd8e@>
References: <fc999c50aa7f4ceba734d6205e1f48e13da1cd8e@>
Message-ID: <ubs662kie.fsf@boost-consulting.com>

Stefan Seefeld <stefan.seefeld at orthosoft.ca> writes:

> hi there,
> 
> now that I have taken the first hurdles, I come back
> with more questions :)
> 
> I want to create a python frontend for a set of libraries /
> modules I'm working with.

You've come to the right place!

> I'v got an interface ('Foo') that is implemented
> at a couple of places ('FooImpl1', 'FooImpl2', etc.),
> and I have a factory that instantiates them depending
> on a string argument.
> 
> It looks like the natural thing to do would be to make the python
> front end expose the interface 'Foo', but instead of exposing
> Foo's constructor, the Foo factory is used:
> 
>  > foo1 = Foo("FooImpl1")
>  > foo2 = Foo("FooImpl2")
> 
> How is this to be done ? It looks like I should play with
> 'HeldType', but I could't get it working yet. 

How about using boost::shared_ptr<Foo> as your HeldType and returning
boost::shared_ptr<Foo> from your factory function?

> Also, If I use
> a 'class_' where the HeldType is a pointer type, how should
> I manage ownership ?

Best not to use a raw pointer, since (I guess it's obvious) managing
ownership is tough. If you use boost::shared_ptr or std::auto_ptr
ownership will be managed for you.

HTH,
Dave

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From dave at boost-consulting.com  Mon Oct  7 20:10:02 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 07 Oct 2002 14:10:02 -0400
Subject: [C++-sig] Leaked reference when putting an extension object in a tuple
In-Reply-To: <3190BC9FA8F6D3119508009027E5B33EBA5340@MORSE>
References: <3190BC9FA8F6D3119508009027E5B33EBA5340@MORSE>
Message-ID: <u7kgu2k91.fsf@boost-consulting.com>

"Charsley, Mark" <Mark.Charsley at radioscape.com> writes:

> I appear to be leaking a reference in my C++ extension. The general gist of
> what I'm trying to achieve is to create a C++ python extension that
> a) defines a new class (MyClass)
> b) provides a way for python to register callback functions
> 
> When a callback becomes necessary, my extension creates a MyClass object,
> puts it in a tuple and then calls PyEval_CallObject with the callback
> function and the tuple. Unfortunately it seems to leak references when I put
> my object in a tuple. The source for a very cut down version of the
> extension is given below. Running it in a debug build of python gives the
> following...
> 
> ActivePython 2.2.1 Build 222 (ActiveState Corp.) based on
> Python 2.2.1 (#34, Apr 10 2002, 11:35:50) [MSC 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import PyObjectPasser
> [8031 refs]
> >>> PyObjectPasser.RequestCallback()
> [8034 refs]
> >>> PyObjectPasser.RequestCallback()
> [8035 refs]
> >>> PyObjectPasser.RequestCallback()
> [8036 refs]
> >>> PyObjectPasser.RequestCallback()
> [8037 refs]
> >>>
> 
> Putting an integer into the tuple instead of a MyClass object gives a
> constant count of 8033 refs. So is there something wrong with
> a) my code
> b) python's reference counting
> c) the boot.python library
> 
> In the probable case of a), what am I doing wrong?
> 
> Many thanks in advance
> 
> Mark

Mark, it doesn't look like you're doing anything wrong, and I'm afraid
I can't fix the problem. The Boost Python v1 codebase is going to be
retired this week; we're releasing v2, and not making any changes to
v1, even for maintenance. If you haven't invested too much in
Boost.Python v1, you might try this with v2; I think you'll see better
results.

Regards,
Dave

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From seefeld at sympatico.ca  Mon Oct  7 20:27:05 2002
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Mon, 07 Oct 2002 14:27:05 -0400
Subject: [C++-sig] newbie questions
References: <fc999c50aa7f4ceba734d6205e1f48e13da1cd8e@> <ubs662kie.fsf@boost-consulting.com>
Message-ID: <af072bda597454d79882f9c4bc6cc0a73da1d312@>

David Abrahams wrote:

> How about using boost::shared_ptr<Foo> as your HeldType and returning
> boost::shared_ptr<Foo> from your factory function?

ok. Now I have

    python::class_<Foo,
                   boost::shared_ptr<Foo>,
                   boost::noncopyable> hello("Foo");

but the compiler complains. You use a 'assert_default_constructible'
class to make sure 'Foo' can be default-constructed, though obviously
in my case it shouldn't (only the factory should construct 'Foo's).
What am I missing ?

Stefan






From dave at boost-consulting.com  Mon Oct  7 20:49:14 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 07 Oct 2002 14:49:14 -0400
Subject: [C++-sig] newbie questions
In-Reply-To: <af072bda597454d79882f9c4bc6cc0a73da1d312@>
References: <fc999c50aa7f4ceba734d6205e1f48e13da1cd8e@>
	<ubs662kie.fsf@boost-consulting.com>
	<af072bda597454d79882f9c4bc6cc0a73da1d312@>
Message-ID: <u7kgu13v9.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> David Abrahams wrote:
> 
> > How about using boost::shared_ptr<Foo> as your HeldType and returning
> > boost::shared_ptr<Foo> from your factory function?
> 
> ok. Now I have
> 
>     python::class_<Foo,
>                    boost::shared_ptr<Foo>,
>                    boost::noncopyable> hello("Foo");
> 
> but the compiler complains. You use a 'assert_default_constructible'
> class to make sure 'Foo' can be default-constructed, though obviously
> in my case it shouldn't (only the factory should construct 'Foo's).
> What am I missing ?

     python::class_<Foo,
                    boost::shared_ptr<Foo>,
                    boost::noncopyable> hello("Foo", no_init);
                                                     ^^^^^^^
-or-

     python::class_<Foo,
                    boost::shared_ptr<Foo>,
                    boost::noncopyable> hello("Foo", init<Arg1, Arg2>());

etc...

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From seefeld at sympatico.ca  Tue Oct  8 15:08:42 2002
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Tue, 08 Oct 2002 09:08:42 -0400
Subject: [C++-sig] newbie questions
References: <fc999c50aa7f4ceba734d6205e1f48e13da1cd8e@>	<ubs662kie.fsf@boost-consulting.com>	<af072bda597454d79882f9c4bc6cc0a73da1d312@> <u7kgu13v9.fsf@boost-consulting.com>
Message-ID: <4fc09342c9f380384b1c9029efe540ae3da2da0f@>

Hi David,

David Abrahams wrote:

>      python::class_<Foo,
>                     boost::shared_ptr<Foo>,
>                     boost::noncopyable> hello("Foo", no_init);

works wonderfully !

I want to add nested types to my class (enums, consts, other classes,
etc.).  How is this to be done ?

Regards,
		Stefan




From dave at boost-consulting.com  Tue Oct  8 15:13:10 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 08 Oct 2002 09:13:10 -0400
Subject: [C++-sig] newbie questions
In-Reply-To: <ubs662kie.fsf@boost-consulting.com>
References: <fc999c50aa7f4ceba734d6205e1f48e13da1cd8e@>
	<ubs662kie.fsf@boost-consulting.com>
Message-ID: <uhefxnkex.fsf@boost-consulting.com>

David Abrahams <dave at boost-consulting.com> writes:

> Stefan Seefeld <stefan.seefeld at orthosoft.ca> writes:
>
> > I'v got an interface ('Foo') that is implemented
> > at a couple of places ('FooImpl1', 'FooImpl2', etc.),
> > and I have a factory that instantiates them depending
> > on a string argument.
> > 
> > It looks like the natural thing to do would be to make the python
> > front end expose the interface 'Foo', but instead of exposing
> > Foo's constructor, the Foo factory is used:
> > 
> >  > foo1 = Foo("FooImpl1")
> >  > foo2 = Foo("FooImpl2")
> > 
> > How is this to be done ? It looks like I should play with
> > 'HeldType', but I could't get it working yet. 
> 
> How about using boost::shared_ptr<Foo> as your HeldType and returning
> boost::shared_ptr<Foo> from your factory function?
> 
> > Also, If I use
> > a 'class_' where the HeldType is a pointer type, how should
> > I manage ownership ?
> 
> Best not to use a raw pointer, since (I guess it's obvious) managing
> ownership is tough. If you use boost::shared_ptr or std::auto_ptr
> ownership will be managed for you.

Actually I forgot that there's support for using raw pointers here, if
you want it:

   class_<Base, noncopyable>("Base", no_init)
       ... // whatever
       ;

Now,

   def("Foo", Foo, return_value_policy<manage_new_object>());

See
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/python/doc/v2/manage_new_object.html
for an example.

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From dave at boost-consulting.com  Tue Oct  8 15:15:59 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 08 Oct 2002 09:15:59 -0400
Subject: [C++-sig] newbie questions
In-Reply-To: <4fc09342c9f380384b1c9029efe540ae3da2da0f@>
References: <fc999c50aa7f4ceba734d6205e1f48e13da1cd8e@>
	<ubs662kie.fsf@boost-consulting.com>
	<af072bda597454d79882f9c4bc6cc0a73da1d312@>
	<u7kgu13v9.fsf@boost-consulting.com>
	<4fc09342c9f380384b1c9029efe540ae3da2da0f@>
Message-ID: <ud6qlnka7.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> Hi David,
> 
> David Abrahams wrote:
> 
> >      python::class_<Foo,
> >                     boost::shared_ptr<Foo>,
> >                     boost::noncopyable> hello("Foo", no_init);
> 
> works wonderfully !
> 
> I want to add nested types to my class (enums, consts, other classes,
> etc.).  How is this to be done ?

See
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/python/doc/v2/scope.html


Hmm, it's clear to me that many pages are missing from the reference
documentation index.

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From seefeld at sympatico.ca  Tue Oct  8 16:03:13 2002
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Tue, 08 Oct 2002 10:03:13 -0400
Subject: [C++-sig] newbie questions
References: <fc999c50aa7f4ceba734d6205e1f48e13da1cd8e@>	<ubs662kie.fsf@boost-consulting.com>	<af072bda597454d79882f9c4bc6cc0a73da1d312@>	<u7kgu13v9.fsf@boost-consulting.com>	<4fc09342c9f380384b1c9029efe540ae3da2da0f@> <ud6qlnka7.fsf@boost-consulting.com>
Message-ID: <3e680ae46be85f5dc496956ed9f704573da2e6db@>

Hi David,

thanks a lot for your prompt replies, they are
extremely helpful.

I now want to wrap a method that returns a 'Bar'
pointer (in fact, what is returned is a 'BarImpl',
derived from 'Bar').

class Bar {};
class BarImpl : public Bar {};
class Foo
{
public:
   BarImpl *GetBar();
};


I'v declared a python class for 'Bar':

python::class_<Bar,
                boost::shared_ptr<Bar>,
                boost::noncopyable> ti("Bar", python::no_init);


but I figure I need to tell boost how to treat a 'BarImpl *'
first, i.e. how to coerce a 'BarImpl *' into a
boost::shared_ptr<Bar>.
I'v come across the 'ResultConverter' stuff, but
couldn't make much use of it so far. Any hints ?

Thanks again,
		Stefan




From dave at boost-consulting.com  Tue Oct  8 16:08:32 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 08 Oct 2002 10:08:32 -0400
Subject: [C++-sig] newbie questions
In-Reply-To: <3e680ae46be85f5dc496956ed9f704573da2e6db@>
References: <fc999c50aa7f4ceba734d6205e1f48e13da1cd8e@>
	<ubs662kie.fsf@boost-consulting.com>
	<af072bda597454d79882f9c4bc6cc0a73da1d312@>
	<u7kgu13v9.fsf@boost-consulting.com>
	<4fc09342c9f380384b1c9029efe540ae3da2da0f@>
	<ud6qlnka7.fsf@boost-consulting.com>
	<3e680ae46be85f5dc496956ed9f704573da2e6db@>
Message-ID: <uu1jxm3a7.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> Hi David,
> 
> thanks a lot for your prompt replies, they are
> extremely helpful.
> 
> I now want to wrap a method that returns a 'Bar'
> pointer (in fact, what is returned is a 'BarImpl',
> derived from 'Bar').
> 
> class Bar {};
> class BarImpl : public Bar {};
> class Foo
> {
> public:
>    BarImpl *GetBar();
> };

OK, first I need to ask some questions:

1. Are you trying to wrap an interface without changing it? In other
   words, is it OK to change the definition of Foo, Bar, and BarImpl,
   or is this wrapping job to be non-intrusive?

2. What is the semantics of GetBar()? Does it just return a pointer to
   some BarImpl, to be used as a kind of reference, or is it the
   caller expected to delete (or otherwise manage) the pointer it gets
   back?

3. If the BarImpl* is just a kind of reference, which object actually
   manages the lifetime of the BarImpl object?

> I'v declared a python class for 'Bar':
> 
> python::class_<Bar,
>                 boost::shared_ptr<Bar>,
>                 boost::noncopyable> ti("Bar", python::no_init);
> 
> 
> but I figure I need to tell boost how to treat a 'BarImpl *'
> first, i.e. how to coerce a 'BarImpl *' into a
> boost::shared_ptr<Bar>.

No, not neccessarily. Maybe it would be better to stop using
boost::shared_ptr<Bar> in your class_<> definition for the time being,
and switch to using return_value_policy<manage_new_object>() for your
factory function instead... just to avoid confusion.

> I'v come across the 'ResultConverter' stuff, but
> couldn't make much use of it so far. Any hints ?

Try answering my questions above first, and we'll see which hints are
appropriate.

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From seefeld at sympatico.ca  Tue Oct  8 16:35:41 2002
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Tue, 08 Oct 2002 10:35:41 -0400
Subject: [C++-sig] newbie questions
References: <fc999c50aa7f4ceba734d6205e1f48e13da1cd8e@>	<ubs662kie.fsf@boost-consulting.com>	<af072bda597454d79882f9c4bc6cc0a73da1d312@>	<u7kgu13v9.fsf@boost-consulting.com>	<4fc09342c9f380384b1c9029efe540ae3da2da0f@>	<ud6qlnka7.fsf@boost-consulting.com>	<3e680ae46be85f5dc496956ed9f704573da2e6db@> <uu1jxm3a7.fsf@boost-consulting.com>
Message-ID: <877826732def20634fedd7af792af5d13da2ee75@>

David Abrahams wrote:

> 1. Are you trying to wrap an interface without changing it? In other
>    words, is it OK to change the definition of Foo, Bar, and BarImpl,
>    or is this wrapping job to be non-intrusive?

ideally it's non-intrusive. I'm all for cleaning it up (and it needs
some cleanup !), but that's not my (current) mandate...

> 2. What is the semantics of GetBar()? Does it just return a pointer to
>    some BarImpl, to be used as a kind of reference, or is it the
>    caller expected to delete (or otherwise manage) the pointer it gets
>    back?

in this particular case Foo remains the owner.

> 3. If the BarImpl* is just a kind of reference, which object actually
>    manages the lifetime of the BarImpl object?

Foo.

I guess in all other cases I would use the factory approach we
discussed yesterday.

Regards,
		Stefan






From dave at boost-consulting.com  Tue Oct  8 16:38:42 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 08 Oct 2002 10:38:42 -0400
Subject: [C++-sig] newbie questions
In-Reply-To: <877826732def20634fedd7af792af5d13da2ee75@>
References: <fc999c50aa7f4ceba734d6205e1f48e13da1cd8e@>
	<ubs662kie.fsf@boost-consulting.com>
	<af072bda597454d79882f9c4bc6cc0a73da1d312@>
	<u7kgu13v9.fsf@boost-consulting.com>
	<4fc09342c9f380384b1c9029efe540ae3da2da0f@>
	<ud6qlnka7.fsf@boost-consulting.com>
	<3e680ae46be85f5dc496956ed9f704573da2e6db@>
	<uu1jxm3a7.fsf@boost-consulting.com>
	<877826732def20634fedd7af792af5d13da2ee75@>
Message-ID: <uptulknbh.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> David Abrahams wrote:
> 
> > 1. Are you trying to wrap an interface without changing it? In other
> >    words, is it OK to change the definition of Foo, Bar, and BarImpl,
> >    or is this wrapping job to be non-intrusive?
> 
> ideally it's non-intrusive. I'm all for cleaning it up (and it needs
> some cleanup !), but that's not my (current) mandate...
> 
> > 2. What is the semantics of GetBar()? Does it just return a pointer to
> >    some BarImpl, to be used as a kind of reference, or is it the
> >    caller expected to delete (or otherwise manage) the pointer it gets
> >    back?
> 
> in this particular case Foo remains the owner.
> 
> > 3. If the BarImpl* is just a kind of reference, which object actually
> >    manages the lifetime of the BarImpl object?
> 
> Foo.
> 
> I guess in all other cases I would use the factory approach we
> discussed yesterday.
> 
> Regards,
> 		Stefan

Okay, revisiting your code in that light:

    class Bar {};
    class BarImpl : public Bar {};
    class Foo
    {
     public:
       BarImpl *GetBar();
    };

you need this part no matter what:

   class_<Bar>("Bar")
       ...
       ;

option 1: expose the BarImpl class too:

   class_<BarImpl, bases<Bar> >("BarImpl", no_init)
       ;

   class_<Foo>("Foo")
       .def("GetBar", &Foo::GetBar
              , return_value_policy<return_internal_reference>())
       ...
       ;

The only downside of that is that Python users might detect that
there's a BarImpl class as well as a Bar class. But so what?

option 2: use a thin wrapper to hide the existence of BarImpl:

    Bar* foo_GetBar(Foo& f) { return f.GetBar(); }

    class_<Foo>("Foo")
       .def("GetBar", foo_GetBar
              , return_value_policy<return_internal_reference>())
       ...
       ;


HTH,
Dave

P.S. I suggest you read up on CallPolicies in the documentation I sent
you pointers to.

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From dave at boost-consulting.com  Tue Oct  8 17:04:50 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 08 Oct 2002 11:04:50 -0400
Subject: [C++-sig] newbie questions
In-Reply-To: <uptulknbh.fsf@boost-consulting.com>
References: <fc999c50aa7f4ceba734d6205e1f48e13da1cd8e@>
	<ubs662kie.fsf@boost-consulting.com>
	<af072bda597454d79882f9c4bc6cc0a73da1d312@>
	<u7kgu13v9.fsf@boost-consulting.com>
	<4fc09342c9f380384b1c9029efe540ae3da2da0f@>
	<ud6qlnka7.fsf@boost-consulting.com>
	<3e680ae46be85f5dc496956ed9f704573da2e6db@>
	<uu1jxm3a7.fsf@boost-consulting.com>
	<877826732def20634fedd7af792af5d13da2ee75@>
	<uptulknbh.fsf@boost-consulting.com>
Message-ID: <ufzvhkm3x.fsf@boost-consulting.com>

David Abrahams <dave at boost-consulting.com> writes:

>    class_<Foo>("Foo")
>        .def("GetBar", &Foo::GetBar
>               , return_value_policy<return_internal_reference>())
>        ...
>        ;

Whoops! All of those places I've written

    <return_internal_reference>

it should say

    <return_internal_reference<> >

instead.

Sorry,
Dave

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From seefeld at sympatico.ca  Tue Oct  8 17:53:30 2002
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Tue, 08 Oct 2002 11:53:30 -0400
Subject: [C++-sig] newbie questions
References: <fc999c50aa7f4ceba734d6205e1f48e13da1cd8e@>	<ubs662kie.fsf@boost-consulting.com>	<af072bda597454d79882f9c4bc6cc0a73da1d312@>	<u7kgu13v9.fsf@boost-consulting.com>	<4fc09342c9f380384b1c9029efe540ae3da2da0f@>	<ud6qlnka7.fsf@boost-consulting.com>	<3e680ae46be85f5dc496956ed9f704573da2e6db@>	<uu1jxm3a7.fsf@boost-consulting.com>	<877826732def20634fedd7af792af5d13da2ee75@> <uptulknbh.fsf@boost-consulting.com>
Message-ID: <23137128b9b82b488fc708a0010a51e93da300b4@>

David Abrahams wrote:

> you need this part no matter what:
> 
>    class_<Bar>("Bar")
>        ...
>        ;

with just one 'Bar' template parameter ? Wouldn't that mean
that each python instance would hold its own 'Bar' *object* ?
I'm dealing with references (pointers), after all, whether I
own them or not...

> option 2: use a thin wrapper to hide the existence of BarImpl:
> 
>     Bar* foo_GetBar(Foo& f) { return f.GetBar(); }
> 
>     class_<Foo>("Foo")
>        .def("GetBar", foo_GetBar
>               , return_value_policy<return_internal_reference>())
>        ...
>        ;

ok, tried that (plus the '<>' you mention in another mail), but
I get linker errors as some types are not to be found, or incomplete.

But what speaks against using shared_ptr with my own (dummy) deleter ?

I try this:

template<class T> struct dummy_deleter
{
     typedef void result_type;
     typedef T * argument_type;

     void operator()(T * x){}
};

boost::shared_ptr<Bar> Foo_GetBar(Foo &foo, int i)
{
    return boost::shared_ptr<Bar>(foo.getBar(),
      dummy_deleter<Foo>());
}

and then simply declare

foo.def("getBar", Foo_GetBar);

and it works. Is this a 'correct' way of doing it ?

Stefan





From Mark.Charsley at radioscape.com  Tue Oct  8 18:16:08 2002
From: Mark.Charsley at radioscape.com (Charsley, Mark)
Date: Tue, 8 Oct 2002 17:16:08 +0100 
Subject: [C++-sig] Leaked reference when putting an 
Message-ID: <3190BC9FA8F6D3119508009027E5B33EBA5345@MORSE>

> > I appear to be leaking a reference in my C++ extension. 
<SNIP>
> > So is there something wrong with
> > a) my code
> > b) python's reference counting
> > c) the boot.python library

> Mark, it doesn't look like you're doing anything wrong, 

That's a shame: my code would have been the easiest to fix :-(. I'll switch
to passing a python dictionary instead of my struct for the time being.

> I can't fix the problem. The Boost Python v1 codebase is going to be
> retired this week; we're releasing v2, 

Oh well I'll keep an eye out at boost.org each for the new release.

TVM

Mark


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
postmaster at radioscape.com.

This footnote also confirms that this email message has been scanned
for the presence of computer viruses known at the time of sending.

www.radioscape.com
**********************************************************************




From dave at boost-consulting.com  Tue Oct  8 18:29:12 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 08 Oct 2002 12:29:12 -0400
Subject: [C++-sig] newbie questions
In-Reply-To: <23137128b9b82b488fc708a0010a51e93da300b4@>
References: <fc999c50aa7f4ceba734d6205e1f48e13da1cd8e@>
	<ubs662kie.fsf@boost-consulting.com>
	<af072bda597454d79882f9c4bc6cc0a73da1d312@>
	<u7kgu13v9.fsf@boost-consulting.com>
	<4fc09342c9f380384b1c9029efe540ae3da2da0f@>
	<ud6qlnka7.fsf@boost-consulting.com>
	<3e680ae46be85f5dc496956ed9f704573da2e6db@>
	<uu1jxm3a7.fsf@boost-consulting.com>
	<877826732def20634fedd7af792af5d13da2ee75@>
	<uptulknbh.fsf@boost-consulting.com>
	<23137128b9b82b488fc708a0010a51e93da300b4@>
Message-ID: <uy998j3mv.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> David Abrahams wrote:
> 
> > you need this part no matter what:
> >    class_<Bar>("Bar")
> >        ...
> >        ;
> 
> with just one 'Bar' template parameter ? Wouldn't that mean
> that each python instance would hold its own 'Bar' *object* ?

Not neccessarily. It just affects how the Bar object is held when you
construct one from Python:

  >>> b = Bar() # Held by-value or,e.g., by shared_ptr<Bar>?

> I'm dealing with references (pointers), after all, whether I
> own them or not...

That's OK. When you use return_value_policy<manage_new_object> the
pointer gets embedded in and managed by a new Python object. When you
use return_value_policy<return_internal_reference<> > the pointer gets
embedded in a new Python object and the other Python object wrappers
have their lifetimes tied together so that the containing object won't
be destroyed until the new object is.

> > option 2: use a thin wrapper to hide the existence of BarImpl:
> >     Bar* foo_GetBar(Foo& f) { return f.GetBar(); }
> >     class_<Foo>("Foo")
> >        .def("GetBar", foo_GetBar
> >               , return_value_policy<return_internal_reference>())
> >        ...
> >        ;
> 
> ok, tried that (plus the '<>' you mention in another mail), but
> I get linker errors as some types are not to be found, or incomplete.

I can't help with that unless you post the linker errors.

> But what speaks against using shared_ptr with my own (dummy) deleter ?
> 
> I try this:
> 
> template<class T> struct dummy_deleter
> {
>      typedef void result_type;
>      typedef T * argument_type;
> 
>      void operator()(T * x){}
> };
> 
> boost::shared_ptr<Bar> Foo_GetBar(Foo &foo, int i)
> {
>     return boost::shared_ptr<Bar>(foo.getBar(),
>       dummy_deleter<Foo>());
> }

Umm, memory leaks and dangling shared_ptrs do.

> and then simply declare
> 
> foo.def("getBar", Foo_GetBar);
> 
> and it works. Is this a 'correct' way of doing it ?

Not very, unless it's OK for Python code using your wrapper to crash
the system. The C++ Bar object can still be deleted out from under the
shared_ptr that refers to it.

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From ostiguy at fnal.gov  Tue Oct  8 20:52:51 2002
From: ostiguy at fnal.gov (Francois Ostiguy)
Date: Tue, 8 Oct 2002 13:52:51 -0500 (CDT)
Subject: [C++-sig] static data members
Message-ID: <Pine.GSO.4.40.0210081349480.3675-100000@boopsie.fnal.gov>

Quick question -

How to I expose static class data members ?  Can you supply a short
example ?


-Francois

----------------------------------------------------------------------------
Dr. Jean-Francois OSTIGUY                              voice: (630) 840-2231
Beam Physics Dept MS220                                  FAX: (630) 840-6039
Fermi National Accelerator Laboratory                email: ostiguy at fnal.gov
Batavia IL 60510-0500                           WWW:www-ap.fnal.gov/~ostiguy





From dave at boost-consulting.com  Tue Oct  8 20:52:19 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 08 Oct 2002 14:52:19 -0400
Subject: [C++-sig] static data members
In-Reply-To: <Pine.GSO.4.40.0210081349480.3675-100000@boopsie.fnal.gov>
References: <Pine.GSO.4.40.0210081349480.3675-100000@boopsie.fnal.gov>
Message-ID: <uadlohifw.fsf@boost-consulting.com>

Francois Ostiguy <ostiguy at fnal.gov> writes:

> Quick question -
> 
> How to I expose static class data members ?  Can you supply a short
> example ?

object x_class
    = class_<X>("X")
         .def( ... )
         ...
         ;

x_class.attr("fu") = X::fu;
x_class.attr("bar") = X::bar;
...

HTH,

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From ostiguy at fnal.gov  Tue Oct  8 22:40:34 2002
From: ostiguy at fnal.gov (Francois Ostiguy)
Date: Tue, 8 Oct 2002 15:40:34 -0500 (CDT)
Subject: [C++-sig] static data members
In-Reply-To: <uadlohifw.fsf@boost-consulting.com>
Message-ID: <Pine.GSO.4.40.0210081527410.3675-100000@boopsie.fnal.gov>

> > Quick question -
> >
> > How to I expose static class data members ?  Can you supply a short
> > example ?
>
> object x_class
>     = class_<X>("X")
>          .def( ... )
>          ...
>          ;
>
> x_class.attr("fu") = X::fu;
> x_class.attr("bar") = X::bar;
> ...
>

I am stumped. I cannot get the code below to compile.
I get the following message from g++ 3.1.1:

py-ring.cc: In function `void init_module_ring()':
py-ring.cc:26: parse error before `=' token


module("ring")
     .add (
       ring_class = class_<Ring>("Ring", python::args<>() )
       .def("doTurn", &Ring::doTurn)
     );

     ring_class.attr("nodesInitialized")  = Ring::nodesInitialized;

...

where

Ring::nodesInitialized is a static variable
Ring::doTurn is a static method

Ring has both static and non-static data/function members.


-Francois

----------------------------------------------------------------------------
Dr. Jean-Francois OSTIGUY                              voice: (630) 840-2231
Beam Physics Dept MS220                                  FAX: (630) 840-6039
Fermi National Accelerator Laboratory                email: ostiguy at fnal.gov
Batavia IL 60510-0500                           WWW:www-ap.fnal.gov/~ostiguy





From ostiguy at fnal.gov  Tue Oct  8 22:46:07 2002
From: ostiguy at fnal.gov (Francois Ostiguy)
Date: Tue, 8 Oct 2002 15:46:07 -0500 (CDT)
Subject: [C++-sig] static data members (fwd) -- oops
Message-ID: <Pine.GSO.4.40.0210081544460.3675-100000@boopsie.fnal.gov>

There was I typo in my previous message. It should have read as follows:

I am stumped. I cannot get the code below to compile.
I get the following message from g++ 3.1.1:

py-ring.cc: In function `void init_module_ring()':
py-ring.cc:26: parse error before `=' token


module("ring")
     .add (
       ring_class object = class_<Ring>("Ring", python::args<>() )
       .def("doTurn", &Ring::doTurn)
     );

     ring_class.attr("nodesInitialized")  = Ring::nodesInitialized;

...

where

Ring::nodesInitialized is a static variable
Ring::doTurn is a static method

Ring has both static and non-static data/function members.


-Francois

----------------------------------------------------------------------------
Dr. Jean-Francois OSTIGUY                              voice: (630) 840-2231
Beam Physics Dept MS220                                  FAX: (630) 840-6039
Fermi National Accelerator Laboratory                email: ostiguy at fnal.gov
Batavia IL 60510-0500                           WWW:www-ap.fnal.gov/~ostiguy



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




From dave at boost-consulting.com  Tue Oct  8 22:47:04 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 08 Oct 2002 16:47:04 -0400
Subject: [C++-sig] static data members (fwd) -- oops
In-Reply-To: <Pine.GSO.4.40.0210081544460.3675-100000@boopsie.fnal.gov>
References: <Pine.GSO.4.40.0210081544460.3675-100000@boopsie.fnal.gov>
Message-ID: <un0pod5fb.fsf@boost-consulting.com>

Francois Ostiguy <ostiguy at fnal.gov> writes:

> There was I typo in my previous message. It should have read as follows:
> 
> I am stumped. I cannot get the code below to compile.
> I get the following message from g++ 3.1.1:
> 
> py-ring.cc: In function `void init_module_ring()':
> py-ring.cc:26: parse error before `=' token
> 
> 
> module("ring")
>      .add (
>        ring_class object = class_<Ring>("Ring", python::args<>() )
>        .def("doTurn", &Ring::doTurn)
>      );
> 
>      ring_class.attr("nodesInitialized")  = Ring::nodesInitialized;

Because it's not legal C++. 

Why not try the example the way I specified in my posting, using the
current Boost CVS source or the RC_1_29_0 branch?

The "module" class is gone in those versions and the upcoming release,
BTW.

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From ostiguy at fnal.gov  Tue Oct  8 23:28:45 2002
From: ostiguy at fnal.gov (Francois Ostiguy)
Date: Tue, 8 Oct 2002 16:28:45 -0500 (CDT)
Subject: [C++-sig] module class
In-Reply-To: <un0pod5fb.fsf@boost-consulting.com>
Message-ID: <Pine.GSO.4.40.0210081603540.3675-100000@boopsie.fnal.gov>

>
> Because it's not legal C++.
>
> Why not try the example the way I specified in my posting, using the
> current Boost CVS source or the RC_1_29_0 branch?
>
> The "module" class is gone in those versions and the upcoming release,
> BTW.
>

Dave  -

Thanks for you patience. I tried

object ring_class = class_<Ring>("Ring", args<>() )
         .def("doTurn", &Ring::doTurn)
       ;

       ring_class.attr("nodesInitialized")  = Ring::nodesInitialized;
       ring_class.attr("ringInitialized")   = Ring::ringInitialized;


It works just fine ! Note that I have been using a very recent
snapshot all along (probably <  2 weeks old) ... and the module class is
apparently still recognized ... has it been removed only recently ?

boost.python is a very, very, nice piece of work. The documentation is formal
and not very friendly. It would greatly benefit from  a few well commented
non-trivial real world examples. I do understand that this represents
even more work ...

Regards -

-Francois

----------------------------------------------------------------------------
Dr. Jean-Francois OSTIGUY                              voice: (630) 840-2231
Beam Physics Dept MS220                                  FAX: (630) 840-6039
Fermi National Accelerator Laboratory                email: ostiguy at fnal.gov
Batavia IL 60510-0500                           WWW:www-ap.fnal.gov/~ostiguy





From dave at boost-consulting.com  Tue Oct  8 23:35:44 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 08 Oct 2002 17:35:44 -0400
Subject: [C++-sig] module class
In-Reply-To: <Pine.GSO.4.40.0210081603540.3675-100000@boopsie.fnal.gov>
References: <Pine.GSO.4.40.0210081603540.3675-100000@boopsie.fnal.gov>
Message-ID: <uvg4cbolr.fsf@boost-consulting.com>

Francois Ostiguy <ostiguy at fnal.gov> writes:

> Thanks for you patience. I tried
> 
> object ring_class = class_<Ring>("Ring", args<>() )
>          .def("doTurn", &Ring::doTurn)
>        ;
> 
>        ring_class.attr("nodesInitialized")  = Ring::nodesInitialized;
>        ring_class.attr("ringInitialized")   = Ring::ringInitialized;
> 
> 
> It works just fine ! Note that I have been using a very recent
> snapshot all along (probably <  2 weeks old) ... and the module class is
> apparently still recognized ... has it been removed only recently ?

Yes.

> boost.python is a very, very, nice piece of work. 

Thanks!

> The documentation is formal and not very friendly. 

We'll have a friendly tutorial in the CVS by tomorrow.

> It would greatly benefit from a few well commented non-trivial real
> world examples. I do understand that this represents even more work
> ...

Have you looked at
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/python/doc/v2/reference.html
recently? It's still just the formal stuff, but you should find lots
of examples in there.

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From dave at boost-consulting.com  Wed Oct  9 17:09:30 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 09 Oct 2002 11:09:30 -0400
Subject: [C++-sig] Just about to release
Message-ID: <ud6qjsl79.fsf@boost-consulting.com>

Hi Everyone,

The main trunk of Boost.Python is basically ready for release,
including documentation and tutorial material. I am just going to move
the latest tweaks over to the RC_1_29_0 branch and run a few tests. If
you have any burning comments about the current state of the CVS, now
would be a good time to make them. In particular, take a look at the
documentation and the tutorial.

-Dave

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From grafik666 at redshift-software.com  Wed Oct  9 17:37:58 2002
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Wed,  9 Oct 2002 10:37:58 -0500
Subject: [C++-sig] Just about to release
In-Reply-To: <ud6qjsl79.fsf@boost-consulting.com>
Message-ID: <20021009103759-r01010800-72021d94-0860-0108@12.100.89.43>

[2002-10-09] David Abrahams wrote:

>Hi Everyone,
>
>The main trunk of Boost.Python is basically ready for release,
>including documentation and tutorial material. I am just going to move
>the latest tweaks over to the RC_1_29_0 branch and run a few tests. If
>you have any burning comments about the current state of the CVS, now
>would be a good time to make them. In particular, take a look at the
>documentation and the tutorial.

Did you incorporate the changes to the build to solve the naming problems?


-- grafik - Don't Assume Anything
-- rrivera at acm.org - grafik at redshift-software.com
-- 102708583 at icq - Grafik666 at AIM - Grafik at jabber.org



From leo at hiper.com.br  Wed Oct  9 17:56:31 2002
From: leo at hiper.com.br (Leonardo Rochael Almeida)
Date: 09 Oct 2002 12:56:31 -0300
Subject: [C++-sig] Just about to release
In-Reply-To: <ud6qjsl79.fsf@boost-consulting.com>
References: <ud6qjsl79.fsf@boost-consulting.com>
Message-ID: <1034178991.15841.5.camel@spitfire>

On Wed, 2002-10-09 at 12:09, David Abrahams wrote:
> Hi Everyone,
> 
> The main trunk of Boost.Python is basically ready for release,
> including documentation and tutorial material. I am just going to move
> the latest tweaks over to the RC_1_29_0 branch and run a few tests. If
> you have any burning comments about the current state of the CVS, now
> would be a good time to make them. In particular, take a look at the
> documentation and the tutorial.

From:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/python/doc/v2/scope.html

This looks strange:

<p>The <code>scope</code> class has an associated global Python object
which controls the Python namespace in which new extension classes and
wrapped functions will be defined as attributes. Default-constructing a
new <code>scope</code> object binds that object to the associated Python
object. Constructing a is associated with , and</p>
                     ^^^                 ^^^^^^^^ 

	Cheers, Leo

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.




From dave at boost-consulting.com  Wed Oct  9 17:55:16 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 09 Oct 2002 11:55:16 -0400
Subject: [C++-sig] Just about to release
In-Reply-To: <20021009103759-r01010800-72021d94-0860-0108@12.100.89.43>
References: <20021009103759-r01010800-72021d94-0860-0108@12.100.89.43>
Message-ID: <u1y6zsj2z.fsf@boost-consulting.com>

Rene Rivera <grafik666 at redshift-software.com> writes:

> [2002-10-09] David Abrahams wrote:
> 
> >Hi Everyone,
> >
> >The main trunk of Boost.Python is basically ready for release,
> >including documentation and tutorial material. I am just going to move
> >the latest tweaks over to the RC_1_29_0 branch and run a few tests. If
> >you have any burning comments about the current state of the CVS, now
> >would be a good time to make them. In particular, take a look at the
> >documentation and the tutorial.
> 
> Did you incorporate the changes to the build to solve the naming problems?

No, I'm sorry Rene. I had too many other things on my plate to be able
to risk a destabilization just for this one platform (AIX). I'll try
this after the release.

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From dave at boost-consulting.com  Wed Oct  9 18:05:14 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 09 Oct 2002 12:05:14 -0400
Subject: [C++-sig] Just about to release
In-Reply-To: <1034178991.15841.5.camel@spitfire>
References: <ud6qjsl79.fsf@boost-consulting.com>
	<1034178991.15841.5.camel@spitfire>
Message-ID: <uu1jvr41x.fsf@boost-consulting.com>

Leonardo Rochael Almeida <leo at hiper.com.br> writes:

> From:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/python/doc/v2/scope.html
> 
> This looks strange:
> 
> <p>The <code>scope</code> class has an associated global Python object
> which controls the Python namespace in which new extension classes and
> wrapped functions will be defined as attributes. Default-constructing a
> new <code>scope</code> object binds that object to the associated Python
> object. Constructing a is associated with , and</p>
>                      ^^^                 ^^^^^^^^ 

Fixed, thanks!

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From dave at boost-consulting.com  Wed Oct  9 18:15:17 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 09 Oct 2002 12:15:17 -0400
Subject: [C++-sig] Re: return policies and mipspro errors
In-Reply-To: <a423ab0343459bcf1a140e406ff9510e3da4544d@>
References: <c9dd13d0ca37b321c03ed8dd826cef5f3da331c3@>
	<usmzgd5sa.fsf@boost-consulting.com>
	<a423ab0343459bcf1a140e406ff9510e3da4544d@>
Message-ID: <uptujr3l6.fsf@boost-consulting.com>

Stefan Seefeld <stefan.seefeld at orthosoft.ca> writes:

> David Abrahams wrote:
> 
> > Those aren't link errors as you claimed in your post, but compile
> > errors.
> 
> yeah, you are right. But the way mipspro works makes them appear in
> the link stage, as that is where (in this case) the templates are
> instantiated.
> 
> > Is your CVS state up-to-date? What I'm seeing there looks like
> > a bug we fixed yesterday. Probably you're safest getting the RC_1_29_0
> > branch of Boost, as that's nearly what's going to be released in a
> > couple of days.
> 
> thanks. For now I just updated from the head branch, and it worked
> nicely.
> 
> The new tutorial is *wonderful*. Really a great help.

You can thank Joel for that.

> It appears you wrote it directly in html. Why don't you use docbook
> so the tutorial could be generated for other media (pdf, say), too ?

Not the tutorial; Joel has a funky little documentation proccessor
which generates the HTML from plaintext. I am looking forward to
re-doing the reference documentation in a more-flexible
format. However, I'm highly tempted to go with something like
reStructuredText (http://docutils.sourceforge.net/rst.html), which is
like a much more powerful version of what Joel was using, instead of
docbook. I can't stand <TYPING>tags</TYPING> or reading them, either.

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From stefan.seefeld at orthosoft.ca  Wed Oct  9 20:03:34 2002
From: stefan.seefeld at orthosoft.ca (Stefan Seefeld)
Date: Wed, 09 Oct 2002 14:03:34 -0400
Subject: [C++-sig] seg fault on IRIX
Message-ID: <59589ca1ee8a2e827ca91bf4accf5f4e3da470e1@>

hi there,

While I'm still busy getting up to speed with boost.python,
I'v run into a problem. From earlier discussions as well as
from the tutorial, I concluded that I could deal with return
values in the way I try to. Attached is a file that I thought
was correct. I compiled and run it on linux without problems.

However, on IRIX with mipspro a call to Foo.getBar() generates
a segmentation fault. Here are the essential lines from the
python wrapper (as seen in the attachment):

Bar *Foo_GetBar(Foo &foo)
{
    return foo.getBar();
}

...

python::class_<Foo, boost::noncopyable> foo("Foo", python::no_init);
foo.def("getBar", Foo_GetBar, python::return_internal_reference<>());


What is the problem ?

Stefan
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bug.cc
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20021009/4c099f69/attachment.txt>

From prabhu at aero.iitm.ernet.in  Wed Oct  9 21:09:14 2002
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Thu, 10 Oct 2002 00:39:14 +0530
Subject: [C++-sig] Trivial error in tutorial.
Message-ID: <15780.32474.564716.108004@monster.linux.in>

hi,

Got the chance to look at the latest docs.  The tutorial (which is all
i've had time to look at) is very nice!  I think I've found a small
mistake.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/python/doc/tutorial/doc/class_virtual_functions.html

  """  
  ...

  Will yield the expected result. Finally, calling calling the free
  function call_f with derived as argument:

    >>> call_f(derived())
    42

  Will also yield the expected result.

  Here's what's happening:

   1. call_f(derived()) is called in Python

  ...

#######
# And finally at the end of the page:

  Calling call_f, passing in a derived object:

    >>> call_f(derived())
    42


  """

AFAIK, *all* the call_f(derived())'s should read

 call_f(derived) 

  or 

 call_f(Derived())

Unless you are magically defining a default __call__ method when you
wrap the class?  

I hope I'm not missing something obvious here.

cheers,
prabhu



From Greg.Hawkins at softwire.co.uk  Wed Oct  9 21:35:24 2002
From: Greg.Hawkins at softwire.co.uk (Greg Hawkins)
Date: Wed, 9 Oct 2002 20:35:24 +0100
Subject: [C++-sig] Just about to release
Message-ID: <616BE6A276E3714788D2AC35C40CD18D7CFDC9@whale.softwire.co.uk>

Dave,

I think there's a small glitch in the boost/libs/python/doc/tutorial/doc/call_policies.html.

Informs Boost.Python that the lifetime of the argument indicated by ward (i.e. the 2nd argument: Z* z) is dependent on the lifetime of the argument indicated by custodian (i.e. the 1st argument: Z* z).

should be

Informs Boost.Python that the lifetime of the argument indicated by ward (i.e. the 2nd argument: Z* z) is dependent on the lifetime of the argument indicated by custodian (i.e. the 1st argument: Y& y).

best,
Greg

-----Original Message-----
From: David Abrahams [mailto:dave at boost-consulting.com]
Sent: 09 October 2002 16:10
To: c++-sig at python.org
Subject: [C++-sig] Just about to release


Hi Everyone,

The main trunk of Boost.Python is basically ready for release,
including documentation and tutorial material. I am just going to move
the latest tweaks over to the RC_1_29_0 branch and run a few tests. If
you have any burning comments about the current state of the CVS, now
would be a good time to make them. In particular, take a look at the
documentation and the tutorial.

-Dave

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com


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



From dave at boost-consulting.com  Wed Oct  9 21:33:16 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 09 Oct 2002 15:33:16 -0400
Subject: [C++-sig] Just about to release
In-Reply-To: <616BE6A276E3714788D2AC35C40CD18D7CFDC9@whale.softwire.co.uk>
References: <616BE6A276E3714788D2AC35C40CD18D7CFDC9@whale.softwire.co.uk>
Message-ID: <uofa3h0g3.fsf@boost-consulting.com>

"Greg Hawkins" <Greg.Hawkins at softwire.co.uk> writes:

> Dave,
> 
> I think there's a small glitch in the
> boost/libs/python/doc/tutorial/doc/call_policies.html.
> 
> Informs Boost.Python that the lifetime of the argument indicated by
> ward (i.e. the 2nd argument: Z* z) is dependent on the lifetime of the
> argument indicated by custodian (i.e. the 1st argument: Z* z).
> 
> should be
> 
> Informs Boost.Python that the lifetime of the argument indicated by
> ward (i.e. the 2nd argument: Z* z) is dependent on the lifetime of the
> argument indicated by custodian (i.e. the 1st argument: Y& y).

Thanks, Greg. I'm going to ask Joel to make the appropriate patches
when he gets done sleeping (it's 3AM where he is).

-Dave


-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From seefeld at sympatico.ca  Wed Oct  9 21:45:43 2002
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 09 Oct 2002 15:45:43 -0400
Subject: [C++-sig] Just about to release
References: <ud6qjsl79.fsf@boost-consulting.com>
Message-ID: <a45d9a0afa785e8dcdf94de247f86d8b3da488c9@>

the file class_operators_special_functions.html
contains special method definitions for Rational:


  class Rational
     { operator double() const; };

     Rational pow(Rational, Rational);
     Rational abs(Rational);
     ostream& operator<<(ostream&,Rational);

     class_<Rational>()
         .def(float_(self))  // __float__
         .def(pow(self))     // __pow__
         .def(abs(self))     // __abs__
         .def(str(self))     // __str__
         ;

shouldn't that read 'pow(self, other<Rational>)' ?
And what about 'str' ? How is the link to 'operator <<'
established ? Something is missing here...

Regards,
		Stefan




From Greg.Hawkins at softwire.co.uk  Wed Oct  9 21:48:56 2002
From: Greg.Hawkins at softwire.co.uk (Greg Hawkins)
Date: Wed, 9 Oct 2002 20:48:56 +0100
Subject: [C++-sig] Just about to release
Message-ID: <616BE6A276E3714788D2AC35C40CD18D7CFDCA@whale.softwire.co.uk>

Sure,

Should minor bits like this go to the list or to you or Joel directly? I guess the list is best so you don't get loads of duplicates...

Another one, for instance:

-------

first code example in boost/libs/python/doc/tutorial/doc/basic_interface.html

the 'y' doesn't correspond to the 'f' in the subsequent cpp example. One of them needs fixing.

    def f(x, f):
         if (y == 'foo'):  <<< this y should be f 
             x[3:7] = 'bar'
         else:
             x.items += f(3, x)
         return x

    def getfunc():
       return f;

-----------

best,
Greg

-----Original Message-----
From: David Abrahams [mailto:dave at boost-consulting.com]
Sent: 09 October 2002 20:33
To: c++-sig at python.org
Subject: Re: [C++-sig] Just about to release


"Greg Hawkins" <Greg.Hawkins at softwire.co.uk> writes:

> Dave,
> 
> I think there's a small glitch in the
> boost/libs/python/doc/tutorial/doc/call_policies.html.
> 
> Informs Boost.Python that the lifetime of the argument indicated by
> ward (i.e. the 2nd argument: Z* z) is dependent on the lifetime of the
> argument indicated by custodian (i.e. the 1st argument: Z* z).
> 
> should be
> 
> Informs Boost.Python that the lifetime of the argument indicated by
> ward (i.e. the 2nd argument: Z* z) is dependent on the lifetime of the
> argument indicated by custodian (i.e. the 1st argument: Y& y).

Thanks, Greg. I'm going to ask Joel to make the appropriate patches
when he gets done sleeping (it's 3AM where he is).

-Dave


-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com


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



From dave at boost-consulting.com  Wed Oct  9 21:42:39 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 09 Oct 2002 15:42:39 -0400
Subject: [C++-sig] Just about to release
In-Reply-To: <a45d9a0afa785e8dcdf94de247f86d8b3da488c9@>
References: <ud6qjsl79.fsf@boost-consulting.com>
	<a45d9a0afa785e8dcdf94de247f86d8b3da488c9@>
Message-ID: <uelaze6vk.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> the file class_operators_special_functions.html
> contains special method definitions for Rational:
> 
> 
>   class Rational
>      { operator double() const; };
> 
>      Rational pow(Rational, Rational);
>      Rational abs(Rational);
>      ostream& operator<<(ostream&,Rational);
> 
>      class_<Rational>()
>          .def(float_(self))  // __float__
>          .def(pow(self))     // __pow__
>          .def(abs(self))     // __abs__
>          .def(str(self))     // __str__
>          ;
> 
> shouldn't that read 'pow(self, other<Rational>)' ?

Yep, that's right.

> And what about 'str' ? 

str is fine.

> How is the link to 'operator <<' established ?

In the same way that "self + self" establishes a link to
operator+(Rational,Rational) (or whatever the signature ends up
being).

> Something is missing here...

What is it?

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From dave at boost-consulting.com  Wed Oct  9 21:46:42 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 09 Oct 2002 15:46:42 -0400
Subject: [C++-sig] Just about to release
In-Reply-To: <616BE6A276E3714788D2AC35C40CD18D7CFDCA@whale.softwire.co.uk>
References: <616BE6A276E3714788D2AC35C40CD18D7CFDCA@whale.softwire.co.uk>
Message-ID: <u7kgre6ot.fsf@boost-consulting.com>

"Greg Hawkins" <Greg.Hawkins at softwire.co.uk> writes:

> Sure,
> 
> Should minor bits like this go to the list or to you or Joel directly?
> I guess the list is best so you don't get loads of duplicates...

To the list is fine, thanks.

> Another one, for instance:
> 
> -------
> 
> first code example in
> boost/libs/python/doc/tutorial/doc/basic_interface.html
> 
> the 'y' doesn't correspond to the 'f' in the subsequent cpp
> example. One of them needs fixing.
> 
>     def f(x, f):
>          if (y == 'foo'): <<< this y should be f

I'm not so sure. I think having 'f' as a parameter to a function
called 'f' is confusing, don't you? Or maybe we should change the
function name to 'g', *and* make your suggested fix.

>              x[3:7] = 'bar'
>          else:
>              x.items += f(3, x)
>          return x
> 
>     def getfunc():
>        return f;
> 
> -----------
> 
> best, Greg
> 

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From seefeld at sympatico.ca  Wed Oct  9 22:01:06 2002
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 09 Oct 2002 16:01:06 -0400
Subject: [C++-sig] Just about to release
References: <ud6qjsl79.fsf@boost-consulting.com>	<a45d9a0afa785e8dcdf94de247f86d8b3da488c9@> <uelaze6vk.fsf@boost-consulting.com>
Message-ID: <737062d77f17ce6494454f302da68aa13da48c64@>

David Abrahams wrote:

>>And what about 'str' ? 
> 
> 
> str is fine.
> 
> 
>>How is the link to 'operator <<' established ?
> 
> 
> In the same way that "self + self" establishes a link to
> operator+(Rational,Rational) (or whatever the signature ends up
> being).

ah, expression templates...

>>Something is missing here...
> 
> 
> What is it?

well, probably just my insight :-)

While 'pow' is declared a few lines above, 'str'
isn't. So I guess it's declared elsewhere as a template
that delegates to 'operator <<', which would provide
the missing link...

Stefan






From ssmith at magnet.fsu.edu  Wed Oct  9 22:01:40 2002
From: ssmith at magnet.fsu.edu (Scott A. Smith)
Date: Wed, 09 Oct 2002 16:01:40 -0400
Subject: [C++-sig] Inplace Operator Problems
In-Reply-To: <15780.32474.564716.108004@monster.linux.in>
Message-ID: <PCEJJPDHEECNEKDDLPNLIEFACAAA.ssmith@magnet.fsu.edu>

Hello,

I've been trying to get inplace operators working in Boost.Python. The dox
(sorry still on Boost 1.28.0) have the following:

	Suppose the class BigNum has an operator+=:

	BigNum& operator+= (BigNum const& right);

	This can be exposed by first writing a wrapper function:
	BigNum& iadd (BigNum& self, const BigNum& right)
	{
	  return self += right;
	}
	and then exposing the wrapper with
	bignum_class.def(&iadd, "__iadd__");

This is exactly what I did with my class. Unfortunately I get the following
problem. Take BigNum as just some integer like class. In Python if I do

X = BigNum(1)
Y = X
Y += BigNum(3)

Then both X and Y are set to 4. Somehow X and Y point to the same thing when
going into the += wrapped function and it does not acknowledge that Y should
change without X. I guess such referencing is done automatically in Python,
but
in a normal addition it figures out that just fine (i.e. using op_add). Is
it
obvious to others what I am doing wrong?

Scott




From dave at boost-consulting.com  Wed Oct  9 21:57:12 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 09 Oct 2002 15:57:12 -0400
Subject: [C++-sig] Just about to release
In-Reply-To: <737062d77f17ce6494454f302da68aa13da48c64@>
References: <ud6qjsl79.fsf@boost-consulting.com>
	<a45d9a0afa785e8dcdf94de247f86d8b3da488c9@>
	<uelaze6vk.fsf@boost-consulting.com>
	<737062d77f17ce6494454f302da68aa13da48c64@>
Message-ID: <uwuorcrmv.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> David Abrahams wrote:
> 
> >> And what about 'str' ?
> > str is fine.
> >
> >>How is the link to 'operator <<' established ?
> > In the same way that "self + self" establishes a link to
> > operator+(Rational,Rational) (or whatever the signature ends up
> > being).
> 
> ah, expression templates...

Precisely.

> >>Something is missing here...
> > What is it?
> 
> well, probably just my insight :-)
> 
> While 'pow' is declared a few lines above, 'str'
> isn't. So I guess it's declared elsewhere as a template
> that delegates to 'operator <<', which would provide
> the missing link...

I agree that it would help if the tutorial docs mentioned explicitly
that operator<< is used by the method defined by
def(str(self)). However, the tutorial is definitely /not/ supposed to
provide insight into how things are implemented.

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From prabhu at aero.iitm.ernet.in  Wed Oct  9 22:08:52 2002
From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran)
Date: Thu, 10 Oct 2002 01:38:52 +0530
Subject: [C++-sig] Just about to release
In-Reply-To: <616BE6A276E3714788D2AC35C40CD18D7CFDC9@whale.softwire.co.uk>
References: <616BE6A276E3714788D2AC35C40CD18D7CFDC9@whale.softwire.co.uk>
Message-ID: <15780.36052.34834.193973@monster.linux.in>

>>>>> "GH" == Greg Hawkins <Greg.Hawkins at softwire.co.uk> writes:

    GH> Dave, I think there's a small glitch in the
    GH> boost/libs/python/doc/tutorial/doc/call_policies.html.

A few more minor corrections:

  boost/libs/python/doc/tutorial/doc/basic_interface.html

The example listed here will not work.  Could that example be changed,
please?

Typos here:

  boost/libs/python/doc/tutorial/doc/object_interface.html

 an integers --> an integer 

  boost/libs/python/doc/tutorial/doc/class_operators_special_functions.html

 oparators --> operators

  boost/libs/python/doc/tutorial/doc/iterators.html

 """
 The typical Python iteration protocol: for y in x... is as follows:

    iter iter = x.__iter__()    #get iterator

## Should read

    iter = x.__iter__()    #get iterator
 """   


prabhu





From seefeld at sympatico.ca  Wed Oct  9 22:12:55 2002
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 09 Oct 2002 16:12:55 -0400
Subject: [C++-sig] Just about to release
References: <ud6qjsl79.fsf@boost-consulting.com>	<a45d9a0afa785e8dcdf94de247f86d8b3da488c9@>	<uelaze6vk.fsf@boost-consulting.com>	<737062d77f17ce6494454f302da68aa13da48c64@> <uwuorcrmv.fsf@boost-consulting.com>
Message-ID: <a9940c3a2f44393671718f021c24946a3da48f5c@>

David Abrahams wrote:

> I agree that it would help if the tutorial docs mentioned explicitly
> that operator<< is used by the method defined by
> def(str(self)). However, the tutorial is definitely /not/ supposed to
> provide insight into how things are implemented.

Well, you expect users to provide 'operator <<', so you should
state that 'str' depends on it. That's more than an implementation
issue.

Regards,
		Stefan







From dave at boost-consulting.com  Wed Oct  9 22:05:12 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 09 Oct 2002 16:05:12 -0400
Subject: [C++-sig] Inplace Operator Problems
In-Reply-To: <PCEJJPDHEECNEKDDLPNLIEFACAAA.ssmith@magnet.fsu.edu>
References: <PCEJJPDHEECNEKDDLPNLIEFACAAA.ssmith@magnet.fsu.edu>
Message-ID: <uptujcr9j.fsf@boost-consulting.com>

"Scott A. Smith" <ssmith at magnet.fsu.edu> writes:

> Hello,
> 
> I've been trying to get inplace operators working in Boost.Python. The
> dox (sorry still on Boost 1.28.0) have the following:
> 
> 	Suppose the class BigNum has an operator+=:
> 
> 	BigNum& operator+= (BigNum const& right);
> 
> 	This can be exposed by first writing a wrapper function:
> 	BigNum& iadd (BigNum& self, const BigNum& right)
> 	{
> 	  return self += right;
> 	}
> 	and then exposing the wrapper with
> 	bignum_class.def(&iadd, "__iadd__");
> 
> This is exactly what I did with my class. Unfortunately I get the
> following problem. Take BigNum as just some integer like class. In
> Python if I do
> 
>       X = BigNum(1)
>       Y = X 
>       Y += BigNum(3)
> 
> Then both X and Y are set to 4. Somehow X and Y point to the same
> thing when going into the += wrapped function and it does not
> acknowledge that Y should change without X. I guess such referencing
> is done automatically in Python, but in a normal addition it figures
> out that just fine (i.e. using op_add). Is it obvious to others what I
> am doing wrong?

You'll see the same behavior if you do this with classes in Pure
Python. The way around it is to do this:

 	BigNum iadd (BigNum& self, const BigNum& right)
 	{
 	  return BigNum(self) += right;
 	}

In Python Y += Z rebinds Y to the result of calling __iadd__(Y,Z). If
you return the same object that was passed in from __iadd__, and
essentially modify the object in-place, you get the equivalent of no
rebinding.

Hmm, it might be neccessary to extend Boost.Python v2 to better handle
cases like this...

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From dave at boost-consulting.com  Wed Oct  9 22:06:18 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 09 Oct 2002 16:06:18 -0400
Subject: [C++-sig] Just about to release
In-Reply-To: <a9940c3a2f44393671718f021c24946a3da48f5c@>
References: <ud6qjsl79.fsf@boost-consulting.com>
	<a45d9a0afa785e8dcdf94de247f86d8b3da488c9@>
	<uelaze6vk.fsf@boost-consulting.com>
	<737062d77f17ce6494454f302da68aa13da48c64@>
	<uwuorcrmv.fsf@boost-consulting.com>
	<a9940c3a2f44393671718f021c24946a3da48f5c@>
Message-ID: <uk7krcr7p.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> David Abrahams wrote:
> 
> > I agree that it would help if the tutorial docs mentioned explicitly
> > that operator<< is used by the method defined by
> > def(str(self)). However, the tutorial is definitely /not/ supposed to
> > provide insight into how things are implemented.
> 
> Well, you expect users to provide 'operator <<', so you should
> state that 'str' depends on it. 

Oh, definitely. 

> That's more than an implementation issue.

I just meant that I don't want to discuss expression templates in the
tutorial ;-)

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From stefan.seefeld at orthosoft.ca  Wed Oct  9 22:27:14 2002
From: stefan.seefeld at orthosoft.ca (Stefan Seefeld)
Date: Wed, 09 Oct 2002 16:27:14 -0400
Subject: [C++-sig] howto convert a python list to a C++ matrix
Message-ID: <022665f4a0b25899319ff250ec7f289c3da49286@>

hi there,

I'm trying to define a matrix constructor that
takes a python list. I want to be able to write

 > matrix = Matrix([[1,0,0,0],[0,1,0,0],[0,0,1,0],[0,0,0,1]])

where Matrix is a C++ type. Obviously I need a factory
such as 'Matrix factory(object);' or similar.

But how am I to extract the elements of the list(s) in
boost.python style ? And how should I raise a TypeError
if I don't find what I'm looking for ?

Here is a first attempt:

Matrix factory(python::list &l)
{
    float matrix[16];
    assert(l.length() == 4);
    for (size_t i = 0; i != 4; ++i)
    {
       python::list row = extract<python::list>(l[i]);
       assert(row.length() == 4);
       for (size_t j = 0; j != 4; ++j)
       {
          matrix[4*i + j] = row[j];
       }
    }
    return Matrix(matrix);
}

But 'length()' doesn't appear to exist, and the asserts
should be replaced with some (python) exceptions that
indicate a type error or similar.




From greg.hawkins at blueyonder.co.uk  Thu Oct 10 00:32:00 2002
From: greg.hawkins at blueyonder.co.uk (Greg Hawkins)
Date: Wed, 09 Oct 2002 23:32:00 +0100
Subject: [C++-sig] Re: Just about to release
Message-ID: <3DA4AE60.3070101@blueyonder.co.uk>

 > I'm not so sure. I think having 'f' as a parameter to a function
 > called 'f' is confusing, don't you? Or maybe we should change the
 > function name to 'g', *and* make your suggested fix.

Oops! Yes, of course, the change should be in the other direction (make 
the c++ version use 'y' instead of 'f'). Having f being callable, 
comparable with 'foo' and the name of the function is not just confusing 
but impossible isn't it?

BTW, a slight worry I have with the tutorial is the emphasis on (b)jam. 
I don't have any problems with bjam but I don't use it for building v2 
extensions and it would be nice to reassure users that (apart from 
typing 'bjam' to build boost itself) they don't need to fool around with 
an alien build tool to build an extension. All they need is

1) the python headers in their include path
2) to link with python
3) $BOOST_ROOT in their include path
4) link with BOOST_ROOT/libs/python/build/bin-stage/<boost python>
5) define BOOST_PYTHON_DYNAMIC_LIB and BOOST_PYTHON_V2 (are these still 
necessary by the way? I haven't fooled around with my build settings for 
a while)

(at least I think that's all you need; a quick glance through my scons 
scripts doesn't turn up anything else...)

There's no need to patronise people but forcing jam on them on page 2 of 
the tutorial may be offputting...

Oh, and seeing that it's almost out of the door now: congratulations 
Dave (and Joel, Ralf, and everyone else) on Boost.Python v2. Its a 
marvellous thing.

best,
Greg


David Abrahams wrote:
 > "Greg Hawkins" <Greg.Hawkins at softwire.co.uk> writes:
 >
 >
 >>Sure,
 >>
 >>Should minor bits like this go to the list or to you or Joel directly?
 >>I guess the list is best so you don't get loads of duplicates...
 >
 >
 > To the list is fine, thanks.
 >
 >
 >>Another one, for instance:
 >>
 >>-------
 >>
 >>first code example in
 >>boost/libs/python/doc/tutorial/doc/basic_interface.html
 >>
 >>the 'y' doesn't correspond to the 'f' in the subsequent cpp
 >>example. One of them needs fixing.
 >>
 >>    def f(x, f):
 >>         if (y == 'foo'): <<< this y should be f
 >
 >
 > I'm not so sure. I think having 'f' as a parameter to a function
 > called 'f' is confusing, don't you? Or maybe we should change the
 > function name to 'g', *and* make your suggested fix.
 >
 >
 >>             x[3:7] = 'bar'
 >>         else:
 >>             x.items += f(3, x)
 >>         return x
 >>
 >>    def getfunc():
 >>       return f;
 >>
 >>-----------
 >>
 >>best, Greg
 >>
 >
 >





From dave at boost-consulting.com  Thu Oct 10 00:51:54 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 09 Oct 2002 18:51:54 -0400
Subject: [C++-sig] Re: Just about to release
In-Reply-To: <3DA4AE60.3070101@blueyonder.co.uk>
References: <3DA4AE60.3070101@blueyonder.co.uk>
Message-ID: <uelazb4z9.fsf@boost-consulting.com>

Greg Hawkins <greg.hawkins at blueyonder.co.uk> writes:

> Oops! Yes, of course, the change should be in the other direction
> (make the c++ version use 'y' instead of 'f'). Having f being
> callable, comparable with 'foo' and the name of the function is not
> just confusing but impossible isn't it?

Probably. I'll let Joel figure that out ;-)

> BTW, a slight worry I have with the tutorial is the emphasis on
> (b)jam. I don't have any problems with bjam but I don't use it for
> building v2 extensions and it would be nice to reassure users that
> (apart from typing 'bjam' to build boost itself) they don't need to
> fool around with an alien build tool to build an extension. All they
> need is
> 
> 1) the python headers in their include path
> 2) to link with python
> 3) $BOOST_ROOT in their include path
> 4) link with BOOST_ROOT/libs/python/build/bin-stage/<boost python>
> 5) define BOOST_PYTHON_DYNAMIC_LIB and BOOST_PYTHON_V2 (are these
> still necessary by the way? 

Nope.

> I haven't fooled around with my build settings for a while)
> 
> (at least I think that's all you need; a quick glance through my scons
> scripts doesn't turn up anything else...)

Well you see, there's the rub. The formula given there is absolutely
reliable for all the supported bjam toolsets. Do you have a 100%
reliable alternative for them? What if they don't know how to make a
shared library? What about getting the other compiler options they
need in order to make their C++ compiler fully-conforming enough to
compile Boost code (don't laugh, for lots of compilers you have to
turn on ansi conformant features).

> There's no need to patronise people but forcing jam on them on page
> 2 of the tutorial may be offputting...

All build systems are messy, AFAICT. Both Boost.Build and Scons are
working hard to change that, but in the meantime I think it's the
case. People need to use bjam anyway just to build
(lib)boost_python.[so/dll]. I think it makes sense to give people a
reliable formula for getting started. I don't know why you see this as
"forcing jam on people".

However, I agree with you that outlining the 5 elements you list above
would be extremely useful.

> Oh, and seeing that it's almost out of the door now: congratulations
> Dave (and Joel, Ralf, and everyone else) on Boost.Python v2. Its a
> marvellous thing.

Thanks!

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From rwgk at yahoo.com  Thu Oct 10 01:09:17 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 9 Oct 2002 16:09:17 -0700 (PDT)
Subject: [C++-sig] howto convert a python list to a C++ matrix
In-Reply-To: <022665f4a0b25899319ff250ec7f289c3da49286@>
Message-ID: <20021009230917.28800.qmail@web20210.mail.yahoo.com>

--- Stefan Seefeld <stefan.seefeld at orthosoft.ca> wrote:
> But how am I to extract the elements of the list(s) in
> boost.python style ? And how should I raise a TypeError
> if I don't find what I'm looking for ?

This is how I raise Python exceptions:

  void raise_index_error()
  {
    PyErr_SetString(PyExc_IndexError, "Index out of range.");
    boost::python::throw_error_already_set();
  }

BUT, you can do a lot better: you can tell Boost.Python how to convert
lists of lists automatically to your matrix type. Then you can simply
.def functions taking a matrix argument instead of providing wrappers
that do the conversion and then dispatch to the C++ library function.
For example:

  void foo(matrix const& m);

  def("foo", foo);

Versus with the factory approach:

  void foo(matrix const& m);

  void foo_wrapper(python::list &l)
  {
    matrix m = matrix_factory(l);
    foo(m);
  }

  def("foo", foo_wrapper);

You will have to write a wrapper for each function that uses matrix.

Attached is a stripped down version of

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/scitbx/include/scitbx/boost_python/container_conversions.h?rev=1.5&content-type=text/vnd.viewcvs-markup

If you move and customize the code from your factory function to
the code shown below you will have a general solution that avoids
the thin-wrapper clutter.

> But 'length()' doesn't appear to exist,

David preferred to deny my repeated requests to resurrect list::size()
and tuple::size() (was there in V1). Maybe if someone helps me begging
we can change his mind for the better. Here is how it works right now:

#include <boost/python/detail/api_placeholder.hpp>

          l = boost::python::len(your_list);

Ralf


  struct matrix_to_list_of_lists // to_tuple in the original file
  {
    static PyObject* convert(matrix const& a)
    {
      using namespace boost::python;
      list result;
      // your code here to generate the list of lists
      return incref(result.ptr()); 
    }
  };

  // This is a "custom lvalue converter". See also: Boost.Python FAQ
  struct matrix_from_list_of_lists // from_python in the original file
  {
    matrix_from_list_of_lists()
    {
      boost::python::converter::registry::push_back(
        &convertible,
        &construct,
        boost::python::type_id<matrix>());
    }

    static void* convertible(PyObject* obj_ptr)
    {
      using namespace boost::python;
      // your "factory" code here
      // return 0; // if the input object is not convertible
      return obj_ptr; // if the input object is convertible
    }

    static void construct(
      PyObject* obj_ptr,
      boost::python::converter::rvalue_from_python_stage1_data* data)
    {
      using namespace boost::python;
      void* storage = (
        (rvalue_from_python_storage<matrix>*)
          data)->storage.bytes;
      new (storage) matrix();
      data->convertible = storage;
      matrix& result = *((matrix*)storage);
      // now set the elements of the matrix using *obj_ptr
      // again similar to your "factory" code
      // for error detection use
      // if (PyErr_Occurred()) throw_error_already_set();
    }
  };

Usage:

     boost::python::to_python_converter<matrix, matrix_to_list_of_lists>();
     matrix_from_list_of_lists();


__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com



From dave at boost-consulting.com  Thu Oct 10 01:16:11 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 09 Oct 2002 19:16:11 -0400
Subject: [C++-sig] howto convert a python list to a C++ matrix
In-Reply-To: <20021009230917.28800.qmail@web20210.mail.yahoo.com>
References: <20021009230917.28800.qmail@web20210.mail.yahoo.com>
Message-ID: <u7kgrb3us.fsf@boost-consulting.com>

"Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:

> David preferred to deny my repeated requests to resurrect list::size()
> and tuple::size() (was there in V1). Maybe if someone helps me begging
> we can change his mind for the better. Here is how it works right now:
> 
> #include <boost/python/detail/api_placeholder.hpp>
> 
>           l = boost::python::len(your_list);
> 

What's wrong with len()? That's how it's spelled in Python.

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From paustin at eos.ubc.ca  Thu Oct 10 03:24:19 2002
From: paustin at eos.ubc.ca (Philip Austin)
Date: Wed, 9 Oct 2002 18:24:19 -0700
Subject: [C++-sig] numeric.hpp: copying raw data
In-Reply-To: <00ed01c26c25$a4f25590$6701a8c0@boostconsulting.com>
References: <OE35vbKmuyz9qcrO3lo0000c5ea@hotmail.com>
	<001001c26bfa$25be9c00$6701a8c0@boostconsulting.com>
	<15774.16189.157867.214799@gull.eos.ubc.ca>
	<00ed01c26c25$a4f25590$6701a8c0@boostconsulting.com>
Message-ID: <15780.54979.149104.744180@gull.eos.ubc.ca>

David Abrahams writes:
 > 
 > Anyway, about the above code: is there a way to do the equivalent of
 > 
 >     NA_Empty(1, &n, tInt32)
 > 
 > from Python?

I've been in touch with Todd Miller of the numarray group, and he says
that they've moved towards complete API compatibility with Numeric
(i.e. PyArrayObject->data can be used to get at a numarray object's
data).  So the bottom line is that if boost::python::numeric could
add zeros(shape,type) and/or ones(shape,type) to its interface,
the wrapper is substantially complete.

Regards, Phil




From djowel at gmx.co.uk  Thu Oct 10 04:22:07 2002
From: djowel at gmx.co.uk (Joel de Guzman)
Date: Thu, 10 Oct 2002 10:22:07 +0800
Subject: [C++-sig] Re: Just about to release
References: <3DA4AE60.3070101@blueyonder.co.uk> <uelazb4z9.fsf@boost-consulting.com>
Message-ID: <013801c27003$d7e64380$5b4ca7cb@kim>

----- Original Message ----- 
From: "David Abrahams" <dave at boost-consulting.com>


> Greg Hawkins <greg.hawkins at blueyonder.co.uk> writes:
> 
> > BTW, a slight worry I have with the tutorial is the emphasis on
> > (b)jam. I don't have any problems with bjam but I don't use it for
> > building v2 extensions and it would be nice to reassure users that
> > (apart from typing 'bjam' to build boost itself) they don't need to
> > fool around with an alien build tool to build an extension. All they
> > need is
> > 
> > 1) the python headers in their include path
> > 2) to link with python
> > 3) $BOOST_ROOT in their include path
> > 4) link with BOOST_ROOT/libs/python/build/bin-stage/<boost python>
> > 5) define BOOST_PYTHON_DYNAMIC_LIB and BOOST_PYTHON_V2 (are these
> > still necessary by the way? 
> 
> Nope.
> 
> > I haven't fooled around with my build settings for a while)
> > 
> > (at least I think that's all you need; a quick glance through my scons
> > scripts doesn't turn up anything else...)
> 
> Well you see, there's the rub. The formula given there is absolutely
> reliable for all the supported bjam toolsets. Do you have a 100%
> reliable alternative for them? What if they don't know how to make a
> shared library? What about getting the other compiler options they
> need in order to make their C++ compiler fully-conforming enough to
> compile Boost code (don't laugh, for lots of compilers you have to
> turn on ansi conformant features).
> 
> > There's no need to patronise people but forcing jam on them on page
> > 2 of the tutorial may be offputting...
> 
> All build systems are messy, AFAICT. Both Boost.Build and Scons are
> working hard to change that, but in the meantime I think it's the
> case. People need to use bjam anyway just to build
> (lib)boost_python.[so/dll]. I think it makes sense to give people a
> reliable formula for getting started. I don't know why you see this as
> "forcing jam on people".

I come from an IDE world. I've just began using the command line again
after more than a decade. I must admit, I had lots of difficulties dealing 
with the details before I was able to run my first Boost.Python module.
On one hand, this is the first thing a user will have to face. On the other 
hand, the details are quite overwhelming. (at least for me when I started).
I wished for something that I can play with straight out of the box;
something that I can setup in 5 minutes flat. I looked at other options
and I found bjam to be the quickest and most general.

> However, I agree with you that outlining the 5 elements you list above
> would be extremely useful.

Yes, these would be extremely useful, however, IMO, this info should
be placed in the more detailed building.html. 2c opinion.

> > Oh, and seeing that it's almost out of the door now: congratulations
> > Dave (and Joel, Ralf, and everyone else) on Boost.Python v2. Its a
> > marvellous thing.
> 
> Thanks!

Thanks!

--Joel




From djowel at gmx.co.uk  Thu Oct 10 04:25:26 2002
From: djowel at gmx.co.uk (Joel de Guzman)
Date: Thu, 10 Oct 2002 10:25:26 +0800
Subject: [C++-sig] Re: Just about to release
References: <3DA4AE60.3070101@blueyonder.co.uk> <uelazb4z9.fsf@boost-consulting.com> <013801c27003$d7e64380$5b4ca7cb@kim>
Message-ID: <015201c27004$4e834100$5b4ca7cb@kim>

Hi Y'all,

FYI, I'm already working on the tutorial update.
Thank you all very much for your comments and 
bug reports.

Regards,
--Joel




From djowel at gmx.co.uk  Thu Oct 10 09:43:26 2002
From: djowel at gmx.co.uk (Joel de Guzman)
Date: Thu, 10 Oct 2002 15:43:26 +0800
Subject: [C++-sig] Re: return policies and mipspro errors
References: <c9dd13d0ca37b321c03ed8dd826cef5f3da331c3@><usmzgd5sa.fsf@boost-consulting.com><a423ab0343459bcf1a140e406ff9510e3da4544d@> <uptujr3l6.fsf@boost-consulting.com>
Message-ID: <00df01c27030$bb223ec0$0100a8c0@kim>

----- Original Message ----- 
From: "David Abrahams" <dave at boost-consulting.com>


> > It appears you wrote it directly in html. Why don't you use docbook
> > so the tutorial could be generated for other media (pdf, say), too ?
> 
> Not the tutorial; Joel has a funky little documentation proccessor
> which generates the HTML from plaintext. I am looking forward to
> re-doing the reference documentation in a more-flexible
> format. However, I'm highly tempted to go with something like
> reStructuredText (http://docutils.sourceforge.net/rst.html), which is
> like a much more powerful version of what Joel was using, instead of
> docbook. I can't stand <TYPING>tags</TYPING> or reading them, either.

The tutorial was done by quickdoc, brought to you by the Spirit
inline parser (http://spirit.sf.net)... A shameless plug :-)

Well, Dave is correct reStructuredText is a more mature tool.
quickdoc is in fact just a weekend hack. It's basically just a
demo (anticipating the boost formal review of Spirit come
11th October). However, I already found it usefull and has
since wrote 3 documents using it. The quickdoc manual, 
the phoenix manual, and now boost.python's tutorial.

Best regards,
--Joel

PS> Pardon the shameless plug... Now back to regular programming :-)







From stefan.seefeld at orthosoft.ca  Thu Oct 10 17:00:59 2002
From: stefan.seefeld at orthosoft.ca (Stefan Seefeld)
Date: Thu, 10 Oct 2002 11:00:59 -0400
Subject: [C++-sig] operators
Message-ID: <b1db87028f02b44c17173f6d60496f7e3da597ab@>

hi there,

operators.hpp imports certain functions (such as 'str')
into the global namespace, instead of the namespace
boost::python. That looks like an error...

Regards,
		Stefan




From dave at boost-consulting.com  Thu Oct 10 17:02:52 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 10 Oct 2002 11:02:52 -0400
Subject: [C++-sig] operators
In-Reply-To: <b1db87028f02b44c17173f6d60496f7e3da597ab@>
References: <b1db87028f02b44c17173f6d60496f7e3da597ab@>
Message-ID: <uwuoqs5er.fsf@boost-consulting.com>

Stefan Seefeld <stefan.seefeld at orthosoft.ca> writes:

> hi there,
> 
> operators.hpp imports certain functions (such as 'str')
> into the global namespace, instead of the namespace
> boost::python. That looks like an error...

It's only on broken compilers which don't support Koenig Lookup, and
it's intentional. The negative impact should be limited due to the
fact that these functions only operate on objects of type
boost::python::self_ns::self_t. Do you anticipate a real problem with
this?

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From seefeld at sympatico.ca  Thu Oct 10 18:02:58 2002
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 10 Oct 2002 12:02:58 -0400
Subject: [C++-sig] operators
References: <b1db87028f02b44c17173f6d60496f7e3da597ab@> <uwuoqs5er.fsf@boost-consulting.com>
Message-ID: <665eb24fbd67b8205cf25967dbe244423da5a632@>

David Abrahams wrote:

> It's only on broken compilers which don't support Koenig Lookup, and
> it's intentional. The negative impact should be limited due to the
> fact that these functions only operate on objects of type
> boost::python::self_ns::self_t. Do you anticipate a real problem with
> this?
> 

not more than a single line change. Quite manageable...:-)

Stefan




From seefeld at sympatico.ca  Thu Oct 10 18:09:47 2002
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 10 Oct 2002 12:09:47 -0400
Subject: [C++-sig] operators
References: <b1db87028f02b44c17173f6d60496f7e3da597ab@>
Message-ID: <6a40ccb7e395e8b654bc66f9999b5f273da5a7cb@>

hi there,

I'v defined 'std::ostream &operator << (std::ostream &, const Matrix &);'

and then def'ed 'str' as documented in the tutorial. Everything compiles
fine, but when I try to print my matrix, I get

RuntimeError: bad lexical cast: source type value could not be 
interpreted as target

What went wrong ?

Thanks,
		Stefan





From dave at boost-consulting.com  Thu Oct 10 19:00:14 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 10 Oct 2002 13:00:14 -0400
Subject: [C++-sig] operators
In-Reply-To: <6a40ccb7e395e8b654bc66f9999b5f273da5a7cb@>
References: <b1db87028f02b44c17173f6d60496f7e3da597ab@>
	<6a40ccb7e395e8b654bc66f9999b5f273da5a7cb@>
Message-ID: <uptuiqlep.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> hi there,
> 
> I'v defined 'std::ostream &operator << (std::ostream &, const Matrix &);'
> 
> and then def'ed 'str' as documented in the tutorial. Everything compiles
> fine, but when I try to print my matrix, I get
> 
> RuntimeError: bad lexical cast: source type value could not be
> interpreted as target
> 
> What went wrong ?

I don't know. Did you consult the lexical_cast documentation?

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From dave at boost-consulting.com  Thu Oct 10 20:06:10 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 10 Oct 2002 14:06:10 -0400
Subject: [C++-sig] numeric.hpp: copying raw data
In-Reply-To: <15780.54979.149104.744180@gull.eos.ubc.ca>
References: <OE35vbKmuyz9qcrO3lo0000c5ea@hotmail.com>
	<001001c26bfa$25be9c00$6701a8c0@boostconsulting.com>
	<15774.16189.157867.214799@gull.eos.ubc.ca>
	<00ed01c26c25$a4f25590$6701a8c0@boostconsulting.com>
	<15780.54979.149104.744180@gull.eos.ubc.ca>
Message-ID: <ud6qip3sd.fsf@boost-consulting.com>

Philip Austin <paustin at eos.ubc.ca> writes:

> I've been in touch with Todd Miller of the numarray group, and he says
> that they've moved towards complete API compatibility with Numeric
> (i.e. PyArrayObject->data can be used to get at a numarray object's
> data).  So the bottom line is that if boost::python::numeric could
> add zeros(shape,type) and/or ones(shape,type) to its interface,
> the wrapper is substantially complete.

I'll be very interested in your detailed suggestions for what should
be done after Boost 1.29.0 is released, which will probably be
tomorrow.

Thanks,
Dave

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From seefeld at sympatico.ca  Fri Oct 11 17:15:56 2002
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Fri, 11 Oct 2002 11:15:56 -0400
Subject: [C++-sig] operators
References: <b1db87028f02b44c17173f6d60496f7e3da597ab@>	<6a40ccb7e395e8b654bc66f9999b5f273da5a7cb@> <uptuiqlep.fsf@boost-consulting.com>
Message-ID: <b5a4b33641fb831d009038a525c04ab73da6ecce@>

David Abrahams wrote:

> I don't know. Did you consult the lexical_cast documentation?

well, the code :)

As I said, I'm writing a matrix. The lexical_cast code suggests
that the matrix is written to a stringstream, and then read out
with a single '>>' operation into a string. (the stringstream
should then be empty, so eof() is tested). This fails in my case
because the matrix output contains whitespace, so a single
string read will only generate one element.

I'm not sure I agree on the semantics of 'lexical_cast', i.e.
I don't think it is right to require that whatever is output
be readable as a single string.

But as it stands, I'll have to redefine an output format for
my matrix that doesn't contain spaces, just to make lexical_cast
happy.

Regards,
		Stefan







From dave at boost-consulting.com  Fri Oct 11 17:21:44 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 11 Oct 2002 11:21:44 -0400
Subject: [C++-sig] operators
In-Reply-To: <b5a4b33641fb831d009038a525c04ab73da6ecce@>
References: <b1db87028f02b44c17173f6d60496f7e3da597ab@>
	<6a40ccb7e395e8b654bc66f9999b5f273da5a7cb@>
	<uptuiqlep.fsf@boost-consulting.com>
	<b5a4b33641fb831d009038a525c04ab73da6ecce@>
Message-ID: <u7kgp9f1z.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> David Abrahams wrote:
> 
> > I don't know. Did you consult the lexical_cast documentation?
> 
> well, the code :)
> 
> As I said, I'm writing a matrix. The lexical_cast code suggests
> that the matrix is written to a stringstream, and then read out
> with a single '>>' operation into a string. (the stringstream
> should then be empty, so eof() is tested). This fails in my case
> because the matrix output contains whitespace, so a single
> string read will only generate one element.
> 
> I'm not sure I agree on the semantics of 'lexical_cast', i.e.
> I don't think it is right to require that whatever is output
> be readable as a single string.

You aren't the only one. Go to the boost webpage and search
lists.boost.org for lexical_cast to see lots of discussion.

Also see http://groups.yahoo.com/group/boost/files for at least two
proposals which attempt to improve the situation. The lexical_cast
maintainer is receptive, but for various reasons, the changes will
have to wait a little while.

> But as it stands, I'll have to redefine an output format for
> my matrix that doesn't contain spaces, just to make lexical_cast
> happy.

There are of course other ways to define a '__str__' method. 

But I guess I think that until lexical_cast is fixed, Boost.Python
ought to be doing something else. Probably just streaming into an
ostringstream and capturing the result would be a much better
solution. I'll happily accept a patch from you for Boost's main trunk.

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From dave at boost-consulting.com  Fri Oct 11 17:28:15 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 11 Oct 2002 11:28:15 -0400
Subject: [C++-sig] operators
In-Reply-To: <u7kgp9f1z.fsf@boost-consulting.com>
References: <b1db87028f02b44c17173f6d60496f7e3da597ab@>
	<6a40ccb7e395e8b654bc66f9999b5f273da5a7cb@>
	<uptuiqlep.fsf@boost-consulting.com>
	<b5a4b33641fb831d009038a525c04ab73da6ecce@>
	<u7kgp9f1z.fsf@boost-consulting.com>
Message-ID: <uvg49806o.fsf@boost-consulting.com>

David Abrahams <dave at boost-consulting.com> writes:

> There are of course other ways to define a '__str__' method. 

Meaning that you can write:

std::string str_my_thing(MyThing const&);

   class<MyThing>("MyThing)
      .def("__str__", str_my_thing)
      ;


-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From seefeld at sympatico.ca  Fri Oct 11 20:41:47 2002
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Fri, 11 Oct 2002 14:41:47 -0400
Subject: [C++-sig] seg fault on IRIX
References: <59589ca1ee8a2e827ca91bf4accf5f4e3da470e1@>
Message-ID: <9fe36b7a02c979fab88fc1cb51f9b39d3da71d14@>

Stefan Seefeld wrote:

> Bar *Foo_GetBar(Foo &foo)
> {
>    return foo.getBar();
> }
> 
> ...
> 
> python::class_<Foo, boost::noncopyable> foo("Foo", python::no_init);
> foo.def("getBar", Foo_GetBar, python::return_internal_reference<>());

could anybody please confirm that the above generates a segmentation 
fault when compiled and run on IRIX/mipspro ?

When I replace the return_internal_reference with

python::return_value_policy<python::manage_new_object>()

it doesn't crash any more (but it would ultimately crash whenever python 
happens to free the bar wrapper...)

Thanks,
		Stefan




From dave at boost-consulting.com  Fri Oct 11 20:49:20 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 11 Oct 2002 14:49:20 -0400
Subject: [C++-sig] seg fault on IRIX
In-Reply-To: <9fe36b7a02c979fab88fc1cb51f9b39d3da71d14@>
References: <59589ca1ee8a2e827ca91bf4accf5f4e3da470e1@>
	<9fe36b7a02c979fab88fc1cb51f9b39d3da71d14@>
Message-ID: <u65w8x13j.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> Stefan Seefeld wrote:
> 
> > Bar *Foo_GetBar(Foo &foo)
> > {
> >    return foo.getBar();
> > }
> > ...
> > python::class_<Foo, boost::noncopyable> foo("Foo", python::no_init);
> > foo.def("getBar", Foo_GetBar, python::return_internal_reference<>());
> 
> could anybody please confirm that the above generates a segmentation fault when compiled and run on
> IRIX/mipspro ?
> 
> When I replace the return_internal_reference with
> 
> python::return_value_policy<python::manage_new_object>()
> 
> it doesn't crash any more (but it would ultimately crash whenever python happens to free the bar
> wrapper...)

Stefan, I doubt anyone can help you if you don't provide complete
source code to your example, with a Python driver file.
-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From seefeld at sympatico.ca  Fri Oct 11 22:33:02 2002
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Fri, 11 Oct 2002 16:33:02 -0400
Subject: [C++-sig] seg fault on IRIX
References: <59589ca1ee8a2e827ca91bf4accf5f4e3da470e1@>	<9fe36b7a02c979fab88fc1cb51f9b39d3da71d14@> <u65w8x13j.fsf@boost-consulting.com>
Message-ID: <639c11d1cad538e8630892ae8d1f525f3da7372c@>

David Abrahams wrote:

> Stefan, I doubt anyone can help you if you don't provide complete
> source code to your example, with a Python driver file.

Indeed. I attached a self-contained program to the first mail in this
thread. I compiled it with:



CC -D_REENTRANT -I/usr/local/include 
-I/usr/local/include/boost/compatibility/cpp_c_headers 
-I/usr/local/include/python2.2 -mips4 -n32 -LANG:std -TARG:proc=r5000 
-fullwarn -woff 1424,1209,3201 -no_auto_include -woff 
1174,1234,1375,1506,3303 -c pfe.cc -o pfe.o


CC -shared -Wl,-no_unresolved -Wl,-LD_MSG:error=157 -mips4 -n32 
-LANG:std -TARG:proc=r5000 -o pfe.so pfe.o -L/usr/local/lib 
-lboost_python_debug -L/usr/local/lib/python2.2/config -lpython2.2 
-lpthread -lm

an then...

Python 2.2 (#1, Mar  4 2002, 08:53:03)
[GCC 2.95.3 20010315 (release)] on irix6
Type "help", "copyright", "credits" or "license" for more information.
 >>> import pfe
 >>> foo = pfe.Foo("bla")
 >>> bar = foo.getBar()
Segmentation fault (core dumped)

Stefan




From dave at boost-consulting.com  Fri Oct 11 22:43:53 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 11 Oct 2002 16:43:53 -0400
Subject: [C++-sig] seg fault on IRIX
In-Reply-To: <639c11d1cad538e8630892ae8d1f525f3da7372c@>
References: <59589ca1ee8a2e827ca91bf4accf5f4e3da470e1@>
	<9fe36b7a02c979fab88fc1cb51f9b39d3da71d14@>
	<u65w8x13j.fsf@boost-consulting.com>
	<639c11d1cad538e8630892ae8d1f525f3da7372c@>
Message-ID: <u4rbsk8om.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> David Abrahams wrote:
> 
> > Stefan, I doubt anyone can help you if you don't provide complete
> > source code to your example, with a Python driver file.
> 
> Indeed. I attached a self-contained program to the first mail in this
> thread. 

Sorry, I missed that. Well, your code looks OK to me...

> I compiled it with:
> 
> CC -D_REENTRANT -I/usr/local/include -I/usr/local/include/boost/compatibility/cpp_c_headers
> -I/usr/local/include/python2.2 -mips4 -n32 -LANG:std -TARG:proc=r5000 -fullwarn -woff 1424,1209,3201
> -no_auto_include -woff 1174,1234,1375,1506,3303 -c pfe.cc -o pfe.o
> 
> 
> CC -shared -Wl,-no_unresolved -Wl,-LD_MSG:error=157 -mips4 -n32 -LANG:std -TARG:proc=r5000 -o pfe.so
> pfe.o -L/usr/local/lib -lboost_python_debug -L/usr/local/lib/python2.2/config -lpython2.2 -lpthread -lm
> 
> an then...
> 
> Python 2.2 (#1, Mar  4 2002, 08:53:03)
> [GCC 2.95.3 20010315 (release)] on irix6
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> import pfe
>  >>> foo = pfe.Foo("bla")
>  >>> bar = foo.getBar()
> Segmentation fault (core dumped)

I have no clue. did you try this with Boost.Build? I have no idea
whether your compiler options are actually OK. At least if it worked
with Boost.Build that would be a pretty strong hint ;-)

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From seefeld at sympatico.ca  Fri Oct 11 23:45:07 2002
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Fri, 11 Oct 2002 17:45:07 -0400
Subject: [C++-sig] seg fault on IRIX
References: <59589ca1ee8a2e827ca91bf4accf5f4e3da470e1@>	<9fe36b7a02c979fab88fc1cb51f9b39d3da71d14@>	<u65w8x13j.fsf@boost-consulting.com>	<639c11d1cad538e8630892ae8d1f525f3da7372c@> <u4rbsk8om.fsf@boost-consulting.com>
Message-ID: <4607f9601d091e9eeeed7704d970557e3da7480f@>

David Abrahams wrote:

> I have no clue. did you try this with Boost.Build? I have no idea
> whether your compiler options are actually OK. At least if it worked
> with Boost.Build that would be a pretty strong hint ;-)

ok, I made some suitable modifications to getting_started2, and
it works. So the next step is to figure out in what way the
compiler options differ which you coded into the bjam build system.
I'll let you know, others might be interested, too...

Stefan







From robertoschler at hotmail.com  Sat Oct 12 14:46:16 2002
From: robertoschler at hotmail.com (Robert Oschler)
Date: Sat, 12 Oct 2002 08:46:16 -0400
Subject: [C++-sig] Zip or CVS for version 2?
Message-ID: <OE42VfdY6hlHK91rGGX00002dbb@hotmail.com>

I saw the good news that Boost Python vs 2 was available?  Is the combined total download file updated with Boost Python vs 2, or do I need to use CVS?

thx

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20021012/11bf108e/attachment.htm>

From dave at boost-consulting.com  Sat Oct 12 14:55:05 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 12 Oct 2002 08:55:05 -0400
Subject: [C++-sig] Zip or CVS for version 2?
In-Reply-To: <OE42VfdY6hlHK91rGGX00002dbb@hotmail.com>
References: <OE42VfdY6hlHK91rGGX00002dbb@hotmail.com>
Message-ID: <uwuon7r6e.fsf@boost-consulting.com>

"Robert Oschler" <robertoschler at hotmail.com> writes:

> I saw the good news that Boost Python vs 2 was available?? Is the
> combined total download file updated with Boost Python vs 2, or do I
> need to use CVS?

You don't need CVS. Just go to the Boost website and download Boost
1.29.0

Enjoy,
Dave

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From sashang at ihug.co.nz  Sun Oct 13 10:58:55 2002
From: sashang at ihug.co.nz (sashan)
Date: Sun, 13 Oct 2002 21:58:55 +1300
Subject: [C++-sig] compilation problems with mingw v2.0
References: <7625665.1031834837@dyn151.snm-hgkz.ch> <08ba01c25aa5$30430f00$6401a8c0@boostconsulting.com> <0a1301c25ab3$287f4370$6401a8c0@boostconsulting.com>
Message-ID: <3DA935CF.5020704@ihug.co.nz>

Hi

I know this thread is old but I'm getting similar link errors when using 
MinGW 2.0. I'm using the latest from cvs (deleted the contents of the 
boost directory and did a checkout) How did you get around this?  This 
is the command line I used to initiate the build:

bjam -sTOOLS=mingw -sBUILD=release -sMINGW_ROOT_DIRECTORY=d:\mingw

I can build Boost.Python fine with MSVC6.0.

Thanks

Sashan

>And now I have the compilation workaround on my disk, but there are
>inexplicable errors linking to Python-22.lib: it's having no problem
>linking to functions, but data objects like PyList_Type aare choking it.
>Can you build and link a simple "C" extension module with this compiler? It
>seems like something is very wrong here!
>
>c:\build\libs\python\bin\bpl.dll\mingw-2.0\debug\runtime-link-dynamic\list.
>obj: In function `ZN5boost6python4list4callERKNS0_3api6objectE':
>c:/boost/libs/python/test/../../../libs/python/src/list.cpp:12: undefined
>reference to `_imp__PyList_Type'
>c:\build\libs\python\bin\bpl.dll\mingw-2.0\debug\runtime-link-dynamic\list.
>obj: In function `ZN5boost6python4list6appendERKNS0_3api6objectE':
>c:/boost/libs/python/test/../../../libs/python/src/list.cpp:29: undefined
>reference to `_imp__PyList_Type'
>c:\build\libs\python\bin\bpl.dll\mingw-2.0\debug\runtime-link-dynamic\list.
>obj: In function `ZN5boost6python4list6insertEiRKNS0_3api6objectE':
>c:/boost/libs/python/test/../../../libs/python/src/list.cpp:65: undefined
>reference to `_imp__PyList_Type'
>c:\build\libs\python\bin\bpl.dll\mingw-2.0\debug\runtime-link-dynamic\list.
>obj: In function `ZN5boost6python4list7reverseEv':
>c:/boost/libs/python/test/../../../libs/python/src/list.cpp:106: undefined
>reference to `_imp__PyList_Type'
>c:\build\libs\python\bin\bpl.dll\mingw-2.0\debug\runtime-link-dynamic\list.
>obj: In function `ZN5boost6python4list4sortEv':
>c:/boost/libs/python/test/../../../libs/python/src/list.cpp:119: undefined
>reference to `_imp__PyList_Type'
>c:\build\libs\python\bin\bpl.dll\mingw-2.0\debug\runtime-link-dynamic\long.
>obj: In function `ZN5boost6python5long_4callERKNS0_3api6objectE':
>c:/boost/libs/python/test/../../../libs/python/src/long.cpp:12: undefined
>reference to `_imp__PyLong_Type'
>...
>  
>







From dave at boost-consulting.com  Sun Oct 13 14:22:56 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 13 Oct 2002 08:22:56 -0400
Subject: [C++-sig] compilation problems with mingw v2.0
In-Reply-To: <3DA935CF.5020704@ihug.co.nz>
References: <7625665.1031834837@dyn151.snm-hgkz.ch>
	<08ba01c25aa5$30430f00$6401a8c0@boostconsulting.com>
	<0a1301c25ab3$287f4370$6401a8c0@boostconsulting.com>
	<3DA935CF.5020704@ihug.co.nz>
Message-ID: <uvg46eden.fsf@boost-consulting.com>

sashan <sashang at ihug.co.nz> writes:

> Hi
> 
> I know this thread is old but I'm getting similar link errors when
> using MinGW 2.0. I'm using the latest from cvs (deleted the contents
> of the boost directory and did a checkout) How did you get around
> this?  This is the command line I used to initiate the build:
> 
> bjam -sTOOLS=mingw -sBUILD=release -sMINGW_ROOT_DIRECTORY=d:\mingw
> 
> I can build Boost.Python fine with MSVC6.0.
> 
> Thanks
> 
> Sashan

I uttered the magic incantations at:

  http://www.python.org/doc/current/inst/non-ms-compilers.html#SECTION000312000000000000000

HTH,
-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From eric at enthought.com  Mon Oct 14 14:15:34 2002
From: eric at enthought.com (eric jones)
Date: Mon, 14 Oct 2002 07:15:34 -0500
Subject: [C++-sig] compilation problems with mingw v2.0
In-Reply-To: <uvg46eden.fsf@boost-consulting.com>
Message-ID: <000001c2737b$68e75d40$8901a8c0@ERICDESKTOP>

We've handled this in SciPy by automating the process in
scipy_distutils.  The file scipy/scipy_distutils/mingw32support.py and
lib2def.py are used in the process.  Here is a (long) link to
mingw32support.py in our CVS.

http://www.scipy.org/site_content/remap?rmurl=http%3A//scipy.net/cgi-bin
/viewcvsx.cgi/scipy/scipy_distutils/mingw32_support.py%3Frev%3D1.7%26con
tent-type%3Dtext/vnd.viewcvs-markup

lib2def.py may not be as general as the solution mentioned on the web
page, but it works fine for all the Python's we've tested against.  We
did modify it some to make it work for any version of Python.  And,
since it is all pure Python and doesn't require any externally installed
binaries, perhaps something like it can be worked into the boost build
process.

On a related topic, I'm getting seg-faults when using weave with
Mingw2.0 (gcc 3.2) when running with the standard MSVC 6.0 compiled
Python.  Switch weave to using gcc 2.95.3 or MSVC 6.0 and all the
problems go away.

I haven't had a chance to investigate any further than knowing it is a
problem.  It sounds like boost is working fine which is a relief.  I was
worried that there was some irreconcilable MSVC-C vs. gcc3.2-C++ ABI
issue.

Eric

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org] On
Behalf
> Of David Abrahams
> Sent: Sunday, October 13, 2002 6:23 AM
> To: c++-sig at python.org
> Subject: Re: [C++-sig] compilation problems with mingw v2.0
> 
> sashan <sashang at ihug.co.nz> writes:
> 
> > Hi
> >
> > I know this thread is old but I'm getting similar link errors when
> > using MinGW 2.0. I'm using the latest from cvs (deleted the contents
> > of the boost directory and did a checkout) How did you get around
> > this?  This is the command line I used to initiate the build:
> >
> > bjam -sTOOLS=mingw -sBUILD=release -sMINGW_ROOT_DIRECTORY=d:\mingw
> >
> > I can build Boost.Python fine with MSVC6.0.
> >
> > Thanks
> >
> > Sashan
> 
> I uttered the magic incantations at:
> 
>   http://www.python.org/doc/current/inst/non-ms-
> compilers.html#SECTION000312000000000000000
> 
> HTH,
> --
>            David Abrahams * Boost Consulting
> dave at boost-consulting.com * http://www.boost-consulting.com
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig






From hoeppler at diener.iap.physik.uni-tuebingen.de  Tue Oct 15 13:08:15 2002
From: hoeppler at diener.iap.physik.uni-tuebingen.de (=?X-UNKNOWN?Q?Christian_H=F6ppler?=)
Date: Tue, 15 Oct 2002 13:08:15 +0200 (CEST)
Subject: [C++-sig] tutorial class_data_members compile problem
Message-ID: <Pine.LNX.4.33.0210151300270.17366-100000@diener.iap.physik.uni-tuebingen.de>

Hi,

Being new to boost::python, I've just tried to build the class Var of the
tutorial class_data_members.html.  However, I get the attached errors
unless I remove the 'const' access modifier from its member variable
'name'.  In that case everything works just fine.

What is the problem?

Thanks, Chris.

(system: gcc version 2.95.3 20010315 (SuSE), Python 2.2.1, boost_1_29_0)


~/boost_1_29_0/tools/build/jam_src/bin.linuxx86/bjam "-sTOOLS=gcc"
...found 1782 targets...
...updating 2 targets...
gcc-C++-action ../../../libs/python/my_project/bin/hello.so/gcc/debug/runtime-link-dynamic/shared-linkable-true/hello.o
/home/hoeppler/boost_1_29_0/boost/python/data_members.hpp: In function `static struct PyObject * boost::python::detail::member<const basic_string<char,string_char_traits<char>,__default_alloc_template<true,0> >,Var,boost::python::return_value_policy<boost::python::copy_non_const_reference,boost::python::default_call_policies> >::get(const string Var::*, PyObject *, PyObject *, const boost::python::return_value_policy<boost::python::copy_non_const_reference,boost::python::default_call_policies> &)':
/home/hoeppler/boost_1_29_0/boost/python/data_members.hpp:74:   instantiated from `boost::python::make_getter<Var, const string>(const string Var::*)'
/home/hoeppler/boost_1_29_0/boost/python/class.hpp:262:   instantiated from here/home/hoeppler/boost_1_29_0/boost/python/data_members.hpp:34: aggregate `struct boost::python::detail::copy_non_const_reference_expects_a_non_const_reference_return_type<const basic_string<char,string_char_traits<char>,__default_alloc_template<true,0> > &> cr' has incomplete type and cannot be initialized
/home/hoeppler/boost_1_29_0/boost/python/data_members.hpp:74:   instantiated from `boost::python::make_getter<Var, const string>(const string Var::*)'
/home/hoeppler/boost_1_29_0/boost/python/class.hpp:262:   instantiated from here
/home/hoeppler/boost_1_29_0/boost/python/data_members.hpp:39: `cr' cannot be used as a function

    g++  -c -Wall -ftemplate-depth-100  -DBOOST_PYTHON_DYNAMIC_LIB  -g -O0 -fno-inline -fPIC   -I"../../../libs/python/my_project"  -isystem "/usr/local/include/python2.2" -isystem "/home/hoeppler/boost_1_29_0"  -o "../../../libs/python/my_project/bin/hello.so/gcc/debug/runtime-link-dynamic/shared-linkable-true/hello.o"  "hello.cpp"

    ...failed gcc-C++-action ../../../libs/python/my_project/bin/hello.so/gcc/debug/runtime-link-dynamic/shared-linkable-true/hello.o...
    ...skipped <libs!python!my_project/hello.so/gcc/debug/runtime-link-dynamic/shared-linkable-true>hello.so for lack of <libs!python!my_project/hello.so/gcc/debug/runtime-link-dynamic/shared-linkable-true>hello.o...
    ...failed updating 1 target...
    ...skipped 1 target...




From dave at boost-consulting.com  Tue Oct 15 15:54:31 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 15 Oct 2002 09:54:31 -0400
Subject: [C++-sig] tutorial class_data_members compile problem
In-Reply-To: <Pine.LNX.4.33.0210151300270.17366-100000@diener.iap.physik.uni-tuebingen.de>
References: <Pine.LNX.4.33.0210151300270.17366-100000@diener.iap.physik.uni-tuebingen.de>
Message-ID: <ulm4zlsdk.fsf@boost-consulting.com>

Christian H?ppler <hoeppler at diener.iap.physik.uni-tuebingen.de> writes:

> Hi,
> 
> Being new to boost::python, I've just tried to build the class Var of the
> tutorial class_data_members.html.  However, I get the attached errors
> unless I remove the 'const' access modifier from its member variable
> 'name'.  In that case everything works just fine.
> 
> What is the problem?

The problem is that we have a bug ;-)
Thanks for reporting it. I'm working on a fix now.

-Dave

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From stefan.seefeld at orthosoft.ca  Tue Oct 15 16:33:29 2002
From: stefan.seefeld at orthosoft.ca (Stefan Seefeld)
Date: Tue, 15 Oct 2002 10:33:29 -0400
Subject: [C++-sig] compiler options and bjam
Message-ID: <c407e3356245ab7ff6d92084bf7e6c663dac296b@>

hi there,

is there any way to output the compiler / linker
options *actually* used with bjam ? I have a hard
time figuring out a bug I expect to be caused by
incompatible flags passed to mipspro, where my
own compile fails but bjam works just fine (it seems).

Thanks,
		Stefan




From Greg.Hawkins at softwire.co.uk  Tue Oct 15 16:41:21 2002
From: Greg.Hawkins at softwire.co.uk (Greg Hawkins)
Date: Tue, 15 Oct 2002 15:41:21 +0100
Subject: [C++-sig] compiler options and bjam
Message-ID: <616BE6A276E3714788D2AC35C40CD18D7CFE09@whale.softwire.co.uk>

You'll want to do 

bjam -d2

to see the actual commands issued by bjam.

best,
Greg

-----Original Message-----
From: Stefan Seefeld [mailto:stefan.seefeld at orthosoft.ca]
Sent: 15 October 2002 15:33
To: c++-sig at python.org
Subject: [C++-sig] compiler options and bjam


hi there,

is there any way to output the compiler / linker
options *actually* used with bjam ? I have a hard
time figuring out a bug I expect to be caused by
incompatible flags passed to mipspro, where my
own compile fails but bjam works just fine (it seems).

Thanks,
		Stefan


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



From Mark.Charsley at radioscape.com  Tue Oct 15 16:53:41 2002
From: Mark.Charsley at radioscape.com (Charsley, Mark)
Date: Tue, 15 Oct 2002 15:53:41 +0100
Subject: [C++-sig] boost 1.29, MSVC++ & precompiled headers
Message-ID: <3190BC9FA8F6D3119508009027E5B33EBA535E@MORSE>

If I include "boost/python.hpp" in a precompiled header in MSVC++ (SP5) and
try building it in debug mode, I get

<whole bunch ofC4275 warnings snipped>
z:\thirdparty\boost\boost\ref.hpp(48) : fatal error C1001: INTERNAL COMPILER
ERROR
        (compiler file 'msc1.cpp', line 1794) 
         Please choose the Technical Support command on the Visual C++ 
         Help menu, or open the Technical Support help file for more
information
Error executing cl.exe.

It works fine in release mode and fine if I include it in a normal .cpp file
outside of a precompiled header. Given how long it takes to compile
"boost/python.hpp", however, getting it working inside a precompiled header
would be _very_ nice. Anyone else seen this, and/or know of a fix?

TIA

-- 

Mark 


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
postmaster at radioscape.com.

This footnote also confirms that this email message has been scanned
for the presence of computer viruses known at the time of sending.

www.radioscape.com
**********************************************************************




From grafik666 at redshift-software.com  Tue Oct 15 17:19:25 2002
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Tue, 15 Oct 2002 10:19:25 -0500
Subject: [C++-sig] compiler options and bjam
In-Reply-To: <616BE6A276E3714788D2AC35C40CD18D7CFE09@whale.softwire.co.uk>
Message-ID: <20021015101926-r01010800-40c45644-0860-0108@12.100.89.43>

[2002-10-15] Greg Hawkins wrote:

>You'll want to do 
>
>bjam -d2
>
>to see the actual commands issued by bjam.

or "bjam -n" if you just want the commands without execution of them.


-- grafik - Don't Assume Anything
-- rrivera at acm.org - grafik at redshift-software.com
-- 102708583 at icq - Grafik666 at AIM - Grafik at jabber.org



From dave at boost-consulting.com  Tue Oct 15 17:26:15 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 15 Oct 2002 11:26:15 -0400
Subject: [C++-sig] compiler options and bjam
In-Reply-To: <c407e3356245ab7ff6d92084bf7e6c663dac296b@>
References: <c407e3356245ab7ff6d92084bf7e6c663dac296b@>
Message-ID: <uhefnhgfc.fsf@boost-consulting.com>

Stefan Seefeld <stefan.seefeld at orthosoft.ca> writes:

> hi there,
> 
> is there any way to output the compiler / linker
> options *actually* used with bjam ? I have a hard
> time figuring out a bug I expect to be caused by
> incompatible flags passed to mipspro, where my
> own compile fails but bjam works just fine (it seems).

Add -d+2 to the command-line before any targets.

Or use -n to suppress building anything; that will also write out the
build commands.

-a will cause everything to be rebuilt, so -n -a shows you all the
 build commands and exits.

HTH,
-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From greglandrum at mindspring.com  Tue Oct 15 17:25:54 2002
From: greglandrum at mindspring.com (greg Landrum)
Date: Tue, 15 Oct 2002 08:25:54 -0700
Subject: [C++-sig] boost 1.29, MSVC++ & precompiled headers
In-Reply-To: <3190BC9FA8F6D3119508009027E5B33EBA535E@MORSE>
Message-ID: <5.1.0.14.2.20021015082013.03d29bd0@mail.mindspring.com>

At 07:53 AM 10/15/2002, Charsley, Mark wrote:
>If I include "boost/python.hpp" in a precompiled header in MSVC++ (SP5) and
>try building it in debug mode, I get
>
><whole bunch ofC4275 warnings snipped>
>z:\thirdparty\boost\boost\ref.hpp(48) : fatal error C1001: INTERNAL COMPILER
>ERROR
>         (compiler file 'msc1.cpp', line 1794)
>          Please choose the Technical Support command on the Visual C++
>          Help menu, or open the Technical Support help file for more
>information
>Error executing cl.exe.
>
>It works fine in release mode and fine if I include it in a normal .cpp file
>outside of a precompiled header. Given how long it takes to compile
>"boost/python.hpp", however, getting it working inside a precompiled header
>would be _very_ nice. Anyone else seen this, and/or know of a fix?

In my use of Boost over the last year or so, these internal compiler errors 
happen pretty much constantly.  As you've already discovered, turning off 
precompiled headers or switching compilation modes can make them go away 
(but not always).  Sometimes switching the order of lines of code can clear 
them up.   Sometimes I haven't been able to solve the problem at all and 
have had to either give up or vastly restructure my code.

My simple-minded analysis is that the BPL really stresses C++ compilers and 
sometimes MSVC++ just falls down.

Good luck,
-greg




From dave at boost-consulting.com  Tue Oct 15 17:37:35 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 15 Oct 2002 11:37:35 -0400
Subject: [C++-sig] boost 1.29, MSVC++ & precompiled headers
In-Reply-To: <3190BC9FA8F6D3119508009027E5B33EBA535E@MORSE>
References: <3190BC9FA8F6D3119508009027E5B33EBA535E@MORSE>
Message-ID: <ubs5vhfwg.fsf@boost-consulting.com>

"Charsley, Mark" <Mark.Charsley at radioscape.com> writes:

> If I include "boost/python.hpp" in a precompiled header in MSVC++ (SP5) and
> try building it in debug mode, I get
> 
> <whole bunch ofC4275 warnings snipped>
> z:\thirdparty\boost\boost\ref.hpp(48) : fatal error C1001: INTERNAL COMPILER
> ERROR
>         (compiler file 'msc1.cpp', line 1794) 
>          Please choose the Technical Support command on the Visual C++ 
>          Help menu, or open the Technical Support help file for more
> information
> Error executing cl.exe.
> 
> It works fine in release mode and fine if I include it in a normal .cpp file
> outside of a precompiled header. Given how long it takes to compile
> "boost/python.hpp", however, getting it working inside a precompiled header
> would be _very_ nice. Anyone else seen this, and/or know of a fix?

Oh, there are about a billion known ways to get that compiler to
ICE. I think if you turn off "program database with edit and continue"
in your linker options, it might suppress this one. Otherwise, I
suggest asking your question in a Microsoft-specific forum. This is
not a Boost.Python specific question, and people are very likely to
have run across it before.

HTH,
-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From dave at boost-consulting.com  Tue Oct 15 17:39:21 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 15 Oct 2002 11:39:21 -0400
Subject: [C++-sig] tutorial class_data_members compile problem
In-Reply-To: <Pine.LNX.4.33.0210151300270.17366-100000@diener.iap.physik.uni-tuebingen.de>
References: <Pine.LNX.4.33.0210151300270.17366-100000@diener.iap.physik.uni-tuebingen.de>
Message-ID: <uelar7lue.fsf@boost-consulting.com>

Christian H?ppler <hoeppler at diener.iap.physik.uni-tuebingen.de> writes:

> Hi,
> 
> Being new to boost::python, I've just tried to build the class Var of the
> tutorial class_data_members.html.  However, I get the attached errors
> unless I remove the 'const' access modifier from its member variable
> 'name'.  In that case everything works just fine.
> 
> What is the problem?

Fixed now in CVS.
-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From hoeppler at diener.iap.physik.uni-tuebingen.de  Tue Oct 15 18:04:43 2002
From: hoeppler at diener.iap.physik.uni-tuebingen.de (Chris Hoeppler)
Date: Tue, 15 Oct 2002 18:04:43 +0200 (CEST)
Subject: [C++-sig] tutorial class_data_members compile problem
In-Reply-To: <uelar7lue.fsf@boost-consulting.com>
Message-ID: <Pine.LNX.4.33.0210151753150.17366-100000@diener.iap.physik.uni-tuebingen.de>

On 15 Oct 2002, David Abrahams wrote:

> Christian H?ppler <hoeppler at diener.iap.physik.uni-tuebingen.de> writes:
>
> > Hi,
> >
> > Being new to boost::python, I've just tried to build the class Var of the
> > tutorial class_data_members.html.  However, I get the attached errors
> > unless I remove the 'const' access modifier from its member variable
> > 'name'.  In that case everything works just fine.
> >
> > What is the problem?
>
> Fixed now in CVS.

Thanx.

Meanwhile I've gotten a little further in the tutorial and ran
into some other problems/questions/typos:


class_properties.html:

-> I think all occurrances of "&Var::" should be replaced by "&Num::"

class_virtual_functions.html:

* At the point where the first version of Base is used in Python:

      In Python, let us try to instantiate our Base class:

      >>> base = Base()
      AttributeError: ...

  -> I get a RuntimeError here

* continuing the example and trying to make an instance of the Python
  class Derived, I also get a:

  RuntimeError: This class cannot be instantiated from Python

* Further on, with the second version of Base and BaseWrap I have to
  include the boost::noncopyable parameter in the class_ template;
  otherwise it won't compile

* Finally, towards the end of the example,
  calling call_f(base) results in

  TypeError: bad argument type for built-in operation

  When rewriting that function as follows

    int call_f(Base *b) { return b->f(); }

  it works just fine.



TIA, Chris




From dave at boost-consulting.com  Tue Oct 15 18:14:34 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 15 Oct 2002 12:14:34 -0400
Subject: [C++-sig] tutorial class_data_members compile problem
In-Reply-To: <Pine.LNX.4.33.0210151753150.17366-100000@diener.iap.physik.uni-tuebingen.de>
References: <Pine.LNX.4.33.0210151753150.17366-100000@diener.iap.physik.uni-tuebingen.de>
Message-ID: <uit0365n9.fsf@boost-consulting.com>

Chris Hoeppler <hoeppler at diener.iap.physik.uni-tuebingen.de> writes:

> On 15 Oct 2002, David Abrahams wrote:
> 
> > Christian H?ppler <hoeppler at diener.iap.physik.uni-tuebingen.de> writes:
> >
> > > Hi,
> > >
> > > Being new to boost::python, I've just tried to build the class Var of the
> > > tutorial class_data_members.html.  However, I get the attached errors
> > > unless I remove the 'const' access modifier from its member variable
> > > 'name'.  In that case everything works just fine.
> > >
> > > What is the problem?
> >
> > Fixed now in CVS.
> 
> Thanx.
> 
> Meanwhile I've gotten a little further in the tutorial and ran
> into some other problems/questions/typos:
> 
> 
> class_properties.html:
> 
> -> I think all occurrances of "&Var::" should be replaced by "&Num::"
> 
> class_virtual_functions.html:
> 
> * At the point where the first version of Base is used in Python:
> 
>       In Python, let us try to instantiate our Base class:
> 
>       >>> base = Base()
>       AttributeError: ...
> 
>   -> I get a RuntimeError here
> 
> * continuing the example and trying to make an instance of the Python
>   class Derived, I also get a:
> 
>   RuntimeError: This class cannot be instantiated from Python

Right. It needs an __init__() function to suppress the Base class'
__init__. 


Hmm, I wonder if we should change that? It could check the object's
__class__ before raising that exception. That wouldn't prevent people
from instantiating subclasses that don't implement the pure virtual
functions, but that would be caught later by an AttributeError when
they try to call the function. Opinions?

> * Further on, with the second version of Base and BaseWrap I have to
>   include the boost::noncopyable parameter in the class_ template;
>   otherwise it won't compile

Hmm, good point.

> * Finally, towards the end of the example, calling call_f(base)
> results in
> 
>   TypeError: bad argument type for built-in operation


Hmm, that doen't sound right. What compiler/version are you using?

>   When rewriting that function as follows
> 
>     int call_f(Base *b) { return b->f(); }
> 
>   it works just fine.

Thanks,
-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From dave at boost-consulting.com  Tue Oct 15 18:33:00 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 15 Oct 2002 12:33:00 -0400
Subject: [C++-sig] tutorial class_data_members compile problem
In-Reply-To: <Pine.LNX.4.33.0210151753150.17366-100000@diener.iap.physik.uni-tuebingen.de>
References: <Pine.LNX.4.33.0210151753150.17366-100000@diener.iap.physik.uni-tuebingen.de>
Message-ID: <uzntf1x37.fsf@boost-consulting.com>

Chris Hoeppler <hoeppler at diener.iap.physik.uni-tuebingen.de> writes:

> * Finally, towards the end of the example,
>   calling call_f(base) results in
> 
>   TypeError: bad argument type for built-in operation
> 
>   When rewriting that function as follows
> 
>     int call_f(Base *b) { return b->f(); }
> 
>   it works just fine.

Yeah, I can't reproduce that problem. Here are a module and driver
file I used to try it out. Placing all three files below in your
$BOOST_ROOT/libs/python/user directory allows you to test it with

        bjam ... test

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test.cpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20021015/e2e37932/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test.py
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20021015/e2e37932/attachment-0001.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Jamfile
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20021015/e2e37932/attachment-0002.txt>
-------------- next part --------------

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com

From stefan.seefeld at orthosoft.ca  Tue Oct 15 19:21:16 2002
From: stefan.seefeld at orthosoft.ca (Stefan Seefeld)
Date: Tue, 15 Oct 2002 13:21:16 -0400
Subject: [C++-sig] Cross-extension-module dependencies
Message-ID: <b7e996d210de8ad0d1c3f327d08fc4503dac50c6@>

hi there,

the online docs talk about <boost/python/cross_module.hpp> etc.,
though I can't find that. Is this chapter of the docs still up to date ?

Stefan




From dave at boost-consulting.com  Tue Oct 15 19:46:18 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 15 Oct 2002 13:46:18 -0400
Subject: [C++-sig] Cross-extension-module dependencies
In-Reply-To: <b7e996d210de8ad0d1c3f327d08fc4503dac50c6@>
References: <b7e996d210de8ad0d1c3f327d08fc4503dac50c6@>
Message-ID: <u8z0z1tp1.fsf@boost-consulting.com>

Stefan Seefeld <stefan.seefeld at orthosoft.ca> writes:

> hi there,
> 
> the online docs talk about <boost/python/cross_module.hpp> etc.,

Where?

> though I can't find that. 

It's obsolete.

> Is this chapter of the docs still up to date ?

Which chapter?
-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From seefeld at sympatico.ca  Tue Oct 15 20:12:58 2002
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Tue, 15 Oct 2002 14:12:58 -0400
Subject: [C++-sig] Cross-extension-module dependencies
References: <b7e996d210de8ad0d1c3f327d08fc4503dac50c6@> <u8z0z1tp1.fsf@boost-consulting.com>
Message-ID: <bf9fde2eae070b669d29cd35adbb594e3dac5ce5@>

David Abrahams wrote:

> Where?

http://www.boost.org/libs/python/doc/cross_module.html

(though I can't remember what page linked to that)

If it's obsolete, does this mean there are no compile-time
dependencies any more among extension modules ? Is type
conversion done exclusively at run-time ?

Regards,
		Stefan




From dave at boost-consulting.com  Tue Oct 15 20:06:19 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 15 Oct 2002 14:06:19 -0400
Subject: [C++-sig] Cross-extension-module dependencies
In-Reply-To: <bf9fde2eae070b669d29cd35adbb594e3dac5ce5@>
References: <b7e996d210de8ad0d1c3f327d08fc4503dac50c6@>
	<u8z0z1tp1.fsf@boost-consulting.com>
	<bf9fde2eae070b669d29cd35adbb594e3dac5ce5@>
Message-ID: <uk7kjziec.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> David Abrahams wrote:
> 
> > Where?
> 
> http://www.boost.org/libs/python/doc/cross_module.html

Well, I don't know why that's on the website. It's not part of the
release branch. Beman?

> (though I can't remember what page linked to that)

I'd really like to know, if you can figure it out.

> If it's obsolete, does this mean there are no compile-time
> dependencies any more among extension modules ? 

Yes.

> Is type conversion done exclusively at run-time ?

Not exclusively. There are some types whose to-python conversion is
fixed at compile time (e.g. int, char const*, std::string, ...)

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From greglandrum at earthlink.net  Tue Oct 15 23:45:49 2002
From: greglandrum at earthlink.net (Greg Landrum)
Date: Tue, 15 Oct 2002 14:45:49 -0700
Subject: [C++-sig] BPL v2 and Exceptions
Message-ID: <5.1.0.14.2.20021015143352.03cc69c8@mail.earthlink.net>

[redhat 8.0, g++ 3.2, python 2.2.1]

Hi,

I'm in the process of porting some wrapped classes from BPL v1 to BPL v2 
(using Boost v1.29 and I've hit a major snag with exceptions causing crashes.

I've read through as much of the docs as I could make sense of as well as 
the last few months of this list and I haven't found much info that helps.

What I'm trying to do is throw python exceptions (e.g. IndexError) from my 
wrapped classes.

Here's the most simple-minded form of a module I can come up with:
//-------------------------------------------------------------------------
#include <boost/python.hpp>

#include <iostream>

namespace python = boost::python;

void throw_arg_error()
{
   std::cerr << "Ach!\n";
   python::throw_argument_error();
}

// A helper function for dealing with errors. Throw a Python ValueError
void throw_value_error(const std::string err)
{
   std::cerr << "Ach!\n";
   PyErr_SetString(PyExc_ValueError, err.c_str());
   python::throw_error_already_set();
}

void killme(){
   throw_arg_error();
}

BOOST_PYTHON_MODULE(except_test)
{
   python::def("throw_arg_error",throw_arg_error);
   python::def("throw_value_error",throw_value_error);
   python::def("killme",killme);
}
//-------------------------------------------------------------------------

when I build this module and try calling any of the three functions, python 
aborts.

Am I doing something horribly stupid, or is this just not ever going to work?

-greg
----
greg Landrum (greglandrum at earthlink.net)
Software Carpenter/Computational Chemist




From dave at boost-consulting.com  Tue Oct 15 23:53:49 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 15 Oct 2002 17:53:49 -0400
Subject: [C++-sig] BPL v2 and Exceptions
In-Reply-To: <5.1.0.14.2.20021015143352.03cc69c8@mail.earthlink.net>
References: <5.1.0.14.2.20021015143352.03cc69c8@mail.earthlink.net>
Message-ID: <uk7kj9xn6.fsf@boost-consulting.com>

Greg Landrum <greglandrum at earthlink.net> writes:

> [redhat 8.0, g++ 3.2, python 2.2.1]
> 
> Hi,
> 
> I'm in the process of porting some wrapped classes from BPL v1 to BPL
> v2 (using Boost v1.29 and I've hit a major snag with exceptions
> causing crashes.
> 
> I've read through as much of the docs as I could make sense of as well
> as the last few months of this list and I haven't found much info that
> helps.
> 
> What I'm trying to do is throw python exceptions (e.g. IndexError)
> from my wrapped classes.
> 
> Here's the most simple-minded form of a module I can come up with:
> //-------------------------------------------------------------------------
> #include <boost/python.hpp>
> 
> #include <iostream>
> 
> namespace python = boost::python;
> 
> void throw_arg_error()
> {
>    std::cerr << "Ach!\n";
>    python::throw_argument_error();

This is part of your problem. You shouldn't be using
throw_argument_error(). If that's in the docs, it shouldn't be. It's
not. Why are you using it?

[ of course that begs the question of why it's in this release at all;
it shouldn't be, and will be removed for the next one ]

On the other hand, it shouldn't cause a crash. At least, not by
itself. It should get translated into

    RuntimeError('unidentifiable C++ exception')

> }
> 
> // A helper function for dealing with errors. Throw a Python ValueError
> void throw_value_error(const std::string err)
> {
>    std::cerr << "Ach!\n";
>    PyErr_SetString(PyExc_ValueError, err.c_str());
>    python::throw_error_already_set();

This one's OK.
> }
> 
> void killme(){
>    throw_arg_error();
> }
> 
> BOOST_PYTHON_MODULE(except_test)
> {
>    python::def("throw_arg_error",throw_arg_error);
>    python::def("throw_value_error",throw_value_error);
>    python::def("killme",killme);
> }
> //-------------------------------------------------------------------------
> 
> when I build this module and try calling any of the three functions,
> python aborts.
> 
> Am I doing something horribly stupid, or is this just not ever going to work?

It's mostly not stupid. I'm not sure why it would be aborting. Do the
tests pass on your system? To find out, go to
$BOOST_ROOT/libs/python/test, and:

        bjam -sTOOLS=gcc test

If any tests fail, it will be apparent.
-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From greglandrum at mindspring.com  Wed Oct 16 00:21:13 2002
From: greglandrum at mindspring.com (greg Landrum)
Date: Tue, 15 Oct 2002 15:21:13 -0700
Subject: [C++-sig] BPL v2 and Exceptions
In-Reply-To: <uk7kj9xn6.fsf@boost-consulting.com>
References: <5.1.0.14.2.20021015143352.03cc69c8@mail.earthlink.net>
 <5.1.0.14.2.20021015143352.03cc69c8@mail.earthlink.net>
Message-ID: <5.1.0.14.2.20021015151039.03c8d338@mail.mindspring.com>

At 02:53 PM 10/15/2002, you wrote:
>Greg Landrum <greglandrum at earthlink.net> writes:
>
> > void throw_arg_error()
> > {
> >    std::cerr << "Ach!\n";
> >    python::throw_argument_error();
>
>This is part of your problem. You shouldn't be using
>throw_argument_error(). If that's in the docs, it shouldn't be. It's
>not. Why are you using it?

That's a pretty good question.  The answer is something along the lines of 
"I've been flailing at this for a couple hours and that managed to diffuse 
in at one point."  The actual call itself isn't terribly important, the 
next case was more what I wanted to be doing anyway:

> >
> > // A helper function for dealing with errors. Throw a Python ValueError
> > void throw_value_error(const std::string err)
> > {
> >    std::cerr << "Ach!\n";
> >    PyErr_SetString(PyExc_ValueError, err.c_str());
> >    python::throw_error_already_set();
>
>This one's OK.



>It's mostly not stupid. I'm not sure why it would be aborting. Do the
>tests pass on your system? To find out, go to
>$BOOST_ROOT/libs/python/test, and:
>
>         bjam -sTOOLS=gcc test
>If any tests fail, it will be apparent.

I ran the tests after installation and everything looked good.  I just 
tried them again to be sure and they still all pass.  Do any of the tests 
actually stress the PyErr_SetString method of throwing exceptions?  (I ask 
because a quick grep of the test source makes me think the answer is no).

-greg





From dave at boost-consulting.com  Wed Oct 16 00:25:00 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 15 Oct 2002 18:25:00 -0400
Subject: [C++-sig] BPL v2 and Exceptions
In-Reply-To: <5.1.0.14.2.20021015151039.03c8d338@mail.mindspring.com>
References: <5.1.0.14.2.20021015143352.03cc69c8@mail.earthlink.net>
	<5.1.0.14.2.20021015143352.03cc69c8@mail.earthlink.net>
	<5.1.0.14.2.20021015151039.03c8d338@mail.mindspring.com>
Message-ID: <usmz78hmr.fsf@boost-consulting.com>

greg Landrum <greglandrum at mindspring.com> writes:

> I ran the tests after installation and everything looked good.  I just
> tried them again to be sure and they still all pass.  Do any of the
> tests actually stress the PyErr_SetString method of throwing
> exceptions?  (I ask because a quick grep of the test source makes me
> think the answer is no).

Yes. exception_translator.cpp does.

The next steps are:

1. Run your test under gdb and get me a stacktrace of the crash.

2. Make me a small C++ test case and Python driver file so I can try
   to reproduce this.
-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From djowel at gmx.co.uk  Wed Oct 16 01:28:55 2002
From: djowel at gmx.co.uk (Joel de Guzman)
Date: Wed, 16 Oct 2002 07:28:55 +0800
Subject: [C++-sig] tutorial class_data_members compile problem
References: <Pine.LNX.4.33.0210151753150.17366-100000@diener.iap.physik.uni-tuebingen.de> <uzntf1x37.fsf@boost-consulting.com>
Message-ID: <009401c274a2$a66c8910$4c4ca7cb@kim>

----- Original Message ----- 
From: "David Abrahams" <dave at boost-consulting.com>


> Chris Hoeppler <hoeppler at diener.iap.physik.uni-tuebingen.de> writes:
> 
> > * Finally, towards the end of the example,
> >   calling call_f(base) results in
> > 
> >   TypeError: bad argument type for built-in operation
> > 
> >   When rewriting that function as follows
> > 
> >     int call_f(Base *b) { return b->f(); }
> > 
> >   it works just fine.
> 
> Yeah, I can't reproduce that problem. Here are a module and driver
> file I used to try it out. Placing all three files below in your
> $BOOST_ROOT/libs/python/user directory allows you to test it with
> 
>         bjam ... test

No problems here. I'll fix the tutorial appropriately.
--Joel





From djowel at gmx.co.uk  Wed Oct 16 01:33:58 2002
From: djowel at gmx.co.uk (Joel de Guzman)
Date: Wed, 16 Oct 2002 07:33:58 +0800
Subject: [C++-sig] tutorial class_data_members compile problem
References: <Pine.LNX.4.33.0210151753150.17366-100000@diener.iap.physik.uni-tuebingen.de> <uit0365n9.fsf@boost-consulting.com>
Message-ID: <009501c274a3$588ef3d0$4c4ca7cb@kim>

----- Original Message ----- 
From: "David Abrahams" <dave at boost-consulting.com>

> * continuing the example and trying to make an instance of the Python
>   class Derived, I also get a:
> 
>   RuntimeError: This class cannot be instantiated from Python

Right. It needs an __init__() function to suppress the Base class'
__init__. 


Hmm, I wonder if we should change that? It could check the object's
__class__ before raising that exception. That wouldn't prevent people
from instantiating subclasses that don't implement the pure virtual
functions, but that would be caught later by an AttributeError when
they try to call the function. Opinions?

-----------------------------
I think it's ok as it is. It will do more but the end result is the same right?
I'll wait for your conclusion and correct the tutorial appropriately.
--Joel







From dave at boost-consulting.com  Wed Oct 16 01:41:53 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 15 Oct 2002 19:41:53 -0400
Subject: [C++-sig] tutorial class_data_members compile problem
In-Reply-To: <009501c274a3$588ef3d0$4c4ca7cb@kim>
References: <Pine.LNX.4.33.0210151753150.17366-100000@diener.iap.physik.uni-tuebingen.de>
	<uit0365n9.fsf@boost-consulting.com>
	<009501c274a3$588ef3d0$4c4ca7cb@kim>
Message-ID: <u7kgj8e2m.fsf@boost-consulting.com>

"Joel de Guzman" <djowel at gmx.co.uk> writes:

> ----- Original Message ----- 
> From: "David Abrahams" <dave at boost-consulting.com>
> 
> > * continuing the example and trying to make an instance of the Python
> >   class Derived, I also get a:
> > 
> >   RuntimeError: This class cannot be instantiated from Python
> 
> Right. It needs an __init__() function to suppress the Base class'
> __init__. 
> 
> 
> Hmm, I wonder if we should change that? It could check the object's
> __class__ before raising that exception. That wouldn't prevent people
> from instantiating subclasses that don't implement the pure virtual
> functions, but that would be caught later by an AttributeError when
> they try to call the function. Opinions?
> 
> -----------------------------
>
> I think it's ok as it is. It will do more but the end result is the
> same right?

If we change it, users who subclass abstract base classes will not
have to implement an __init__ function just to shut the base class up.
However, as I think more about it, I think a more-drastic fix may be
needed. After all, it is the C++ init function which creates the C++
class instance, which is needed for obvious reasons. If you subclass
an abstract class Base in Python, it has to create an instance of the
class wrapper BaseWrap...

...so carrying this line of thinking a little further, the user has to
expose some accessible __init__ function for derived classes to
call. That will cover up the one which raises the Python exception
anyway, (I hope - but I think not, now... anyway, users don't have to
use no_init here) so I guess it's OK. It might be nice to have the
__init__ functions exposed by the user raise the Python exception if
the Python type is Base, but that doesn't look too achievable anyway
;-).

I hope you followed my twisty thinking above. If not, sorry.

> I'll wait for your conclusion and correct the tutorial appropriately.

Whatever you write is fine, as long as it's backed up by experimental
data ;-)

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From djowel at gmx.co.uk  Wed Oct 16 02:28:03 2002
From: djowel at gmx.co.uk (Joel de Guzman)
Date: Wed, 16 Oct 2002 08:28:03 +0800
Subject: [C++-sig] tutorial class_data_members compile problem
References: <Pine.LNX.4.33.0210151753150.17366-100000@diener.iap.physik.uni-tuebingen.de><uit0365n9.fsf@boost-consulting.com><009501c274a3$588ef3d0$4c4ca7cb@kim> <u7kgj8e2m.fsf@boost-consulting.com>
Message-ID: <00d901c274aa$e6d73100$4c4ca7cb@kim>

----- Original Message ----- 
From: "David Abrahams" <dave at boost-consulting.com>


> "Joel de Guzman" <djowel at gmx.co.uk> writes:
> 
> > ----- Original Message ----- 
> > From: "David Abrahams" <dave at boost-consulting.com>
> > 
> > > * continuing the example and trying to make an instance of the Python
> > >   class Derived, I also get a:
> > > 
> > >   RuntimeError: This class cannot be instantiated from Python
> > 
> > Right. It needs an __init__() function to suppress the Base class'
> > __init__. 
> > 
> > 
> > Hmm, I wonder if we should change that? It could check the object's
> > __class__ before raising that exception. That wouldn't prevent people
> > from instantiating subclasses that don't implement the pure virtual
> > functions, but that would be caught later by an AttributeError when
> > they try to call the function. Opinions?
> > 
> > -----------------------------
> >
> > I think it's ok as it is. It will do more but the end result is the
> > same right?
> 
> If we change it, users who subclass abstract base classes will not
> have to implement an __init__ function just to shut the base class up.
> However, as I think more about it, I think a more-drastic fix may be
> needed. After all, it is the C++ init function which creates the C++
> class instance, which is needed for obvious reasons. If you subclass
> an abstract class Base in Python, it has to create an instance of the
> class wrapper BaseWrap...
> 
> ...so carrying this line of thinking a little further, the user has to
> expose some accessible __init__ function for derived classes to
> call. That will cover up the one which raises the Python exception
> anyway, (I hope - but I think not, now... anyway, users don't have to
> use no_init here) so I guess it's OK. It might be nice to have the
> __init__ functions exposed by the user raise the Python exception if
> the Python type is Base, but that doesn't look too achievable anyway
> ;-).
> 
> I hope you followed my twisty thinking above. If not, sorry.

Oh I understood you. Well, at least I think I do ;-)
1) no_init  raises a Python RuntimeError exception 
2) no_init is always called when constructing
3) A user defined __init__ function for derived classes will bypass no_init  

> > I'll wait for your conclusion and correct the tutorial appropriately.
> 
> Whatever you write is fine, as long as it's backed up by experimental
> data ;-)

You can count on that-this time-for sure ;)  

--Joel






From rwgk at yahoo.com  Wed Oct 16 03:47:27 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 15 Oct 2002 18:47:27 -0700 (PDT)
Subject: [C++-sig] BPL v2 and Exceptions
In-Reply-To: <usmz78hmr.fsf@boost-consulting.com>
Message-ID: <20021016014727.4921.qmail@web20204.mail.yahoo.com>

Here is another thing to try:

import sys
if (sys.platform == "linux2"):
  if (hasattr(sys, "setdlopenflags")):
    sys.setdlopenflags(0x100|0x2)

I put this in all my __init__.py files (all my extensions are in packages, so
this is a very easy fix for me).

This assumes that dlopen()'ing with RTLD_GLOBAL (try man dlopen) does not lead
to name clashes in your environment.

See also:
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6629

Ralf


__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com



From dave at boost-consulting.com  Wed Oct 16 04:38:15 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 15 Oct 2002 22:38:15 -0400
Subject: [C++-sig] BPL v2 and Exceptions
In-Reply-To: <20021016014727.4921.qmail@web20204.mail.yahoo.com>
References: <20021016014727.4921.qmail@web20204.mail.yahoo.com>
Message-ID: <ud6qbw1k8.fsf@boost-consulting.com>

"Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:

> Here is another thing to try:
> 
> import sys
> if (sys.platform == "linux2"):
>   if (hasattr(sys, "setdlopenflags")):
>     sys.setdlopenflags(0x100|0x2)
> 
> I put this in all my __init__.py files (all my extensions are in packages, so
> this is a very easy fix for me).
> 
> This assumes that dlopen()'ing with RTLD_GLOBAL (try man dlopen) does not lead
> to name clashes in your environment.
> 
> See also:
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6629

I don't think that's an appropriate or neccessary fix in Greg's
case. IMO, this is a different sort of problem we're seeing, since it
works fine from within bjam...

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From hoeppler at diener.iap.physik.uni-tuebingen.de  Wed Oct 16 08:21:31 2002
From: hoeppler at diener.iap.physik.uni-tuebingen.de (Chris Hoeppler)
Date: Wed, 16 Oct 2002 08:21:31 +0200 (CEST)
Subject: [C++-sig] tutorial class_data_members compile problem
In-Reply-To: <uzntf1x37.fsf@boost-consulting.com>
Message-ID: <Pine.LNX.4.33.0210160817420.20762-100000@diener.iap.physik.uni-tuebingen.de>

On 15 Oct 2002, David Abrahams wrote:

> Chris Hoeppler <hoeppler at diener.iap.physik.uni-tuebingen.de> writes:
>
> > * Finally, towards the end of the example,
> >   calling call_f(base) results in
> >
> >   TypeError: bad argument type for built-in operation
> >
> >   When rewriting that function as follows
> >
> >     int call_f(Base *b) { return b->f(); }
> >
> >   it works just fine.
>
> Yeah, I can't reproduce that problem. Here are a module and driver
> file I used to try it out. Placing all three files below in your
> $BOOST_ROOT/libs/python/user directory allows you to test it with
>
>         bjam ... test

Thanks. Great, your files work here, as well. Hmmm. Even modifying them
such that they resemble what I did doesn't break them. Sorry. Maybe I got
some strange characters into my source file when copying/pasting from the
tutorial in my browser?

At any rate, problem solved.

Thanks again, Chris.




From stefan.seefeld at orthosoft.ca  Wed Oct 16 17:20:14 2002
From: stefan.seefeld at orthosoft.ca (Stefan Seefeld)
Date: Wed, 16 Oct 2002 11:20:14 -0400
Subject: [C++-sig] strange error
Message-ID: <36ecb1754aac0ccd1ee7dbfa323f48f03dad860d@>

hi there,

here is a (python) error I'v run across a couple of times
without understanding what it represents / comes from:

Traceback (most recent call last):
   File "<stdin>", line 1, in ?
TypeError: __repr__ returned non-string (type str)

It looks as if I called (implicitely at least) a string
conversion function but the __repr__ function didn't return
what it is supposed to: a string.

The most puzzling is now that I have defined a wrapper
for a C++ method 'void Foo::bar(...)', and this
error is printed when a call to 'foo' returns.
The internals of Foo::bar are not seen by python, and the
return value is void, where does a string conversion attempt
come into play here ?

Thanks,
		Stefan

PS: I even tried

r = foo.bar()
print type(r)

and then the 'print type(r)' would raise the above error...




From dave at boost-consulting.com  Wed Oct 16 17:15:39 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 16 Oct 2002 11:15:39 -0400
Subject: [C++-sig] strange error
In-Reply-To: <36ecb1754aac0ccd1ee7dbfa323f48f03dad860d@>
References: <36ecb1754aac0ccd1ee7dbfa323f48f03dad860d@>
Message-ID: <ulm4yct44.fsf@boost-consulting.com>

Stefan Seefeld <stefan.seefeld at orthosoft.ca> writes:

> hi there,
> 
> here is a (python) error I'v run across a couple of times
> without understanding what it represents / comes from:
> 
> Traceback (most recent call last):
>    File "<stdin>", line 1, in ?
> TypeError: __repr__ returned non-string (type str)
> 
> It looks as if I called (implicitely at least) a string
> conversion function but the __repr__ function didn't return
> what it is supposed to: a string.
> 
> The most puzzling is now that I have defined a wrapper
> for a C++ method 'void Foo::bar(...)', and this
> error is printed when a call to 'foo' returns.
> The internals of Foo::bar are not seen by python, and the
> return value is void, where does a string conversion attempt
> come into play here ?
> 
> Thanks,
> 		Stefan
> 
> PS: I even tried
> 
> r = foo.bar()
> print type(r)
> 
> and then the 'print type(r)' would raise the above error...

Can you post code which reproduces the problem?
A Jamfile, too, please, if possible.
-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com




From seefeld at sympatico.ca  Wed Oct 16 17:48:29 2002
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 16 Oct 2002 11:48:29 -0400
Subject: [C++-sig] strange error
References: <36ecb1754aac0ccd1ee7dbfa323f48f03dad860d@> <ulm4yct44.fsf@boost-consulting.com>
Message-ID: <da3557cd79c7a1ed6ed5eb9c85655a1d3dad8ca3@>

David Abrahams wrote:

> Can you post code which reproduces the problem?
> A Jamfile, too, please, if possible.

ok, attached is a trivial test that exhibits the
problem. As the whole thing is part of a much bigger
system, I use the integrated build system (autotools /
make based), i.e. there is no Jamfile. But here are
the compiler options I used:

to compile:

CC -DBOOST_PYTHON_DYNAMIC_LIB 
-I/usr/local/include/boost/compatibility/cpp_c_headers -D_REENTRANT 
-I/usr/local/include/python2.2 -I/usr/local/include -n32 -mips4 
-no_auto_include -LANG:std -O0 -OPT:Olimit=0 -OPT:IEEE_NaN_inf=ON -c -o 
test.o test.cc

and to link:

CC -shared -Wl,-no_unresolved -Wl,-LD_MSG:error=157 -n32 -mips4 
-no_auto_include -LANG:std -O0 -OPT:Olimit=0 -OPT:IEEE_NaN_inf=ON 
-L/usr/local/lib -L/usr/local/lib/python2.2/config -o test.so test.o 
-lboost_python -lpython2.2 -lpthread -lm

Stefan
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test.cc
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20021016/c3bec612/attachment.txt>

From dave at boost-consulting.com  Wed Oct 16 18:13:19 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 16 Oct 2002 12:13:19 -0400
Subject: [C++-sig] strange error
In-Reply-To: <da3557cd79c7a1ed6ed5eb9c85655a1d3dad8ca3@>
References: <36ecb1754aac0ccd1ee7dbfa323f48f03dad860d@>
	<ulm4yct44.fsf@boost-consulting.com>
	<da3557cd79c7a1ed6ed5eb9c85655a1d3dad8ca3@>
Message-ID: <u1y6qcqg0.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> David Abrahams wrote:
> 
> > Can you post code which reproduces the problem?
> > A Jamfile, too, please, if possible.
> 
> ok, attached is a trivial test that exhibits the
> problem. 

Surely you don't just get the problem by compiling and linking? What
Python do you have to execute?  My tests fail to reproduce your
problem. I can import the module and call the wrapped function. The
enclosed files can be unpacked to libs/python/test to demonstrate,
using bjam. I'm quite sure that your problem has to do with the build
system you're using, and nothing else... you can use "bjam -n -a test"
to view all of the build/test commands, so just make sure your build
system is doing the equivalent.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test.cpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20021016/8145f877/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test.py
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20021016/8145f877/attachment-0001.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Jamfile
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20021016/8145f877/attachment-0002.txt>
-------------- next part --------------


> As the whole thing is part of a much bigger
> system, I use the integrated build system (autotools /
> make based), i.e. there is no Jamfile. But here are
> the compiler options I used:



> to compile:
> 
> CC -DBOOST_PYTHON_DYNAMIC_LIB
> -I/usr/local/include/boost/compatibility/cpp_c_headers -D_REENTRANT
> -I/usr/local/include/python2.2 -I/usr/local/include -n32 -mips4
> -no_auto_include -LANG:std -O0 -OPT:Olimit=0 -OPT:IEEE_NaN_inf=ON -c
> -o
> test.o test.cc
> 
> and to link:
> 
> CC -shared -Wl,-no_unresolved -Wl,-LD_MSG:error=157 -n32 -mips4
> -no_auto_include -LANG:std -O0 -OPT:Olimit=0 -OPT:IEEE_NaN_inf=ON
> -L/usr/local/lib -L/usr/local/lib/python2.2/config -o test.so test.o
> -lboost_python -lpython2.2 -lpthread -lm
> 
> Stefan
> #include <boost/python/module.hpp>
> #include <boost/python/extract.hpp>
> #include <boost/python/list.hpp>
> #include <boost/python/scope.hpp>
> #include <boost/python/enum.hpp>
> #include <boost/python/class.hpp>
> #include <boost/python/return_internal_reference.hpp>
> #include <boost/python/manage_new_object.hpp>
> #include <boost/python/def.hpp>
> #include <boost/python/operators.hpp>
> #include <boost/python/detail/api_placeholder.hpp>
> 
> 
> #include <iostream>
> #include <fstream>
> #include <sstream>
> #include <memory>
> #include <string>
> 
> namespace python = boost::python;
> 
> namespace
> {
> void foo() {}
> }
> 
> BOOST_PYTHON_MODULE(test)
> {
>    python::def("foo", foo);
> }

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com

From dave at boost-consulting.com  Wed Oct 16 18:52:49 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 16 Oct 2002 12:52:49 -0400
Subject: [C++-sig] Building C/C++ extensions for Python
Message-ID: <uznte9vha.fsf@boost-consulting.com>

Enthought and Boost Consulting are proud to announce "Building C/C++
extensions for Python," an intense 3 day course taught by David
Beazley, David Abrahams, and Eric Jones, the lead authors of SWIG,
Boost.Python, and Weave.  This hands-on course is geared toward C/C++
programmers and teaches the start-to-finish process of exposing C/C++
libraries for use in Python.  Students are sure to benefit from this
opportunity to learn from three of the leading experts in the field.

The class teaches the fundamentals of designing and building Python
extensions and addresses the common problems that arise during the
process.  Boost.Python, SWIG, and Weave are central to the discussion,
and each is covered in depth.  Fundamental topics such as handling
reference counts and building Python 2.2 style extension types by hand
are also covered.  Other topics discussed include Pyrex, distributing
extensions using distutils, debugging extensions, and solving shared
library issues.

The course is divided equally between lectures and hands-on programming
sessions.  Users will need to bring either a Linux or a Windows
NT/2000/XP, network enabled, laptop to the class with Python 2.2 and a
C++ compiler installed for the programming sessions.  More information
about setup requirements is available at the website.

Space is limited. 

Website: http://www.enthought.com/training/building_extensions.html

Signup Information: 
Call (512) 536-1057 to reserve your place.

Dates:
December 9th, 10th, and 11th, 2002 (Monday through Wednesday)

Instruction Hours:
Instruction runs from 9am-9pm on the first two days (with breaks for
lunch, dinner, and between sessions), and 9am-6pm on the final day of
the class.

Location:
The Driskill Hotel 
www.driskillhotel.com
604 Brazos Street
Austin, Texas

The Driskill is conveniently located in the heart of downtown Austin.
And, yes, it has high speed internet connections in the guest rooms.

What's Included:
3 nights of lodging
All meals and snacks
Unlimited caffeinated drinks
Class materials
3 days of instruction 

Cost:
$2400.00 US.  

About the Authors:

David Beazley
David is an assistant professor in the Department of Computer Science at
the University of Chicago.  He has worked on Python extension building
since 1996 and is the creator of SWIG (www.swig.org).  He is also the
author of the "Python Essential Reference."  David holds a PhD in
Computer Science from the University of Utah.

David Abrahams
David is a founding member and moderator of Boost (www.boost.org) and
heads Boost Consulting, a company dedicated to providing professional
support and development services for the Boost C++ libraries and
associated tools. He has been an ANSI/ISO C++ committee member since
1996, when he contributed a theory, specification, and implementation of
exception handling for the C++ standard library. In his 14-year career
he has developed applications for the desktop and embedded devices in
the fields of music software, speech recognition, and circuit
simulation.  David holds a BSE in Computer Science from the University
of Pennsylvania.

Eric Jones
Eric has a broad background in engineering and software development and
leads Enthought's product engineering and software design.  Eric is a
lead developer on the SciPy (www.scipy.org) and Weave projects and has
taught numerous courses about Python and how to leverage it for
scientific computing.  Prior to co-founding Enthought, Eric worked in
the fields of numerical electromagnetics and genetic optimization.  Eric
holds a PhD degree in Electrical Engineering from Duke University.

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com

Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html




From greglandrum at mindspring.com  Wed Oct 16 20:56:02 2002
From: greglandrum at mindspring.com (greg Landrum)
Date: Wed, 16 Oct 2002 11:56:02 -0700
Subject: [C++-sig] supporting binary strings
Message-ID: <5.1.0.14.2.20021016114526.03ee7988@mail.earthlink.net>


The default string conversion behavior of BPLv2 truncates strings 
containing nulls.  BPLv1 did not do this (Python strings containing nulls 
were properly passed to the C++ layer).

I've made two small mods to change the behavior back.  A context diff for 
the changes is attached.

I'm not super comfortable with the new type conversion system yet, so I'm 
not 100% sure that my change from char* to string in the PyString converter 
isn't going to break things in other peoples' code (though all the tests 
pass for me).

-greg
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diffs.txt
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20021016/18deaa12/attachment.txt>

From dave at boost-consulting.com  Wed Oct 16 21:54:48 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 16 Oct 2002 15:54:48 -0400
Subject: [C++-sig] supporting binary strings
In-Reply-To: <5.1.0.14.2.20021016114526.03ee7988@mail.earthlink.net>
References: <5.1.0.14.2.20021016114526.03ee7988@mail.earthlink.net>
Message-ID: <uhefm5fcn.fsf@boost-consulting.com>

greg Landrum <greglandrum at mindspring.com> writes:

> The default string conversion behavior of BPLv2 truncates strings
> containing nulls.  BPLv1 did not do this (Python strings containing
> nulls were properly passed to the C++ layer).
> 
> I've made two small mods to change the behavior back.  A context diff
> for the changes is attached.

Your changes look reasonable to me. The ones in the .cpp file are not
the most efficient implementation possible, because two copies of the
C++ string will be created. A more-efficient implementation would not
be able to use the slot_rvalue_from_python scaffolding, though. I
think I'll apply your patch; we can optimize later if neccessary.

> I'm not super comfortable with the new type conversion system yet, so
> I'm not 100% sure that my change from char* to string in the PyString
> converter isn't going to break things in other peoples' code (though
> all the tests pass for me).

It certainly could, if they're somehow depending on the
zero-terminating behavior. However, I think that would just be wrong,
so you win this round ;-)

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com

Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html




From dave at boost-consulting.com  Wed Oct 16 22:12:36 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 16 Oct 2002 16:12:36 -0400
Subject: [C++-sig] supporting binary strings
In-Reply-To: <uhefm5fcn.fsf@boost-consulting.com>
References: <5.1.0.14.2.20021016114526.03ee7988@mail.earthlink.net>
	<uhefm5fcn.fsf@boost-consulting.com>
Message-ID: <uof9u2le3.fsf@boost-consulting.com>

David Abrahams <dave at boost-consulting.com> writes:

> greg Landrum <greglandrum at mindspring.com> writes:
> 
> > The default string conversion behavior of BPLv2 truncates strings
> > containing nulls.  BPLv1 did not do this (Python strings containing
> > nulls were properly passed to the C++ layer).
> > 
> > I've made two small mods to change the behavior back.  A context diff
> > for the changes is attached.
> 
> Your changes look reasonable to me. The ones in the .cpp file are not
> the most efficient implementation possible, because two copies of the
> C++ string will be created. A more-efficient implementation would not
> be able to use the slot_rvalue_from_python scaffolding, though. I
> think I'll apply your patch; we can optimize later if neccessary.

Done, including a test case.

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com

Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html




From seefeld at sympatico.ca  Wed Oct 16 22:32:04 2002
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 16 Oct 2002 16:32:04 -0400
Subject: [C++-sig] strange error
References: <36ecb1754aac0ccd1ee7dbfa323f48f03dad860d@>	<ulm4yct44.fsf@boost-consulting.com>	<da3557cd79c7a1ed6ed5eb9c85655a1d3dad8ca3@> <u1y6qcqg0.fsf@boost-consulting.com>
Message-ID: <c9af99882306a0bfb463572a8582c87b3dadcf22@>

Hi David,

thanks a lot for your patience...

I'm getting a bit closer to the origin of my trouble
(both with this python error as well as the segmentation
fault I reported the other day).

I'm not fully there yet, but the problem is related to the
way I link the module. For some reason bjam doesn't link
the examples (getting_started2.so, say) with -lpython, only
-lboost_python. As I seemingly need to link with that, too
(since otherwise I get unresolved symbols) I just added
'-lpython2.2' at the end of the link command as issued
by bjam -n "-sBUILD=<architecture>mips4", and things start
to go wrong. At one point I suddenly get the python error
when I run the module, at some other point I get the
segmentation fault. Does anybody have any clue as to what
goes on inside the linker here ? Why does the getting_started2
not need to be linked to -lpython ? Are all symbols resolved
inside -lboost_python ?


Thanks again,
		Stefan




From dave at boost-consulting.com  Wed Oct 16 23:12:04 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 16 Oct 2002 17:12:04 -0400
Subject: [C++-sig] strange error
In-Reply-To: <c9af99882306a0bfb463572a8582c87b3dadcf22@>
References: <36ecb1754aac0ccd1ee7dbfa323f48f03dad860d@>
	<ulm4yct44.fsf@boost-consulting.com>
	<da3557cd79c7a1ed6ed5eb9c85655a1d3dad8ca3@>
	<u1y6qcqg0.fsf@boost-consulting.com>
	<c9af99882306a0bfb463572a8582c87b3dadcf22@>
Message-ID: <uvg42142j.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> Hi David,
> 
> thanks a lot for your patience...
> 
> I'm getting a bit closer to the origin of my trouble
> (both with this python error as well as the segmentation
> fault I reported the other day).
> 
> I'm not fully there yet, but the problem is related to the
> way I link the module. For some reason bjam doesn't link
> the examples (getting_started2.so, say) with -lpython, only
> -lboost_python. 

That's because you're not supposed to under Linux (I got this straight
from Guido himself, BTW). The Python symbols are provided by the
Python executable, and if you link to the library you have duplicate
copies of all the symbols (in fact I don't know how you did this
without getting link errors).

> As I seemingly need to link with that, too (since otherwise I get
> unresolved symbols) I just added '-lpython2.2' at the end of the
> link command as issued by bjam -n "-sBUILD=<architecture>mips4", and
> things start to go wrong.

Ahh, you're doing this under IRIX? That could be a different story.
Note that Python has a bunch of different methods for getting dynamic
libraries to see its symbols. For example, on AIX a shared library
opened by dlopen does not have access to the executable's symbols, so
Python has dynload_aix to "push" the symbols into the shared
library. We hijacked that code to get Python's symbols into
libboost_python.so on AIX (see aix_module_init.cpp) by pretending to
be a Python module. However, we don't have to do anything like that on
IRIX so I'm suspicious that this isn't the problem.

> At one point I suddenly get the python error
> when I run the module, at some other point I get the
> segmentation fault. Does anybody have any clue as to what
> goes on inside the linker here ? Why does the getting_started2
> not need to be linked to -lpython ? Are all symbols resolved
> inside -lboost_python ?

I suggest you try building with the mipspro toolset and see what
command-lines you get. We have been testing with that toolset under
IRIX, but not with gcc... or you could look at:

    http://cci.lbl.gov/boost/results/1034780401/dailylog_irix_CC

Which shows the command-lines, so you don't have to try it yourself.

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com

Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html




From seefeld at sympatico.ca  Thu Oct 17 15:18:48 2002
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 17 Oct 2002 09:18:48 -0400
Subject: [C++-sig] strange error
References: <36ecb1754aac0ccd1ee7dbfa323f48f03dad860d@>	<ulm4yct44.fsf@boost-consulting.com>	<da3557cd79c7a1ed6ed5eb9c85655a1d3dad8ca3@> <u1y6qcqg0.fsf@boost-consulting.com> <c9af99882306a0bfb463572a8582c87b3dadcf22@>
Message-ID: <0f80d894d37aa3fe54c02ef4b423fe903daebb35@>

Hi David,

thanks for your reply. It gave me the missing link
to resolve the puzzle. The problem was indeed apparently
that the linker resolved symbols at link time that should
really be resolved at load time. At least now that I don't
link with -lpython any more both errors seem to be fixed.

Thanks a lot !

Stefan




From daniel.kottow at ipk.fhg.de  Thu Oct 17 18:32:49 2002
From: daniel.kottow at ipk.fhg.de (daniel)
Date: Thu, 17 Oct 2002 18:32:49 +0200
Subject: [C++-sig] MillerIndex example and other notes
Message-ID: <20021017183249.A11959@pasteur.mustererkennung>

hi,
and first of all congratulations to v2 boost.python - i feel it much 
easier to find my way around than in the previous version, specially due 
to the enhanced docs. thank you.

i would like to ask/comment some points i noticed when upgrading to v2 my 
first and certainly buggy version of a boosted c++ api:

let me start with the MillerIndex example filed in 
examples/do_it_yourself_convts.cpp of v1.
i guess this is very similar to the faq posted by ralf on c++ vs native 
python containers:
according to that, converrting MillerIndex to native python list would go 
like this:


/*************************************************************/

class MillerIndex {
  public:
    int v[3];
};

struct MillerIndex_to_python
{
   static PyObject* convert(MillerIndex const& mi)
   {
	boost::python::tuple result = make_tuple(mi.v[0],mi.v[1],mi.v[2]);
	return incref(result.ptr());
   }
}; 
struct MillerIndex_from_python
{
   MillerIndex_from_python()
   {
	boost::python::converter::registry
	  ::push_back(&convertible,&construct,
				  boost::python::type_id<MillerIndex>());
   }  
   static void* convertible(PyObject* obj_ptr)
   {
	if ( ! PySequence_Check(obj_ptr)) {
	  return 0;
	}

	if ( PySequence_Length(obj_ptr) != 3) {
	  return 0;
	}

	return obj_ptr; // if the input object is convertible
   }     
   static void construct(PyObject* obj_ptr,
						boost::python::converter
						 
::rvalue_from_python_stage1_data* data)
   {

	boost::python::tuple t = extract<boost::python::tuple>(obj_ptr);

	void* storage;
	storage = ((boost::python::converter
				 
::rvalue_from_python_storage<FloatVector>*)data)->storage.bytes;

	new (storage) MillerIndex;
	data->convertible = storage;

	MillerIndex& result = *((MillerIndex*)storage);

	for(int i=0;i<3;++i) {
	  result.v[i] = extract<int>(t[i]); //checking omitted
	}
   }
};

/*************************************************************/

IMHO this is pretty long and a bit akward, at least the from_python part.
is their a more easy way of doing this ? or is this usage of boost.python 
disencouraged ?

------

extract<>() and the object class seemed to me really nice, enhancing 
features.

i think i misunderstood the tutorial when it talks about instantiating 
class_<T> objects, though.
according to it, i thought it was necessary to write down the class_>T> 
"declaration" just as if you were exposing the class to python but finally 
calling the constructor
(http://www.boost.org/libs/python/doc/tutorial/doc/derived_object_types.html)

but if you already registered a certain class_<T> in the module,
you can instantiate python-objects from c++ of that type just by writing:
object(T()); (i tried to create an instance by "re-declaring" class_<T> in 
my code and i got a registration error at execution time, saying:

python: libs/python/src/converter/registry.cpp:74: void 
boost::python::converter::registry::insert(PyObject*(*)(const void*), 
boost::python::type_info): Assertion `slot == 0' failed

another thing which i have not really played much with is about the 
reference counting. as long as you stay in the upper levels, exporting 
classes with class_<T> and using object/tuple/list etc. this is perfectly 
hidden, very nice. but if you have to write these converter things by 
hand, i would like to know how to get them back into the "boost refernce 
counting".

e.g. if i have: 
PyObject *obj = createObjectFromTheTimesWhereBoostWasNotBorn();
{
	return Py_BuildValue("iii", 1,2,3);
}

how could i incorporate this using boost::python::def() ?


greetings, daniel

-- 
Daniel Kottow                                    daniel.kottow at ipk.fhg.de
Security and Testing Technology                  
http://vision.fhg.de/~daniel
Production Technology Centre                     Pascalstr. 8 - 9
Fraunhofer-Institut IPK Berlin                   D - 10587 Berlin





From dave at boost-consulting.com  Thu Oct 17 18:43:47 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 17 Oct 2002 12:43:47 -0400
Subject: [C++-sig] MillerIndex example and other notes
In-Reply-To: <20021017183249.A11959@pasteur.mustererkennung>
References: <20021017183249.A11959@pasteur.mustererkennung>
Message-ID: <uzntdm2ws.fsf@boost-consulting.com>

daniel <daniel.kottow at ipk.fhg.de> writes:

> Hi,
> and first of all congratulations to v2 boost.python - i feel it much
> easier to find my way around than in the previous version, specially
> due to the enhanced docs. thank you.

You're welcome!

> I would like to ask/comment some points i noticed when upgrading to v2
> my first and certainly buggy version of a boosted c++ api:
> 
> Let me start with the MillerIndex example filed in
> examples/do_it_yourself_convts.cpp of v1.
> I guess this is very similar to the faq posted by ralf on c++ vs
> native python containers:
> according to that, converrting MillerIndex to native python list would
> go like this:
> 

<snip> 

> IMHO this is pretty long and a bit akward, at least the from_python part.
> Is their a more easy way of doing this ? Or is this usage of
> boost.python disencouraged ?

It's not discouraged exactly... but it's not really yet part of the
public interface to the library. I wasn't ready to expose this part of
the library to users yet, well, in part because as you say it's pretty
long and a bit awkward. Also because the low-level interfaces may need
to change to cover things like converters with "write-back"
(e.g. conversion from a Python list to a mutable MillerIndex
reference, which converts back to the list after the call).

So we have the following plans:

  - Simplify and prepare the low-level conversion interfaces for
    public consumption, after implementing "write-back" converters.

  - Get Ralf's container conversion code into the library itself and
    make it easy to write these conversions

> ------
> 
> extract<>() and the object class seemed to me really nice, enhancing
> features.
> 
> I think i misunderstood the tutorial when it talks about
> instantiating class_<T> objects, though.  According to it, i thought
> it was necessary to write down the class_<T> "declaration" just as
> if you were exposing the class to python but finally calling the
> constructor
> (http://www.boost.org/libs/python/doc/tutorial/doc/derived_object_types.html)

Only if T doesn't have a copy-constructor.

> But if you already registered a certain class_<T> in the module, you
> can instantiate python-objects from c++ of that type just by
> writing: object(T());

But if you do this, you don't have a pointer or reference to the C++ T
object held by the object.

If you do:

   T& x = T();
   object o(x);

then you still don't, since x gets copied.

You could do this, though:

  T& y = extract<T&>(o);

But then you've still paid to build an extra instance of T, and T must
be copy-constructible so it can be wrapped.

> (i tried to create an instance by "re-declaring" class_<T> in my
> code and i got a registration error at execution time, saying:
>
> Python: libs/python/src/converter/registry.cpp:74: void
> boost::python::converter::registry::insert(PyObject*(*)(const void*),
> boost::python::type_info): Assertion `slot == 0' failed

Yep, that would be a bad idea.

> Another thing which i have not really played much with is about the
> reference counting. as long as you stay in the upper levels,
> exporting classes with class_<T> and using object/tuple/list
> etc. this is perfectly hidden, very nice. but if you have to write
> these converter things by hand, i would like to know how to get them
> back into the "boost refernce counting".
> 
> E.g. if i have: PyObject *obj =
> createObjectFromTheTimesWhereBoostWasNotBorn();
> {
> 	return Py_BuildValue("iii", 1,2,3);
> }

I think you must mean:

PyObject* createObjectFromTheTimesWhereBoostWasNotBorn()
{
    return Py_BuildValue("iii", 1,2,3);
}

> How could i incorporate this using boost::python::def() ?

Nothing to it:

   def("create", createObjectFromTheTimesWhereBoostWasNotBorn);

HTH,
-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com

Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html




From rwgk at yahoo.com  Thu Oct 17 19:37:24 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 17 Oct 2002 10:37:24 -0700 (PDT)
Subject: [C++-sig] MillerIndex example and other notes
In-Reply-To: <20021017183249.A11959@pasteur.mustererkennung>
Message-ID: <20021017173724.47851.qmail@web20202.mail.yahoo.com>

--- daniel <daniel.kottow at ipk.fhg.de> wrote:
> class MillerIndex {
>   public:
>     int v[3];
> };

This example is from the first days of my C++ experience. These days
it would be more like:

class MillerIndex : boost::array<int, 3>
{
  // some stuff here
};

or simply

typedef boost::array<int, 3> MillerIndex;

Either way you will be able to directly use the higher-level interface in
#include <scitbx/boost_python/container_conversions.h>:

scitbx::boost_python::container_conversions::tuple_mapping_fixed_size<MillerIndex>();

That's all.

The include file has no dependencies other than Boost.Python itself.
You can copy it directly from CVS to your own include tree:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/scitbx/include/scitbx/boost_python/

Hey David, why don't you copy the file to, say,

boost/boost/python/contrib/container_conversions.h

Then I wouldn't have to manufacture these horribly long links all the time.
I could delete it from the scitbx tree and maintain it in the boost tree.

Ralf






From dave at boost-consulting.com  Thu Oct 17 19:34:07 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 17 Oct 2002 13:34:07 -0400
Subject: [C++-sig] MillerIndex example and other notes
In-Reply-To: <20021017173724.47851.qmail@web20202.mail.yahoo.com>
References: <20021017173724.47851.qmail@web20202.mail.yahoo.com>
Message-ID: <ufzv5m0kw.fsf@boost-consulting.com>

"Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:

> Hey David, why don't you copy the file to, say,
> 
> boost/boost/python/contrib/container_conversions.h
> 
> Then I wouldn't have to manufacture these horribly long links all
> the time.  I could delete it from the scitbx tree and maintain it in
> the boost tree.

Because I figure if I make it sufficiently uncomfortable for you,
you'll write some documentation so I can incorporate it directly and I
won't need a contrib/ directory ;-)

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com

Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html




From stefan.seefeld at orthosoft.ca  Thu Oct 17 21:59:06 2002
From: stefan.seefeld at orthosoft.ca (Stefan Seefeld)
Date: Thu, 17 Oct 2002 15:59:06 -0400
Subject: [C++-sig] call policies
Message-ID: <bea90007017200f96d981334ba3521e03daf1905@>

hi there,

I'm reading up on call policies but I'm not sure my case is
covered there:

I'v got an object handed back from a factory call. I pass
this object to another object where the second one takes
over ownership:

Foo *foo = FooFactory();
Bar *bar = BarFactory(foo);

(with either

Bar *BarFactory(Foo *);

or

Bar *BarFactory(auto_ptr<Foo>);

signature. How do I express that in boost.python ? The
'custody_and_wart' policy expects two arguments, the object
to be consumed as well as the consuming one. In my case
the consumer is created in the call. Which policy do I need ?

Thanks,
		Stefan




From dave at boost-consulting.com  Thu Oct 17 22:03:52 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 17 Oct 2002 16:03:52 -0400
Subject: [C++-sig] call policies
In-Reply-To: <bea90007017200f96d981334ba3521e03daf1905@>
References: <bea90007017200f96d981334ba3521e03daf1905@>
Message-ID: <ud6q8bzo7.fsf@boost-consulting.com>

Stefan Seefeld <stefan.seefeld at orthosoft.ca> writes:

> hi there,
> 
> I'm reading up on call policies but I'm not sure my case is
> covered there:
> 
> I'v got an object handed back from a factory call. I pass
> this object to another object where the second one takes
> over ownership:
> 
> Foo *foo = FooFactory();
> Bar *bar = BarFactory(foo);
> 
> (with either
> 
> Bar *BarFactory(Foo *);
> 
> or
> 
> Bar *BarFactory(auto_ptr<Foo>);
> 
> signature. How do I express that in boost.python ? The
> 'custody_and_wart' policy expects two arguments, the object
   ^^^^^^^^^^^^^^^^

A very interesting re-spelling, to be sure!

> to be consumed as well as the consuming one. In my case
> the consumer is created in the call. Which policy do I need ?

Well, there's no provision in any of the CallPolicy models for
handing ownership for your C++ object away from a Python object. Think
about it: the C++ object is embedded inside some Python object. How do
you wrest its lifetime management away from that object? You can't.

However, if your C++ object is held by smart pointer, you can get
shared or sole ownership back from the Python object. So for example,
if you declare your Foo class_<> with auto_ptr<Foo> as its Holder, the
corresponding Python object can be passed to a wrapped function which
expects an auto_ptr<Foo> argument (which will cause the Python object
to lose ownership), and your FooFactory function can return
auto_ptr<Foo>. I suggested that FooFactory returns auto_ptr<Foo>
explicitly, because manage_new_object uses boost::shared_ptr<> as a
workaround for one broken compiler (Intel C++ 5), though
manage_new_object would work find for any other compiler.

   Bar* BarFactory(std::auto_ptr<Foo> foo);

   class_<Foo, std::auto_ptr<Foo> >("Foo")
        ...
        ;


HTH,
Dave

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com

Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html




From seefeld at sympatico.ca  Thu Oct 17 22:18:53 2002
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 17 Oct 2002 16:18:53 -0400
Subject: [C++-sig] call policies
References: <bea90007017200f96d981334ba3521e03daf1905@> <ud6q8bzo7.fsf@boost-consulting.com>
Message-ID: <9c7c4fe781e69e3f684285ae90a2976c3daf1dac@>

David Abrahams wrote:

>>signature. How do I express that in boost.python ? The
>>'custody_and_wart' policy expects two arguments, the object
> 
>    ^^^^^^^^^^^^^^^^
> 
> A very interesting re-spelling, to be sure!

oups, what a slip ! :-)


>    Bar* BarFactory(std::auto_ptr<Foo> foo);
> 
>    class_<Foo, std::auto_ptr<Foo> >("Foo")
>         ...
>         ;

thanks, that sounds very reasonable !

Stefan







From greglandrum at mindspring.com  Fri Oct 18 04:16:41 2002
From: greglandrum at mindspring.com (greg landrum)
Date: 17 Oct 2002 19:16:41 -0700
Subject: [C++-sig] type converters and a g++ bug
Message-ID: <1034907402.1141.13.camel@badger.rationaldiscovery.com>

[Redhat 8.0, g++ 3.2, python 2.2, boost 1.29.0]

I'm in the process of trying to get my brain around the new type
conversion system in BPLv2 (it's definitely a lot more complex than the
one in v1) and I hit this little beauty.

The attached code snippet causes g++ to seg fault most beautifully:

-----------------
convert2.cpp: In function `PyObject* foof(int)':
convert2.cpp:13: internal error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://bugzilla.redhat.com/bugzilla/> for instructions.
-----------------

The bad actor appears to be to_python_value

Before i worry about the fact that I'm killing the compiler, I wanted to
check that I am doing something reasonable.

This snippet is the core of an attempt I was making for a general
purpose converter which takes std::vectors on the C++ side and returns
them to python as tuples.

In BPLv1, I used something like this:
-----------------
template <typename T>
  PyObject* to_python(std::vector<T> p)
  {
    int l=p.end()-p.begin();
    typename std::vector<T>::iterator i;
    int idx;
    PyObject *res=PyTuple_New(l);
    for(i=p.begin(),idx=0;i!=p.end();i++,idx++){
      PyTuple_SetItem(res,idx,to_python(*i));
    }
    // FIX: is this needed?
    Py_INCREF(res);
    return res;
  }
-----------------
which, though not pretty, was perfectly functional.

Is there a straightforward equivalent to this in BPLv2?

Thanks,
-greg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: convert2.cpp
Type: text/x-c++
Size: 411 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20021017/182bbd9b/attachment.bin>

From greglandrum at mindspring.com  Fri Oct 18 03:33:40 2002
From: greglandrum at mindspring.com (greg Landrum)
Date: Thu, 17 Oct 2002 18:33:40 -0700
Subject: [C++-sig] type converters and a g++ bug
In-Reply-To: <1034907402.1141.13.camel@badger.rationaldiscovery.com>
Message-ID: <5.1.0.14.2.20021017183233.03210cf0@mail.mindspring.com>

At 07:16 PM 10/17/2002, greg landrum wrote:

>Is there a straightforward equivalent to this in BPLv2?

ah!  I have discovered the joys of Ralf's scitbx stuff and and answered my 
own question!

-greg




From dave at boost-consulting.com  Fri Oct 18 17:03:14 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 18 Oct 2002 11:03:14 -0400
Subject: [C++-sig] type converters and a g++ bug
In-Reply-To: <1034907402.1141.13.camel@badger.rationaldiscovery.com>
References: <1034907402.1141.13.camel@badger.rationaldiscovery.com>
Message-ID: <ubs5rx00d.fsf@boost-consulting.com>

greg landrum <greglandrum at mindspring.com> writes:

> [Redhat 8.0, g++ 3.2, python 2.2, boost 1.29.0]
> 
> I'm in the process of trying to get my brain around the new type
> conversion system in BPLv2 (it's definitely a lot more complex than the
> one in v1) and I hit this little beauty.
> 
> The attached code snippet causes g++ to seg fault most beautifully:
> 
> -----------------
> convert2.cpp: In function `PyObject* foof(int)':
> convert2.cpp:13: internal error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://bugzilla.redhat.com/bugzilla/> for instructions.
> -----------------
> 
> The bad actor appears to be to_python_value
> 
> Before i worry about the fact that I'm killing the compiler

I'm worried about it. Have you submitted a bug report?


> I wanted to check that I am doing something reasonable.

I'm afraid that you weren't. Still, I'm worried about the compiler
bug. Please please please submit a bug report!

Thanks,
-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com

Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html




From seefeld at sympatico.ca  Fri Oct 18 17:56:59 2002
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Fri, 18 Oct 2002 11:56:59 -0400
Subject: [C++-sig] call policies
References: <bea90007017200f96d981334ba3521e03daf1905@> <ud6q8bzo7.fsf@boost-consulting.com>
Message-ID: <3374756ffe84cb575f4ae0b427a781ce3db031e4@>

David Abrahams wrote:

>    Bar* BarFactory(std::auto_ptr<Foo> foo);
> 
>    class_<Foo, std::auto_ptr<Foo> >("Foo")
>         ...
>         ;

I'm trying to do what you suggest, with some additional parameters:

----

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

#include <memory>

namespace python = boost::python;

namespace
{

class Bar {};

}

BOOST_PYTHON_MODULE(pfe)
{
    python::class_<Bar,
                   std::auto_ptr<Bar>,
                   boost::noncopyable> bar("Bar", python::no_init);

}

----

I copied that over 'getting_started2.cc and run
bjam "-sBUILD=<architecture>mips4" (with TOOLS=mipspro).

This results in the error message

cc-1306 CC: ERROR File = 
/homes/Developer/sseefel/boost/boost/python/object/make_instance.hpp, 
Line = 60
   Class "std::auto_ptr<<unnamed>::Bar>" has no copy constructor to copy 
a const
           object.

           return new ((void*)&result->storage) Holder(x);

...

what is wrong ? I guess it's either boost:noncopyable or python::no_init
though I don't see why that should be wrong.

Thanks,
		Stefan




From dave at boost-consulting.com  Fri Oct 18 18:19:47 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 18 Oct 2002 12:19:47 -0400
Subject: [C++-sig] call policies
In-Reply-To: <3374756ffe84cb575f4ae0b427a781ce3db031e4@>
References: <bea90007017200f96d981334ba3521e03daf1905@>
	<ud6q8bzo7.fsf@boost-consulting.com>
	<3374756ffe84cb575f4ae0b427a781ce3db031e4@>
Message-ID: <u8z0vvhwc.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

Stefan,

I think this is my fault. As you probably know, std::auto_ptr<>'s copy
constructor is weird: it takes a non-const RHS. I think I must've
failed to account for that. I'll look into providing a patch for this
case today.

Sorry,
Dave

> David Abrahams wrote:
> 
> >    Bar* BarFactory(std::auto_ptr<Foo> foo);
> >    class_<Foo, std::auto_ptr<Foo> >("Foo")
> >         ...
> >         ;
> 
> I'm trying to do what you suggest, with some additional parameters:
> 
> ----
> 
> #include <boost/python/module.hpp>
> #include <boost/python/class.hpp>
> #include <boost/python/def.hpp>
> 
> #include <memory>
> 
> namespace python = boost::python;
> 
> namespace
> {
> 
> class Bar {};
> 
> }
> 
> BOOST_PYTHON_MODULE(pfe)
> {
>     python::class_<Bar,
>                    std::auto_ptr<Bar>,
>                    boost::noncopyable> bar("Bar", python::no_init);
> 
> }
> 
> ----
> 
> I copied that over 'getting_started2.cc and run
> bjam "-sBUILD=<architecture>mips4" (with TOOLS=mipspro).
> 
> This results in the error message
> 
> cc-1306 CC: ERROR File =
> /homes/Developer/sseefel/boost/boost/python/object/make_instance.hpp,
> Line = 60
>    Class "std::auto_ptr<<unnamed>::Bar>" has no copy constructor to
> copy a const
>            object.
> 
>            return new ((void*)&result->storage) Holder(x);
> 
> ...
> 
> what is wrong ? I guess it's either boost:noncopyable or python::no_init
> though I don't see why that should be wrong.
> 
> Thanks,
> 		Stefan
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com

Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html




From seefeld at sympatico.ca  Fri Oct 18 18:44:04 2002
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Fri, 18 Oct 2002 12:44:04 -0400
Subject: [C++-sig] call policies
References: <bea90007017200f96d981334ba3521e03daf1905@>	<ud6q8bzo7.fsf@boost-consulting.com>	<3374756ffe84cb575f4ae0b427a781ce3db031e4@> <u8z0vvhwc.fsf@boost-consulting.com>
Message-ID: <256b2a6a0319323c231895d0cf45dd823db03cec@>

David Abrahams wrote:
> Stefan Seefeld <seefeld at sympatico.ca> writes:
> 
> Stefan,
> 
> I think this is my fault. As you probably know, std::auto_ptr<>'s copy
> constructor is weird: it takes a non-const RHS.

indeed.

> I think I must've
> failed to account for that. I'll look into providing a patch for this
> case today.

Thanks a lot !

Stefan




From dave at boost-consulting.com  Fri Oct 18 20:01:28 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 18 Oct 2002 14:01:28 -0400
Subject: [C++-sig] call policies
In-Reply-To: <256b2a6a0319323c231895d0cf45dd823db03cec@>
References: <bea90007017200f96d981334ba3521e03daf1905@>
	<ud6q8bzo7.fsf@boost-consulting.com>
	<3374756ffe84cb575f4ae0b427a781ce3db031e4@>
	<u8z0vvhwc.fsf@boost-consulting.com>
	<256b2a6a0319323c231895d0cf45dd823db03cec@>
Message-ID: <ud6q7tymf.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> David Abrahams wrote:
> > Stefan Seefeld <seefeld at sympatico.ca> writes:
> > Stefan,
> > I think this is my fault. As you probably know, std::auto_ptr<>'s
> > copy
> > constructor is weird: it takes a non-const RHS.
> 
> indeed.
> 
> > I think I must've
> > failed to account for that. I'll look into providing a patch for this
> > case today.
> 
> Thanks a lot !

Hi Stefan,

Well, this turns out to be much stickier than I had thought; it's
going to take a bit more time than I have today. Could you settle for
shared ownership using boost::shared_ptr<>, or do you have an
underlying interface which really needs to manage ownership through
raw pointers?

-Dave

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com

Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html




From seefeld at sympatico.ca  Fri Oct 18 20:16:41 2002
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Fri, 18 Oct 2002 14:16:41 -0400
Subject: [C++-sig] call policies
References: <bea90007017200f96d981334ba3521e03daf1905@>	<ud6q8bzo7.fsf@boost-consulting.com>	<3374756ffe84cb575f4ae0b427a781ce3db031e4@>	<u8z0vvhwc.fsf@boost-consulting.com>	<256b2a6a0319323c231895d0cf45dd823db03cec@> <ud6q7tymf.fsf@boost-consulting.com>
Message-ID: <5354e9345fa13ae12edee9e53ff2db463db052a5@>

David Abrahams wrote:

> Hi Stefan,
> 
> Well, this turns out to be much stickier than I had thought; it's
> going to take a bit more time than I have today. Could you settle for
> shared ownership using boost::shared_ptr<>, or do you have an
> underlying interface which really needs to manage ownership through
> raw pointers?

no, I already switched to boost::shared_ptr<> as a temporary workaround.
I guessed that it would be quite tricky to deal with Foo(Foo &) 
constructors, and I want to finish my frontend asap...:-)

Thanks,
		Stefan







From dave at boost-consulting.com  Fri Oct 18 20:20:10 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 18 Oct 2002 14:20:10 -0400
Subject: [C++-sig] call policies
In-Reply-To: <5354e9345fa13ae12edee9e53ff2db463db052a5@>
References: <bea90007017200f96d981334ba3521e03daf1905@>
	<ud6q8bzo7.fsf@boost-consulting.com>
	<3374756ffe84cb575f4ae0b427a781ce3db031e4@>
	<u8z0vvhwc.fsf@boost-consulting.com>
	<256b2a6a0319323c231895d0cf45dd823db03cec@>
	<ud6q7tymf.fsf@boost-consulting.com>
	<5354e9345fa13ae12edee9e53ff2db463db052a5@>
Message-ID: <uzntbsj6t.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> David Abrahams wrote:
> 
> > Hi Stefan,
> > Well, this turns out to be much stickier than I had thought; it's
> > going to take a bit more time than I have today. Could you settle for
> > shared ownership using boost::shared_ptr<>, or do you have an
> > underlying interface which really needs to manage ownership through
> > raw pointers?
> 
> no, I already switched to boost::shared_ptr<> as a temporary workaround.
> I guessed that it would be quite tricky to deal with Foo(Foo &)
> constructors, and I want to finish my frontend asap...:-)

Thanks; I'll put this on my as-yet-nonexistent list of things which
need to be addressed.

-Dave

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com

Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html




From dominique.devriese at student.kuleuven.ac.be  Sun Oct 20 22:34:14 2002
From: dominique.devriese at student.kuleuven.ac.be (Dominique Devriese)
Date: Sun, 20 Oct 2002 22:34:14 +0200
Subject: [C++-sig] wrapping global variables
Message-ID: <20021020203414.GA24216@appel.kotnet.org>

Hi,
( please cc me as i'm not subscribed to the list)
I'm playing around a bit with embedding python in a C++ program.  I'm
using Boost.python for exposing the program's API to python, and the
normal python interface ( Py_Initialize, PyRun_SimpleString and
Py_Finalize ) for embedding.

So far this has proven surprisingly easy.  Especially Boost.Python has
amazed me with its ease of use, so congratulations to everyone here
who helped write it, as it most definitely rocks :)

But I have a question:  I would like to expose some global variables
to python.  E.g. if I have a variable curbuf, I would like to be able
to write ( in the embedded python interpreter, that is ) something
like "len = curbuf.length();".  curbuf is of class Buffer, and this
class has been exported very easily, but I don't seem to be able to
find how to expose a global variable.  Of course I can think of some
workarounds like exposing a free function, exposing a curbuf class
that has a singleton constructor, combining either of the above with
something like "PyRun_SimpleString( \"global a = freeFunOrClass();\"
);" ( If that is wrong python, that's because I'm more of a C++
programmer than a python programmer ;) etc., but I was wondering if
there wasn't a clean way to go about it.

I've browsed the c++-sig at python.org archives a bit ( but as there
doesn't seem to be a search function, I've only read the last five
months or so ), and all i've found was this thread:
http://mail.python.org/pipermail/c++-sig/2002-July/001768.html
but it's not very clear...

So, is there a way to do this, or are there any plans to implement it
any time soon or are there any easy alternatives I'm missing ?
Thanks in advance
domi

-- 
Dominique Devriese



From dave at boost-consulting.com  Mon Oct 21 00:45:44 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 20 Oct 2002 18:45:44 -0400
Subject: [C++-sig] wrapping global variables
In-Reply-To: <20021020203414.GA24216@appel.kotnet.org>
References: <20021020203414.GA24216@appel.kotnet.org>
Message-ID: <ulm4safvr.fsf@boost-consulting.com>

Dominique Devriese <dominique.devriese at student.kuleuven.ac.be> writes:

> Hi,
> ( please cc me as i'm not subscribed to the list)
> I'm playing around a bit with embedding python in a C++ program.  I'm
> using Boost.python for exposing the program's API to python, and the
> normal python interface ( Py_Initialize, PyRun_SimpleString and
> Py_Finalize ) for embedding.
> 
> So far this has proven surprisingly easy.  Especially Boost.Python has
> amazed me with its ease of use, so congratulations to everyone here
> who helped write it, as it most definitely rocks :)
> 
> But I have a question:  I would like to expose some global variables
> to python.  E.g. if I have a variable curbuf, I would like to be able
> to write ( in the embedded python interpreter, that is ) something
> like "len = curbuf.length();".  curbuf is of class Buffer, and this
> class has been exported very easily, but I don't seem to be able to
> find how to expose a global variable.  

Take a look at the documentation for scope.hpp. What you're asking
might be as easy as:

     scope().attr("len") = curbuf.length();

...if I understand what you're asking correctly.

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com

Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html




From dominique.devriese at student.kuleuven.ac.be  Mon Oct 21 01:07:28 2002
From: dominique.devriese at student.kuleuven.ac.be (Dominique Devriese)
Date: Mon, 21 Oct 2002 01:07:28 +0200
Subject: [C++-sig] wrapping global variables
In-Reply-To: <ulm4safvr.fsf@boost-consulting.com>
References: <20021020203414.GA24216@appel.kotnet.org> <ulm4safvr.fsf@boost-consulting.com>
Message-ID: <20021020230728.GA26765@appel.kotnet.org>

On Sun, Oct 20, 2002 at 06:45:44PM -0400, David Abrahams wrote:
> Dominique Devriese <dominique.devriese at student.kuleuven.ac.be> writes:
> 
> > Hi,
> > ( please cc me as i'm not subscribed to the list)
> > I'm playing around a bit with embedding python in a C++ program.  I'm
> > using Boost.python for exposing the program's API to python, and the
> > normal python interface ( Py_Initialize, PyRun_SimpleString and
> > Py_Finalize ) for embedding.
> > 
> > So far this has proven surprisingly easy.  Especially Boost.Python has
> > amazed me with its ease of use, so congratulations to everyone here
> > who helped write it, as it most definitely rocks :)
> > 
> > But I have a question:  I would like to expose some global variables
> > to python.  E.g. if I have a variable curbuf, I would like to be able
> > to write ( in the embedded python interpreter, that is ) something
> > like "len = curbuf.length();".  curbuf is of class Buffer, and this
> > class has been exported very easily, but I don't seem to be able to
> > find how to expose a global variable.  
> 
> Take a look at the documentation for scope.hpp. What you're asking
> might be as easy as:
> 
>      scope().attr("len") = curbuf.length();
> 
> ...if I understand what you're asking correctly.

Thanks !
Actually, what i needed wasn't exactly that, but well, this:

"
static Buffer curbuf;

BOOST_PYTHON_MODULE_INIT(ee)
{
  python::class_<Buffer>( "Buffer" )
    .def( "length", &Buffer::length )
    ;
  python::scope().attr( "curbuf" ) = curbuf;
}
"

But it works great, sorry i didn't think of that myself...
cheers
domi

-- 
Dominique Devriese
http://users.pandora.be/frit/domi.gpg



From dave at boost-consulting.com  Mon Oct 21 01:01:28 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 20 Oct 2002 19:01:28 -0400
Subject: [C++-sig] wrapping global variables
In-Reply-To: <20021020230728.GA26765@appel.kotnet.org>
References: <20021020203414.GA24216@appel.kotnet.org>
	<ulm4safvr.fsf@boost-consulting.com>
	<20021020230728.GA26765@appel.kotnet.org>
Message-ID: <ubs5oaf5j.fsf@boost-consulting.com>

Dominique Devriese <dominique.devriese at student.kuleuven.ac.be> writes:

> Thanks !
> Actually, what i needed wasn't exactly that, but well, this:
> 
> "
> static Buffer curbuf;
> 
> BOOST_PYTHON_MODULE_INIT(ee)
> {
>   python::class_<Buffer>( "Buffer" )
>     .def( "length", &Buffer::length )
>     ;
>   python::scope().attr( "curbuf" ) = curbuf;
> }
> "
> 
> But it works great, sorry i didn't think of that myself...
> cheers

for this case you might want:

  scope().attr( "curbuf" ) = boost::ref(curbuf);

-Dave
-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com

Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html




From dominique.devriese at student.kuleuven.ac.be  Mon Oct 21 01:26:04 2002
From: dominique.devriese at student.kuleuven.ac.be (Dominique Devriese)
Date: Mon, 21 Oct 2002 01:26:04 +0200
Subject: [C++-sig] wrapping global variables
In-Reply-To: <ubs5oaf5j.fsf@boost-consulting.com>
References: <20021020203414.GA24216@appel.kotnet.org> <ulm4safvr.fsf@boost-consulting.com> <20021020230728.GA26765@appel.kotnet.org> <ubs5oaf5j.fsf@boost-consulting.com>
Message-ID: <20021020232604.GA30030@appel.kotnet.org>

On Sun, Oct 20, 2002 at 07:01:28PM -0400, David Abrahams wrote:
> Dominique Devriese <dominique.devriese at student.kuleuven.ac.be> writes:
> > "
> > static Buffer curbuf;
> > 
> > BOOST_PYTHON_MODULE_INIT(ee)
> > {
> >   python::class_<Buffer>( "Buffer" )
> >     .def( "length", &Buffer::length )
> >     ;
> >   python::scope().attr( "curbuf" ) = curbuf;
> > }
> > "
> for this case you might want:
> 
>   scope().attr( "curbuf" ) = boost::ref(curbuf);

right, thx.. :)
domi
-- 
Dominique Devriese
http://users.pandora.be/frit/domi.gpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20021021/56d472be/attachment.pgp>

From greglandrum at mindspring.com  Wed Oct 23 01:11:08 2002
From: greglandrum at mindspring.com (greg Landrum)
Date: Tue, 22 Oct 2002 16:11:08 -0700
Subject: [C++-sig] splitting it into multiple pieces
Message-ID: <5.1.0.14.2.20021022160406.02f26360@mail.earthlink.net>

Today while trying to build my BPLv2 stuff under windows using MSVC++, I 
got this beauty of an error:
>compiler limit : internal structure overflow
>
>The compiler has run out of memory. Your program needs to be simplified, 
>perhaps by splitting a large source code file into smaller files.

(explanation from 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/vcerrFatalErrorC1204.asp)

I've been thinking about splitting my project up into multiple files 
anyway; I guess this is MSVC's way of telling me that the time has 
come.  Now I just need to figure out how.

The problem is that I've got a bunch of interconnected objects:
Molecules are made up of Atoms and Bonds (and have GetAtom/Bond methods)
Atoms and Bonds each contain a pointer back to their parent Molecule (and 
have GetParent methods)

I'd like to have separate modules for Mols, Atoms and Bonds.  Can I do this 
given the interdependencies?  If so, is there a convenient example laying 
around somewhere I can look at/steal code from?

thanks,
-greg




From seefeld at sympatico.ca  Wed Oct 23 01:22:42 2002
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Tue, 22 Oct 2002 19:22:42 -0400
Subject: [C++-sig] splitting it into multiple pieces
References: <5.1.0.14.2.20021022160406.02f26360@mail.earthlink.net>
Message-ID: <3DB5DDC2.3080602@sympatico.ca>

greg Landrum wrote:

> The problem is that I've got a bunch of interconnected objects:
> Molecules are made up of Atoms and Bonds (and have GetAtom/Bond methods)
> Atoms and Bonds each contain a pointer back to their parent Molecule 
> (and have GetParent methods)

Right, but these methods are in the C++ domain, where obviously
dependencies are not an issue. The wrapper objects you create with
boost.python don't care. Even inheritance seems to be resolved dynamically,
i.e. at runtime.
I'v just done a similar thing and it works wonderfully.

Regards,
		Stefan




From rwgk at yahoo.com  Wed Oct 23 01:33:30 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 22 Oct 2002 16:33:30 -0700 (PDT)
Subject: [C++-sig] splitting it into multiple pieces
In-Reply-To: <5.1.0.14.2.20021022160406.02f26360@mail.earthlink.net>
Message-ID: <20021022233330.33359.qmail@web20204.mail.yahoo.com>

--- greg Landrum <greglandrum at mindspring.com> wrote:
> The problem is that I've got a bunch of interconnected objects:
> Molecules are made up of Atoms and Bonds (and have GetAtom/Bond methods)
> Atoms and Bonds each contain a pointer back to their parent Molecule (and 
> have GetParent methods)
> 
> I'd like to have separate modules for Mols, Atoms and Bonds.  Can I do this 
> given the interdependencies?

Yes, this is no problem if you are using Boost.Python V2. I do this all the
time.

> If so, is there a convenient example laying around somewhere I can
> look at/steal code from?

I got into the habit of binding one class per file. E.g.:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/cctbx/sgtbx/boost_python/?only_with_tag=boost_python_v2_transition_2

The "top-level" module in this directory is sgtbx_module.cpp. This module calls
the bindings in all the other files (e.g. wrap_brick();). I am pointing you to
this directory specifically because MSVC 7 even made me split up the bindings
for one class: files space_group.cpp and space_group_2.cpp . It all works
without a problem on a variety of platforms.

Related suggestion: you could try lowering BOOST_PYTHON_MAX_ARITY and
BOOST_PYTHON_MAX_BASES (see Boost.Python configuration docs). Maybe this helps
MSVC, but I am not sure.

Ralf


__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/



From rwgk at yahoo.com  Wed Oct 23 01:53:14 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 22 Oct 2002 16:53:14 -0700 (PDT)
Subject: [C++-sig] splitting it into multiple pieces
In-Reply-To: <3DB5DDC2.3080602@sympatico.ca>
Message-ID: <20021022235314.48788.qmail@web20208.mail.yahoo.com>

--- Stefan Seefeld <seefeld at sympatico.ca> wrote:
> Even inheritance seems to be resolved dynamically,
> i.e. at runtime.

Yes, exactly. The only thing to watch out for is that the base-class bindings
must be registered (at runtime) before the bindings for the derived classes.
Ralf


__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/



From gideon at xs4all.nl  Wed Oct 23 13:22:38 2002
From: gideon at xs4all.nl (gideon at xs4all.nl)
Date: Wed, 23 Oct 2002 13:22:38 +0200 (CEST)
Subject: [C++-sig] boost-python link command a bit too long on gcc 3.2
In-Reply-To: <3DB5DDC2.3080602@sympatico.ca>
References: <5.1.0.14.2.20021022160406.02f26360@mail.earthlink.net>
        <3DB5DDC2.3080602@sympatico.ca>
Message-ID: <16860.213.189.150.187.1035372158.squirrel@webmail.xs4all.nl>

Hello,

I am working on a wrapper library which has quite a number of source
files, about 80. This is not a problem, except that currently the
link command is longer than 10240 characters, a limit on the length of the
gcc linker. The reason is that each object path is about 120 chars due to
the boost build system. Has anyone come across the same problem and might
have a solution for me ?

ciao,

gideon





From Paul_Kunz at SLAC.Stanford.EDU  Wed Oct 23 18:55:24 2002
From: Paul_Kunz at SLAC.Stanford.EDU (Paul F. Kunz)
Date: Wed, 23 Oct 2002 09:55:24 -0700
Subject: [C++-sig] Boost V1 build on Solaris
Message-ID: <200210231655.g9NGtOs14379@libra3.slac.stanford.edu>

   I'm trying to build V1 boost::python on Solaris from boost_1_28.

tersk06> $GCC_ROOT_DIRECTORY/bin/gcc -v
Reading specs from /afs/slac/package/gcc/gcc-3/3.1.1/sun4x_58/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.1.1/specs
Configured with: ../../src/gcc-3.1.1/configure --disable-libffi --without-libffi --prefix=/afs/slac.stanford.edu/package/gcc/gcc-3/3.1.1/sun4x_58 --srcdir=../../src/gcc-3.1.1 --enable-shared --enable-version-specific-runtime-libs
Thread model: posix
gcc version 3.1.1

tersk06> pwd
/a/surrey07/g.ek.novadata/data/pfkeb/boost_1_28_0

tersk06> bjam "-sTOOLS=gcc"
---------------------------------------------------------------------
skipping Boost.Python library build
You can configure the location of your python installation, by setting:
PYTHON_ROOT    - currently "/afs/slac/package/python/sun4x_59/2.0"
PYTHON_VERSION - The 2-part python Major.Minor version number (e.g.
                 "2.2", NOT "2.2.1")  - currently "2.0"

The following are automatically configured from PYTHON_ROOT if not
otherwise set:
    PYTHON_INCLUDES    - path to Python #include directories; currently "/afs/slac/package/python/sun4x_59/2.0/include/python2.0"
    PYTHON_LIB_PATH    - path to Python library; currently
                          "/afs/slac/package/python/sun4x_59/2.0/lib/python2.0/config"
    PYTHON_STDLIB_PATH - path to Python standard library modules; currently
                          "/afs/slac/package/python/sun4x_59/2.0/lib/python2.0"
---------------------------------------------------------------------
...found 414 targets...

So the rest of boost built but not python.   I've not had problems
under Linux.

Any hints?



From dave at boost-consulting.com  Wed Oct 23 19:27:01 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 23 Oct 2002 13:27:01 -0400
Subject: [C++-sig] Boost V1 build on Solaris
In-Reply-To: <200210231655.g9NGtOs14379@libra3.slac.stanford.edu>
References: <200210231655.g9NGtOs14379@libra3.slac.stanford.edu>
Message-ID: <ufzuxgj6i.fsf@boost-consulting.com>

"Paul F. Kunz" <Paul_Kunz at SLAC.Stanford.EDU> writes:

>    I'm trying to build V1 boost::python on Solaris from boost_1_28.
> 
> tersk06> $GCC_ROOT_DIRECTORY/bin/gcc -v
> Reading specs from /afs/slac/package/gcc/gcc-3/3.1.1/sun4x_58/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.1.1/specs
> Configured with: ../../src/gcc-3.1.1/configure --disable-libffi --without-libffi --prefix=/afs/slac.stanford.edu/package/gcc/gcc-3/3.1.1/sun4x_58 --srcdir=../../src/gcc-3.1.1 --enable-shared --enable-version-specific-runtime-libs
> Thread model: posix
> gcc version 3.1.1
> 
> tersk06> pwd
> /a/surrey07/g.ek.novadata/data/pfkeb/boost_1_28_0
> 
> tersk06> bjam "-sTOOLS=gcc"
> ---------------------------------------------------------------------
> skipping Boost.Python library build
> You can configure the location of your python installation, by setting:
> PYTHON_ROOT    - currently "/afs/slac/package/python/sun4x_59/2.0"
> PYTHON_VERSION - The 2-part python Major.Minor version number (e.g.
>                  "2.2", NOT "2.2.1")  - currently "2.0"
> 
> The following are automatically configured from PYTHON_ROOT if not
> otherwise set:
>     PYTHON_INCLUDES    - path to Python #include directories; currently "/afs/slac/package/python/sun4x_59/2.0/include/python2.0"
>     PYTHON_LIB_PATH    - path to Python library; currently
>                           "/afs/slac/package/python/sun4x_59/2.0/lib/python2.0/config"
>     PYTHON_STDLIB_PATH - path to Python standard library modules; currently
>                           "/afs/slac/package/python/sun4x_59/2.0/lib/python2.0"
> ---------------------------------------------------------------------
> ...found 414 targets...
> 
> So the rest of boost built but not python.   I've not had problems
> under Linux.
> 
> Any hints?

make sure there is an empty file at:

   /afs/slac/package/python/sun4x_59/2.0/lib/python2.0/test/__init__.py

If there isn't one there already, add it. This will not mess up your
python installation, and will make bjam happy.

HTH,
-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com

Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html




From leo at hiper.com.br  Wed Oct 23 19:43:04 2002
From: leo at hiper.com.br (Leonardo Rochael Almeida)
Date: 23 Oct 2002 15:43:04 -0200
Subject: [C++-sig] Boost V1 build on Solaris
In-Reply-To: <200210231655.g9NGtOs14379@libra3.slac.stanford.edu>
References: <200210231655.g9NGtOs14379@libra3.slac.stanford.edu>
Message-ID: <1035394984.6290.0.camel@spitfire>

On Wed, 2002-10-23 at 14:55, Paul F. Kunz wrote:
>    I'm trying to build V1 boost::python on Solaris from boost_1_28.
> 
> tersk06> $GCC_ROOT_DIRECTORY/bin/gcc -v
> Reading specs from /afs/slac/package/gcc/gcc-3/3.1.1/sun4x_58/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.1.1/specs
> Configured with: ../../src/gcc-3.1.1/configure --disable-libffi --without-libffi --prefix=/afs/slac.stanford.edu/package/gcc/gcc-3/3.1.1/sun4x_58 --srcdir=../../src/gcc-3.1.1 --enable-shared --enable-version-specific-runtime-libs
> Thread model: posix
> gcc version 3.1.1
> 
> tersk06> pwd
> /a/surrey07/g.ek.novadata/data/pfkeb/boost_1_28_0
> 
> tersk06> bjam "-sTOOLS=gcc"
> ---------------------------------------------------------------------
> skipping Boost.Python library build
> You can configure the location of your python installation, by setting:
> PYTHON_ROOT    - currently "/afs/slac/package/python/sun4x_59/2.0"
> PYTHON_VERSION - The 2-part python Major.Minor version number (e.g.
>                  "2.2", NOT "2.2.1")  - currently "2.0"
> 
> The following are automatically configured from PYTHON_ROOT if not
> otherwise set:
>     PYTHON_INCLUDES    - path to Python #include directories; currently "/afs/slac/package/python/sun4x_59/2.0/include/python2.0"
>     PYTHON_LIB_PATH    - path to Python library; currently
>                           "/afs/slac/package/python/sun4x_59/2.0/lib/python2.0/config"
>     PYTHON_STDLIB_PATH - path to Python standard library modules; currently
>                           "/afs/slac/package/python/sun4x_59/2.0/lib/python2.0"
> ---------------------------------------------------------------------
> ...found 414 targets...
> 
> So the rest of boost built but not python.   I've not had problems
> under Linux.
> 
> Any hints?
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 

edit Jamrules in your boost root dir. and add:

PYTHON_ROOT ?= /usr/local ;
PYTHON_VERSION ?= 2.2 ;

replace /usr/local with whatever directory has bin/python and replace
2.2 with the first two levels of whatever version of python you have
(e.g. 2.1, not 2.1.3).

Cheers, Leo

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.




From Paul_Kunz at SLAC.Stanford.EDU  Wed Oct 23 19:53:41 2002
From: Paul_Kunz at SLAC.Stanford.EDU (Paul F. Kunz)
Date: Wed, 23 Oct 2002 10:53:41 -0700
Subject: [C++-sig] Boost V1 build on Solaris
In-Reply-To: <ufzuxgj6i.fsf@boost-consulting.com>
References: <200210231655.g9NGtOs14379@libra3.slac.stanford.edu>
 <ufzuxgj6i.fsf@boost-consulting.com>
Message-ID: <200210231753.g9NHrft14492@libra3.slac.stanford.edu>

>>>>> On Wed, 23 Oct 2002 13:27:01 -0400, David Abrahams <dave at boost-consulting.com> said:

> make sure there is an empty file at:

>
> /afs/slac/package/python/sun4x_59/2.0/lib/python2.0/test/__init__.py

   Thanks for the rapid response.  

   In the meantime, I discovered that the python2.0/include directory
only contains config.h.   So the sys admins have not installed Python
correctly.   Grrr.




From Paul_Kunz at SLAC.Stanford.EDU  Wed Oct 23 23:07:31 2002
From: Paul_Kunz at SLAC.Stanford.EDU (Paul F. Kunz)
Date: Wed, 23 Oct 2002 14:07:31 -0700
Subject: [C++-sig] Boost V1 build on Solaris
In-Reply-To: <ufzuxgj6i.fsf@boost-consulting.com>
References: <200210231655.g9NGtOs14379@libra3.slac.stanford.edu>
 <ufzuxgj6i.fsf@boost-consulting.com>
Message-ID: <200210232107.g9NL7V121141@libra3.slac.stanford.edu>

   I finally got bjam to compile boost::python sources (if you
remember my previous post, I found the Python header files is a
strange place).   Now I'm failing on the link step...

    /afs/slac/package/gcc/gcc-3/3.1.1/sun4x_58/bin/g++   -s -fPIC
    -shared  -o
    "libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/runtime-link-dynamic/shared-linkable-true/libboost_python.so"

< ..munch..>

/bin/libboost_python.so/gcc/release/inlining-on/runtime-link-dynamic/shared-linkable-true/errors.o"    -lutil


ld: fatal: library -lutil: not found

On my Linux machine, libutil.so appears in /usr/lib.  and 

libra3> rpm -q --file /usr/lib/libutil.a
glibc-devel-2.2.4-29

libutil.so doesn't appear to be on Solaris 5.8.   Is there some other
library I could link to?   Do I really need libutil.so?



From grafik666 at redshift-software.com  Wed Oct 23 23:09:56 2002
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Wed, 23 Oct 2002 16:09:56 -0500
Subject: [C++-sig] boost-python link command a bit too long on gcc 3.2
In-Reply-To: <16860.213.189.150.187.1035372158.squirrel@webmail.xs4all.nl>
Message-ID: <20021023160957-r01010800-ab6d94bf-0860-0108@12.100.89.43>

[2002-10-23] gideon at xs4all.nl wrote:

>Hello,
>
>I am working on a wrapper library which has quite a number of source
>files, about 80. This is not a problem, except that currently the
>link command is longer than 10240 characters, a limit on the length of the
>gcc linker. The reason is that each object path is about 120 chars due to
>the boost build system. Has anyone come across the same problem and might
>have a solution for me ?

That looks like the WindowsNT command.com limit. Which platform are you
doing this on? What version of bjam? What version of Boost? etc.

By the way, I frequently link, with gcc on Linux, libraries that have
hundreds of files.


-- grafik - Don't Assume Anything
-- rrivera at acm.org - grafik at redshift-software.com
-- 102708583 at icq - Grafik666 at AIM - Grafik at jabber.org



From dave at boost-consulting.com  Wed Oct 23 23:01:10 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 23 Oct 2002 17:01:10 -0400
Subject: [C++-sig] Boost V1 build on Solaris
In-Reply-To: <200210232107.g9NL7V121141@libra3.slac.stanford.edu>
References: <200210231655.g9NGtOs14379@libra3.slac.stanford.edu>
	<ufzuxgj6i.fsf@boost-consulting.com>
	<200210232107.g9NL7V121141@libra3.slac.stanford.edu>
Message-ID: <u1y6gamzt.fsf@boost-consulting.com>

"Paul F. Kunz" <Paul_Kunz at SLAC.Stanford.EDU> writes:

>    I finally got bjam to compile boost::python sources (if you
> remember my previous post, I found the Python header files is a
> strange place).   Now I'm failing on the link step...
> 
>     /afs/slac/package/gcc/gcc-3/3.1.1/sun4x_58/bin/g++   -s -fPIC
>     -shared  -o
>     "libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/runtime-link-dynamic/shared-linkable-true/libboost_python.so"
> 
> < ..munch..>
> 
> /bin/libboost_python.so/gcc/release/inlining-on/runtime-link-dynamic/shared-linkable-true/errors.o"    -lutil
> 
> 
> ld: fatal: library -lutil: not found
> 
> On my Linux machine, libutil.so appears in /usr/lib.  and 
> 
> libra3> rpm -q --file /usr/lib/libutil.a
> glibc-devel-2.2.4-29
> 
> libutil.so doesn't appear to be on Solaris 5.8.   Is there some other
> library I could link to?   Do I really need libutil.so?

I think you don't. If you want to manually edit
$BOOST_ROOT/tools/build/python.jam to remove mention of
<find-library>util or -lutil that might be your best bet.

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com

Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html




From Paul_Kunz at SLAC.Stanford.EDU  Wed Oct 23 23:46:07 2002
From: Paul_Kunz at SLAC.Stanford.EDU (Paul F. Kunz)
Date: Wed, 23 Oct 2002 14:46:07 -0700
Subject: [C++-sig] Boost V1 build on Solaris
In-Reply-To: <u1y6gamzt.fsf@boost-consulting.com>
References: <200210231655.g9NGtOs14379@libra3.slac.stanford.edu>
 <ufzuxgj6i.fsf@boost-consulting.com>
 <200210232107.g9NL7V121141@libra3.slac.stanford.edu>
 <u1y6gamzt.fsf@boost-consulting.com>
Message-ID: <200210232146.g9NLk7321254@libra3.slac.stanford.edu>

>>>>> On Wed, 23 Oct 2002 17:01:10 -0400, David Abrahams <dave at boost-consulting.com> said:


> I think you don't. If you want to manually edit
> $BOOST_ROOT/tools/build/python.jam to remove mention of
> <find-library>util or -lutil that might be your best bet.

   That fixed it!   Thanks again.



From dave at boost-consulting.com  Wed Oct 23 23:41:30 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 23 Oct 2002 17:41:30 -0400
Subject: [C++-sig] Re: ANN: Boost.Python v2
In-Reply-To: <3DB4632B.40309@atd.ucar.edu>
References: <mailman.1034603227.1430.clpa-moderators@python.org>
	<3DB40C22.2020705@atd.ucar.edu> <uk7kb96rz.fsf@boost-consulting.com>
	<3DB4632B.40309@atd.ucar.edu>
Message-ID: <usmyw96k5.fsf@boost-consulting.com>

Joe Van Andel <vanandel at atd.ucar.edu> writes:

> Thanks for your quick response.

No problem.

> > http://www.boost.org/libs/python/doc/v2/numeric.html
> 
> 
> Sorry, I guess I missed this.  You do reference Numeric in the
> reference manual, but I didn't see any reference in the Synopsis or
> the Tutorial Introduction.  Would you be willing to mention Numeric
> support in the Synopsis?

Sure. Tell me what you think it should say.

> Do you have any more examples of accessing Numeric arrays using Boost?

http://www.boost.org/libs/python/test/numpy.cpp
http://www.boost.org/libs/python/test/numpy.py

> >>That is, I want to pass Numeric Python arrays to my C++ extensions,
> >>and not have to write my C++ code to be aware of the Numeric
> >>interfaces (if possible).
> > I'm not sure what you mean by "not aware of the Numeric interfaces".
> 
> Sorry, I meant to say the Numeric API, e.g. calls like:
> PyArray_ISCONTIGUOUS()
> or
> PyArray_As2D((PyObject **)&theInput, (char ***)&inP,
>                   &numRays, &numGates,  PyArray_FLOAT);

I don't know if the above meets your needs. The numeric support could
use some fleshing-out, as others have pointed out on this
list. Patches to enhance the existing numeric support would be
gratefully considered.

HTH,
-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com

Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html




From Paul_Kunz at SLAC.Stanford.EDU  Thu Oct 24 02:36:58 2002
From: Paul_Kunz at SLAC.Stanford.EDU (Paul F. Kunz)
Date: Wed, 23 Oct 2002 17:36:58 -0700
Subject: [C++-sig] Boost V1 build on Solaris
References: <200210231655.g9NGtOs14379@libra3.slac.stanford.edu>
 <ufzuxgj6i.fsf@boost-consulting.com>
 <200210232107.g9NL7V121141@libra3.slac.stanford.edu>
 <u1y6gamzt.fsf@boost-consulting.com>
Message-ID: <200210240036.g9O0awA23318@libra3.slac.stanford.edu>

   One final question, which is not specific to boost::python but
general question on building Python modules.   What my Solaris
administrators have done is to configure Python with 

>  ./configure
 --prefix=/afs/.slac.stanford.edu/package/python/common/2.0
 --exec-prefix=/afs/.slac.stanford.edu/package/python/sun4x_55/2.0

They also did a build fron Linux with the appropriate `exec-prefix'.
What apparently this has done is to put all but one of the Python
include files in the directory `common/2.0/include'.  But Python.h
includes `config.h' or `pyconfig.h' (depending on the version) which
gets installed in `sun4x_55/2.0/include'.  This is appropriate since
this file is machine/OS dependent.

   Now the problem is that boost::python, and other packages, gives you
one variable, like PYTHON_INCLUDES,  for its build.   When it is set to find
`Python.h' it will not find `pyconfig.h'.   

   What is the best way to handle this situation?   Is it a bug in
Python's configure script?   Bug in boost::python and others?   Or am
I missing something obvious?



From leo at hiper.com.br  Thu Oct 24 19:38:34 2002
From: leo at hiper.com.br (Leonardo Rochael Almeida)
Date: 24 Oct 2002 15:38:34 -0200
Subject: [C++-sig] Boost V1 build on Solaris
In-Reply-To: <200210240036.g9O0awA23318@libra3.slac.stanford.edu>
References: <200210231655.g9NGtOs14379@libra3.slac.stanford.edu>
	<ufzuxgj6i.fsf@boost-consulting.com>
	<200210232107.g9NL7V121141@libra3.slac.stanford.edu>
	<u1y6gamzt.fsf@boost-consulting.com> 
	<200210240036.g9O0awA23318@libra3.slac.stanford.edu>
Message-ID: <1035481114.11231.0.camel@spitfire>

On Wed, 2002-10-23 at 22:36, Paul F. Kunz wrote:
>    One final question, which is not specific to boost::python but
> general question on building Python modules.   What my Solaris
> administrators have done is to configure Python with 
> 
> >  ./configure
>  --prefix=/afs/.slac.stanford.edu/package/python/common/2.0
>  --exec-prefix=/afs/.slac.stanford.edu/package/python/sun4x_55/2.0
> 
> They also did a build fron Linux with the appropriate `exec-prefix'.
> What apparently this has done is to put all but one of the Python
> include files in the directory `common/2.0/include'.  But Python.h
> includes `config.h' or `pyconfig.h' (depending on the version) which
> gets installed in `sun4x_55/2.0/include'.  This is appropriate since
> this file is machine/OS dependent.
> 
>    Now the problem is that boost::python, and other packages, gives you
> one variable, like PYTHON_INCLUDES,  for its build.   When it is set to find
> `Python.h' it will not find `pyconfig.h'.   
> 
>    What is the best way to handle this situation?   Is it a bug in
> Python's configure script?   Bug in boost::python and others?   Or am
> I missing something obvious?

Your setup requires that sun4x_55/2.0/include is in the include path
somehow (i.e. it should be in the -I parameter of all compiler
invocations). Reading <boost>tools/build/gcc-tools.jam makes me believe
that you can make your setup work by adding the following line to your
<boost>/Jamrules file:

STDHDRS += /afs/.slac.stanford.edu/package/python/sun4x_55/2.0


IMO, the proper way to fix this would be to make boost.python accept a
PYTHON_EXECUTABLE variable which we could set like:

PYTHON_EXECUTABLE ?= /usr/local/bin/python2.2

This way, boost could probe python for its version and distutil
infrastructure for all apropriate include and link flags. This is what
Psycopg does in it's ./configure script (e.g. --with-python=...)

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.




From okuda1 at llnl.gov  Thu Oct 24 19:42:52 2002
From: okuda1 at llnl.gov (chuzo okuda)
Date: Thu, 24 Oct 2002 10:42:52 -0700
Subject: [C++-sig] Tutorial
References: <bea90007017200f96d981334ba3521e03daf1905@> <ud6q8bzo7.fsf@boost-consulting.com>
Message-ID: <3DB8311C.299058B5@llnl.gov>

I read some of the tutorial. 

I cannot make it work without eliminating "const" in Class Data Members
topic.
How to make it work with const?

struct Var {
   Var(std::string name) : name(name), value() {}
   std::string const name;
   float value;
};

BOOST_PYTHON_MODULE_INIT(mytest3)
{
   using namespace boost::python; 

   class_<Var>("Var", init<std::string>())
      .def_readonly("name", &Var::name)
      .def_readwrite("value", &Var::value)
      ;
}

*** snips ***
"boost::python::detail::copy_non_const_reference_expects_a_non_const_          
reference_return_type<boost::add_reference<boost::add_const<boost::py          
thon::objects::make_holder<1>::apply<boost::python::objects::detail::          
select_value_holder<Var, Var>::type,
*** snips ***

Also, on the next topic, Class Property, I see:

    class_<Num>("Num")
             .add_property("rovalue", &Var::get)
             .add_property("value", &Var::get, &Var::set);

It should be &Num::get and &Num::set.

Additionally, I would like to have a index page that can quickly find
information such as "add_property", "def_readonly", etc.
It would be very much helpful like python web page.
Cheers!
Chuzo



From lpeng at bcm.tmc.edu  Thu Oct 24 23:35:04 2002
From: lpeng at bcm.tmc.edu (Liwei Peng)
Date: Thu, 24 Oct 2002 16:35:04 -0500 (CDT)
Subject: [C++-sig] type convert: python file <-> C++ FILE*
Message-ID: <Pine.SGI.3.95.1021024163145.309896A-100000@blake.3dem.bioch.bcm.tmc.edu>

Hi,

I am using Boost Python V2 to wrap my C++ code. I failed
to convert python file to/from C++ FILE*. Here is my code:

----------------------------------------
struct FILE_to_pyfile
{
    static PyObject* convert(FILE* x)
    {        
        return PyFile_FromFile(x, "", "", NULL);
    }
};

FILE* getfile(const char* fname)
{
    printf("openning file: %s\n", fname);
    FILE* f = fopen(fname, "w");
    fprintf(f, "initial words\n");
    return f;
}

BOOST_PYTHON_MODULE(numbermod)
{
    python::to_python_converter<FILE*, FILE_to_pyfile>();
    python::def("getfile", getfile,
                python::return_internal_reference<>());
}

-----------------------------------------------
After I compiled the code, in python run

  f = getfile("hello.txt")
  
gave me the following error:

Traceback (most recent call last):
  File "./test.py", line 18, in ?
    f1 = getfile("hello.txt")
TypeError: bad argument type for built-in operation


Can you kindly tell me
  1) what's wrong with the above code? 

  2) The above code is from C++ 'FILE*' to python file.
     If I want to convert python file to C++ file,
     how can I do that?

Thanks in advance.

Liwei





From j.c.webster at bigpond.com  Fri Oct 25 16:44:07 2002
From: j.c.webster at bigpond.com (James Webster)
Date: Fri, 25 Oct 2002 07:44:07 -0700
Subject: [C++-sig] (no subject)
Message-ID: <003701c27c34$fc2015e0$d4878b90@james-webster>

confirm 502702

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20021025/addce199/attachment.htm>

From leo at hiper.com.br  Fri Oct 25 00:28:48 2002
From: leo at hiper.com.br (Leonardo Rochael Almeida)
Date: 24 Oct 2002 20:28:48 -0200
Subject: [C++-sig] linking with external libraries
Message-ID: <1035498528.13406.4.camel@spitfire>

Hi,

As I mentioned before, I'm wrapping a GIS library. This library build
process can't be easily boostified, so it is built externally and I have
to instruct my extensions to link against it and to search for include
files in specific locations. My first try to make this run on Linux went
like this (Jamfile):

extension pyterralib
:  # sources
        pyterralib.cpp

   # dependencies
   <dll>../build/boost_python
:  # requirements
   <sysinclude>/usr/local/include/terralib
   <linkflags>-lterralib
  ;

And it worked reasonably well, but it left me unsatisfied. the
<sysinclude> feature seems reasoable, but I felt there should be a more
generic way to specify a library to link against instead of a specific
<linkflags>.

Sure enough, when I tried to make the same thing work in Windows,
"<linkflags>-l" wouldn't cut it, so I found the <library-path> and
<library-file> features which, in msvc-tools.jam seemed to do the right
thing, so I did this:

# Declare a Python extension called geobusca
extension pyterralib
:  # sources
   pyterralib.cpp
  
   # dependencies
   <dll>../build/boost_python
:  # flags
   <sysinclude>C:/geobusca/terralib/Terralib10/src/terralib
   <library-path>C:/geobusca/terralib/Terralib10/terralibw/terralib/Debug
   <library-file>terralib
  ;

Unfortunately this doesn't work as bjam complains:

    don't know how to make terralib
    
the <sysinclude> part works, without it the build failed in the middle
of the compilation, but I don't know the proper link flags for msvc (I'm
a Linux guy) and I was hoping boost.build would free me from ever having
to learn it :-)

So is there an official and cross-platform way to specify a dependency
on an external library which boost.build shouldn't try to build?

Cheers, Leo

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.




From dave at boost-consulting.com  Thu Oct 24 20:03:11 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 24 Oct 2002 14:03:11 -0400
Subject: [C++-sig] Boost V1 build on Solaris
In-Reply-To: <1035481114.11231.0.camel@spitfire>
References: <200210231655.g9NGtOs14379@libra3.slac.stanford.edu>
	<ufzuxgj6i.fsf@boost-consulting.com>
	<200210232107.g9NL7V121141@libra3.slac.stanford.edu>
	<u1y6gamzt.fsf@boost-consulting.com>
	<200210240036.g9O0awA23318@libra3.slac.stanford.edu>
	<1035481114.11231.0.camel@spitfire>
Message-ID: <u3cqvu334.fsf@boost-consulting.com>


Leonardo Rochael Almeida <leo at hiper.com.br> writes:

> On Wed, 2002-10-23 at 22:36, Paul F. Kunz wrote:
> >    One final question, which is not specific to boost::python but
> > general question on building Python modules.   What my Solaris
> > administrators have done is to configure Python with 
> > 
> > >  ./configure
> >  --prefix=/afs/.slac.stanford.edu/package/python/common/2.0
> >  --exec-prefix=/afs/.slac.stanford.edu/package/python/sun4x_55/2.0
> > 
> > They also did a build fron Linux with the appropriate `exec-prefix'.
> > What apparently this has done is to put all but one of the Python
> > include files in the directory `common/2.0/include'.  But Python.h
> > includes `config.h' or `pyconfig.h' (depending on the version) which
> > gets installed in `sun4x_55/2.0/include'.  This is appropriate since
> > this file is machine/OS dependent.
> > 
> >    Now the problem is that boost::python, and other packages, gives you
> > one variable, like PYTHON_INCLUDES,  for its build.   When it is set to find
> > `Python.h' it will not find `pyconfig.h'.   
> > 
> >    What is the best way to handle this situation?   Is it a bug in
> > Python's configure script?   Bug in boost::python and others?   Or am
> > I missing something obvious?
> 
> Your setup requires that sun4x_55/2.0/include is in the include path
> somehow (i.e. it should be in the -I parameter of all compiler
> invocations). Reading <boost>tools/build/gcc-tools.jam makes me believe
> that you can make your setup work by adding the following line to your
> <boost>/Jamrules file:
> 
> STDHDRS += /afs/.slac.stanford.edu/package/python/sun4x_55/2.0

That's generally /not/ the way you're intended to use the build
system. You can do this, but it's not going to work in future versions
of the build system and it could do unexpected things when you build
targets other than Boost.Python and Boost.Python extensions.  The
right thing to do is to add something like:

  PYTHON_PROPERTIES += <sysinclude>$(PYTHON:D)/include ;

to the end of tools/build/python.jam, but I don't want to make that
change until I hear from python-dev about what's going on here. In the
meantime, you can do it in the Jamfiles after python.jam is included.

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com

Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html




From dave at boost-consulting.com  Thu Oct 24 20:06:56 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 24 Oct 2002 14:06:56 -0400
Subject: [C++-sig] Tutorial
In-Reply-To: <3DB8311C.299058B5@llnl.gov>
References: <bea90007017200f96d981334ba3521e03daf1905@>
	<ud6q8bzo7.fsf@boost-consulting.com> <3DB8311C.299058B5@llnl.gov>
Message-ID: <uy98nsocf.fsf@boost-consulting.com>


chuzo okuda <okuda1 at llnl.gov> writes:

> I read some of the tutorial. 
> 
> I cannot make it work without eliminating "const" in Class Data Members
> topic.
> How to make it work with const?
> 
> struct Var {
>    Var(std::string name) : name(name), value() {}
>    std::string const name;
>    float value;
> };
> 
> BOOST_PYTHON_MODULE_INIT(mytest3)
> {
>    using namespace boost::python; 
> 
>    class_<Var>("Var", init<std::string>())
>       .def_readonly("name", &Var::name)
>       .def_readwrite("value", &Var::value)
>       ;
> }
> 
> *** snips ***
> "boost::python::detail::copy_non_const_reference_expects_a_non_const_          
> reference_return_type<boost::add_reference<boost::add_const<boost::py          
> thon::objects::make_holder<1>::apply<boost::python::objects::detail::          
> select_value_holder<Var, Var>::type,
> *** snips ***

This was answered already, here:

   http://aspn.activestate.com/ASPN/Mail/Message/1397291

> Also, on the next topic, Class Property, I see:
> 
>     class_<Num>("Num")
>              .add_property("rovalue", &Var::get)
>              .add_property("value", &Var::get, &Var::set);
> 
> It should be &Num::get and &Num::set.

Thanks. Joel, would you make this fix?

> Additionally, I would like to have a index page that can quickly
> find information such as "add_property", "def_readonly", etc.  It
> would be very much helpful like python web page.  

Yeah, that would be nice, but it's a big job. We're looking into how
to get a tool called Synopsis to help with some of that. It's a
long-term solution, though.

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com

Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html




From dave at boost-consulting.com  Fri Oct 25 00:00:39 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 24 Oct 2002 18:00:39 -0400
Subject: [C++-sig] Boost V1 build on Solaris
In-Reply-To: <u3cqvu334.fsf@boost-consulting.com>
References: <200210231655.g9NGtOs14379@libra3.slac.stanford.edu>
	<ufzuxgj6i.fsf@boost-consulting.com>
	<200210232107.g9NL7V121141@libra3.slac.stanford.edu>
	<u1y6gamzt.fsf@boost-consulting.com>
	<200210240036.g9O0awA23318@libra3.slac.stanford.edu>
	<1035481114.11231.0.camel@spitfire>
	<u3cqvu334.fsf@boost-consulting.com>
Message-ID: <uof9jxzso.fsf@boost-consulting.com>


Leonardo Rochael Almeida <leo at hiper.com.br> writes:

> On Wed, 2002-10-23 at 22:36, Paul F. Kunz wrote:
> >    One final question, which is not specific to boost::python but
> > general question on building Python modules.   What my Solaris
> > administrators have done is to configure Python with 
> > 
> > >  ./configure
> >  --prefix=/afs/.slac.stanford.edu/package/python/common/2.0
> >  --exec-prefix=/afs/.slac.stanford.edu/package/python/sun4x_55/2.0
> > 
> > They also did a build fron Linux with the appropriate `exec-prefix'.
> > What apparently this has done is to put all but one of the Python
> > include files in the directory `common/2.0/include'.  But Python.h
> > includes `config.h' or `pyconfig.h' (depending on the version) which
> > gets installed in `sun4x_55/2.0/include'.  This is appropriate since
> > this file is machine/OS dependent.
> > 
> >    Now the problem is that boost::python, and other packages, gives you
> > one variable, like PYTHON_INCLUDES,  for its build.   When it is set to find
> > `Python.h' it will not find `pyconfig.h'.   
> > 
> >    What is the best way to handle this situation?   Is it a bug in
> > Python's configure script?   Bug in boost::python and others?   Or am
> > I missing something obvious?
> 
> Your setup requires that sun4x_55/2.0/include is in the include path
> somehow (i.e. it should be in the -I parameter of all compiler
> invocations). Reading <boost>tools/build/gcc-tools.jam makes me believe
> that you can make your setup work by adding the following line to your
> <boost>/Jamrules file:
> 
> STDHDRS += /afs/.slac.stanford.edu/package/python/sun4x_55/2.0

That's generally /not/ the way you're intended to use the build
system. You can do this, but it's not going to work in future versions
of the build system and it could do unexpected things when you build
targets other than Boost.Python and Boost.Python extensions.  The
right thing to do is to add something like:

  PYTHON_PROPERTIES += <sysinclude>$(PYTHON:D)/include ;

to the end of tools/build/python.jam, but I don't want to make that
change until I hear from python-dev about what's going on here. In the
meantime, you can do it in the Jamfiles after python.jam is included.

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com

Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html




From grafik666 at redshift-software.com  Fri Oct 25 00:58:58 2002
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Thu, 24 Oct 2002 17:58:58 -0500
Subject: [C++-sig] linking with external libraries
In-Reply-To: <1035498528.13406.4.camel@spitfire>
Message-ID: <20021024175859-r01010800-302ff4e2-0860-0108@12.100.89.43>

[2002-10-24] Leonardo Rochael Almeida wrote:

>Hi,
>
>So is there an official and cross-platform way to specify a dependency
>on an external library which boost.build shouldn't try to build?

    <library-path>C:/geobusca/terralib/Terralib10/terralibw/terralib/Debug
    <find-library>terralib


-- grafik - Don't Assume Anything
-- rrivera at acm.org - grafik at redshift-software.com
-- 102708583 at icq - Grafik666 at AIM - Grafik at jabber.org



From nicodemus at globalite.com.br  Sat Oct 26 04:21:48 2002
From: nicodemus at globalite.com.br (Nicodemus)
Date: Fri, 25 Oct 2002 23:21:48 -0300
Subject: [C++-sig] Linking problems with msvc+stlport
Message-ID: <001601c27c96$70e723d0$0200000a@nicodemus>

Hail!

I've been trying to use boost python with the msvc 6.0 compiler and
STLport-4.5.3 for two weeks now, without success.

I've read the tutorial, and created a short snippet to export a simple class
that represents color information. I compiled boost without problems (using
the "msvc-stlport" toolset), and I'm using Python 2.2 (ActiveState's
distribution).
I'm using a msvc project to build a DLL, and during the linking stage it
complains about the following unresolved externals:

void boost::python::objects::register_dynamic_id_aux(...)
class boost::python::api::object __cdecl
boost::python::objects::function_object

Plus, it gives some warnings about:
 "non dll-interface class 'boost::noncopyable' used as base for dll-interface
struct 'boost::python::instance_holder'"

I've also done the same tests using the Intel 6.0 compiler, and it gives the
same unresolved externals, but no warnings. I didn't compile boost with Intel
and STLport support because I couldn't find in the documentation a tool to do
it, but would like to do it, since I don't plan to use the msvc compiler,
which was used just for the sake of this tests.

I plan also to create a static library for embedding purposes, so that I can
link this library with a program, and use the objects exported by it. To do
this, I compile the lib with the flag BOOST_PYTHON_STATIC_LIB, and it gives 2
warnings (about int being cast to bool), and in the main() of the program I
call the function initmymodule() (there's a better way to do this?). When I
try to compile my application thought, it gives the same unresolved externals
above.

On the other hand, If I don't use STLport (including compiling boost with the
"msvc" toolset), everything works as expected, both the DLL and the embeded
application.

What can I do to successfuly compile both the application and the DLL? Any
pointer will be great!

Thanks a lot,
Nicodemus.








From dave at boost-consulting.com  Sat Oct 26 14:55:40 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 26 Oct 2002 08:55:40 -0400
Subject: [C++-sig] Linking problems with msvc+stlport
In-Reply-To: <001601c27c96$70e723d0$0200000a@nicodemus>
References: <001601c27c96$70e723d0$0200000a@nicodemus>
Message-ID: <uwuo5l5pv.fsf@boost-consulting.com>

"Nicodemus" <nicodemus at globalite.com.br> writes:

> Hail!
> 
> I've been trying to use boost python with the msvc 6.0 compiler and
> STLport-4.5.3 for two weeks now, without success.
> 
> I've read the tutorial, and created a short snippet to export a simple class
> that represents color information. I compiled boost without problems (using
> the "msvc-stlport" toolset), and I'm using Python 2.2 (ActiveState's
> distribution).
> I'm using a msvc project to build a DLL, and during the linking stage it
> complains about the following unresolved externals:

Did you try using Boost.Build to create your DLL? Usually when people
have trouble building or linking their Boost.Python projects it's
because they don't set up their build environment to do what
Boost.Build would do; they get the build instructions wrong...

If you invoke Boost.Build with the "-n -a" options it will just dump
all the build commands it runs so you can inspect the command-line
options.

On the other hand, MSVC6 is reknowned for its many bugs, so you might
just be running into a problem with your tools.

> void boost::python::objects::register_dynamic_id_aux(...)
> class boost::python::api::object __cdecl
> boost::python::objects::function_object

These are exported from libs/python/src/object/inheritance.cpp and
libs/python/src/object/function.cpp, respectively.

> Plus, it gives some warnings about:
>  "non dll-interface class 'boost::noncopyable' used as base for dll-interface
> struct 'boost::python::instance_holder'"

You can ignore that warning.

> I've also done the same tests using the Intel 6.0 compiler, and it
> gives the same unresolved externals, but no warnings. 

Did you rebuild the Boost.Python library with Intel 6.0, or are you
trying to use the same one you built with MSVC6?

> I didn't compile boost with Intel and STLport support because I
> couldn't find in the documentation a tool to do it, but would like
> to do it, since I don't plan to use the msvc compiler, which was
> used just for the sake of this tests.

An advantage of Intel + STLPort is that you can turn off the
"microsoft bug emulation mode" in the Intel compiler to get a very
high degree of standard conformance.

> I plan also to create a static library for embedding purposes, so
> that I can link this library with a program, and use the objects
> exported by it. To do this, I compile the lib with the flag
> BOOST_PYTHON_STATIC_LIB, and it gives 2 warnings (about int being
> cast to bool), and in the main() of the program I call the function
> initmymodule() (there's a better way to do this?). When I try to
> compile my application thought, it gives the same unresolved
> externals above.

That's awfully strange. Does Intel give any more-detailed information
about which source files (or preferably functions) are asking for
these symbols?

> On the other hand, If I don't use STLport (including compiling boost
> with the "msvc" toolset), everything works as expected, both the DLL
> and the embeded application.
> 
> What can I do to successfuly compile both the application and the DLL? Any
> pointer will be great!

I suggest that you start with a small example using Boost.Build.

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com




From nicodemus at globalite.com.br  Sat Oct 26 21:27:48 2002
From: nicodemus at globalite.com.br (Nicodemus)
Date: Sat, 26 Oct 2002 16:27:48 -0300
Subject: [C++-sig] Linking problems with msvc+stlport
References: <001601c27c96$70e723d0$0200000a@nicodemus> <uwuo5l5pv.fsf@boost-consulting.com>
Message-ID: <001e01c27d25$ce8e7620$0200000a@nicodemus>

Hail, thanks for the quick response.

David Abrahams <dave at boost-consulting.com> wrote:

> Did you try using Boost.Build to create your DLL? Usually when people
> have trouble building or linking their Boost.Python projects it's
> because they don't set up their build environment to do what
> Boost.Build would do; they get the build instructions wrong...
I did compile the simple hello world example, but didn't investigate in this
path further because building the extensions using Boost.Build was not
desired, because we plan to use it at work and we have other build system.
After your suggestion, I did compile my extension with Boost.Build, and it did
work perfectly.

> If you invoke Boost.Build with the "-n -a" options it will just dump
> all the build commands it runs so you can inspect the command-line
> options.
Great, I was looking for this. Thanks.

> On the other hand, MSVC6 is reknowned for its many bugs, so you might
> just be running into a problem with your tools.
Indeed, and I was using it only because I wanted to compile boost with
stlport, and there's no toolset to compile intel+stlport.


> Did you rebuild the Boost.Python library with Intel 6.0, or are you
> trying to use the same one you built with MSVC6?
I didn't rebuild Boost.Python with Intel 6, because I wanted to build it using
STLport.


> That's awfully strange. Does Intel give any more-detailed information
> about which source files (or preferably functions) are asking for
> these symbols?
Unfortunetely, no. But here it is the complete error for one of the functions:
rgba.obj : error LNK2001: unresolved external symbol "__declspec(dllimport)
void __cdecl boost::python::objects::register_dynamic_id_aux(struct
boost::python::type_info,struct _STL::pair<void *,struct
boost::python::type_info> (__cdecl*)(void *))" (
__imp_?register_dynamic_id_aux at objects@python at boost@@YAXUtype_info at 23@P6A?AU?$
pair at PAXUtype_info@python at boost@@@_STL@@PAX at Z@Z)


> I suggest that you start with a small example using Boost.Build.
Thanks, I will do just that.

One thing that I noticed after analyzing the command line generated by
Boost.Build is that I was not specifying the path to my stlport instalation
correctly! I corrected this, but now the msvc compiler gives internal errors
while parsing one of the stlport's headers, _complex.h. 8(
So, the previous unresolved externals where the result of the mixing of
STLport and the msvc stl implementation, because like I said previously, if I
compiled without STLport everything worked.

I then compiled everything with Intel 32, without STLport, and Alas!,
everything works nicely. (except one detail: like I said before, to embed the
code in one executable, I compiled the static lib with
BOOST_PYTHON_STATIC_LIB, which was giving me one unresolved external. After I
removed this define, it compiled and linked without any error or warning).

After all this, another question then: How can I compile Boost.Python using
the Intel compiler and STLport? Unfortunetely, using the native msvc stl
libraries is not an option for me.

Thanks again for the help David!
Nicodemus.





From dave at boost-consulting.com  Sat Oct 26 23:20:19 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 26 Oct 2002 17:20:19 -0400
Subject: [C++-sig] Linking problems with msvc+stlport
In-Reply-To: <001e01c27d25$ce8e7620$0200000a@nicodemus>
References: <001601c27c96$70e723d0$0200000a@nicodemus>
	<uwuo5l5pv.fsf@boost-consulting.com>
	<001e01c27d25$ce8e7620$0200000a@nicodemus>
Message-ID: <uk7k4ew30.fsf@boost-consulting.com>

"Nicodemus" <nicodemus at globalite.com.br> writes:

> Hail, thanks for the quick response.

You're welcome. It would be easier to read your replies if you'd leave
a blank line after quoted text.

> David Abrahams <dave at boost-consulting.com> wrote:
> 
> > On the other hand, MSVC6 is reknowned for its many bugs, so you might
> > just be running into a problem with your tools.
> Indeed, and I was using it only because I wanted to compile boost with
> stlport, and there's no toolset to compile intel+stlport.

Huh? What's wrong with
http://www.boost.org/tools/build/intel-win32-stlport-tools.jam?

> > Did you rebuild the Boost.Python library with Intel 6.0, or are you
> > trying to use the same one you built with MSVC6?
>
> I didn't rebuild Boost.Python with Intel 6, because I wanted to
> build it using STLport.

In theory, Intel is supposed to produce code that's link-compatible
with that produced by msvc6. However in general that's not true of C++
compilers and I wouldn't be at all surprised to find out that it fails
in corner cases for msvc6 and Intel C++.

> > That's awfully strange. Does Intel give any more-detailed information
> > about which source files (or preferably functions) are asking for
> > these symbols?
>
> Unfortunetely, no. But here it is the complete error for one of the functions:
> rgba.obj : error LNK2001: unresolved external symbol "__declspec(dllimport)
> void __cdecl boost::python::objects::register_dynamic_id_aux(struct
> boost::python::type_info,struct _STL::pair<void *,struct
> boost::python::type_info> (__cdecl*)(void *))" (
> __imp_?register_dynamic_id_aux at objects@python at boost@@YAXUtype_info at 23@P6A?AU?$
> pair at PAXUtype_info@python at boost@@@_STL@@PAX at Z@Z)

Oh, that's very different: your previous message seemed to indicate
that 3 symbols were missing. This is just one symbol. Unfortunately,
it doesn't change my response.

> > I suggest that you start with a small example using Boost.Build.
>
> Thanks, I will do just that.
> 
> One thing that I noticed after analyzing the command line generated by
> Boost.Build is that I was not specifying the path to my stlport instalation
> correctly! I corrected this, but now the msvc compiler gives internal errors
> while parsing one of the stlport's headers, _complex.h. 8(
> So, the previous unresolved externals where the result of the mixing of
> STLport and the msvc stl implementation, because like I said previously, if I
> compiled without STLport everything worked.

Yeah, that seems plausible. In particular, it was the confusion about
std::pair vs _STL::pair.

> I then compiled everything with Intel 32, without STLport, and Alas!,
> everything works nicely.

Why "alas"? Do you lament the fact that it's working?

>  (except one detail: like I said before, to embed the code in one
> executable, I compiled the static lib with BOOST_PYTHON_STATIC_LIB,
> which was giving me one unresolved external. After I removed this
> define, it compiled and linked without any error or warning).

Is there a reason you need static linking? Dynamically linking to the
boost_python dll should still work for embedding.

> After all this, another question then: How can I compile Boost.Python using
> the Intel compiler and STLport? Unfortunetely, using the native msvc stl
> libraries is not an option for me.

Use the supplied toolset?

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com




From dave at boost-consulting.com  Sun Oct 27 00:07:45 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 26 Oct 2002 18:07:45 -0400
Subject: [C++-sig] type convert: python file <-> C++ FILE*
In-Reply-To: <Pine.SGI.3.95.1021024163145.309896A-100000@blake.3dem.bioch.bcm.tmc.edu>
References: <Pine.SGI.3.95.1021024163145.309896A-100000@blake.3dem.bioch.bcm.tmc.edu>
Message-ID: <u65voetvy.fsf@boost-consulting.com>

Liwei Peng <lpeng at bcm.tmc.edu> writes:

> Hi,
> 
> I am using Boost Python V2 to wrap my C++ code. I failed
> to convert python file to/from C++ FILE*. Here is my code:
> 
> ----------------------------------------
> struct FILE_to_pyfile
> {
>     static PyObject* convert(FILE* x)
>     {        
>         return PyFile_FromFile(x, "", "", NULL);
>     }
> };
> 
> FILE* getfile(const char* fname)
> {
>     printf("openning file: %s\n", fname);
>     FILE* f = fopen(fname, "w");
>     fprintf(f, "initial words\n");
>     return f;
> }
> 
> BOOST_PYTHON_MODULE(numbermod)
> {
>     python::to_python_converter<FILE*, FILE_to_pyfile>();
>     python::def("getfile", getfile,
>                 python::return_internal_reference<>());
> }
> 
> -----------------------------------------------
> After I compiled the code, in python run
> 
>   f = getfile("hello.txt")
>   
> gave me the following error:
> 
> Traceback (most recent call last):
>   File "./test.py", line 18, in ?
>     f1 = getfile("hello.txt")
> TypeError: bad argument type for built-in operation
> 
> 
> Can you kindly tell me
>   1) what's wrong with the above code? 

The problem is that when converting a pointer to python, Boost.Python
looks up a converter for the _pointee_. So you need to register a
to_python converter for FILE, not FILE*. This should probably be a lot
clearer in my documentation than it is right now.

So I suggest as a first step:

    struct FILE_to_pyfile
    {
        static PyObject* convert(FILE const& x)
        {        
            return PyFile_FromFile(&x, "", "", NULL);
        }
    };

    FILE* getfile(const char* fname)
    {
        printf("openning file: %s\n", fname);
        FILE* f = fopen(fname, "w");
        fprintf(f, "initial words\n");
        return f;
    }

    BOOST_PYTHON_MODULE(numbermod)
    {
        python::to_python_converter<FILE, FILE_to_pyfile>();
        python::def("getfile", getfile,
                    python::return_value_policy<reference_existing_object>());
    }

However, this is really not the best arrangement, since it shouldn't
be neccessary to use return_value_policy<reference_existing_object>
for FILE*. Probably we should add converter specializations for FILE*
just as we have got for the builtin types.

>   2) The above code is from C++ 'FILE*' to python file.
>      If I want to convert python file to C++ file,
>      how can I do that?

You need to register an lvalue converter for FILE. Something like:

    struct pyfile_to_FILE
    {
        static File& execute(PyObject& o) { return *PyFile_AsFile(&o); }
    }

    // In your module init function
    lvalue_from_pytype<pyfile_to_FILE,&PyFile_Type>();

But again, I think these should probably be done by the library,
through specialization rather than dynamically registered converters.

HTH,
-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com




From nicodemus at globalite.com.br  Sun Oct 27 00:36:58 2002
From: nicodemus at globalite.com.br (Nicodemus)
Date: Sat, 26 Oct 2002 19:36:58 -0300
Subject: [C++-sig] Linking problems with msvc+stlport
References: <001601c27c96$70e723d0$0200000a@nicodemus><uwuo5l5pv.fsf@boost-consulting.com><001e01c27d25$ce8e7620$0200000a@nicodemus> <uk7k4ew30.fsf@boost-consulting.com>
Message-ID: <000d01c27d40$349b09f0$0200000a@nicodemus>

"David Abrahams" <dave at boost-consulting.com> wrote:
> > Indeed, and I was using it only because I wanted to compile boost with
> > stlport, and there's no toolset to compile intel+stlport.
>
> Huh? What's wrong with
> http://www.boost.org/tools/build/intel-win32-stlport-tools.jam?

Nothing, except that I didn't know it existed. <wink>
Seriously, I didn't found it mentioned in the documentation, but I should've
searched more. Thanks for the pointer.

> > I didn't rebuild Boost.Python with Intel 6, because I wanted to
> > build it using STLport.
>
> In theory, Intel is supposed to produce code that's link-compatible
> with that produced by msvc6. However in general that's not true of C++
> compilers and I wouldn't be at all surprised to find out that it fails
> in corner cases for msvc6 and Intel C++.

Indeed, we had some linkage problems while mixing object code compiled with
intel and msvc.

> > Unfortunetely, no. But here it is the complete error for one of the
functions:
> > rgba.obj : error LNK2001: unresolved external symbol
"__declspec(dllimport)
> > void __cdecl boost::python::objects::register_dynamic_id_aux(struct
> > boost::python::type_info,struct _STL::pair<void *,struct
> > boost::python::type_info> (__cdecl*)(void *))" (
> >
__imp_?register_dynamic_id_aux at objects@python at boost@@YAXUtype_info at 23@P6A?AU?$
> > pair at PAXUtype_info@python at boost@@@_STL@@PAX at Z@Z)
>
> Oh, that's very different: your previous message seemed to indicate
> that 3 symbols were missing. This is just one symbol. Unfortunately,
> it doesn't change my response.

Sorry for not making myself clear, but this is the error message for just one
of the symbols.


> > I then compiled everything with Intel 32, without STLport, and Alas!,
> > everything works nicely.
>
> Why "alas"? Do you lament the fact that it's working?

Ops! English is not my native language, and I thought "Alas" meant something
along the lines of "Ah?!"... sorry about that! ;)

> >  (except one detail: like I said before, to embed the code in one
> > executable, I compiled the static lib with BOOST_PYTHON_STATIC_LIB,
> > which was giving me one unresolved external. After I removed this
> > define, it compiled and linked without any error or warning).
>
> Is there a reason you need static linking? Dynamically linking to the
> boost_python dll should still work for embedding.

Oh, sorry again for not making myself clear: I compiled MY static library with
BOOST_PYTHON_STATIC_LIB, supposing that would solve the unresolved externals.
But as I understand now, this flag should be set only while build Boost.Python
for static linking, right?

> > After all this, another question then: How can I compile Boost.Python
using
> > the Intel compiler and STLport? Unfortunetely, using the native msvc stl
> > libraries is not an option for me.
>
> Use the supplied toolset?

Hehe, indeed.

And I did just that. Everything worked perfectly. 8)

Thanks again for your time and patience!
Farewell,
Nicodemus.





From dave at boost-consulting.com  Sun Oct 27 00:29:22 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 26 Oct 2002 18:29:22 -0400
Subject: [C++-sig] Linking problems with msvc+stlport
In-Reply-To: <000d01c27d40$349b09f0$0200000a@nicodemus>
References: <001601c27c96$70e723d0$0200000a@nicodemus>
	<uwuo5l5pv.fsf@boost-consulting.com>
	<001e01c27d25$ce8e7620$0200000a@nicodemus>
	<uk7k4ew30.fsf@boost-consulting.com>
	<000d01c27d40$349b09f0$0200000a@nicodemus>
Message-ID: <uu1j8debh.fsf@boost-consulting.com>

"Nicodemus" <nicodemus at globalite.com.br> writes:

> Oh, sorry again for not making myself clear: I compiled MY static library with
> BOOST_PYTHON_STATIC_LIB, supposing that would solve the unresolved externals.
> But as I understand now, this flag should be set only while build Boost.Python
> for static linking, right?

Right.

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com




From achim.domma at syynx.de  Sun Oct 27 19:11:46 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sun, 27 Oct 2002 19:11:46 +0100
Subject: [C++-sig] scope / namespace question
Message-ID: <FCEMIEFBFOIDAOJDEPIAGEBBEBAA.achim.domma@syynx.de>

Hi,

I'm exposing a lot of classes called DrawableXXX and PathXXX. I want to put
them in two sub-modules Drawable and Path, so that the python classes would
be called Drawable.XXX and Path.XXX. As far as I understand the
documentation of scope, I have to do something like this:

BOOST_PYTHON_MODULE(myModule)
{
    // register classes which are not part
    // of Drawable and Path
    // ...

    registerDrawableClasses();
    registerPathClasses();
}

void registerDrawableClasses()
{
    scope drawable = ???;
    class_<DrawableXXX>("XXX")
        .def(...
}

void registerPathClasses()
{
    scope path = ???;
    class_<PathXXX>("XXX")
        .def(...
}

In the documentation nested classes are used, so should I use an empty class
like this?

struct drawable_place_holder {};
scope drawable = class_<drawable_place_holder>("Drawable",no_init);

Is that the way to go?

greetings
Achim





From unix at psihar.net  Sun Oct 27 21:19:32 2002
From: unix at psihar.net (unix at psihar.net)
Date: Sun, 27 Oct 2002 22:19:32 +0200
Subject: [C++-sig] test
Message-ID: <200210272019.g9RKJWF5020620@psihar.net>

test



From achim.domma at syynx.de  Sun Oct 27 22:04:44 2002
From: achim.domma at syynx.de (Achim Domma)
Date: Sun, 27 Oct 2002 22:04:44 +0100
Subject: [C++-sig] fatal error C1204: compiler limit : internal structure overflow
Message-ID: <FCEMIEFBFOIDAOJDEPIAKEBEEBAA.achim.domma@syynx.de>

Hi,

I get this error with VC7: "fatal error C1204: compiler limit : internal
structure overflow". I remember that there should be a flag to change this
internal structure, but I can't remember what the flag was and how to pass
it to bjam. Any hint?

thanks
Achim





From rwgk at yahoo.com  Mon Oct 28 00:35:34 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 27 Oct 2002 15:35:34 -0800 (PST)
Subject: [C++-sig] scope / namespace question
In-Reply-To: <FCEMIEFBFOIDAOJDEPIAGEBBEBAA.achim.domma@syynx.de>
Message-ID: <20021027233534.28808.qmail@web20210.mail.yahoo.com>

--- Achim Domma <achim.domma at syynx.de> wrote:
> struct drawable_place_holder {};
> scope drawable = class_<drawable_place_holder>("Drawable",no_init);
> 
> Is that the way to go?

I don't know the answer to this question so hopefully someone else will help,
but I see two alternatives that you might want to consider:

- Simply split your module into two and put them in a package.

- Manufacture the desired Python interface at the Python level.
  For example:

  Files:
    your_module_ext.so
    your_module.py

  File you_module.py:

    from your_package import your_module_ext as ext

    class empty: pass

    Drawable = empty()
    Drawable.XXX = ext.DrawableXXX

Ralf

P.S.: The second approach allows you to do other interesting things, for
example I use this to define constructors with keywords in a very light-weight
fashion, or you could add Python-specific member functions by way of class
foo(ext.foo): ..."


__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/



From rwgk at yahoo.com  Mon Oct 28 00:40:31 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 27 Oct 2002 15:40:31 -0800 (PST)
Subject: [C++-sig] fatal error C1204: compiler limit : internal structure overflow
In-Reply-To: <FCEMIEFBFOIDAOJDEPIAKEBEEBAA.achim.domma@syynx.de>
Message-ID: <20021027234031.78053.qmail@web20209.mail.yahoo.com>

--- Achim Domma <achim.domma at syynx.de> wrote:
> I get this error with VC7: "fatal error C1204: compiler limit : internal
> structure overflow". I remember that there should be a flag to change this
> internal structure, but I can't remember what the flag was and how to pass
> it to bjam. Any hint?

I am afraid there is no flag for this. You might be thinking of the /Zm option,
but that is a different error. Most likely the only way out is to split your
module into pieces. Related message:

http://mail.python.org/pipermail/c++-sig/2002-October/002345.html

Ralf


__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/



From liwei_peng at yahoo.com  Mon Oct 28 02:59:34 2002
From: liwei_peng at yahoo.com (Liwei Peng)
Date: Sun, 27 Oct 2002 17:59:34 -0800 (PST)
Subject: [C++-sig] type convert: python file <-> C++ FILE*
Message-ID: <20021028015934.65242.qmail@web41005.mail.yahoo.com>

Hi,

For converting python file to/from C++ FILE*,
I tried the suggested code. It didn't work.
I got the same error message like before.

Here is my c++ code:
-----------------------------------------
#include <boost/python.hpp>

namespace python = boost::python;

struct FILE_to_pyfile
{
    static PyObject* convert(FILE const& x)
    {        
	return PyFile_FromFile((FILE*)(&x), "", "", NULL);
    }
};

FILE* getfile(const char* fname)
{
    printf("openning file: %s\n", fname);
    FILE* f = fopen(fname, "w");
    fprintf(f, "initial words\n");
    return f;
}

BOOST_PYTHON_MODULE(numbermod)
{
    python::to_python_converter<FILE,
FILE_to_pyfile>();
    python::def("getfile", getfile,
	
python::return_value_policy<python::reference_existing_object>());
}

--------------------------------
The only change I made to the suggested code is
to cast "&x" (whose type is const FILE*) to 'FILE*".
Without this, the code won't compile.

Here is how I compile the code:
---------------------------------
g++ -I/usr/include/python2.2 -fPIC  -c number_wrap1.C
g++ -shared number_wrap1.o  -o numbermod.so
-lboost_python

--------------------------
I am using g++ 3.2, python 2.2.1.

The error message from python code:
-------------------------------------------

Python 2.2.1 (#1, Sep  9 2002, 09:26:21)
[GCC 3.2 (Mandrake Linux 9.0 3.2-1mdk)] on linux-i386
Type "help", "copyright", "credits" or "license" for
more information.
>>>
>>> from numbermod import *
>>> f = getfile('hello.txt')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: bad argument type for built-in operation
>>>

Can anyone please help me out?

Thanks in advance,

liwei

__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/



From liwei_peng at yahoo.com  Mon Oct 28 04:32:09 2002
From: liwei_peng at yahoo.com (Liwei Peng)
Date: Sun, 27 Oct 2002 19:32:09 -0800 (PST)
Subject: [C++-sig] boost python v2: error with both default arg and pointer-return function
Message-ID: <20021028033209.68378.qmail@web41011.mail.yahoo.com>

Hi,

When using the boost python v2 to port a C++ member
function like the following, I got an error with
message
"TypeError: bad argument type for built-in operation".

   class A;
   A* MyClass::foo(int n = 100);

This only happens when a member function
  a) has a default argument;
  b) returns a pointer value.

Here is my related C++ code:

----------------------------------------------
class Number {
public:
    Number(int n);
    Number* copy(int n = 100);
};

Number* Number::copy(int n)
{
    printf("number of copies = %d\n", n);
    return this;
}

BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS(copy_overloads,
copy, 0, 1);

BOOST_PYTHON_MODULE(numbermod)
{
    python::class_<Number> number_class("Number",
python::init<int>());
    
    number_class.def("copy", &Number::copy,
		     python::return_internal_reference<>(),
		     copy_overloads());
}

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

python code:

----------------------------------------
from numbermod import *

n = Number(10)
n1 = n.copy()
----------------------------------------

error message:

----------------------------------------
Traceback (most recent call last):
  File "./test.py", line 19, in ?
    n1 = n.copy()
TypeError: bad argument type for built-in operation


Can anyone please tell me what's wrong?

Thanks.

Liwei


__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/



From dave at boost-consulting.com  Mon Oct 28 04:25:39 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 27 Oct 2002 22:25:39 -0500
Subject: [C++-sig] scope / namespace question
In-Reply-To: <FCEMIEFBFOIDAOJDEPIAGEBBEBAA.achim.domma@syynx.de>
References: <FCEMIEFBFOIDAOJDEPIAGEBBEBAA.achim.domma@syynx.de>
Message-ID: <uiszndz2k.fsf@boost-consulting.com>

"Achim Domma" <achim.domma at syynx.de> writes:

> Hi,
> 
> I'm exposing a lot of classes called DrawableXXX and PathXXX. I want to put
> them in two sub-modules Drawable and Path, so that the python classes would
> be called Drawable.XXX and Path.XXX. As far as I understand the
> documentation of scope, I have to do something like this:
> 
> BOOST_PYTHON_MODULE(myModule)
> {
>     // register classes which are not part
>     // of Drawable and Path
>     // ...
> 
>     registerDrawableClasses();
>     registerPathClasses();
> }
> 
> void registerDrawableClasses()
> {
>     scope drawable = ???;
>     class_<DrawableXXX>("XXX")
>         .def(...
> }
> 
> void registerPathClasses()
> {
>     scope path = ???;
>     class_<PathXXX>("XXX")
>         .def(...
> }
> 
> In the documentation nested classes are used, so should I use an empty class
> like this?
> 
> struct drawable_place_holder {};
> scope drawable = class_<drawable_place_holder>("Drawable",no_init);
> 
> Is that the way to go?

No, just use the Python/'C' API to create a new module object, grab it
with a handle<>. Something like:

   handle<> inner_module(PyModule_New("myModule.Drawable"));
   scope drawable = object(inner_module);

...but look in the Python docs for the right way to use the module
creation functions. Don't expect the above to work verbatim.

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com




From grafik666 at redshift-software.com  Mon Oct 28 05:00:09 2002
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Sun, 27 Oct 2002 22:00:09 -0600
Subject: [C++-sig] MacOSX building... of shared libraries...
Message-ID: <20021027220010-r01010800-f9f077e7-0860-0108@12.100.89.43>

I've been working on the "darwin-tools.jam" toolset to try and get Boost &
Boost.Python working on MacoOSX. (Thanks to Ralf for access to the MacOSX
machine :-)

...And here are some conclusions...

The toolset is minimally working for standard compilation. But the
compilation of shared libraries is limited at best. That is the toolset is
working to generate both "dylib" and "bundle" type shared libraries. The
problem is... that this doesn't work for Boost.Python in it's current form.

After much reading and many different attempts I've learned some things
about MacOSX.

1. "dylib" shared libraries are what I would consider standard shared
libraries in the Unix sense.
2. "bundle" shared libraries are what Apple thinks application plugins
should be like.

That's all nice, but the way Apple changed the compiler, linker, and loader
to implement that makes the above arrangement problematic for code like
Boost.Python. The problems are:

a. "dylib" shared libraries don't seem to support resolving of symbols back
from the application loading the library. Like the AIX loading problem.

...not a problem, after all that's what "bundles" are for, right? but...

b. "bundle" shared libraries do resolve the symbols from the loader context
as long as you specify the loader binary when linking, using the
-bundle_loader flag. And the current build system files in CVS do this when
using the darwin toolset. But bundles have one limitation, they can't depend
on other bundles. So if I build boost_python as a bundle, other python
extensions can't use it as a dependence as one would in Linux.

So I have two options, neither of which work for Boost.Python. So if anyone
has suggestions or insights I would welcome them ;-\

Or for that matter.. is there any way to rearrange the Boost.Python code so
that is doesn't need to link against the python executable? Which would turn
it into what Apple calls a framework, to break the inter-dependence problem.


-- grafik - Don't Assume Anything
-- rrivera at acm.org - grafik at redshift-software.com
-- 102708583 at icq - Grafik666 at AIM - Grafik at jabber.org



From rwgk at yahoo.com  Mon Oct 28 06:05:44 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 27 Oct 2002 21:05:44 -0800 (PST)
Subject: [C++-sig] MacOSX building... of shared libraries...
In-Reply-To: <20021027220010-r01010800-f9f077e7-0860-0108@12.100.89.43>
Message-ID: <20021028050544.3154.qmail@web20207.mail.yahoo.com>

--- Rene Rivera <grafik666 at redshift-software.com> wrote:
> Or for that matter.. is there any way to rearrange the Boost.Python code so
> that is doesn't need to link against the python executable? Which would turn
> it into what Apple calls a framework, to break the inter-dependence problem.

Did you consider linking against libpython2.2.a ? I just checked, this file is
missing in the /usr/lib/python2.2/config directory supplied by Apple. However,
there is now a Python 2.2.2 installation in /usr/local_cci/Python-2.2.2t (t =
threaded) with a file
/usr/local_cci/Python-2.2.2t/lib/python2.2/config/libpython2.2.a .

Ralf


__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/



From dave at boost-consulting.com  Mon Oct 28 05:50:18 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 27 Oct 2002 23:50:18 -0500
Subject: [C++-sig] type convert: python file <-> C++ FILE*
In-Reply-To: <20021028015934.65242.qmail@web41005.mail.yahoo.com>
References: <20021028015934.65242.qmail@web41005.mail.yahoo.com>
Message-ID: <uof9fcgl1.fsf@boost-consulting.com>

Liwei Peng <liwei_peng at yahoo.com> writes:

> Hi,
> 
> For converting python file to/from C++ FILE*,
> I tried the suggested code. It didn't work.
> I got the same error message like before.

Sorry. Try the following, which works for me:

  #include <boost/python.hpp>
  #include <stdio.h>

  namespace python = boost::python;

  struct FILE_to_pyfile
  {
      static PyObject* convert(FILE* x)
      {        
          return PyFile_FromFile(x, "", "", NULL);
      }
  };

  FILE* getfile(const char* fname)
  {
      printf("openning file: %s\n", fname);
      FILE* f = fopen(fname, "w");
      fprintf(f, "initial words\n");
      return f;
  }

  BOOST_PYTHON_MODULE(numbermod)
  {
      python::to_python_converter<FILE*, FILE_to_pyfile>();
      python::def("getfile", getfile
                 , python::return_value_policy<python::return_by_value>());
  }

> Can anyone please help me out?

I hope this gets you past the problem. As I said before, these
conversions should be built-in so you don't have to provide
special call policies yourself.

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com




From dave at boost-consulting.com  Mon Oct 28 05:54:15 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 27 Oct 2002 23:54:15 -0500
Subject: [C++-sig] boost python v2: error with both default arg and pointer-return function
In-Reply-To: <20021028033209.68378.qmail@web41011.mail.yahoo.com>
References: <20021028033209.68378.qmail@web41011.mail.yahoo.com>
Message-ID: <uk7k3cgeg.fsf@boost-consulting.com>

Liwei Peng <liwei_peng at yahoo.com> writes:

> Hi,
> 
> When using the boost python v2 to port a C++ member
> function like the following, I got an error with
> message
> "TypeError: bad argument type for built-in operation".
> 
>    class A;
>    A* MyClass::foo(int n = 100);
> 
> This only happens when a member function
>   a) has a default argument;
>   b) returns a pointer value.
> 
> Can anyone please tell me what's wrong?

It has nothing to do with the pointer value. If you want to wrap
functions with default arguments so that you can omit them when called
from Python, you have to remember that the defaults are not part of
the type of the function pointer, and use the techniques described in:

  http://www.boost.org/libs/python/doc/tutorial/doc/default_arguments.html

and

  http://www.boost.org/libs/python/doc/v2/overloads.html

HTH,
-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com




From grafik666 at redshift-software.com  Mon Oct 28 06:20:12 2002
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Sun, 27 Oct 2002 23:20:12 -0600
Subject: [C++-sig] MacOSX building... of shared libraries...
In-Reply-To: <20021028050544.3154.qmail@web20207.mail.yahoo.com>
Message-ID: <20021027232012-r01010800-8ac60f3a-0860-0108@12.100.89.43>

[2002-10-27] Ralf W. Grosse-Kunstleve wrote:

>--- Rene Rivera <grafik666 at redshift-software.com> wrote:
>> Or for that matter.. is there any way to rearrange the Boost.Python code
so
>> that is doesn't need to link against the python executable? Which would
turn
>> it into what Apple calls a framework, to break the inter-dependence
problem.
>
>Did you consider linking against libpython2.2.a ? I just checked, this file
is
>missing in the /usr/lib/python2.2/config directory supplied by Apple.
However,
>there is now a Python 2.2.2 installation in /usr/local_cci/Python-2.2.2t (t
=
>threaded) with a file
>/usr/local_cci/Python-2.2.2t/lib/python2.2/config/libpython2.2.a .

No, and yes... I looked for such a thing but didn't find it. Thanks for
pointing it out I'll try that and see if it makes things easier.


-- grafik - Don't Assume Anything
-- rrivera at acm.org - grafik at redshift-software.com
-- 102708583 at icq - Grafik666 at AIM - Grafik at jabber.org



From rwgk at yahoo.com  Mon Oct 28 06:27:04 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 27 Oct 2002 21:27:04 -0800 (PST)
Subject: [C++-sig] type convert: python file <-> C++ FILE*
In-Reply-To: <20021028015934.65242.qmail@web41005.mail.yahoo.com>
Message-ID: <20021028052704.5535.qmail@web20207.mail.yahoo.com>

--- Liwei Peng <liwei_peng at yahoo.com> wrote:
> FILE* getfile(const char* fname)
> {
>     printf("openning file: %s\n", fname);
>     FILE* f = fopen(fname, "w");
>     fprintf(f, "initial words\n");
>     return f;
> }

This doesn't work for me as well, using compiler options that work for
everything else. I've verified that the custom converter works in general by
changing the signature to FILE getfile(...) and return *f, but it does not work
with the signature above or FILE& getfile(...).
Ralf


__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/



From rwgk at yahoo.com  Mon Oct 28 06:53:43 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 27 Oct 2002 21:53:43 -0800 (PST)
Subject: [C++-sig] type convert: python file <-> C++ FILE*
In-Reply-To: <uof9fcgl1.fsf@boost-consulting.com>
Message-ID: <20021028055343.51579.qmail@web20206.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> I hope this gets you past the problem. As I said before, these
> conversions should be built-in so you don't have to provide
> special call policies yourself.

Thanks, David!

The code didn't work with my CVS branch from Oct 11, which I believe is just
boost 1.29.0. But it works with gcc 3.2 and the current CVS.

Ralf


__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/



From dave at boost-consulting.com  Mon Oct 28 08:21:56 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 28 Oct 2002 02:21:56 -0500
Subject: [C++-sig] Tutorial
In-Reply-To: <00ed01c2ab9e$3548c860$16be8aca@kim>
References: <bea90007017200f96d981334ba3521e03daf1905@>
	<ud6q8bzo7.fsf@boost-consulting.com> <3DB8311C.299058B5@llnl.gov>
	<uy98nsocf.fsf@boost-consulting.com>
	<00ed01c2ab9e$3548c860$16be8aca@kim>
Message-ID: <u65vnc9kb.fsf@boost-consulting.com>

"Joel de Guzman" <djowel at gmx.co.uk> writes:

> ----- Original Message ----- 
> From: "David Abrahams" <dave at boost-consulting.com>
> 
> > > 
> > >     class_<Num>("Num")
> > >              .add_property("rovalue", &Var::get)
> > >              .add_property("value", &Var::get, &Var::set);
> > > 
> > > It should be &Num::get and &Num::set.
> > 
> > Thanks. Joel, would you make this fix?
> 
> Done. Plus some more. Please check the stuff in the CVS if it is
> up to your standards :-)

Hard to tell. quickstart.txt hasn't been updated since 10/10.
What's going on? Did you forget to commit changes?

> --Joel
> 
> PS> Is there a target date for boost 1.29.1 ?

Not yet. I'll probably try to start something early next month.

P.S. Congratulations on Spirit!!

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com




From dave at boost-consulting.com  Mon Oct 28 08:30:55 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 28 Oct 2002 02:30:55 -0500
Subject: [C++-sig] Re: [jamboost] MacOSX building... of shared libraries...
In-Reply-To: <20021027220010-r01010800-f9f077e7-0860-0108@12.100.89.43>
References: <20021027220010-r01010800-f9f077e7-0860-0108@12.100.89.43>
Message-ID: <uwuo3aukw.fsf@boost-consulting.com>

Rene Rivera <grafik666 at redshift-software.com> writes:

> I've been working on the "darwin-tools.jam" toolset to try and get Boost &
> Boost.Python working on MacoOSX. (Thanks to Ralf for access to the MacOSX
> machine :-)
> 
> ...And here are some conclusions...

Rene,

Thanks for pursuing this. I've forwarded your message to my contact on
the Apple compiler team. Maybe it will lead somewhere...

-Dave

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com




From djowel at gmx.co.uk  Mon Oct 28 09:06:14 2002
From: djowel at gmx.co.uk (Joel de Guzman)
Date: Mon, 28 Oct 2002 16:06:14 +0800
Subject: [C++-sig] Tutorial
References: <bea90007017200f96d981334ba3521e03daf1905@><ud6q8bzo7.fsf@boost-consulting.com> <3DB8311C.299058B5@llnl.gov><uy98nsocf.fsf@boost-consulting.com><00ed01c2ab9e$3548c860$16be8aca@kim> <u65vnc9kb.fsf@boost-consulting.com>
Message-ID: <002501c27e58$e5e58000$0100a8c0@kim>

----- Original Message ----- 
From: "David Abrahams" <dave at boost-consulting.com>
To: <c++-sig at python.org>
Sent: Monday, October 28, 2002 3:21 PM
Subject: Re: [C++-sig] Tutorial


> "Joel de Guzman" <djowel at gmx.co.uk> writes:
> 
> > ----- Original Message ----- 
> > From: "David Abrahams" <dave at boost-consulting.com>
> > 
> > > > 
> > > >     class_<Num>("Num")
> > > >              .add_property("rovalue", &Var::get)
> > > >              .add_property("value", &Var::get, &Var::set);
> > > > 
> > > > It should be &Num::get and &Num::set.
> > > 
> > > Thanks. Joel, would you make this fix?
> > 
> > Done. Plus some more. Please check the stuff in the CVS if it is
> > up to your standards :-)
> 
> Hard to tell. quickstart.txt hasn't been updated since 10/10.
> What's going on? Did you forget to commit changes?

The html files are updated. I failed to update the quickstart.txt.
Duh! 

> > --Joel
> > 
> > PS> Is there a target date for boost 1.29.1 ?
> 
> Not yet. I'll probably try to start something early next month.
> 
> P.S. Congratulations on Spirit!!

Thanks!

--Joel




From tom at muzzylane.com  Mon Oct 28 23:03:15 2002
From: tom at muzzylane.com (tom)
Date: Mon, 28 Oct 2002 17:03:15 -0500
Subject: [C++-sig] Creating python objects from C++
Message-ID: <000001c27ecd$d141a190$6501a8c0@TOMSDELL>

Hi
 
I'm embedding a Python interpreter in a C++ application and am trying to
use Boost.Python to connect the two.  I've got it hooked up and can
access my application from Python, and subclass C++ objects inside the
interpreter and it works perfectly!
 
The tricky part is that I need to drive this process from the C++ side,
instead of the Python side.  I need the ability to extend C++ objects
with Python methods, but to create and maintain those objects from C++.
I haven't seen anything in the mailing list or the docs about how to do
this.
 
I've been trying to pass back the PyTypeObject* for a given class back
to C++ and create the objects using the _PyObject_New function described
in the Python documentation, but I haven't been able to pass it back to
C++.  I get 
 
"TypeError: No registered converter was able to extract a C++ reference
to type struct _typeobject from this Python object of type
Boost.Python.class."
 
Is there a better way to do this? Or if not, what's the best way to
write a converter to pull out the PyTypeObject information?
 
Thanks
Tom McCormack
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20021028/d1a44fe5/attachment.htm>

From grafik666 at redshift-software.com  Mon Oct 28 23:23:08 2002
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Mon, 28 Oct 2002 16:23:08 -0600
Subject: [C++-sig] MacOSX building... of shared libraries...
In-Reply-To: <20021028050544.3154.qmail@web20207.mail.yahoo.com>
Message-ID: <20021028162309-r01010800-6985b37e-0860-0108@12.100.89.43>

[2002-10-27] Ralf W. Grosse-Kunstleve wrote:

>--- Rene Rivera <grafik666 at redshift-software.com> wrote:
>> Or for that matter.. is there any way to rearrange the Boost.Python code
so
>> that is doesn't need to link against the python executable? Which would
turn
>> it into what Apple calls a framework, to break the inter-dependence
problem.
>
>Did you consider linking against libpython2.2.a ? I just checked, this file
is
>missing in the /usr/lib/python2.2/config directory supplied by Apple.
However,
>there is now a Python 2.2.2 installation in /usr/local_cci/Python-2.2.2t (t
=
>threaded) with a file
>/usr/local_cci/Python-2.2.2t/lib/python2.2/config/libpython2.2.a .

OK... more results and observations...

Using libpython2.2.a does help! After making more changes, to build dylibs
instead of bundles. Which requires a fun trick I've used before of double
linking, in this case to resolve common symbols defined in libpython. I
managed to get the minimal _ext to link correctly :-)

...Now the revelations, and more problems...

Python wants *.so files instead of *.dylib files, I'm talking names not type
here. Not a problem after all it's just a name. So I rename the file and try
again and boom Python complains with:

"ImportError: Inappropriate file type for dynamic loading"

Which means that Python can, so far, only load MacOSX "bundles". So even
though the libpython helps me create dynamic libs that correctly reference
each other and Python. One can't load them anyway :-(

So this problem goes back to Apple... How does one create bundles that can
refer to other bundles? If it's even possible!


-- grafik - Don't Assume Anything
-- rrivera at acm.org - grafik at redshift-software.com
-- 102708583 at icq - Grafik666 at AIM - Grafik at jabber.org



From rwgk at yahoo.com  Tue Oct 29 01:12:30 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 28 Oct 2002 16:12:30 -0800 (PST)
Subject: [C++-sig] MacOSX building... of shared libraries...
In-Reply-To: <20021028162309-r01010800-6985b37e-0860-0108@12.100.89.43>
Message-ID: <20021029001230.57114.qmail@web20205.mail.yahoo.com>

--- Rene Rivera <grafik666 at redshift-software.com> wrote:
> OK... more results and observations...
> 
> Using libpython2.2.a does help! After making more changes, to build dylibs
> instead of bundles. Which requires a fun trick I've used before of double
> linking, in this case to resolve common symbols defined in libpython. I
> managed to get the minimal _ext to link correctly :-)

Wow, it sounds like you are getting really close!

> ...Now the revelations, and more problems...
> 
> Python wants *.so files instead of *.dylib files, I'm talking names not type
> here. Not a problem after all it's just a name. So I rename the file and try
> again and boom Python complains with:
> 
> "ImportError: Inappropriate file type for dynamic loading"
> 
> Which means that Python can, so far, only load MacOSX "bundles". So even
> though the libpython helps me create dynamic libs that correctly reference
> each other and Python. One can't load them anyway :-(

Ideas:

- Describe your remaining problem to Jack Janssen (http://www.cwi.nl/~jack/).
He is maintaining the Python Apple port. He must have had similar problems when
porting the standard Python "C" extension modules (e.g. all the files in
/usr/local_cci/Python-2.2.2t/lib/python2.2/lib-dynload).

- Run the Python installation to see how the standard modules are built.

- This is a wild one: make a "thin bundle" that dispatches to the dynamic libs
that you have already.

Ralf


__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/



From grafik666 at redshift-software.com  Tue Oct 29 06:57:32 2002
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Mon, 28 Oct 2002 23:57:32 -0600
Subject: [C++-sig] MacOSX building... of shared libraries...
In-Reply-To: <20021029001230.57114.qmail@web20205.mail.yahoo.com>
Message-ID: <20021028235733-r01010800-7992a91f-0860-0108@12.100.89.43>

[2002-10-28] Ralf W. Grosse-Kunstleve wrote:

>--- Rene Rivera <grafik666 at redshift-software.com> wrote:
>> OK... more results and observations...
>> 
>> Using libpython2.2.a does help! After making more changes, to build
dylibs
>> instead of bundles. Which requires a fun trick I've used before of double
>> linking, in this case to resolve common symbols defined in libpython. I
>> managed to get the minimal _ext to link correctly :-)
>
>Wow, it sounds like you are getting really close!

So close, yet so far :-(

>Ideas:
>
>- Describe your remaining problem to Jack Janssen
(http://www.cwi.nl/~jack/).
>He is maintaining the Python Apple port. He must have had similar problems
when
>porting the standard Python "C" extension modules (e.g. all the files in
>/usr/local_cci/Python-2.2.2t/lib/python2.2/lib-dynload).

I looked at some of his documentation, and some of the code, and tried a few
things out.

>- Run the Python installation to see how the standard modules are built.

Did that... the Python installation fails to compile. It was rather funny,
it failed right at the last link because it was trying to link "python" but
there already existed a "Python" directory.


All in all I did manage to make more progress... After some thinking I came
up with this arragement:

    1. Build libboost_python as a dylib, shared library that is linked to
libpython*.a
    2. Build the extensions as a bundle, that load from the "python2.2"
executable.

That not only links, but also runs, that is it loads the module... almost!
This is when I ran into the last problem. Because libboost_python links to
libpython*.a and the extentions to python2.2(exe), the loader (MacOSX dyld)
barfs from duplicate symbol clashes. All kinds of Python(_Py*) symbols that
are defined in both the executable and the library. The reason... python2.2
is not normally linked to the common library, and that is an insurmountable
arrangement. So this approach is failure :-( --- for now...

But there is an ultimate solution to the problem... Boost.Python will have
to wait for Python2.3. With it one should be able to have the commandline
python built as a MacOSX Framework (fancy term for shared library). That way
everybody links to the framework and no more duplicate symbols. Hooray.


-- grafik - Don't Assume Anything
-- rrivera at acm.org - grafik at redshift-software.com
-- 102708583 at icq - Grafik666 at AIM - Grafik at jabber.org



From BPettersen at NAREX.com  Tue Oct 29 18:56:17 2002
From: BPettersen at NAREX.com (Bjorn Pettersen)
Date: Tue, 29 Oct 2002 10:56:17 -0700
Subject: [C++-sig] boost.python coredump in debug mode..?
Message-ID: <60FB8BB7F0EFC7409B75EEEC13E2019201774315@admin56.narex.com>

I'm working through the tutorial introduction, and I'm getting a strange
coredump in a debug build. I'm at the struct World example with a
constructor:

>>> import hello
>>> x = hello.World('hi')
>>> x.greet()
'hi'
>>> hello.World('hi') # if I remove this I don't get a coredump
<hello.World object at 0x0089E748>
>>> x.greet()
[coredump]

The exact message is "Debug Assertion Failed! File: dbgheap.c Line 1044
Expression _CrtIsValidHeapPointer(pUserData)". I'm using msvc6 on winxp
and the release version works fine. Am I doing something wrong?

-- bjorn

Bjorn Pettersen
NAREX Inc.
303.526.4000 ext. 312
303.526.5130 fax
www.narex.com



From nobody at maui.dnsvault.com  Wed Oct 30 01:26:18 2002
From: nobody at maui.dnsvault.com (Nobody)
Date: Tue, 29 Oct 2002 19:26:18 -0500
Subject: [C++-sig] A larger gold balance!
Message-ID: <E186ggc-0005W0-00@maui.dnsvault.com>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20021029/affeff85/attachment.htm>

From dave at boost-consulting.com  Wed Oct 30 03:51:51 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 29 Oct 2002 21:51:51 -0500
Subject: [C++-sig] boost.python coredump in debug mode..?
In-Reply-To: <60FB8BB7F0EFC7409B75EEEC13E2019201774315@admin56.narex.com>
References: <60FB8BB7F0EFC7409B75EEEC13E2019201774315@admin56.narex.com>
Message-ID: <uu1j4k5a0.fsf@boost-consulting.com>

"Bjorn Pettersen" <BPettersen at NAREX.com> writes:

> I'm working through the tutorial introduction, and I'm getting a strange
> coredump in a debug build. I'm at the struct World example with a
> constructor:
> 
> >>> import hello
> >>> x = hello.World('hi')
> >>> x.greet()
> 'hi'
> >>> hello.World('hi') # if I remove this I don't get a coredump
> <hello.World object at 0x0089E748>
> >>> x.greet()
> [coredump]
> 
> The exact message is "Debug Assertion Failed! File: dbgheap.c Line 1044
> Expression _CrtIsValidHeapPointer(pUserData)". I'm using msvc6 on winxp
> and the release version works fine. Am I doing something wrong?

Perhaps you didn't carefully read the section on build variants at
http://www.boost.org/libs/python/building.html?

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com




From dave at boost-consulting.com  Wed Oct 30 05:59:47 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 29 Oct 2002 23:59:47 -0500
Subject: [C++-sig] Creating python objects from C++
In-Reply-To: <000001c27ecd$d141a190$6501a8c0@TOMSDELL>
References: <000001c27ecd$d141a190$6501a8c0@TOMSDELL>
Message-ID: <uadkwh67w.fsf@boost-consulting.com>

"tom" <tom at muzzylane.com> writes:

> Hi
>  
> I'm embedding a Python interpreter in a C++ application and am trying to
> use Boost.Python to connect the two.  I've got it hooked up and can
> access my application from Python, and subclass C++ objects inside the
> interpreter and it works perfectly!
>  
> The tricky part is that I need to drive this process from the C++ side,
> instead of the Python side.  I need the ability to extend C++ objects
> with Python methods, but to create and maintain those objects from C++.
> I haven't seen anything in the mailing list or the docs about how to do
> this.

See the example at the bottom of 

   http://www.boost.org/libs/python/doc/v2/extract.html

Does that help?

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com




From BPettersen at NAREX.com  Wed Oct 30 17:54:55 2002
From: BPettersen at NAREX.com (Bjorn Pettersen)
Date: Wed, 30 Oct 2002 09:54:55 -0700
Subject: [C++-sig] boost.python coredump in debug mode..?
Message-ID: <60FB8BB7F0EFC7409B75EEEC13E201920177437C@admin56.narex.com>

> From: David Abrahams [mailto:dave at boost-consulting.com] 
> 
> "Bjorn Pettersen" <BPettersen at NAREX.com> writes:
> 
> > I'm working through the tutorial introduction, and I'm getting a 
> > strange coredump in a debug build. I'm at the struct World example 
> > with a constructor:
[snip]
> 
> Perhaps you didn't carefully read the section on build 
> variants at http://www.boost.org/libs/python/building.html?

I got a 404 with that link, but I did read the Build Variants section at
http://www.boost.org/libs/python/doc/building.html and I must be dense
because I still can't get it to work. I included
<boost/python/detail/wrap_python.hpp> at the top of my file, defined
_DEBUG, and linked with either boost_python.lib or
boost_python_debug.lib and I'm always getting the coredump. I'm sure I'm
missing something obvious....

-- bjorn





From dave at boost-consulting.com  Wed Oct 30 23:03:14 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 30 Oct 2002 17:03:14 -0500
Subject: [C++-sig] boost.python coredump in debug mode..?
In-Reply-To: <60FB8BB7F0EFC7409B75EEEC13E201920177437C@admin56.narex.com>
References: <60FB8BB7F0EFC7409B75EEEC13E201920177437C@admin56.narex.com>
Message-ID: <uhef38tzx.fsf@boost-consulting.com>

"Bjorn Pettersen" <BPettersen at NAREX.com> writes:

> > From: David Abrahams [mailto:dave at boost-consulting.com] 
> > 
> > "Bjorn Pettersen" <BPettersen at NAREX.com> writes:
> > 
> > > I'm working through the tutorial introduction, and I'm getting a 
> > > strange coredump in a debug build. I'm at the struct World example 
> > > with a constructor:
> [snip]
> > 
> > Perhaps you didn't carefully read the section on build 
> > variants at http://www.boost.org/libs/python/building.html?
> 
> I got a 404 with that link, but I did read the Build Variants section at
> http://www.boost.org/libs/python/doc/building.html and I must be dense
> because I still can't get it to work. I included
> <boost/python/detail/wrap_python.hpp> at the top of my file, defined
> _DEBUG, and linked with either boost_python.lib or
> boost_python_debug.lib and I'm always getting the coredump. I'm sure I'm
> missing something obvious....

What was the test case again?

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com




From BPettersen at NAREX.com  Wed Oct 30 23:59:47 2002
From: BPettersen at NAREX.com (Bjorn Pettersen)
Date: Wed, 30 Oct 2002 15:59:47 -0700
Subject: [C++-sig] boost.python coredump in debug mode..?
Message-ID: <60FB8BB7F0EFC7409B75EEEC13E20192017743CC@admin56.narex.com>

> From: David Abrahams [mailto:dave at boost-consulting.com] 
> 
> "Bjorn Pettersen" <BPettersen at NAREX.com> writes:
> 
> > > From: David Abrahams [mailto:dave at boost-consulting.com]
> > > 
> > > "Bjorn Pettersen" <BPettersen at NAREX.com> writes:
> > > 
> > > > I'm working through the tutorial introduction, and I'm getting a
> > > > strange coredump in a debug build. I'm at the struct 
> World example 
> > > > with a constructor:
> > [snip]
> > > 
> > > Perhaps you didn't carefully read the section on build
> > > variants at http://www.boost.org/libs/python/building.html?
> > 
> > I got a 404 with that link, but I did read the Build 
> Variants section 
> > at http://www.boost.org/libs/python/doc/building.html and I must be 
> > dense because I still can't get it to work. I included 
> > <boost/python/detail/wrap_python.hpp> at the top of my 
> file, defined 
> > _DEBUG, and linked with either boost_python.lib or 
> > boost_python_debug.lib and I'm always getting the coredump. 
> I'm sure 
> > I'm missing something obvious....
> 
> What was the test case again?

>>> import hello
>>> x = hello.World('hi')
>>> hello.World('hi')    # this call...
<hello.World object at 0x0089E748>
>>> x.greet()            # ... causes this to coredump

with the code at
http://www.boost.org/libs/python/doc/tutorial/doc/constructors.html

-- bjorn



From BPettersen at NAREX.com  Thu Oct 31 02:07:34 2002
From: BPettersen at NAREX.com (Bjorn Pettersen)
Date: Wed, 30 Oct 2002 18:07:34 -0700
Subject: [C++-sig] How do I wrap a C++ object to a PyObject*
Message-ID: <60FB8BB7F0EFC7409B75EEEC13E20192017743D8@admin56.narex.com>

I'm trying to embed Python in my C++ application, and it looks pretty
easy to convert a PyObject* returned from PyRun_String using the
'extract' functionality. How do I go the other way? I.e. I want to set a
variable in __main__ to an instance of my C++ class (or pass them as
arguments to PyObject_CallFunctionObjArgs). With SIP there was a
function called sipMapCppToSelf used like this:

	void set(const std::string& name, const LegalStatusCode& value)
{
	    PyObject* key = PyString_FromString(name.c_str());
	    PyObject* val = sipMapCppToSelf(&value,
sipClass_LegalStatusCode);
	    PyDict_SetItem(mainmodule, key, val);
	    Py_DECREF(key);
	    Py_DECREF(val);
	}

I've looked through the documentation but haven't found anything
obvious...

-- bjorn



From dave at boost-consulting.com  Thu Oct 31 05:17:18 2002
From: dave at boost-consulting.com (David Abrahams)
Date: 30 Oct 2002 23:17:18 -0500
Subject: [C++-sig] How do I wrap a C++ object to a PyObject*
In-Reply-To: <60FB8BB7F0EFC7409B75EEEC13E20192017743D8@admin56.narex.com>
References: <60FB8BB7F0EFC7409B75EEEC13E20192017743D8@admin56.narex.com>
Message-ID: <u7kfz6y41.fsf@boost-consulting.com>

"Bjorn Pettersen" <BPettersen at NAREX.com> writes:

> I'm trying to embed Python in my C++ application, and it looks pretty
> easy to convert a PyObject* returned from PyRun_String using the
> 'extract' functionality. How do I go the other way? I.e. I want to set a
> variable in __main__ to an instance of my C++ class (or pass them as
> arguments to PyObject_CallFunctionObjArgs). With SIP there was a
> function called sipMapCppToSelf used like this:
> 
> 	void set(const std::string& name, const LegalStatusCode& value)
> {
> 	    PyObject* key = PyString_FromString(name.c_str());
> 	    PyObject* val = sipMapCppToSelf(&value,
> sipClass_LegalStatusCode);
> 	    PyDict_SetItem(mainmodule, key, val);
> 	    Py_DECREF(key);
> 	    Py_DECREF(val);
> 	}
> 
> I've looked through the documentation but haven't found anything
> obvious...

Let's see. You have a wrapped C++ class somewhere?
If so, you can write in __main__:

  import some_boost_python_module
  x = some_boost_python_module.some_class(some_arg)

But this is trivially explained in the docs, so you must mean
something else...

-- 
                    David Abrahams
dave at boost-consulting.com * http://www.boost-consulting.com




From grafik666 at redshift-software.com  Thu Oct 31 06:25:32 2002
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Wed, 30 Oct 2002 23:25:32 -0600
Subject: [C++-sig] More MacOSX & Python - 2.3
Message-ID: <20021030232533-r01010800-64682719-0860-0108@12.100.89.43>

Well thanks again to Ralf for doing some of the MacOSX work... and figuring
out how to install the latest Python as a framework.

Good news is...

* Extensions and libboost_python build and link. That is the ones that
compile.
* Of the ones that produce an extension they are loaded by the Python
interpreter.
* Of the ones that load, some of them seem to run to completion, and what
looks like without errors.

Bad news...

* Only a small number of them compile. The single compile problem is this
error:

In file included from
/net/taipan/scratch1/grafik/boost/boost/python/class.hpp:11,
                 from args.cpp:10:
/net/taipan/scratch1/grafik/boost/boost/python/bases.hpp:19: parse error
before 
   numeric constant
/net/taipan/scratch1/grafik/boost/boost/python/bases.hpp:24: confused by
earlier errors, bailing out

* Of the ones that compile and load, the majority seem to just hang there
doing nothing for some time. After some short period of time (~1 minute) I
killed the Python interpreter. Don't know why this is, but it could be
something as silly as it deciding to open a dialog box I can't see and is
waiting for never to arrive feedback.

There is one change I had to make to Boost.Python code to even get this far:

Index: rvalue_from_python_data.hpp
===================================================================
RCS file:
/cvsroot/boost/boost/boost/python/converter/rvalue_from_python_data.hpp,v
retrieving revision 1.10
diff -b -u -2 -r1.10 rvalue_from_python_data.hpp
--- rvalue_from_python_data.hpp 12 Oct 2002 15:37:33 -0000  1.10
+++ rvalue_from_python_data.hpp 31 Oct 2002 04:57:49 -0000
@@ -98,5 +98,5 @@
         && !defined(BOOST_PYTHON_SYNOPSIS) /* Synopsis' OpenCXX has trouble
parsing this */
     // This must always be a POD struct with m_data its first member.
-   
BOOST_STATIC_ASSERT(BOOST_PYTHON_OFFSETOF(rvalue_from_python_storage<T>,stage1)
== 0);
+   
//BOOST_STATIC_ASSERT(BOOST_PYTHON_OFFSETOF(rvalue_from_python_storage<T>,stage1)
== 0);
 # endif

If that BOOST_STATIC_ASSERT is not commented out the compiler chokes with an
can't-do-that/unimplemented error.

I'm attachinng the test output just in case it usefull in some form.

The setup for compilation is like so:

PYTHON_ROOT=/Library/Frameworks/Python.framework/Versions/2.3
PYTHON_VERSION=2.3


-- grafik - Don't Assume Anything
-- rrivera at acm.org - grafik at redshift-software.com
-- 102708583 at icq - Grafik666 at AIM - Grafik at jabber.org
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: darwin-python-tests.txt
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20021030/7018b2f0/attachment.txt>

From rwgk at yahoo.com  Thu Oct 31 10:56:28 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 31 Oct 2002 01:56:28 -0800 (PST)
Subject: [C++-sig] How do I wrap a C++ object to a PyObject*
In-Reply-To: <u7kfz6y41.fsf@boost-consulting.com>
Message-ID: <20021031095628.15029.qmail@web20209.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> "Bjorn Pettersen" <BPettersen at NAREX.com> writes:
> > I've looked through the documentation but haven't found anything
> > obvious...
> 
> Let's see. You have a wrapped C++ class somewhere?
> If so, you can write in __main__:
> 
>   import some_boost_python_module
>   x = some_boost_python_module.some_class(some_arg)
> 
> But this is trivially explained in the docs, so you must mean
> something else...

I believe he wants to do this from C++. I don't know what __main__
is, but I am guessing that his problem is solved by using a
construct like this:

    scope().attr("key") = value;

which I believe is just a shorthand for

    scope().attr("key") = object(value);

This sets an attribute in the importing module.
value can be any object that is convertible from C++ to Python,
including but not limited to instances of a user-defined classes
X with a corresponding class_<X> statement.

Ralf


__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/



From BPettersen at NAREX.com  Thu Oct 31 17:08:37 2002
From: BPettersen at NAREX.com (Bjorn Pettersen)
Date: Thu, 31 Oct 2002 09:08:37 -0700
Subject: [C++-sig] How do I wrap a C++ object to a PyObject*
Message-ID: <60FB8BB7F0EFC7409B75EEEC13E20192017743F4@admin56.narex.com>

> From: Ralf W. Grosse-Kunstleve [mailto:rwgk at yahoo.com] 
> 
> --- David Abrahams <dave at boost-consulting.com> wrote:
> > "Bjorn Pettersen" <BPettersen at NAREX.com> writes:
> > > I've looked through the documentation but haven't found anything 
> > > obvious...
> > 
> > Let's see. You have a wrapped C++ class somewhere?
> > If so, you can write in __main__:
> > 
> >   import some_boost_python_module
> >   x = some_boost_python_module.some_class(some_arg)
> > 
> > But this is trivially explained in the docs, so you must mean 
> > something else...
> 
> I believe he wants to do this from C++. I don't know what 
> __main__ is, but I am guessing that his problem is solved by 
> using a construct like this:
> 
>     scope().attr("key") = value;
> 
> which I believe is just a shorthand for
> 
>     scope().attr("key") = object(value);
> 
> This sets an attribute in the importing module.
> value can be any object that is convertible from C++ to 
> Python, including but not limited to instances of a 
> user-defined classes X with a corresponding class_<X> statement.

Cool. Thanks!

-- bjorn



From n_lelong at hotmail.com  Thu Oct 31 18:01:39 2002
From: n_lelong at hotmail.com (Nicolas Lelong)
Date: Thu, 31 Oct 2002 18:01:39 +0100
Subject: [C++-sig] Python + Boost Python V2 + downcasting
Message-ID: <DAV69SVuS1VKhsGAHbf0000ae28@hotmail.com>

Hello,

I'm experiencing some embedding+extending with BPLv2 - and I could not find any answer to this simple question :

I have, say, a c++ class 'Base' and a c++ class 'Derived':

class Base
{
public:
    virtual int do_stuff() { return 0; }
};

class Derived
{
public:
    virtual int do_more() { return 100; }
};

class ObjectServer
{
public:
    Base* getObject(unsigned id)
    {
        return m_objects[id];
    }

    Base* m_objects[12];
}

declared in my module like this:

class_<Base>("Base")
    .def("do_stuff", &Base::do_stuff);

class_<Derived, bases<Base> >("Derived")
    .def("do_more", &Derived::do_more);

class_<ObjectServer>("ObjectServer")
    .def("getObject", &ObjectServer::getObject, return_internal_reference<>());

everything works fine - except that I can't get python to see the _real_ class of the objects returned by getObject. I tried the following:

...
obj = objectServer.getObject(0)
print isinstance(obj, Base)
print isinstance(obj, Derived)
print issubclass(Derived, Base)
print obj.__class__

and I get, when 'obj' is really a 'Derived*'
...
1
0
1
module.Base

how can I get to know that an object is an instance of Derived ?! is there a builtin way in Python ? a BPL v2 way ? I even thought about implementing my own 'isinstance' function but I'm not familiar enough with boost python & python !!... Any help or advice will be _greatly_ appreciated :)

Thanks in advance,
Nicolas.
PS. Please CC your response to n_lelong at hotmail.com as I'm not a regular contributor to this list!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20021031/ed66b731/attachment.htm>

From rwgk at yahoo.com  Thu Oct 31 18:14:48 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 31 Oct 2002 09:14:48 -0800 (PST)
Subject: [C++-sig] More MacOSX & Python - 2.3
In-Reply-To: <20021030232533-r01010800-64682719-0860-0108@12.100.89.43>
Message-ID: <20021031171448.10569.qmail@web20202.mail.yahoo.com>

--- Rene Rivera <grafik666 at redshift-software.com> wrote:
> Well thanks again to Ralf for doing some of the MacOSX work... and figuring
> out how to install the latest Python as a framework.
> 
> Good news is...
> 
> * Extensions and libboost_python build and link. That is the ones that
> compile.
> * Of the ones that produce an extension they are loaded by the Python
> interpreter.
> * Of the ones that load, some of them seem to run to completion, and what
> looks like without errors.

This is fantastic progress! At least we are at the point where we know it works
in general.

> Bad news...
> 
> * Only a small number of them compile. The single compile problem is this
> error:

As per http://cci.lbl.gov/boost/ the Sun gcc 3.1 compilations are also failing
at the moment. The current boost CVS clearly is in need of maintenance.
Unfortunately I don't have time for this right now. If someone could help out
getting the gcc 3.1 compilations going again this would be great.

> * Of the ones that compile and load, the majority seem to just hang there
> doing nothing for some time. After some short period of time (~1 minute) I
> killed the Python interpreter. Don't know why this is, but it could be
> something as silly as it deciding to open a dialog box I can't see and is
> waiting for never to arrive feedback.

Unfortunately I am not too surprised. One of my (non-Boost.Python) regression
tests revealed a fairly bad Apple c++ bug: under certain (?) circumstances
objects are double-destructed! I've sent a comprehensive bug report to Apple
but have not heard back for a couple of weeks.

Ralf


__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/



From rwgk at yahoo.com  Thu Oct 31 23:15:48 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 31 Oct 2002 14:15:48 -0800 (PST)
Subject: [C++-sig] Re: modules and separate compilation
In-Reply-To: <Pine.GSO.4.40.0210311540330.8113-100000@boopsie.fnal.gov>
Message-ID: <20021031221548.32882.qmail@web20205.mail.yahoo.com>

--- Francois Ostiguy <ostiguy at fnal.gov> wrote:
> I have a very large collection of classes which should all be part of the
> same module. Is there any way of separately compiling the module interface
> code (i.e boost.python code)  for different groups of classes belonging to
> the *same* module ... or do I absolutely need to use a single file with
> all the class interface declations within the scope of a single instance
> of

I believe your question is answered in this message:

http://mail.python.org/pipermail/c++-sig/2002-October/002345.html

Ralf

P.S.: Please post to c++-sig at python.org, not to c++-sig-owner.


__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/