From sagarwal at cs.ucsd.edu  Thu May  1 01:58:25 2003
From: sagarwal at cs.ucsd.edu (Sameer Agarwal)
Date: Wed, 30 Apr 2003 16:58:25 -0700
Subject: [C++-sig] multiple support in pyste
In-Reply-To: <9186A6BB-79AB-11D7-96C7-0003935AB3AC@cs.ucsd.edu>
Message-ID: <A161A138-7B67-11D7-9294-0003935AB3AC@cs.ucsd.edu>

here is another thought on pyste.
generalizing the exclude functionality to general pre and post 
processing hooks, can allow for
nifty stuff like SWIG's shadow classes to. e.g.

I would like to have the ability to have keyword arguments for my 
constructors, the name of the keyword argument is something I would 
like to be able to different from the ones specified in the c++ files. 
This is done most easily by spitting out code to a file as each class 
is wrapped.

Basically what I am asking for is more of the pyste internals be 
exposed, so that we can hook code into it via the .pyste files. Am I 
the only one wishing for stuff like this ?

sameer




From dominique.devriese at student.kuleuven.ac.be  Fri May  2 17:03:11 2003
From: dominique.devriese at student.kuleuven.ac.be (Dominique Devriese)
Date: 02 May 2003 17:03:11 +0200
Subject: [C++-sig] converting objects to python..
In-Reply-To: <uu1cg7s2p.fsf@boost-consulting.com>
References: <87k7ddksiz.fsf@student.kuleuven.ac.be>
	<uu1cg7s2p.fsf@boost-consulting.com>
Message-ID: <87isstjsr4.fsf@student.kuleuven.ac.be>

David Abrahams writes:

  >> Anyway, I'm kinda stuck on this..  Could you give me some
  >> pointers on where to look ?

  David> http://www.boost.org/libs/python/doc/v2/ptr.html

great :)  I found it..
thanks
domi

-- 
I don't know half of you half as well as I should like; and I like less
than half of you half as well as you deserve.
		-- J. R. R. Tolkien



From patrick at vrac.iastate.edu  Fri May  2 18:30:56 2003
From: patrick at vrac.iastate.edu (Patrick Hartling)
Date: Fri, 02 May 2003 11:30:56 -0500
Subject: [C++-sig] Passing by reference from Pythont to C++
Message-ID: <3EB29D40.4080004@vrac.iastate.edu>

I am pulling my hair out trying to figure out why the following code 
cannot be called from Python:

#include <boost/python.hpp>

void f(float& x)
{
    x = 5.0f;
}

BOOST_PYTHON_MODULE(reftest)
{
    boost::python::def("f", f);
}

When I try to call reftest.f() in Python, I get the dreaded error message 
about a bad argument type:

% python
Python 2.2.1 (#1, Aug 30 2002, 12:15:30)
[GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> import reftest
 >>> x = 0.0
 >>> reftest.f(x)
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
TypeError: bad argument type for built-in operation

Is this an error in how I am using reftest.f() from Python, or is 
something missing from my BPL code?  I've written bindings for a lot of 
other code that used pass-by-reference semantics, but it was always with 
classes rather than floats (or ints or other built-in types).

  -Patrick


-- 
Patrick L. Hartling                     | Research Assistant, VRAC
patrick at vrac.iastate.edu                | 2624 Howe Hall: 1.515.294.4916
http://www.137.org/patrick/             | http://www.vrac.iastate.edu/




From hupp at cs.wisc.edu  Fri May  2 18:41:02 2003
From: hupp at cs.wisc.edu (Adam Hupp)
Date: Fri, 2 May 2003 11:41:02 -0500
Subject: [C++-sig] Passing by reference from Pythont to C++
In-Reply-To: <3EB29D40.4080004@vrac.iastate.edu>
References: <3EB29D40.4080004@vrac.iastate.edu>
Message-ID: <20030502164102.GA26180@upl.cs.wisc.edu>

On Fri, May 02, 2003 at 11:30:56AM -0500, Patrick Hartling wrote:
> I am pulling my hair out trying to figure out why the following code 
> cannot be called from Python:
> 
> Is this an error in how I am using reftest.f() from Python, or is 
> something missing from my BPL code?  I've written bindings for a lot of 
> other code that used pass-by-reference semantics, but it was always with 
> classes rather than floats (or ints or other built-in types).


Ints and floats are immutable in python.  You'll need to create a
wrapper function that returns the modified float:


float f_wrap(float x) 
{
	f(x);
	return x;
}

void f(float& x)
{
   x = 5.0f;
}


-Adam



From patrick at vrac.iastate.edu  Fri May  2 19:02:07 2003
From: patrick at vrac.iastate.edu (Patrick Hartling)
Date: Fri, 02 May 2003 12:02:07 -0500
Subject: [C++-sig] Passing by reference from Pythont to C++
References: <3EB29D40.4080004@vrac.iastate.edu> <20030502164102.GA26180@upl.cs.wisc.edu>
Message-ID: <3EB2A48F.9010100@vrac.iastate.edu>

Ah, I see.  Well, the solution you propose doesn't quite work for the 
real situation I'm facing (my example code was a bit too trivial), but it 
gave me a good idea for working around the problem.  Thanks very much.

  -Patrick

Adam Hupp wrote:
> On Fri, May 02, 2003 at 11:30:56AM -0500, Patrick Hartling wrote:
> 
>>I am pulling my hair out trying to figure out why the following code 
>>cannot be called from Python:
>>
>>Is this an error in how I am using reftest.f() from Python, or is 
>>something missing from my BPL code?  I've written bindings for a lot of 
>>other code that used pass-by-reference semantics, but it was always with 
>>classes rather than floats (or ints or other built-in types).
> 
> 
> 
> Ints and floats are immutable in python.  You'll need to create a
> wrapper function that returns the modified float:
> 
> 
> float f_wrap(float x) 
> {
> 	f(x);
> 	return x;
> }
> 
> void f(float& x)
> {
>    x = 5.0f;
> }
> 
> 
> -Adam
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig



-- 
Patrick L. Hartling                     | Research Assistant, VRAC
patrick at vrac.iastate.edu                | 2624 Howe Hall: 1.515.294.4916
http://www.137.org/patrick/             | http://www.vrac.iastate.edu/




From dave at boost-consulting.com  Fri May  2 23:32:57 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 02 May 2003 17:32:57 -0400
Subject: [C++-sig] Re: boost:python:embedding
In-Reply-To: <E374F34816D3BE49AA6A2C37523190960A241A19@mailsto01.front.se> (Mattias
 Karlsson's message of "Fri, 2 May 2003 16:03:16 +0200")
References: <E374F34816D3BE49AA6A2C37523190960A241A19@mailsto01.front.se>
Message-ID: <usmrxnieu.fsf@boost-consulting.com>

Please post Boost.Python correspondence to the C++-sig:
http://www.python.org/sigs/c++-sig/

Mattias Karlsson <mattias.karlsson at front.com> writes:

> Hi
>
> I embed Python in a c++ application using Paul Dubois CXX stuff. Lately I've
> been looking into Boost:Python. Your library seems to be alive and updated
> frequently. So I thought it might be nice to use. Do you have any plans to
> release something that makes embedding more easy ?

What did you have in mind?

> Have a nice weekend!

You too!

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From milind_patil at hotmail.com  Sat May  3 01:43:46 2003
From: milind_patil at hotmail.com (Milind Patil)
Date: Fri, 2 May 2003 16:43:46 -0700
Subject: [C++-sig] long long unsigned issue...
Message-ID: <b8uvp7$kp1$1@main.gmane.org>

Hi,

I have used boost libraries to wrap a large c++ library and it has worked
very well.

However, I stumbled on the issue of long long conversion to class problem.
The problem has been reduced to the minimum code below.

I would like to expose to python a class that has constructors from int and
long long unsigned int among others:

class Y {
  public:
    Y() : y(0L) { }
    Y(int y) : y(y) { }
    Y(long long unsigned int y) : y(y) { }
    Y(Y const& rhs) : y(rhs.y) { }
    virtual ~Y() { }

    operator int() const { return y; }

    void operator=(Y const& y) {
        this->y = y.y;
    }

    long long unsigned int y;
};

I use boost thus:

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

#include <boost/python.hpp>
#include <hello.h>

using namespace boost::python;

BOOST_PYTHON_MODULE(hello)
{
    class_< Y >("Y", init<  >())
        .def(init< int >())
        .def(init< long long unsigned int >())
        .def(init< const Y & >())
        .def_readwrite("y", &Y::y)
        .def("__int__", &Y::operator int)
    ;

    implicitly_convertible<int, Y>();
    implicitly_convertible<long long unsigned int, Y>();
}

and use it in python thus:

import hello

x = hello.Y(4294967295)
print x.y
y = hello.Y(0xFFFFFFFFFFFFFFFF)
print y.y

However the code craps out:

Traceback (most recent call last):
  File "p.py", line 3, in ?
    x = hello.Y(4294967295)
OverflowError: long int too large to convert to int

Why wouldn't it try yo convert to long long unsigned int before trying
out int?

I am seeking a behaviour where python int is converted to c++ int
before constructing to c++ object Y, and python long is converted
to c++ long long unsigned int before constructing to c++ object Y.

It is possible that there are ways to write explicit boost converters
from long to Y, but that is too hairy for me. But before I go into it, I
was wondering if I have made a silly presumption or missed a simple
obvious way to do this. Any pointers will be a great help.

Thanks,
Milind






From dave at boost-consulting.com  Sat May  3 03:05:44 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 02 May 2003 21:05:44 -0400
Subject: [C++-sig] long long unsigned issue...
In-Reply-To: <b8uvp7$kp1$1@main.gmane.org> (Milind Patil's message of "Fri,
 2 May 2003 16:43:46 -0700")
References: <b8uvp7$kp1$1@main.gmane.org>
Message-ID: <uk7d8n8k7.fsf@boost-consulting.com>

"Milind Patil" <milind_patil at hotmail.com> writes:

> Hi,
>
> I have used boost libraries to wrap a large c++ library and it has worked
> very well.
>
> However, I stumbled on the issue of long long conversion to class problem.
> The problem has been reduced to the minimum code below.
>
> I would like to expose to python a class that has constructors from int and
> long long unsigned int among others:
>
> class Y {
>   public:
>     Y() : y(0L) { }
>     Y(int y) : y(y) { }
>     Y(long long unsigned int y) : y(y) { }
>     Y(Y const& rhs) : y(rhs.y) { }
>     virtual ~Y() { }
>
>     operator int() const { return y; }
>
>     void operator=(Y const& y) {
>         this->y = y.y;
>     }
>
>     long long unsigned int y;
> };
>
> I use boost thus:
>
> #include <boost/python/module.hpp>
> #include <boost/python/def.hpp>
>
> #include <boost/python.hpp>
> #include <hello.h>
>
> using namespace boost::python;
>
> BOOST_PYTHON_MODULE(hello)
> {
>     class_< Y >("Y", init<  >())
>         .def(init< int >())
>         .def(init< long long unsigned int >())
>         .def(init< const Y & >())
>         .def_readwrite("y", &Y::y)
>         .def("__int__", &Y::operator int)
>     ;
>
>     implicitly_convertible<int, Y>();
>     implicitly_convertible<long long unsigned int, Y>();
> }
>
> and use it in python thus:
>
> import hello
>
> x = hello.Y(4294967295)
> print x.y
> y = hello.Y(0xFFFFFFFFFFFFFFFF)
> print y.y
>
> However the code craps out:
>
> Traceback (most recent call last):
>   File "p.py", line 3, in ?
>     x = hello.Y(4294967295)
> OverflowError: long int too large to convert to int
>
> Why wouldn't it try yo convert to long long unsigned int before trying
> out int?

Because of the order of your implicitly_convertible<...> invocations.
Conversions to a C++ type (Y in this case) get tried in the order
they're registered.  I know; it's confusing since that's the opposite
of the way overloads work.

Are you sure you want the implicitly_convertible invocations?  You
don't need them in order to be able to compile and run the code above.
The only reason you would need them was if you wanted to be able to
pass a Python int or long directly to a wrapped C++ function accepting
a Y or Y const& argument.  If you *do* need that functionality, just
swap the order and everything will work.  However, the long long
conversion will mask the other one.

Incidentally, the following order also works:

    class_< Y >("Y", init<  >())
        .def(init< const Y & >())
        .def(init< int >())
        .def(init< long long unsigned int >())
        .def_readwrite("y", &Y::y)
        .def("__int__", &Y::operator int)
    ;

    implicitly_convertible<int, Y>();
    implicitly_convertible<long long unsigned int, Y>();

But this one breaks:

    class_< Y >("Y", init<  >())
        .def(init< const Y & >())
        .def(init< long long unsigned int >())
        .def(init< int >())
        .def_readwrite("y", &Y::y)
        .def("__int__", &Y::operator int)
    ;

    implicitly_convertible<int, Y>();
    implicitly_convertible<long long unsigned int, Y>();
    
That's because the constructor overloads get searched first (in
reverse order), then converters to the argument types get searched (in
forward order).

In your original example it was finding Y(const Y&) and looking for a
converter to the Y argument, finding the implicit converter for Python
Int -> Y, which is a good enough match to use with long values.

There's a lot of redundancy in all your declared constructors and
especially in the use of implicitly_convertible.  You might consider
starting with a minimal set of functionality (using unsigned long long
only) and seeing if you can get that to do what you want.

BTW,

        .def("__int__", &Y::operator int)

might be better written:

        .def(int_(self))

> I am seeking a behaviour where python int is converted to c++ int
> before constructing to c++ object Y, and python long is converted
> to c++ long long unsigned int before constructing to c++ object Y.

That might be difficult.  Guido and the lads are making it
increasingly difficult to detect a difference between Python int and
Python long, and plan to erase the distinction altogether soon.

Do you really need to handle the cases differently?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dirk at gerrits.homeip.net  Sat May  3 18:18:12 2003
From: dirk at gerrits.homeip.net (Dirk Gerrits)
Date: Sat, 03 May 2003 18:18:12 +0200
Subject: [C++-sig] Re: boost:python:embedding
In-Reply-To: <usmrxnieu.fsf@boost-consulting.com>
References: <E374F34816D3BE49AA6A2C37523190960A241A19@mailsto01.front.se> <usmrxnieu.fsf@boost-consulting.com>
Message-ID: <b90q1o$e6i$1@main.gmane.org>

David Abrahams wrote:
> Mattias Karlsson <mattias.karlsson at front.com> writes:
> 
>>Hi
>>
>>I embed Python in a c++ application using Paul Dubois CXX stuff. Lately I've
>>been looking into Boost:Python. Your library seems to be alive and updated
>>frequently. So I thought it might be nice to use. Do you have any plans to
>>release something that makes embedding more easy ?
> 
> 
> What did you have in mind?

I don't know what Mattias has in mind, but I personally use a home-made 
boost::python::interpreter class. (See attachments.) I would really love 
to see it in Boost.Python but perhaps it is not "up to Boost standards" 
at this point? It ignores things like multiple interpreters, the GIL, 
multithreading, code that already uses Py_Initialize, and perhaps more. 
I haven't looked into any of these because I don't have to worry about 
them in my code. (YAGNI and all that. ;))

There have been previous discussions about something like this. Others 
have rolled their own solutions, probably more advanced than mine, but I 
don't believe anyone has stepped up to get something into the library.

Regards,
Dirk Gerrits

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: interpreter.hpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20030503/e05e1c36/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: interpreter.cpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20030503/e05e1c36/attachment-0001.txt>

From dirk at gerrits.homeip.net  Sat May  3 18:24:51 2003
From: dirk at gerrits.homeip.net (Dirk Gerrits)
Date: Sat, 03 May 2003 18:24:51 +0200
Subject: [C++-sig] Re: boost:python:embedding
In-Reply-To: <b90q1o$e6i$1@main.gmane.org>
References: <E374F34816D3BE49AA6A2C37523190960A241A19@mailsto01.front.se> <usmrxnieu.fsf@boost-consulting.com> <b90q1o$e6i$1@main.gmane.org>
Message-ID: <b90qe7$f9d$1@main.gmane.org>

Dirk Gerrits wrote:
 >
> ... but I personally use a home-made
> boost::python::interpreter class. (See attachments.) I would really love 
> to see it in Boost.Python but perhaps it is not "up to Boost standards" 
> at this point? 

Hmm, a bit of an understatement. The execfile code is giving me access 
violations. I'll look into it.

Dirk Gerrits





From dirk at gerrits.homeip.net  Sat May  3 18:46:24 2003
From: dirk at gerrits.homeip.net (Dirk Gerrits)
Date: Sat, 03 May 2003 18:46:24 +0200
Subject: [C++-sig] Re: boost:python:embedding
In-Reply-To: <b90qe7$f9d$1@main.gmane.org>
References: <E374F34816D3BE49AA6A2C37523190960A241A19@mailsto01.front.se> <usmrxnieu.fsf@boost-consulting.com> <b90q1o$e6i$1@main.gmane.org> <b90qe7$f9d$1@main.gmane.org>
Message-ID: <b90rmk$jat$1@main.gmane.org>

Dirk Gerrits wrote:
> Dirk Gerrits wrote:
>  >
> 
>> ... but I personally use a home-made
>> boost::python::interpreter class. (See attachments.) I would really 
>> love to see it in Boost.Python but perhaps it is not "up to Boost 
>> standards" at this point? 
> 
> 
> Hmm, a bit of an understatement. The execfile code is giving me access 
> violations. I'll look into it.
> 

Okay, this seems to fix it:

void interpreter::execfile(char const* filename, dict& globals, dict& 
locals)
{
     FILE* file = 0;

     handle<> py_file(allow_null( PyFile_FromString(filename, "r") ));
     if (py_file)
         file = PyFile_AsFile(py_file.get());
     if (!file)
         throw std::runtime_error("Failed to open file: " + 
std::string(filename));
     handle<> result(
         PyRun_File(file, filename, Py_file_input, globals.ptr(), 
locals.ptr()) );
}

Apparently, my C library is incompatible with the one my Python 
installation was built with.

Anyway, it would be nice if this sort of low-level stuff was a part of 
Boost.Python, so that I wouldn't have to make a fool of myself by 
getting it wrong and posting about it. ;)

Dirk Gerrits





From dave at boost-consulting.com  Sat May  3 22:46:32 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 03 May 2003 16:46:32 -0400
Subject: [C++-sig] Re: boost:python:embedding
In-Reply-To: <b90rmk$jat$1@main.gmane.org> (Dirk Gerrits's message of "Sat,
 03 May 2003 18:46:24 +0200")
References: <E374F34816D3BE49AA6A2C37523190960A241A19@mailsto01.front.se>
	<usmrxnieu.fsf@boost-consulting.com> <b90q1o$e6i$1@main.gmane.org>
	<b90qe7$f9d$1@main.gmane.org> <b90rmk$jat$1@main.gmane.org>
Message-ID: <u8ytnkbbr.fsf@boost-consulting.com>

Dirk Gerrits <dirk at gerrits.homeip.net> writes:

> Okay, this seems to fix it:
>
> void interpreter::execfile(char const* filename, dict& globals, dict&
> locals)
> {
>      FILE* file = 0;
>
>      handle<> py_file(allow_null( PyFile_FromString(filename, "r") ));
>      if (py_file)
>          file = PyFile_AsFile(py_file.get());
>      if (!file)
>          throw std::runtime_error("Failed to open file: " +
>          std::string(filename));
>      handle<> result(
>          PyRun_File(file, filename, Py_file_input, globals.ptr(),
>          locals.ptr()) );
> }
>
> Apparently, my C library is incompatible with the one my Python
> installation was built with.
>
> Anyway, it would be nice if this sort of low-level stuff was a part of
> Boost.Python, so that I wouldn't have to make a fool of myself by
> getting it wrong and posting about it. ;)

How do you think it's going to get into the library anyway, Dirk?
You're going to have to submit your code, along with documentation and
tests.  I'll certainly credit you in the acknowledgements page and
your name will go in the copyrights for that code so credit (or blame)
will still be on you! ;-)

Anyway, I'd be delighted to have this in Boost.Python, so long as it
comes with docs and tests.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dirk at gerrits.homeip.net  Sat May  3 23:47:42 2003
From: dirk at gerrits.homeip.net (Dirk Gerrits)
Date: Sat, 03 May 2003 23:47:42 +0200
Subject: [C++-sig] Re: boost:python:embedding
In-Reply-To: <u8ytnkbbr.fsf@boost-consulting.com>
References: <E374F34816D3BE49AA6A2C37523190960A241A19@mailsto01.front.se>	<usmrxnieu.fsf@boost-consulting.com> <b90q1o$e6i$1@main.gmane.org>	<b90qe7$f9d$1@main.gmane.org> <b90rmk$jat$1@main.gmane.org> <u8ytnkbbr.fsf@boost-consulting.com>
Message-ID: <b91dbj$d22$1@main.gmane.org>

David Abrahams wrote:
> Dirk Gerrits <dirk at gerrits.homeip.net> writes:
>
> How do you think it's going to get into the library anyway, Dirk?
> You're going to have to submit your code, along with documentation and
> tests.  I'll certainly credit you in the acknowledgements page and
> your name will go in the copyrights for that code so credit (or blame)
> will still be on you! ;-)

Hmm, good point Dave. :)

> Anyway, I'd be delighted to have this in Boost.Python, so long as it
> comes with docs and tests.

Oh I'd be willing to update the tutorial. It would definately be a lot 
shorter with this code in the library. ;)

You'll have to teach me how to write the reference material, though. 
That is, I assume it's not hand-written HTML?

For the tests I can just use

void test() { ... }

int main()
{
     if (python::handle_exception(test))
     {
         if (PyErr_Occurred())
             PyErr_Print();
         return 1;
     }
     return 0;
}
#include "module_tail.cpp"

as in embedding.cpp right? That shouldn't be too hard.


I'd like to stress again though, that my current solution is pretty 
basic. I really have no use for multiple interpreters, or multiple 
Python-using threads at the moment. If anyone else does, and wants to 
see it addressed in Boost.Python, I encourage them to post their code 
and extra testcases here.

Regards,
Dirk Gerrits





From dave at boost-consulting.com  Sun May  4 00:23:04 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 03 May 2003 18:23:04 -0400
Subject: [C++-sig] Re: boost:python:embedding
In-Reply-To: <b91dbj$d22$1@main.gmane.org> (Dirk Gerrits's message of "Sat,
 03 May 2003 23:47:42 +0200")
References: <E374F34816D3BE49AA6A2C37523190960A241A19@mailsto01.front.se>
	<usmrxnieu.fsf@boost-consulting.com> <b90q1o$e6i$1@main.gmane.org>
	<b90qe7$f9d$1@main.gmane.org> <b90rmk$jat$1@main.gmane.org>
	<u8ytnkbbr.fsf@boost-consulting.com> <b91dbj$d22$1@main.gmane.org>
Message-ID: <uof2jisaf.fsf@boost-consulting.com>

Dirk Gerrits <dirk at gerrits.homeip.net> writes:

> David Abrahams wrote:
>> Dirk Gerrits <dirk at gerrits.homeip.net> writes:
>>
>> How do you think it's going to get into the library anyway, Dirk?
>> You're going to have to submit your code, along with documentation and
>> tests.  I'll certainly credit you in the acknowledgements page and
>> your name will go in the copyrights for that code so credit (or blame)
>> will still be on you! ;-)
>
> Hmm, good point Dave. :)
>
>> Anyway, I'd be delighted to have this in Boost.Python, so long as it
>> comes with docs and tests.
>
> Oh I'd be willing to update the tutorial. It would definately be a lot
> shorter with this code in the library. ;)
>
> You'll have to teach me how to write the reference material,
> though. That is, I assume it's not hand-written HTML?

Sadly, no.  One day we'll use BoostBook generation, but 'till then,
you just copy one of the templates
(e.g. http://www.boost.org/libs/python/doc/v2/header.html) and go
from there.
>
> For the tests I can just use
>
> void test() { ... }
>
> int main()
> {
>      if (python::handle_exception(test))
>      {
>          if (PyErr_Occurred())
>              PyErr_Print();
>          return 1;
>      }
>      return 0;
> }
> #include "module_tail.cpp"
>
> as in embedding.cpp right? 

Seems likely, but I'm not certain what you need to do for the tests
you want to run.

> That shouldn't be too hard.
>
>
> I'd like to stress again though, that my current solution is pretty
> basic. I really have no use for multiple interpreters

Most people don't, it turns out.

> , or multiple Python-using threads at the moment. If anyone else
> does, and wants to see it addressed in Boost.Python, I encourage
> them to post their code and extra testcases here.

That's the spirit!

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From milind_patil at hotmail.com  Sun May  4 00:30:32 2003
From: milind_patil at hotmail.com (Milind Patil)
Date: Sat, 3 May 2003 15:30:32 -0700
Subject: [C++-sig] Re: long long unsigned issue...
References: <b8uvp7$kp1$1@main.gmane.org> <uk7d8n8k7.fsf@boost-consulting.com>
Message-ID: <b91fup$lnm$1@main.gmane.org>

"David Abrahams" <dave at boost-consulting.com> wrote in message
news:uk7d8n8k7.fsf at boost-consulting.com...
> "Milind Patil" <milind_patil at hotmail.com> writes:
>
> > Hi,
...<snipped>...
> > Why wouldn't it try yo convert to long long unsigned int before trying
> > out int?
>
> Because of the order of your implicitly_convertible<...> invocations.
> Conversions to a C++ type (Y in this case) get tried in the order
> they're registered.  I know; it's confusing since that's the opposite
> of the way overloads work.
>

This clears some of my puzzlement. Thank you.

> Are you sure you want the implicitly_convertible invocations?  You
> don't need them in order to be able to compile and run the code above.
> The only reason you would need them was if you wanted to be able to
> pass a Python int or long directly to a wrapped C++ function accepting
> a Y or Y const& argument.
...<snipped>...
> That's because the constructor overloads get searched first (in
> reverse order), then converters to the argument types get searched (in
> forward order).
>
> In your original example it was finding Y(const Y&) and looking for a
> converter to the Y argument, finding the implicit converter for Python
> Int -> Y, which is a good enough match to use with long values.
>
> There's a lot of redundancy in all your declared constructors and
> especially in the use of implicitly_convertible.  You might consider
> starting with a minimal set of functionality (using unsigned long long
> only) and seeing if you can get that to do what you want.
>

You are right of course about this particular example not needing the
implicity_convertibles.

But, taking the toy example a step closer to the actual class I am
wrapping...

class Y {
  public:
    Y() : y(0L) { }
    Y(int y) : y(y) { }
    Y(long long unsigned int y) : y(y) { }
    Y(int s, const Y & y) : y(y << s/* toy usage*/) { }
    Y(Y const& rhs) : y(rhs.y) { }
    virtual ~Y() { }

    operator int() const { return y; }

    void operator=(Y const& y) {
        this->y = y.y;
    }

    long long unsigned int y;
};

BOOST_PYTHON_MODULE(hello)
{
    class_< Y >("Y", init<  >())
        .def(init< const Y & >())
        .def(init< int, const Y & >())
        .def(init< int >())
        .def(init< long long unsigned int >())
        .def_readwrite("y", &Y::y)
        .def("__int__", &Y::operator int)
    ;
}

This should work, ... intutively. But doesn't,  if I tried
to execute the python code...

z = hello.Y(2, 1)

Why should I now need
implicitly_convertible<int, Y>();
for it to work?

> > I am seeking a behaviour where python int is converted to c++ int
> > before constructing to c++ object Y, and python long is converted
> > to c++ long long unsigned int before constructing to c++ object Y.
>
> That might be difficult.  Guido and the lads are making it
> increasingly difficult to detect a difference between Python int and
> Python long, and plan to erase the distinction altogether soon.
>
> Do you really need to handle the cases differently?
>

Not explicitly. But consider if I want to do

z = hello.Y(~0)
or
z = hello.Y(-1)

This is best converted to Y(int) constructor. But python still insists
on calling the Y(long long unsigned int) constructor and craps out saying
about bad argument type.

> -- 
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com

Part of the c++ library I am wrapping is a bit vector library which
acts like a c++ builtin type for most part. It is only when converting
python types to the bit vector object that differences become
visibile according to whether source type is signed or not.

I read up a bit on python long and learned that it is not like the
c++ long. It seems the python long is a structure and is not
width bound. How does boost handle python boost to long
conversion?

Thank you for the quick response.

Milind








From milind_patil at hotmail.com  Sun May  4 00:35:50 2003
From: milind_patil at hotmail.com (Milind Patil)
Date: Sat, 3 May 2003 15:35:50 -0700
Subject: [C++-sig] Re: long long unsigned issue...
References: <b8uvp7$kp1$1@main.gmane.org> <uk7d8n8k7.fsf@boost-consulting.com>
Message-ID: <b91g6e$me8$1@main.gmane.org>

"David Abrahams" <dave at boost-consulting.com> wrote in message
news:uk7d8n8k7.fsf at boost-consulting.com...
> "Milind Patil" <milind_patil at hotmail.com> writes:
>
> > Hi,
...<snipped>...
> > Why wouldn't it try yo convert to long long unsigned int before trying
> > out int?
>
> Because of the order of your implicitly_convertible<...> invocations.
> Conversions to a C++ type (Y in this case) get tried in the order
> they're registered.  I know; it's confusing since that's the opposite
> of the way overloads work.
>

This clears some of my puzzlement. Thank you.

> Are you sure you want the implicitly_convertible invocations?  You
> don't need them in order to be able to compile and run the code above.
> The only reason you would need them was if you wanted to be able to
> pass a Python int or long directly to a wrapped C++ function accepting
> a Y or Y const& argument.
...<snipped>...
> That's because the constructor overloads get searched first (in
> reverse order), then converters to the argument types get searched (in
> forward order).
>
> In your original example it was finding Y(const Y&) and looking for a
> converter to the Y argument, finding the implicit converter for Python
> Int -> Y, which is a good enough match to use with long values.
>
> There's a lot of redundancy in all your declared constructors and
> especially in the use of implicitly_convertible.  You might consider
> starting with a minimal set of functionality (using unsigned long long
> only) and seeing if you can get that to do what you want.
>

You are right of course about this particular example not needing the
implicity_convertibles.

But, taking the toy example a step closer to the actual class I am
wrapping...

class Y {
  public:
    Y() : y(0L) { }
    Y(int y) : y(y) { }
    Y(long long unsigned int y) : y(y) { }
    Y(int s, const Y & y) : y(y << s/* toy usage*/) { }
    Y(Y const& rhs) : y(rhs.y) { }
    virtual ~Y() { }

    operator int() const { return y; }

    void operator=(Y const& y) {
        this->y = y.y;
    }

    long long unsigned int y;
};

BOOST_PYTHON_MODULE(hello)
{
    class_< Y >("Y", init<  >())
        .def(init< const Y & >())
        .def(init< int, const Y & >())
        .def(init< int >())
        .def(init< long long unsigned int >())
        .def_readwrite("y", &Y::y)
        .def("__int__", &Y::operator int)
    ;
}

This should work, ... intutively. But doesn't,  if I tried
to execute the python code...

z = hello.Y(2, 1)

Why should I now need
implicitly_convertible<int, Y>();
for it to work?

> > I am seeking a behaviour where python int is converted to c++ int
> > before constructing to c++ object Y, and python long is converted
> > to c++ long long unsigned int before constructing to c++ object Y.
>
> That might be difficult.  Guido and the lads are making it
> increasingly difficult to detect a difference between Python int and
> Python long, and plan to erase the distinction altogether soon.
>
> Do you really need to handle the cases differently?
>

Not explicitly. But consider if I want to do

z = hello.Y(~0)
or
z = hello.Y(-1)

This is best converted to Y(int) constructor. But python still insists
on calling the Y(long long unsigned int) constructor and craps out saying
about bad argument type.

> -- 
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com

Part of the c++ library I am wrapping is a bit vector library which
acts like a c++ builtin type for most part. It is only when converting
python types to the bit vector object that differences become
visibile according to whether source type is signed or not.

I read up a bit on python long and learned that it is not like the
c++ long. It seems the python long is a structure and is not
width bound. How does boost handle python boost to long
conversion?

Thank you for the quick response.

Milind






From dave at boost-consulting.com  Sun May  4 03:04:14 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 03 May 2003 21:04:14 -0400
Subject: [C++-sig] Re: long long unsigned issue...
In-Reply-To: <b91g6e$me8$1@main.gmane.org> (Milind Patil's message of "Sat,
 3 May 2003 15:35:50 -0700")
References: <b8uvp7$kp1$1@main.gmane.org> <uk7d8n8k7.fsf@boost-consulting.com>
	<b91g6e$me8$1@main.gmane.org>
Message-ID: <u65oriktt.fsf@boost-consulting.com>

"Milind Patil" <milind_patil at hotmail.com> writes:

> But, taking the toy example a step closer to the actual class I am
> wrapping...
>
> class Y {
>   public:
>     Y() : y(0L) { }
>     Y(int y) : y(y) { }
>     Y(long long unsigned int y) : y(y) { }
>     Y(int s, const Y & y) : y(y << s/* toy usage*/) { }
>     Y(Y const& rhs) : y(rhs.y) { }
>     virtual ~Y() { }
>
>     operator int() const { return y; }
>
>     void operator=(Y const& y) {
>         this->y = y.y;
>     }
>
>     long long unsigned int y;
> };
>
> BOOST_PYTHON_MODULE(hello)
> {
>     class_< Y >("Y", init<  >())
>         .def(init< const Y & >())
>         .def(init< int, const Y & >())
>         .def(init< int >())
>         .def(init< long long unsigned int >())
>         .def_readwrite("y", &Y::y)
>         .def("__int__", &Y::operator int)
>     ;
> }
>
> This should work, ... intutively. But doesn't,  if I tried
> to execute the python code...
>
> z = hello.Y(2, 1)
>
> Why should I now need
> implicitly_convertible<int, Y>();
> for it to work?

Because:

    a). Boost.Python doesn't automatically detect that the Y(int) case
        isn't explicit (although it could on most compilers).

    b). Python itself doesn't do any implicit conversions.

It would be interesting to generate implicitly_convertible invocations
for single-argument constructors where the argument type is in fact
implicitly convertible to the destination type.  It wouldn't be
supported on CWPro7, but I plan to drop support for that old compiler
anyway.

>> > I am seeking a behaviour where python int is converted to c++ int
>> > before constructing to c++ object Y, and python long is converted
>> > to c++ long long unsigned int before constructing to c++ object Y.
>>
>> That might be difficult.  Guido and the lads are making it
>> increasingly difficult to detect a difference between Python int and
>> Python long, and plan to erase the distinction altogether soon.
>>
>> Do you really need to handle the cases differently?
>>
>
> Not explicitly. But consider if I want to do
>
> z = hello.Y(~0)
> or
> z = hello.Y(-1)
>
> This is best converted to Y(int) constructor. 

Why?

> Part of the c++ library I am wrapping is a bit vector library which
> acts like a c++ builtin type for most part. It is only when
> converting python types to the bit vector object that differences
> become visibile according to whether source type is signed or not.
>
> I read up a bit on python long and learned that it is not like the
> c++ long. It seems the python long is a structure and is not width
> bound. How does boost handle python boost to long conversion?

What is "python boost to long conversion"?  Please be specific.


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From milind_patil at hotmail.com  Sun May  4 03:29:55 2003
From: milind_patil at hotmail.com (Milind Patil)
Date: Sat, 3 May 2003 18:29:55 -0700
Subject: [C++-sig] Re: Re: long long unsigned issue...
References: <b8uvp7$kp1$1@main.gmane.org> <uk7d8n8k7.fsf@boost-consulting.com><b91g6e$me8$1@main.gmane.org> <u65oriktt.fsf@boost-consulting.com>
Message-ID: <b91qci$oc6$1@main.gmane.org>

"David Abrahams" <dave at boost-consulting.com> wrote in message
news:u65oriktt.fsf at boost-consulting.com...
> "Milind Patil" <milind_patil at hotmail.com> writes:
>
> >> > I am seeking a behaviour where python int is converted to c++ int
> >> > before constructing to c++ object Y, and python long is converted
> >> > to c++ long long unsigned int before constructing to c++ object Y.
> >>
> >> Do you really need to handle the cases differently?
> >>
> >
> > Not explicitly. But consider if I want to do
> >
> > z = hello.Y(~0)
> > or
> > z = hello.Y(-1)
> >
> > This is best converted to Y(int) constructor.
>
> Why?

Because if I have constructor Y(long unsigned unsigned int) precede
Y(int) (and you rightly said it masks the int), then I get

OverflowError: bad numeric cast: loss of range in numeric_cast

for the python statement z = hello.Y(-1).  There is no way to convert a
python -1L to a c++ long long unsigned int.

> > I read up a bit on python long and learned that it is not like the
> > c++ long. It seems the python long is a structure and is not width
> > bound. How does boost handle python boost to long conversion?
>
> What is "python boost to long conversion"?  Please be specific.

I meant python long to c++ long conversion by boost. For example,
what happens if the python long is more than 64 bits wide? How do I
handle this in c++?

Thanks,
Milind






From dave at boost-consulting.com  Sun May  4 03:44:00 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 03 May 2003 21:44:00 -0400
Subject: [C++-sig] Re: Re: long long unsigned issue...
In-Reply-To: <b91qci$oc6$1@main.gmane.org> (Milind Patil's message of "Sat,
 3 May 2003 18:29:55 -0700")
References: <b8uvp7$kp1$1@main.gmane.org> <uk7d8n8k7.fsf@boost-consulting.com>
	<b91g6e$me8$1@main.gmane.org> <u65oriktt.fsf@boost-consulting.com>
	<b91qci$oc6$1@main.gmane.org>
Message-ID: <u1xzfiizj.fsf@boost-consulting.com>

"Milind Patil" <milind_patil at hotmail.com> writes:

>> >
>> > This is best converted to Y(int) constructor.
>>
>> Why?
>
> Because if I have constructor Y(long unsigned unsigned int) precede
> Y(int) (and you rightly said it masks the int), then I get
>
> OverflowError: bad numeric cast: loss of range in numeric_cast
>
> for the python statement z = hello.Y(-1).  There is no way to convert a
> python -1L to a c++ long long unsigned int.

OK, I understand.

>> > I read up a bit on python long and learned that it is not like the
>> > c++ long. It seems the python long is a structure and is not width
>> > bound. How does boost handle python boost to long conversion?
>>
>> What is "python boost to long conversion"?  Please be specific.
>
> I meant python long to c++ long conversion by boost. For example,
> what happens if the python long is more than 64 bits wide? 

If it doesn't fit in a C++ long (not neccessarily 64 bits), you'll
get an overflow error.

BTW, a Python int is precisely the same number of bits as a C++ long.
I don't know if that helps you at all.

BTW2, Boost.Python has a "long_" type which corresponds precisely to
a Python long.  You can use that in your constructor.

> How do I handle this in c++?

I guess it depends on the behavior you're trying to achieve.  Can you
explain precisely what you're after?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From milind_patil at hotmail.com  Sun May  4 07:40:31 2003
From: milind_patil at hotmail.com (Milind Patil)
Date: Sat, 3 May 2003 22:40:31 -0700
Subject: [C++-sig] Re: Re: Re: long long unsigned issue...
References: <b8uvp7$kp1$1@main.gmane.org> <uk7d8n8k7.fsf@boost-consulting.com><b91g6e$me8$1@main.gmane.org> <u65oriktt.fsf@boost-consulting.com><b91qci$oc6$1@main.gmane.org> <u1xzfiizj.fsf@boost-consulting.com>
Message-ID: <b9292b$qru$1@main.gmane.org>

"David Abrahams" <dave at boost-consulting.com> wrote in message
news:u1xzfiizj.fsf at boost-consulting.com...
> "Milind Patil" <milind_patil at hotmail.com> writes:
>
> > I meant python long to c++ long conversion by boost. For example,
> > what happens if the python long is more than 64 bits wide?
>
> If it doesn't fit in a C++ long (not neccessarily 64 bits), you'll
> get an overflow error.
>
> BTW2, Boost.Python has a "long_" type which corresponds precisely to
> a Python long.  You can use that in your constructor.
>
> > How do I handle this in c++?
>
> I guess it depends on the behavior you're trying to achieve.  Can you
> explain precisely what you're after?
>

Avoiding the overflow error is one of the requirements of the wrapper.
If the user uses arbitrary width python longs to get a result in python and
then casts it into the bit vector class (which is also arbitrary width) or
uses
a operation resulting in an implict cast, then this should be possible
consistently.

Unfortunately the bit vector class I am wrapping with python is not
modifyable by me, therefore I cannot introduce a constructor into the
bit vector class to effect a python long (long_) to bit vector class
converter.

However, I could have a Y_Wrapper class that I can add constructors to.
Is this possible?...

struct Y_Wrapper: Y {
  public:
    Y_Wrapper(PyObject* self_) : self(self_) { }
    /* ... more constructors ... */
    Y_Wrapper(PyObject* self_, boost::python::long_  y) : self(self_) { /*
some code to convert long_ to Y */ }

    PyObject* self;
};

BOOST_PYTHON_MODULE(hello)
{
    class_< Y, Y_Wrapper >("Y", init<  >())
        .def(init< const Y & >())
        //... more init defs ...
        .def(init< long_ >())
       //...
    ;
}


> -- 
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com






From dave at boost-consulting.com  Sun May  4 12:39:13 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 04 May 2003 06:39:13 -0400
Subject: [C++-sig] Re: Re: Re: long long unsigned issue...
In-Reply-To: <b9292b$qru$1@main.gmane.org> (Milind Patil's message of "Sat,
 3 May 2003 22:40:31 -0700")
References: <b8uvp7$kp1$1@main.gmane.org> <uk7d8n8k7.fsf@boost-consulting.com>
	<b91g6e$me8$1@main.gmane.org> <u65oriktt.fsf@boost-consulting.com>
	<b91qci$oc6$1@main.gmane.org> <u1xzfiizj.fsf@boost-consulting.com>
	<b9292b$qru$1@main.gmane.org>
Message-ID: <u65orxage.fsf@boost-consulting.com>

"Milind Patil" <milind_patil at hotmail.com> writes:

> However, I could have a Y_Wrapper class that I can add constructors to.
> Is this possible?...

Yes, that's a good approach, and the only one we currently support
well.  Eventually it should be possible to add factory functions as
constructors, but it isn't yet.

> struct Y_Wrapper: Y {
>   public:
>     Y_Wrapper(PyObject* self_) : self(self_) { }
>     /* ... more constructors ... */
>     Y_Wrapper(PyObject* self_, boost::python::long_  y) : self(self_) { /*
> some code to convert long_ to Y */ }
>
>     PyObject* self;
> };
>
> BOOST_PYTHON_MODULE(hello)
> {
>     class_< Y, Y_Wrapper >("Y", init<  >())
>         .def(init< const Y & >())
>         //... more init defs ...
>         .def(init< long_ >())
>        //...
>     ;
> }


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dirk at gerrits.homeip.net  Sun May  4 13:15:42 2003
From: dirk at gerrits.homeip.net (Dirk Gerrits)
Date: Sun, 04 May 2003 13:15:42 +0200
Subject: [C++-sig] Re: boost:python:embedding
In-Reply-To: <uof2jisaf.fsf@boost-consulting.com>
References: <E374F34816D3BE49AA6A2C37523190960A241A19@mailsto01.front.se>	<usmrxnieu.fsf@boost-consulting.com> <b90q1o$e6i$1@main.gmane.org>	<b90qe7$f9d$1@main.gmane.org> <b90rmk$jat$1@main.gmane.org>	<u8ytnkbbr.fsf@boost-consulting.com> <b91dbj$d22$1@main.gmane.org> <uof2jisaf.fsf@boost-consulting.com>
Message-ID: <b92smh$euc$1@main.gmane.org>

David Abrahams wrote:
> Dirk Gerrits <dirk at gerrits.homeip.net> writes:
> 
> 
>>David Abrahams wrote:
>>
>>>Dirk Gerrits <dirk at gerrits.homeip.net> writes:
>>
>>You'll have to teach me how to write the reference material,
>>though. That is, I assume it's not hand-written HTML?
> 
> 
> Sadly, no.  One day we'll use BoostBook generation, but 'till then,
> you just copy one of the templates
> (e.g. http://www.boost.org/libs/python/doc/v2/header.html) and go
> from there.

Okay, will do.

>>For the tests I can just use
>>
[code snipped]
 >>as in embedding.cpp right?
> 
> 
> Seems likely, but I'm not certain what you need to do for the tests
> you want to run.

Well nothing too fancy I think.

>>That shouldn't be too hard.
>>
>>
>>I'd like to stress again though, that my current solution is pretty
>>basic. I really have no use for multiple interpreters
> 
> 
> Most people don't, it turns out.

Well then, I'll get my code boostified. :)

>>, or multiple Python-using threads at the moment. If anyone else
>>does, and wants to see it addressed in Boost.Python, I encourage
>>them to post their code and extra testcases here.
> 
> 
> That's the spirit!

Boost.Spirit? :P

Seriously though, I have some more questions.

When you are embedding Python in a C++ program, your Python code may 
need to call C++ code in the embedding program. (At least, that's what I 
currently need to do.) To do this, you can't simply create a 
module_name.so or module_name.pyd as you'd do when extending; the BPL 
wrapper code must be in the C++ program itself. To make the module 
available to Python, you must call a function like 
PyImport_AppendInittab (or interpreter::add_module which I just whipped 
up ;)). The parameters to this call are the module name and the init 
function. Herein lies the problem. If the module is in a different 
compilation unit than the code using the interpreter one must forward 
declare the init function. Is there currently a way to do this safely? 
Perhaps a macro like the following?

#if (defined(_WIN32) || defined(__CYGWIN__)) && 
!defined(BOOST_PYTHON_STATIC_MODULE)

#  define BOOST_PYTHON_FORWARD_DECLARE_MODULE_INIT(name)     \
extern "C" __declspec(dllexport) void init##name();

#else

#  define BOOST_PYTHON_FORWARD_DECLARE_MODULE_INIT(name)     \
extern "C" void init##name()

#endif

I have some issues with this though. For starters, the macro name is 
much too long for my taste. ;) Furthermore, I doubt if it makes sense to 
do this sort of embedding without defining BOOST_PYTHON_STATIC_MODULE. 
Which brings me to my last question.

There used to be a bug which caused a 'Fatal Python error' upon 
Py_Finalize when doing this kind of embedding. But when I ran into that, 
there was no BOOST_PYTHON_STATIC_MODULE. Now, with 
BOOST_PYTHON_STATIC_MODULE I haven't been able to replicate it. Has it 
been fixed then?

Dirk Gerrits





From dave at boost-consulting.com  Sun May  4 22:09:51 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 04 May 2003 16:09:51 -0400
Subject: [C++-sig] Ownership question.
In-Reply-To: <5.2.0.9.2.20030427170646.00a7dcb8@talsit.org> (tALSit de CoD's
 message of "Sun, 27 Apr 2003 17:15:00 +1000")
References: <5.2.0.9.2.20030427145130.00b0d200@talsit.org>
	<5.2.0.9.2.20030427145130.00b0d200@talsit.org>
	<5.2.0.9.2.20030427170646.00a7dcb8@talsit.org>
Message-ID: <usmrucw34.fsf@boost-consulting.com>

tALSit de CoD <talsit at talsit.org> writes:

> Ok, I think i got ya, but I think that's not what I was saying.
>
> When I do this:
>
>  >>> key = cAnimCurveKey ()
>
> Python is in charge of the ownership of the object. So, in theory, the
> GC could mark it for collection at any given moment, right?

Well, not until all the (strong) references are gone, but yes.

> So if I now add the key to a class that takes it's ownership

[I assume you mean by accepting a std::auto_ptr<cAnimCurveKey>
argument...]

> what happens?

The C++ part of the object gets detached from the Python part and
animCurve manages the C++ part.

>  >>> animCurve.addKey (key)  # animCurve is now in charge of deleting the key
>
> is key still managed by python? 

The one you see in Python is.  You can't do much with it, though,
since it's lost its C++ data.  Try it; you'll get a "friendly"
traceback.

> Will it be marked for collection by the GC?

Actually, Boost.Python objects are not GC-enabled.  It's really too
dangerous since we can't be guaranteed of being able to trace all the
references they hold to Python objects (e.g. the C++ class might embed
a boost::python::object, or even a shared_ptr<> which is keeping a
Python object alive).  However, I don't think you're really interested
in GC, since plenty of objects get destroyed by Python just due to its
reference-counting, before GC ever kicks in.  GC in Python is really
only for collecting reference cycles.

> If so, how do i prevent it?

I doubt this question is still relevant given what I've said above,
but if I'm wrong, please ask again.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From nicodemus at globalite.com.br  Sun May  4 23:31:35 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Sun, 04 May 2003 18:31:35 -0300
Subject: [C++-sig] Tutorial - Techniques
Message-ID: <3EB586B7.8090108@globalite.com.br>

Hi All!

I have written the Techniques page for the Tutorial as I promised last 
week. Sorry for not finishing this earlier, but I had a lot of stuff 
from college to do. Could you people take a look and share your opinions 
(especially Ralf and Dave)?
I didn't post a patch to the original docs, but I'm sure Joel will have 
absolutely no problem adding it. 8) Btw, Joel, all Python comments are 
getting an extra #... perhaps I am doing something wrong?

I created three sections, "Creating Packages", "Extending Wrapped 
Objects in Python" and "Reducing Compiling Time". Any comments are welcome!

<cid:part1.02070604.05000309 at globalite.com.br>Regards,
Nicodemus.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: techniques.zip
Type: application/zip
Size: 33582 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20030504/76ce98e1/attachment.zip>

From dirk at gerrits.homeip.net  Mon May  5 09:11:47 2003
From: dirk at gerrits.homeip.net (Dirk Gerrits)
Date: Mon, 05 May 2003 09:11:47 +0200
Subject: [C++-sig] Re: Tutorial - Techniques
In-Reply-To: <3EB586B7.8090108@globalite.com.br>
References: <3EB586B7.8090108@globalite.com.br>
Message-ID: <b952p7$ka$1@main.gmane.org>

Nicodemus wrote:
> I created three sections, "Creating Packages", "Extending Wrapped 
> Objects in Python" and "Reducing Compiling Time". Any comments are welcome!

Just two minor nits about "Extending Wrapped Objects in Python":

* advantages is misspelled 'advantagens'
* the term 'syntax sugar' is used, I thought it was 'syntactic sugar'?

Otherwise, this is great stuff!

Dirk Gerrits





From paul.rudin at ntlworld.com  Mon May  5 09:27:56 2003
From: paul.rudin at ntlworld.com (Paul Rudin)
Date: 05 May 2003 08:27:56 +0100
Subject: [C++-sig] pyste - falling over on certain inputs.
In-Reply-To: <b952p7$ka$1@main.gmane.org>
Message-ID: <m3smrtam4j.fsf_-_@ntlworld.com>


Apologies if this is a known issue - I did have a quick look through
the mailing list archive and couldn't see any mention of it.

I'm getting this assertion failure (up to date cvs pyste) when using
AllFromHeader on a number of files.


Traceback (most recent call last):
  File "/usr/local/boost/libs/python/pyste/src/pyste.py", line 195, in ?
    status = Main()
  File "/usr/local/boost/libs/python/pyste/src/pyste.py", line 158, in Main
    export.Parse(parser)
  File "/usr/local/boost/libs/python/pyste/src/Exporter.py", line 26, in Parse
    self.SetDeclarations(declarations)
  File "/usr/local/boost/libs/python/pyste/src/HeaderExporter.py", line 38, in SetDeclarations
    self.HandleDeclaration(decl)
  File "/usr/local/boost/libs/python/pyste/src/HeaderExporter.py", line 54, in HandleDeclaration
    self.HandleExporter(decl, exporter_class)
  File "/usr/local/boost/libs/python/pyste/src/HeaderExporter.py", line 64, in HandleExporter
    exporter.SetDeclarations(self.declarations)
  File "/usr/local/boost/libs/python/pyste/src/ClassExporter.py", line 63, in SetDeclarations
    decl = self.GetDeclaration(self.info.name)
  File "/usr/local/boost/libs/python/pyste/src/Exporter.py", line 60, in GetDeclaration
    assert len(decls) == 1
AssertionError

An example of a header file that causes this is attached.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OgreCamera.h
Type: application/octet-stream
Size: 22705 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20030505/2ecbb5c2/attachment.obj>

From paul.rudin at ntlworld.com  Mon May  5 09:52:41 2003
From: paul.rudin at ntlworld.com (Paul Rudin)
Date: 05 May 2003 08:52:41 +0100
Subject: [C++-sig] pyste - falling over on certain inputs.
In-Reply-To: <m3smrtam4j.fsf_-_@ntlworld.com>
References: <m3smrtam4j.fsf_-_@ntlworld.com>
Message-ID: <m3of2hakza.fsf@ntlworld.com>

Paul Rudin <paul.rudin at ntlworld.com> writes:

> An example of a header file that causes this is attached. ...



Hmmm - sorry that was a bad example since it includes a number of other
headers.

Maybe it's a known issue anyway?



From giulio.eulisse at cern.ch  Mon May  5 13:32:48 2003
From: giulio.eulisse at cern.ch (Giulio Eulisse)
Date: 05 May 2003 13:32:48 +0200
Subject: [C++-sig] Pyste error message...
Message-ID: <1052134368.1871.12.camel@lxcms25>

What does the following error mean?
I get it while pystifing SoCamera/SoPerspectiveCamera object from 
coin OpenInventor clone(www.coin3d.org)

Traceback (most recent call last):
  File "/localscratch/e/eulisse/pyste-0.7.2/src/pyste.py", line 195, in
?
    status = Main()
  File "/localscratch/e/eulisse/pyste-0.7.2/src/pyste.py", line 165, in
Main
    exports = [(x.Order(), x) for x in exporters.exporters]
  File "/localscratch/e/eulisse/pyste-0.7.2/src/ClassExporter.py", line
91, in Order
    return '%s_%s' % (len(self.ClassBases()), self.class_.FullName())
  File "/localscratch/e/eulisse/pyste-0.7.2/src/ClassExporter.py", line
82, in ClassBases
    GetBases(self.class_)
  File "/localscratch/e/eulisse/pyste-0.7.2/src/ClassExporter.py", line
80, in GetBases
    GetBases(base)
  File "/localscratch/e/eulisse/pyste-0.7.2/src/ClassExporter.py", line
80, in GetBases
    GetBases(base)
  File "/localscratch/e/eulisse/pyste-0.7.2/src/ClassExporter.py", line
77, in GetBases
    this_bases = [self.GetDeclaration(x.name) for x in class_.bases]
  File "/localscratch/e/eulisse/pyste-0.7.2/src/Exporter.py", line 60,
in GetDeclaration
    assert len(decls) == 1
AssertionError

Ciao,
Giulio




From djowel at gmx.co.uk  Mon May  5 18:15:00 2003
From: djowel at gmx.co.uk (Joel de Guzman)
Date: Tue, 6 May 2003 00:15:00 +0800
Subject: [C++-sig] Tutorial - Techniques
References: <3EB586B7.8090108@globalite.com.br>
Message-ID: <00be01c31321$8081bae0$0100a8c0@kim>

Nicodemus wrote:
> Hi All!
> 
> I have written the Techniques page for the Tutorial as I promised last
> week. Sorry for not finishing this earlier, but I had a lot of stuff
> from college to do. Could you people take a look and share your
> opinions (especially Ralf and Dave)?
> I didn't post a patch to the original docs, but I'm sure Joel will
> have absolutely no problem adding it. 8) Btw, Joel, all Python
> comments are getting an extra #... perhaps I am doing something wrong?
> 
> I created three sections, "Creating Packages", "Extending Wrapped
> Objects in Python" and "Reducing Compiling Time". Any comments are
> welcome! 
> 
> <cid:part1.02070604.05000309 at globalite.com.br>Regards,
> Nicodemus.

GREAT! Pardon the extra #. quickdoc was not designed, ahem, for
Python code 'o).... Sure, I'll patch the stuff in....

-- 
Joel de Guzman
joel at boost-consulting.com
http://www.boost-consulting.com
http://spirit.sf.net




From dave at boost-consulting.com  Mon May  5 20:13:09 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 05 May 2003 14:13:09 -0400
Subject: [C++-sig] Re: boost:python:embedding
In-Reply-To: <b92smh$euc$1@main.gmane.org> (Dirk Gerrits's message of "Sun,
 04 May 2003 13:15:42 +0200")
References: <E374F34816D3BE49AA6A2C37523190960A241A19@mailsto01.front.se>
	<usmrxnieu.fsf@boost-consulting.com> <b90q1o$e6i$1@main.gmane.org>
	<b90qe7$f9d$1@main.gmane.org> <b90rmk$jat$1@main.gmane.org>
	<u8ytnkbbr.fsf@boost-consulting.com> <b91dbj$d22$1@main.gmane.org>
	<uof2jisaf.fsf@boost-consulting.com> <b92smh$euc$1@main.gmane.org>
Message-ID: <uof2h5kju.fsf@boost-consulting.com>

Dirk Gerrits <dirk at gerrits.homeip.net> writes:

> Seriously though, I have some more questions.
>
> When you are embedding Python in a C++ program, your Python code may
> need to call C++ code in the embedding program. (At least, that's
> what I currently need to do.)

That seems pretty standard.  There's probably not much point in
embedding otherwise.

> To do this, you can't simply create a module_name.so or
> module_name.pyd as you'd do when extending; the BPL wrapper code
> must be in the C++ program itself. 

Loading of plugin extension libraries is disabled? Are you sure?
I can understand why you'd want to link statically, but it seems to
me that dynamic linking should still be possible... no?

> To make the module available to Python, you must call a function
> like PyImport_AppendInittab (or interpreter::add_module which I just
> whipped up ;)). The parameters to this call are the module name and
> the init function. Herein lies the problem. If the module is in a
> different compilation unit than the code using the interpreter one
> must forward declare the init function. 

OK...

> Is there currently a way to
> do this safely? Perhaps a macro like the following?
>
> #if (defined(_WIN32) || defined(__CYGWIN__)) &&
>  !defined(BOOST_PYTHON_STATIC_MODULE)
>
> #  define BOOST_PYTHON_FORWARD_DECLARE_MODULE_INIT(name)     \
> extern "C" __declspec(dllexport) void init##name();
>
> #else
>
> #  define BOOST_PYTHON_FORWARD_DECLARE_MODULE_INIT(name)     \
> extern "C" void init##name()
>
> #endif
>
> I have some issues with this though. For starters, the macro name is
> much too long for my taste. ;) 

You could leave out the word "DECLARE".

> Furthermore, I doubt if it makes sense to do this sort of embedding
> without defining BOOST_PYTHON_STATIC_MODULE. Which brings me to my
> last question.
>
> There used to be a bug which caused a 'Fatal Python error' upon
> Py_Finalize when doing this kind of embedding. But when I ran into
> that, there was no BOOST_PYTHON_STATIC_MODULE. Now, with
> BOOST_PYTHON_STATIC_MODULE I haven't been able to replicate it. Has it
> been fixed then?

No, it hasn't.  This should still be addressed, and in fact it isn't
that difficult.  As I've said before, I'm sure you could do it with a
little hand-holding.  The problem is that some references to Python
objects are being kept alive by global data
(e.g. boost::python::object instances) which must be released before
Py_Finalize is called.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From milind_patil at hotmail.com  Tue May  6 01:58:13 2003
From: milind_patil at hotmail.com (Milind Patil)
Date: Mon, 5 May 2003 16:58:13 -0700
Subject: [C++-sig] Re: Re: Re: Re: long long unsigned issue...
References: <b8uvp7$kp1$1@main.gmane.org> <uk7d8n8k7.fsf@boost-consulting.com><b91g6e$me8$1@main.gmane.org> <u65oriktt.fsf@boost-consulting.com><b91qci$oc6$1@main.gmane.org> <u1xzfiizj.fsf@boost-consulting.com><b9292b$qru$1@main.gmane.org> <u65orxage.fsf@boost-consulting.com>
Message-ID: <b96to4$d5$1@main.gmane.org>

"David Abrahams" <dave at boost-consulting.com> wrote in message
news:u65orxage.fsf at boost-consulting.com...
> "Milind Patil" <milind_patil at hotmail.com> writes:
>
> > However, I could have a Y_Wrapper class that I can add constructors to.
> > Is this possible?...
>
> Yes, that's a good approach, and the only one we currently support
> well.  Eventually it should be possible to add factory functions as
> constructors, but it isn't yet.
>
> > struct Y_Wrapper: Y {
> >   public:
> >     Y_Wrapper(PyObject* self_) : self(self_) { }
> >     /* ... more constructors ... */
> >     Y_Wrapper(PyObject* self_, boost::python::long_  y) : self(self_) { /*
> > some code to convert long_ to Y */ }
> >
> >     PyObject* self;
> > };
> >
> > BOOST_PYTHON_MODULE(hello)
> > {
> >     class_< Y, Y_Wrapper >("Y", init<  >())
> >         .def(init< const Y & >())
> >         //... more init defs ...
> >         .def(init< long_ >())
> >        //...
> >     ;
> > }
>
>
> --
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com

OK. Now when I try to add a Y_Wrapper with a constructor from long_ (with no real conversion),  at
runtime
it craps out saying

TypeError: No to_python (by-value) converter found for C++ type:
Q45boost6python7objectst18reference_to_value1ZQ35boost6python5long_

ie. with

struct Y_Wrapper: Y {
    Y_Wrapper (PyObject* self_) : Y(), self(self_) {}
    Y_Wrapper (PyObject* self_, int y) : Y(y), self(self_) {}
    Y_Wrapper (PyObject* self_, long long unsigned int y) : Y(y), self(self_) {}
    Y_Wrapper (PyObject* self_, int s,  const Y& y) : Y(s,y), self(self_) {}
    Y_Wrapper (PyObject* self_, const Y& y) : Y(y), self(self_) {}
    Y_Wrapper (PyObject* self_, boost::python::long_ y) : Y(0), self(self_) {printf("hello long_");}

    PyObject* self;
};

...and ...

    class_< Y, Y_Wrapper >("Y", init<  >())
        .def(init< const Y & >())
        .def(init< int, const Y & >())
        .def(init< int >())
        .def(init< long long unsigned int >())
        .def(init< long_ >())
        .def_readwrite("y", &Y::y)
        .def("__int__", &Y::operator int)
    ;

Any pointer as to where I am going wrong?

Thanks again,
Milind






From nicodemus at globalite.com.br  Tue May  6 02:59:01 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Mon, 05 May 2003 21:59:01 -0300
Subject: [C++-sig] pyste - falling over on certain inputs.
In-Reply-To: <m3of2hakza.fsf@ntlworld.com>
References: <m3smrtam4j.fsf_-_@ntlworld.com> <m3of2hakza.fsf@ntlworld.com>
Message-ID: <3EB708D5.4010405@globalite.com.br>

Paul Rudin wrote:

>Paul Rudin <paul.rudin at ntlworld.com> writes:
>
>  
>
>>An example of a header file that causes this is attached. ...
>>    
>>
>
>
>
>Hmmm - sorry that was a bad example since it includes a number of other
>headers.
>
>Maybe it's a known issue anyway?
>  
>

I manage to make the header to compile, but it worked just fine... but I 
don't think that tells much, because I had to make a lot of changes to 
it. Could you send me the xmls generated by GCCXML? Just run pyste with 
--debug. Also change this function of Exporter.py (line 58) from this:

    def GetDeclaration(self, fullname):
        decls = self.GetDeclarations(fullname)
        assert len(decls) == 1
        return decls[0]


to this:

    def GetDeclaration(self, fullname):
        decls = self.GetDeclarations(fullname)
        if len(decls) != 1:
            print "More than one declaration of", fullname, "found"
        return decls[0]

And see what name it prints... also, see if the generated code works for 
you. I belive it should.

Regards,
Nicodemus.




From nicodemus at globalite.com.br  Tue May  6 02:59:58 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Mon, 05 May 2003 21:59:58 -0300
Subject: [C++-sig] Pyste error message...
In-Reply-To: <1052134368.1871.12.camel@lxcms25>
References: <1052134368.1871.12.camel@lxcms25>
Message-ID: <3EB7090E.7000202@globalite.com.br>

Giulio Eulisse wrote:

>What does the following error mean?
>I get it while pystifing SoCamera/SoPerspectiveCamera object from 
>coin OpenInventor clone(www.coin3d.org)
>
>Traceback (most recent call last):
>  File "/localscratch/e/eulisse/pyste-0.7.2/src/pyste.py", line 195, in
>?
>    status = Main()
>  File "/localscratch/e/eulisse/pyste-0.7.2/src/pyste.py", line 165, in
>Main
>    exports = [(x.Order(), x) for x in exporters.exporters]
>  File "/localscratch/e/eulisse/pyste-0.7.2/src/ClassExporter.py", line
>91, in Order
>    return '%s_%s' % (len(self.ClassBases()), self.class_.FullName())
>  File "/localscratch/e/eulisse/pyste-0.7.2/src/ClassExporter.py", line
>82, in ClassBases
>    GetBases(self.class_)
>  File "/localscratch/e/eulisse/pyste-0.7.2/src/ClassExporter.py", line
>80, in GetBases
>    GetBases(base)
>  File "/localscratch/e/eulisse/pyste-0.7.2/src/ClassExporter.py", line
>80, in GetBases
>    GetBases(base)
>  File "/localscratch/e/eulisse/pyste-0.7.2/src/ClassExporter.py", line
>77, in GetBases
>    this_bases = [self.GetDeclaration(x.name) for x in class_.bases]
>  File "/localscratch/e/eulisse/pyste-0.7.2/src/Exporter.py", line 60,
>in GetDeclaration
>    assert len(decls) == 1
>AssertionError
>
>Ciao,
>Giulio
>

Please see my response to Paul Rudin... try to make the same change in 
the Pyste source, and see if it works out.




From nicodemus at globalite.com.br  Tue May  6 03:04:23 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Mon, 05 May 2003 22:04:23 -0300
Subject: [C++-sig] Re: Tutorial - Techniques
In-Reply-To: <b952p7$ka$1@main.gmane.org>
References: <3EB586B7.8090108@globalite.com.br> <b952p7$ka$1@main.gmane.org>
Message-ID: <3EB70A17.7090307@globalite.com.br>



Dirk Gerrits wrote:

> Just two minor nits about "Extending Wrapped Objects in Python":
>
> * advantages is misspelled 'advantagens' 

Oops!

> * the term 'syntax sugar' is used, I thought it was 'syntactic sugar'?

You're right, my mistake!

> Otherwise, this is great stuff! 

Thanks!

Attached is the quickdoc file with this fixes... thanks for pointing 
them out Dirk!

Regards,
Nicodemus.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: techniques.txt
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20030505/77fdd443/attachment.txt>

From dave at boost-consulting.com  Tue May  6 03:16:57 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 05 May 2003 21:16:57 -0400
Subject: [C++-sig] Re: Re: Re: Re: long long unsigned issue...
In-Reply-To: <b96to4$d5$1@main.gmane.org> (Milind Patil's message of "Mon, 5
 May 2003 16:58:13 -0700")
References: <b8uvp7$kp1$1@main.gmane.org> <uk7d8n8k7.fsf@boost-consulting.com>
	<b91g6e$me8$1@main.gmane.org> <u65oriktt.fsf@boost-consulting.com>
	<b91qci$oc6$1@main.gmane.org> <u1xzfiizj.fsf@boost-consulting.com>
	<b9292b$qru$1@main.gmane.org> <u65orxage.fsf@boost-consulting.com>
	<b96to4$d5$1@main.gmane.org>
Message-ID: <uof2g6fhy.fsf@boost-consulting.com>

"Milind Patil" <milind_patil at hotmail.com> writes:

> OK. Now when I try to add a Y_Wrapper with a constructor from long_ (with no real conversion),  at
> runtime
> it craps out saying
>
> TypeError: No to_python (by-value) converter found for C++ type:
> Q45boost6python7objectst18reference_to_value1ZQ35boost6python5long_
>
> ie. with
>
> struct Y_Wrapper: Y {
>     Y_Wrapper (PyObject* self_) : Y(), self(self_) {}
>     Y_Wrapper (PyObject* self_, int y) : Y(y), self(self_) {}
>     Y_Wrapper (PyObject* self_, long long unsigned int y) : Y(y), self(self_) {}
>     Y_Wrapper (PyObject* self_, int s,  const Y& y) : Y(s,y), self(self_) {}
>     Y_Wrapper (PyObject* self_, const Y& y) : Y(y), self(self_) {}
>     Y_Wrapper (PyObject* self_, boost::python::long_ y) : Y(0), self(self_) {printf("hello long_");}
>
>     PyObject* self;
> };
>
> ..and ...
>
>     class_< Y, Y_Wrapper >("Y", init<  >())
>         .def(init< const Y & >())
>         .def(init< int, const Y & >())
>         .def(init< int >())
>         .def(init< long long unsigned int >())
>         .def(init< long_ >())
>         .def_readwrite("y", &Y::y)
>         .def("__int__", &Y::operator int)
>     ;
>
> Any pointer as to where I am going wrong?

What is the Python code which causes the traceback?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From milind_patil at hotmail.com  Tue May  6 03:48:52 2003
From: milind_patil at hotmail.com (Milind Patil)
Date: Mon, 5 May 2003 18:48:52 -0700
Subject: [C++-sig] Re: Re: Re: Re: Re: long long unsigned issue...
References: <b8uvp7$kp1$1@main.gmane.org> <uk7d8n8k7.fsf@boost-consulting.com><b91g6e$me8$1@main.gmane.org> <u65oriktt.fsf@boost-consulting.com><b91qci$oc6$1@main.gmane.org> <u1xzfiizj.fsf@boost-consulting.com><b9292b$qru$1@main.gmane.org> <u65orxage.fsf@boost-consulting.com><b96to4$d5$1@main.gmane.org> <uof2g6fhy.fsf@boost-consulting.com>
Message-ID: <b9747j$vqv$1@main.gmane.org>

"David Abrahams" <dave at boost-consulting.com> wrote in message
news:uof2g6fhy.fsf at boost-consulting.com...
> "Milind Patil" <milind_patil at hotmail.com> writes:
>
>
> What is the Python code which causes the traceback?
>
> --
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com

x = hello.Y(4294967295)






From dave at boost-consulting.com  Tue May  6 04:10:58 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 05 May 2003 22:10:58 -0400
Subject: [C++-sig] Re: Re: Re: Re: Re: long long unsigned issue...
In-Reply-To: <b9747j$vqv$1@main.gmane.org> (Milind Patil's message of "Mon,
 5 May 2003 18:48:52 -0700")
References: <b8uvp7$kp1$1@main.gmane.org> <uk7d8n8k7.fsf@boost-consulting.com>
	<b91g6e$me8$1@main.gmane.org> <u65oriktt.fsf@boost-consulting.com>
	<b91qci$oc6$1@main.gmane.org> <u1xzfiizj.fsf@boost-consulting.com>
	<b9292b$qru$1@main.gmane.org> <u65orxage.fsf@boost-consulting.com>
	<b96to4$d5$1@main.gmane.org> <uof2g6fhy.fsf@boost-consulting.com>
	<b9747j$vqv$1@main.gmane.org>
Message-ID: <ufzns6czx.fsf@boost-consulting.com>

"Milind Patil" <milind_patil at hotmail.com> writes:

> "David Abrahams" <dave at boost-consulting.com> wrote in message
> news:uof2g6fhy.fsf at boost-consulting.com...
>> "Milind Patil" <milind_patil at hotmail.com> writes:
>>
>>
>> What is the Python code which causes the traceback?
>>
>> --
>> Dave Abrahams
>> Boost Consulting
>> www.boost-consulting.com
>
> x = hello.Y(4294967295)

Can you post the source for a complete example so I can try to
reproduce it?

This is very strange; do you see any reason that there should be a
to_python conversion involved here?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From milind_patil at hotmail.com  Tue May  6 06:42:12 2003
From: milind_patil at hotmail.com (Milind Patil)
Date: Mon, 5 May 2003 21:42:12 -0700
Subject: [C++-sig] Re: Re: Re: Re: Re: Re: long long unsigned issue...
References: <b8uvp7$kp1$1@main.gmane.org> <uk7d8n8k7.fsf@boost-consulting.com><b91g6e$me8$1@main.gmane.org> <u65oriktt.fsf@boost-consulting.com><b91qci$oc6$1@main.gmane.org> <u1xzfiizj.fsf@boost-consulting.com><b9292b$qru$1@main.gmane.org> <u65orxage.fsf@boost-consulting.com><b96to4$d5$1@main.gmane.org> <uof2g6fhy.fsf@boost-consulting.com><b9747j$vqv$1@main.gmane.org> <ufzns6czx.fsf@boost-consulting.com>
Message-ID: <b97eg3$sod$1@main.gmane.org>

"David Abrahams" <dave at boost-consulting.com> wrote in message
news:ufzns6czx.fsf at boost-consulting.com...
>
> Can you post the source for a complete example so I can try to
> reproduce it?
>

The Y class (hello.h):

class Y {
  public:
    Y() : y(0L) { }
    Y(int y) : y(y) { }
    Y(long long unsigned int y) : y(y) { }
    Y(int s, const Y & y) : y(y << s) { }
    Y(Y const& rhs) : y(rhs.y) { }
    virtual ~Y() { }

    operator int() const { return y; }

    void operator=(Y const& y) {
        this->y = y.y;
    }

    long long unsigned int y;
};

The Wrapped boost part (hello.cpp):

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

#include <boost/python.hpp>
#include <hello.h>

using namespace boost::python;

namespace {
struct Y_Wrapper: Y {
    Y_Wrapper (PyObject* self_) : Y(), self(self_) {}
    Y_Wrapper (PyObject* self_, int y) : Y(y), self(self_) {}
    Y_Wrapper (PyObject* self_, long long unsigned int y) : Y(y),
self(self_) {}
    Y_Wrapper (PyObject* self_, int s,  const Y& y) : Y(s,y), self(self_) {}
    Y_Wrapper (PyObject* self_, const Y& y) : Y(y), self(self_) {}
    Y_Wrapper (PyObject* self_, boost::python::long_ y) : Y(0), self(self_)
{printf("hello long_");}

    PyObject* self;
};
}

BOOST_PYTHON_MODULE(hello)
{
    class_< Y, Y_Wrapper >("Y", init<  >())
        .def(init< const Y & >())
        .def(init< int, const Y & >())
        .def(init< int >())
        .def(init< long long unsigned int >())
        .def(init< long_ >())
        .def_readwrite("y", &Y::y)
        .def("__int__", &Y::operator int)
    ;

    implicitly_convertible<int, Y>();
}

The python script:

import hello

x = hello.Y(4294967295)
print x.y

> This is very strange; do you see any reason that there should be a
> to_python conversion involved here?

No, I cannot even guess why to_python conversion is needed.

>
> -- 
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com






From paul.rudin at ntlworld.com  Tue May  6 07:27:49 2003
From: paul.rudin at ntlworld.com (Paul Rudin)
Date: 06 May 2003 06:27:49 +0100
Subject: [C++-sig] pyste - falling over on certain inputs.
In-Reply-To: <3EB708D5.4010405@globalite.com.br>
References: <m3smrtam4j.fsf_-_@ntlworld.com> <m3of2hakza.fsf@ntlworld.com>
	<3EB708D5.4010405@globalite.com.br>
Message-ID: <m365oofxuy.fsf@ntlworld.com>

Nicodemus <nicodemus at globalite.com.br> writes:

> Paul Rudin wrote:

[snip]

> I manage to make the header to compile, but it worked just fine... but
> I don't think that tells much, because I had to make a lot of changes
> to it. 

If you so desire it's possible to get the rest of the sources from cvs:

cvs -d:pserver:anonymous at cvs.ogre.sourceforge.net:/cvsroot/ogre login

Press 'Enter' when prompted for a password. Then:

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



>         Could you send me the xmls generated by GCCXML? Just run pyste
> with --debug. 

It's about one and a half meg I won't send it to the list - you can get
it here:

http://rudin.co.uk/ogrecamera.xml


>            Also change this function of Exporter.py (line 58) from

[snip]
> 
> to this:
> 
>     def GetDeclaration(self, fullname):
>         decls = self.GetDeclarations(fullname)
>         if len(decls) != 1:
>             print "More than one declaration of", fullname, "found"
>         return decls[0]
> 
> And see what name it prints... 

/usr/local/ogrenew/Tools/PythonInterface/pyste $ python /usr/local/boost-cvs/libs/python/pyste/src/pyste.py --debug -DHAVE_CONFIG_H -I../../../OgreMain/inclde --module Camera camera.pyste 
More than one declaration of Ogre::Camera found
More than one declaration of Ogre::Camera found

Module Camera generated
5.42 seconds

>                                  also, see if the generated code works
> for you. I belive it should.

The generated code has all the Camera (and associated wrapper
stucture) definitions and declarations twice.. other than that it
looks fine.



From sean_dunn1 at yahoo.com  Tue May  6 08:38:40 2003
From: sean_dunn1 at yahoo.com (Sean Dunn)
Date: Mon, 5 May 2003 23:38:40 -0700 (PDT)
Subject: [C++-sig] Assert's in boost.python when instanciating class
Message-ID: <20030506063840.70322.qmail@web40804.mail.yahoo.com>

I've been having troubles getting a very simple class to work in Python
after extending C++ code using boost.python.

system:
Win2k
VC6 sp5
boost.python 1.30.0 built using bjam, using pydebug dynamic link
library
python 2.2.2 debug shell

// C++ code
#include <boost/python.hpp>
using namespace boost::python;
struct SimpleTest
{
	int val;
};
class_<SimpleTest>("SimpleTest")
	.def_readwrite("val",  &SimpleTest::val)
;


Upon loading this in python, I hit a failed assert in class.cpp:
# Python output
Adding parser accelerators ...
Done.
Python 2.2.2 (#37, Apr 29 2003, 17:46:46) [MSC 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import payamodule
[8162 refs]
>>> t = payamodule.SimpleTest()
Assertion failed: self_->ob_type->ob_type == &class_metatype_object,
file ../src
/object\class.cpp, line 481

// from the debugger
self_->ob_type->ob_type == 0x1e194858
&class_metatype_object == 0x00895b80

So, the problem here seems to be that this maybe should be
assert(self_->ob_type->ob_type == class_metatype_object.ob_type);

Is this a manifestation of using the debug libraries? There is an
instance of actual running code in the non-debug case inside
class.cpp:264,find_instance_impl(). I had previously tracked down a bug
to this line in a previous test where I was calling a simple method
that would return an integer constant. It gave me a 
TypeError: bad argument type for built-in operation.

I made the above change, and although it passes the asserts, and I can
read "val", it crashes when I try to set "val". An expected PyObject*
seems to be garbage (a value of 0x00000002 instead of a sane pointer).

I'll give the normal disclaimer that I've been using boost.python for
about 24 hours now, and I really do know nothing.

Sean


=====
--

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From dirk at gerrits.homeip.net  Tue May  6 09:03:06 2003
From: dirk at gerrits.homeip.net (Dirk Gerrits)
Date: Tue, 06 May 2003 09:03:06 +0200
Subject: [C++-sig] Re: boost:python:embedding
In-Reply-To: <uof2h5kju.fsf@boost-consulting.com>
References: <E374F34816D3BE49AA6A2C37523190960A241A19@mailsto01.front.se>	<usmrxnieu.fsf@boost-consulting.com> <b90q1o$e6i$1@main.gmane.org>	<b90qe7$f9d$1@main.gmane.org> <b90rmk$jat$1@main.gmane.org>	<u8ytnkbbr.fsf@boost-consulting.com> <b91dbj$d22$1@main.gmane.org>	<uof2jisaf.fsf@boost-consulting.com> <b92smh$euc$1@main.gmane.org> <uof2h5kju.fsf@boost-consulting.com>
Message-ID: <b97mkp$jrs$1@main.gmane.org>

David Abrahams wrote:
> Dirk Gerrits <dirk at gerrits.homeip.net> writes:
> 
> 
>>To do this, you can't simply create a module_name.so or
>>module_name.pyd as you'd do when extending; the BPL wrapper code
>>must be in the C++ program itself. 
> 
> 
> Loading of plugin extension libraries is disabled? Are you sure?

No that's not what I meant. You need this only to call the C++ code from 
the embedding program. Say that the C++ program contains the functions 
foo and bar that work on some shared data. (Perhaps they are members of 
the same class.) Now if foo calls some Python code, and that Python code 
needs bar, then obviously bar can't be in a .pyd when foo is in a .exe, 
right?

> I can understand why you'd want to link statically, but it seems to
> me that dynamic linking should still be possible... no?

Yes, you can still have *other* C++ code stuffed into extension 
libaries. Sorry for the confusion. This wasn't a bug report. ;)

[snip]
 >>#  define BOOST_PYTHON_FORWARD_DECLARE_MODULE_INIT(name)     \
[snip]
>>
>>I have some issues with this though. For starters, the macro name is
>>much too long for my taste. ;) 
> 
> 
> You could leave out the word "DECLARE".

OK.

[snipped bug description]
>>Has it been fixed then?
> 
> 
> No, it hasn't.  This should still be addressed, and in fact it isn't
> that difficult.  As I've said before, I'm sure you could do it with a
> little hand-holding.  The problem is that some references to Python
> objects are being kept alive by global data
> (e.g. boost::python::object instances) which must be released before
> Py_Finalize is called.

Yes I looked into it a bit, but I haven't actually changed any code. For 
one, I'm not totally sure how the releasing should be done. Py_AtExit() 
won't suffice, so I suppose the cleanup function must be exposed to 
Python to be registered with atexit.register() through PyRun_String?

BTW, you didn't say anything about whether embedding makes sense without 
defining BOOST_PYTHON_STATIC_MODULE. My guess is that it doesn't. I'd 
have to put something about this in the tutorial and/or reference so I'd 
like your thoughts.

Dirk Gerrits





From rwgk at yahoo.com  Tue May  6 10:27:12 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 6 May 2003 01:27:12 -0700 (PDT)
Subject: [C++-sig] Assert's in boost.python when instanciating class
In-Reply-To: <20030506063840.70322.qmail@web40804.mail.yahoo.com>
Message-ID: <20030506082712.3268.qmail@web20209.mail.yahoo.com>

--- Sean Dunn <sean_dunn1 at yahoo.com> wrote:
> class_<SimpleTest>("SimpleTest")
> 	.def_readwrite("val",  &SimpleTest::val)
> ;

Please try this:

#include <boost/python/return_value_policy.hpp>
#include <boost/python/return_by_value.hpp>

class_<SimpleTest>("SimpleTest")
  .add_property("val",
    make_getter(&SimpleTest::val, return_value_policy<return_by_value()),
    make_setter(&SimpleTest::val))
;                              

If it works I am sure David can explain why (I cannot).
Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From giulio.eulisse at cern.ch  Tue May  6 12:20:28 2003
From: giulio.eulisse at cern.ch (Giulio Eulisse)
Date: 06 May 2003 12:20:28 +0200
Subject: [C++-sig] reproducing the bug (???) with -pedantic
Message-ID: <1052216429.4071.130.camel@lxcms25>

I think I menaged to create a simple example to reproduce the problem I
have with -pedantic.
 
If you use the following headers:

--BEGIN ClassA.h---
#include "ClassB.h"
class ClassA
{
public:
	ClassA (void);
	ClassB test;
};
--END---

--BEGIN ClassB.h--
class ClassB
{
public:
	ClassB;
};
---END---

The pyste file looks like 

---BEGIN Class.pyste---
ClassB=Class("ClassB",ClassB.h")
ClassA=Class("ClassA","ClassA.h")
---END---

and produces, as output:

// Includes
====================================================================
#include <boost/python.hpp>
#include <ClassB.h>
#include <ClassA.h>

// Using
=======================================================================
using namespace boost::python;

// Module
======================================================================
BOOST_PYTHON_MODULE(ClassA)
{
    class_< ClassA >("ClassA", init<  >())
        .def(init< const ClassA & >())
        .def_readwrite("test", &ClassA::test)
    ;

    class_< ClassB >("ClassB", init<  >())
        .def(init< const ClassB & >())
    ;

}

Compiling this with -pedantic turned on results in the following
error(compiles perfectly fine without -pedantic):

/localscratch/e/eulisse/boost_1_30_0/boost/python/object/make_ptr_instance.hpp: In static member function `static PyTypeObject* boost::python::objects::make_ptr_instance<T, Holder>::get_class_object_impl(const volatile U*) [with U = ClassB, T = ClassB, Holder = boost::python::objects::pointer_holder<ClassB*, ClassB>]':
/localscratch/e/eulisse/boost_1_30_0/boost/python/object/make_ptr_instance.hpp:30:   instantiated from `static PyTypeObject* boost::python::objects::make_ptr_instance<T, Holder>::get_class_object(const Ptr&) [with Ptr = ClassB*, T = ClassB, Holder = boost::python::objects::pointer_holder<ClassB*, ClassB>]'
/localscratch/e/eulisse/boost_1_30_0/boost/python/object/make_instance.hpp:25:   instantiated from `static PyObject* boost::python::objects::make_instance_impl<T, Holder, Derived>::execute(Arg&) [with Arg = ClassB*, T = ClassB, Holder = boost::python::objects::pointer_holder<ClassB*, ClassB>, Derived = boost::python::objects::make_ptr_instance<ClassB, boost::python::objects::pointer_holder<ClassB*, ClassB> >]'
/localscratch/e/eulisse/boost_1_30_0/boost/python/to_python_indirect.hpp:62:   instantiated from `static PyObject* boost::python::detail::make_reference_holder::execute(T*) [with T = ClassB]'
/localscratch/e/eulisse/boost_1_30_0/boost/python/detail/unwind_type.hpp:19:   instantiated from `Generator::result_type boost::python::detail::unwind_type_cv(U*, boost::python::detail::cv_tag<false, false>, Generator*) [with Generator = boost::python::detail::make_reference_holder, U = ClassB]'
/localscratch/e/eulisse/boost_1_30_0/boost/python/detail/unwind_type.hpp:48:   instantiated from `Generator::result_type boost::python::detail::unwind_ptr_type(U*, Generator*) [with Generator = boost::python::detail::make_reference_holder, U = ClassB]'
/localscratch/e/eulisse/boost_1_30_0/boost/python/detail/unwind_type.hpp:58:   instantiated from `static Generator::result_type boost::python::detail::unwind_helper<is_ptr>::execute(U, Generator*) [with Generator = boost::python::detail::make_reference_holder, U = ClassB*, bool is_ptr = true]'
/localscratch/e/eulisse/boost_1_30_0/boost/python/detail/unwind_type.hpp:77:   instantiated from `Generator::result_type boost::python::detail::unwind_type(const U&, Generator*) [with Generator = boost::python::detail::make_reference_holder, U = ClassB*]'
/localscratch/e/eulisse/boost_1_30_0/boost/python/detail/unwind_type.hpp:26:   instantiated from `Generator::result_type boost::python::detail::unwind_type_cv(const U*, boost::python::detail::cv_tag<true, false>, Generator*) [with Generator = boost::python::detail::make_reference_holder, U = ClassB]'
/localscratch/e/eulisse/boost_1_30_0/boost/python/detail/unwind_type.hpp:48:   instantiated from `Generator::result_type boost::python::detail::unwind_ptr_type(U*, Generator*) [with Generator = boost::python::detail::make_reference_holder, U = const ClassB]'
/localscratch/e/eulisse/boost_1_30_0/boost/python/detail/unwind_type.hpp:69:   instantiated from `static Generator::result_type boost::python::detail::unwind_helper<false>::execute(U&, Generator*) [with Generator = boost::python::detail::make_reference_holder, U = const ClassB]'
/localscratch/e/eulisse/boost_1_30_0/boost/python/detail/unwind_type.hpp:77:   instantiated from `Generator::result_type boost::python::detail::unwind_type(const U&, Generator*) [with Generator = boost::python::detail::make_reference_holder, U = ClassB]'
/localscratch/e/eulisse/boost_1_30_0/boost/python/to_python_indirect.hpp:103:   instantiated from `PyObject* boost::python::to_python_indirect<T, MakeHolder>::operator()(T) const [with T = ClassB&, MakeHolder = boost::python::detail::make_reference_holder]'
/localscratch/e/eulisse/boost_1_30_0/boost/python/data_members.hpp:49:  
instantiated from `static PyObject* boost::python::detail::member<Data,
Class, Policies>::get(Data Class::*, PyObject*, PyObject*, const
Policies&) [with Data = ClassB, Class = ClassA, Policies =
boost::python::return_internal_reference<1,
boost::python::default_call_policies>]'
/localscratch/e/eulisse/boost_1_30_0/boost/python/data_members.hpp:103:   instantiated from `boost::python::api::object boost::python::make_getter(D C::*) [with C = ClassA, D = ClassB]'
/localscratch/e/eulisse/boost_1_30_0/boost/python/class.hpp:309:  
instantiated from `boost::python::class_<T, X1, X2, X3>&
boost::python::class_<T, X1, X2, X3>::def_readwrite(const char*, D B::*)
[with D = ClassB, B = ClassA, T = ClassA, X1 =
boost::python::detail::not_specified, X2 =
boost::python::detail::not_specified, X3 =
boost::python::detail::not_specified]'
ClassA_boost.cc:15:   instantiated from here
/localscratch/e/eulisse/boost_1_30_0/boost/python/object/make_ptr_instance.hpp:37: invalid use of member `boost::mpl::bool_<false>::type'
gmake[1]: *** [ClassA_boost_pic.o] Error 1


The XML files generated by pyste are:
---BEGIN ClassB.h---
<?xml version="1.0"?>
<GCC_XML>
  <Namespace id="_1" name="::" members="_3 "/>
  <Namespace id="_2" name="std" context="_1" members=""/>
  <Class id="_3" name="ClassB" context="_1" location="f0:5" members="_4
_5 " bases=""/>
  <Constructor id="_4" name="ClassB" context="_3" location="f0:5">
    <Argument name="_ctor_arg" type="_6"/>
  </Constructor>
  <Constructor id="_5" name="ClassB" context="_3" location="f0:7"
extern="1"/>
  <ReferenceType id="_6" type="_3c"/>
  <File id="f0"
name="/localscratch/e/eulisse/tmp/IGUANA_4_2_1/src/Ig_Modules/IgOpenInventor/interface/ClassB.h"/>
</GCC_XML>
---END---

---BEGIN ClassA.h---
<?xml version="1.0"?>
<GCC_XML>
  <Namespace id="_1" name="::" members="_3 _4 "/>
  <Namespace id="_2" name="std" context="_1" members=""/>
  <Class id="_3" name="ClassA" context="_1" location="f0:8" members="_5
_6 _7 " bases=""/>
  <Class id="_4" name="ClassB" context="_1" location="f1:5" members="_8
_9 " bases=""/>
  <Field id="_5" name="test" type="_4" context="_3" location="f0:11"/>
  <Constructor id="_6" name="ClassA" context="_3" location="f0:8">
    <Argument name="_ctor_arg" type="_10"/>
  </Constructor>
  <Constructor id="_7" name="ClassA" context="_3" location="f0:10"
extern="1"/>
  <Constructor id="_8" name="ClassB" context="_4" location="f1:5">
    <Argument name="_ctor_arg" type="_11"/>
  </Constructor>
  <Constructor id="_9" name="ClassB" context="_4" location="f1:7"
extern="1"/>
  <ReferenceType id="_10" type="_3c"/>
  <ReferenceType id="_11" type="_4c"/>
  <File id="f0"
name="/localscratch/e/eulisse/tmp/IGUANA_4_2_1/src/Ig_Modules/IgOpenInventor/interface/ClassA.h"/>
  <File id="f1"
name="/localscratch/e/eulisse/tmp/IGUANA_4_2_1/src/Ig_Modules/IgOpenInventor/interface/ClassB.h"/>
</GCC_XML>
---END---

Ciao,
Giulio
PS: Sorry for the very long post, but at least understanding what is
going on is quite important for me. Many thanks in advance.




From dave at boost-consulting.com  Tue May  6 12:53:37 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 06 May 2003 06:53:37 -0400
Subject: [C++-sig] Assert's in boost.python when instanciating class
In-Reply-To: <20030506063840.70322.qmail@web40804.mail.yahoo.com> (Sean
 Dunn's message of "Mon, 5 May 2003 23:38:40 -0700 (PDT)")
References: <20030506063840.70322.qmail@web40804.mail.yahoo.com>
Message-ID: <u4r485osu.fsf@boost-consulting.com>

Sean Dunn <sean_dunn1 at yahoo.com> writes:

> // from the debugger
> self_->ob_type->ob_type == 0x1e194858

Can you tell me what self_->ob_type->ob_type->tp_name is?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Tue May  6 13:10:04 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 06 May 2003 07:10:04 -0400
Subject: [C++-sig] Assert's in boost.python when instanciating class
In-Reply-To: <20030506063840.70322.qmail@web40804.mail.yahoo.com> (Sean
 Dunn's message of "Mon, 5 May 2003 23:38:40 -0700 (PDT)")
References: <20030506063840.70322.qmail@web40804.mail.yahoo.com>
Message-ID: <uwuh449gz.fsf@boost-consulting.com>

Sean Dunn <sean_dunn1 at yahoo.com> writes:


Hum, aren't you missing something?


BOOST_PYTHON_MODULE(payamodule)
{

> // C++ code
> #include <boost/python.hpp>
> using namespace boost::python;
> struct SimpleTest
> {
> 	int val;
> };

}

> class_<SimpleTest>("SimpleTest")
> 	.def_readwrite("val",  &SimpleTest::val)
> ;


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Tue May  6 13:11:48 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 06 May 2003 07:11:48 -0400
Subject: [C++-sig] Assert's in boost.python when instanciating class
In-Reply-To: <uwuh449gz.fsf@boost-consulting.com> (David Abrahams's message
 of "Tue, 06 May 2003 07:10:04 -0400")
References: <20030506063840.70322.qmail@web40804.mail.yahoo.com>
	<uwuh449gz.fsf@boost-consulting.com>
Message-ID: <uptmw49e3.fsf@boost-consulting.com>


Of course I meant to surround the class_<...> part with the
BOOST_PYTHON_MODULE thing


// C++ code
#include <boost/python.hpp>
using namespace boost::python;
struct SimpleTest
{
	int val;
};

BOOST_PYTHON_MODULE(payamodule)
{

 class_<SimpleTest>("SimpleTest")
 	.def_readwrite("val",  &SimpleTest::val)
 ;

}


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Tue May  6 14:34:06 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 06 May 2003 08:34:06 -0400
Subject: [C++-sig] reproducing the bug (???) with -pedantic
In-Reply-To: <1052216429.4071.130.camel@lxcms25> (Giulio Eulisse's message
 of "06 May 2003 12:20:28 +0200")
References: <1052216429.4071.130.camel@lxcms25>
Message-ID: <ullxk45kx.fsf@boost-consulting.com>

Giulio Eulisse <giulio.eulisse at cern.ch> writes:

> I think I menaged to create a simple example to reproduce the problem I
> have with -pedantic.

Which version of GCC are you using?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From giulio.eulisse at cern.ch  Tue May  6 15:22:04 2003
From: giulio.eulisse at cern.ch (Giulio Eulisse)
Date: 06 May 2003 15:22:04 +0200
Subject: [C++-sig] reproducing the bug (???) with -pedantic
In-Reply-To: <ullxk45kx.fsf@boost-consulting.com>
References: <1052216429.4071.130.camel@lxcms25> 
	<ullxk45kx.fsf@boost-consulting.com>
Message-ID: <1052227325.4874.5.camel@lxcms25>

On Tue, 2003-05-06 at 14:34, David Abrahams wrote:
> Giulio Eulisse <giulio.eulisse at cern.ch> writes:
> 
> > I think I menaged to create a simple example to reproduce the problem I
> > have with -pedantic.
> 
> Which version of GCC are you using?

"gcc -v" output:

Reading specs from
/usr/local/gcc-alt-3.2/lib/gcc-lib/i686-pc-linux-gnu/3.2/specs
Configured with: ./configure --prefix=/usr/local/gcc-alt-3.2
--enable-shared
Thread model: posix
gcc version 3.2

I'm in the process of trying with 3.2.2.

Ciao,
Giulio




From giulio.eulisse at cern.ch  Tue May  6 16:02:38 2003
From: giulio.eulisse at cern.ch (Giulio Eulisse)
Date: 06 May 2003 16:02:38 +0200
Subject: [C++-sig] reproducing the bug (???) with -pedantic
In-Reply-To: <1052227325.4874.5.camel@lxcms25>
References: <1052216429.4071.130.camel@lxcms25> 
	<ullxk45kx.fsf@boost-consulting.com>  <1052227325.4874.5.camel@lxcms25>
Message-ID: <1052229759.4874.14.camel@lxcms25>

> > Which version of GCC are you using?
> 3.2
> I'm in the process of trying with 3.2.2.

Doesn't compile with 3.2.2 as well.

Ciao,
Giulio




From dave at boost-consulting.com  Tue May  6 16:04:18 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 06 May 2003 10:04:18 -0400
Subject: [C++-sig] reproducing the bug (???) with -pedantic
In-Reply-To: <1052227325.4874.5.camel@lxcms25> (Giulio Eulisse's message of
 "06 May 2003 15:22:04 +0200")
References: <1052216429.4071.130.camel@lxcms25>
	<ullxk45kx.fsf@boost-consulting.com> <1052227325.4874.5.camel@lxcms25>
Message-ID: <uhe8841el.fsf@boost-consulting.com>

Giulio Eulisse <giulio.eulisse at cern.ch> writes:

> On Tue, 2003-05-06 at 14:34, David Abrahams wrote:
>> Giulio Eulisse <giulio.eulisse at cern.ch> writes:
>> 
>> > I think I menaged to create a simple example to reproduce the problem I
>> > have with -pedantic.
>> 
>> Which version of GCC are you using?
>
> "gcc -v" output:
>
> Reading specs from
> /usr/local/gcc-alt-3.2/lib/gcc-lib/i686-pc-linux-gnu/3.2/specs
> Configured with: ./configure --prefix=/usr/local/gcc-alt-3.2
> --enable-shared
> Thread model: posix
> gcc version 3.2
>
> I'm in the process of trying with 3.2.2.

try changing line 37 of make_ptr_instance.hpp from:

        PyTypeObject* derived = get_derived_class_object(is_polymorphic<U>::type(), p);

to 

        PyTypeObject* derived = get_derived_class_object(typename is_polymorphic<U>::type(), p);
                                                         ^^^^^^^^

and let me know.
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From giulio.eulisse at cern.ch  Tue May  6 16:14:07 2003
From: giulio.eulisse at cern.ch (Giulio Eulisse)
Date: 06 May 2003 16:14:07 +0200
Subject: [C++-sig] reproducing the bug (???) with -pedantic
In-Reply-To: <uhe8841el.fsf@boost-consulting.com>
References: <1052216429.4071.130.camel@lxcms25>
	<ullxk45kx.fsf@boost-consulting.com> <1052227325.4874.5.camel@lxcms25> 
	<uhe8841el.fsf@boost-consulting.com>
Message-ID: <1052230449.4701.17.camel@lxcms25>

> try changing line 37 of make_ptr_instance.hpp from:
>         PyTypeObject* derived = get_derived_class_object(is_polymorphic<U>::type(), p);
> to 
>         PyTypeObject* derived = get_derived_class_object(typename is_polymorphic<U>::type(), p);
> and let me know.

It works! Thanks a lot!

Ciao,
Giulio




From dave at boost-consulting.com  Tue May  6 16:35:29 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 06 May 2003 10:35:29 -0400
Subject: [C++-sig] reproducing the bug (???) with -pedantic
In-Reply-To: <1052230449.4701.17.camel@lxcms25> (Giulio Eulisse's message of
 "06 May 2003 16:14:07 +0200")
References: <1052216429.4071.130.camel@lxcms25>
	<1052227325.4874.5.camel@lxcms25> <uhe8841el.fsf@boost-consulting.com>
	<1052230449.4701.17.camel@lxcms25>
Message-ID: <ud6iw3zym.fsf@boost-consulting.com>

Giulio Eulisse <giulio.eulisse at cern.ch> writes:

>> try changing line 37 of make_ptr_instance.hpp from:
>>         PyTypeObject* derived = get_derived_class_object(is_polymorphic<U>::type(), p);
>> to 
>>         PyTypeObject* derived = get_derived_class_object(typename is_polymorphic<U>::type(), p);
>> and let me know.
>
> It works! Thanks a lot!

Please let me know if you find any other problems with -pedantic.
You might even try some similar fixes; the compiler's last message
pointed me directly at that line.

I'm surprised you're not hearing a lot of complaints about `long long'
from the compiler; that's what happens to me when I use -pedantic.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From giulio.eulisse at cern.ch  Tue May  6 16:41:13 2003
From: giulio.eulisse at cern.ch (Giulio Eulisse)
Date: 06 May 2003 16:41:13 +0200
Subject: [C++-sig] reproducing the bug (???) with -pedantic
In-Reply-To: <ud6iw3zym.fsf@boost-consulting.com>
References: <1052216429.4071.130.camel@lxcms25>
	<1052227325.4874.5.camel@lxcms25> <uhe8841el.fsf@boost-consulting.com>
	<1052230449.4701.17.camel@lxcms25>  <ud6iw3zym.fsf@boost-consulting.com>
Message-ID: <1052232074.4874.29.camel@lxcms25>

> Please let me know if you find any other problems with -pedantic.

Sure. Thanks again.

Ciao,
Giulio





From dave at boost-consulting.com  Tue May  6 17:40:37 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 06 May 2003 11:40:37 -0400
Subject: [C++-sig] Re: long long unsigned issue...
References: <b8uvp7$kp1$1@main.gmane.org> <uk7d8n8k7.fsf@boost-consulting.com>
 <b91g6e$me8$1@main.gmane.org> <u65oriktt.fsf@boost-consulting.com>
 <b91qci$oc6$1@main.gmane.org> <u1xzfiizj.fsf@boost-consulting.com>
 <b9292b$qru$1@main.gmane.org> <u65orxage.fsf@boost-consulting.com>
 <b96to4$d5$1@main.gmane.org> <uof2g6fhy.fsf@boost-consulting.com>
 <b9747j$vqv$1@main.gmane.org> <ufzns6czx.fsf@boost-consulting.com>
 <b97eg3$sod$1@main.gmane.org>
Message-ID: <uvfwo2idm.fsf@boost-consulting.com>

"Milind Patil" <milind_patil at hotmail.com> writes:

>> This is very strange; do you see any reason that there should be a
>> to_python conversion involved here?
>
> No, I cannot even guess why to_python conversion is needed.

Actually, this problem turns out to be difficult to solve. It's going
to take me a few days to get to it at least.  Sorry about that.

-Dave

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Tue May  6 17:13:21 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 06 May 2003 11:13:21 -0400
Subject: [C++-sig] Re: long long unsigned issue...
References: <b8uvp7$kp1$1@main.gmane.org> <uk7d8n8k7.fsf@boost-consulting.com>
 <b91g6e$me8$1@main.gmane.org> <u65oriktt.fsf@boost-consulting.com>
 <b91qci$oc6$1@main.gmane.org> <u1xzfiizj.fsf@boost-consulting.com>
 <b9292b$qru$1@main.gmane.org> <u65orxage.fsf@boost-consulting.com>
 <b96to4$d5$1@main.gmane.org> <uof2g6fhy.fsf@boost-consulting.com>
 <b9747j$vqv$1@main.gmane.org> <ufzns6czx.fsf@boost-consulting.com>
 <b97eg3$sod$1@main.gmane.org>
Message-ID: <u8ytk3y7i.fsf@boost-consulting.com>

"Milind Patil" <milind_patil at hotmail.com> writes:

>> This is very strange; do you see any reason that there should be a
>> to_python conversion involved here?
>
> No, I cannot even guess why to_python conversion is needed.

The reason is complicated.  I have a fix which I plan to check in
shortly, after the tests are complete.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Tue May  6 18:51:00 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 06 May 2003 12:51:00 -0400
Subject: [C++-sig] Re: boost:python:embedding
In-Reply-To: <b97mkp$jrs$1@main.gmane.org> (Dirk Gerrits's message of "Tue,
 06 May 2003 09:03:06 +0200")
References: <E374F34816D3BE49AA6A2C37523190960A241A19@mailsto01.front.se>
	<usmrxnieu.fsf@boost-consulting.com> <b90q1o$e6i$1@main.gmane.org>
	<b90qe7$f9d$1@main.gmane.org> <b90rmk$jat$1@main.gmane.org>
	<u8ytnkbbr.fsf@boost-consulting.com> <b91dbj$d22$1@main.gmane.org>
	<uof2jisaf.fsf@boost-consulting.com> <b92smh$euc$1@main.gmane.org>
	<uof2h5kju.fsf@boost-consulting.com> <b97mkp$jrs$1@main.gmane.org>
Message-ID: <uisso2f4b.fsf@boost-consulting.com>

Dirk Gerrits <dirk at gerrits.homeip.net> writes:

> David Abrahams wrote:
>> Dirk Gerrits <dirk at gerrits.homeip.net> writes:
>> 
>>>To do this, you can't simply create a module_name.so or
>>>module_name.pyd as you'd do when extending; the BPL wrapper code
>>> must be in the C++ program itself.
>> Loading of plugin extension libraries is disabled? Are you sure?
>
> No that's not what I meant. You need this only to call the C++ code
> from the embedding program. Say that the C++ program contains the
> functions foo and bar that work on some shared data. (Perhaps they are
> members of the same class.) Now if foo calls some Python code, and
> that Python code needs bar, then obviously bar can't be in a .pyd when
> foo is in a .exe, right?

Ahhm.  Not on Windows, no.  You'd have to link your application and
the .pyd to the Python DLL, instead of linking Python into your
program statically.  On most Unices, extension modules actually get
their Python symbols resolved back into the python executable.

>> I can understand why you'd want to link statically, but it seems to
>> me that dynamic linking should still be possible... no?
>
> Yes, you can still have *other* C++ code stuffed into extension
> libaries. Sorry for the confusion. This wasn't a bug report. ;)
>
> [snip]
>  >>#  define BOOST_PYTHON_FORWARD_DECLARE_MODULE_INIT(name)     \
> [snip]
>>>
>>>I have some issues with this though. For starters, the macro name is
>>> much too long for my taste. ;)
>> You could leave out the word "DECLARE".
>
> OK.
>
> Yes I looked into it a bit, but I haven't actually changed any
> code. For one, I'm not totally sure how the releasing should be
> done. Py_AtExit() won't suffice

Why, pray tell?

> so I suppose the cleanup function must be exposed to Python to be
> registered with atexit.register() through PyRun_String?

I guess that would be fine.

> BTW, you didn't say anything about whether embedding makes sense
> without defining BOOST_PYTHON_STATIC_MODULE. 

Probably because I don't know ;-)

> My guess is that it doesn't. I'd have to put something about this in
> the tutorial and/or reference so I'd like your thoughts.

Sorry...

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dirk at gerrits.homeip.net  Tue May  6 19:04:28 2003
From: dirk at gerrits.homeip.net (Dirk Gerrits)
Date: Tue, 06 May 2003 19:04:28 +0200
Subject: [C++-sig] Re: boost:python:embedding
In-Reply-To: <uisso2f4b.fsf@boost-consulting.com>
References: <E374F34816D3BE49AA6A2C37523190960A241A19@mailsto01.front.se>	<usmrxnieu.fsf@boost-consulting.com> <b90q1o$e6i$1@main.gmane.org>	<b90qe7$f9d$1@main.gmane.org> <b90rmk$jat$1@main.gmane.org>	<u8ytnkbbr.fsf@boost-consulting.com> <b91dbj$d22$1@main.gmane.org>	<uof2jisaf.fsf@boost-consulting.com> <b92smh$euc$1@main.gmane.org>	<uof2h5kju.fsf@boost-consulting.com> <b97mkp$jrs$1@main.gmane.org> <uisso2f4b.fsf@boost-consulting.com>
Message-ID: <b98psb$lfq$1@main.gmane.org>

David Abrahams wrote:
> Dirk Gerrits <dirk at gerrits.homeip.net> writes:
> 
> 
>>David Abrahams wrote:
>>
>>>Dirk Gerrits <dirk at gerrits.homeip.net> writes:
>>
>>No that's not what I meant. You need this only to call the C++ code
>>from the embedding program. Say that the C++ program contains the
>>functions foo and bar that work on some shared data. (Perhaps they are
>>members of the same class.) Now if foo calls some Python code, and
>>that Python code needs bar, then obviously bar can't be in a .pyd when
>>foo is in a .exe, right?
> 
> 
> Ahhm.  Not on Windows, no.  You'd have to link your application and
> the .pyd to the Python DLL, instead of linking Python into your
> program statically.  On most Unices, extension modules actually get
> their Python symbols resolved back into the python executable.

Interesting! I think I'll need to update the tutorial on this. At the 
moment it only mentions linking Python statically to the embedding program.

>>Yes I looked into it a bit, but I haven't actually changed any
>>code. For one, I'm not totally sure how the releasing should be
>>done. Py_AtExit() won't suffice
> 
> 
> Why, pray tell?

 From the docs:

int Py_AtExit(void (*func) ())
     Register a cleanup function to be called by Py_Finalize()
[snip]
Since Python's internal finallization will have completed before the 
cleanup function, no Python APIs should be called by func.

I assumed that the releasing would need to make Python API calls. But 
perhaps I'm mistaken?

>>so I suppose the cleanup function must be exposed to Python to be
>>registered with atexit.register() through PyRun_String?
> 
> 
> I guess that would be fine.
> 
> 
>>BTW, you didn't say anything about whether embedding makes sense
>>without defining BOOST_PYTHON_STATIC_MODULE. 
> 
> 
> Probably because I don't know ;-)

I see. I guess I'll have to look into it then. ;)

Dirk Gerrits





From dave at boost-consulting.com  Tue May  6 20:39:44 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 06 May 2003 14:39:44 -0400
Subject: [C++-sig] Re: boost:python:embedding
In-Reply-To: <b98psb$lfq$1@main.gmane.org> (Dirk Gerrits's message of "Tue,
 06 May 2003 19:04:28 +0200")
References: <E374F34816D3BE49AA6A2C37523190960A241A19@mailsto01.front.se>
	<usmrxnieu.fsf@boost-consulting.com> <b90q1o$e6i$1@main.gmane.org>
	<b90qe7$f9d$1@main.gmane.org> <b90rmk$jat$1@main.gmane.org>
	<u8ytnkbbr.fsf@boost-consulting.com> <b91dbj$d22$1@main.gmane.org>
	<uof2jisaf.fsf@boost-consulting.com> <b92smh$euc$1@main.gmane.org>
	<uof2h5kju.fsf@boost-consulting.com> <b97mkp$jrs$1@main.gmane.org>
	<uisso2f4b.fsf@boost-consulting.com> <b98psb$lfq$1@main.gmane.org>
Message-ID: <u7k933onj.fsf@boost-consulting.com>

Dirk Gerrits <dirk at gerrits.homeip.net> writes:

>>>Yes I looked into it a bit, but I haven't actually changed any
>>>code. For one, I'm not totally sure how the releasing should be
>>>done. Py_AtExit() won't suffice
>> Why, pray tell?
>
>  From the docs:
>
> int Py_AtExit(void (*func) ())
>      Register a cleanup function to be called by Py_Finalize()
> [snip]
> Since Python's internal finallization will have completed before the
> cleanup function, no Python APIs should be called by func.

I'm not sure if these docs are accurate; I checked into it once.  You
might want to use the source (Luke).

> I assumed that the releasing would need to make Python API calls. But
> perhaps I'm mistaken?

No, you're correct.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dirk at gerrits.homeip.net  Tue May  6 23:10:42 2003
From: dirk at gerrits.homeip.net (Dirk Gerrits)
Date: Tue, 06 May 2003 23:10:42 +0200
Subject: [C++-sig] Re: boost:python:embedding
In-Reply-To: <u7k933onj.fsf@boost-consulting.com>
References: <E374F34816D3BE49AA6A2C37523190960A241A19@mailsto01.front.se>	<usmrxnieu.fsf@boost-consulting.com> <b90q1o$e6i$1@main.gmane.org>	<b90qe7$f9d$1@main.gmane.org> <b90rmk$jat$1@main.gmane.org>	<u8ytnkbbr.fsf@boost-consulting.com> <b91dbj$d22$1@main.gmane.org>	<uof2jisaf.fsf@boost-consulting.com> <b92smh$euc$1@main.gmane.org>	<uof2h5kju.fsf@boost-consulting.com> <b97mkp$jrs$1@main.gmane.org>	<uisso2f4b.fsf@boost-consulting.com> <b98psb$lfq$1@main.gmane.org> <u7k933onj.fsf@boost-consulting.com>
Message-ID: <b9989v$db$1@main.gmane.org>

David Abrahams wrote:
> Dirk Gerrits <dirk at gerrits.homeip.net> writes:
> 
>> From the docs:
>>
>>int Py_AtExit(void (*func) ())
>>     Register a cleanup function to be called by Py_Finalize()
>>[snip]
>>Since Python's internal finallization will have completed before the
>>cleanup function, no Python APIs should be called by func.
> 
> 
> I'm not sure if these docs are accurate; I checked into it once.  You
> might want to use the source (Luke).

It seems to me that the docs are accurate. call_ll_exitfuncs() is the 
very last thing done by Py_Finalize() in the CVS source 
(Python/pythonrun.c).

>>I assumed that the releasing would need to make Python API calls. But
>>perhaps I'm mistaken?
> 
> 
> No, you're correct.

Ok, atexit.register() it is then?

Dirk Gerrits






From dave at boost-consulting.com  Tue May  6 23:40:17 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 06 May 2003 17:40:17 -0400
Subject: [C++-sig] Re: boost:python:embedding
In-Reply-To: <b9989v$db$1@main.gmane.org> (Dirk Gerrits's message of "Tue,
 06 May 2003 23:10:42 +0200")
References: <E374F34816D3BE49AA6A2C37523190960A241A19@mailsto01.front.se>
	<usmrxnieu.fsf@boost-consulting.com> <b90q1o$e6i$1@main.gmane.org>
	<b90qe7$f9d$1@main.gmane.org> <b90rmk$jat$1@main.gmane.org>
	<u8ytnkbbr.fsf@boost-consulting.com> <b91dbj$d22$1@main.gmane.org>
	<uof2jisaf.fsf@boost-consulting.com> <b92smh$euc$1@main.gmane.org>
	<uof2h5kju.fsf@boost-consulting.com> <b97mkp$jrs$1@main.gmane.org>
	<uisso2f4b.fsf@boost-consulting.com> <b98psb$lfq$1@main.gmane.org>
	<u7k933onj.fsf@boost-consulting.com> <b9989v$db$1@main.gmane.org>
Message-ID: <uel3b21q6.fsf@boost-consulting.com>

Dirk Gerrits <dirk at gerrits.homeip.net> writes:

>> I'm not sure if these docs are accurate; I checked into it once.  You
>> might want to use the source (Luke).
>
> It seems to me that the docs are accurate. call_ll_exitfuncs() is the
> very last thing done by Py_Finalize() in the CVS source
> (Python/pythonrun.c).
>
>>>I assumed that the releasing would need to make Python API calls. But
>>>perhaps I'm mistaken?
>> No, you're correct.
>
> Ok, atexit.register() it is then?

Sounds good to me.

Before you start making code modifications, we should discuss what
kind of infrastructure we'll want in the project to handle this sort
of thing.  I don't have anything particular in mind yet, so feel free
to make suggestions.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From varora at bofasecurities.com  Wed May  7 17:53:32 2003
From: varora at bofasecurities.com (Arora, Vivek)
Date: Wed, 7 May 2003 11:53:32 -0400 
Subject: [C++-sig] Using Boost Pyhton as a C++ Reflection Library
Message-ID: <41592908789ED611B9420008023E865E02DA1995@ny-exch-2.montgomery.com>

In addition to exposing C++ classes to Python is  Boost a good option
for use as a reflection library? i.e. is it possible to enumerate and 
invoke methods and access fields reflected by the Boost Macros(or Pyste) 
directly within C++. Offcourse one  obvious way is to invoke methods
indirectly via the Python interpreter but this will be quite inefficient.
  
Thanks
Vivek Arora







_____________________________________________________________________ 
IMPORTANT NOTICES: 
          This message is intended only for the addressee. Please notify the
sender by e-mail if you are not the intended recipient. If you are not the
intended recipient, you may not copy, disclose, or distribute this message
or its contents to any other person and any such actions may be unlawful.

         Banc of America Securities LLC("BAS") does not accept time
sensitive, action-oriented messages or transaction orders, including orders
to purchase or sell securities, via e-mail.

         BAS reserves the right to monitor and review the content of all
messages sent to or from this e-mail address. Messages sent to or from this
e-mail address may be stored on the BAS e-mail system.





From nicodemus at globalite.com.br  Thu May  8 12:41:08 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Thu, 08 May 2003 07:41:08 -0300
Subject: [C++-sig] pyste - falling over on certain inputs.
In-Reply-To: <m365oofxuy.fsf@ntlworld.com>
References: <m3smrtam4j.fsf_-_@ntlworld.com> <m3of2hakza.fsf@ntlworld.com>	<3EB708D5.4010405@globalite.com.br> <m365oofxuy.fsf@ntlworld.com>
Message-ID: <3EBA3444.7080709@globalite.com.br>

Paul Rudin wrote:

>The generated code has all the Camera (and associated wrapper
>stucture) definitions and declarations twice.. other than that it
>looks fine.
>

This issue has been fixed in CVS. Thanks to Paul and Giulio for the bug 
report, and wilingness to send xml data and discuss the problem.

Regards,
Nicodemus.




From dave at boost-consulting.com  Thu May  8 13:06:19 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 08 May 2003 07:06:19 -0400
Subject: [C++-sig] Assert's in boost.python when instanciating class
In-Reply-To: <20030506063840.70322.qmail@web40804.mail.yahoo.com> (Sean
 Dunn's message of "Mon, 5 May 2003 23:38:40 -0700 (PDT)")
References: <20030506063840.70322.qmail@web40804.mail.yahoo.com>
Message-ID: <uu1c5sno4.fsf@boost-consulting.com>

Sean Dunn <sean_dunn1 at yahoo.com> writes:

> I've been having troubles getting a very simple class to work in Python
> after extending C++ code using boost.python.
>
> system:
> Win2k
> VC6 sp5
> boost.python 1.30.0 built using bjam, using pydebug dynamic link
> library
> python 2.2.2 debug shell
>
> // C++ code
> #include <boost/python.hpp>
> using namespace boost::python;
> struct SimpleTest
> {
> 	int val;
> };
> class_<SimpleTest>("SimpleTest")
> 	.def_readwrite("val",  &SimpleTest::val)
> ;

And how are you building your extension module?  Did you try doing it
as described here:
http://www.boost.org/libs/python/doc/building.html#easy?

> Upon loading this in python, I hit a failed assert in class.cpp:
> # Python output
> Adding parser accelerators ...
> Done.
> Python 2.2.2 (#37, Apr 29 2003, 17:46:46) [MSC 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import payamodule
> [8162 refs]
>>>> t = payamodule.SimpleTest()
> Assertion failed: self_->ob_type->ob_type == &class_metatype_object,
> file ../src
> /object\class.cpp, line 481
>
> // from the debugger
> self_->ob_type->ob_type == 0x1e194858
> &class_metatype_object == 0x00895b80
>
> So, the problem here seems to be that this maybe should be
> assert(self_->ob_type->ob_type == class_metatype_object.ob_type);

No, the original assertion is correct.  Since class_metatype_object's
type is simply 'type', as is the type of most other types, your
version of the assertion tests almost nothing.

When an assert fails, responding with "maybe the assertion's wrong and
I should change it so that it shuts up" will usually lead you down a
false path, as it has here.

> Is this a manifestation of using the debug libraries? 

Quite possibly. If you didn't build your extension module with the
same debug options, object layout could be different.  That might
mean that the ob_type field of the `self_' object falls right where
another PyObject* is located in your object.  That's why I am
suggesting that you follow the build instructions above first.

> There is an instance of actual running code in the non-debug case
> inside class.cpp:264,find_instance_impl().

That sentence is incomprehensible to me.  Could you elaborate?

> I had previously tracked down a bug to this line in a previous test
> where I was calling a simple method that would return an integer
> constant. It gave me a TypeError: bad argument type for built-in
> operation.
>
> I made the above change, and although it passes the asserts, and I can
> read "val", it crashes when I try to set "val". 

Asserts are there to stop the code when something goes wrong *before*
a crash occurs.

> An expected PyObject* seems to be garbage (a value of 0x00000002
> instead of a sane pointer).
>
> I'll give the normal disclaimer that I've been using boost.python for
> about 24 hours now, and I really do know nothing.

Probably a bad time to start disabling its internal checks, my man!

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dirk at gerrits.homeip.net  Thu May  8 19:07:27 2003
From: dirk at gerrits.homeip.net (Dirk Gerrits)
Date: Thu, 08 May 2003 19:07:27 +0200
Subject: [C++-sig] Re: boost:python:embedding
In-Reply-To: <uel3b21q6.fsf@boost-consulting.com>
References: <E374F34816D3BE49AA6A2C37523190960A241A19@mailsto01.front.se>	<usmrxnieu.fsf@boost-consulting.com> <b90q1o$e6i$1@main.gmane.org>	<b90qe7$f9d$1@main.gmane.org> <b90rmk$jat$1@main.gmane.org>	<u8ytnkbbr.fsf@boost-consulting.com> <b91dbj$d22$1@main.gmane.org>	<uof2jisaf.fsf@boost-consulting.com> <b92smh$euc$1@main.gmane.org>	<uof2h5kju.fsf@boost-consulting.com> <b97mkp$jrs$1@main.gmane.org>	<uisso2f4b.fsf@boost-consulting.com> <b98psb$lfq$1@main.gmane.org>	<u7k933onj.fsf@boost-consulting.com> <b9989v$db$1@main.gmane.org> <uel3b21q6.fsf@boost-consulting.com>
Message-ID: <b9e2pq$v3v$1@main.gmane.org>

David Abrahams wrote:
> Dirk Gerrits <dirk at gerrits.homeip.net> writes:
>>
>>Ok, atexit.register() it is then?
> 
> 
> Sounds good to me.
> 
> Before you start making code modifications, we should discuss what
> kind of infrastructure we'll want in the project to handle this sort
> of thing.  I don't have anything particular in mind yet, so feel free
> to make suggestions.

I'll look into BPL's architecture in some more detail before I can make 
an educated suggestion. But I planned to do that anyway. ;)

Dirk Gerrits






From dave at boost-consulting.com  Fri May  9 18:23:55 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 09 May 2003 12:23:55 -0400
Subject: [C++-sig] Using Boost Pyhton as a C++ Reflection Library
In-Reply-To: <41592908789ED611B9420008023E865E02DA1995@ny-exch-2.montgomery.com> (Vivek
 Arora's message of "Wed, 7 May 2003 11:53:32 -0400")
References: <41592908789ED611B9420008023E865E02DA1995@ny-exch-2.montgomery.com>
Message-ID: <uel3884x0.fsf@boost-consulting.com>

"Arora, Vivek" <varora at bofasecurities.com> writes:

> In addition to exposing C++ classes to Python is  Boost a good option
> for use as a reflection library? i.e. is it possible to enumerate and 
> invoke methods and access fields reflected by the Boost Macros(or Pyste) 
> directly within C++. Offcourse one  obvious way is to invoke methods
> indirectly via the Python interpreter but this will be quite inefficient.

I don't think Boost.Python is a particularly good tool for that unless
you need Python bindings anyway... and even then, some information
about argument lists, overloads, etc., would be lost.  I *have* been
thinking for some time that a Pyste-like system could be used to
generate MPL-compatible class descriptions that could be explored at
compile-time or at runtime.

For example, given:

    class X
    {
       int f(double);
       char* x;
       static int y;
    };

You might generate, as a starting point:

    template <class T, T v, char const*> struct member {};
    template <class T> struct members;

    template <>
    struct members<X>
      : mpl::vector<
            member<int(X::*)(double), &X::f, "f">
          , member<char*(X::*), &X::x, "x">
          , member<int&, X::y, "y">
        >
    {
    };


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From franke at ableton.com  Fri May  9 19:30:08 2003
From: franke at ableton.com (Stefan Franke)
Date: Fri, 9 May 2003 19:30:08 +0200
Subject: [C++-sig] Using Boost Pyhton as a C++ Reflection Library
In-Reply-To: <uel3884x0.fsf@boost-consulting.com>
Message-ID: <E36E759773705945AD00AB9A1A46140A0A5756@sky.office.ableton.com>

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org]On
> Behalf Of David Abrahams
...
> 
> I don't think Boost.Python is a particularly good tool for that unless
> you need Python bindings anyway... and even then, some information
> about argument lists, overloads, etc., would be lost.  I *have* been
> thinking for some time that a Pyste-like system could be used to
> generate MPL-compatible class descriptions that could be explored at
> compile-time or at runtime.
> 

Sorry, I'm completely ignorant of the MPL stuff: How would 
you iterate over this structure at runtime and do something
meaningful with the member descriptors (e.g. use them to
stream out some members for persistency)?

How could objects refer to their class descriptors?


Thanks for enlightenment,
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20030509/c4680fdd/attachment.htm>

From jochen at neverEngine.com  Mon May 12 09:58:23 2003
From: jochen at neverEngine.com (jochen)
Date: Mon, 12 May 2003 09:58:23 +0200
Subject: [C++-sig] boost_1_30_00
Message-ID: <FOEEIHHKFDJPFLJCHLAKOEFNCAAA.jochen@neverEngine.com>

I recently switched to boost_1_30_00 from boost_1_29_00

I include the boost_python headers from within my precompiled header file:

#if defined _DEBUG
#pragma message( "Using boost wrapper to include Python.h" )
#include <boost/python/detail/wrap_python.hpp>
#else
#include <Python.h>
#endif //_DEBUG


#pragma warning( push )

#pragma warning( disable: 4800 )
#pragma warning( disable: 4275 )
#pragma warning( disable: 4251 )
#pragma warning( disable: 4267 )

#include <boost/python.hpp>

#pragma warning( pop )


when using the new version 1_30_00, I get an internal compiler error from
within

e:\boost\boost_1_30_0\boost\python\detail\convertible.hpp(25) : fatal error
C1001: INTERNER COMPILERFEHLER        (Compilerdatei "msc1.cpp", Zeile 2844)


Has somebody else encountered these problems ?




From jeff at brewer.com  Mon May 12 11:50:18 2003
From: jeff at brewer.com (Jeff Brewer)
Date: Mon, 12 May 2003 02:50:18 -0700
Subject: [C++-sig] boost_1_30_00
Message-ID: <3C609AD34AAF22488364057AA72EAC14019EE337@adsl-64-170-107-114.dsl.snfc21.pacbell.net>

Microsoft should be using Boost to test their compiler because with all
the templates, you basically can't use precompiled headers with Boost
Python (I tried for a little while). It's not too bad without
precompiled headers on a fast machine, but it would be nice if Microsoft
would fix their compiler.

Jeff Brewer

-----Original Message-----
From: jochen [mailto:jochen at neverEngine.com] 
Posted At: Monday, May 12, 2003 12:58 AM
Posted To: c++-sig
Conversation: [C++-sig] boost_1_30_00
Subject: [C++-sig] boost_1_30_00

I recently switched to boost_1_30_00 from boost_1_29_00

I include the boost_python headers from within my precompiled header
file:

#if defined _DEBUG
#pragma message( "Using boost wrapper to include Python.h" )
#include <boost/python/detail/wrap_python.hpp>
#else
#include <Python.h>
#endif //_DEBUG


#pragma warning( push )

#pragma warning( disable: 4800 )
#pragma warning( disable: 4275 )
#pragma warning( disable: 4251 )
#pragma warning( disable: 4267 )

#include <boost/python.hpp>

#pragma warning( pop )


when using the new version 1_30_00, I get an internal compiler error
from
within

e:\boost\boost_1_30_0\boost\python\detail\convertible.hpp(25) : fatal
error
C1001: INTERNER COMPILERFEHLER        (Compilerdatei "msc1.cpp", Zeile
2844)


Has somebody else encountered these problems ?


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




From rwgk at yahoo.com  Mon May 12 11:52:50 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 12 May 2003 02:52:50 -0700 (PDT)
Subject: [C++-sig] boost_1_30_00
In-Reply-To: <FOEEIHHKFDJPFLJCHLAKOEFNCAAA.jochen@neverEngine.com>
Message-ID: <20030512095250.66938.qmail@web20202.mail.yahoo.com>

--- jochen <jochen at neverEngine.com> wrote:
> when using the new version 1_30_00, I get an internal compiler error from
> within
> 
> e:\boost\boost_1_30_0\boost\python\detail\convertible.hpp(25) : fatal error
> C1001: INTERNER COMPILERFEHLER        (Compilerdatei "msc1.cpp", Zeile 2844)
> 
> 
> Has somebody else encountered these problems ?

Before the release we've verified that all tests in libs/python/test compile
and run with VC6 and VC7.0. Do you get the ICE even if you just include the
quoted header file? Or is there more code involved?

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From jochen at neverEngine.com  Tue May 13 16:39:53 2003
From: jochen at neverEngine.com (jochen)
Date: Tue, 13 May 2003 16:39:53 +0200
Subject: [C++-sig] boost_1_30_00
Message-ID: <FOEEIHHKFDJPFLJCHLAKMEFOCAAA.jochen@neverEngine.com>

This is the complete stdafx.h header file.
It compiles well and can perfectly be used with boost_1_29_00,
but when compiling with 1_30_00 I get the internal compiler error #C1001
within every .cpp file.



/////////////////////////////////////////////////////////////////////
// Source Safe
// $Header:
/neverEngine/neverEngineProjects/neverEngineScenePack/Include/StdAfx.h 2
9.05.03 22:12 Jochen $
// end of Source Safe
/////////////////////////////////////////////////////////////////////


#if ! defined NEVERENGINE_SCENE_PACK_STDAFX_HEADER
#define NEVERENGINE_SCENE_PACK_STDAFX_HEADER


#pragma once

#define WIN32_LEAN_AND_MEAN		// Selten verwendete Teile der Windows-Header
nicht einbinden
#define STRICT

#include <windows.h>
#include <wtypes.h>

#include <iostream>
#include <fstream>
#include <sstream>
#include <string>
#include <vector>
#include <stack>
#include <list>
#include <set>
#include <map>
#include <hash_map>
#include <locale>
#include <iomanip>
#include <algorithm>
#include <memory>

#include <cassert>
#include <ctime>

#pragma warning( push )

#pragma warning( disable: 4800 )
#pragma warning( disable: 4275 )
#pragma warning( disable: 4251 )
#pragma warning( disable: 4267 )

#include <boost/python.hpp>

#pragma warning( pop )


// initiate linking with the boost_python lib
#if defined _DEBUG
#pragma comment ( lib, "boost_python_debug" )
#else
#pragma comment ( lib, "boost_python" )
#endif // _DEBUG

#include <d3d9.h>
#include <d3dx9.h>
#include <dxerr9.h>


#endif // NEVERENGINE_SCENE_PACK_STDAFX_HEADER




From dave at boost-consulting.com  Tue May 13 21:21:00 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 13 May 2003 15:21:00 -0400
Subject: [C++-sig] Re: boost_1_30_00
References: <FOEEIHHKFDJPFLJCHLAKMEFOCAAA.jochen@neverEngine.com>
Message-ID: <u7k8ubqlf.fsf@boost-consulting.com>

"jochen" <jochen at neverEngine.com> writes:

> This is the complete stdafx.h header file.
> It compiles well and can perfectly be used with boost_1_29_00,
> but when compiling with 1_30_00 I get the internal compiler error #C1001
> within every .cpp file.

The best I can do for you is to say:

    #1: Talk to your compiler vendor about this.  Internal compiler
     errors are their bugs, not ours.

    #2: I'm not sure what "stdafx.h" means, but if it has something
     to do with precompiled headers, you might try turning them off.

Sorry,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From greglandrum at mindspring.com  Tue May 13 22:40:08 2003
From: greglandrum at mindspring.com (greg Landrum)
Date: Tue, 13 May 2003 13:40:08 -0700
Subject: [C++-sig] boost_1_30_00
In-Reply-To: <FOEEIHHKFDJPFLJCHLAKMEFOCAAA.jochen@neverEngine.com>
Message-ID: <5.1.0.14.2.20030513133654.06923d98@mail.mindspring.com>

At 07:39 AM 5/13/2003, jochen wrote:

>This is the complete stdafx.h header file.
>It compiles well and can perfectly be used with boost_1_29_00,
>but when compiling with 1_30_00 I get the internal compiler error #C1001
>within every .cpp file.

I'll add another voice to the "disable precompiled headers" choir.

The MS compiler just can't handle BPL with precompiled headers switched 
on.  If you are lucky, this will make the problem go away (make sure to do 
Project->Clean before rebuilding).  If it doesn't clear things up, I have 
sometimes made these go away by reordering statements in my input file, but 
this isn't any kind of real solution. :-S

-greg




From milind_patil at hotmail.com  Wed May 14 03:52:22 2003
From: milind_patil at hotmail.com (Milind Patil)
Date: Tue, 13 May 2003 18:52:22 -0700
Subject: [C++-sig] Re: long long unsigned issue...
References: <b8uvp7$kp1$1@main.gmane.org> <uk7d8n8k7.fsf@boost-consulting.com> <b91g6e$me8$1@main.gmane.org> <u65oriktt.fsf@boost-consulting.com> <b91qci$oc6$1@main.gmane.org> <u1xzfiizj.fsf@boost-consulting.com> <b9292b$qru$1@main.gmane.org> <u65orxage.fsf@boost-consulting.com> <b96to4$d5$1@main.gmane.org> <uof2g6fhy.fsf@boost-consulting.com> <b9747j$vqv$1@main.gmane.org> <ufzns6czx.fsf@boost-consulting.com> <b97eg3$sod$1@main.gmane.org> <uvfwo2idm.fsf@boost-consulting.com>
Message-ID: <b9s7dn$b0$1@main.gmane.org>

"David Abrahams" <dave at boost-consulting.com> wrote in message
news:uvfwo2idm.fsf at boost-consulting.com...
> "Milind Patil" <milind_patil at hotmail.com> writes:
>
> >> This is very strange; do you see any reason that there should be a
> >> to_python conversion involved here?
> >
> > No, I cannot even guess why to_python conversion is needed.
>
> Actually, this problem turns out to be difficult to solve. It's going
> to take me a few days to get to it at least.  Sorry about that.
>
> -Dave

Thanks Dave, for taking the time to look into this. Is there some intermediate work-around
that I can try?

Thanks again,
Milind






From paul.rudin at ntlworld.com  Wed May 14 07:36:08 2003
From: paul.rudin at ntlworld.com (Paul Rudin)
Date: 14 May 2003 06:36:08 +0100
Subject: [C++-sig] pyste: current cvs/1_30_00 difference in treatment of overloaded members
In-Reply-To: <b9s7dn$b0$1@main.gmane.org>
Message-ID: <m37k8uf5tj.fsf_-_@ntlworld.com>


Hi,

I've noticed a difference between the c++ generated by the current cvs and the 1_30_00 released version.
Here's an illustration:

Say foo.h is:

-------------------------
class foo {
 public:
  virtual void bar (int * x);
  virtual void bar (char * x);
};
-------------------------
and foo.pyste is:

-----------------
foo = AllFromHeader("./foo.h")
-------------------

Then cvs pyste gives (ommiting includes and such):

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

struct foo_Wrapper: foo
{
    foo_Wrapper(PyObject* self_, const foo & p0):
        foo(p0), self(self_) {}

    foo_Wrapper(PyObject* self_):
        foo(), self(self_) {}

    void bar(int * p0) {
        call_method< void >(self, "bar", p0);
    }

    void default_bar(int * p0) {
        foo::bar(p0);
    }

    PyObject* self;
};

BOOST_PYTHON_MODULE(foo2)
{
    class_< foo, foo_Wrapper >("foo", init<  >())
        .def(init< const foo & >())
        .def("bar", &foo::bar, &foo_Wrapper::default_bar)
    ;

}

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

whereas current cvs gives:

----------------------------
struct foo_Wrapper: foo
{
    foo_Wrapper(PyObject* self_, const foo & p0):
        foo(p0), self(self_) {}

    foo_Wrapper(PyObject* self_):
        foo(), self(self_) {}

    void bar(int * p0) {
        call_method< void >(self, "bar", p0);
    }

    void default_bar(int * p0) {
        foo::bar(p0);
    }

    void bar(char * p0) {
        call_method< void >(self, "bar", p0);
    }

    void default_bar(char * p0) {
        foo::bar(p0);
    }

    PyObject* self;
};


BOOST_PYTHON_MODULE(foo1)
{
    class_< foo, foo_Wrapper >("foo", init<  >())
        .def(init< const foo & >())
        .def("bar", (void (foo::*)(int *) )&foo::bar, (void (foo_Wrapper::*)(int *))foo_Wrapper::default_bar)
        .def("bar", (void (foo::*)(char *) )&foo::bar, (void (foo_Wrapper::*)(char *))foo_Wrapper::default_bar)
    ;

}
 
------------------------------------------------------------



From paul.rudin at ntlworld.com  Wed May 14 07:44:58 2003
From: paul.rudin at ntlworld.com (Paul Rudin)
Date: 14 May 2003 06:44:58 +0100
Subject: [C++-sig] pyste: current cvs/1_30_00 difference in treatment of overloaded members
In-Reply-To: <m37k8uf5tj.fsf_-_@ntlworld.com>
References: <m37k8uf5tj.fsf_-_@ntlworld.com>
Message-ID: <m33cjif5et.fsf@ntlworld.com>

Paul Rudin <paul.rudin at ntlworld.com> writes:

> 
> whereas current cvs gives:
>

Whoops, sorry - the second version is the Version 1_30_0  case.





From david at uti.is  Wed May 14 13:30:05 2003
From: david at uti.is (David Helgason)
Date: Wed, 14 May 2003 13:30:05 +0200
Subject: [C++-sig] Sporadic access faults in boost::python::converter::registry::query()
Message-ID: <68FD589C-85FF-11D7-91C4-000A9566DA8A@uti.is>

I hope I can make this understandable.

I am using CodeWarrior 8.3 on OS X 10.2.6, with a Boost::Python CVS  
checkout from february.

I have exported a class (Collider) to python. I use a pattern  
previously suggested on this list I believe for registering the  
converter (and a hack to solve a CodeWarrior bug with an identity  
function, also suggested here) in a thread called "Exporting references  
into python", 2nd and 3rd of March this year.

Now, when I try to convert types with no registered converter, I  
rightly get an error. But when I try to convert my registered class  
Collider, it sometimes works and sometimes gives an access fault. The  
last part of the stack trace is attached below.

Now, I have tried to debug this by looking at the set<entry> lookup  
which goes on here,

       registry_t::iterator p = entries().find(entry(type));

but the CW debugger consistently crashes when I try. Intercepting the  
call on the way in (at levels 3-18 in the stacktrace), I don't see any  
difference with the data coming in: I certainly have no NULL pointer  
coming in.

I suspect foul play by the compiler, and wonder if this is a known  
problem and/or whether I should try to upgade to a newer version of  
boost::python.


I will of course submit code samples if anyone is interested, or follow  
any other instructions for that matter.


Regards,
David Helgason


***********

Date/Time:  2003-05-13 15:39:49 +0200
OS Version: 10.2.6 (Build 6L60)
Host:       bao.local.

Command:    Crimson Editor
PID:        28721

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000005

Thread 0 Crashed:
  #0   0x003d4e2c in  
_ZNSt6__treeIN5boost6python9converter12registrationENSt4lessIS3_EESaIS3_ 
EE4findIS3_EENS_18__generic_iteratorILb0EEERKT2_
  #1   0x00154fc0 in  
boost::python::converter::registry::query(boost::python::type_info)
  #2   0x0009e0f0 in  
_ZN5boost6python7objects17make_ptr_instanceI8ColliderNS1_14pointer_holde 
rIPS3_S3_EEE24get_derived_class_objectIS3_EEP11_typeobjectNS_3mpl6bool_c 
ILb1EEEPVKT1_
  #3   0x0009e07c in  
_ZN5boost6python7objects17make_ptr_instanceI8ColliderNS1_14pointer_holde 
rIPS3_S3_EEE21get_class_object_implIS3_EEP11_typeobjectPVKT1_
  #4   0x0009e034 in  
_ZN5boost6python7objects17make_ptr_instanceI8ColliderNS1_14pointer_holde 
rIPS3_S3_EEE16get_class_objectIS5_EEP11_typeobjectRKT1_
  #5   0x0009def4 in  
_ZN5boost6python7objects18make_instance_implI8ColliderNS1_14pointer_hold 
erIPS3_S3_EENS1_17make_ptr_instanceIS3_S6_EEE7executeIS5_EEP7_objectRT2_
  #6   0x0009debc in object*  
boost::python::detail::make_reference_holder::execute<Collider>(Collider 
*)
  #7   0x0031686c in  
_ZN5boost6python6detail14unwind_type_cvINS1_21make_reference_holderE8Col 
liderEENT_11result_typeEPT0_NS1_6cv_tagILb0ELb0EEEPT_
  #8   0x00316844 in  
_ZN5boost6python6detail15unwind_ptr_typeINS1_21make_reference_holderE8Co 
lliderEENT_11result_typeEPT0_PT_
  #9   0x0009de94 in  
_ZN5boost6python6detail13unwind_helperILb1EE7executeINS1_21make_referenc 
e_holderEP8ColliderEENT0_11result_typeET1_PT0_
  #10  0x00316808 in  
_ZN5boost6python6detail11unwind_typeINS1_21make_reference_holderEP8Colli 
derEENT_11result_typeERKT0_PT_
  #11  0x003167d0 in boost::python::to_python_indirect<Collider*&,  
boost::python::detail::make_reference_holder>::operator()(Collider*&)  
const
  #12  0x0031677c in  
boost::python::converter::detail::reference_arg_to_python<Collider*>::ge 
t_object(Collider*&)
  #13  0x0031673c in  
boost::python::converter::detail::reference_arg_to_python<Collider*>::re 
ference_arg_to_python[in-charge](Collider*&)
  #14  0x00316704 in  
boost::python::converter::arg_to_python<boost::reference_wrapper<Collide 
r*> >::arg_to_python[in-charge](boost::reference_wrapper<Collider*>  
const&)
  #15  0x003165d4 in  
_ZN5boost6python4callINS0_3api6objectENS_17reference_wrapperIP8ColliderE 
EEENNS0_6detail10returnableIT_EE4typeEP7_objectRKT0_PNS_4typeIT_EE
  #16  0x0009c9b8 in  
_ZNK5boost6python3api16object_operatorsINS1_6objectEEclINS_17reference_w 
rapperIP8ColliderEEEENNS0_6detail9dependentIS3_T0_EE4typeERKT0_
  #17  0x0031353c in boost::python::api::object  
NotificationDataConvertT<Collider>(NotificationData&)
  #18  0x00080e54 in ConvertNotificationDataToPython(NotificationData&)
// ... 26 layers of my own code here





From nicodemus at globalite.com.br  Wed May 14 18:20:14 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Wed, 14 May 2003 13:20:14 -0300
Subject: [C++-sig] pyste: current cvs/1_30_00 difference in treatment
 of overloaded members
In-Reply-To: <m37k8uf5tj.fsf_-_@ntlworld.com>
References: <m37k8uf5tj.fsf_-_@ntlworld.com>
Message-ID: <3EC26CBE.3030003@globalite.com.br>

Paul Rudin wrote:

>Hi,
>
>I've noticed a difference between the c++ generated by the current cvs and the 1_30_00 released version.
>Here's an illustration:
>

Thanks for the report Rubin! I found the problem, but now a doubt came 
up about how to properly export protected (and even private) methods.

Suppose:

class A
{
public:
    const char* get_name() { return name(); }

protected:
    virtual const char* name() { return "foo"; }
};
 


Here's the wrapper generated by pyste now:


struct A_Wrapper: A
{
    A_Wrapper(PyObject* self_, const A & p0):
        A(p0), self(self_) {}

    A_Wrapper(PyObject* self_):
        A(), self(self_) {}

    const char * name() {
        return call_method< const char * >(self, "name");
    }

    PyObject* self;
};


BOOST_PYTHON_MODULE(test)
{
    class_< A, A_Wrapper >("A", init<  >())
        .def(init< const A & >())
        .def("get_name", &A::get_name)
    ;

}


Now from Python:

 >>> from test import *
 >>> a = A()
 >>> a.get_name()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'A' object has no attribute 'name'
 >>>

Sure: get_name is called in C++, which calls the *overriden* "name" in 
A_Wrapper, but the Python object doesn't have this function. Even 
thought the protected method "name" has a default implementation, this 
is not passed to Boost.Python at all. It couldn't be declared like any 
public virtual function in the class_ definition (hence passsing also 
its default implementation), because A::name is protected and can't be 
accessed by outside code. So how to export default implementations of 
protected virtual methods?





From paul.rudin at ntlworld.com  Thu May 15 00:08:13 2003
From: paul.rudin at ntlworld.com (Paul Rudin)
Date: 14 May 2003 23:08:13 +0100
Subject: [C++-sig] confused...
Message-ID: <m3el31dvw2.fsf@ntlworld.com>


Should this work? If not is there an obvious way to make it work? TIA.


Say subclassTest.cpp contains:

---------------------
#include <boost/python.hpp>
using namespace boost::python;

class Base
{
public:
  virtual int foo(int x) { return x+1;}
};

class Bar 
{
public:
  Base* thing;
  void setThing(Base* bptr) { thing=bptr;};
  int callThing(int x) {return thing->foo(x);};
};

class BaseWrap : public Base
{
public:
  BaseWrap(PyObject* self_):self(self_){}

  int foo(int x)
  {
    return call_method<bool>(self,"foo",x);
  }
  PyObject* self;
};


BOOST_PYTHON_MODULE(subclassTest)
{


  class_<Base, BaseWrap, boost::noncopyable >("Base")
    .def("foo", &BaseWrap::foo)
    ;

  class_<Bar>("Bar")
    .def("setThing", &Bar::setThing)
    .def("callThing", &Bar::callThing)
    ;

};

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

Then in python:

>>> from subclassTest import *
>>> class sub(Base):
... 	 def foo(z):
... 	     z=z+7		
... 
>>> s=sub()
>>> bar=Bar()
>>> bar.setThing(s)
>>> bar.callThing(2)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: foo() takes exactly 1 argument (2 given)
>>> 



From nicodemus at globalite.com.br  Thu May 15 00:35:52 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Wed, 14 May 2003 19:35:52 -0300
Subject: [C++-sig] confused...
In-Reply-To: <m3el31dvw2.fsf@ntlworld.com>
References: <m3el31dvw2.fsf@ntlworld.com>
Message-ID: <3EC2C4C8.2020808@globalite.com.br>


Paul Rudin wrote:

>Should this work? If not is there an obvious way to make it work? TIA.
>
>
>Say subclassTest.cpp contains:
>
>---------------------
>#include <boost/python.hpp>
>using namespace boost::python;
>
>class Base
>{
>public:
>  virtual int foo(int x) { return x+1;}
>};
>
>class Bar 
>{
>public:
>  Base* thing;
>  void setThing(Base* bptr) { thing=bptr;};
>  int callThing(int x) {return thing->foo(x);};
>};
>
>class BaseWrap : public Base
>{
>public:
>  BaseWrap(PyObject* self_):self(self_){}
>
>  int foo(int x)
>  {
>    return call_method<bool>(self,"foo",x);
>  }
>

Here you mean:
    return call_method<int>(self, "foo", x);
                       ^^^

Right?

>  PyObject* self;
>};
>
>
>BOOST_PYTHON_MODULE(subclassTest)
>{
>
>
>  class_<Base, BaseWrap, boost::noncopyable >("Base")
>    .def("foo", &BaseWrap::foo)
>    ;
>
>  class_<Bar>("Bar")
>    .def("setThing", &Bar::setThing)
>    .def("callThing", &Bar::callThing)
>    ;
>
>};
>
>---------------------
>
>Then in python:
>
>  
>
>>>>from subclassTest import *
>>>>class sub(Base):
>>>>        
>>>>
>... 	 def foo(z):
>... 	     z=z+7		
>... 
>
Change sub to:

 >>> class sub(Base):
...     def foo(self, z):
...         return z+7
...

Note the "self" argument in the method. In Python, the "self" ("this" in 
C++) is explicity.

>>>>s=sub()
>>>>bar=Bar()
>>>>bar.setThing(s)
>>>>bar.callThing(2)
>>>>        
>>>>
>Traceback (most recent call last):
>  File "<stdin>", line 1, in ?
>TypeError: foo() takes exactly 1 argument (2 given)
>  
>

Hope that helps,
Nicodemus.




From paul.rudin at ntlworld.com  Thu May 15 07:52:33 2003
From: paul.rudin at ntlworld.com (Paul Rudin)
Date: 15 May 2003 06:52:33 +0100
Subject: [C++-sig] confused...
In-Reply-To: <3EC2C4C8.2020808@globalite.com.br>
References: <m3el31dvw2.fsf@ntlworld.com> <3EC2C4C8.2020808@globalite.com.br>
Message-ID: <m3addoeoym.fsf@ntlworld.com>

Nicodemus <nicodemus at globalite.com.br> writes:


> >>>>class sub(Base):
> >>>>
> >... 	 def foo(z):
> >... 	     z=z+7		
> > ...
> Change sub to:
> 
>  >>> class sub(Base):
> ...     def foo(self, z):
> ...         return z+7
> ...
> 

Arrgh, yes. Silly error. Sorry.




From dave at boost-consulting.com  Thu May 15 13:34:40 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 15 May 2003 07:34:40 -0400
Subject: [C++-sig] Re: boost_1_30_00
References: <FOEEIHHKFDJPFLJCHLAKMEFOCAAA.jochen@neverEngine.com> <5.1.0.14.2.20030513133654.06923d98@mail.mindspring.com>
Message-ID: <uptmkxx2n.fsf@boost-consulting.com>

greg Landrum <greglandrum at mindspring.com> writes:

> At 07:39 AM 5/13/2003, jochen wrote:
>
>>This is the complete stdafx.h header file.
>>It compiles well and can perfectly be used with boost_1_29_00,
>>but when compiling with 1_30_00 I get the internal compiler error #C1001
>>within every .cpp file.
>
> I'll add another voice to the "disable precompiled headers" choir.
>
> The MS compiler just can't handle BPL with precompiled headers
> switched on.  If you are lucky, this will make the problem go away
> (make sure to do Project->Clean before rebuilding).  If it doesn't
> clear things up, I have sometimes made these go away by reordering
> statements in my input file, but this isn't any kind of real
> solution. :-S

Upgrading to vc7.1 should fix this, though.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Thu May 15 13:38:18 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 15 May 2003 07:38:18 -0400
Subject: [C++-sig] Re: pyste: current cvs/1_30_00 difference in treatment of
 overloaded members
References: <m37k8uf5tj.fsf_-_@ntlworld.com> <3EC26CBE.3030003@globalite.com.br>
Message-ID: <uk7csxwwl.fsf@boost-consulting.com>

Nicodemus <nicodemus at globalite.com.br> writes:

> Paul Rudin wrote:
>
>>Hi,
>>
>>I've noticed a difference between the c++ generated by the current cvs and the 1_30_00 released version.
>>Here's an illustration:
>>
>
> Thanks for the report Rubin! I found the problem, but now a doubt came
> up about how to properly export protected (and even private) methods.
>
> Suppose:
>
> class A
> {
> public:
>     const char* get_name() { return name(); }
>
> protected:
>     virtual const char* name() { return "foo"; }
> };
>  Here's the wrapper generated by pyste now:
>
>
> struct A_Wrapper: A
> {
>     A_Wrapper(PyObject* self_, const A & p0):
>         A(p0), self(self_) {}
>
>     A_Wrapper(PyObject* self_):
>         A(), self(self_) {}
>
>     const char * name() {
>         return call_method< const char * >(self, "name");
>     }
>
>     PyObject* self;
> };
>
>
> BOOST_PYTHON_MODULE(test)
> {
>     class_< A, A_Wrapper >("A", init<  >())
>         .def(init< const A & >())
>         .def("get_name", &A::get_name)
>     ;
>
> }
>
>
> Now from Python:
>
>  >>> from test import *
>  >>> a = A()
>  >>> a.get_name()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> AttributeError: 'A' object has no attribute 'name'
>  >>>
>
> Sure: get_name is called in C++, which calls the *overriden* "name" in
> A_Wrapper, but the Python object doesn't have this function. Even
> thought the protected method "name" has a default implementation, this
> is not passed to Boost.Python at all. It couldn't be declared like any
> public virtual function in the class_ definition (hence passsing also
> its default implementation), because A::name is protected and can't be
> accessed by outside code. 

So? It can be accessed from A_Wrapper, where you need to declare the
default implementation.

> So how to export default implementations of
> protected virtual methods?

I don't see the problem.

Private virtual functions are a bigger problem; the best you can do
is to break the C++ rules by replicating the base class declaration
with the private function declared protected.

HTH,
Dave
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From nicodemus at globalite.com.br  Thu May 15 20:59:42 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Thu, 15 May 2003 10:59:42 -0800
Subject: [C++-sig] Re: pyste: current cvs/1_30_00 difference in treatment
 of overloaded members
In-Reply-To: <uk7csxwwl.fsf@boost-consulting.com>
References: <m37k8uf5tj.fsf_-_@ntlworld.com> <3EC26CBE.3030003@globalite.com.br> <uk7csxwwl.fsf@boost-consulting.com>
Message-ID: <3EC3E39E.7000509@globalite.com.br>


David Abrahams wrote:

>So? It can be accessed from A_Wrapper, where you need to declare the
>default implementation.
>  
>

Yes, but you can't tell Boost.Python about the default implementation, 
so just declaring a function "default_name" in the wrapper will have no 
effect:

    const char * default_name() {
        return A::name();
    }

... unless we also expose it in the class_ declaration:

    .def("name", &A::name, &A_Wrapper::default_name)

Which, besides making the function public, can't be done because A::name 
is protected. Or am I missing something?

>Private virtual functions are a bigger problem; the best you can do
>is to break the C++ rules by replicating the base class declaration
>with the private function declared protected.
>  
>

I believe the problem persists: you still must tell Boost.Python about 
the default implementation.

>HTH,
>Dave
>

Thanks Dave,
Nicodemus.




From Paul_Kunz at SLAC.Stanford.EDU  Thu May 15 20:40:14 2003
From: Paul_Kunz at SLAC.Stanford.EDU (Paul F. Kunz)
Date: Thu, 15 May 2003 11:40:14 -0700
Subject: [C++-sig] gcc 3.3
References: <5.1.0.14.2.20021211170218.03babb20@mail.earthlink.net>
Message-ID: <200305151840.h4FIeEW04774@libra3.slac.stanford.edu>

   I've just installed gcc 3.3 and I get the following error 

g++ -DQT_THREAD_SUPPORT -I. -I../../hippodraw/python -I.. -I../../hippodraw -I../../hippodraw/qt -I../qt -I/usr/local/boost -ftemplate-depth-60 -I/usr/include/python2.2 -I/usr/lib/qt-3.1/include -g -O2 -Wall -c ../../hippodraw/python/QtCut.cxx -MT QtCut.lo -MD -MP -MF .deps/QtCut.TPlo  -fPIC -DPIC
In file included from /usr/local/boost/boost/config.hpp:35,
                 from /usr/local/boost/boost/type_traits/config.hpp:14,
                 from /usr/local/boost/boost/type_traits/is_same.hpp:14,
                 from /usr/local/boost/boost/type_traits/same_traits.hpp:14,
                 from /usr/local/boost/boost/python/cast.hpp:10,
                 from /usr/local/boost/boost/python/handle.hpp:10,
                 from /usr/local/boost/boost/python/args_fwd.hpp:9,
                 from /usr/local/boost/boost/python/args.hpp:9,
                 from /usr/local/boost/boost/python.hpp:12,
                 from ../../hippodraw/python/QtCut.cxx:23:
/usr/local/boost/boost/config/compiler/gcc.hpp:66:7: warning: #warning "Unknown compiler version - please run the configure tests and report the results"
/usr/local/boost/boost/python/converter/as_to_python_function.hpp:31: sorry, unimplemented: `
   method_call_expr' not supported by dump_expr

I understanding the warning, but I get the error 4 times.  Any ideas?


P.S.

  To run the "configure tests" is it the
$BOOST_ROOT/tools/regression/run_tests.sh script?   I rebuilt
boost_1_30_0 with gcc 3.3 and ran it.   The results are at

ftp://ftp.slac.stanford.edu/users/pfkeb/boost/




From dave at boost-consulting.com  Thu May 15 20:40:49 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 15 May 2003 14:40:49 -0400
Subject: [C++-sig] Re: pyste: current cvs/1_30_00 difference in treatment of
 overloaded members
References: <m37k8uf5tj.fsf_-_@ntlworld.com> <3EC26CBE.3030003@globalite.com.br>
 <uk7csxwwl.fsf@boost-consulting.com> <3EC3E39E.7000509@globalite.com.br>
Message-ID: <un0hovyry.fsf@boost-consulting.com>

Nicodemus <nicodemus at globalite.com.br> writes:

> David Abrahams wrote:
>
>>So? It can be accessed from A_Wrapper, where you need to declare the
>>default implementation.
>>  
>
> Yes, but you can't tell Boost.Python about the default implementation,
> so just declaring a function "default_name" in the wrapper will have
> no effect:
>
>     const char * default_name() {
>         return A::name();
>     }
>
> ... unless we also expose it in the class_ declaration:
>
>     .def("name", &A::name, &A_Wrapper::default_name)

Of course you do have to do that.

> Which, besides making the function public, can't be done because
> A::name is protected. Or am I missing something?

You're certainly missing that A_Wrapper is derived from A and so can
access A's protected members, including name().

Anyway, let me get this straight.  In what context don't you want to
make "the function" (which function?) public?

Are you trying to prevent:

    >>> x = A()
    >>> x.name()

??

If so, keep in mind that Python doesn't have any notion of
"protected" interfaces.  Something's either accessible or it's not --
I suppose you can use the "private" method name hack to keep things
somewhat hidden:

    >>> class B(A):
    ...     def f(self):
    ...          self._A__name()
                

But that doesn't work too well for functions that need to be
overridden:

    >>> class B(A):
    ...     def _A__name(self):  # override "private" method
    ...          return 2
                

But anyway, back to your original problem.  I think you are saying you
want instances of A created from Python not to have a Python "name"
method, yet that Python classes derived from A can override A::name,
and that from C++, python instances of A implement "name" using the
C++ A::name by default.  Right?

I think trying to get Python A instances not to have a name method is
sort of unpythonic, but be that as it may...

To get overridability, you need to implement A_Wrapper::name() so that
it dispatches into Python.  If you don't want to expose a "name"
attribute, you'd better implement A_Wrapper::name() something like
this:

        char const* name()
        {
            if (PyObject_HasAttrString(this->self, "name"))
                return boost::python::call_method<char const*>(self, "name");
            else
                return A::name();
        }

>>Private virtual functions are a bigger problem; the best you can do
>>is to break the C++ rules by replicating the base class declaration
>>with the private function declared protected.
>>  
>
> I believe the problem persists: you still must tell Boost.Python about
> the default implementation.

Still not sure what you perceive the problem to be...

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From nicodemus at globalite.com.br  Fri May 16 05:21:38 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Thu, 15 May 2003 19:21:38 -0800
Subject: [C++-sig] Re: pyste: current cvs/1_30_00 difference in treatment
 of overloaded members
In-Reply-To: <un0hovyry.fsf@boost-consulting.com>
References: <m37k8uf5tj.fsf_-_@ntlworld.com> <3EC26CBE.3030003@globalite.com.br> <uk7csxwwl.fsf@boost-consulting.com> <3EC3E39E.7000509@globalite.com.br> <un0hovyry.fsf@boost-consulting.com>
Message-ID: <3EC45942.9040405@globalite.com.br>

David Abrahams wrote:

>Nicodemus <nicodemus at globalite.com.br> writes:
>  
>
>>... unless we also expose it in the class_ declaration:
>>
>>    .def("name", &A::name, &A_Wrapper::default_name)
>>    
>>
>
>Of course you do have to do that.
>
>  
>
>>Which, besides making the function public, can't be done because
>>A::name is protected. Or am I missing something?
>>    
>>
>
>You're certainly missing that A_Wrapper is derived from A and so can
>access A's protected members, including name().
>

That's what I meant by "making the function public" (sorry, I should 
have said "exported"):

    class_< A, A_Wrapper >("A", init<  >())
        .def(init< const A & >())
        .def("get_name", &A::get_name)
        .def("name", &A::name, &A_Wrapper::default_name)
    ;

This gives an error (obviously):

test.cpp(43): error #308: function "A::name" is inaccessible
          .def("name", &A::name, &A_Wrapper::default_name)
                           ^

>Anyway, let me get this straight.  In what context don't you want to
>make "the function" (which function?) public?
>
>Are you trying to prevent:
>
>    >>> x = A()
>    >>> x.name()
>
>??
>  
>

Yes. I think it would be nice to mimic the C++ classes on the Python 
side as much as possible, but I know that Python has different 
semantics. My first thoughts were that one couldn't access the protected 
function from outside the class, but could override it inside a derived 
class. But on second thought, that is not a very good option either, 
because then you can't call the parent's implementation from the derived 
class that way:

     class B(A):
         def name(self):
             return A.name(self) + 'B'  # wouldn't work, unless "name" 
were also exported

>If so, keep in mind that Python doesn't have any notion of
>"protected" interfaces.  
>

I'm aware of that.

>But anyway, back to your original problem.  I think you are saying you
>want instances of A created from Python not to have a Python "name"
>method, yet that Python classes derived from A can override A::name,
>and that from C++, python instances of A implement "name" using the
>C++ A::name by default.  Right?
>

Yes.

>I think trying to get Python A instances not to have a name method is
>sort of unpythonic, but be that as it may...
>  
>
>To get overridability, you need to implement A_Wrapper::name() so that
>it dispatches into Python.  If you don't want to expose a "name"
>attribute, you'd better implement A_Wrapper::name() something like
>this:
>
>        char const* name()
>        {
>            if (PyObject_HasAttrString(this->self, "name"))
>                return boost::python::call_method<char const*>(self, "name");
>            else
>                return A::name();
>        }
>  
>

That's what I thought...

>>>Private virtual functions are a bigger problem; the best you can do
>>>is to break the C++ rules by replicating the base class declaration
>>>with the private function declared protected.
>>> 
>>>      
>>>
>>I believe the problem persists: you still must tell Boost.Python about
>>the default implementation.
>>    
>>
>
>Still not sure what you perceive the problem to be...
>  
>

I wanted to know how to expose the default implementation of protected 
virtual methods, and also how should Pyste handle them. I saw two 
options: export them normaly, just like a public method; or override the 
function and inside it check if the python object has reimplemented it, 
otherwise call the default implementation. I wanted to discuss here in 
the list what would be the best method, that's all.





From dave at boost-consulting.com  Fri May 16 00:53:50 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 15 May 2003 18:53:50 -0400
Subject: [C++-sig] Re: gcc 3.3
References: <5.1.0.14.2.20021211170218.03babb20@mail.earthlink.net> <200305151840.h4FIeEW04774@libra3.slac.stanford.edu>
Message-ID: <u65obvn29.fsf@boost-consulting.com>

"Paul F. Kunz" <Paul_Kunz at SLAC.Stanford.EDU> writes:

>    I've just installed gcc 3.3 and I get the following error 
>
> /usr/local/boost/boost/python/converter/as_to_python_function.hpp:31: sorry, unimplemented: `
>    method_call_expr' not supported by dump_expr
>
> I understanding the warning, but I get the error 4 times.  Any ideas?

That's a compiler bug, plain and simple.  You should report it to the
gcc people: http://gcc.gnu.org/bugs.html.


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Fri May 16 01:02:49 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 15 May 2003 19:02:49 -0400
Subject: [C++-sig] Re: pyste: current cvs/1_30_00 difference in treatment of
 overloaded members
References: <m37k8uf5tj.fsf_-_@ntlworld.com> <3EC26CBE.3030003@globalite.com.br>
 <uk7csxwwl.fsf@boost-consulting.com> <3EC3E39E.7000509@globalite.com.br>
 <un0hovyry.fsf@boost-consulting.com> <3EC45942.9040405@globalite.com.br>
Message-ID: <uznlnu82u.fsf@boost-consulting.com>

Nicodemus <nicodemus at globalite.com.br> writes:

> David Abrahams wrote:
>
>>Nicodemus <nicodemus at globalite.com.br> writes:
>>  
>>>... unless we also expose it in the class_ declaration:
>>>
>>>    .def("name", &A::name, &A_Wrapper::default_name)
>>>    
>>
>>Of course you do have to do that.
>>
>>  
>>>Which, besides making the function public, can't be done because
>>>A::name is protected. Or am I missing something?
>>>    
>>
>>You're certainly missing that A_Wrapper is derived from A and so can
>>access A's protected members, including name().
>>
>
> That's what I meant by "making the function public" (sorry, I should
> have said "exported"):
>
>     class_< A, A_Wrapper >("A", init<  >())
>         .def(init< const A & >())
>         .def("get_name", &A::get_name)
>         .def("name", &A::name, &A_Wrapper::default_name)
>     ;
>
> This gives an error (obviously):
>
> test.cpp(43): error #308: function "A::name" is inaccessible
>           .def("name", &A::name, &A_Wrapper::default_name)


Oh, sorry.  You can of course stick a function in A_Wrapper which gets
you &A::name:

        static char const* (A::*a_name())() { return &A::name; }

>>Anyway, let me get this straight.  In what context don't you want to
>>make "the function" (which function?) public?
>>
>>Are you trying to prevent:
>>
>>    >>> x = A()
>>    >>> x.name()
>>
>>??
>>  
>
> Yes. I think it would be nice to mimic the C++ classes on the Python
> side as much as possible, but I know that Python has different
> semantics. My first thoughts were that one couldn't access the
> protected function from outside the class, but could override it
> inside a derived class. But on second thought, that is not a very good
> option either, because then you can't call the parent's implementation
> from the derived class that way:
>
>      class B(A):
>          def name(self):
>              return A.name(self) + 'B'  # wouldn't work, unless "name"
>              were also exported

Right.  Of course, designs which make you do that are evil anyway,
but we still have to wrap them ;-).

>>But anyway, back to your original problem.  I think you are saying you
>>want instances of A created from Python not to have a Python "name"
>>method, yet that Python classes derived from A can override A::name,
>>and that from C++, python instances of A implement "name" using the
>>C++ A::name by default.  Right?
>>
>
> Yes.
>
>>I think trying to get Python A instances not to have a name method is
>>sort of unpythonic, but be that as it may...
>>  To get overridability, you need to implement A_Wrapper::name() so
>> that
>>it dispatches into Python.  If you don't want to expose a "name"
>>attribute, you'd better implement A_Wrapper::name() something like
>>this:
>>
>>        char const* name()
>>        {
>>            if (PyObject_HasAttrString(this->self, "name"))
>>                return boost::python::call_method<char const*>(self, "name");
>>            else
>>                return A::name();
>>        }
>>  
>
> That's what I thought...

But it seems like that's not the solution you're looking for.
Unfortunately Python doesn't let you say "who's asking?" before giving
out an attribute value, so you can't hide A.name from everything
that's not a derived class of A.

> I wanted to know how to expose the default implementation of
> protected virtual methods, and also how should Pyste handle them. I
> saw two options: export them normaly, just like a public method; or
> override the function and inside it check if the python object has
> reimplemented it, otherwise call the default implementation. I
> wanted to discuss here in the list what would be the best method,
> that's all.

OK, I understand now.  I hope I helped a little at least.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From Paul_Kunz at SLAC.Stanford.EDU  Fri May 16 02:10:40 2003
From: Paul_Kunz at SLAC.Stanford.EDU (Paul F. Kunz)
Date: Thu, 15 May 2003 17:10:40 -0700
Subject: [C++-sig] Re: gcc 3.3
In-Reply-To: <u65obvn29.fsf@boost-consulting.com>
References: <5.1.0.14.2.20021211170218.03babb20@mail.earthlink.net>
 <200305151840.h4FIeEW04774@libra3.slac.stanford.edu>
 <u65obvn29.fsf@boost-consulting.com>
Message-ID: <200305160010.h4G0Aew13554@libra3.slac.stanford.edu>

>>>>> On Thu, 15 May 2003 18:53:50 -0400, David Abrahams <dave at boost-consulting.com> said:

> "Paul F. Kunz" <Paul_Kunz at SLAC.Stanford.EDU> writes:
>> I've just installed gcc 3.3 and I get the following error
>> 
>> /usr/local/boost/boost/python/converter/as_to_python_function.hpp:31:
>> sorry, unimplemented: ` method_call_expr' not supported by
>> dump_expr
>> 
>> I understanding the warning, but I get the error 4 times.  Any
>> ideas?

> That's a compiler bug, plain and simple.  You should report it to
> the gcc people: http://gcc.gnu.org/bugs.html.

   I commented out in boost/python/converter/as_to_python_function.hh


        BOOST_STATIC_ASSERT(
            sizeof(
                convert_function_must_take_value_or_const_reference(&ToPython::convert, 1L))
            == sizeof(int));

and thing compiled and ran ok.   



From Paul_Kunz at SLAC.Stanford.EDU  Fri May 16 03:07:03 2003
From: Paul_Kunz at SLAC.Stanford.EDU (Paul F. Kunz)
Date: Thu, 15 May 2003 18:07:03 -0700
Subject: [C++-sig] Re: gcc 3.3
In-Reply-To: <u65obvn29.fsf@boost-consulting.com>
References: <5.1.0.14.2.20021211170218.03babb20@mail.earthlink.net>
 <200305151840.h4FIeEW04774@libra3.slac.stanford.edu>
 <u65obvn29.fsf@boost-consulting.com>
Message-ID: <200305160107.h4G173413656@libra3.slac.stanford.edu>

>>>>> On Thu, 15 May 2003 18:53:50 -0400, David Abrahams <dave at boost-consulting.com> said:

> "Paul F. Kunz" <Paul_Kunz at SLAC.Stanford.EDU> writes:
>> I've just installed gcc 3.3 and I get the following error
>> 
>> /usr/local/boost/boost/python/converter/as_to_python_function.hpp:31:
>> sorry, unimplemented: ` method_call_expr' not supported by
>> dump_expr
>> 
>> I understanding the warning, but I get the error 4 times.  Any
>> ideas?

> That's a compiler bug, plain and simple.  You should report it to
> the gcc people: http://gcc.gnu.org/bugs.html.

   If I knew what the bug was, I would.   Did this bug show up in one
of the failed boost regression tests that I posted?   If so, which
one.   Sending that test to the gcc people would be a lot more useful
thatn how I can described the bug.



From cyril.bonnard at cirad.fr  Fri May 16 15:34:40 2003
From: cyril.bonnard at cirad.fr (Cyril Bonnard)
Date: Fri, 16 May 2003 15:34:40 +0200
Subject: [C++-sig] return_internal_reference<>()
Message-ID: <3EC4E8F0.40608@cirad.fr>

hi, iam newbie in using boost.python, and i don't understand why the 
following code doesn't work:


hello.h:
....
         int& geti()     { return i; }
...


hello.cpp:
....
       .def("geti", &World::geti, return_internal_reference<>())
...


i noticed that this works if there is a class (string, inner....) 
instead of int or uchar....
so waht i done wrong and what shoud be be the right policy to return 
int& or unsigned char&....

regards. cyril




From greglandrum at mindspring.com  Fri May 16 16:46:42 2003
From: greglandrum at mindspring.com (greg Landrum)
Date: Fri, 16 May 2003 07:46:42 -0700
Subject: [C++-sig] Re: boost_1_30_00
In-Reply-To: <uptmkxx2n.fsf@boost-consulting.com>
References: <FOEEIHHKFDJPFLJCHLAKMEFOCAAA.jochen@neverEngine.com>
 <5.1.0.14.2.20030513133654.06923d98@mail.mindspring.com>
Message-ID: <5.1.0.14.2.20030516074553.028e3480@mail.mindspring.com>

At 04:34 AM 5/15/2003, David Abrahams wrote:
> >
> > The MS compiler just can't handle BPL with precompiled headers
> > switched on.  If you are lucky, this will make the problem go away
> > (make sure to do Project->Clean before rebuilding).  If it doesn't
> > clear things up, I have sometimes made these go away by reordering
> > statements in my input file, but this isn't any kind of real
> > solution. :-S
>
>Upgrading to vc7.1 should fix this, though.

This isn't an option when one has clients who are using vc6.

-greg




From rwgk at yahoo.com  Fri May 16 18:34:02 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 16 May 2003 09:34:02 -0700 (PDT)
Subject: [C++-sig] return_internal_reference<>()
In-Reply-To: <3EC4E8F0.40608@cirad.fr>
Message-ID: <20030516163402.66689.qmail@web20207.mail.yahoo.com>

--- Cyril Bonnard <cyril.bonnard at cirad.fr> wrote:
> hi, iam newbie in using boost.python, and i don't understand why the 
> following code doesn't work:
> 
> 
> hello.h:
> ....
>          int& geti()     { return i; }
> ...
> 
> 
> hello.cpp:
> ....
>        .def("geti", &World::geti, return_internal_reference<>())
> ...
> 
> 
> i noticed that this works if there is a class (string, inner....) 
> instead of int or uchar....
> so waht i done wrong and what shoud be be the right policy to return 
> int& or unsigned char&....

I think it doesn't work because integers and strings are immutable in Python.
If you need to modify the integer from Python you will need a setter, along the
lines of

  void seti(your_type& o, int new_i)
  {
    o.geti() = new_i;
  }

Then:

  .def("seti", seti)

Note that this adds the non-member C++ seti() function as a member function of
the Python type. One of the many cool features of Boost.Python.

I am not sure what the right return value policy is for your geti() function,
but it has to be one which returns a copy.

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From dave at boost-consulting.com  Fri May 16 18:42:58 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 16 May 2003 12:42:58 -0400
Subject: [C++-sig] Re: boost_1_30_00
References: <FOEEIHHKFDJPFLJCHLAKMEFOCAAA.jochen@neverEngine.com> <5.1.0.14.2.20030513133654.06923d98@mail.mindspring.com>
 <5.1.0.14.2.20030516074553.028e3480@mail.mindspring.com>
Message-ID: <u8yt6rgfh.fsf@boost-consulting.com>

greg Landrum <greglandrum at mindspring.com> writes:

G> At 04:34 AM 5/15/2003, David Abrahams wrote:
>> >
>> > The MS compiler just can't handle BPL with precompiled headers
>> > switched on.  If you are lucky, this will make the problem go away
>> > (make sure to do Project->Clean before rebuilding).  If it doesn't
>> > clear things up, I have sometimes made these go away by reordering
>> > statements in my input file, but this isn't any kind of real
>> > solution. :-S
>>
>>Upgrading to vc7.1 should fix this, though.
>
> This isn't an option when one has clients who are using vc6.

Even if you don't need to deliver them source code?  I bet you could
force vc7.1 to link against the vc6 libs, if pressed ;-)  Even if you
don't, I compile and run extensions built with vc7.1 using a vc6
Python all the time, so this might be an option for you.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Sat May 17 14:07:23 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 17 May 2003 08:07:23 -0400
Subject: [C++-sig] Re: Tutorial - Techniques
References: <3EB586B7.8090108@globalite.com.br> <b952p7$ka$1@main.gmane.org>
Message-ID: <u7k8pojyc.fsf@boost-consulting.com>

Dirk Gerrits <dirk at gerrits.homeip.net> writes:

> Nicodemus wrote:
>> I created three sections, "Creating Packages", "Extending Wrapped
>> Objects in Python" and "Reducing Compiling Time". Any comments are
>> welcome!
>
> Just two minor nits about "Extending Wrapped Objects in Python":
>
> * advantages is misspelled 'advantagens'
> * the term 'syntax sugar' is used, I thought it was 'syntactic sugar'?

I agree with Dirk; you did a wonderful job and I'm eager to get this
into CVS!

---
A few more nits:

the comment in the 2nd code box makes it too wide

"Compiling this files will generate the following Python extensions"
           ^^^^
          "these"

That module renaming/packagizing thing is only one way to add Pure
Python methods.  You might discuss other ways.  For example,
sounds/__init__.py can add them directly (though that causes
submodules to load early), or you can use the ihooks module to install
an import hook from sounds/__init__.py, which, when you load
sounds/foo.pyd, also loads sounds/_foo.py (or even foo.py!) and merges
definitions, even merging functions from same-named classes.  Why
ihooks isn't documented in the standard module docs, I'll never know
;-).  It's only mentioned here
http://www.python.org/doc/current/lib/built-in-funcs.html#l2h-64, but
you can always:

    >>> import ihooks
    >>> help(ihooks)

This solution might not be as simple to get started, but a single
prepackaged __init__ could handle this for people so that they only
need to write the pure python file.  OTOH, maybe that's more than you
want to get into.  If Ralf is doing this sort of thing a lot, perhaps
he'll want to implement that.

"But if we let it like this" should be "But if we leave it that way".

Did you actually test your MetaInjector thing?  I'm pretty sure you
need to derive the metaclass from the metaclass used for Boost.Python
objects, or you'll get a metaclass conflict.

About reducing compilation time: this section is very closely related
to http://www.boost.org/libs/python/doc/v2/faq.html#c1204.  Should we
cross-link them somehow?


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From nicodemus at globalite.com.br  Sun May 18 03:17:38 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Sat, 17 May 2003 17:17:38 -0800
Subject: [C++-sig] Re: pyste: current cvs/1_30_00 difference in treatment
 of overloaded members
In-Reply-To: <uznlnu82u.fsf@boost-consulting.com>
References: <m37k8uf5tj.fsf_-_@ntlworld.com> <3EC26CBE.3030003@globalite.com.br> <uk7csxwwl.fsf@boost-consulting.com> <3EC3E39E.7000509@globalite.com.br> <un0hovyry.fsf@boost-consulting.com> <3EC45942.9040405@globalite.com.br> <uznlnu82u.fsf@boost-consulting.com>
Message-ID: <3EC6DF32.2040403@globalite.com.br>

Thanks for the replies so far David, your help is very appreciated!

David Abrahams wrote:

>Oh, sorry.  You can of course stick a function in A_Wrapper which gets
>you &A::name:
>
>        static char const* (A::*a_name())() { return &A::name; }
>

Hmm... I did that, and added this line to the wrapper:

    .def("name", A_Wrapper::a_name(), &A_Wrapper::default_name)

And in Python:

 >>> from test import *
 >>> A()
<test.A object at 0x008B8560>
 >>> a = A()
 >>> a.name()
'foo'
 >>> a.get_name()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ReferenceError: Attempt to return dangling pointer to object of type: char
 >>>

Perhaps am I doing something wrong?

>>>I think trying to get Python A instances not to have a name method is
>>>sort of unpythonic, but be that as it may...
>>> To get overridability, you need to implement A_Wrapper::name() so
>>>that
>>>it dispatches into Python.  If you don't want to expose a "name"
>>>attribute, you'd better implement A_Wrapper::name() something like
>>>this:
>>>
>>>       char const* name()
>>>       {
>>>           if (PyObject_HasAttrString(this->self, "name"))
>>>               return boost::python::call_method<char const*>(self, "name");
>>>           else
>>>               return A::name();
>>>       }
>>> 
>>>
>>That's what I thought...
>>
>
>But it seems like that's not the solution you're looking for.
>Unfortunately Python doesn't let you say "who's asking?" before giving
>out an attribute value, so you can't hide A.name from everything
>that's not a derived class of A.
>

This solution would be perfect, except that the Python class can't 
access the default implementation of the method, which is a quite common 
need. 8/

>>I wanted to know how to expose the default implementation of
>>protected virtual methods, and also how should Pyste handle them. I
>>saw two options: export them normaly, just like a public method; or
>>override the function and inside it check if the python object has
>>reimplemented it, otherwise call the default implementation. I
>>wanted to discuss here in the list what would be the best method,
>>that's all.
>>
>
>OK, I understand now.  I hope I helped a little at least.
>

Of course you did. Thanks again,
Nicodemus.





From nicodemus at globalite.com.br  Sun May 18 03:41:25 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Sat, 17 May 2003 17:41:25 -0800
Subject: [C++-sig] Re: Tutorial - Techniques
In-Reply-To: <u7k8pojyc.fsf@boost-consulting.com>
References: <3EB586B7.8090108@globalite.com.br> <b952p7$ka$1@main.gmane.org> <u7k8pojyc.fsf@boost-consulting.com>
Message-ID: <3EC6E4C5.1090601@globalite.com.br>

David Abrahams wrote:

>Dirk Gerrits <dirk at gerrits.homeip.net> writes:
>
>  
>
>>Nicodemus wrote:
>>    
>>
>>>I created three sections, "Creating Packages", "Extending Wrapped
>>>Objects in Python" and "Reducing Compiling Time". Any comments are
>>>welcome!
>>>      
>>>
>>Just two minor nits about "Extending Wrapped Objects in Python":
>>
>>* advantages is misspelled 'advantagens'
>>* the term 'syntax sugar' is used, I thought it was 'syntactic sugar'?
>>    
>>
>
>I agree with Dirk; you did a wonderful job and I'm eager to get this
>into CVS!
>

Thanks!

>---
>A few more nits:
>
>the comment in the 2nd code box makes it too wide
>
>"Compiling this files will generate the following Python extensions"
>           ^^^^
>          "these"
>  
>

Fixed.

>That module renaming/packagizing thing is only one way to add Pure
>Python methods.  You might discuss other ways.  For example,
>sounds/__init__.py can add them directly (though that causes
>submodules to load early), or you can use the ihooks module to install
>an import hook from sounds/__init__.py, which, when you load
>sounds/foo.pyd, also loads sounds/_foo.py (or even foo.py!) and merges
>definitions, even merging functions from same-named classes.  Why
>ihooks isn't documented in the standard module docs, I'll never know
>;-).  It's only mentioned here
>http://www.python.org/doc/current/lib/built-in-funcs.html#l2h-64, but
>you can always:
>
>    >>> import ihooks
>    >>> help(ihooks)
>
>This solution might not be as simple to get started, but a single
>prepackaged __init__ could handle this for people so that they only
>need to write the pure python file.  OTOH, maybe that's more than you
>want to get into.  If Ralf is doing this sort of thing a lot, perhaps
>he'll want to implement that.
>  
>

Hmm... I didn't know about ihooks. I will take a look, thanks Dave.
If Ralf wants to contribute with something, I will gladly put it into 
the text.

>"But if we let it like this" should be "But if we leave it that way".
>  
>

Fixed.

>Did you actually test your MetaInjector thing?  I'm pretty sure you
>need to derive the metaclass from the metaclass used for Boost.Python
>objects, or you'll get a metaclass conflict.
>

Silly me! I did test, but with a pure Python class! 8P

Indeed, trying to inject methods in a Boost.Python class gives an error: 
"TypeError: metatype conflict among bases". So I tried to use your 
MetaInjector, but it gives the same error. Any idea?

>About reducing compilation time: this section is very closely related
>to http://www.boost.org/libs/python/doc/v2/faq.html#c1204.  Should we
>cross-link them somehow?
>

I added a blurb to the end of that section pointing to the FAQ.





From dave at boost-consulting.com  Sun May 18 01:33:49 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 17 May 2003 19:33:49 -0400
Subject: [C++-sig] Re: pyste: current cvs/1_30_00 difference in treatment of
 overloaded members
References: <m37k8uf5tj.fsf_-_@ntlworld.com> <3EC26CBE.3030003@globalite.com.br>
 <uk7csxwwl.fsf@boost-consulting.com> <3EC3E39E.7000509@globalite.com.br>
 <un0hovyry.fsf@boost-consulting.com> <3EC45942.9040405@globalite.com.br>
 <uznlnu82u.fsf@boost-consulting.com> <3EC6DF32.2040403@globalite.com.br>
Message-ID: <uvfw9qhb6.fsf@boost-consulting.com>

Nicodemus <nicodemus at globalite.com.br> writes:

> Thanks for the replies so far David, your help is very appreciated!
>
> David Abrahams wrote:
>
>>Oh, sorry.  You can of course stick a function in A_Wrapper which gets
>>you &A::name:
>>
>>        static char const* (A::*a_name())() { return &A::name; }
>>
>
> Hmm... I did that, and added this line to the wrapper:
>
>     .def("name", A_Wrapper::a_name(), &A_Wrapper::default_name)
>
> And in Python:
>
>  >>> from test import *
>  >>> A()
> <test.A object at 0x008B8560>
>  >>> a = A()
>  >>> a.name()
> 'foo'
>  >>> a.get_name()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ReferenceError: Attempt to return dangling pointer to object of type: char
>  >>>
>
> Perhaps am I doing something wrong?

Yes, but it's a separate problem.  See
http://www.boost.org/libs/python/doc/v2/faq.html#dangling

There's often no safe way to wrap virtual functions which return char
const*.  If you think about what has to happen in the dispatching
function you'll see why.

>>>>I think trying to get Python A instances not to have a name method is
>>>>sort of unpythonic, but be that as it may...
>>>> To get overridability, you need to implement A_Wrapper::name() so
>>>>that
>>>>it dispatches into Python.  If you don't want to expose a "name"
>>>>attribute, you'd better implement A_Wrapper::name() something like
>>>>this:
>>>>
>>>>       char const* name()
>>>>       {
>>>>           if (PyObject_HasAttrString(this->self, "name"))
>>>>               return boost::python::call_method<char const*>(self, "name");
>>>>           else
>>>>               return A::name();
>>>>       }
>>>> 
>>>That's what I thought...
>>>
>>
>>But it seems like that's not the solution you're looking for.
>>Unfortunately Python doesn't let you say "who's asking?" before giving
>>out an attribute value, so you can't hide A.name from everything
>>that's not a derived class of A.
>>
>
> This solution would be perfect, except that the Python class can't
> access the default implementation of the method, which is a quite
> common need. 8/

Too bad, I guess.  There's no way to have only partial access in
Python.  Either it's accessible to everyone or to no one.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From brett.calcott at paradise.net.nz  Sun May 18 05:40:24 2003
From: brett.calcott at paradise.net.nz (Brett Calcott)
Date: Sun, 18 May 2003 15:40:24 +1200
Subject: [C++-sig] OT: VC6 -> VC7
Message-ID: <ba6v85$42b$1@main.gmane.org>

Hi all,

I'm using VC6 Prof, and would like to upgrade to avoid the internal compiler
errors - but I am a little confused by the MS literature. Can someone let me
know whether this product:

Microsoft? Visual C++T .NET Standard 2003

which only costs $263.20 (New Zealand dollars), and is not an upgrade, has
all of the code optimisations. I seem to remember MS sold some Academic or
Cheaper version that lacked a few essential items like optimisation.

I want to avoid having to purchase .NET studio, which contains lots of stuff
I'll never use.

I've tried talking to MS in NZ - but they know little about the dev
products.

Cheers,
Brett






From tim at zope.com  Sun May 18 06:45:33 2003
From: tim at zope.com (Tim Peters)
Date: Sun, 18 May 2003 00:45:33 -0400
Subject: [C++-sig] OT: VC6 -> VC7
In-Reply-To: <ba6v85$42b$1@main.gmane.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEACEGAB.tim@zope.com>

[Brett Calcott]
> I'm using VC6 Prof, and would like to upgrade to avoid the
> internal compiler errors - but I am a little confused by the MS
> literature. Can someone let meknow whether this product:
>
> Microsoft? Visual C++T .NET Standard 2003
>
> which only costs $263.20 (New Zealand dollars), and is not an upgrade,
> has all of the code optimisations.

It does not.  See the third row in this table:

    http://msdn.microsoft.com/visualc/howtobuy/choosing.aspx


> I seem to remember MS sold some Academic or Cheaper version that
> lacked a few essential items like optimisation.

There's also Visual Studio .NET Academic.


> I want to avoid having to purchase .NET studio, which contains
> lots of stuff I'll never use.

Sorry, I think you're stuck.  MS knows professional apps need the optimizer,
so they don't put it in the cheapest product.  The same was true of VC6, of
course.




From brett.calcott at paradise.net.nz  Sun May 18 13:09:46 2003
From: brett.calcott at paradise.net.nz (Brett Calcott)
Date: Sun, 18 May 2003 23:09:46 +1200
Subject: [C++-sig] Re: OT: VC6 -> VC7
References: <ba6v85$42b$1@main.gmane.org> <LNBBLJKPBEHFEDALKOLCGEACEGAB.tim@zope.com>
Message-ID: <ba7piu$s0c$1@main.gmane.org>


"Tim Peters" wrote:
> > I'm using VC6 Prof, and would like to upgrade to avoid the internal
> > compiler errors - but I am a little confused by the MS literature.
> > Can someone let meknow whether this product:
> >
> > Microsoft? Visual C++T .NET Standard 2003
> >
> > which only costs $263.20 (New Zealand dollars), and is not an
> > upgrade, has all of the code optimisations.
>
> It does not.  See the third row in this table:
>
>     http://msdn.microsoft.com/visualc/howtobuy/choosing.aspx
>

Thanks for responding Tim. I was confused as I came across this:

http://www.microsoft.com/catalog/display.asp?subid=16&site=11511

It is headed "Microsoft Visual C++T.NET Standard 2003", and lists as one
of the benefits:

"Create Highly Tuned Unmanaged Windows-based Applications and Components
Write and compile unmanaged x86 code. Speed up your application or
reduce its size with optimization options for a range of processors,
including Whole Program Optimization, and support for Streaming SIMD
Extensions (SSE) and Streaming SIMD Extensions 2 (SSE2) instruction
sets."

I had another look, and found a second page:

http://www.microsoft.com/catalog/display.asp?site=11511&subid=16&pg=2

There is another page headed "Microsoft Visual C++ .NET Standard" (no
2003), which does not list these benefits.

Could it be that this is some new release which includes optimisation.

Or just an advertising mistake...


>
> > I seem to remember MS sold some Academic or Cheaper version that
> > lacked a few essential items like optimisation.
>
> There's also Visual Studio .NET Academic.
>
>
> > I want to avoid having to purchase .NET studio, which contains lots
> > of stuff I'll never use.
>
> Sorry, I think you're stuck.  MS knows professional apps need the
> optimizer, so they don't put it in the cheapest product.  The same was
> true of VC6, of course.
>

Yeah, but with VC6 you could get a C++ Professional. There is no such
thing as .NET C++ Prof. You have to buy the whole .NET thing.








From dave at boost-consulting.com  Sun May 18 16:19:00 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 18 May 2003 10:19:00 -0400
Subject: [C++-sig] Re: Tutorial - Techniques
References: <3EB586B7.8090108@globalite.com.br> <b952p7$ka$1@main.gmane.org>
 <u7k8pojyc.fsf@boost-consulting.com> <3EC6E4C5.1090601@globalite.com.br>
Message-ID: <u3cjcqqwb.fsf@boost-consulting.com>

Nicodemus <nicodemus at globalite.com.br> writes:

>>Did you actually test your MetaInjector thing?  I'm pretty sure you
>>need to derive the metaclass from the metaclass used for Boost.Python
>>objects, or you'll get a metaclass conflict.
>>
>
> Silly me! I did test, but with a pure Python class! 8P
>
> Indeed, trying to inject methods in a Boost.Python class gives an
> error: "TypeError: metatype conflict among bases". So I tried to use
> your MetaInjector, but it gives the same error. Any idea?

Err, did you take my code literally, and write:

    # The one Boost.Python uses for all wrapped classes.
    class BoostPythonMetaclass(type): pass

??

That doesn't work, of course.  The "one true metaclass" already exists
in Boost.Python.  You need to get the metaclass, either by explicitly
making it available in an extension module, or by getting it from some
wrapped class:

     BoostPythonMetaclass = some_wrapped_class.__class__

>>About reducing compilation time: this section is very closely related
>>to http://www.boost.org/libs/python/doc/v2/faq.html#c1204.  Should we
>>cross-link them somehow?
>>
>
> I added a blurb to the end of that section pointing to the FAQ.

I think you ought to add some entries to the FAQ which point into the
techniques paper as well... e.g., "Compilation takes forever! How can
I make it faster?"

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Sun May 18 16:38:46 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 18 May 2003 10:38:46 -0400
Subject: [C++-sig] Re: OT: VC6 -> VC7
References: <ba6v85$42b$1@main.gmane.org>
Message-ID: <usmrcpbex.fsf@boost-consulting.com>

"Brett Calcott" <brett.calcott at paradise.net.nz> writes:

> Hi all,
>
> I'm using VC6 Prof, and would like to upgrade to avoid the internal compiler
> errors - but I am a little confused by the MS literature. Can someone let me
> know whether this product:
>
> Microsoft? Visual C++T .NET Standard 2003
>
> which only costs $263.20 (New Zealand dollars), and is not an upgrade, has
> all of the code optimisations. I seem to remember MS sold some Academic or
> Cheaper version that lacked a few essential items like optimisation.
>
> I want to avoid having to purchase .NET studio, which contains lots of stuff
> I'll never use.
>
> I've tried talking to MS in NZ - but they know little about the dev
> products.

I've asked some of my friends at Microsoft to try to clear this up.

In the meantime, there are some known techniques for working around
ICEs in VC6.  I'd have to recommend the upgrade to vc7.1 at any price,
because it's a great compiler and well worth the investment. If,
however, you're serious about staying with vc6 for any reason, Boost
Consulting will be glad to be of assistance.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From achim.domma at syynx.de  Sun May 18 17:03:52 2003
From: achim.domma at syynx.de (Achim Domma)
Date: Sun, 18 May 2003 17:03:52 +0200
Subject: [C++-sig] current CVS: error in graph\adjacency_list.hpp
Message-ID: <FCEMIEFBFOIDAOJDEPIAIEHPFEAA.achim.domma@syynx.de>

Trying to compile boost.python from the current CVS I get the following
errors:

vc-C++
..\..\..\libs\python\build\bin\boost_python.dll\vc7\release\runtime-link-
dynamic\inheritance.obj
inheritance.cpp
K:\cvsroot\boost\boost\graph\adjacency_list.hpp(183) : error C2065:
'mulitsetS': undeclared identifier
K:\cvsroot\boost\boost\graph\adjacency_list.hpp(183) : error C2990:
'boost::container_selector' : non-template class has already been defined as
a template class
        K:\cvsroot\boost\boost\graph\adjacency_list.hpp(172) : see
declaration of 'boost::container_selector'

any idea what's going wrong?

regards,
Achim




From tim_one at email.msn.com  Sun May 18 19:04:07 2003
From: tim_one at email.msn.com (Tim Peters)
Date: Sun, 18 May 2003 13:04:07 -0400
Subject: [C++-sig] Re: OT: VC6 -> VC7
In-Reply-To: <ba7piu$s0c$1@main.gmane.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEPLEJAB.tim_one@email.msn.com>

[Brett Calcott]
> Thanks for responding Tim. I was confused as I came across this:
>
> http://www.microsoft.com/catalog/display.asp?subid=16&site=11511
>
> It is headed "Microsoft Visual C++T.NET Standard 2003", and lists as one
> of the benefits:
>
> "Create Highly Tuned Unmanaged Windows-based Applications and Components
> Write and compile unmanaged x86 code. Speed up your application or
> reduce its size with optimization options for a range of processors,
> including Whole Program Optimization, and support for Streaming SIMD
> Extensions (SSE) and Streaming SIMD Extensions 2 (SSE2) instruction
> sets."
>
> I had another look, and found a second page:
>
> http://www.microsoft.com/catalog/display.asp?site=11511&subid=16&pg=2
>
> There is another page headed "Microsoft Visual C++ .NET Standard" (no
> 2003), which does not list these benefits.
>
> Could it be that this is some new release which includes optimisation.
>
> Or just an advertising mistake...

Very interesting!  A bizarre other possibility is that MS loves New Zealand
so much that they're giving you a better product there <wink>.

PythonLabs has a .NET Standard C++ contributed by a user who wanted us to
move Python to VC7, so I know for certain that at least the US version does
not support optimization (you get a warning msg saying so if you pass an
optimization option to the compiler, and a Python built with it runs 3-4x
slower than under VC6 Pro with optimization; people who have .NET Studio Pro
with optimization have reported mildly smaller and faster Python executables
than under VC6 Pro).




From dave at boost-consulting.com  Mon May 19 02:16:52 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 18 May 2003 20:16:52 -0400
Subject: [C++-sig] Re: Sporadic access faults in
 boost::python::converter::registry::query()
References: <68FD589C-85FF-11D7-91C4-000A9566DA8A@uti.is>
Message-ID: <ullx3oknf.fsf@boost-consulting.com>

David Helgason <david at uti.is> writes:

> I hope I can make this understandable.
>
> I am using CodeWarrior 8.3 on OS X 10.2.6, with a Boost::Python CVS
> checkout from february.
>
> I have exported a class (Collider) to python. I use a pattern
> previously suggested on this list I believe for registering the
> converter (and a hack to solve a CodeWarrior bug with an identity
> function, also suggested here) in a thread called "Exporting
> references  into python", 2nd and 3rd of March this year.
>
> Now, when I try to convert types with no registered converter, I
> rightly get an error. But when I try to convert my registered class
> Collider, it sometimes works and sometimes gives an access fault. 

Is it repeatable with the same bit of Python code?

> The last part of the stack trace is attached below.

The first thing to do when posting stack traces is to pass them
through c++filt so we can read them ;-).

> Now, I have tried to debug this by looking at the set<entry> lookup
> which goes on here,
>
>        registry_t::iterator p = entries().find(entry(type));
>
> but the CW debugger consistently crashes when I try. 

Yum!  Have you tried GDB?

> Intercepting the call on the way in (at levels 3-18 in the
> stacktrace), I don't see any difference with the data coming in: I
> certainly have no NULL pointer coming in.
>
> I suspect foul play by the compiler, and wonder if this is a known
> problem 

Not until you reported it.

> and/or whether I should try to upgade to a newer version of
> boost::python.

You can always try.  Have you tried to reproduce the problem on any
other platform?  FWIW I like to keep a copy of Microsoft Visual
Studio handy for its incredibly robust debugger.

> I will of course submit code samples if anyone is interested, or
> follow  any other instructions for that matter.

I've BCC'd people on the compiler and library (because it appears to
crash in the std::set implementation) teams at Metrowerks; they may
have some ideas.  Otherwise, I suggest you try this on other
platforms/compilers.  As a last resort I guess if you can post a small
reproducible test case someone else can try to get it to break on
another platform.

---

Thread 0 Crashed:
  #0   0x003d4e2c in
   _ZNSt6__treeIN5boost6python9converter12registrationENSt4lessIS3_EESaIS3_
   EE4findIS3_EENS_18__generic_iteratorILb0EEERKT2_
  #1   0x00154fc0 in
   boost::python::converter::registry::query(boost::python::type_info)
  #2   0x0009e0f0 in
   _ZN5boost6python7objects17make_ptr_instanceI8ColliderNS1_14pointer_holde
   rIPS3_S3_EEE24get_derived_class_objectIS3_EEP11_typeobjectNS_3mpl6bool_c
   ILb1EEEPVKT1_

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Mon May 19 02:19:22 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 18 May 2003 20:19:22 -0400
Subject: [C++-sig] Re: gcc 3.3
References: <5.1.0.14.2.20021211170218.03babb20@mail.earthlink.net> <200305151840.h4FIeEW04774@libra3.slac.stanford.edu>
 <u65obvn29.fsf@boost-consulting.com>
 <200305160107.h4G173413656@libra3.slac.stanford.edu>
Message-ID: <ufznbokj9.fsf@boost-consulting.com>

"Paul F. Kunz" <Paul_Kunz at SLAC.Stanford.EDU> writes:

>>>>>> On Thu, 15 May 2003 18:53:50 -0400, David Abrahams <dave at boost-consulting.com> said:
>
>> "Paul F. Kunz" <Paul_Kunz at SLAC.Stanford.EDU> writes:
>>> I've just installed gcc 3.3 and I get the following error
>>> 
>>> /usr/local/boost/boost/python/converter/as_to_python_function.hpp:31:
>>> sorry, unimplemented: ` method_call_expr' not supported by
>>> dump_expr
>>> 
>>> I understanding the warning, but I get the error 4 times.  Any
>>> ideas?
>
>> That's a compiler bug, plain and simple.  You should report it to
>> the gcc people: http://gcc.gnu.org/bugs.html.
>
>    If I knew what the bug was, I would.   

What do you mean "what the bug was?"  You don't have to diagnose the
bug to report it.  Any time you get an internal assertion failure
from the compiler like that, all you have to do is post them a
preprocessed file that reproduces it.

> Did this bug show up in one of the failed boost regression tests
> that I posted?  If so, which one.  

Now I'm really confused.  If you posted the regressions, surely you
can go through them and look for that error message?

> Sending that test to the gcc people would be a lot more useful thatn
> how I can described the bug.

Sure, can't you do that?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From Paul_Kunz at SLAC.Stanford.EDU  Mon May 19 03:18:52 2003
From: Paul_Kunz at SLAC.Stanford.EDU (Paul F. Kunz)
Date: Sun, 18 May 2003 18:18:52 -0700
Subject: [C++-sig] Re: gcc 3.3
In-Reply-To: <ufznbokj9.fsf@boost-consulting.com>
References: <5.1.0.14.2.20021211170218.03babb20@mail.earthlink.net>
 <200305151840.h4FIeEW04774@libra3.slac.stanford.edu>
 <u65obvn29.fsf@boost-consulting.com>
 <200305160107.h4G173413656@libra3.slac.stanford.edu>
 <ufznbokj9.fsf@boost-consulting.com>
Message-ID: <200305190118.h4J1Iq404745@libra3.slac.stanford.edu>

>>>>> On Sun, 18 May 2003 20:19:22 -0400, David Abrahams <dave at boost-consulting.com> said:

> "Paul F. Kunz" <Paul_Kunz at SLAC.Stanford.EDU> writes:
>>>>>>> On Thu, 15 May 2003 18:53:50 -0400, David Abrahams
>>>>>>> <dave at boost-consulting.com> said:
>>
>>> "Paul F. Kunz" <Paul_Kunz at SLAC.Stanford.EDU> writes:
>>>> I've just installed gcc 3.3 and I get the following error
>>>> 
>>>> /usr/local/boost/boost/python/converter/as_to_python_function.hpp:31:
>>>> sorry, unimplemented: ` method_call_expr' not supported by
>>>> dump_expr
>>>> 
>>>> I understanding the warning, but I get the error 4 times.  Any
>>>> ideas?
>>
>>> That's a compiler bug, plain and simple.  You should report it to
>>> the gcc people: http://gcc.gnu.org/bugs.html.
>>  If I knew what the bug was, I would.

> What do you mean "what the bug was?"  You don't have to diagnose the
> bug to report it.  Any time you get an internal assertion failure
> from the compiler like that, 

   Oh, the message is coming from the compiler.   I thought it was
coming from the BOOST_ASSERT on that line.

> all you have to do is post them a
> preprocessed file that reproduces it.

   Ok, I'm familer with that.

>> Did this bug show up in one of the failed boost regression tests
>> that I posted?  If so, which one.

> Now I'm really confused.  If you posted the regressions, surely you
> can go through them and look for that error message?

   Sorry, I should have thought of that once I realize it was a
compiler error.   The answer is, no such error message from the
regression tests.

>> Sending that test to the gcc people would be a lot more useful
>> thatn how I can described the bug.

> Sure, can't you do that?

   Will do.




From brett.calcott at paradise.net.nz  Mon May 19 10:30:50 2003
From: brett.calcott at paradise.net.nz (Brett Calcott)
Date: Mon, 19 May 2003 20:30:50 +1200
Subject: [C++-sig] Re: Re: OT: VC6 -> VC7
References: <ba7piu$s0c$1@main.gmane.org> <LNBBLJKPBEHFEDALKOLCGEPLEJAB.tim_one@email.msn.com>
Message-ID: <baa513$fiq$1@main.gmane.org>

>
> Very interesting!  A bizarre other possibility is that MS loves New
Zealand
> so much that they're giving you a better product there <wink>.
>

Ah yes, living in the GMT+12 Timezone, we're always one step ahead :)






From brett.calcott at paradise.net.nz  Mon May 19 10:37:29 2003
From: brett.calcott at paradise.net.nz (Brett Calcott)
Date: Mon, 19 May 2003 20:37:29 +1200
Subject: [C++-sig] Re: OT: VC6 -> VC7
References: <ba6v85$42b$1@main.gmane.org> <usmrcpbex.fsf@boost-consulting.com>
Message-ID: <baa515$fiq$2@main.gmane.org>

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

> "Brett Calcott" <brett.calcott at paradise.net.nz> writes:
>
> > Hi all,
> >
> > I'm using VC6 Prof, and would like to upgrade to avoid the internal
compiler
> > errors - but I am a little confused by the MS literature. Can someone
let me
> > know whether this product:
> >
> > Microsoft? Visual C++T .NET Standard 2003
> >
> > which only costs $263.20 (New Zealand dollars), and is not an upgrade,
has
> > all of the code optimisations. I seem to remember MS sold some Academic
or
> > Cheaper version that lacked a few essential items like optimisation.
> >
> > I want to avoid having to purchase .NET studio, which contains lots of
stuff
> > I'll never use.
> >
> > I've tried talking to MS in NZ - but they know little about the dev
> > products.
>
> I've asked some of my friends at Microsoft to try to clear this up.
>
> In the meantime, there are some known techniques for working around
> ICEs in VC6.  I'd have to recommend the upgrade to vc7.1 at any price,
> because it's a great compiler and well worth the investment. If,
> however, you're serious about staying with vc6 for any reason, Boost
> Consulting will be glad to be of assistance.
>

I'm quitting my job (and $) and going back to uni for 3-4 years, so my
budget is tight. I'll need the optimisations as I'll be writing some
simulations as part of my study - the core in C++, the rest will be in
python.

I can live with VC6 - I have for some years already - but I thought it might
be time to move on (sigh).

Thanks for your enquiries - my local MS shop had no idea.

Brett






From cyril.bonnard at cirad.fr  Mon May 19 12:04:29 2003
From: cyril.bonnard at cirad.fr (Cyril Bonnard)
Date: Mon, 19 May 2003 12:04:29 +0200
Subject: [C++-sig] no matching function for call
Message-ID: <3EC8AC2D.6050607@cirad.fr>

If someone could help me on theses errors.......

1///
I just can't explain why the following code (line 17) doesn't work fine:

error is:
appe_color.cpp: In function `void init_module_appe_color()':
appe_color.cpp:17: no matching function for call to 
`boost::python::class_<Color3, boost::python::detail::not_specified, 
boost::python::detail::not_specified, 
boost::python::detail::not_specified>::def_readonly(const char[6], const 
Color3*)



code is:
appe_color.cpp:
...
BOOST_PYTHON_MODULE(appe_color)
{
    class_< Color3 >("Color3", init< const Color3 & >())
        .def(init< unsigned char, unsigned char, unsigned char >())
        .def(init< optional< unsigned char > >())
        .def(init< const unsigned char * >())
 
        .def_readonly("BLACK", &Color3::BLACK)   // line 17
...

appe_color.h:
...
class GEOM_API Color3 : public TOOLS(Tuple3)<uchar>
//class Color3 : public UCharTuple3
{

  friend class Color4;

public:

  /// The black color.
  static const Color3 BLACK;
...

2///
I also get a problem with constructor of class Color4: the pb is that 
one of the constructor seems to not match one of the 4 defined constructors,

appe_color.cpp:42:call of overloaded `Color4(unsigned char&)' is ambiguous
/home/cbonnard/devlp/AMAPmod/src/GEOM/appe_color.h:157: candidates are: 
Color4::Color4(const Color4&) <near match>
/home/cbonnard/devlp/AMAPmod/src/GEOM/appe_color.h:168:                 
Color4::Color4(const uchar*) <near match>
/home/cbonnard/devlp/AMAPmod/src/GEOM/appe_color.h:165:                 
Color4::Color4(unsigned char)
/home/cbonnard/devlp/AMAPmod/src/GEOM/appe_color.h:162:                 
Color4::Color4(unsigned char = 255, unsigned char = 255, unsigned char = 
255, unsigned char = 0)

appe_color.cpp:
    class_< Color4 >("Color4", init< const Color4 & >())
        .def(init< optional< unsigned char, unsigned char, unsigned 
char, unsigned char > >())
        .def(init< unsigned char >())                                   
                                                              // line 
42: the one that should be recognized
        .def(init< const unsigned char * >())
        .def(init< const Color3 &, unsigned char >())

appe_color.h:
  explicit Color4( uchar r = 255, uchar g = 255, uchar b = 255, uchar a 
= 0 ) ;
  explicit Color4( uchar v );
               Color4( const uchar * rgba );
               Color4( const Color3& c, uchar alpha );









From brett.calcott at paradise.net.nz  Mon May 19 12:13:55 2003
From: brett.calcott at paradise.net.nz (Brett Calcott)
Date: Mon, 19 May 2003 22:13:55 +1200
Subject: [C++-sig] Re: current CVS: error in graph\adjacency_list.hpp
References: <FCEMIEFBFOIDAOJDEPIAIEHPFEAA.achim.domma@syynx.de>
Message-ID: <baaanb$8i4$1@main.gmane.org>


"Achim Domma" <achim.domma at syynx.de> wrote:

> Trying to compile boost.python from the current CVS I get the following
> errors:
>
> vc-C++
> ..\..\..\libs\python\build\bin\boost_python.dll\vc7\release\runtime-link-
> dynamic\inheritance.obj
> inheritance.cpp
> K:\cvsroot\boost\boost\graph\adjacency_list.hpp(183) : error C2065:
> 'mulitsetS': undeclared identifier
     ^^^^
This is just a spelling mistake. It should be "multisetS"

It compiles if you fix this.

The cross-post should find the right person (vladimir prus?)











From Paul_Kunz at SLAC.Stanford.EDU  Mon May 19 18:15:57 2003
From: Paul_Kunz at SLAC.Stanford.EDU (Paul F. Kunz)
Date: Mon, 19 May 2003 09:15:57 -0700
Subject: [C++-sig] Re: gcc 3.3
In-Reply-To: <ufznbokj9.fsf@boost-consulting.com>
References: <5.1.0.14.2.20021211170218.03babb20@mail.earthlink.net>
 <200305151840.h4FIeEW04774@libra3.slac.stanford.edu>
 <u65obvn29.fsf@boost-consulting.com>
 <200305160107.h4G173413656@libra3.slac.stanford.edu>
 <ufznbokj9.fsf@boost-consulting.com>
Message-ID: <200305191615.h4JGFvD07324@libra3.slac.stanford.edu>

>>>>> On Sun, 18 May 2003 20:19:22 -0400, David Abrahams <dave at boost-consulting.com> said:

> What do you mean "what the bug was?"  You don't have to diagnose the
> bug to report it.  Any time you get an internal assertion failure
> from the compiler like that, all you have to do is post them a
> preprocessed file that reproduces it.

   Its is GCC's GnatsWeb.   Someone beat me to it.
   



From rwgk at yahoo.com  Mon May 19 18:34:14 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 19 May 2003 09:34:14 -0700 (PDT)
Subject: [C++-sig] Re: Tutorial - Techniques
In-Reply-To: <3EC6E4C5.1090601@globalite.com.br>
Message-ID: <20030519163414.22711.qmail@web20202.mail.yahoo.com>

--- Nicodemus <nicodemus at globalite.com.br> wrote:
> Hmm... I didn't know about ihooks. I will take a look, thanks Dave.
> If Ralf wants to contribute with something, I will gladly put it into 
> the text.

I'll give it a go when Bruno's material is in the CVS database.
Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From dominique.devriese at student.kuleuven.ac.be  Mon May 19 18:41:31 2003
From: dominique.devriese at student.kuleuven.ac.be (Dominique Devriese)
Date: 19 May 2003 18:41:31 +0200
Subject: [C++-sig] Re: gcc 3.3
In-Reply-To: <200305191615.h4JGFvD07324@libra3.slac.stanford.edu>
References: <5.1.0.14.2.20021211170218.03babb20@mail.earthlink.net>
	<200305151840.h4FIeEW04774@libra3.slac.stanford.edu>
	<u65obvn29.fsf@boost-consulting.com>
	<200305160107.h4G173413656@libra3.slac.stanford.edu>
	<ufznbokj9.fsf@boost-consulting.com>
	<200305191615.h4JGFvD07324@libra3.slac.stanford.edu>
Message-ID: <87znlikhxg.fsf@student.kuleuven.ac.be>

Paul F Kunz writes:

  >>>>>> On Sun, 18 May 2003 20:19:22 -0400, David Abrahams
  >>>>>> <dave at boost-consulting.com> said:
  >> What do you mean "what the bug was?"  You don't have to diagnose
  >> the bug to report it.  Any time you get an internal assertion
  >> failure from the compiler like that, all you have to do is post
  >> them a preprocessed file that reproduces it.

  Paul>    Its is GCC's GnatsWeb.  Someone beat me to it.

err.. yes, I did :)  I had the same problem, but I only noticed now
that there was a discussion about this here too..

cheers
domi

-- 
Bank error in your favor.  Collect $200.



From dave at boost-consulting.com  Mon May 19 21:18:29 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 19 May 2003 15:18:29 -0400
Subject: [C++-sig] Re: no matching function for call
References: <3EC8AC2D.6050607@cirad.fr>
Message-ID: <u7k8mkanu.fsf@boost-consulting.com>

Cyril Bonnard <cyril.bonnard at cirad.fr> writes:

> If someone could help me on theses errors.......
>
> 1///
> I just can't explain why the following code (line 17) doesn't work fine:
>
> error is:
> appe_color.cpp: In function `void init_module_appe_color()':
> appe_color.cpp:17: no matching function for call to
> boost::python::class_<Color3, boost::python::detail::not_specified,
> boost::python::detail::not_specified,
> boost::python::detail::not_specified>::def_readonly(const char[6],
> const Color3*)

Are you using the current Boost CVS state or something earlier?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Mon May 19 21:20:14 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 19 May 2003 15:20:14 -0400
Subject: [C++-sig] Re: current CVS: error in graph\adjacency_list.hpp
References: <FCEMIEFBFOIDAOJDEPIAIEHPFEAA.achim.domma@syynx.de> <baaanb$8i4$1@main.gmane.org>
Message-ID: <u1xyukakx.fsf@boost-consulting.com>

"Brett Calcott" <brett.calcott at paradise.net.nz> writes:

> "Achim Domma" <achim.domma at syynx.de> wrote:
>
>> Trying to compile boost.python from the current CVS I get the following
>> errors:
>>
>> vc-C++
>> ..\..\..\libs\python\build\bin\boost_python.dll\vc7\release\runtime-link-
>> dynamic\inheritance.obj
>> inheritance.cpp
>> K:\cvsroot\boost\boost\graph\adjacency_list.hpp(183) : error C2065:
>> 'mulitsetS': undeclared identifier
>      ^^^^
> This is just a spelling mistake. It should be "multisetS"
>
> It compiles if you fix this.
>
> The cross-post should find the right person (vladimir prus?)

Yup, CVS annotate confirms that.  Fixed in CVS, thanks.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From nickhod at microsoft.com  Mon May 19 20:40:59 2003
From: nickhod at microsoft.com (Nick Hodapp)
Date: Mon, 19 May 2003 11:40:59 -0700
Subject: [C++-sig] RE: VC6 -> VC7
Message-ID: <01B0F1A5817E244FA89D7F580EE3139D07FE9611@red-msg-09.redmond.corp.microsoft.com>

Visual C++ .NET 2003 Standard Edition does not include the optimizing
C++ compiler.  That feature is only available in Visual Studio .NET 2003
Professional or Enterprise versions.



-----Original Message-----
From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org] On
Behalf Of Brett Calcott
Sent: Sunday, May 18, 2003 4:10 AM



"Tim Peters" wrote:
> > I'm using VC6 Prof, and would like to upgrade to avoid the internal
> > compiler errors - but I am a little confused by the MS literature.
> > Can someone let meknow whether this product:
> >
> > Microsoft(r) Visual C++T .NET Standard 2003
> >
> > which only costs $263.20 (New Zealand dollars), and is not an
> > upgrade, has all of the code optimisations.
>
> It does not.  See the third row in this table:
>
>     http://msdn.microsoft.com/visualc/howtobuy/choosing.aspx
>

Thanks for responding Tim. I was confused as I came across this:

http://www.microsoft.com/catalog/display.asp?subid=16&site=11511

It is headed "Microsoft Visual C++T.NET Standard 2003", and lists as one
of the benefits:

"Create Highly Tuned Unmanaged Windows-based Applications and Components
Write and compile unmanaged x86 code. Speed up your application or
reduce its size with optimization options for a range of processors,
including Whole Program Optimization, and support for Streaming SIMD
Extensions (SSE) and Streaming SIMD Extensions 2 (SSE2) instruction
sets."

I had another look, and found a second page:

http://www.microsoft.com/catalog/display.asp?site=11511&subid=16&pg=2

There is another page headed "Microsoft Visual C++ .NET Standard" (no
2003), which does not list these benefits.

Could it be that this is some new release which includes optimisation.

Or just an advertising mistake...


>
> > I seem to remember MS sold some Academic or Cheaper version that
> > lacked a few essential items like optimisation.
>
> There's also Visual Studio .NET Academic.
>
>
> > I want to avoid having to purchase .NET studio, which contains lots
> > of stuff I'll never use.
>
> Sorry, I think you're stuck.  MS knows professional apps need the
> optimizer, so they don't put it in the cheapest product.  The same was
> true of VC6, of course.
>

Yeah, but with VC6 you could get a C++ Professional. There is no such
thing as .NET C++ Prof. You have to buy the whole .NET thing.



From nicodemus at globalite.com.br  Tue May 20 06:41:26 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Mon, 19 May 2003 20:41:26 -0800
Subject: [C++-sig] Re: Tutorial - Techniques
In-Reply-To: <u3cjcqqwb.fsf@boost-consulting.com>
References: <3EB586B7.8090108@globalite.com.br> <b952p7$ka$1@main.gmane.org> <u7k8pojyc.fsf@boost-consulting.com> <3EC6E4C5.1090601@globalite.com.br> <u3cjcqqwb.fsf@boost-consulting.com>
Message-ID: <3EC9B1F6.4050309@globalite.com.br>

David Abrahams wrote:

>Nicodemus <nicodemus at globalite.com.br> writes:
>
>
>>>Did you actually test your MetaInjector thing?  I'm pretty sure you
>>>need to derive the metaclass from the metaclass used for Boost.Python
>>>objects, or you'll get a metaclass conflict.
>>>
>>>
>>Silly me! I did test, but with a pure Python class! 8P
>>
>>Indeed, trying to inject methods in a Boost.Python class gives an
>>error: "TypeError: metatype conflict among bases". So I tried to use
>>your MetaInjector, but it gives the same error. Any idea?
>>
>
>Err, did you take my code literally, and write:
>
>    # The one Boost.Python uses for all wrapped classes.
>    class BoostPythonMetaclass(type): pass
>
>??
>
>That doesn't work, of course.  The "one true metaclass" already exists
>in Boost.Python.  You need to get the metaclass, either by explicitly
>making it available in an extension module, or by getting it from some
>wrapped class:
>
>     BoostPythonMetaclass = some_wrapped_class.__class__
>

Yeah, I tried to use some_wrapped_class.__metaclass__, but the classes 
don't have this attribute. I didn't know you could use the class as a 
metaclass... anyway, the code now works:

    # The one Boost.Python uses for all wrapped classes.
    # You can use here any class exported by Boost instead of "point"
    BoostPythonMetaclass = point.__class__

    class injector(object):
        class __metaclass__(BoostPythonMetaclass):
            def __init__(self, name, bases, dict):
                for b in bases:
                    if type(b) not in (self, type):
                        for k,v in dict.items():
                            setattr(b,k,v)
                return type.__init__(self, name, bases, dict)

    # inject some methods in the point foo
    class more_point(injector, point):
        def __repr__(self):
            return 'Point(x=%s, y=%s)' % (self.x, self.y)
        def foo(self):
            print 'foo!'

>>>About reducing compilation time: this section is very closely related
>>>to http://www.boost.org/libs/python/doc/v2/faq.html#c1204.  Should we
>>>cross-link them somehow?
>>>
>>>
>>I added a blurb to the end of that section pointing to the FAQ.
>>
>
>I think you ought to add some entries to the FAQ which point into the
>techniques paper as well... e.g., "Compilation takes forever! How can
>I make it faster?"
>

Good idea! I added two new entries,  "How do I create sub-packages using 
Boost.Python?" and "Compilation takes too much time and eats too much 
memory! What can I do to make it faster?". Attached is a diff for it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20030519/3124163e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Techniques.zip
Type: application/zip
Size: 32283 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20030519/3124163e/attachment.zip>

From cyril.bonnard at cirad.fr  Tue May 20 08:45:29 2003
From: cyril.bonnard at cirad.fr (Cyril Bonnard)
Date: Tue, 20 May 2003 08:45:29 +0200
Subject: [C++-sig] Re: no matching function for call
References: <3EC8AC2D.6050607@cirad.fr> <u7k8mkanu.fsf@boost-consulting.com>
Message-ID: <3EC9CF09.6070204@cirad.fr>

David Abrahams wrote:

>Cyril Bonnard <cyril.bonnard at cirad.fr> writes:
>
>  
>
>>If someone could help me on theses errors.......
>>
>>1///
>>I just can't explain why the following code (line 17) doesn't work fine:
>>
>>error is:
>>appe_color.cpp: In function `void init_module_appe_color()':
>>appe_color.cpp:17: no matching function for call to
>>boost::python::class_<Color3, boost::python::detail::not_specified,
>>boost::python::detail::not_specified,
>>boost::python::detail::not_specified>::def_readonly(const char[6],
>>const Color3*)
>>    
>>
>
>Are you using the current Boost CVS state or something earlier?
>
>  
>
i am currently working with Boost CVS....





From rwgk at yahoo.com  Tue May 20 09:43:44 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 20 May 2003 00:43:44 -0700 (PDT)
Subject: [C++-sig] make_getter problem
Message-ID: <20030520074344.66900.qmail@web20201.mail.yahoo.com>

The code below comiles and works as expected with Boost 1.30.0, but fails to
compile with the current CVS state (see attached error message) unless the
add_property line is commented out. What could be wrong?
Thanks,
        Ralf

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

namespace sandbx { namespace {

  struct trivial
  {
    trivial() : value(123) {}
    double value;
  };

  void init_module()
  {
    using namespace boost::python;
    class_<trivial>("trivial")
      .add_property("property", make_getter(&trivial::value,
return_value_policy<return_by_value>()))
      .def_readonly("readonly", &trivial::value)
    ;
  }

}} // namespace sandbx::<anonymous>

BOOST_PYTHON_MODULE(make_getter)
{
  sandbx::init_module();
}


Output of gcc 3.2 (similar with gcc 3.3):

g++ -fPIC -ftemplate-depth-120 -w -O0 -fno-inline -DBOOST_PYTHON_MAX_BASES=2
-I/net/cci/rwgk/hot/sandbx/include -I/net/cci/rwgk/hot/boost
-I/usr/include/python2.2 -c -o sandbx/debug/make_getter_module.os
/net/cci/rwgk/hot/sandbx/debug/make_getter_module.cpp
/net/cci/rwgk/hot/sandbx/debug/make_getter_module.cpp: In function `void 
   sandbx::<unnamed>::init_module()':
/net/cci/rwgk/hot/sandbx/debug/make_getter_module.cpp:16: could not convert `
   &sandbx::<unnamed>::trivial::value' to `double 
   sandbx::<unnamed>::trivial::*&'
/net/cci/rwgk/hot/boost/boost/python/data_members.hpp:219: in passing argument 
   1 of `boost::python::api::object boost::python::make_getter(D&, const 
   Policies&) [with D = double sandbx::<unnamed>::trivial::*, Policies = 
   boost::python::return_value_policy<boost::python::return_by_value, 
   boost::python::default_call_policies>]'


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From cyril.bonnard at cirad.fr  Tue May 20 10:53:55 2003
From: cyril.bonnard at cirad.fr (Cyril Bonnard)
Date: Tue, 20 May 2003 10:53:55 +0200
Subject: [C++-sig] problem using global variable, static variable
References: <20030520074344.66900.qmail@web20201.mail.yahoo.com>
Message-ID: <3EC9ED23.9030104@cirad.fr>

i have a problem defining global and static variables: the variable is 
not recognized

this peace of code highlights the problem:
test.h:
class color
{
public:
  color() : col(0) {}
  ~color() {}
 
  const static color BLACK;// error
  //static color YELLOW;     // same error
  //static int i;            // same error
  int col;
};

test.cpp: In function `void init_module_test()':
test.cpp:14: no matching function for call to 
`boost::python::class_<color, boost::python::detail::not_specified, 
boost::python::detail::not_specified, 
boost::python::detail::not_specified>::def_readonly(const char[6], const 
color*)'
scons: *** [test.os] Error


i try to reproduce this "behaviour" with a global variable using pyste:

class color
{
public:
  color() : col(0) {}
  ~color() {}
 
  //const static color BLACK;// error
  //static color YELLOW;     // error
  //static int i;            // error
  int col;
};

static color BLACK;

pyste generates code which seems very strange to me:
BOOST_PYTHON_MODULE(test)
{
    class_< color >("color", init<  >())
        .def(init< const color & >())
        .def_readwrite("col", &color::col)
    ;

    def("_GLOBAL__D__home_cbonnard_devlp_AMAPmod_src_GEOM_test.hef3xme", 
&_GLOBAL__D__home_cbonnard_devlp_AMAPmod_src_GEOM_test.hef3xme);
    def("_GLOBAL__I__home_cbonnard_devlp_AMAPmod_src_GEOM_test.hp8ylhc", 
&_GLOBAL__I__home_cbonnard_devlp_AMAPmod_src_GEOM_test.hp8ylhc);

My questions are: how should i proceed to declare and use global and 
static variables? is the above pyste code known? how to resolve the problem?









From brett.calcott at paradise.net.nz  Tue May 20 11:12:06 2003
From: brett.calcott at paradise.net.nz (Brett Calcott)
Date: Tue, 20 May 2003 21:12:06 +1200
Subject: [C++-sig] Re: VC6 -> VC7
References: <01B0F1A5817E244FA89D7F580EE3139D07FE9611@red-msg-09.redmond.corp.microsoft.com>
Message-ID: <bacre0$2tp$1@main.gmane.org>

> Visual C++ .NET 2003 Standard Edition does not include the optimizing
> C++ compiler.  That feature is only available in Visual Studio .NET
> 2003 Professional or Enterprise versions.
>

Okay, I thought it was too good to be true.

Back to the ICE world...






From dave at boost-consulting.com  Tue May 20 13:42:42 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 20 May 2003 07:42:42 -0400
Subject: [C++-sig] Re: Tutorial - Techniques
References: <3EB586B7.8090108@globalite.com.br> <b952p7$ka$1@main.gmane.org>
 <u7k8pojyc.fsf@boost-consulting.com> <3EC6E4C5.1090601@globalite.com.br>
 <u3cjcqqwb.fsf@boost-consulting.com> <3EC9B1F6.4050309@globalite.com.br>
Message-ID: <uptmdhmj1.fsf@boost-consulting.com>

Nicodemus <nicodemus at globalite.com.br> writes:

> Good idea! I added two new entries,  "How do I create sub-packages
> using Boost.Python?" and "Compilation takes too much time and eats too
> much memory! What can I do to make it faster?". Attached is a diff for
> it.
> *** original-faq.html	Tue Mar 18 17:49:50 2003
> --- faq.html	Mon May 19 20:38:47 2003
> ***************
> *** 57,62 ****
> --- 57,67 ----
>   
>         #ownership
> +   
> +       #slow_compilation
> +       
> +       #packages 
>       </dl>

Somehow that doesn't look like valid HTML.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Tue May 20 13:47:56 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 20 May 2003 07:47:56 -0400
Subject: [C++-sig] Re: problem using global variable, static variable
References: <20030520074344.66900.qmail@web20201.mail.yahoo.com> <3EC9ED23.9030104@cirad.fr>
Message-ID: <uk7clhmab.fsf@boost-consulting.com>

Cyril Bonnard <cyril.bonnard at cirad.fr> writes:

> i have a problem defining global and static variables: the variable is
> not recognized

Obviously a bug crept into the CVS; I'll address it this morning.
Sorry!

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From phil at freehackers.org  Tue May 20 19:02:43 2003
From: phil at freehackers.org (Philippe Fremy)
Date: Tue, 20 May 2003 19:02:43 +0200
Subject: [C++-sig] avoiding long long warning in boost
Message-ID: <200305201902.43420.phil@freehackers.org>

	Hi,

I am trying to build my first python extension with boost. For personal 
reasons I am using a tmake based makefile instead of the bjam one. But it 
should not relate to my question.

When building my extension, I get tons of warning, some from the long long 
usage, others being obscure to me.

I was wondering if there is any way to disable the use of long long in 
boost, so that I don't get all these warnings. There seem to be some macro 
testing before enabling the use of long long but I am too unfamiliar with 
boost to understand where I can configure that.

I also welcome any information from the second error.

	regards,

	Philippe

philippe at werewindle 
~/work/jayacard/cvs-sf_jayacard/experimental/boost_python $ make
g++ -c -pipe -Wall -W -ansi -pedantic -Wno-unused-parameter -g -fPIC 
-DBOOST_PYTHON_DYNAMIC_LIB -I/usr/include/python2.2 -I/usr/src/boost_1_29_0 
-o obj/some_file.o some_file.cpp
In file included from /usr/src/boost_1_29_0/boost/python.hpp:43,
                 from some_file.cpp:53:
/usr/src/boost_1_29_0/boost/python/operators.hpp:184:42: warning: pasting 
"operator" and "+" does not give a valid preprocessing token
/usr/src/boost_1_29_0/boost/python/operators.hpp:185:42: warning: pasting 
"operator" and "-" does not give a valid preprocessing token
/usr/src/boost_1_29_0/boost/python/operators.hpp:186:42: warning: pasting 
"operator" and "*" does not give a valid preprocessing token
/usr/src/boost_1_29_0/boost/python/operators.hpp:187:42: warning: pasting 
"operator" and "/" does not give a valid preprocessing token
/usr/src/boost_1_29_0/boost/python/operators.hpp:188:42: warning: pasting 
"operator" and "%" does not give a valid preprocessing token
/usr/src/boost_1_29_0/boost/python/operators.hpp:189:49: warning: pasting 
"operator" and "<<" does not give a valid preprocessing token
/usr/src/boost_1_29_0/boost/python/operators.hpp:190:49: warning: pasting 
"operator" and ">>" does not give a valid preprocessing token
/usr/src/boost_1_29_0/boost/python/operators.hpp:191:42: warning: pasting 
"operator" and "&" does not give a valid preprocessing token
/usr/src/boost_1_29_0/boost/python/operators.hpp:192:42: warning: pasting 
"operator" and "^" does not give a valid preprocessing token
/usr/src/boost_1_29_0/boost/python/operators.hpp:193:40: warning: pasting 
"operator" and "|" does not give a valid preprocessing token
/usr/src/boost_1_29_0/boost/python/operators.hpp:194:39: warning: pasting 
"operator" and ">" does not give a valid preprocessing token
/usr/src/boost_1_29_0/boost/python/operators.hpp:195:40: warning: pasting 
"operator" and ">=" does not give a valid preprocessing token
/usr/src/boost_1_29_0/boost/python/operators.hpp:196:39: warning: pasting 
"operator" and "<" does not give a valid preprocessing token
/usr/src/boost_1_29_0/boost/python/operators.hpp:197:40: warning: pasting 
"operator" and "<=" does not give a valid preprocessing token
/usr/src/boost_1_29_0/boost/python/operators.hpp:198:40: warning: pasting 
"operator" and "==" does not give a valid preprocessing token
/usr/src/boost_1_29_0/boost/python/operators.hpp:199:40: warning: pasting 
"operator" and "!=" does not give a valid preprocessing token
/usr/src/boost_1_29_0/boost/python/operators.hpp:271:38: warning: pasting 
"operator" and "+=" does not give a valid preprocessing token
/usr/src/boost_1_29_0/boost/python/operators.hpp:272:38: warning: pasting 
"operator" and "-=" does not give a valid preprocessing token
/usr/src/boost_1_29_0/boost/python/operators.hpp:273:38: warning: pasting 
"operator" and "*=" does not give a valid preprocessing token
/usr/src/boost_1_29_0/boost/python/operators.hpp:274:38: warning: pasting 
"operator" and "/=" does not give a valid preprocessing token
/usr/src/boost_1_29_0/boost/python/operators.hpp:275:38: warning: pasting 
"operator" and "%=" does not give a valid preprocessing token
/usr/src/boost_1_29_0/boost/python/operators.hpp:276:42: warning: pasting 
"operator" and "<<=" does not give a valid preprocessing token
/usr/src/boost_1_29_0/boost/python/operators.hpp:277:42: warning: pasting 
"operator" and ">>=" does not give a valid preprocessing token
/usr/src/boost_1_29_0/boost/python/operators.hpp:278:38: warning: pasting 
"operator" and "&=" does not give a valid preprocessing token
/usr/src/boost_1_29_0/boost/python/operators.hpp:279:38: warning: pasting 
"operator" and "^=" does not give a valid preprocessing token
/usr/src/boost_1_29_0/boost/python/operators.hpp:280:37: warning: pasting 
"operator" and "|=" does not give a valid preprocessing token
In file included from some_file.cpp:53:
 :8: warning: extra tokens at end of #endif directive
In file included from /usr/include/python2.2/Python.h:73,
                 from 
/usr/src/boost_1_29_0/boost/python/detail/wrap_python.hpp:121,
                 from /usr/src/boost_1_29_0/boost/python/handle.hpp:9,
                 from /usr/src/boost_1_29_0/boost/python/args_fwd.hpp:9,
                 from /usr/src/boost_1_29_0/boost/python/args.hpp:9,
                 from /usr/src/boost_1_29_0/boost/python.hpp:9,
                 from some_file.cpp:53:
/usr/include/python2.2/longobject.h:48: warning: ISO C++ does not support 
`long
   long'
/usr/include/python2.2/longobject.h:49: warning: ISO C++ does not support 
`long
   long'
/usr/include/python2.2/longobject.h:50: warning: ISO C++ does not support 
`long
   long'
/usr/include/python2.2/longobject.h:51: warning: ISO C++ does not support 
`long
   long'
In file included from 
/usr/src/boost_1_29_0/boost/type_traits/is_arithmetic.hpp:13,
                 from 
/usr/src/boost_1_29_0/boost/type_traits/is_scalar.hpp:13,
                 from /usr/src/boost_1_29_0/boost/type_traits/is_POD.hpp:14,
                 from 
/usr/src/boost_1_29_0/boost/type_traits/has_trivial_assign.hpp:13,
                 from 
/usr/src/boost_1_29_0/boost/type_traits/has_nothrow_assign.hpp:13,
                 from /usr/src/boost_1_29_0/boost/type_traits.hpp:18,
                 from 
/usr/src/boost_1_29_0/boost/function/function_base.hpp:25,
                 from 
/usr/src/boost_1_29_0/boost/function/function_template.hpp:24,
                 from /usr/src/boost_1_29_0/boost/function/function0.hpp:28,
                 from /usr/src/boost_1_29_0/boost/python/errors.hpp:14,
                 from /usr/src/boost_1_29_0/boost/python/handle.hpp:11,
                 from /usr/src/boost_1_29_0/boost/python/args_fwd.hpp:9,
                 from /usr/src/boost_1_29_0/boost/python/args.hpp:9,
                 from /usr/src/boost_1_29_0/boost/python.hpp:9,
                 from some_file.cpp:53:
/usr/src/boost_1_29_0/boost/type_traits/is_integral.hpp:43: warning: ISO C++
   does not support `long long'
/usr/src/boost_1_29_0/boost/type_traits/is_integral.hpp:43: warning: ISO C++
   does not support `long long'
/usr/src/boost_1_29_0/boost/type_traits/is_integral.hpp:43: warning: ISO C++
   does not support `long long'
/usr/src/boost_1_29_0/boost/type_traits/is_integral.hpp:43: warning: ISO C++
   does not support `long long'
/usr/src/boost_1_29_0/boost/type_traits/is_integral.hpp:44: warning: ISO C++
   does not support `long long'
/usr/src/boost_1_29_0/boost/type_traits/is_integral.hpp:44: warning: ISO C++
   does not support `long long'
/usr/src/boost_1_29_0/boost/type_traits/is_integral.hpp:44: warning: ISO C++
   does not support `long long'
/usr/src/boost_1_29_0/boost/type_traits/is_integral.hpp:44: warning: ISO C++
   does not support `long long'
In file included from 
/usr/src/boost_1_29_0/boost/type_traits/is_enum.hpp:17,
                 from 
/usr/src/boost_1_29_0/boost/type_traits/is_scalar.hpp:14,
                 from /usr/src/boost_1_29_0/boost/type_traits/is_POD.hpp:14,
                 from 
/usr/src/boost_1_29_0/boost/type_traits/has_trivial_assign.hpp:13,
                 from 
/usr/src/boost_1_29_0/boost/type_traits/has_nothrow_assign.hpp:13,
                 from /usr/src/boost_1_29_0/boost/type_traits.hpp:18,
                 from 
/usr/src/boost_1_29_0/boost/function/function_base.hpp:25,
                 from 
/usr/src/boost_1_29_0/boost/function/function_template.hpp:24,
                 from /usr/src/boost_1_29_0/boost/function/function0.hpp:28,
                 from /usr/src/boost_1_29_0/boost/python/errors.hpp:14,
                 from /usr/src/boost_1_29_0/boost/python/handle.hpp:11,
                 from /usr/src/boost_1_29_0/boost/python/args_fwd.hpp:9,
                 from /usr/src/boost_1_29_0/boost/python/args.hpp:9,
                 from /usr/src/boost_1_29_0/boost/python.hpp:9,
                 from some_file.cpp:53:
/usr/src/boost_1_29_0/boost/type_traits/is_convertible.hpp:220: warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/type_traits/is_convertible.hpp:220: warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/type_traits/is_convertible.hpp:220: warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/type_traits/is_convertible.hpp:220: warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/type_traits/is_convertible.hpp:220: warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/type_traits/is_convertible.hpp:220: warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/type_traits/is_convertible.hpp:221: warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/type_traits/is_convertible.hpp:221: warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/type_traits/is_convertible.hpp:221: warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/type_traits/is_convertible.hpp:221: warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/type_traits/is_convertible.hpp:221: warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/type_traits/is_convertible.hpp:221: warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/type_traits/is_convertible.hpp:222: warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/type_traits/is_convertible.hpp:222: warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/type_traits/is_convertible.hpp:222: warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/type_traits/is_convertible.hpp:222: warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/type_traits/is_convertible.hpp:222: warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/type_traits/is_convertible.hpp:222: warning: ISO
   C++ does not support `long long'
In file included from 
/usr/src/boost_1_29_0/boost/python/converter/arg_to_python.hpp:22,
                 from /usr/src/boost_1_29_0/boost/python/call.hpp:14,
                 from /usr/src/boost_1_29_0/boost/python.hpp:14,
                 from some_file.cpp:53:
/usr/src/boost_1_29_0/boost/python/converter/builtin_converters.hpp:97: 
warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/python/converter/builtin_converters.hpp:97: 
warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/python/converter/builtin_converters.hpp:97: 
warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/python/converter/builtin_converters.hpp:97: 
warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/python/converter/builtin_converters.hpp:97: 
warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/python/converter/builtin_converters.hpp:97: 
warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/python/converter/builtin_converters.hpp:98: 
warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/python/converter/builtin_converters.hpp:98: 
warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/python/converter/builtin_converters.hpp:98: 
warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/python/converter/builtin_converters.hpp:98: 
warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/python/converter/builtin_converters.hpp:98: 
warning: ISO
   C++ does not support `long long'
/usr/src/boost_1_29_0/boost/python/converter/builtin_converters.hpp:98: 
warning: ISO
   C++ does not support `long long'
rm -f libsome_file.so.1.0.0 libsome_file.so libsome_file.so.1 
libsome_file.so.1.0
g++ -shared -Wl,-soname,libsome_file.so.1 -o libsome_file.so.1.0.0 
obj/some_file.o   -L"../build/bin-stage" -L"/usr/lib/python2.2/config" 
-lboost_python_debug
ln -s libsome_file.so.1.0.0 libsome_file.so
ln -s libsome_file.so.1.0.0 libsome_file.so.1
ln -s libsome_file.so.1.0.0 libsome_file.so.1.0


-- 
Horms and I discussed this, and we came up with two categories of people:
people who use vim, and people who don't realize that they could be using
vim.
        - Geoff Harrison




From dave at boost-consulting.com  Tue May 20 20:54:34 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 20 May 2003 14:54:34 -0400
Subject: [C++-sig] Re: avoiding long long warning in boost
References: <200305201902.43420.phil@freehackers.org>
Message-ID: <ud6idfnyt.fsf@boost-consulting.com>

Philippe Fremy <phil at freehackers.org> writes:

> 	Hi,
>
> I am trying to build my first python extension with boost. For personal 
> reasons I am using a tmake based makefile instead of the bjam one. But it 
> should not relate to my question.

Sure it does!  The Jamfile doesn't add -pedantic!

> When building my extension, I get tons of warning, some from the long long 
> usage, others being obscure to me.
>
> I was wondering if there is any way to disable the use of long long in 
> boost, so that I don't get all these warnings. There seem to be some macro 
> testing before enabling the use of long long but I am too unfamiliar with 
> boost to understand where I can configure that.
>
> I also welcome any information from the second error.

I strongly suggest you get a version of Boost at least as recent as
1.30.0.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From rwgk at yahoo.com  Tue May 20 21:50:10 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 20 May 2003 12:50:10 -0700 (PDT)
Subject: [C++-sig] avoiding long long warning in boost
In-Reply-To: <200305201902.43420.phil@freehackers.org>
Message-ID: <20030520195010.39122.qmail@web20204.mail.yahoo.com>

--- Philippe Fremy <phil at freehackers.org> wrote:
I agree with David that it would be better to use 1_30_0 if you can.

> /usr/src/boost_1_29_0/boost/python/operators.hpp:184:42: warning: pasting 
> "operator" and "+" does not give a valid preprocessing token

These you can get rid off by removing the ## between operator and op:

Old: operator##op
New: operator op

> /usr/src/boost_1_29_0/boost/type_traits/is_integral.hpp:43: warning: ISO C++
>    does not support `long long'

You could maybe use -Wno-long-long.

I find that -Wall and -pedantic are just giving me a hard time without doing
much good. In general we use "g++ -w" at our place. We rely on EDG-based
compilers (i.e. the Intel compiler) to ensure that our code is clean. The EDG
error messages and warnings are vastly more useful than gcc's.

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From nicodemus at globalite.com.br  Wed May 21 03:40:55 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Tue, 20 May 2003 17:40:55 -0800
Subject: [C++-sig] Re: Tutorial - Techniques
In-Reply-To: <uptmdhmj1.fsf@boost-consulting.com>
References: <3EB586B7.8090108@globalite.com.br> <b952p7$ka$1@main.gmane.org> <u7k8pojyc.fsf@boost-consulting.com> <3EC6E4C5.1090601@globalite.com.br> <u3cjcqqwb.fsf@boost-consulting.com> <3EC9B1F6.4050309@globalite.com.br> <uptmdhmj1.fsf@boost-consulting.com>
Message-ID: <3ECAD927.5060301@globalite.com.br>

David Abrahams wrote:

>Nicodemus <nicodemus at globalite.com.br> writes:
>
>  
>
>>Good idea! I added two new entries,  "How do I create sub-packages
>>using Boost.Python?" and "Compilation takes too much time and eats too
>>much memory! What can I do to make it faster?". Attached is a diff for
>>it.
>>*** original-faq.html	Tue Mar 18 17:49:50 2003
>>--- faq.html	Mon May 19 20:38:47 2003
>>***************
>>*** 57,62 ****
>>--- 57,67 ----
>>  
>>        #ownership
>>+   
>>+       #slow_compilation
>>+       
>>+       #packages 
>>      </dl>
>>    
>>
>
>Somehow that doesn't look like valid HTML.
>  
>
Somehow that doesn't look like the patch that I posted. I will send it 
zipped this time. Mozilla and Netscape have no trouble reading it after 
the patch is applied, btw.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: faq.zip
Type: application/zip
Size: 749 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20030520/c5df84a8/attachment.zip>

From dave at boost-consulting.com  Wed May 21 01:30:59 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 20 May 2003 19:30:59 -0400
Subject: [C++-sig] Re: Tutorial - Techniques
References: <3EB586B7.8090108@globalite.com.br> <b952p7$ka$1@main.gmane.org>
 <u7k8pojyc.fsf@boost-consulting.com> <3EC6E4C5.1090601@globalite.com.br>
 <u3cjcqqwb.fsf@boost-consulting.com> <3EC9B1F6.4050309@globalite.com.br>
 <uptmdhmj1.fsf@boost-consulting.com> <3ECAD927.5060301@globalite.com.br>
Message-ID: <uel2tdwlo.fsf@boost-consulting.com>

Nicodemus <nicodemus at globalite.com.br> writes:

> David Abrahams wrote:
>
>>Nicodemus <nicodemus at globalite.com.br> writes:
>>
>>  
>>>Good idea! I added two new entries,  "How do I create sub-packages
>>>using Boost.Python?" and "Compilation takes too much time and eats too
>>>much memory! What can I do to make it faster?". Attached is a diff for
>>>it.
>>>*** original-faq.html	Tue Mar 18 17:49:50 2003
>>>--- faq.html	Mon May 19 20:38:47 2003
>>>***************
>>>*** 57,62 ****
>>>--- 57,67 ----
>>>         #ownership
>>> +   +       #slow_compilation
>>> +       +       #packages      </dl>
>>>    
>>
>>Somehow that doesn't look like valid HTML.
>>  
> Somehow that doesn't look like the patch that I posted. I will send it
> zipped this time. Mozilla and Netscape have no trouble reading it
> after the patch is applied, btw.

Looks great!  Why don't you apply it?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From rwgk at yahoo.com  Wed May 21 03:43:47 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 20 May 2003 18:43:47 -0700 (PDT)
Subject: [C++-sig] Mac OS 10 success
Message-ID: <20030521014347.13871.qmail@web20205.mail.yahoo.com>

For the records:

Based on the work done earlier by Rene Rivera and Nick Sauter I've been
able to successfully port all our Boost.Python bindings to Mac OS 10.2.
I am using:

  - Python 2.3b1 as a "framework installation"
  - gcc 3.3 compiled from sources
  - Boost 1.30.0 with a few small patches

The Boost patches are attached. Strictly speaking it is probably
"wrong" to simply disable the static assertions in type_with_alignment.hpp,
but all our regression tests pass anyway. The patch for
as_to_python_function.hpp disables another static assertion that is
probably not critical. The patch for wrap_python.hpp is for Python 2.3
compatibility.

Python 2.3b1 was installed with the commands:
  ./configure --enable-framework
  make
  make frameworkinstall

gcc 3.3 was installed with the commands:
  ./configure --prefix=/usr/local/gcc-3.3 --enable-languages=c,c++
  make bootstrap
  make
  make install

This installation does not interfere with the compiler provided
by Apple. We source the following script before compiling:

set path=(/usr/local/gcc-3.3/bin $path)
set addl_libpath=/usr/local/gcc-3.3/lib:/usr/local/gcc-3.3/lib/soft-float
if ( $?DYLD_LIBRARY_PATH ) then
  setenv DYLD_LIBRARY_PATH "$addl_libpath:${DYLD_LIBRARY_PATH}"
else
  setenv DYLD_LIBRARY_PATH "$addl_libpath"
endif
unset addl_libpath

Initially g++ stopped with an Internal Compiler Error while compiling
some of our Boost.Python bindings. A workaround is to first preprocess
the sources using the -E compiler option and redirecting the output to
a new file. Then compile the preprocessed file. In my case this worked
for everything except one file; fortunately that one file compiles the
normal way. Phew.
Here is my little script that does the trick:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/libtbx/libtbx/command_line/mac_os_x_cpp.py?rev=1.1&content-type=text/vnd.viewcvs-markup
Instead of "g++" specify the name of the script; arguments are what
you would normally pass to g++ for compiling.

Linking libboost_python.dylib is a two-step process. Here is how
I do it:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/libtbx/libtbx/command_line/mac_os_x_ld_bpl_dll.csh?rev=1.1&content-type=text/vnd.viewcvs-markup

Linking extension modules is less complicated:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/libtbx/libtbx/command_line/mac_os_x_ld_pyd.csh?rev=1.1&content-type=text/vnd.viewcvs-markup

The last problem I had to deal with was unresolved symbols while
linking certain extension modules (only 3 out of 29). It turned
out that these were the only modules that did not make use of
boost::python::class_. To fix the unresolved symbol errors I
added a dummy class_ instance, e.g.:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/cctbx/sgtbx/boost_python/row_echelon.cpp?rev=1.3&content-type=text/vnd.viewcvs-markup
Look for "dummy"

That's it. Easy!

Well, while writing this I am running a compilation with -O3 instead of
-O0 and evidently the Internal Compiler Errors creep up in different
places. But at least it works with -O0.

Ralf

Index: boost/python/converter/as_to_python_function.hpp
===================================================================
RCS file:
/net/cci/cvs/boost_1_30_0_cci/boost/python/converter/as_to_python_function.hpp,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -r1.1.1.1 -r1.2
27a28
> #if !(defined(__GNUC__) && __GNUC__ == 3 && __GNUC_MINOR__ == 3)
31a33
> #endif
Index: boost/python/detail/wrap_python.hpp
===================================================================
RCS file: /net/cci/cvs/boost_1_30_0_cci/boost/python/detail/wrap_python.hpp,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -r1.1.1.1 -r1.2
160a161,164
> 
> #if defined(PY_LONG_LONG) && !defined(LONG_LONG)
> #define LONG_LONG PY_LONG_LONG
> #endif
Index: boost/type_traits/type_with_alignment.hpp
===================================================================
RCS file:
/net/cci/cvs/boost_1_30_0_cci/boost/type_traits/type_with_alignment.hpp,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -r1.1.1.1 -r1.2
108a109,110
> #if !(defined(__APPLE__) && defined(__MACH__) \
>  && defined(__GNUC__) && __GNUC__ == 3 && __GNUC_MINOR__ == 3)
110a113
> #endif


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From dlp at fractaltechnologies.com  Wed May 21 09:36:51 2003
From: dlp at fractaltechnologies.com (Daniel Paull)
Date: Wed, 21 May 2003 15:36:51 +0800
Subject: [C++-sig] (no subject)
In-Reply-To: <000301c2ab17$73fe2c30$0a01a8c0@fractalgraphics.com.au>
Message-ID: <002e01c31f6b$bf4ea570$0a01a8c0@fractalgraphics.com.au>

Hello,

I've hit a situation somewhat similar to that mentioned in the, "I'm
getting the "attempt to return dangling reference" error. What am I
doing wrong?", section of the FAQ.

The FAQ describes a situation like this:

  period const& get_floating_frequency() const
  {
    return boost::python::call_method<period const&>(
      m_self,"get_floating_frequency");
  }

  class MyClass( ... ):
    def get_floating_frequency( self ):
      return period( 25 )

Clearly, the period C++ object will be destroyed as the returned python
object is garbage collected, as noted in the FAQ.  However, the object
being returned in my case is an attribute of the class.  For example:

class MyClass( ... ):
    def __init__( self ):
	self.period = period( 25 )

  def get_floating_frequency( self ):
    return self.period

By my reckoning this should be safe (so long as I manage the lifetime of
the class instance properly).  However, I still get a ReferenceException
raised.

Looking at the boost.python code I see (in from_python.cpp):

----------------------------------------------------------------------
void* lvalue_result_from_python(
      PyObject* source
      , registration const& converters
      , char const* ref_type)
  {
      handle<> holder(source);
      if (source->ob_refcnt <= 2)
      {
          handle<> msg(
              ::PyString_FromFormat(
                  "Attempt to return dangling %s to object of type: %s"
                  , ref_type
                  , converters.target_type.name()));
          
          PyErr_SetObject(PyExc_ReferenceError, msg.get());

          throw_error_already_set();
      }
      
      void* result = get_lvalue_from_python(source, converters);
      if (!result)
          (throw_no_lvalue_from_python)(source, converters, ref_type);
      return result;
  }  
}
----------------------------------------------------------------------

I'm wondering if the "<= 2" test should be "< 2".  Where does the second
ref come from?

Anyway, the FAQ doesn't offer me a solution to the problem - is there a
preferred method for doing what I want to do?

Thanks,

Daniel Paull





From dlp at fractaltechnologies.com  Wed May 21 09:46:46 2003
From: dlp at fractaltechnologies.com (Daniel Paull)
Date: Wed, 21 May 2003 15:46:46 +0800
Subject: [C++-sig] Dangling Reference Exception dramas
Message-ID: <002f01c31f6d$21419bb0$0a01a8c0@fractalgraphics.com.au>

Apologies for the lack of subject line on my previous post.  This is a
repost of my previous message.

-----Original Message-----
From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org] On
Behalf Of Daniel Paull
Sent: Wednesday, 21 May 2003 3:37 PM
To: c++-sig at python.org
Subject: [C++-sig] (no subject)

Hello,

I've hit a situation somewhat similar to that mentioned in the, "I'm
getting the "attempt to return dangling reference" error. What am I
doing wrong?", section of the FAQ.

The FAQ describes a situation like this:

  period const& get_floating_frequency() const
  {
    return boost::python::call_method<period const&>(
      m_self,"get_floating_frequency");
  }

  class MyClass( ... ):
    def get_floating_frequency( self ):
      return period( 25 )

Clearly, the period C++ object will be destroyed as the returned python
object is garbage collected, as noted in the FAQ.  However, the object
being returned in my case is an attribute of the class.  For example:

class MyClass( ... ):
    def __init__( self ):
	self.period = period( 25 )

  def get_floating_frequency( self ):
    return self.period

By my reckoning this should be safe (so long as I manage the lifetime of
the class instance properly).  However, I still get a ReferenceException
raised.

Looking at the boost.python code I see (in from_python.cpp):

----------------------------------------------------------------------
void* lvalue_result_from_python(
      PyObject* source
      , registration const& converters
      , char const* ref_type)
  {
      handle<> holder(source);
      if (source->ob_refcnt <= 2)
      {
          handle<> msg(
              ::PyString_FromFormat(
                  "Attempt to return dangling %s to object of type: %s"
                  , ref_type
                  , converters.target_type.name()));
          
          PyErr_SetObject(PyExc_ReferenceError, msg.get());

          throw_error_already_set();
      }
      
      void* result = get_lvalue_from_python(source, converters);
      if (!result)
          (throw_no_lvalue_from_python)(source, converters, ref_type);
      return result;
  }  
}
----------------------------------------------------------------------

I'm wondering if the "<= 2" test should be "< 2".  Where does the second
ref come from?

Anyway, the FAQ doesn't offer me a solution to the problem - is there a
preferred method for doing what I want to do?

Thanks,

Daniel Paull



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




From dave at boost-consulting.com  Wed May 21 16:39:06 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 21 May 2003 10:39:06 -0400
Subject: [C++-sig] Re: Dangling Reference Exception dramas
References: <002f01c31f6d$21419bb0$0a01a8c0@fractalgraphics.com.au>
Message-ID: <ud6iccqk5.fsf@boost-consulting.com>

"Daniel Paull" <dlp at fractaltechnologies.com> writes:

> Hello,
>
> I've hit a situation somewhat similar to that mentioned in the, "I'm
> getting the "attempt to return dangling reference" error. What am I
> doing wrong?", section of the FAQ.
>
> The FAQ describes a situation like this:
>
>   period const& get_floating_frequency() const
>   {
>     return boost::python::call_method<period const&>(
>       m_self,"get_floating_frequency");
>   }
>
>   class MyClass( ... ):
>     def get_floating_frequency( self ):
>       return period( 25 )
>
> Clearly, the period C++ object will be destroyed as the returned python
> object is garbage collected, as noted in the FAQ.  However, the object
> being returned in my case is an attribute of the class.  For example:
>
> class MyClass( ... ):
>     def __init__( self ):
> 	self.period = period( 25 )
>
>   def get_floating_frequency( self ):
>     return self.period
>
> By my reckoning this should be safe (so long as I manage the lifetime of
> the class instance properly).  However, I still get a ReferenceException
> raised.

What is the precise code which causes the exception?  Can you post a
reduced test case?

> Looking at the boost.python code I see (in from_python.cpp):
>
> ----------------------------------------------------------------------
> void* lvalue_result_from_python(
>       PyObject* source
>       , registration const& converters
>       , char const* ref_type)
>   {
>       handle<> holder(source);
>       if (source->ob_refcnt <= 2)
>       {
>           handle<> msg(
>               ::PyString_FromFormat(
>                   "Attempt to return dangling %s to object of type: %s"
>                   , ref_type
>                   , converters.target_type.name()));
>           
>           PyErr_SetObject(PyExc_ReferenceError, msg.get());
>
>           throw_error_already_set();
>       }
>       
>       void* result = get_lvalue_from_python(source, converters);
>       if (!result)
>           (throw_no_lvalue_from_python)(source, converters, ref_type);
>       return result;
>   }  
> }
> ----------------------------------------------------------------------
>
> I'm wondering if the "<= 2" test should be "< 2".  Where does the second
> ref come from?

Well, "<=2" was right once upon a time, but I see that I have no
tests for this case in the test suite.  I could try to track this
down, but it would be a lot faster if you'd post the test which
causes the problem.

> Anyway, the FAQ doesn't offer me a solution to the problem - is there a
> preferred method for doing what I want to do?

I can't tell what you want to do until you show me the code ;-)

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From cdn_pride at yahoo.com  Wed May 21 21:19:44 2003
From: cdn_pride at yahoo.com (Fast Bike)
Date: Wed, 21 May 2003 12:19:44 -0700 (PDT)
Subject: [C++-sig] Can't get a simple example with fstream to compile & link
Message-ID: <20030521191944.6512.qmail@web41201.mail.yahoo.com>

I have been trying this for a little while. I can do
simple examples, but when I try to do something a
little more complex I get litany of errors.

For example creating a simple class that uses an
instance of fstream seems to give me trouble.

Example:
class PythonWrapper
{
public:
	PythonWrapper(int id) : { myid = id; };
private:
	int myid;
	std::fstream myfile;
};

BOOST_PYTHON_MODULE(PythonWrapper)
    {
    	using namespace boost::python;
    	
        scope x_class =
        class_<PythonWrapper>("PythonWrapper",
init<int>())

        ;
        
    }

Gives me:
/usr/local/gcc_3.2/bin/g++ -c -DOTL_ODBC_UNIX
-DOTL_STL -DOTL_ANSI_CPP -DOTL_STREAM_POOLING_ON
PrintFileStats/PythonWrapp
er.cpp -I/home/kstrauss/boost/boost_1_30_0
-I/usr/local/python-2.2/include/python2.2
PrintFileStats/PythonWrapper.cpp: In constructor 
   `PythonWrapper::PythonWrapper(int)':
PrintFileStats/PythonWrapper.cpp:21: no base or member
initializers given 
   following ':'
/usr/local/gcc_3.2/include/c++/3.2.2/bits/ios_base.h:
In copy constructor 
   `std::basic_ios<char, std::char_traits<char>
>::basic_ios(const 
   std::basic_ios<char, std::char_traits<char> >&)':
/home/kstrauss/boost/boost_1_30_0/boost/python/object/value_holder.hpp:111:
  instantiated from `boost::python::objects::
value_holder<Held>::value_holder(PyObject*, A0) [with
A0 = boost::reference_wrapper<const PythonWrapper>,
Held = PythonWr
apper]'
/home/kstrauss/boost/boost_1_30_0/boost/python/object/make_instance.hpp:64:
  instantiated from `static Holder* boost::py
thon::objects::make_instance<T,
Holder>::construct(void*, PyObject*,
boost::reference_wrapper<const T>) [with T = PythonW
rapper, Holder =
boost::python::objects::value_holder<PythonWrapper>]'
/home/kstrauss/boost/boost_1_30_0/boost/python/object/make_instance.hpp:38:
  instantiated from `static PyObject* boost::
python::objects::make_instance_impl<T, Holder,
Derived>::execute(Arg&) [with Arg = const
boost::reference_wrapper<const P
ythonWrapper>, T = PythonWrapper, Holder =
boost::python::objects::value_holder<PythonWrapper>,
Derived = boost::python::
objects::make_instance<PythonWrapper,
boost::python::objects::value_holder<PythonWrapper>
>]'
/home/kstrauss/boost/boost_1_30_0/boost/python/object/class_wrapper.hpp:27:
  instantiated from `static PyObject* boost::
python::objects::class_cref_wrapper<Src,
MakeInstance>::convert(const Src&) [with Src =
PythonWrapper, MakeInstance = boo
st::python::objects::make_instance<PythonWrapper,
boost::python::objects::value_holder<PythonWrapper>
>]'
/home/kstrauss/boost/boost_1_30_0/boost/python/converter/as_to_python_function.hpp:31:
  instantiated from `static PyObje
ct* boost::python::converter::as_to_python_function<T,
ToPython>::convert(const void*) [with T =
PythonWrapper, ToPython 
=
boost::python::objects::class_cref_wrapper<PythonWrapper,
boost::python::objects::make_instance<PythonWrapper,
boost::p
ython::objects::value_holder<PythonWrapper> > >]'
/home/kstrauss/boost/boost_1_30_0/boost/python/to_python_converter.hpp:32:
  instantiated from `boost::python::to_python_
converter<T, Conversion>::to_python_converter() [with
T = PythonWrapper, Conversion =
boost::python::objects::class_cref_
wrapper<PythonWrapper,
boost::python::objects::make_instance<PythonWrapper,
boost::python::objects::value_holder<PythonWr
apper> > >]'
/home/kstrauss/boost/boost_1_30_0/boost/python/class.hpp:90:
  instantiated from `void
boost::python::detail::register_cl
ass_to_python(boost::mpl::bool_<true>, SelectHolder,
T*) [with T = PythonWrapper, SelectHolder =
boost::python::objects::
detail::select_value_holder<PythonWrapper,
PythonWrapper>]'
/home/kstrauss/boost/boost_1_30_0/boost/python/class.hpp:478:
  instantiated from `void boost::python::class_<T, X1,
X2, 
X3>::register_() const [with T = PythonWrapper, X1 =
boost::python::detail::not_specified, X2 =
boost::python::detail::no
t_specified, X3 =
boost::python::detail::not_specified]'
/home/kstrauss/boost/boost_1_30_0/boost/python/class.hpp:215:
  instantiated from `boost::python::class_<T, X1, X2,
X3>::
class_(const char*, const
boost::python::init_base<DerivedT>&) [with DerivedT =
boost::python::init<int, boost::mpl::void
_, boost::mpl::void_, boost::mpl::void_,
boost::mpl::void_, boost::mpl::void_,
boost::mpl::void_, boost::mpl::void_, boos
t::mpl::void_, boost::mpl::void_, boost::mpl::void_,
boost::mpl::void_, boost::mpl::void_,
boost::mpl::void_, boost::mpl:
:void_>, T = PythonWrapper, X1 =
boost::python::detail::not_specified, X2 =
boost::python::detail::not_specified, X3 = bo
ost::python::detail::not_specified]'
PrintFileStats/PythonWrapper.cpp:48:   instantiated
from here
/usr/local/gcc_3.2/include/c++/3.2.2/bits/ios_base.h:424:
`
   std::ios_base::ios_base(const std::ios_base&)' is
private
/home/kstrauss/boost/boost_1_30_0/boost/python/object/value_holder.hpp:111:
within
   this context
/usr/local/gcc_3.2/include/c++/3.2.2/streambuf: In
copy constructor 
   `std::basic_filebuf<char, std::char_traits<char>
>::basic_filebuf(const 
   std::basic_filebuf<char, std::char_traits<char>
>&)':
/usr/local/gcc_3.2/include/c++/3.2.2/streambuf:479: `
   std::basic_streambuf<_CharT,
_Traits>::basic_streambuf(const 
   std::basic_streambuf<_CharT, _Traits>&) [with
_CharT = char, _Traits = 
   std::char_traits<char>]' is private
/home/kstrauss/boost/boost_1_30_0/boost/python/object/value_holder.hpp:111:
within
   this context
make: *** [PythonWrapper.o] Error 1

Obviously I'm missing something in the overall concept
here. Anybody willing to give me a hand?

Thx

Karl


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From cdn_pride at yahoo.com  Wed May 21 21:31:35 2003
From: cdn_pride at yahoo.com (Fast Bike)
Date: Wed, 21 May 2003 12:31:35 -0700 (PDT)
Subject: [C++-sig] Can't get a simple example with fstream to compile & link
In-Reply-To: <20030521191944.6512.qmail@web41201.mail.yahoo.com>
Message-ID: <20030521193135.80090.qmail@web41208.mail.yahoo.com>

Opps, I messed up when cutting and pasting my example
out of a larger sample.

The constructor shouldn't start to initialize
variables and should read:

PythonWrapper(int id) { myid = id; };

Sorry!
--- Fast Bike <cdn_pride at yahoo.com> wrote:
> I have been trying this for a little while. I can do
> simple examples, but when I try to do something a
> little more complex I get litany of errors.
> 
> For example creating a simple class that uses an
> instance of fstream seems to give me trouble.
> 
> Example:
> class PythonWrapper
> {
> public:
> 	PythonWrapper(int id) : { myid = id; };
> private:
> 	int myid;
> 	std::fstream myfile;
> };
> 
> BOOST_PYTHON_MODULE(PythonWrapper)
>     {
>     	using namespace boost::python;
>     	
>         scope x_class =
>         class_<PythonWrapper>("PythonWrapper",
> init<int>())
> 
>         ;
>         
>     }
> 
> Gives me:
> /usr/local/gcc_3.2/bin/g++ -c -DOTL_ODBC_UNIX
> -DOTL_STL -DOTL_ANSI_CPP -DOTL_STREAM_POOLING_ON
> PrintFileStats/PythonWrapp
> er.cpp -I/home/kstrauss/boost/boost_1_30_0
> -I/usr/local/python-2.2/include/python2.2
> PrintFileStats/PythonWrapper.cpp: In constructor 
>    `PythonWrapper::PythonWrapper(int)':
> PrintFileStats/PythonWrapper.cpp:21: no base or
> member
> initializers given 
>    following ':'
>
/usr/local/gcc_3.2/include/c++/3.2.2/bits/ios_base.h:
> In copy constructor 
>    `std::basic_ios<char, std::char_traits<char>
> >::basic_ios(const 
>    std::basic_ios<char, std::char_traits<char> >&)':
>
/home/kstrauss/boost/boost_1_30_0/boost/python/object/value_holder.hpp:111:
>   instantiated from `boost::python::objects::
> value_holder<Held>::value_holder(PyObject*, A0)
> [with
> A0 = boost::reference_wrapper<const PythonWrapper>,
> Held = PythonWr
> apper]'
>
/home/kstrauss/boost/boost_1_30_0/boost/python/object/make_instance.hpp:64:
>   instantiated from `static Holder* boost::py
> thon::objects::make_instance<T,
> Holder>::construct(void*, PyObject*,
> boost::reference_wrapper<const T>) [with T = PythonW
> rapper, Holder =
>
boost::python::objects::value_holder<PythonWrapper>]'
>
/home/kstrauss/boost/boost_1_30_0/boost/python/object/make_instance.hpp:38:
>   instantiated from `static PyObject* boost::
> python::objects::make_instance_impl<T, Holder,
> Derived>::execute(Arg&) [with Arg = const
> boost::reference_wrapper<const P
> ythonWrapper>, T = PythonWrapper, Holder =
> boost::python::objects::value_holder<PythonWrapper>,
> Derived = boost::python::
> objects::make_instance<PythonWrapper,
> boost::python::objects::value_holder<PythonWrapper>
> >]'
>
/home/kstrauss/boost/boost_1_30_0/boost/python/object/class_wrapper.hpp:27:
>   instantiated from `static PyObject* boost::
> python::objects::class_cref_wrapper<Src,
> MakeInstance>::convert(const Src&) [with Src =
> PythonWrapper, MakeInstance = boo
> st::python::objects::make_instance<PythonWrapper,
> boost::python::objects::value_holder<PythonWrapper>
> >]'
>
/home/kstrauss/boost/boost_1_30_0/boost/python/converter/as_to_python_function.hpp:31:
>   instantiated from `static PyObje
> ct*
> boost::python::converter::as_to_python_function<T,
> ToPython>::convert(const void*) [with T =
> PythonWrapper, ToPython 
> =
>
boost::python::objects::class_cref_wrapper<PythonWrapper,
> boost::python::objects::make_instance<PythonWrapper,
> boost::p
> ython::objects::value_holder<PythonWrapper> > >]'
>
/home/kstrauss/boost/boost_1_30_0/boost/python/to_python_converter.hpp:32:
>   instantiated from `boost::python::to_python_
> converter<T, Conversion>::to_python_converter()
> [with
> T = PythonWrapper, Conversion =
> boost::python::objects::class_cref_
> wrapper<PythonWrapper,
> boost::python::objects::make_instance<PythonWrapper,
> boost::python::objects::value_holder<PythonWr
> apper> > >]'
>
/home/kstrauss/boost/boost_1_30_0/boost/python/class.hpp:90:
>   instantiated from `void
> boost::python::detail::register_cl
> ass_to_python(boost::mpl::bool_<true>, SelectHolder,
> T*) [with T = PythonWrapper, SelectHolder =
> boost::python::objects::
> detail::select_value_holder<PythonWrapper,
> PythonWrapper>]'
>
/home/kstrauss/boost/boost_1_30_0/boost/python/class.hpp:478:
>   instantiated from `void boost::python::class_<T,
> X1,
> X2, 
> X3>::register_() const [with T = PythonWrapper, X1 =
> boost::python::detail::not_specified, X2 =
> boost::python::detail::no
> t_specified, X3 =
> boost::python::detail::not_specified]'
>
/home/kstrauss/boost/boost_1_30_0/boost/python/class.hpp:215:
>   instantiated from `boost::python::class_<T, X1,
> X2,
> X3>::
> class_(const char*, const
> boost::python::init_base<DerivedT>&) [with DerivedT
> =
> boost::python::init<int, boost::mpl::void
> _, boost::mpl::void_, boost::mpl::void_,
> boost::mpl::void_, boost::mpl::void_,
> boost::mpl::void_, boost::mpl::void_, boos
> t::mpl::void_, boost::mpl::void_, boost::mpl::void_,
> boost::mpl::void_, boost::mpl::void_,
> boost::mpl::void_, boost::mpl:
> :void_>, T = PythonWrapper, X1 =
> boost::python::detail::not_specified, X2 =
> boost::python::detail::not_specified, X3 = bo
> ost::python::detail::not_specified]'
> PrintFileStats/PythonWrapper.cpp:48:   instantiated
> from here
>
/usr/local/gcc_3.2/include/c++/3.2.2/bits/ios_base.h:424:
> `
>    std::ios_base::ios_base(const std::ios_base&)' is
> private
>
/home/kstrauss/boost/boost_1_30_0/boost/python/object/value_holder.hpp:111:
> within
>    this context
> /usr/local/gcc_3.2/include/c++/3.2.2/streambuf: In
> copy constructor 
>    `std::basic_filebuf<char, std::char_traits<char>
> >::basic_filebuf(const 
>    std::basic_filebuf<char, std::char_traits<char>
> >&)':
> /usr/local/gcc_3.2/include/c++/3.2.2/streambuf:479:
> `
>    std::basic_streambuf<_CharT,
> _Traits>::basic_streambuf(const 
>    std::basic_streambuf<_CharT, _Traits>&) [with
> _CharT = char, _Traits = 
>    std::char_traits<char>]' is private
>
/home/kstrauss/boost/boost_1_30_0/boost/python/object/value_holder.hpp:111:
> within
>    this context
> make: *** [PythonWrapper.o] Error 1
> 
> Obviously I'm missing something in the overall
> concept
> here. Anybody willing to give me a hand?
> 
> Thx
> 
> Karl
> 
> 
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo.
> http://search.yahoo.com
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From seefeld at sympatico.ca  Wed May 21 21:35:52 2003
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 21 May 2003 15:35:52 -0400
Subject: [C++-sig] Can't get a simple example with fstream to compile
 & link
References: <20030521191944.6512.qmail@web41201.mail.yahoo.com>
Message-ID: <ff4b68b5985147828304e53d473a8cfc3ecbd768@Orthosoft.ca>

Fast Bike wrote:
> I have been trying this for a little while. I can do
> simple examples, but when I try to do something a
> little more complex I get litany of errors.
> 
> For example creating a simple class that uses an
> instance of fstream seems to give me trouble.
> 
> Example:
> class PythonWrapper
> {
> public:
> 	PythonWrapper(int id) : { myid = id; };

this is syntactically incorrect: you provide ':' but an empty
initializer list. That should read:

         PythonWrapper(int id) : myid(id) {}

> private:
> 	int myid;
> 	std::fstream myfile;
> };
> 
> BOOST_PYTHON_MODULE(PythonWrapper)
>     {
>     	using namespace boost::python;
>     	
>         scope x_class =
>         class_<PythonWrapper>("PythonWrapper",
> init<int>())
> 
>         ;
>         
>     }

the error hints at a problem with the copy constructor. May be the
class_ template requires a copy constructor to be present, but you
don't provide one, and the default (compiler generated) may just
not work, for example because std::fstream is neither copyable nor
assignable.

Regards,
		Stefan




From seefeld at sympatico.ca  Wed May 21 21:37:12 2003
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 21 May 2003 15:37:12 -0400
Subject: [C++-sig] Can't get a simple example with fstream to compile
 & link
References: <20030521193135.80090.qmail@web41208.mail.yahoo.com>
Message-ID: <420f8ab95f85968b2c648486bd4ca31e3ecbd7b7@Orthosoft.ca>

Fast Bike wrote:
> Opps, I messed up when cutting and pasting my example
> out of a larger sample.
> 
> The constructor shouldn't start to initialize
> variables and should read:
> 
> PythonWrapper(int id) { myid = id; };

It's generally preferable to use the initializer list instead of doing
assignment within the constructor body.

Stefan




From dave at boost-consulting.com  Thu May 22 00:21:26 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 21 May 2003 18:21:26 -0400
Subject: [C++-sig] Re: long long unsigned issue...
References: <b8uvp7$kp1$1@main.gmane.org> <uk7d8n8k7.fsf@boost-consulting.com>
 <b91g6e$me8$1@main.gmane.org> <u65oriktt.fsf@boost-consulting.com>
 <b91qci$oc6$1@main.gmane.org> <u1xzfiizj.fsf@boost-consulting.com>
 <b9292b$qru$1@main.gmane.org> <u65orxage.fsf@boost-consulting.com>
 <b96to4$d5$1@main.gmane.org> <uof2g6fhy.fsf@boost-consulting.com>
 <b9747j$vqv$1@main.gmane.org> <ufzns6czx.fsf@boost-consulting.com>
 <b97eg3$sod$1@main.gmane.org> <uvfwo2idm.fsf@boost-consulting.com>
 <b9s7dn$b0$1@main.gmane.org>
Message-ID: <uu1boaql5.fsf@boost-consulting.com>

"Milind Patil" <milind_patil at hotmail.com> writes:

> "David Abrahams" <dave at boost-consulting.com> wrote in message
> news:uvfwo2idm.fsf at boost-consulting.com...
>> "Milind Patil" <milind_patil at hotmail.com> writes:
>>
>> >> This is very strange; do you see any reason that there should be a
>> >> to_python conversion involved here?
>> >
>> > No, I cannot even guess why to_python conversion is needed.
>>
>> Actually, this problem turns out to be difficult to solve. It's going
>> to take me a few days to get to it at least.  Sorry about that.
>>
>> -Dave
>
> Thanks Dave, for taking the time to look into this. Is there some intermediate work-around
> that I can try?

You can try the latest CVS.  I believe I've fixed it.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Thu May 22 00:28:10 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 21 May 2003 18:28:10 -0400
Subject: [C++-sig] Re: make_getter problem
References: <20030520074344.66900.qmail@web20201.mail.yahoo.com>
Message-ID: <ud6icaq9x.fsf@boost-consulting.com>

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

> The code below comiles and works as expected with Boost 1.30.0, but fails to
> compile with the current CVS state (see attached error message) unless the
> add_property line is commented out. What could be wrong?
> Thanks,
>         Ralf
>
> #include <boost/python/module.hpp>
> #include <boost/python/class.hpp>
>
> namespace sandbx { namespace {
>
>   struct trivial
>   {
>     trivial() : value(123) {}
>     double value;
>   };
>
>   void init_module()
>   {
>     using namespace boost::python;
>     class_<trivial>("trivial")
>       .add_property("property", make_getter(&trivial::value,
> return_value_policy<return_by_value>()))
>       .def_readonly("readonly", &trivial::value)
>     ;
>   }
>
> }} // namespace sandbx::<anonymous>
>
> BOOST_PYTHON_MODULE(make_getter)
> {
>   sandbx::init_module();
> }
>

Please try again with the latest CVS.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Thu May 22 00:23:33 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 21 May 2003 18:23:33 -0400
Subject: [C++-sig] Re: no matching function for call
References: <3EC8AC2D.6050607@cirad.fr>
Message-ID: <uof1waqhm.fsf@boost-consulting.com>

Cyril Bonnard <cyril.bonnard at cirad.fr> writes:

> If someone could help me on theses errors.......
>
> 1///
> I just can't explain why the following code (line 17) doesn't work fine:
>
> error is:
> appe_color.cpp: In function `void init_module_appe_color()':
> appe_color.cpp:17: no matching function for call to
> boost::python::class_<Color3, boost::python::detail::not_specified,
> boost::python::detail::not_specified,
> boost::python::detail::not_specified>::def_readonly(const char[6],
> const Color3*)
>

I think this one is fixed now.  Please try the latest CVS.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Thu May 22 00:42:20 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 21 May 2003 18:42:20 -0400
Subject: [C++-sig] Re: Mac OS 10 success
References: <20030521014347.13871.qmail@web20205.mail.yahoo.com>
Message-ID: <u7k8jc46r.fsf@boost-consulting.com>

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

> For the records:
>
> Based on the work done earlier by Rene Rivera and Nick Sauter I've been
> able to successfully port all our Boost.Python bindings to Mac OS
> 10.2.

Cool!

> I am using:
>
>   - Python 2.3b1 as a "framework installation"
>   - gcc 3.3 compiled from sources
>   - Boost 1.30.0 with a few small patches
>
> The Boost patches are attached. Strictly speaking it is probably
> "wrong" to simply disable the static assertions in
> type_with_alignment.hpp, but all our regression tests pass anyway.

Hmm, those things assert that:

    BOOST_STATIC_ASSERT(found >= Align);

The alignment of the result type is at least as great as the alignment sought.

    BOOST_STATIC_ASSERT(found % Align == 0);

The alignment of the result type is a multiple of the alignment
sought.

If it's failing, it means either that our ability to calculate
alignments is completely messed up or that we're allocating data at
an inappropriate alignment.  I guess the latter isn't so bad, as long
as it doesn't crash, but I'd like to know which it is.

Can you describe the case where it's failing?  An instantiation
backtrace might be quite illuminating.

> The patch for as_to_python_function.hpp disables another static
> assertion that is probably not critical. 

It's critical for users.

> The patch for wrap_python.hpp is for Python 2.3 compatibility.
>
> Python 2.3b1 was installed with the commands:
>   ./configure --enable-framework
>   make
>   make frameworkinstall
>
> gcc 3.3 was installed with the commands:
>   ./configure --prefix=/usr/local/gcc-3.3 --enable-languages=c,c++
>   make bootstrap
>   make
>   make install
>
> This installation does not interfere with the compiler provided
> by Apple. We source the following script before compiling:
>
> set path=(/usr/local/gcc-3.3/bin $path)
> set addl_libpath=/usr/local/gcc-3.3/lib:/usr/local/gcc-3.3/lib/soft-float
> if ( $?DYLD_LIBRARY_PATH ) then
>   setenv DYLD_LIBRARY_PATH "$addl_libpath:${DYLD_LIBRARY_PATH}"
> else
>   setenv DYLD_LIBRARY_PATH "$addl_libpath"
> endif
> unset addl_libpath
>
> Initially g++ stopped with an Internal Compiler Error while compiling
> some of our Boost.Python bindings. A workaround is to first preprocess
> the sources using the -E compiler option and redirecting the output to
> a new file. Then compile the preprocessed file. 

Oh, there's no excuse for a bug like that!

> In my case this worked for everything except one file; fortunately
> that one file compiles the normal way. Phew.  Here is my little
> script that does the trick:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/libtbx/libtbx/command_line/mac_os_x_cpp.py?rev=1.1&content-type=text/vnd.viewcvs-markup
> Instead of "g++" specify the name of the script; arguments are what
> you would normally pass to g++ for compiling.

Yikes.  I suppose we might have to build that into Boost.Build.  I
suppose instead you could call this script g++ and put it earlier in
your PATH.

> Linking libboost_python.dylib is a two-step process. Here is how
> I do it:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/libtbx/libtbx/command_line/mac_os_x_ld_bpl_dll.csh?rev=1.1&content-type=text/vnd.viewcvs-markup
>
> Linking extension modules is less complicated:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/libtbx/libtbx/command_line/mac_os_x_ld_pyd.csh?rev=1.1&content-type=text/vnd.viewcvs-markup

This appears to refer to a removed file (?)

> The last problem I had to deal with was unresolved symbols while
> linking certain extension modules (only 3 out of 29). It turned
> out that these were the only modules that did not make use of
> boost::python::class_. To fix the unresolved symbol errors I
> added a dummy class_ instance, e.g.:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/cctbx/sgtbx/boost_python/row_echelon.cpp?rev=1.3&content-type=text/vnd.viewcvs-markup
> Look for "dummy"

Aww, that's awful, too.

> That's it. Easy!

You forgot the smiley.

> Well, while writing this I am running a compilation with -O3 instead of
> -O0 and evidently the Internal Compiler Errors creep up in different
> places. But at least it works with -O0.

You forgot the smiley again.

I don't like the first two patches, which aren't conditional on your
platform.  If you could make that change I wouldn't mind you checking
them in.

Would you like to write up an HTML or Wiki page on what it takes to
get this to work?  We currently have a FAQ answer which says "OSX?
nope!"

> Index: boost/python/converter/as_to_python_function.hpp
> ===================================================================
> RCS file:
> /net/cci/cvs/boost_1_30_0_cci/boost/python/converter/as_to_python_function.hpp,v
> retrieving revision 1.1.1.1
> retrieving revision 1.2
> diff -r1.1.1.1 -r1.2
> 27a28
>> #if !(defined(__GNUC__) && __GNUC__ == 3 && __GNUC_MINOR__ == 3)
> 31a33
>> #endif
> Index: boost/python/detail/wrap_python.hpp
> ===================================================================
> RCS file: /net/cci/cvs/boost_1_30_0_cci/boost/python/detail/wrap_python.hpp,v
> retrieving revision 1.1.1.1
> retrieving revision 1.2
> diff -r1.1.1.1 -r1.2
> 160a161,164
>> 
>> #if defined(PY_LONG_LONG) && !defined(LONG_LONG)
>> #define LONG_LONG PY_LONG_LONG
>> #endif
> Index: boost/type_traits/type_with_alignment.hpp
> ===================================================================
> RCS file:
> /net/cci/cvs/boost_1_30_0_cci/boost/type_traits/type_with_alignment.hpp,v
> retrieving revision 1.1.1.1
> retrieving revision 1.2
> diff -r1.1.1.1 -r1.2
> 108a109,110
>> #if !(defined(__APPLE__) && defined(__MACH__) \
>>  && defined(__GNUC__) && __GNUC__ == 3 && __GNUC_MINOR__ == 3)
> 110a113
>> #endif
>
>
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo.
> http://search.yahoo.com

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Thu May 22 00:27:33 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 21 May 2003 18:27:33 -0400
Subject: [C++-sig] Re: problem using global variable, static variable
References: <20030520074344.66900.qmail@web20201.mail.yahoo.com> <3EC9ED23.9030104@cirad.fr>
Message-ID: <uiss4aqay.fsf@boost-consulting.com>

Cyril Bonnard <cyril.bonnard at cirad.fr> writes:

> i have a problem defining global and static variables: the variable is
> not recognized
>
> this peace of code highlights the problem:
> test.h:
> class color
> {
> public:
>   color() : col(0) {}
>   ~color() {}
>  const static color BLACK;// error
>   //static color YELLOW;     // same error
>   //static int i;            // same error
>   int col;
> };
>
> test.cpp: In function `void init_module_test()':
> test.cpp:14: no matching function for call to
> boost::python::class_<color, boost::python::detail::not_specified,
> boost::python::detail::not_specified,
> boost::python::detail::not_specified>::def_readonly(const char[6],
> const color*)'
> scons: *** [test.os] Error

This should work now.  Please try the latest CVS.

> i try to reproduce this "behaviour" with a global variable using pyste:
>
> class color
> {
> public:
>   color() : col(0) {}
>   ~color() {}
>  //const static color BLACK;// error
>   //static color YELLOW;     // error
>   //static int i;            // error
>   int col;
> };
>
> static color BLACK;
>
> pyste generates code which seems very strange to me:
> BOOST_PYTHON_MODULE(test)
> {
>     class_< color >("color", init<  >())
>         .def(init< const color & >())
>         .def_readwrite("col", &color::col)
>     ;
>
>     def("_GLOBAL__D__home_cbonnard_devlp_AMAPmod_src_GEOM_test.hef3xme",
>     &_GLOBAL__D__home_cbonnard_devlp_AMAPmod_src_GEOM_test.hef3xme);
>     def("_GLOBAL__I__home_cbonnard_devlp_AMAPmod_src_GEOM_test.hp8ylhc",
>     &_GLOBAL__I__home_cbonnard_devlp_AMAPmod_src_GEOM_test.hp8ylhc);

This appears to be a Pyste bug.  It should say:

     scope().attr("BLACK") = BLACK;

> My questions are: how should i proceed to declare and use global and
> static variables? is the above pyste code known? how to resolve the
> problem?

HTH,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Thu May 22 00:59:44 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 21 May 2003 18:59:44 -0400
Subject: [C++-sig] Re: Sporadic access faults in
 boost::python::converter::registry::query()
References: <68FD589C-85FF-11D7-91C4-000A9566DA8A@uti.is> <ullx3oknf.fsf@boost-consulting.com>
Message-ID: <uptmbaotb.fsf@boost-consulting.com>

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

> I've BCC'd people on the compiler and library (because it appears to
> crash in the std::set implementation) teams at Metrowerks; they may
> have some ideas.  

The std library author reminded me that they have an invariants check
in their associative container implementation.  I added code to
Boost.Python which calls the check each time the set is modified in a
debug build.  You might try the latest CVS to see if you learn
anything...

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From rwgk at yahoo.com  Thu May 22 01:52:38 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 21 May 2003 16:52:38 -0700 (PDT)
Subject: [C++-sig] Re: Mac OS 10 success
In-Reply-To: <u7k8jc46r.fsf@boost-consulting.com>
Message-ID: <20030521235238.19403.qmail@web20205.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/libtbx/libtbx/command_line/mac_os_x_ld_pyd.csh?rev=1.1&content-type=text/vnd.viewcvs-markup
> 
> This appears to refer to a removed file (?)

Oh, sorry; I was hoping that the link remains valid because the rev=1.1 is
explicit.

In the meantime I've done some cleanup work. I attach the essential compilation
commands for easy consumption.

Ralf


Note that SCons uses the extension ".os" instead of the usual ".o" for object
files compiled for shared libraries.

Compiling Boost.Python sources:

g++ -fPIC -ftemplate-depth-120 -w -O0 -fno-inline -DBOOST_PYTHON_MAX_BASES=2
-DBOOST_PYTHON_SOURCE -I/net/cci/rwgk/boost_releases/1_30_0/mac/boost
-I/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3 -c -o
boost/libs/python/src/tuple.os
/net/cci/rwgk/boost_releases/1_30_0/mac/boost/libs/python/src/tuple.cpp

Linking libboost_python.dylib (three commands):

ld -dynamic -m -r -d -o libboost_python.lo boost/libs/python/src/numeric.os
boost/libs/python/src/list.os boost/libs/python/src/long.os
boost/libs/python/src/dict.os boost/libs/python/src/tuple.os
boost/libs/python/src/str.os boost/libs/python/src/aix_init_module.os
boost/libs/python/src/converter/from_python.os
boost/libs/python/src/converter/registry.os
boost/libs/python/src/converter/type_id.os boost/libs/python/src/object/enum.os
boost/libs/python/src/object/class.os boost/libs/python/src/object/function.os
boost/libs/python/src/object/inheritance.os
boost/libs/python/src/object/life_support.os
boost/libs/python/src/object/pickle_support.os boost/libs/python/src/errors.os
boost/libs/python/src/module.os
boost/libs/python/src/converter/builtin_converters.os
boost/libs/python/src/converter/arg_to_python_base.os
boost/libs/python/src/object/iterator.os
boost/libs/python/src/object_protocol.os
boost/libs/python/src/object_operators.os

g++ -nostartfiles -Wl,-dylib -ldylib1.o -framework
/Library/Frameworks/Python.framework/Versions/2.3/Python -o
libtbx/libboost_python.dylib libboost_python.lo

rm -f libboost_python.lo

Compiling an extension module:

g++ -fPIC -ftemplate-depth-120 -w -O0 -fno-inline -DBOOST_PYTHON_MAX_BASES=2
-Ilibtbx/include -I/net/cci/rwgk/boost_releases/1_30_0/mac/libtbx/include
-I/net/cci/rwgk/boost_releases/1_30_0/mac/scitbx/include
-I/net/cci/rwgk/boost_releases/1_30_0/mac/boost
-I/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3 -c -o
scitbx/fftpack/boost_python/fftpack_ext.os
/net/cci/rwgk/boost_releases/1_30_0/mac/scitbx/fftpack/boost_python/fftpack_ext.cpp

Linking an extension module:

g++ -w -bundle /Library/Frameworks/Python.framework/Versions/2.3/Python
-bundle_loader /Library/Frameworks/Python.framework/Versions/2.3/Python -o
libtbx/scitbx_boost/fftpack_ext.so scitbx/fftpack/boost_python/fftpack_ext.os
-Llibtbx -L/net/cci/rwgk/boost_releases/1_30_0/mac/libtbx -lscitbx_boost_python
-lboost_python -lm


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From rwgk at yahoo.com  Thu May 22 02:41:06 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 21 May 2003 17:41:06 -0700 (PDT)
Subject: [C++-sig] Mac OS 10 & type_with_alignment.hpp
In-Reply-To: <u7k8jc46r.fsf@boost-consulting.com>
Message-ID: <20030522004106.61628.qmail@web20208.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> > The Boost patches are attached. Strictly speaking it is probably
> > "wrong" to simply disable the static assertions in
> > type_with_alignment.hpp, but all our regression tests pass anyway.
> 
> Hmm, those things assert that:
> 
>     BOOST_STATIC_ASSERT(found >= Align);
> 
> The alignment of the result type is at least as great as the alignment
> sought.
> 
>     BOOST_STATIC_ASSERT(found % Align == 0);
> 
> The alignment of the result type is a multiple of the alignment
> sought.
> 
> If it's failing, it means either that our ability to calculate
> alignments is completely messed up or that we're allocating data at
> an inappropriate alignment.  I guess the latter isn't so bad, as long
> as it doesn't crash, but I'd like to know which it is.
> 
> Can you describe the case where it's failing?  An instantiation
> backtrace might be quite illuminating.

It's failing while compiling this file (will not be removed any time soon):

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/scitbx/array_family/boost_python/flex_histogram.cpp?rev=1.1&content-type=text/vnd.viewcvs-markup

I put back this (and only this) assertion:

     BOOST_STATIC_ASSERT(found >= Align);

The preprocessor output and the compiler error messages are here:

http://cci.lbl.gov/~rwgk/tmp/fh1.cpp
http://cci.lbl.gov/~rwgk/tmp/fh1.g++_errors

I put back this (and only this) assertion:

     BOOST_STATIC_ASSERT(found % Align == 0);

The preprocessor output and the compiler error messages are here:

http://cci.lbl.gov/~rwgk/tmp/fh2.cpp
http://cci.lbl.gov/~rwgk/tmp/fh2.g++_errors

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From rwgk at yahoo.com  Thu May 22 02:43:15 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 21 May 2003 17:43:15 -0700 (PDT)
Subject: [C++-sig] Re: make_getter problem
In-Reply-To: <ud6icaq9x.fsf@boost-consulting.com>
Message-ID: <20030522004315.80078.qmail@web20207.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> > BOOST_PYTHON_MODULE(make_getter)
> > {
> >   sandbx::init_module();
> > }
> >
> 
> Please try again with the latest CVS.

Yes, it works now! Thanks a lot!
Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From rwgk at yahoo.com  Thu May 22 03:07:24 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 21 May 2003 18:07:24 -0700 (PDT)
Subject: [C++-sig] Re: Mac OS 10 success
In-Reply-To: <u7k8jc46r.fsf@boost-consulting.com>
Message-ID: <20030522010724.82996.qmail@web20207.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> I don't like the first two patches, which aren't conditional on your
> platform.  If you could make that change I wouldn't mind you checking
> them in.

The PY_LONG_LONG patch is already in CVS (in a slightly different form).

Here is the other patch that you don't like:

Index: as_to_python_function.hpp
===================================================================
RCS file:
/cvsroot/boost/boost/boost/python/converter/as_to_python_function.hpp,v
retrieving revision 1.1
diff -u -r1.1 as_to_python_function.hpp
--- as_to_python_function.hpp   2 Dec 2002 01:37:39 -0000       1.1
+++ as_to_python_function.hpp   22 May 2003 01:01:11 -0000
@@ -25,10 +25,12 @@
         
     static PyObject* convert(void const* x)
     {
+#if !(defined(__GNUC__) && __GNUC__ == 3 && __GNUC_MINOR__ == 3)
         BOOST_STATIC_ASSERT(
             sizeof(
                
convert_function_must_take_value_or_const_reference(&ToPython::convert, 1L))
             == sizeof(int));
+#endif
         
         // Yes, the const_cast below opens a hole in const-correctness,
         // but it's needed to convert auto_ptr<U> to python.

The #if is necessary both under Redhat 8 and Mac OS 10. Therefore I am jumping
to the conclusion that gcc 3.3 cannot cope with the code on any platform. Here
is the error message (using Redhat 8 in this case):

/net/cci/rwgk/hot/boost/boost/python/converter/as_to_python_function.hpp:33:
sorry, unimplemented: `
   method_call_expr' not supported by dump_expr

What do you think?

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From dlp at fractaltechnologies.com  Thu May 22 03:43:08 2003
From: dlp at fractaltechnologies.com (Daniel Paull)
Date: Thu, 22 May 2003 09:43:08 +0800
Subject: [C++-sig] Re: Dangling Reference Exception dramas
In-Reply-To: <ud6iccqk5.fsf@boost-consulting.com>
Message-ID: <000101c32003$7f9ecc50$0a01a8c0@fractalgraphics.com.au>

Hi Dave,

I've formulated a test case which shows up the problem.  See the listing
at the end of this post.  Here is what is happening:

1) There is a class Foo which is being exposed to Python with the
intention of being subclassed.
2) A subclass of Foo is passed from Python to C++ via the setFoo()
method.  In my real case this is registry of objects, not just a global
pointer.
3) The getBar() method is called on the Foo returned in (2)

The code as listed below produces the following output:

    Foo()
    Got the Foo object
    hello: <__main__.MyFoo object at 0x0032DDC8>
    ReferenceError: Attempt to return dangling pointer to object of
type: class Bar
    ~Foo()

If you uncomment the line "self.bar_extra_ref = self.bar" in MyFoo's
__init__ method, you get the following output:

    Foo()
    Got the Foo object
    hello: <__main__.MyFoo object at 0x009426F0>
    ~Foo()

This shows that introducing one extra reference to the Bar object stops
the exception from being signalled, hence, the reference count of
self.bar must be 2 in the original listing (as getBar() returns).  It
was this observation that made me think that the "<= 2" check noted in
my original post may be in error.

---------------------------------------
#include <iostream.h>
#include <boost/python.hpp>
using namespace boost::python;

class Bar {};
class Foo
{
public:
	Foo(){ cout << "Foo()" << endl; }
	virtual ~Foo() { cout << "~Foo()" << endl; }
	virtual Bar *getBar() {	return 0; }
	virtual void dump() {}
};

class FooWrapper : public Foo
{
public:
	FooWrapper( PyObject* pSelf ) : m_pSelf( pSelf ) {}
	virtual ~FooWrapper() {}
	virtual Bar *getBar() 
	{
	 return call_method<Bar*>( m_pSelf, "getBar" );
	}
	virtual void dump() 
	{
		call_method<void>( m_pSelf, "dump" );
	}
	PyObject* m_pSelf;
};

// global pointer kludge
static Foo* g_pFoo = 0;
void setFoo( Foo* pFoo ) { g_pFoo = pFoo; }

BOOST_PYTHON_MODULE(hello)
{	
	class_< Bar >( "Bar" );
	class_< Foo, FooWrapper, boost::noncopyable >( "Foo" )
		.def( "getBar", &FooWrapper::getBar,
return_internal_reference<>() )
		.def( "dump", &FooWrapper::dump )
		;
	def( "setFoo", &setFoo );
}

void main( void )
{
	Py_Initialize();
	PyImport_AppendInittab("hello", inithello);
	
	// here we create a subclass of Foo in Python and
	// pass it back to C++ via the setFoo() method
	handle<> main_module(borrowed( PyImport_AddModule("__main__")
));
	handle<> main_namespace(borrowed(
PyModule_GetDict(main_module.get()) ));
	handle<>( PyRun_String(
		"import hello\n"
		"\n"
		"class MyFoo( hello.Foo ):\n"
		"  def __init__( self ):\n"
		"    hello.Foo.__init__( self )\n"
		"    self.bar = hello.Bar()\n"
		"    #self.bar_extra_ref = self.bar"
		"\n"
		"  def getBar( self ):\n"
		"    return self.bar\n"
		"\n"
		"  def dump( self ):\n"
		"    print 'hello: ' + str(self)\n"
		"\n"
		"foo = MyFoo()\n"
		"hello.setFoo( foo )\n",
		Py_file_input, main_namespace.get(),
main_namespace.get()) );

	// now we extract the Bar object from g_foo
	if ( g_pFoo )
	{
		cout << "Got the Foo object" << endl;
		try
		{
			g_pFoo->dump();
			Bar *pBar = g_pFoo->getBar();
		}
		catch( error_already_set )
		{
			PyErr_Print();
		}	
	}

	Py_Finalize();
}
---------------------------------------

> -----Original Message-----
> From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org] On
Behalf
> Of David Abrahams
> Sent: Wednesday, 21 May 2003 10:39 PM
> To: c++-sig at python.org
> Subject: [C++-sig] Re: Dangling Reference Exception dramas
> 
> "Daniel Paull" <dlp at fractaltechnologies.com> writes:
> 
> > Hello,
> >
> > I've hit a situation somewhat similar to that mentioned in the, "I'm
> > getting the "attempt to return dangling reference" error. What am I
> > doing wrong?", section of the FAQ.
> >
> > The FAQ describes a situation like this:
> >
> >   period const& get_floating_frequency() const
> >   {
> >     return boost::python::call_method<period const&>(
> >       m_self,"get_floating_frequency");
> >   }
> >
> >   class MyClass( ... ):
> >     def get_floating_frequency( self ):
> >       return period( 25 )
> >
> > Clearly, the period C++ object will be destroyed as the returned
python
> > object is garbage collected, as noted in the FAQ.  However, the
object
> > being returned in my case is an attribute of the class.  For
example:
> >
> > class MyClass( ... ):
> >     def __init__( self ):
> > 	self.period = period( 25 )
> >
> >   def get_floating_frequency( self ):
> >     return self.period
> >
> > By my reckoning this should be safe (so long as I manage the
lifetime of
> > the class instance properly).  However, I still get a
ReferenceException
> > raised.
> 
> What is the precise code which causes the exception?  Can you post a
> reduced test case?
> 
> > Looking at the boost.python code I see (in from_python.cpp):
> >
> >
----------------------------------------------------------------------
> > void* lvalue_result_from_python(
> >       PyObject* source
> >       , registration const& converters
> >       , char const* ref_type)
> >   {
> >       handle<> holder(source);
> >       if (source->ob_refcnt <= 2)
> >       {
> >           handle<> msg(
> >               ::PyString_FromFormat(
> >                   "Attempt to return dangling %s to object of type:
%s"
> >                   , ref_type
> >                   , converters.target_type.name()));
> >
> >           PyErr_SetObject(PyExc_ReferenceError, msg.get());
> >
> >           throw_error_already_set();
> >       }
> >
> >       void* result = get_lvalue_from_python(source, converters);
> >       if (!result)
> >           (throw_no_lvalue_from_python)(source, converters,
ref_type);
> >       return result;
> >   }
> > }
> >
----------------------------------------------------------------------
> >
> > I'm wondering if the "<= 2" test should be "< 2".  Where does the
second
> > ref come from?
> 
> Well, "<=2" was right once upon a time, but I see that I have no
> tests for this case in the test suite.  I could try to track this
> down, but it would be a lot faster if you'd post the test which
> causes the problem.
> 
> > Anyway, the FAQ doesn't offer me a solution to the problem - is
there a
> > preferred method for doing what I want to do?
> 
> I can't tell what you want to do until you show me the code ;-)
> 
> --
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig




From rwgk at yahoo.com  Thu May 22 03:46:10 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 21 May 2003 18:46:10 -0700 (PDT)
Subject: [C++-sig] Re: Mac OS 10 success
In-Reply-To: <u7k8jc46r.fsf@boost-consulting.com>
Message-ID: <20030522014610.34758.qmail@web20205.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> > Initially g++ stopped with an Internal Compiler Error while compiling
> > some of our Boost.Python bindings. A workaround is to first preprocess
> > the sources using the -E compiler option and redirecting the output to
> > a new file. Then compile the preprocessed file. 
> 
> Oh, there's no excuse for a bug like that!

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10922

>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/cctbx/sgtbx/boost_python/row_echelon.cpp?rev=1.3&content-type=text/vnd.viewcvs-markup
> > Look for "dummy"
> 
> Aww, that's awful, too.

I have seen worse :-)

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From cyril.bonnard at cirad.fr  Thu May 22 09:49:13 2003
From: cyril.bonnard at cirad.fr (Cyril Bonnard)
Date: Thu, 22 May 2003 09:49:13 +0200
Subject: [C++-sig] Re: no matching function for call
References: <3EC8AC2D.6050607@cirad.fr> <uof1waqhm.fsf@boost-consulting.com>
Message-ID: <3ECC80F9.7030307@cirad.fr>

David Abrahams wrote:

>Cyril Bonnard <cyril.bonnard at cirad.fr> writes:
>
>  
>
>>If someone could help me on theses errors.......
>>
>>1///
>>I just can't explain why the following code (line 17) doesn't work fine:
>>
>>error is:
>>appe_color.cpp: In function `void init_module_appe_color()':
>>appe_color.cpp:17: no matching function for call to
>>boost::python::class_<Color3, boost::python::detail::not_specified,
>>boost::python::detail::not_specified,
>>boost::python::detail::not_specified>::def_readonly(const char[6],
>>const Color3*)
>>
>>    
>>
>
>I think this one is fixed now.  Please try the latest CVS.
>
>  
>
i am sorry i've done a cvs update an try it again:
...
 .def_readonly("BLACK", &Color3::BLACK) //line 17
...

appe_color.cpp:17: no matching function for call to 
`boost::python::class_<Color3, boost::python::detail::not_specified, 
boost::python::detail::not_specified, 
boost::python::detail::not_specified>::def_readonly(const char[6], const 
Color3*)'
scons: *** [appe_color.os] Error 1
scons: done building targets.


it doesn't work .....




From camelo at esss.com.br  Thu May 22 15:51:51 2003
From: camelo at esss.com.br (Marcelo A. Camelo)
Date: Thu, 22 May 2003 10:51:51 -0300
Subject: [C++-sig] method_call_expr not supported by dump_expr
In-Reply-To: <3ECC80F9.7030307@cirad.fr>
Message-ID: <002601c32069$4c91e2f0$0d00000a@esss.com.br>

Hi!!!

While porting my code to Linux, I got the following error 
message from GCC 3.3:

	sorry, unimplemented: `
	   method_call_expr' not supported by dump_expr

On win32 I use Intel C++ 7.0, without trouble.

I'm only beginning to search for the offending piece of 
code but, from the archives, I've found that David has 
already faced this problem. So I wonder if him, or anyone
else in the list, can give me hints about what I'm doing
wrong.

Any help is welcome.
 
 

Marcelo A. Camelo, M. Eng. - Project Leader
ESSS - Engineering Simulation and Scientific Software
 
E-mail: camelo at esss.com.br
Phone: +55-48-239-2226
 





From camelo at esss.com.br  Thu May 22 16:04:42 2003
From: camelo at esss.com.br (Marcelo A. Camelo)
Date: Thu, 22 May 2003 11:04:42 -0300
Subject: [C++-sig] method_call_expr not supported by dump_expr
In-Reply-To: <002601c32069$4c91e2f0$0d00000a@esss.com.br>
Message-ID: <002901c3206b$17888bc0$0d00000a@esss.com.br>

Some further information:

I've commented all my source code except 
#include <boost/python.hpp>. The error persists.

The error goes away when I use GCC 3.2.

Can this be a GCC bug or a boost.Python non-conformance?

Cheers,
 

Marcelo A. Camelo, M. Eng. - Project Leader
ESSS - Engineering Simulation and Scientific Software
 
E-mail: camelo at esss.com.br
Phone: +55-48-239-2226

-----Original Message-----
From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org] On
Behalf Of Marcelo A. Camelo
Sent: quinta-feira, 22 de maio de 2003 10:52
To: c++-sig at python.org
Subject: [C++-sig] method_call_expr not supported by dump_expr


Hi!!!

While porting my code to Linux, I got the following error 
message from GCC 3.3:

	sorry, unimplemented: `
	   method_call_expr' not supported by dump_expr

On win32 I use Intel C++ 7.0, without trouble.

I'm only beginning to search for the offending piece of 
code but, from the archives, I've found that David has 
already faced this problem. So I wonder if him, or anyone
else in the list, can give me hints about what I'm doing
wrong.

Any help is welcome.
 
 

Marcelo A. Camelo, M. Eng. - Project Leader
ESSS - Engineering Simulation and Scientific Software
 
E-mail: camelo at esss.com.br
Phone: +55-48-239-2226
 



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




From Paul_Kunz at SLAC.Stanford.EDU  Thu May 22 16:03:20 2003
From: Paul_Kunz at SLAC.Stanford.EDU (Paul F. Kunz)
Date: Thu, 22 May 2003 07:03:20 -0700
Subject: [C++-sig] method_call_expr not supported by dump_expr
In-Reply-To: <002601c32069$4c91e2f0$0d00000a@esss.com.br>
References: <002601c32069$4c91e2f0$0d00000a@esss.com.br>
Message-ID: <200305221403.h4ME3KI10062@libra3.slac.stanford.edu>

>>>>> On Thu, 22 May 2003 10:51:51 -0300, "Marcelo A. Camelo" <camelo at esss.com.br> said:

> Hi!!!  While porting my code to Linux, I got the following error
> message from GCC 3.3:

> 	sorry, unimplemented: ` method_call_expr' not supported by
> dump_expr

> On win32 I use Intel C++ 7.0, without trouble.

> I'm only beginning to search for the offending piece of code but,
> from the archives, I've found that David has already faced this
> problem. So I wonder if him, or anyone else in the list, can give me
> hints about what I'm doing wrong.

   David says it is a GCC 3.3 compiler bug.   Revert to gcc 3.2 or
earlier will get around the problem.   

   The offending line seem to be in
`boost/python/converter/as_to_python_function.hpp'.   I tried
commenting it out and didn't get any ill effects.

    static PyObject* convert(void const* x)
    {
//         BOOST_STATIC_ASSERT(
//             sizeof(
//                 convert_function_must_take_value_or_const_reference(&ToPython::convert, 1L))
//             == sizeof(int));
        



From rlerallut at free.fr  Thu May 22 16:15:02 2003
From: rlerallut at free.fr (Romain Lerallut)
Date: Thu, 22 May 2003 16:15:02 +0200
Subject: [C++-sig] method_call_expr not supported by dump_expr
In-Reply-To: <002601c32069$4c91e2f0$0d00000a@esss.com.br>
References: <002601c32069$4c91e2f0$0d00000a@esss.com.br>
Message-ID: <200305221615.02339.rlerallut@free.fr>

Le Jeudi 22 Mai 2003 15:51, Marcelo A. Camelo a ?crit :
> Hi!!!
>
> While porting my code to Linux, I got the following error
> message from GCC 3.3:
>
> 	sorry, unimplemented: `
> 	   method_call_expr' not supported by dump_expr

It's apparently a bug in gcc 3.3. There's a workaround posted there:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=192481

GCC bug report is there:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10858

HTH,
Romain



From camelo at esss.com.br  Thu May 22 16:24:05 2003
From: camelo at esss.com.br (Marcelo A. Camelo)
Date: Thu, 22 May 2003 11:24:05 -0300
Subject: [C++-sig] method_call_expr not supported by dump_expr
In-Reply-To: <200305221403.h4ME3KI10062@libra3.slac.stanford.edu>
Message-ID: <002a01c3206d$ccc7dc00$0d00000a@esss.com.br>

Paul,

I will try the second route, since I've switched
to GCC 3.3 in the hope of finding that a very weird 
linking problem I've faced in the recent past have 
been discoreded to be a bug and fixed. Or, at least, 
to try to fix my error/workaround the bug in the 
most recent version of the compiler.

[...minutes later...]

I've commented the code, like you suggested and it
compiled just fine. 

David, is it possible to tell if this workaround 
can have undesired side effecs?

Thank you for the help Paul,


Marcelo A. Camelo, M. Eng. - Project Leader
ESSS - Engineering Simulation and Scientific Software
 
E-mail: camelo at esss.com.br
Phone: +55-48-239-2226


-----Original Message-----
From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org] On
Behalf Of Paul F. Kunz
Sent: quinta-feira, 22 de maio de 2003 11:03
To: c++-sig at python.org
Cc: c++-sig at python.org
Subject: Re: [C++-sig] method_call_expr not supported by dump_expr


>>>>> On Thu, 22 May 2003 10:51:51 -0300, "Marcelo A. Camelo" 
>>>>> <camelo at esss.com.br> said:

> Hi!!!  While porting my code to Linux, I got the following error 
> message from GCC 3.3:

> 	sorry, unimplemented: ` method_call_expr' not supported by
dump_expr

> On win32 I use Intel C++ 7.0, without trouble.

> I'm only beginning to search for the offending piece of code but, from

> the archives, I've found that David has already faced this problem. So

> I wonder if him, or anyone else in the list, can give me hints about 
> what I'm doing wrong.

   David says it is a GCC 3.3 compiler bug.   Revert to gcc 3.2 or
earlier will get around the problem.   

   The offending line seem to be in
`boost/python/converter/as_to_python_function.hpp'.   I tried
commenting it out and didn't get any ill effects.

    static PyObject* convert(void const* x)
    {
//         BOOST_STATIC_ASSERT(
//             sizeof(
//
convert_function_must_take_value_or_const_reference(&ToPython::convert,
1L))
//             == sizeof(int));
        

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




From camelo at esss.com.br  Thu May 22 16:40:01 2003
From: camelo at esss.com.br (Marcelo A. Camelo)
Date: Thu, 22 May 2003 11:40:01 -0300
Subject: [C++-sig] method_call_expr not supported by dump_expr
In-Reply-To: <200305221615.02339.rlerallut@free.fr>
Message-ID: <003601c32070$0647f170$0d00000a@esss.com.br>

> There's a workaround posted there:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=192481

Done that. Thank you Romain.

 

Marcelo A. Camelo, M. Eng. - Project Leader
ESSS - Engineering Simulation and Scientific Software
 
E-mail: camelo at esss.com.br
Phone: +55-48-239-2226
 




From dominique.devriese at student.kuleuven.ac.be  Thu May 22 17:00:20 2003
From: dominique.devriese at student.kuleuven.ac.be (Dominique Devriese)
Date: 22 May 2003 17:00:20 +0200
Subject: [C++-sig] method_call_expr not supported by dump_expr
In-Reply-To: <002601c32069$4c91e2f0$0d00000a@esss.com.br>
References: <002601c32069$4c91e2f0$0d00000a@esss.com.br>
Message-ID: <87of1vauwr.fsf@student.kuleuven.ac.be>

Marcelo A Camelo writes:

  Marcelo> Hi!!!  While porting my code to Linux, I got the following
  Marcelo> error message from GCC 3.3:

  Marcelo> 	sorry, unimplemented: `
  Marcelo> 	   method_call_expr' not supported by dump_expr

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10858

it's a gcc 3.3 bug that doesn't allow a function to be called within a
sizeof(), it seems.. 

try downgrading to GCC 3.2, or commenting out the ASSERT call..

cheers
domi

-- 
VI is historically important, if "religiously evil;"
(Christopher Browne on alt.religion.emacs)



From dave at boost-consulting.com  Thu May 22 17:13:13 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 22 May 2003 11:13:13 -0400
Subject: [C++-sig] Re: Dangling Reference Exception dramas
References: <ud6iccqk5.fsf@boost-consulting.com> <000101c32003$7f9ecc50$0a01a8c0@fractalgraphics.com.au>
Message-ID: <u7k8j6mly.fsf@boost-consulting.com>

"Daniel Paull" <dlp at fractaltechnologies.com> writes:

> Hi Dave,
>
> I've formulated a test case which shows up the problem.  See the listing
> at the end of this post.  Here is what is happening:
>
> 1) There is a class Foo which is being exposed to Python with the
> intention of being subclassed.
> 2) A subclass of Foo is passed from Python to C++ via the setFoo()
> method.  In my real case this is registry of objects, not just a global
> pointer.
> 3) The getBar() method is called on the Foo returned in (2)
>
> The code as listed below produces the following output:
>
>     Foo()
>     Got the Foo object
>     hello: <__main__.MyFoo object at 0x0032DDC8>
>     ReferenceError: Attempt to return dangling pointer to object of
> type: class Bar
>     ~Foo()
>
> If you uncomment the line "self.bar_extra_ref = self.bar" in MyFoo's
> __init__ method, you get the following output:
>
>     Foo()
>     Got the Foo object
>     hello: <__main__.MyFoo object at 0x009426F0>
>     ~Foo()
>
> This shows that introducing one extra reference to the Bar object stops
> the exception from being signalled, hence, the reference count of
> self.bar must be 2 in the original listing (as getBar() returns).  It
> was this observation that made me think that the "<= 2" check noted in
> my original post may be in error.

You're right!  Thanks for locating this bug.

In fact, there were tests attempting to check for this, but details
of the way the tests were working, and other code in the system,
conspired to hide the issue.

Your patch was not sufficient to fix it, though.  Before submitting a
patch, it's best if you run all the regression tests first.  The
"callbacks" test fails if we just change "<= 2" to "< 2".

I'll be checking in a fix momentarily.
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Thu May 22 17:22:07 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 22 May 2003 11:22:07 -0400
Subject: [C++-sig] Re: Mac OS 10 & type_with_alignment.hpp
References: <u7k8jc46r.fsf@boost-consulting.com> <20030522004106.61628.qmail@web20208.mail.yahoo.com>
Message-ID: <uel2rgg68.fsf@boost-consulting.com>

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

> It's failing while compiling this file (will not be removed any time soon):
>
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/scitbx/array_family/boost_python/flex_histogram.cpp?rev=1.1&content-type=text/vnd.viewcvs-markup
>
> I put back this (and only this) assertion:
>
>      BOOST_STATIC_ASSERT(found >= Align);
>
> The preprocessor output and the compiler error messages are here:
>
> http://cci.lbl.gov/~rwgk/tmp/fh1.cpp
> http://cci.lbl.gov/~rwgk/tmp/fh1.g++_errors
>
> I put back this (and only this) assertion:
>
>      BOOST_STATIC_ASSERT(found % Align == 0);
>

After passing this through Leor Zolman's STLFilt.pl script to make the
long messages readable (love that script!), I see that it's having a
problem deducing the alignment of your histogram class.

Could you make the following patch to
boost/type_traits/type_with_alignment.hpp just to see what happens?

change:

    class alignment_dummy;
    typedef void (*function_ptr)();
    typedef int (alignment_dummy::*member_ptr);
    typedef int (alignment_dummy::*member_function_ptr)();

    #define BOOST_TT_ALIGNMENT_TYPES BOOST_PP_TUPLE_TO_LIST( \
            11, ( \
            char, short, int, long, float, double, long double \
            , void*, function_ptr, member_ptr, member_function_ptr))

to:

    class alignment_dummy {};
    typedef void (*function_ptr)();
    typedef int (alignment_dummy::*member_ptr);
    typedef int (alignment_dummy::*member_function_ptr)();

    #define BOOST_TT_ALIGNMENT_TYPES BOOST_PP_TUPLE_TO_LIST( \
            11, ( \
            char, short, int, long, float, double, long double \
            , void*, function_ptr, member_ptr, member_function_ptr, alignment_dummy))


[all changes in 1st and last lines]

Thanks!
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Thu May 22 17:32:28 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 22 May 2003 11:32:28 -0400
Subject: [C++-sig] Re: method_call_expr not supported by dump_expr
References: <002601c32069$4c91e2f0$0d00000a@esss.com.br> <002901c3206b$17888bc0$0d00000a@esss.com.br>
Message-ID: <u3cj7gfoz.fsf@boost-consulting.com>

"Marcelo A. Camelo" <camelo at esss.com.br> writes:

> Some further information:
>
> I've commented all my source code except 
> #include <boost/python.hpp>. The error persists.
>
> The error goes away when I use GCC 3.2.
>
> Can this be a GCC bug or a boost.Python non-conformance?

It's a GCC bug.  It's always possible that it was stimulated by a
Boost.Python non-conformance (though unlikely in this case), but that
"sorry, unimplemented" message is essentially an internal assertion
in the compiler.  Compilers should never do that.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From v.rey at laposte.net  Thu May 22 17:22:39 2003
From: v.rey at laposte.net (Vincent Rey)
Date: Thu, 22 May 2003 17:22:39 +0200
Subject: [C++-sig] boost.python compilation with STLport-4.5.3
Message-ID: <baipsf$mjt$1@main.gmane.org>

Boost.Python compiles very well with VC7 stl, but not with STLport-4.5.3.
Already using STLport for other parts of my application, I would like to
compile with it.

It makes about 200 errors, but all related with 'type_info' :
boost_1_30_0\boost\python\detail\msvc_typeinfo.hpp(23) : error C2039:
'type_info' : is not a member of '_STL'



I guess it's a problem of configuration of boost (version 1_30_0)... but I
didn't find anything, nor in stlport forum.

If someone has a clue, thanks to him.







From dave at boost-consulting.com  Thu May 22 17:30:35 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 22 May 2003 11:30:35 -0400
Subject: [C++-sig] Re: Mac OS 10 success
References: <u7k8jc46r.fsf@boost-consulting.com> <20030522010724.82996.qmail@web20207.mail.yahoo.com>
Message-ID: <u8yszgfs4.fsf@boost-consulting.com>

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

> --- David Abrahams <dave at boost-consulting.com> wrote:
>> I don't like the first two patches, which aren't conditional on your
>> platform.  If you could make that change I wouldn't mind you checking
>> them in.
>
> The PY_LONG_LONG patch is already in CVS (in a slightly different form).
>
> Here is the other patch that you don't like:
>
> Index: as_to_python_function.hpp
> ===================================================================
> RCS file:
> /cvsroot/boost/boost/boost/python/converter/as_to_python_function.hpp,v
> retrieving revision 1.1
> diff -u -r1.1 as_to_python_function.hpp
> --- as_to_python_function.hpp   2 Dec 2002 01:37:39 -0000       1.1
> +++ as_to_python_function.hpp   22 May 2003 01:01:11 -0000
> @@ -25,10 +25,12 @@
>          
>      static PyObject* convert(void const* x)
>      {
> +#if !(defined(__GNUC__) && __GNUC__ == 3 && __GNUC_MINOR__ == 3)
>          BOOST_STATIC_ASSERT(
>              sizeof(
>                 
> convert_function_must_take_value_or_const_reference(&ToPython::convert, 1L))
>              == sizeof(int));
> +#endif
>          
>          // Yes, the const_cast below opens a hole in const-correctness,
>          // but it's needed to convert auto_ptr<U> to python.
>
> The #if is necessary both under Redhat 8 and Mac OS 10. Therefore I am jumping
> to the conclusion that gcc 3.3 cannot cope with the code on any platform. Here
> is the error message (using Redhat 8 in this case):
>
> /net/cci/rwgk/hot/boost/boost/python/converter/as_to_python_function.hpp:33:
> sorry, unimplemented: `
>    method_call_expr' not supported by dump_expr
>
> What do you think?

I think that's a silly bug and it should be reported to GNU ;-) 

In fact, the sizeof stuff isn't needed; I was just trying to avoid
some compilation overhead, but that was a shot in the dark.  You can
change both of those
convert_function_must_take_value_or_const_reference overloads to
inline void, give them bodies, and remove the
BOOST_STATIC_ASSERT(sizeof( ... ) == sizeof(int)) wrapper around the
call.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Thu May 22 17:41:03 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 22 May 2003 11:41:03 -0400
Subject: [C++-sig] Re: no matching function for call
References: <3EC8AC2D.6050607@cirad.fr> <uof1waqhm.fsf@boost-consulting.com>
 <3ECC80F9.7030307@cirad.fr>
Message-ID: <uwugjf0q8.fsf@boost-consulting.com>

Cyril Bonnard <cyril.bonnard at cirad.fr> writes:

> David Abrahams wrote:
>
>>Cyril Bonnard <cyril.bonnard at cirad.fr> writes:
>>
>>  
>>>If someone could help me on theses errors.......
>>>
>>>1///
>>>I just can't explain why the following code (line 17) doesn't work fine:
>>>
>>>error is:
>>>appe_color.cpp: In function `void init_module_appe_color()':
>>>appe_color.cpp:17: no matching function for call to
>>>boost::python::class_<Color3, boost::python::detail::not_specified,
>>>boost::python::detail::not_specified,
>>>boost::python::detail::not_specified>::def_readonly(const char[6],
>>>const Color3*)
>>>
>>>    
>>
>>I think this one is fixed now.  Please try the latest CVS.
>>
>>  
> i am sorry i've done a cvs update an try it again:
> ...
>  .def_readonly("BLACK", &Color3::BLACK) //line 17
> ...
>
> appe_color.cpp:17: no matching function for call to
> boost::python::class_<Color3, boost::python::detail::not_specified,
> boost::python::detail::not_specified,
> boost::python::detail::not_specified>::def_readonly(const char[6],
> const Color3*)'
> scons: *** [appe_color.os] Error 1
> scons: done building targets.


Please (always when asking for help) post a small, complete,
reproducible test case which shows what you expect to work and what
you expect the results to be.  Trying to extrapolate from what you've
supplied is not working out for me.  The following compiles with the
current CVS state:

    #include <boost/python.hpp>

    using namespace boost::python;

    struct Color3
    {

      static const Color3 BLACK;
    };

    BOOST_PYTHON_MODULE(foo_ext)
    {
        class_< Color3 >("Color3", init< const Color3 & >())
            .def_readonly("BLACK", &Color3::BLACK)   // line 17
            ;
    }


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Thu May 22 17:42:26 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 22 May 2003 11:42:26 -0400
Subject: [C++-sig] Re: Mac OS 10 success
References: <u7k8jc46r.fsf@boost-consulting.com> <20030521235238.19403.qmail@web20205.mail.yahoo.com>
Message-ID: <ur86rf0nx.fsf@boost-consulting.com>

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

> In the meantime I've done some cleanup work. I attach the essential compilation
> commands for easy consumption.

Thanks, but:

    Would you like to write up an HTML or Wiki page on what it takes to
    get this to work?  We currently have a FAQ answer which says "OSX?
    nope!"

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From rwgk at yahoo.com  Thu May 22 18:35:26 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 22 May 2003 09:35:26 -0700 (PDT)
Subject: [C++-sig] Re: method_call_expr not supported by dump_expr
In-Reply-To: <u3cj7gfoz.fsf@boost-consulting.com>
Message-ID: <20030522163526.45362.qmail@web20203.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> "Marcelo A. Camelo" <camelo at esss.com.br> writes:
> 
> > Some further information:
> >
> > I've commented all my source code except 
> > #include <boost/python.hpp>. The error persists.
> >
> > The error goes away when I use GCC 3.2.
> >
> > Can this be a GCC bug or a boost.Python non-conformance?
> 
> It's a GCC bug.  It's always possible that it was stimulated by a
> Boost.Python non-conformance (though unlikely in this case), but that
> "sorry, unimplemented" message is essentially an internal assertion
> in the compiler.  Compilers should never do that.

Romain's workaround solves this problem. Suggested patch attached. David, do
you want this in CVS?

Index: as_to_python_function.hpp
===================================================================
RCS file:
/cvsroot/boost/boost/boost/python/converter/as_to_python_function.hpp,v
retrieving revision 1.1
diff -u -r1.1 as_to_python_function.hpp
--- as_to_python_function.hpp   2 Dec 2002 01:37:39 -0000       1.1
+++ as_to_python_function.hpp   22 May 2003 16:29:14 -0000
@@ -27,6 +27,9 @@
     {
         BOOST_STATIC_ASSERT(
             sizeof(
+#if defined(__GNUC__) && __GNUC__ == 3 && __GNUC_MINOR__ == 3 &&
__GNU_PATCHLEVEL__ == 0
+                as_to_python_function::
+#endif
                
convert_function_must_take_value_or_const_reference(&ToPython::convert, 1L))
             == sizeof(int));


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From dave at boost-consulting.com  Thu May 22 18:39:56 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 22 May 2003 12:39:56 -0400
Subject: [C++-sig] Re: method_call_expr not supported by dump_expr
References: <u3cj7gfoz.fsf@boost-consulting.com> <20030522163526.45362.qmail@web20203.mail.yahoo.com>
Message-ID: <u4r3ney03.fsf@boost-consulting.com>

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

> --- David Abrahams <dave at boost-consulting.com> wrote:
>> "Marcelo A. Camelo" <camelo at esss.com.br> writes:
>> 
>> > Some further information:
>> >
>> > I've commented all my source code except 
>> > #include <boost/python.hpp>. The error persists.
>> >
>> > The error goes away when I use GCC 3.2.
>> >
>> > Can this be a GCC bug or a boost.Python non-conformance?
>> 
>> It's a GCC bug.  It's always possible that it was stimulated by a
>> Boost.Python non-conformance (though unlikely in this case), but that
>> "sorry, unimplemented" message is essentially an internal assertion
>> in the compiler.  Compilers should never do that.
>
> Romain's workaround solves this problem. Suggested patch attached. David, do
> you want this in CVS?
>
> Index: as_to_python_function.hpp
> ===================================================================
> RCS file:
> /cvsroot/boost/boost/boost/python/converter/as_to_python_function.hpp,v
> retrieving revision 1.1
> diff -u -r1.1 as_to_python_function.hpp
> --- as_to_python_function.hpp   2 Dec 2002 01:37:39 -0000       1.1
> +++ as_to_python_function.hpp   22 May 2003 16:29:14 -0000
> @@ -27,6 +27,9 @@
>      {
>          BOOST_STATIC_ASSERT(
>              sizeof(
> +#if defined(__GNUC__) && __GNUC__ == 3 && __GNUC_MINOR__ == 3 &&
> __GNU_PATCHLEVEL__ == 0
> +                as_to_python_function::
> +#endif

Yes, please.  I sent a different simple suggestion in response to your
"Mac OS 10 success" message which I'd like you to quickly try first.
If it doesn't work out, please go ahead with the above patch.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Thu May 22 18:48:20 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 22 May 2003 12:48:20 -0400
Subject: [C++-sig] Re: boost.python compilation with STLport-4.5.3
References: <baipsf$mjt$1@main.gmane.org>
Message-ID: <uy90zdj1n.fsf@boost-consulting.com>

"Vincent Rey" <v.rey at laposte.net> writes:

> Boost.Python compiles very well with VC7 stl, but not with STLport-4.5.3.
> Already using STLport for other parts of my application, I would like to
> compile with it.
>
> It makes about 200 errors, but all related with 'type_info' :
> boost_1_30_0\boost\python\detail\msvc_typeinfo.hpp(23) : error C2039:
> 'type_info' : is not a member of '_STL'
>
>
>
> I guess it's a problem of configuration of boost (version 1_30_0)... but I
> didn't find anything, nor in stlport forum.

It's a problem with your use of STLPort, IIUC.  I think you're trying
to use the native iostreams instead of the STLPort iostreams.  These
lines in STLPort's <typeinfo.h> should be bringing the misplaced
::typeinfo into namespace _STL, unless you are using a configuration
which doesn't put the stlport components into "std::" (i.e. _STL):

    # if defined  (_STLP_USE_OWN_NAMESPACE) && ! (defined (_STLP_TYPEINFO) && !defined(_STLP_NO_NEW_NEW_HEADER))

    _STLP_BEGIN_NAMESPACE

    using /*_STLP_VENDOR_EXCEPT_STD */ :: type_info;
    # if !(defined(__MRC__) || defined(__SC__))
    using /* _STLP_VENDOR_EXCEPT_STD */ :: bad_typeid;
    # endif
    using /* _STLP_VENDOR_EXCEPT_STD */ :: bad_cast;

    _STLP_END_NAMESPACE

    #endif /* _STLP_OWN_NAMESPACE */


I don't think I'm going to support any such configurations unless
someone can show me that I'm mistaken and STLPort is just failing to
put ::type_info into std:: erroneously.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From rwgk at yahoo.com  Thu May 22 19:00:51 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 22 May 2003 10:00:51 -0700 (PDT)
Subject: [C++-sig] Re: Mac OS 10 & type_with_alignment.hpp
In-Reply-To: <uel2rgg68.fsf@boost-consulting.com>
Message-ID: <20030522170051.51453.qmail@web20204.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> After passing this through Leor Zolman's STLFilt.pl script to make the
> long messages readable (love that script!), I see that it's having a
> problem deducing the alignment of your histogram class.
> 
> Could you make the following patch to
> boost/type_traits/type_with_alignment.hpp just to see what happens?

I also had to replace "11" by "12". My patch relative to the 1.30.0 release is
attached for verification purposes. The compiler still issues the "application
of `sizeof' to an incomplete type" error. The result of passing the error
message through gSTLFilt.pl is available here:

http://cci.lbl.gov/~rwgk/tmp/fh2_2.g++_errors_stlfilt

Ralf

% cvs -q diff -r1.1.1.1
Index: type_with_alignment.hpp
===================================================================
RCS file:
/net/cci/cvs/boost_1_30_0_cci/boost/type_traits/type_with_alignment.hpp,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 type_with_alignment.hpp
36c36
< class alignment_dummy;
---
> class alignment_dummy {};
42c42
<         11, ( \
---
>         12, ( \
44c44
<         , void*, function_ptr, member_ptr, member_function_ptr))
---
>         , void*, function_ptr, member_ptr, member_function_ptr,
alignment_dummy))
108a109,110
> #if !(defined(__APPLE__) && defined(__MACH__) \
>  && defined(__GNUC__) && __GNUC__ == 3 && __GNUC_MINOR__ == 3)
109a112
> #endif


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From rwgk at yahoo.com  Thu May 22 19:10:48 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 22 May 2003 10:10:48 -0700 (PDT)
Subject: [C++-sig] Re: method_call_expr not supported by dump_expr
In-Reply-To: <u4r3ney03.fsf@boost-consulting.com>
Message-ID: <20030522171048.66869.qmail@web20205.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> Yes, please.  I sent a different simple suggestion in response to your
> "Mac OS 10 success" message which I'd like you to quickly try first.
> If it doesn't work out, please go ahead with the above patch.


From rwgk at yahoo.com  Thu May 22 19:21:11 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 22 May 2003 10:21:11 -0700 (PDT)
Subject: [C++-sig] Re: Mac OS 10 success
In-Reply-To: <ur86rf0nx.fsf@boost-consulting.com>
Message-ID: <20030522172111.95670.qmail@web20202.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:
> 
> > In the meantime I've done some cleanup work. I attach the essential
> compilation
> > commands for easy consumption.
> 
> Thanks, but:
> 
>     Would you like to write up an HTML or Wiki page on what it takes to
>     get this to work?  We currently have a FAQ answer which says "OSX?
>     nope!"

One thing at a time.

1. When using -O3 almost all my extensions abort with a segmentation fault or
bus error (but they all work with -O0). I'd really like to know if the
type_with_alignment problems cause the crashes.

2. I think it would be best if you or Rene could modify the darwin toolset to
make it work for Boost.Python. Then we wouldn't have to post the compiler and
linker commands, people could just try it out and refer to the bjam output.

3. I could add an entry to the FAQ explaining how to work around the
"unresolved symbols" problem (using class_<dummy>).

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From grafik666 at redshift-software.com  Thu May 22 21:33:11 2003
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Thu, 22 May 2003 14:33:11 -0500
Subject: [C++-sig] Re: Mac OS 10 success
In-Reply-To: <20030522172111.95670.qmail@web20202.mail.yahoo.com>
Message-ID: <20030522143313-r01010800-b5bd1c0f-0860-0108@12.100.89.43>

[2003-05-22] Ralf W. Grosse-Kunstleve wrote:

>--- David Abrahams <dave at boost-consulting.com> wrote:
>> "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:
>> 
>> > In the meantime I've done some cleanup work. I attach the essential
>> compilation
>> > commands for easy consumption.
>> 
>> Thanks, but:
>> 
>>     Would you like to write up an HTML or Wiki page on what it takes to
>>     get this to work?  We currently have a FAQ answer which says "OSX?
>>     nope!"
>
>One thing at a time.

[snip]

>2. I think it would be best if you or Rene could modify the darwin toolset
to
>make it work for Boost.Python. Then we wouldn't have to post the compiler
and
>linker commands, people could just try it out and refer to the bjam output.

Yes, agreed, but I thought I had done some of this alread to the darwin
toolset. And this is the main reason the darwin toolset exists. Are there
specific differences from what the current toolset does and what is required
for BP that you know of? Otherwise I'll just have to take time to look at
your commands and compare them.


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



From gdoughtie at anim.dreamworks.com  Fri May 23 01:34:42 2003
From: gdoughtie at anim.dreamworks.com (Gavin Doughtie)
Date: Thu, 22 May 2003 16:34:42 -0700
Subject: [C++-sig] exception specifiers and pyste
Message-ID: <3ECD5E92.9020308@anim.dreamworks.com>

So, I turned pyste loose on a C++ header that included "throw 
(AnException)" on a virtual method. Pyste generated a wrapper class that 
implemented a call_method<> implementation of the method, but did not 
automatically include the "throw" declaration, causing compilation of 
the generated C++ to fail with a "looser throw specifier for..." error.

Is this a shortcoming of pyste?

Gavin




From dave at boost-consulting.com  Thu May 22 22:48:39 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 22 May 2003 16:48:39 -0400
Subject: [C++-sig] Re: Mac OS 10 & type_with_alignment.hpp
References: <uel2rgg68.fsf@boost-consulting.com> <20030522170051.51453.qmail@web20204.mail.yahoo.com>
Message-ID: <u65o2pv14.fsf@boost-consulting.com>

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

> --- David Abrahams <dave at boost-consulting.com> wrote:
>> After passing this through Leor Zolman's STLFilt.pl script to make the
>> long messages readable (love that script!), I see that it's having a
>> problem deducing the alignment of your histogram class.
>> 
>> Could you make the following patch to
>> boost/type_traits/type_with_alignment.hpp just to see what happens?
>
> I also had to replace "11" by "12". My patch relative to the 1.30.0 release is
> attached for verification purposes. The compiler still issues the "application
> of `sizeof' to an incomplete type" error. The result of passing the error
> message through gSTLFilt.pl is available here:
>
> http://cci.lbl.gov/~rwgk/tmp/fh2_2.g++_errors_stlfilt
>
> Ralf
>

OK, please undo my suggested patch, and feel free to disable those
asserts on MacOSX :(

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From milind_patil at hotmail.com  Fri May 23 03:59:27 2003
From: milind_patil at hotmail.com (Milind Patil)
Date: Thu, 22 May 2003 18:59:27 -0700
Subject: [C++-sig] Re: long long unsigned issue...
References: <b8uvp7$kp1$1@main.gmane.org> <uk7d8n8k7.fsf@boost-consulting.com> <b91g6e$me8$1@main.gmane.org> <u65oriktt.fsf@boost-consulting.com> <b91qci$oc6$1@main.gmane.org> <u1xzfiizj.fsf@boost-consulting.com> <b9292b$qru$1@main.gmane.org> <u65orxage.fsf@boost-consulting.com> <b96to4$d5$1@main.gmane.org> <uof2g6fhy.fsf@boost-consulting.com> <b9747j$vqv$1@main.gmane.org> <ufzns6czx.fsf@boost-consulting.com> <b97eg3$sod$1@main.gmane.org> <uvfwo2idm.fsf@boost-consulting.com> <b9s7dn$b0$1@main.gmane.org> <uu1boaql5.fsf@boost-consulting.com>
Message-ID: <bajv6b$pe7$1@main.gmane.org>

Thanks Dave. The to_python conversion error has gone away.

I am running accross a different issue now. My assumption was that once
I had a way to convert python long to Y via long_, I should also be able to handle
statements like

x = hello.Y(2, 4294967295)

possibly after adding

implicitly_convertible<int, Y_Wrapper>();

But this does not work. Is my assumption wrong? Any pointers as to
where to look for a solution?

Thanks,
Milind

PS:

Code reproduced here for reference:

class Y {
  public:
    Y() : y(0L) { }
    Y(int y) : y(y) { }
    Y(long long unsigned int y) : y(y) { }
    Y(int s, const Y & y) : y(y << s) { }
    Y(Y const& rhs) : y(rhs.y) { }
    virtual ~Y() { }

    operator int() const { return y; }

    void operator=(Y const& y) {
        this->y = y.y;
    }

    long long unsigned int y;
};

The Wrapped boost part (hello.cpp):

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

#include <boost/python.hpp>
#include <hello.h>

using namespace boost::python;

namespace {
struct Y_Wrapper: Y {
    Y_Wrapper (PyObject* self_) : Y(), self(self_) {}
    Y_Wrapper (PyObject* self_, int y) : Y(y), self(self_) {}
    Y_Wrapper (PyObject* self_, long long unsigned int y) : Y(y),
self(self_) {}
    Y_Wrapper (PyObject* self_, int s,  const Y& y) : Y(s,y), self(self_) {}
    Y_Wrapper (PyObject* self_, const Y& y) : Y(y), self(self_) {}
    Y_Wrapper (PyObject* self_, boost::python::long_ y) : Y(0), self(self_)
{printf("hello long_");}

    PyObject* self;
};
}

BOOST_PYTHON_MODULE(hello)
{
    class_< Y, Y_Wrapper >("Y", init<  >())
        .def(init< const Y & >())
        .def(init< int, const Y & >())
        .def(init< int >())
        .def(init< long long unsigned int >())
        .def(init< long_ >())
        .def_readwrite("y", &Y::y)
        .def("__int__", &Y::operator int)
    ;

    implicitly_convertible<int, Y>();
    implicitly_convertible<long_, Y_Wrapper>();
}

The python script:

import hello

x = hello.Y(4294967295)
print x.y
z = hello.Y(2, 4294967295)
print z.y






From dave at boost-consulting.com  Thu May 22 22:46:28 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 22 May 2003 16:46:28 -0400
Subject: [C++-sig] Re: method_call_expr not supported by dump_expr
References: <u4r3ney03.fsf@boost-consulting.com> <20030522171048.66869.qmail@web20205.mail.yahoo.com>
Message-ID: <ubrxupv4r.fsf@boost-consulting.com>

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

> --- David Abrahams <dave at boost-consulting.com> wrote:
>> Yes, please.  I sent a different simple suggestion in response to your
>> "Mac OS 10 success" message which I'd like you to quickly try first.
>> If it doesn't work out, please go ahead with the above patch.
>
> From your other message:
>
>> In fact, the sizeof stuff isn't needed; I was just trying to avoid
>> some compilation overhead, but that was a shot in the dark.  You can
>> change both of those
>> convert_function_must_take_value_or_const_reference overloads to
>> inline void, give them bodies, and remove the
>> BOOST_STATIC_ASSERT(sizeof( ... ) == sizeof(int)) wrapper around the
>> call.
>
> I will try this out if you want, but I'd like you to consider that the
> suggested change could cause problems on other platforms

I doubt it.  Everything interesting happens in evaluating the sizeof
expression.  If they're not having problems now, they're not likely
to start.

> , while Romain's fix is
> minimally intrusive and does not change the code seen by compilers other than
> gcc 3.3.
> Your choice: adventurous or conservative?

adventurous.


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From chip at cyan.com  Fri May 23 01:23:10 2003
From: chip at cyan.com (Paul Querna)
Date: Thu, 22 May 2003 16:23:10 -0700
Subject: [C++-sig] linking problems with gcc and embedded python
Message-ID: <20030522232310.M34474@cyan.com>

First off, this code works fine in Windows using VC++ v6. (the pinnacle of all
compilers! (hehe))

This error reproduces in gcc 3.0.2(redhat 7.2) and 3.2.2(redhat 9.0).

We are using boost 1.29.0. Upgrading to the latest CVS would be possible if it
will fix this, but we would prefer not to have to go this route.(pain,
suffering, death... etc)

We are in the process of adding an embedded python interpreter to one of our
server programs.

We have built a boost python shared object that we dynamicly link to in our
servers.  It seems to work fine for other things.

Here are the linking errors we get: (be prepared... its ugly..)

../../../../UnixProjects/Plasma/Apps/plNetGameServer/plNetGameServer.dbg.lib.a(pyPythonMsg.dbg.o)(.gnu.linkonce.t._ZN5boost6python6detail17make_function_auxIM11pyPythonMsgFSsvENS0_21default_call_policiesENS1_16args_from_pythonENS_3mpl5list2ISsRS3_EENS8_5int_cILi0EEEEENS0_3api6objectET_RKT0_RKT1_RKT2_RKSt4pairIPKNS1_7keywordEST_ET3_+0x4d):
In function `boost::python::api::object
boost::python::detail::make_function_aux<std::basic_string<char,
std::char_traits<char>, std::allocator<char> > (pyPythonMsg::*)(),
boost::python::default_call_policies, boost::python::detail::args_from_python,
boost::mpl::list2<std::basic_string<char, std::char_traits<char>,
std::allocator<char> >, pyPythonMsg&>, boost::mpl::int_c<(int)0>
>(std::basic_string<char, std::char_traits<char>, std::allocator<char> >
(pyPythonMsg::*)(), boost::python::default_call_policies const&,
boost::python::detail::args_from_python const&,
boost::mpl::list2<std::basic_string<char, std::char_traits<char>,
std::allocator<char> >, pyPythonMsg&> const&,
std::pair<boost::python::detail::keyword const*,
boost::python::detail::keyword const*> const&, boost::mpl::int_c<(int)0>)':
../../../../../StaticSDKs/XPlatform/boost_1_29_0/boost/function/function_base.hpp:246:
undefined reference to
`boost::python::objects::function_object(boost::function2<_object*, _object*,
_object*, std::allocator<boost::function_base> > const&, unsigned,
std::pair<boost::python::detail::keyword const*,
boost::python::detail::keyword const*> const&)'

../../../../UnixProjects/Plasma/Apps/plNetGameServer/plNetGameServer.dbg.lib.a(pyPythonMsg.dbg.o)(.gnu.linkonce.t._ZN5boost6python6detail17make_function_auxIM11pyPythonMsgFvSsENS0_21default_call_policiesENS1_16args_from_pythonENS_3mpl5list3IvRS3_SsEENS8_5int_cILi0EEEEENS0_3api6objectET_RKT0_RKT1_RKT2_RKSt4pairIPKNS1_7keywordEST_ET3_+0x4d):
In function `boost::python::api::object
boost::python::detail::make_function_aux<void
(pyPythonMsg::*)(std::basic_string<char, std::char_traits<char>,
std::allocator<char> >), boost::python::default_call_policies,
boost::python::detail::args_from_python, boost::mpl::list3<void, pyPythonMsg&,
std::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
boost::mpl::int_c<(int)0> >(void (pyPythonMsg::*)(std::basic_string<char,
std::char_traits<char>, std::allocator<char> >),
boost::python::default_call_policies const&,
boost::python::detail::args_from_python const&, boost::mpl::list3<void,
pyPythonMsg&, std::basic_string<char, std::char_traits<char>,
std::allocator<char> > > const&, std::pair<boost::python::detail::keyword
const*, boost::python::detail::keyword const*> const&,
boost::mpl::int_c<(int)0>)':
../../../../../StaticSDKs/XPlatform/boost_1_29_0/boost/function/function_base.hpp:246:
undefined reference to
`boost::python::objects::function_object(boost::function2<_object*, _object*,
_object*, std::allocator<boost::function_base> > const&, unsigned,
std::pair<boost::python::detail::keyword const*,
boost::python::detail::keyword const*> const&)'

../../../../UnixProjects/Plasma/Apps/plNetGameServer/plNetGameServer.dbg.lib.a(pyPythonMsg.dbg.o)(.gnu.linkonce.t._ZN5boost6python6detail17make_function_auxIM11pyPythonMsgFivENS0_21default_call_policiesENS1_16args_from_pythonENS_3mpl5list2IiRS3_EENS8_5int_cILi0EEEEENS0_3api6objectET_RKT0_RKT1_RKT2_RKSt4pairIPKNS1_7keywordEST_ET3_+0x4d):
In function `boost::python::api::object
boost::python::detail::make_function_aux<int (pyPythonMsg::*)(),
boost::python::default_call_policies, boost::python::detail::args_from_python,
boost::mpl::list2<int, pyPythonMsg&>, boost::mpl::int_c<(int)0> >(int
(pyPythonMsg::*)(), boost::python::default_call_policies const&,
boost::python::detail::args_from_python const&, boost::mpl::list2<int,
pyPythonMsg&> const&, std::pair<boost::python::detail::keyword const*,
boost::python::detail::keyword const*> const&, boost::mpl::int_c<(int)0>)':
../../../../../StaticSDKs/XPlatform/boost_1_29_0/boost/function/function_base.hpp:246:
undefined reference to
`boost::python::objects::function_object(boost::function2<_object*, _object*,
_object*, std::allocator<boost::function_base> > const&, unsigned,
std::pair<boost::python::detail::keyword const*,
boost::python::detail::keyword const*> const&)'

../../../../UnixProjects/Plasma/Apps/plNetGameServer/plNetGameServer.dbg.lib.a(pyPythonMsg.dbg.o)(.gnu.linkonce.t._ZN5boost6python6detail17make_function_auxIM11pyPythonMsgFvP5pyKeyENS0_21default_call_policiesENS1_16args_from_pythonENS_3mpl5list3IvRS3_S5_EENSA_5int_cILi0EEEEENS0_3api6objectET_RKT0_RKT1_RKT2_RKSt4pairIPKNS1_7keywordESV_ET3_+0x4d):
In function `boost::python::api::object
boost::python::detail::make_function_aux<void (pyPythonMsg::*)(pyKey*),
boost::python::default_call_policies, boost::python::detail::args_from_python,
boost::mpl::list3<void, pyPythonMsg&, pyKey*>, boost::mpl::int_c<(int)0>
>(void (pyPythonMsg::*)(pyKey*), boost::python::default_call_policies const&,
boost::python::detail::args_from_python const&, boost::mpl::list3<void,
pyPythonMsg&, pyKey*> const&, std::pair<boost::python::detail::keyword const*,
boost::python::detail::keyword const*> const&, boost::mpl::int_c<(int)0>)':
../../../../../StaticSDKs/XPlatform/boost_1_29_0/boost/function/function_base.hpp:246:
undefined reference to
`boost::python::objects::function_object(boost::function2<_object*, _object*,
_object*, std::allocator<boost::function_base> > const&, unsigned,
std::pair<boost::python::detail::keyword const*,
boost::python::detail::keyword const*> const&)'

../../../../UnixProjects/Plasma/Apps/plNetGameServer/plNetGameServer.dbg.lib.a(pyPythonMsg.dbg.o)(.gnu.linkonce.t._ZN5boost6python6detail17make_function_auxIM11pyPythonMsgFviENS0_21default_call_policiesENS1_16args_from_pythonENS_3mpl5list3IvRS3_iEENS8_5int_cILi0EEEEENS0_3api6objectET_RKT0_RKT1_RKT2_RKSt4pairIPKNS1_7keywordEST_ET3_+0x4d):
In function `boost::python::api::object
boost::python::detail::make_function_aux<void (pyPythonMsg::*)(int),
boost::python::default_call_policies, boost::python::detail::args_from_python,
boost::mpl::list3<void, pyPythonMsg&, int>, boost::mpl::int_c<(int)0> >(void
(pyPythonMsg::*)(int), boost::python::default_call_policies const&,
boost::python::detail::args_from_python const&, boost::mpl::list3<void,
pyPythonMsg&, int> const&, std::pair<boost::python::detail::keyword const*,
boost::python::detail::keyword const*> const&, boost::mpl::int_c<(int)0>)':
../../../../../StaticSDKs/XPlatform/boost_1_29_0/boost/function/function_base.hpp:246:
undefined reference to
`boost::python::objects::function_object(boost::function2<_object*, _object*,
_object*, std::allocator<boost::function_base> > const&, unsigned,
std::pair<boost::python::detail::keyword const*,
boost::python::detail::keyword const*> const&)'

../../../../UnixProjects/Plasma/Apps/plNetGameServer/plNetGameServer.dbg.lib.a(pyPythonMsg.dbg.o)(.gnu.linkonce.t._ZN5boost6python6detail17make_function_auxIPFP7_objectRK5pyKeyS7_ENS0_21default_call_policiesENS1_16args_from_pythonENS_3mpl5list3IS4_S7_S7_EENSC_5int_cILi0EEEEENS0_3api6objectET_RKT0_RKT1_RKT2_RKSt4pairIPKNS1_7keywordESW_ET3_+0x3e):../../../../Sources/Plasma/PubUtilLib/plNetCommon/plNetCommon.h:141:
more undefined references to
`boost::python::objects::function_object(boost::function2<_object*, _object*,
_object*, std::allocator<boost::function_base> > const&, unsigned,
std::pair<boost::python::detail::keyword const*,
boost::python::detail::keyword const*> const&)' follow
../../../../UnixProjects/Plasma/Apps/plNetGameServer/plNetGameServer.dbg.lib.a(pyPythonMsg.dbg.o)(.gnu.linkonce.t._ZN5boost6python7objects13make_instanceI5pyKeyNS1_14pointer_holderISt8auto_ptrIS3_ES3_EEE7executeIS6_EEP7_objectRT_+0x11):
In function `_object* boost::python::objects::make_instance<pyKey,
boost::python::objects::pointer_holder<std::auto_ptr<pyKey>, pyKey>
>::execute<std::auto_ptr<pyKey> >(std::auto_ptr<pyKey>&)':
../../../../../StaticSDKs/XPlatform/boost_1_29_0/boost/python/errors.hpp:46:
undefined reference to
`boost::python::converter::registration::get_class_object() const'

../../../../UnixProjects/Plasma/Apps/plNetGameServer/plNetGameServer.dbg.lib.a(pyPythonMsg.dbg.o)(.gnu.linkonce.t._ZN5boost6python7objects13make_instanceI5pyKeyNS1_12value_holderIS3_EEE7executeIKNS_17reference_wrapperIKS3_EEEEP7_objectRT_+0x11):
In function `_object* boost::python::objects::make_instance<pyKey,
boost::python::objects::value_holder<pyKey>
>::execute<boost::reference_wrapper<pyKey const>
const>(boost::reference_wrapper<pyKey const> const&)':
../../../../../StaticSDKs/XPlatform/boost_1_29_0/boost/python/errors.hpp:46:
undefined reference to
`boost::python::converter::registration::get_class_object() const'
../../../../UnixProjects/Plasma/Apps/plNetGameServer/plNetGameServer.dbg.lib.a(pyPythonMsg.dbg.o)(.gnu.linkonce.t._ZN5boost6python7objects13make_instanceI11pyPythonMsgNS1_12value_holderIS3_EEE7executeIKNS_17reference_wrapperIKS3_EEEEP7_objectRT_+0x11):
In function `_object* boost::python::objects::make_instance<pyPythonMsg,
boost::python::objects::value_holder<pyPythonMsg>
>::execute<boost::reference_wrapper<pyPythonMsg const>
const>(boost::reference_wrapper<pyPythonMsg const> const&)':
../../../../../StaticSDKs/XPlatform/boost_1_29_0/boost/python/errors.hpp:46:
undefined reference to
`boost::python::converter::registration::get_class_object() const'


sniplet of part of the offending code:

void pyPythonMsg::PythonModDef()
{
        class_<pyPythonMsg>("ptPythonMsg", init<>())
                .def("getContents",&pyPythonMsg::GetMsgContents)
                .def("setContents",&pyPythonMsg::SetMsgContents)
                .def("getSenderID",&pyPythonMsg::GetSenderID)
               
.def("getKey",&pyPythonMsg::GetKey,return_value_policy<manage_new_object>())
                .def("setKey",&pyPythonMsg::SetKey)
                .def("send",&pyPythonMsg::SendMessage)
        ;
        pyKey::PythonModDef();
}

If the defs are commented out, we do not get these linking errors.  The same
code works great under windows and VC++. The code without the embedded python
interpreter also works under both Windows and Linux.

I have been looking over these errors, but I can't seem to find anything
obvious that would be causing them.  For example, we aren't missing other
boost python functions, the linker seems to find them, but somthing about
these defs are causing the linker to not see the boost functions. We have
tried quote a few variations, recompiled boost a couple times, linked to debug
/nondebug.. etc., but can't seem to find anything that is causing this.

Because of the nature of this server, I cannot release a full copy of its
source for outside developers to test it. Sorry about that.  

Any pointers or possible solutions, no matter how faint of a chance, would be
greatly appreciated.


-chip

Cyan Worlds: http://www.cyanworlds.com
Cyan Worlds Open Source: http://open.cyanworlds.com



From chip at force-elite.com  Fri May 23 06:04:11 2003
From: chip at force-elite.com (chip)
Date: Thu, 22 May 2003 21:04:11 -0700
Subject: [C++-sig] linking problems with gcc and embedded python
Message-ID: <20030523040411.M85456@force-elite.com>

First off, this code works fine in Windows using VC++ v6. (the pinnacle of all
compilers! (hehe))

This error reproduces in gcc 3.0.2(redhat 7.2) and 3.2.2(redhat 9.0).

We are using boost 1.29.0. Upgrading to the latest CVS would be possible if it
will fix this, but we would prefer not to have to go this route.(pain,
suffering, death... etc)

We are in the process of adding an embedded python interpreter to one of our
server programs.

We have built a boost python shared object that we dynamicly link to in our
servers.  It seems to work fine for other things.

Here are the linking errors we get: (be prepared... its ugly..)

../../../../UnixProjects/Plasma/Apps/plNetGameServer/plNetGameServer.dbg.lib.a(pyPythonMsg.dbg.o)(.gnu.linkonce.t._ZN5boost6python6detail17make_function_auxIM11pyPythonMsgFSsvENS0_21default_call_policiesENS1_16args_from_pythonENS_3mpl5list2ISsRS3_EENS8_5int_cILi0EEEEENS0_3api6objectET_RKT0_RKT1_RKT2_RKSt4pairIPKNS1_7keywordEST_ET3_+0x4d):
In function `boost::python::api::object
boost::python::detail::make_function_aux<std::basic_string<char,
std::char_traits<char>, std::allocator<char> > (pyPythonMsg::*)(),
boost::python::default_call_policies, boost::python::detail::args_from_python,
boost::mpl::list2<std::basic_string<char, std::char_traits<char>,
std::allocator<char> >, pyPythonMsg&>, boost::mpl::int_c<(int)0>
>(std::basic_string<char, std::char_traits<char>, std::allocator<char> >
(pyPythonMsg::*)(), boost::python::default_call_policies const&,
boost::python::detail::args_from_python const&,
boost::mpl::list2<std::basic_string<char, std::char_traits<char>,
std::allocator<char> >, pyPythonMsg&> const&,
std::pair<boost::python::detail::keyword const*,
boost::python::detail::keyword const*> const&, boost::mpl::int_c<(int)0>)':
../../../../../StaticSDKs/XPlatform/boost_1_29_0/boost/function/function_base.hpp:246:
undefined reference to
`boost::python::objects::function_object(boost::function2<_object*, _object*,
_object*, std::allocator<boost::function_base> > const&, unsigned,
std::pair<boost::python::detail::keyword const*,
boost::python::detail::keyword const*> const&)'

../../../../UnixProjects/Plasma/Apps/plNetGameServer/plNetGameServer.dbg.lib.a(pyPythonMsg.dbg.o)(.gnu.linkonce.t._ZN5boost6python6detail17make_function_auxIM11pyPythonMsgFvSsENS0_21default_call_policiesENS1_16args_from_pythonENS_3mpl5list3IvRS3_SsEENS8_5int_cILi0EEEEENS0_3api6objectET_RKT0_RKT1_RKT2_RKSt4pairIPKNS1_7keywordEST_ET3_+0x4d):
In function `boost::python::api::object
boost::python::detail::make_function_aux<void
(pyPythonMsg::*)(std::basic_string<char, std::char_traits<char>,
std::allocator<char> >), boost::python::default_call_policies,
boost::python::detail::args_from_python, boost::mpl::list3<void, pyPythonMsg&,
std::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
boost::mpl::int_c<(int)0> >(void (pyPythonMsg::*)(std::basic_string<char,
std::char_traits<char>, std::allocator<char> >),
boost::python::default_call_policies const&,
boost::python::detail::args_from_python const&, boost::mpl::list3<void,
pyPythonMsg&, std::basic_string<char, std::char_traits<char>,
std::allocator<char> > > const&, std::pair<boost::python::detail::keyword
const*, boost::python::detail::keyword const*> const&,
boost::mpl::int_c<(int)0>)':
../../../../../StaticSDKs/XPlatform/boost_1_29_0/boost/function/function_base.hpp:246:
undefined reference to
`boost::python::objects::function_object(boost::function2<_object*, _object*,
_object*, std::allocator<boost::function_base> > const&, unsigned,
std::pair<boost::python::detail::keyword const*,
boost::python::detail::keyword const*> const&)'

../../../../UnixProjects/Plasma/Apps/plNetGameServer/plNetGameServer.dbg.lib.a(pyPythonMsg.dbg.o)(.gnu.linkonce.t._ZN5boost6python6detail17make_function_auxIM11pyPythonMsgFivENS0_21default_call_policiesENS1_16args_from_pythonENS_3mpl5list2IiRS3_EENS8_5int_cILi0EEEEENS0_3api6objectET_RKT0_RKT1_RKT2_RKSt4pairIPKNS1_7keywordEST_ET3_+0x4d):
In function `boost::python::api::object
boost::python::detail::make_function_aux<int (pyPythonMsg::*)(),
boost::python::default_call_policies, boost::python::detail::args_from_python,
boost::mpl::list2<int, pyPythonMsg&>, boost::mpl::int_c<(int)0> >(int
(pyPythonMsg::*)(), boost::python::default_call_policies const&,
boost::python::detail::args_from_python const&, boost::mpl::list2<int,
pyPythonMsg&> const&, std::pair<boost::python::detail::keyword const*,
boost::python::detail::keyword const*> const&, boost::mpl::int_c<(int)0>)':
../../../../../StaticSDKs/XPlatform/boost_1_29_0/boost/function/function_base.hpp:246:
undefined reference to
`boost::python::objects::function_object(boost::function2<_object*, _object*,
_object*, std::allocator<boost::function_base> > const&, unsigned,
std::pair<boost::python::detail::keyword const*,
boost::python::detail::keyword const*> const&)'

../../../../UnixProjects/Plasma/Apps/plNetGameServer/plNetGameServer.dbg.lib.a(pyPythonMsg.dbg.o)(.gnu.linkonce.t._ZN5boost6python6detail17make_function_auxIM11pyPythonMsgFvP5pyKeyENS0_21default_call_policiesENS1_16args_from_pythonENS_3mpl5list3IvRS3_S5_EENSA_5int_cILi0EEEEENS0_3api6objectET_RKT0_RKT1_RKT2_RKSt4pairIPKNS1_7keywordESV_ET3_+0x4d):
In function `boost::python::api::object
boost::python::detail::make_function_aux<void (pyPythonMsg::*)(pyKey*),
boost::python::default_call_policies, boost::python::detail::args_from_python,
boost::mpl::list3<void, pyPythonMsg&, pyKey*>, boost::mpl::int_c<(int)0>
>(void (pyPythonMsg::*)(pyKey*), boost::python::default_call_policies const&,
boost::python::detail::args_from_python const&, boost::mpl::list3<void,
pyPythonMsg&, pyKey*> const&, std::pair<boost::python::detail::keyword const*,
boost::python::detail::keyword const*> const&, boost::mpl::int_c<(int)0>)':
../../../../../StaticSDKs/XPlatform/boost_1_29_0/boost/function/function_base.hpp:246:
undefined reference to
`boost::python::objects::function_object(boost::function2<_object*, _object*,
_object*, std::allocator<boost::function_base> > const&, unsigned,
std::pair<boost::python::detail::keyword const*,
boost::python::detail::keyword const*> const&)'

../../../../UnixProjects/Plasma/Apps/plNetGameServer/plNetGameServer.dbg.lib.a(pyPythonMsg.dbg.o)(.gnu.linkonce.t._ZN5boost6python6detail17make_function_auxIM11pyPythonMsgFviENS0_21default_call_policiesENS1_16args_from_pythonENS_3mpl5list3IvRS3_iEENS8_5int_cILi0EEEEENS0_3api6objectET_RKT0_RKT1_RKT2_RKSt4pairIPKNS1_7keywordEST_ET3_+0x4d):
In function `boost::python::api::object
boost::python::detail::make_function_aux<void (pyPythonMsg::*)(int),
boost::python::default_call_policies, boost::python::detail::args_from_python,
boost::mpl::list3<void, pyPythonMsg&, int>, boost::mpl::int_c<(int)0> >(void
(pyPythonMsg::*)(int), boost::python::default_call_policies const&,
boost::python::detail::args_from_python const&, boost::mpl::list3<void,
pyPythonMsg&, int> const&, std::pair<boost::python::detail::keyword const*,
boost::python::detail::keyword const*> const&, boost::mpl::int_c<(int)0>)':
../../../../../StaticSDKs/XPlatform/boost_1_29_0/boost/function/function_base.hpp:246:
undefined reference to
`boost::python::objects::function_object(boost::function2<_object*, _object*,
_object*, std::allocator<boost::function_base> > const&, unsigned,
std::pair<boost::python::detail::keyword const*,
boost::python::detail::keyword const*> const&)'

../../../../UnixProjects/Plasma/Apps/plNetGameServer/plNetGameServer.dbg.lib.a(pyPythonMsg.dbg.o)(.gnu.linkonce.t._ZN5boost6python6detail17make_function_auxIPFP7_objectRK5pyKeyS7_ENS0_21default_call_policiesENS1_16args_from_pythonENS_3mpl5list3IS4_S7_S7_EENSC_5int_cILi0EEEEENS0_3api6objectET_RKT0_RKT1_RKT2_RKSt4pairIPKNS1_7keywordESW_ET3_+0x3e):../../../../Sources/Plasma/PubUtilLib/plNetCommon/plNetCommon.h:141:
more undefined references to
`boost::python::objects::function_object(boost::function2<_object*, _object*,
_object*, std::allocator<boost::function_base> > const&, unsigned,
std::pair<boost::python::detail::keyword const*,
boost::python::detail::keyword const*> const&)' follow
../../../../UnixProjects/Plasma/Apps/plNetGameServer/plNetGameServer.dbg.lib.a(pyPythonMsg.dbg.o)(.gnu.linkonce.t._ZN5boost6python7objects13make_instanceI5pyKeyNS1_14pointer_holderISt8auto_ptrIS3_ES3_EEE7executeIS6_EEP7_objectRT_+0x11):
In function `_object* boost::python::objects::make_instance<pyKey,
boost::python::objects::pointer_holder<std::auto_ptr<pyKey>, pyKey>
>::execute<std::auto_ptr<pyKey> >(std::auto_ptr<pyKey>&)':
../../../../../StaticSDKs/XPlatform/boost_1_29_0/boost/python/errors.hpp:46:
undefined reference to
`boost::python::converter::registration::get_class_object() const'

../../../../UnixProjects/Plasma/Apps/plNetGameServer/plNetGameServer.dbg.lib.a(pyPythonMsg.dbg.o)(.gnu.linkonce.t._ZN5boost6python7objects13make_instanceI5pyKeyNS1_12value_holderIS3_EEE7executeIKNS_17reference_wrapperIKS3_EEEEP7_objectRT_+0x11):
In function `_object* boost::python::objects::make_instance<pyKey,
boost::python::objects::value_holder<pyKey>
>::execute<boost::reference_wrapper<pyKey const>
const>(boost::reference_wrapper<pyKey const> const&)':
../../../../../StaticSDKs/XPlatform/boost_1_29_0/boost/python/errors.hpp:46:
undefined reference to
`boost::python::converter::registration::get_class_object() const'
../../../../UnixProjects/Plasma/Apps/plNetGameServer/plNetGameServer.dbg.lib.a(pyPythonMsg.dbg.o)(.gnu.linkonce.t._ZN5boost6python7objects13make_instanceI11pyPythonMsgNS1_12value_holderIS3_EEE7executeIKNS_17reference_wrapperIKS3_EEEEP7_objectRT_+0x11):
In function `_object* boost::python::objects::make_instance<pyPythonMsg,
boost::python::objects::value_holder<pyPythonMsg>
>::execute<boost::reference_wrapper<pyPythonMsg const>
const>(boost::reference_wrapper<pyPythonMsg const> const&)':
../../../../../StaticSDKs/XPlatform/boost_1_29_0/boost/python/errors.hpp:46:
undefined reference to
`boost::python::converter::registration::get_class_object() const'

sniplet of part of the offending code:

void pyPythonMsg::PythonModDef()
{
        class_<pyPythonMsg>("ptPythonMsg", init<>())
                .def("getContents",&pyPythonMsg::GetMsgContents)
                .def("setContents",&pyPythonMsg::SetMsgContents)
                .def("getSenderID",&pyPythonMsg::GetSenderID)
               
.def("getKey",&pyPythonMsg::GetKey,return_value_policy<manage_new_object>())
                .def("setKey",&pyPythonMsg::SetKey)
                .def("send",&pyPythonMsg::SendMessage)
        ;
        pyKey::PythonModDef();
}

If the defs are commented out, we do not get these linking errors.  The same
code works great under windows and VC++. The code without the embedded python
interpreter also works under both Windows and Linux.

I have been looking over these errors, but I can't seem to find anything
obvious that would be causing them.  For example, we aren't missing other
boost python functions, the linker seems to find them, but somthing about
these defs are causing the linker to not see the boost functions. We have
tried quote a few variations, recompiled boost a couple times, linked to debug
/nondebug.. etc., but can't seem to find anything that is causing this.

Because of the nature of this server, I cannot release a full copy of its
source for outside developers to test it. Sorry about that.  

Any pointers or possible solutions, no matter how faint of a chance, would be
greatly appreciated.

-chip

Cyan Worlds: http://www.cyanworlds.com
Cyan Worlds Open Source: http://open.cyanworlds.com



From grafik666 at redshift-software.com  Fri May 23 07:26:51 2003
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Fri, 23 May 2003 00:26:51 -0500
Subject: [C++-sig] Re: Mac OS 10 success
In-Reply-To: <20030521235238.19403.qmail@web20205.mail.yahoo.com>
Message-ID: <20030523002652-r01010800-ee5be03c-0860-0108@12.100.89.43>

[2003-05-21] Ralf W. Grosse-Kunstleve wrote:

>--- David Abrahams <dave at boost-consulting.com> wrote:
>>
>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/libtbx/libtbx/command_line/mac_os_x_ld_pyd.csh?rev=1.1&content-type=text/vnd.viewcvs-markup
>> 
>> This appears to refer to a removed file (?)
>
>Oh, sorry; I was hoping that the link remains valid because the rev=1.1 is
>explicit.
>
>In the meantime I've done some cleanup work. I attach the essential
compilation
>commands for easy consumption.
>
>Ralf
>
>
>Note that SCons uses the extension ".os" instead of the usual ".o" for
object
>files compiled for shared libraries.
>
>Compiling Boost.Python sources:

These are the bjam equivalents with the current state of darwin-tools.jam...

### currently called as "c++" not "g++"
>g++
    ### <shared-linkable>true (on for DLL and PYD targets)
>   -fPIC
    ### currently set to -ftemplate-depth-120
>   -ftemplate-depth-120
    ### currently set to -Wall ?
>   -w
    ### <optimization>off
>   -O0
    ### <inlining>off
>   -fno-inline
    ### I presume these are set by the libboost_python target?
>   -DBOOST_PYTHON_MAX_BASES=2
>   -DBOOST_PYTHON_SOURCE
    ### <include>$BOOST_ROOT
>   -I/net/cci/rwgk/boost_releases/1_30_0/mac/boost
    ### <include>/Library/Frameworks... (It seems that python.jam would need
to change to look here when the correspoding PYTHON_VERSION is set. That is
setting the PYTHON_ROOT to
"/Library/Frameworks/Python.framework/Versions/$(PYTHON_VERSION)" )
>   -I/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3
>   -c
>   -o boost/libs/python/src/tuple.os
>   /net/cci/rwgk/boost_releases/1_30_0/mac/boost/libs/python/src/tuple.cpp

>Linking libboost_python.dylib (three commands):

    ### I'm fairly sure there are additional library path seetings here?
    
    ### Yea, that's just what the DLL target does, except for...
    
>ld -dynamic -m -r -d -o libboost_python.lo boost/libs/python/src/numeric.os
>boost/libs/python/src/list.os boost/libs/python/src/long.os
>boost/libs/python/src/dict.os boost/libs/python/src/tuple.os
>boost/libs/python/src/str.os boost/libs/python/src/aix_init_module.os
>boost/libs/python/src/converter/from_python.os
>boost/libs/python/src/converter/registry.os
>boost/libs/python/src/converter/type_id.os
boost/libs/python/src/object/enum.os
>boost/libs/python/src/object/class.os
boost/libs/python/src/object/function.os
>boost/libs/python/src/object/inheritance.os
>boost/libs/python/src/object/life_support.os
>boost/libs/python/src/object/pickle_support.os
boost/libs/python/src/errors.os
>boost/libs/python/src/module.os
>boost/libs/python/src/converter/builtin_converters.os
>boost/libs/python/src/converter/arg_to_python_base.os
>boost/libs/python/src/object/iterator.os
>boost/libs/python/src/object_protocol.os
>boost/libs/python/src/object_operators.os
>
>g++ -nostartfiles -Wl,-dylib -ldylib1.o

    ### <framework>/Library/Frameworks/... (this is currently put in as
<framework>Python, is that enough? Or is the complete path-spec needed?)

>   -framework /Library/Frameworks/Python.framework/Versions/2.3/Python

>-o libtbx/libboost_python.dylib libboost_python.lo
>
>rm -f libboost_python.lo
>
>Compiling an extension module:

    ### Same as the previous comments.

>g++ -fPIC -ftemplate-depth-120 -w -O0 -fno-inline
-DBOOST_PYTHON_MAX_BASES=2
>-Ilibtbx/include -I/net/cci/rwgk/boost_releases/1_30_0/mac/libtbx/include
>-I/net/cci/rwgk/boost_releases/1_30_0/mac/scitbx/include
>-I/net/cci/rwgk/boost_releases/1_30_0/mac/boost
>-I/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3 -c -o
>scitbx/fftpack/boost_python/fftpack_ext.os
>/net/cci/rwgk/boost_releases/1_30_0/mac/scitbx/fftpack/boost_python/fftpack_ext.cpp
>
>Linking an extension module:
>
>g++ -w

    ### I thought -bundle didn't take a value? (Currently only -bundle is
added)

> -bundle /Library/Frameworks/Python.framework/Versions/2.3/Python

    ### <bundle-loader>... (Currently this is added by python.jam as
<bundle-loader>$(PYTHON_ROOT)/bin/python$(PYTHON_VERSION) when building PYD
targets)

>-bundle_loader /Library/Frameworks/Python.framework/Versions/2.3/Python -o
>libtbx/scitbx_boost/fftpack_ext.so
scitbx/fftpack/boost_python/fftpack_ext.os
>-Llibtbx -L/net/cci/rwgk/boost_releases/1_30_0/mac/libtbx
-lscitbx_boost_python
>-lboost_python -lm

So as far as I can see the only changes needed are in python.jam, and
possibly the "-bundle" option in the toolset.

Dave, do you think my comments are enough for you to do the changes? I could
try and do them and post a patch. I'm not about to touch CVS on this one as
it really requires other eyes than mine :-)


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



From dimour at mail.ru  Fri May 23 08:59:12 2003
From: dimour at mail.ru (Dmitri Mouromtsev)
Date: Fri, 23 May 2003 10:59:12 +0400
Subject: [C++-sig] call PyInstance_New with parameters
Message-ID: <001701c320f8$d0fc9be0$7300a8c0@dima>

Hello,

I need to call python obect constructor with parameter(s), for instance:
class MyObj:

    def __init__(self, name):

        self.__name__ = name


How can I do it with PyInstance_New(), what should be as  *arg, *kw
parameters in this function?

Thanks

Dmitri





From cyril.bonnard at cirad.fr  Fri May 23 09:04:10 2003
From: cyril.bonnard at cirad.fr (Cyril Bonnard)
Date: Fri, 23 May 2003 09:04:10 +0200
Subject: [C++-sig] Re: no matching function for call
References: <3EC8AC2D.6050607@cirad.fr> <uof1waqhm.fsf@boost-consulting.com> <3ECC80F9.7030307@cirad.fr> <uwugjf0q8.fsf@boost-consulting.com>
Message-ID: <3ECDC7EA.5080103@cirad.fr>

David Abrahams wrote:

>Cyril Bonnard <cyril.bonnard at cirad.fr> writes:
>
>  
>
>>David Abrahams wrote:
>>
>>    
>>
>>>Cyril Bonnard <cyril.bonnard at cirad.fr> writes:
>>>
>>> 
>>>      
>>>
>>>>If someone could help me on theses errors.......
>>>>
>>>>1///
>>>>I just can't explain why the following code (line 17) doesn't work fine:
>>>>
>>>>error is:
>>>>appe_color.cpp: In function `void init_module_appe_color()':
>>>>appe_color.cpp:17: no matching function for call to
>>>>boost::python::class_<Color3, boost::python::detail::not_specified,
>>>>boost::python::detail::not_specified,
>>>>boost::python::detail::not_specified>::def_readonly(const char[6],
>>>>const Color3*)
>>>>
>>>>   
>>>>        
>>>>
>>>I think this one is fixed now.  Please try the latest CVS.
>>>
>>> 
>>>      
>>>
>>i am sorry i've done a cvs update an try it again:
>>...
>> .def_readonly("BLACK", &Color3::BLACK) //line 17
>>...
>>
>>appe_color.cpp:17: no matching function for call to
>>boost::python::class_<Color3, boost::python::detail::not_specified,
>>boost::python::detail::not_specified,
>>boost::python::detail::not_specified>::def_readonly(const char[6],
>>const Color3*)'
>>scons: *** [appe_color.os] Error 1
>>scons: done building targets.
>>    
>>
>
>
>Please (always when asking for help) post a small, complete,
>reproducible test case which shows what you expect to work and what
>you expect the results to be.  Trying to extrapolate from what you've
>supplied is not working out for me.  The following compiles with the
>current CVS state:
>
>    #include <boost/python.hpp>
>
>    using namespace boost::python;
>
>    struct Color3
>    {
>
>      static const Color3 BLACK;
>    };
>
>    BOOST_PYTHON_MODULE(foo_ext)
>    {
>        class_< Color3 >("Color3", init< const Color3 & >())
>            .def_readonly("BLACK", &Color3::BLACK)   // line 17
>            ;
>    }
>
>
>  
>
it's ok for me too (i try an other update). I will follow your advices 
for future ;)





From v.rey at laposte.net  Fri May 23 11:51:36 2003
From: v.rey at laposte.net (Vincent Rey)
Date: Fri, 23 May 2003 11:51:36 +0200
Subject: [C++-sig] Re: boost.python compilation with STLport-4.5.3
References: <baipsf$mjt$1@main.gmane.org> <uy90zdj1n.fsf@boost-consulting.com>
Message-ID: <bakqrm$rqu$1@main.gmane.org>

First, thank you for your answer.
I downloaded the last beta version (4.5-0119) and found this fix in typeinfo
file :

# if defined(_STLP_MSVC) && (_STLP_MSVC >= 1300)
// In .NET, <typeinfo> actually includes <typeinfo.h>
#  undef _STLP_OLDSTD_typeinfo
# endif

With this version, it nearly compiled :
I had just 2 errors left, strcmp and fprintf not members of _STL.
It finally compiled defining BOOST_MSVC_STD_ITERATOR.


"David Abrahams" <dave at boost-consulting.com> wrote in message
news:uy90zdj1n.fsf at boost-consulting.com...
> "Vincent Rey" <v.rey at laposte.net> writes:
>
> > Boost.Python compiles very well with VC7 stl, but not with
STLport-4.5.3.
> > Already using STLport for other parts of my application, I would like to
> > compile with it.
> >
> > It makes about 200 errors, but all related with 'type_info' :
> > boost_1_30_0\boost\python\detail\msvc_typeinfo.hpp(23) : error C2039:
> > 'type_info' : is not a member of '_STL'
> >
> >
> >
> > I guess it's a problem of configuration of boost (version 1_30_0)... but
I
> > didn't find anything, nor in stlport forum.
>
> It's a problem with your use of STLPort, IIUC.  I think you're trying
> to use the native iostreams instead of the STLPort iostreams.  These
> lines in STLPort's <typeinfo.h> should be bringing the misplaced
> ::typeinfo into namespace _STL, unless you are using a configuration
> which doesn't put the stlport components into "std::" (i.e. _STL):
>
>     # if defined  (_STLP_USE_OWN_NAMESPACE) && ! (defined (_STLP_TYPEINFO)
&& !defined(_STLP_NO_NEW_NEW_HEADER))
>
>     _STLP_BEGIN_NAMESPACE
>
>     using /*_STLP_VENDOR_EXCEPT_STD */ :: type_info;
>     # if !(defined(__MRC__) || defined(__SC__))
>     using /* _STLP_VENDOR_EXCEPT_STD */ :: bad_typeid;
>     # endif
>     using /* _STLP_VENDOR_EXCEPT_STD */ :: bad_cast;
>
>     _STLP_END_NAMESPACE
>
>     #endif /* _STLP_OWN_NAMESPACE */
>
>
> I don't think I'm going to support any such configurations unless
> someone can show me that I'm mistaken and STLPort is just failing to
> put ::type_info into std:: erroneously.
>
> --
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com






From camelo at esss.com.br  Fri May 23 14:11:47 2003
From: camelo at esss.com.br (Marcelo A. Camelo)
Date: Fri, 23 May 2003 09:11:47 -0300
Subject: [C++-sig] Import error: undefined symbol
In-Reply-To: <20030522232310.M34474@cyan.com>
Message-ID: <00cd01c32124$7be8cee0$0d00000a@esss.com.br>

Hello again!!!

Like I've said in a previous post, I'm having a strange 
linking problem in GCC (upgrading to 3.3 didn't help, as 
I suspected). 

I'm still investigating the root of it by simplifying the 
troublesome module. In the mean time, I decided to share 
my problem in the hope of someone here being familiar 
with such error or maybe getting more information about
the internals of a GCC shared library.

Down to it:

My shared lib compiles and links with no error or warning. 
When trying to import it from python, I get the following 
error message:

ImportError: ./_coilibmodule.so: undefined symbol: 
_ZN6coilib17unstructuredblockeqERKNS0_19IEdgeOnFaceIteratorIN4Loki8Typel
istINS0_11ElementBaseILj3ELj4ELi3EEENS2_8NullTypeEEEEESA_

which suggests that the object file containing that symbol 
hasn't been linked into the final binary. The problem is 
that the file is being linked for sure. 

I've 'grep'ed both the obj file and the final shared 
library for the missing symbol and the match was positive, 

As you can guess from the name of the symbol, this code 
relies on heavy template machinery. Maybe this can be part 
of the problem.

As usual, the system builds and runs fine on win32 systems.

If anyone here has already faced a similar problem or can 
spot any flaws in my thinking, please let me know. Any help 
will be greatly appreciated. 

I will get back to my investigation now. Any relevant 
discovery will be posted to the list.

Cheers,

 

Marcelo A. Camelo, M. Eng. - Project Leader
ESSS - Engineering Simulation and Scientific Software
 
E-mail: camelo at esss.com.br
Phone: +55-48-239-2226
 




From cdn_pride at yahoo.com  Fri May 23 17:58:56 2003
From: cdn_pride at yahoo.com (Fast Bike)
Date: Fri, 23 May 2003 08:58:56 -0700 (PDT)
Subject: [C++-sig] Can't get a simple example with fstream to compile & link
In-Reply-To: <420f8ab95f85968b2c648486bd4ca31e3ecbd7b7@Orthosoft.ca>
Message-ID: <20030523155856.46548.qmail@web41209.mail.yahoo.com>

I guess what I was trying to ask is: Why is a copy
constructor needed for everything?

For example if I want to open a member file object
within the constructor of the object I am wrapping and
close it within the destructor that seems good and
normal to me. However, without making it a pointer to
a file object I can't because the boost::python
library wants to copy it.

I don't understand why it would need to make a copy of
it. That's the part I'm trying to understand.

Thanks for your help.

--- Stefan Seefeld <seefeld at sympatico.ca> wrote:
> Fast Bike wrote:
> > Opps, I messed up when cutting and pasting my
> example
> > out of a larger sample.
> > 
> > The constructor shouldn't start to initialize
> > variables and should read:
> > 
> > PythonWrapper(int id) { myid = id; };
> 
> It's generally preferable to use the initializer
> list instead of doing
> assignment within the constructor body.
> 
> Stefan
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From cdn_pride at yahoo.com  Fri May 23 18:01:11 2003
From: cdn_pride at yahoo.com (Fast Bike)
Date: Fri, 23 May 2003 09:01:11 -0700 (PDT)
Subject: [C++-sig] Can't get a simple example with fstream to compile & link
In-Reply-To: <420f8ab95f85968b2c648486bd4ca31e3ecbd7b7@Orthosoft.ca>
Message-ID: <20030523160111.86184.qmail@web41201.mail.yahoo.com>

I guess what I was trying to ask is: Why is a copy
constructor needed for everything?

For example if I want to open a member file object
within the constructor of the object I am wrapping and
close it within the destructor that seems good and
normal to me. However, without making it a pointer to
a file object I can't because the boost::python
library wants to copy it.

I don't understand why it would need to make a copy of
it. That's the part I'm trying to understand.

Thanks for your help.

--- Stefan Seefeld <seefeld at sympatico.ca> wrote:
> Fast Bike wrote:
> > Opps, I messed up when cutting and pasting my
> example
> > out of a larger sample.
> > 
> > The constructor shouldn't start to initialize
> > variables and should read:
> > 
> > PythonWrapper(int id) { myid = id; };
> 
> It's generally preferable to use the initializer
> list instead of doing
> assignment within the constructor body.
> 
> Stefan
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From camelo at esss.com.br  Fri May 23 19:06:52 2003
From: camelo at esss.com.br (Marcelo A. Camelo)
Date: Fri, 23 May 2003 14:06:52 -0300
Subject: [C++-sig] Import error: undefined symbol
In-Reply-To: <00cd01c32124$7be8cee0$0d00000a@esss.com.br>
Message-ID: <011601c3214d$b4a42300$0d00000a@esss.com.br>

Hi!!!

Problem resolved. 

For the records: it was due to a particularity in the 
way that GCC handles friends of template classes. 
Because we were declaring them in a non GCC way (which 
the Intel compiler handles nicely), it ended up not 
being instancialized by the compiler.

Once we switched to the GCC friendly declaration the 
problem went away.

For further information about how different compilers
handle template friends declarations, refer to:

http://www.cuj.com/documents/s=8244/cujcexp2101sutter/

Cheers,
 

Marcelo A. Camelo, M. Eng. - Project Leader
ESSS - Engineering Simulation and Scientific Software
 
E-mail: camelo at esss.com.br
Phone: +55-48-239-2226

Keywords: GCC, ImportError, undefined symbol, python, templates, friend,
shared

-----Original Message-----
From: c++-sig-admin at python.org [mailto:c++-sig-admin at python.org] On
Behalf Of Marcelo A. Camelo
Sent: sexta-feira, 23 de maio de 2003 09:12
To: c++-sig at python.org
Subject: [C++-sig] Import error: undefined symbol


Hello again!!!

Like I've said in a previous post, I'm having a strange 
linking problem in GCC (upgrading to 3.3 didn't help, as 
I suspected). 

I'm still investigating the root of it by simplifying the 
troublesome module. In the mean time, I decided to share 
my problem in the hope of someone here being familiar 
with such error or maybe getting more information about
the internals of a GCC shared library.

Down to it:

My shared lib compiles and links with no error or warning. 
When trying to import it from python, I get the following 
error message:

ImportError: ./_coilibmodule.so: undefined symbol: 
_ZN6coilib17unstructuredblockeqERKNS0_19IEdgeOnFaceIteratorIN4Loki8Typel
istINS0_11ElementBaseILj3ELj4ELi3EEENS2_8NullTypeEEEEESA_

which suggests that the object file containing that symbol 
hasn't been linked into the final binary. The problem is 
that the file is being linked for sure. 

I've 'grep'ed both the obj file and the final shared 
library for the missing symbol and the match was positive, 

As you can guess from the name of the symbol, this code 
relies on heavy template machinery. Maybe this can be part 
of the problem.

As usual, the system builds and runs fine on win32 systems.

If anyone here has already faced a similar problem or can 
spot any flaws in my thinking, please let me know. Any help 
will be greatly appreciated. 

I will get back to my investigation now. Any relevant 
discovery will be posted to the list.

Cheers,

 

Marcelo A. Camelo, M. Eng. - Project Leader
ESSS - Engineering Simulation and Scientific Software
 
E-mail: camelo at esss.com.br
Phone: +55-48-239-2226
 


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




From nicodemus at globalite.com.br  Sat May 24 01:02:04 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Fri, 23 May 2003 15:02:04 -0800
Subject: [C++-sig] Re: Tutorial - Techniques
In-Reply-To: <uel2tdwlo.fsf@boost-consulting.com>
References: <3EB586B7.8090108@globalite.com.br> <b952p7$ka$1@main.gmane.org> <u7k8pojyc.fsf@boost-consulting.com> <3EC6E4C5.1090601@globalite.com.br> <u3cjcqqwb.fsf@boost-consulting.com> <3EC9B1F6.4050309@globalite.com.br> <uptmdhmj1.fsf@boost-consulting.com> <3ECAD927.5060301@globalite.com.br> <uel2tdwlo.fsf@boost-consulting.com>
Message-ID: <3ECEA86C.3020804@globalite.com.br>

David Abrahams wrote:

>Nicodemus <nicodemus at globalite.com.br> writes:
>
>  
>
>>David Abrahams wrote:
>>
>>    
>>
>>>Nicodemus <nicodemus at globalite.com.br> writes:
>>>
>>> 
>>>      
>>>
>>>>Good idea! I added two new entries,  "How do I create sub-packages
>>>>using Boost.Python?" and "Compilation takes too much time and eats too
>>>>much memory! What can I do to make it faster?". Attached is a diff for
>>>>it.
>>>>*** original-faq.html	Tue Mar 18 17:49:50 2003
>>>>--- faq.html	Mon May 19 20:38:47 2003
>>>>***************
>>>>*** 57,62 ****
>>>>--- 57,67 ----
>>>>        #ownership
>>>>+   +       #slow_compilation
>>>>+       +       #packages      </dl>
>>>>   
>>>>        
>>>>
>>>Somehow that doesn't look like valid HTML.
>>> 
>>>      
>>>
>>Somehow that doesn't look like the patch that I posted. I will send it
>>zipped this time. Mozilla and Netscape have no trouble reading it
>>after the patch is applied, btw.
>>    
>>
>
>Looks great!  Why don't you apply it?
>  
>
Done.






From nicodemus at globalite.com.br  Sat May 24 01:07:17 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Fri, 23 May 2003 15:07:17 -0800
Subject: [C++-sig] Re: problem using global variable, static variable
In-Reply-To: <uiss4aqay.fsf@boost-consulting.com>
References: <20030520074344.66900.qmail@web20201.mail.yahoo.com> <3EC9ED23.9030104@cirad.fr> <uiss4aqay.fsf@boost-consulting.com>
Message-ID: <3ECEA9A5.1040705@globalite.com.br>

David Abrahams wrote:

>Cyril Bonnard <cyril.bonnard at cirad.fr> writes:
>
>  
>
>>pyste generates code which seems very strange to me:
>>BOOST_PYTHON_MODULE(test)
>>{
>>    class_< color >("color", init<  >())
>>        .def(init< const color & >())
>>        .def_readwrite("col", &color::col)
>>    ;
>>
>>    def("_GLOBAL__D__home_cbonnard_devlp_AMAPmod_src_GEOM_test.hef3xme",
>>    &_GLOBAL__D__home_cbonnard_devlp_AMAPmod_src_GEOM_test.hef3xme);
>>    def("_GLOBAL__I__home_cbonnard_devlp_AMAPmod_src_GEOM_test.hp8ylhc",
>>    &_GLOBAL__I__home_cbonnard_devlp_AMAPmod_src_GEOM_test.hp8ylhc);
>>    
>>
>
>This appears to be a Pyste bug.  It should say:
>
>     scope().attr("BLACK") = BLACK;
>  
>

(Sorry for not responding earlier: my internet connection wasn't working.)

The bug in this case is trying to export those two functions, which are 
clearly for internal use of the compiler(_GLOBAL___D__home_... is a 
function). I will change AllFromHeader so that it will ignore names that 
start with "_" (the same semantics of Python's "from foo import *" ;-) )

But Pyste now doesn't support global variables. I will add it, with a 
"Var" declaration, similar to a "Class" declaration.

Thanks Cyril,
Nicodemus.






From nicodemus at globalite.com.br  Sat May 24 01:12:04 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Fri, 23 May 2003 15:12:04 -0800
Subject: [C++-sig] exception specifiers and pyste
In-Reply-To: <3ECD5E92.9020308@anim.dreamworks.com>
References: <3ECD5E92.9020308@anim.dreamworks.com>
Message-ID: <3ECEAAC4.70308@globalite.com.br>

Gavin Doughtie wrote:

> So, I turned pyste loose on a C++ header that included "throw 
> (AnException)" on a virtual method. Pyste generated a wrapper class 
> that implemented a call_method<> implementation of the method, but did 
> not automatically include the "throw" declaration, causing compilation 
> of the generated C++ to fail with a "looser throw specifier for..." 
> error.
>
> Is this a shortcoming of pyste?

It's a shortcoming, I completely forgot about exception specifiers while 
implementing Pyste. Thanks for the reminder Gavin.

Regards,
Nicodemus.






From stefan.seefeld at orthosoft.ca  Fri May 23 20:34:05 2003
From: stefan.seefeld at orthosoft.ca (Stefan Seefeld)
Date: Fri, 23 May 2003 14:34:05 -0400
Subject: [C++-sig] instantiating python objects within C++
Message-ID: <f98cbc39db7a493b8a6b06ee21bceb563ece6c1f@Orthosoft.ca>

hi there,

I'v the feeling I'm not seeing the obvious, but...


...how can I instantiate a python object in C++ ?

I'v defined a C++ class, wrapped it into a python
class, and now want to call a python function
using an object of that type. Read: I want to
provide python 'callbacks' that let people interact
with my C++ application, but in python.

I'v set up the python interpreter and can run it
successfully. All I'm missing is a way to instantiate
objects of said type and inject them into the namespace
that is passed to the PyRun_File call...

Thanks a lot,
		Stefan




From rwgk at yahoo.com  Fri May 23 20:40:00 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 23 May 2003 11:40:00 -0700 (PDT)
Subject: [C++-sig] Re: Mac OS 10 success
In-Reply-To: <20030523002652-r01010800-ee5be03c-0860-0108@12.100.89.43>
Message-ID: <20030523184000.27918.qmail@web20208.mail.yahoo.com>

--- Rene Rivera <grafik666 at redshift-software.com> wrote:
> These are the bjam equivalents with the current state of darwin-tools.jam...
> 
> ### currently called as "c++" not "g++"
> >g++

Apple's current c++ (based on gcc 3.1) doesn't work. I am using g++ 3.3
compiled from sources. How about renaming the toolset to darwin-gcc-tools.jam?

>     ### <shared-linkable>true (on for DLL and PYD targets)
> >   -fPIC
>     ### currently set to -ftemplate-depth-120
> >   -ftemplate-depth-120
>     ### currently set to -Wall ?
> >   -w

-Wall creates a lot of noise for my compilations, but we could still try it for
the Boost.Python regression tests.

>     ### <optimization>off
> >   -O0
>     ### <inlining>off
> >   -fno-inline
>     ### I presume these are set by the libboost_python target?
> >   -DBOOST_PYTHON_MAX_BASES=2
> >   -DBOOST_PYTHON_SOURCE

The -DBOOST_PYTHON_MAX_BASES=2 is an attempt to cut down our compile-times. I
think it should be omitted from the bjam toolset. The -DBOOST_PYTHON_SOURCE is
already set somewhere by bjam (?).

>     ### <include>$BOOST_ROOT
> >   -I/net/cci/rwgk/boost_releases/1_30_0/mac/boost
>     ### <include>/Library/Frameworks... (It seems that python.jam would need
> to change to look here when the correspoding PYTHON_VERSION is set. That is
> setting the PYTHON_ROOT to
> "/Library/Frameworks/Python.framework/Versions/$(PYTHON_VERSION)" )

I obtain the -I path by looking at sys.executable and sys.version in Python.
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/libtbx/libtbx/config.py?rev=1.5&content-type=text/vnd.viewcvs-markup
I am not sure how this could fit into the bjam framework.

> >   -I/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3
> >   -c
> >   -o boost/libs/python/src/tuple.os
> >   /net/cci/rwgk/boost_releases/1_30_0/mac/boost/libs/python/src/tuple.cpp
> 
> >Linking libboost_python.dylib (three commands):
> 
>     ### I'm fairly sure there are additional library path seetings here?

Sorry, I don't understand what you mean here.

>     ### Yea, that's just what the DLL target does, except for...
>     
> >ld -dynamic -m -r -d -o libboost_python.lo boost/libs/python/src/numeric.os
> >boost/libs/python/src/list.os boost/libs/python/src/long.os
...
> >boost/libs/python/src/object_operators.os
> >
> >g++ -nostartfiles -Wl,-dylib -ldylib1.o
> 
>     ### <framework>/Library/Frameworks/... (this is currently put in as
> <framework>Python, is that enough? Or is the complete path-spec needed?)

I am not entirely sure I understand your question. Trial answer: I only could
get it to work when specifying the full path. My experiments with
-L/Library/Frameworks/.../2.3 failed. Maybe because Python doesn't exist with a
.dylib extension?

> >   -framework /Library/Frameworks/Python.framework/Versions/2.3/Python
> 
> >-o libtbx/libboost_python.dylib libboost_python.lo
> >
> >rm -f libboost_python.lo
> >
> >Compiling an extension module:
> 
>     ### Same as the previous comments.
> 
> >g++ -fPIC -ftemplate-depth-120 -w -O0 -fno-inline
> -DBOOST_PYTHON_MAX_BASES=2
> >-Ilibtbx/include -I/net/cci/rwgk/boost_releases/1_30_0/mac/libtbx/include
> >-I/net/cci/rwgk/boost_releases/1_30_0/mac/scitbx/include
> >-I/net/cci/rwgk/boost_releases/1_30_0/mac/boost
> >-I/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3 -c -o
> >scitbx/fftpack/boost_python/fftpack_ext.os
>
>/net/cci/rwgk/boost_releases/1_30_0/mac/scitbx/fftpack/boost_python/fftpack_ext.cpp
> >
> >Linking an extension module:
> >
> >g++ -w
> 
>     ### I thought -bundle didn't take a value? (Currently only -bundle is
> added)

> > -bundle /Library/Frameworks/Python.framework/Versions/2.3/Python

You are right, -bundle doesn't take a value. But the full
/Library/.../2.3/Python path has to appear somewhere. Maybe this is most
logical:

g++ -w -bundle -bundle_loader
/Library/Frameworks/Python.framework/Versions/2.3/
Python -o libtbx/scitbx_boost/rational_ext.so
scitbx/boost_python/rational_ext.o
s -Llibtbx -L/net/cci/rwgk/boost_releases/1_30_0/mac/libtbx
-lscitbx_boost_pytho
n -lboost_python /Library/Frameworks/Python.framework/Versions/2.3/Python -lm

>     ### <bundle-loader>... (Currently this is added by python.jam as
> <bundle-loader>$(PYTHON_ROOT)/bin/python$(PYTHON_VERSION) when building PYD
> targets)

This didn't work for me with the Python 2.3b1 installation.

> >-bundle_loader /Library/Frameworks/Python.framework/Versions/2.3/Python -o
> >libtbx/scitbx_boost/fftpack_ext.so
> scitbx/fftpack/boost_python/fftpack_ext.os
> >-Llibtbx -L/net/cci/rwgk/boost_releases/1_30_0/mac/libtbx
> -lscitbx_boost_python
> >-lboost_python -lm
> 
> So as far as I can see the only changes needed are in python.jam, and
> possibly the "-bundle" option in the toolset.

If you modify the toolset and check it in I will try it out. I don't think
there is a reason to be conservative since the old one never worked for
compiling and linking all Boost.Python regression tests AFAIK, due to bugs and
limitations of compilers older than gcc 3.3.

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From hupp at cs.wisc.edu  Fri May 23 21:01:27 2003
From: hupp at cs.wisc.edu (Adam Hupp)
Date: Fri, 23 May 2003 14:01:27 -0500
Subject: [C++-sig] instantiating python objects within C++
In-Reply-To: <f98cbc39db7a493b8a6b06ee21bceb563ece6c1f@Orthosoft.ca>
References: <f98cbc39db7a493b8a6b06ee21bceb563ece6c1f@Orthosoft.ca>
Message-ID: <20030523190127.GA17673@upl.cs.wisc.edu>

On Fri, May 23, 2003 at 02:34:05PM -0400, Stefan Seefeld wrote:
> 
> ...how can I instantiate a python object in C++ ?
> 
> I'v defined a C++ class, wrapped it into a python
> class, and now want to call a python function
> using an object of that type. Read: I want to
> provide python 'callbacks' that let people interact
> with my C++ application, but in python.
> 
> I'v set up the python interpreter and can run it
> successfully. All I'm missing is a way to instantiate
> objects of said type and inject them into the namespace
> that is passed to the PyRun_File call...

Try looking at libs/python/test/embedding.cpp.  It has a nice example
of this usage.  

-Adam



From rwgk at yahoo.com  Fri May 23 21:04:47 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 23 May 2003 12:04:47 -0700 (PDT)
Subject: [C++-sig] Re: method_call_expr not supported by dump_expr
In-Reply-To: <ubrxupv4r.fsf@boost-consulting.com>
Message-ID: <20030523190447.80189.qmail@web20203.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> I doubt it.  Everything interesting happens in evaluating the sizeof
> expression.  If they're not having problems now, they're not likely
> to start.
> 
> > , while Romain's fix is
> > minimally intrusive and does not change the code seen by compilers other
> than
> > gcc 3.3.
> > Your choice: adventurous or conservative?
> 
> adventurous.

Ay-ay, sir!

I am already in trouble, so I backed up:

- checked out current boost CVS (~1 hour ago)
- compiled my scitbx with default Redhat 8 gcc 3.2: no problems
- trying to compile with gcc 3.3 under Redhat 8 after completely disabling the
assertion at line 28 of as_to_python_function.hpp. Here is the full
stlfilt'ered error message:

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

The file being compiled is here:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/scitbx/array_family/boost_python/flex_scitbx_ext.cpp?rev=1.7&content-type=text/vnd.viewcvs-markup

The error message ends with:

boost::python::optional<
const
double &, boost::mpl::void_, boost::mpl::void_, ... boost::mpl::void_>
>::sequence2' is private

I remember that this worked before you checked in the fairly massive set of
fixes a couple of days ago. Did something nasty creep in?

Ralf



__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From rwgk at yahoo.com  Fri May 23 21:17:42 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 23 May 2003 12:17:42 -0700 (PDT)
Subject: [C++-sig] Can't get a simple example with fstream to compile & link
In-Reply-To: <20030523160111.86184.qmail@web41201.mail.yahoo.com>
Message-ID: <20030523191742.33557.qmail@web20208.mail.yahoo.com>

--- Fast Bike <cdn_pride at yahoo.com> wrote:
> I guess what I was trying to ask is: Why is a copy
> constructor needed for everything?

I think it is not. Look for boost::noncopyable in the tutorial.
Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From seefeld at sympatico.ca  Fri May 23 21:56:22 2003
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Fri, 23 May 2003 15:56:22 -0400
Subject: [C++-sig] instantiating python objects within C++
References: <f98cbc39db7a493b8a6b06ee21bceb563ece6c1f@Orthosoft.ca> <20030523190127.GA17673@upl.cs.wisc.edu>
Message-ID: <a1e7d37248a9c4b31966633bceb4f2023ece7f6d@Orthosoft.ca>

Hi Adam,

Adam Hupp wrote:

> Try looking at libs/python/test/embedding.cpp.  It has a nice example
> of this usage.  

thanks for the pointer. I looked, but the main question is still
unanswered, as the example instantiates an object 'implemented' in
python (derived from a C++ type). Do I really have to run the
interpreter to instantiate a python-wrapper-object around my own type ?

Anyways, I tried and failed. I attach the test, may be someone can
see what I'm doing wrong...

Running the compiled program (which calls 'script.py') results in
the following output:

<code object ? at 0x8120068, file "null", line 1>
<type 'code'>
python exception
Traceback (most recent call last):
   File "script.py", line 3, in ?
     object.value = 42
TypeError: 'code' object has only read-only attributes (assign to .value)


Thanks a lot,
		Stefan
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Embedded.cc
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20030523/bb1aff74/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: script.py
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20030523/bb1aff74/attachment-0001.txt>

From pjdurai at hotmail.com  Fri May 16 18:24:49 2003
From: pjdurai at hotmail.com (pj)
Date: Fri, 16 May 2003 10:24:49 -0600
Subject: [C++-sig] Automatic (implicit ?) type conversion for a data member of a struct.
Message-ID: <ba334r$h85$1@main.gmane.org>

Greetings.

Generally how would I enable automatic conversion for a given C++ type ?

To be specific.

I know how to expose this class to Python and exposing a function returning
this struct.
Its pretty easy due to the power of boost-python.

class MyStruct
{
    std::string name;
}

MyStruct fuc1();


What I cant figure out is how would I do this if the 'name' is not a type
understood by boost-python.
say ..

class MyString;

class MyStruct
{
    MyString name;
}

MyStruct fuc1();

How would I expose 'MyStruct' to python so that the 'name' data member of
MyStruct is _automatically_  _exposed_ as
a python string ?

I have tried the basic documentation and couldnt find the information I
need.

Appreciate your time.

cheers
pj







From pjdurai at hotmail.com  Fri May 23 22:02:41 2003
From: pjdurai at hotmail.com (pj)
Date: Fri, 23 May 2003 14:02:41 -0600
Subject: [C++-sig] How to create and return a new instance of a Python Exported C++ class.
Message-ID: <balulo$gt6$1@main.gmane.org>

Greetings.

I am using boost-python to write a python extension and export some of my
C++ class.

I cant quite figure out how to do this.

class AA {}    -> Exported to Python using class_  construct. No problems
here.

I am wring another C++ class BB (just for this extension, new code)  which
too has to be exported to Python , in which, I want to create and return a
Python-AA object.

class BB
{
    GetMeAA ( )
    {
        // When called from python this needs to create and return a
Python-AA object.
    }
};


How would I write this member function, and how would I export it ?
I suspect I am missing something rudimentary. But no clue yet to what.

Appreciate your time.

cheers
pj








From nicodemus at globalite.com.br  Sat May 24 03:32:13 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Fri, 23 May 2003 17:32:13 -0800
Subject: [C++-sig] Re: problem using global variable, static variable
In-Reply-To: <3ECEA9A5.1040705@globalite.com.br>
References: <20030520074344.66900.qmail@web20201.mail.yahoo.com> <3EC9ED23.9030104@cirad.fr> <uiss4aqay.fsf@boost-consulting.com> <3ECEA9A5.1040705@globalite.com.br>
Message-ID: <3ECECB9D.1010102@globalite.com.br>


Nicodemus wrote:

> David Abrahams wrote:
>
>> Cyril Bonnard <cyril.bonnard at cirad.fr> writes:
>>
>>  
>>
>>> pyste generates code which seems very strange to me:
>>> BOOST_PYTHON_MODULE(test)
>>> {
>>>    class_< color >("color", init<  >())
>>>        .def(init< const color & >())
>>>        .def_readwrite("col", &color::col)
>>>    ;
>>>
>>>    def("_GLOBAL__D__home_cbonnard_devlp_AMAPmod_src_GEOM_test.hef3xme",
>>>    &_GLOBAL__D__home_cbonnard_devlp_AMAPmod_src_GEOM_test.hef3xme);
>>>    def("_GLOBAL__I__home_cbonnard_devlp_AMAPmod_src_GEOM_test.hp8ylhc",
>>>    &_GLOBAL__I__home_cbonnard_devlp_AMAPmod_src_GEOM_test.hp8ylhc);
>>>   
>>
>>
>> This appears to be a Pyste bug.  It should say:
>>
>>     scope().attr("BLACK") = BLACK;
>>  
>>
>
> (Sorry for not responding earlier: my internet connection wasn't 
> working.)
>
> The bug in this case is trying to export those two functions, which 
> are clearly for internal use of the compiler(_GLOBAL___D__home_... is 
> a function). I will change AllFromHeader so that it will ignore names 
> that start with "_" (the same semantics of Python's "from foo import 
> *" ;-) )
>
> But Pyste now doesn't support global variables. I will add it, with a 
> "Var" declaration, similar to a "Class" declaration.
>
> Thanks Cyril,
> Nicodemus.
>
Implemented in the current CVS (version 0.8.0).

David, if you export a non-const global variable this way and change it 
in Python, the change won't happen in C++, right? I mentioned it in the 
docs.

Regards,
Nicodemus.






From pjdurai at hotmail.com  Mon May 19 19:54:14 2003
From: pjdurai at hotmail.com (pj)
Date: Mon, 19 May 2003 11:54:14 -0600
Subject: [C++-sig] Automatic (implicit ?) type conversion for a data member of a struct.
Message-ID: <bab5ku$h98$1@main.gmane.org>

Greetings.

Generally how would I enable automatic conversion for a given C++ type ?

To be specific.

I know how to expose this class to Python and exposing a function returning
this struct.
Its pretty easy due to the power of boost-python.

class MyStruct
{
    std::string name;
}

MyStruct fuc1();


What I cant figure out is how would I do this if the 'name' is not a type
understood by boost-python.
say ..

class MyString;

class MyStruct
{
    MyString name;
}

MyStruct fuc1();

I _dont_ want to wrap the whole 'MyString' class to Python.

I would like to expose 'MyStruct' to python so that the 'name' data member
of
MyStruct is _automatically_  _exposed_ as
a python string ?

I have tried the basic documentation and couldnt find the information I
need.

Appreciate your time.

cheers
pj








From rwgk at yahoo.com  Fri May 23 22:56:42 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 23 May 2003 13:56:42 -0700 (PDT)
Subject: [C++-sig] How to create and return a new instance of a Python Exported C++ class.
In-Reply-To: <balulo$gt6$1@main.gmane.org>
Message-ID: <20030523205642.4680.qmail@web20209.mail.yahoo.com>

--- pj <pjdurai at hotmail.com> wrote:
> class BB
> {
>     GetMeAA ( )
>     {
>         // When called from python this needs to create and return a
> Python-AA object.
>     }
> };
> 
> 
> How would I write this member function, and how would I export it ?
> I suspect I am missing something rudimentary. But no clue yet to what.

Unless I am missing something: it is all automatic. Just make your member
function complete:

  AA GetMeAA() { return AA(); }

Then

  class_<BB>("BB", ...)
    .def("GetMeAA", &BB::GetMeAA)
  ;

Boost.Python generates all the wrapping/unwrapping code for you. You don't have
to think about it unless you are dealing with raw pointers or want to avoid
using AA's copy constructor.

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From rwgk at yahoo.com  Fri May 23 23:02:10 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 23 May 2003 14:02:10 -0700 (PDT)
Subject: [C++-sig] Recent changes to FAQ
Message-ID: <20030523210210.74986.qmail@web20207.mail.yahoo.com>

The links in the two new additions to the FAQ point to files that I cannot
find. The second new link has extension .html.html. Is this due to an
oversight?
Thanks,
        Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From chip at force-elite.com  Fri May 23 23:05:54 2003
From: chip at force-elite.com (chip)
Date: Fri, 23 May 2003 14:05:54 -0700
Subject: [C++-sig] linking problems with gcc and embedded python
In-Reply-To: <20030523040411.M85456@force-elite.com>
References: <20030523040411.M85456@force-elite.com>
Message-ID: <20030523210554.M58305@force-elite.com>

I was able to compile our code using the Intel C++ Compiler v7.0 for Linux.  I
also made a libboost_python.so that used icc.  The server works fine when
built with icc, but without the embeded python.

The Intel compiler has some more readable errors with linking on the same code:

../../../../UnixProjects/Plasma/Apps/plNetGameServer/plNetGameServer.dbg.lib.a(plNetGameServerPython.dbg.o):
In function `plNetGameServerPython':
../../../../Sources/Plasma/Apps/plNetGameServer/plNetGameServerPython.cpp:27:
undefined reference to
`boost::python::objects::function_object(boost::function2<_object*, _object*,
_object*, int> const&, unsigned)'
../../../../UnixProjects/Plasma/Apps/plNetGameServer/plNetGameServer.dbg.lib.a(pyPythonMsg.dbg.o):
In function `boost::ref':
../../../../Sources/Plasma/NucleusLib/inc/../pnFactory/ref.hpp:63: undefined
reference to `boost::python::converter::registration::get_class_object() const'
../../../../Sources/Plasma/NucleusLib/inc/../pnFactory/ref.hpp:63: undefined
reference to `boost::python::converter::registration::get_class_object() const'
../../../../Sources/Plasma/NucleusLib/inc/../pnFactory/ref.hpp:63: undefined
reference to `boost::python::converter::registration::get_class_object() const'
../../../../UnixProjects/Plasma/Apps/plNetGameServer/plNetGameServer.dbg.lib.a(pyPythonMsg.dbg.o):
In function `boost::python::make_function':
../../../../../StaticSDKs/XPlatform/boost_1_29_0/boost/utility/addressof.hpp:27:
undefined reference to
`boost::python::objects::function_object(boost::function2<_object*, _object*,
_object*, int> const&, unsigned, std::pair<boost::python::detail::keyword
const*, boost::python::detail::keyword const*> const&)'
../../../../../StaticSDKs/XPlatform/boost_1_29_0/boost/utility/addressof.hpp:27:
undefined reference to
`boost::python::objects::function_object(boost::function2<_object*, _object*,
_object*, int> const&, unsigned, std::pair<boost::python::detail::keyword
const*, boost::python::detail::keyword const*> const&)'
../../../../UnixProjects/Plasma/Apps/plNetGameServer/plNetGameServer.dbg.lib.a(pyPythonMsg.dbg.o):
In function `boost::python::xdecref':
../../../../../StaticSDKs/XPlatform/boost_1_29_0/boost/utility/addressof.hpp:27:
undefined reference to
`boost::python::objects::function_object(boost::function2<_object*, _object*,
_object*, int> const&, unsigned, std::pair<boost::python::detail::keyword
const*, boost::python::detail::keyword const*> const&)'
../../../../../StaticSDKs/XPlatform/boost_1_29_0/boost/utility/addressof.hpp:27:
undefined reference to
`boost::python::objects::function_object(boost::function2<_object*, _object*,
_object*, int> const&, unsigned, std::pair<boost::python::detail::keyword
const*, boost::python::detail::keyword const*> const&)'
../../../../../StaticSDKs/XPlatform/boost_1_29_0/boost/utility/addressof.hpp:27:
undefined reference to
`boost::python::objects::function_object(boost::function2<_object*, _object*,
_object*, int> const&, unsigned, std::pair<boost::python::detail::keyword
const*, boost::python::detail::keyword const*> const&)'
../../../../UnixProjects/Plasma/Apps/plNetGameServer/plNetGameServer.dbg.lib.a(pyPythonMsg.dbg.o):../../../../../StaticSDKs/XPlatform/boost_1_29_0/boost/utility/addressof.hpp:27:
more undefined references to
`boost::python::objects::function_object(boost::function2<_object*, _object*,
_object*, int> const&, unsigned, std::pair<boost::python::detail::keyword
const*, boost::python::detail::keyword const*> const&)' follow
.


I thought maybe our libboost_python was somehow not building correctly, so I
tried a couple pre-built RPMs that are around the internet, they all showed
the same undefined symbols.

Anyone have any clues?

Thanks,

-chip

Cyan Worlds: http://www.cyanworlds.com
Cyan Worlds Open Source: http://open.cyanworlds.com




From nicodemus at globalite.com.br  Sat May 24 04:08:56 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Fri, 23 May 2003 18:08:56 -0800
Subject: [C++-sig] Recent changes to FAQ
In-Reply-To: <20030523210210.74986.qmail@web20207.mail.yahoo.com>
References: <20030523210210.74986.qmail@web20207.mail.yahoo.com>
Message-ID: <3ECED438.9030308@globalite.com.br>

Ralf W. Grosse-Kunstleve wrote:

>The links in the two new additions to the FAQ point to files that I cannot
>find. The second new link has extension .html.html. Is this due to an
>oversight?
>Thanks,
>        Ralf
>  
>

Ops! Sorry about that, my fault. Fixed.

The two missed links point to the Techniques section, that was not added 
yet. David, Joel, Ralf, you think that now that material is good enough 
for a checkin?

Regards,
Nicodemus.





From grafik666 at redshift-software.com  Fri May 23 23:27:33 2003
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Fri, 23 May 2003 16:27:33 -0500
Subject: [C++-sig] Re: Mac OS 10 success
In-Reply-To: <20030523184000.27918.qmail@web20208.mail.yahoo.com>
Message-ID: <20030523162734-r01010800-e84e5ecb-0860-0108@12.100.89.43>

[2003-05-23] Ralf W. Grosse-Kunstleve wrote:

>--- Rene Rivera <grafik666 at redshift-software.com> wrote:
>> These are the bjam equivalents with the current state of
darwin-tools.jam...
>> 
>> ### currently called as "c++" not "g++"
>> >g++
>
>Apple's current c++ (based on gcc 3.1) doesn't work. I am using g++ 3.3
>compiled from sources. How about renaming the toolset to
darwin-gcc-tools.jam?

Na, too much hasle for the outdated BBv1 ;-)

I'll just update the existing one... But I have a question about GCC in your
case. When you compile/install from sources where is it installed to? That
is how can I find it as opposed to the built in c++?

>>     ### <include>/Library/Frameworks... (It seems that python.jam would
need
>> to change to look here when the correspoding PYTHON_VERSION is set. That
is
>> setting the PYTHON_ROOT to
>> "/Library/Frameworks/Python.framework/Versions/$(PYTHON_VERSION)" )
>
>I obtain the -I path by looking at sys.executable and sys.version in
Python.
>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/libtbx/libtbx/config.py?rev=1.5&content-type=text/vnd.viewcvs-markup
>I am not sure how this could fit into the bjam framework.

It would not. Is it standard, or required, for the Python build as framework
to go where you have it? If it is I can just use that and assume the Python
build does the right thing.

>> >Linking libboost_python.dylib (three commands):
>> 
>>     ### I'm fairly sure there are additional library path seetings here?
>
>Sorry, I don't understand what you mean here.

:-) In the current bjam toolset I have stuff for setting the load library
search path so that it finds other libraries.

>>     ### Yea, that's just what the DLL target does, except for...
>>     
>> >ld -dynamic -m -r -d -o libboost_python.lo
boost/libs/python/src/numeric.os
>> >boost/libs/python/src/list.os boost/libs/python/src/long.os
>....
>> >boost/libs/python/src/object_operators.os
>> >
>> >g++ -nostartfiles -Wl,-dylib -ldylib1.o
>> 
>>     ### <framework>/Library/Frameworks/... (this is currently put in as
>> <framework>Python, is that enough? Or is the complete path-spec needed?)
>
>I am not entirely sure I understand your question. Trial answer: I only
could
>get it to work when specifying the full path. My experiments with
>-L/Library/Frameworks/.../2.3 failed. Maybe because Python doesn't exist
with a
>..dylib extension?
>
>> >   -framework /Library/Frameworks/Python.framework/Versions/2.3/Python

It's a question between:
    -framework /Library/Framework/Python.framework/Version/2.3/Python
or
    -framework Python

It's my understanding that in the second case the OS will search for the
latest version, or something such. But perhaps being specific is best for
now. I'll put the full path in there just to get it working :-)

>>     ### I thought -bundle didn't take a value? (Currently only -bundle is
>> added)
>
>> > -bundle /Library/Frameworks/Python.framework/Versions/2.3/Python
>
>You are right, -bundle doesn't take a value. But the full
>/Library/.../2.3/Python path has to appear somewhere. Maybe this is most
>logical:
>
>g++ -w -bundle -bundle_loader
>/Library/Frameworks/Python.framework/Versions/2.3/
>Python -o libtbx/scitbx_boost/rational_ext.so
>scitbx/boost_python/rational_ext.o
>s -Llibtbx -L/net/cci/rwgk/boost_releases/1_30_0/mac/libtbx
>-lscitbx_boost_pytho
>n -lboost_python /Library/Frameworks/Python.framework/Versions/2.3/Python
-lm

Ah, got it, it's just the link to the dylib bundle (without the .dylib). You
would think the -bundle_loader... option would be sufficient :-(

>> So as far as I can see the only changes needed are in python.jam, and
>> possibly the "-bundle" option in the toolset.
>
>If you modify the toolset and check it in I will try it out. I don't think
>there is a reason to be conservative since the old one never worked for
>compiling and linking all Boost.Python regression tests AFAIK, due to bugs
and
>limitations of compilers older than gcc 3.3.

I'll do the modifications and check it in. My concerns where in modifying
python.jam, without really being able to test it, as that affects all python
builds, not just the darwin one.


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



From gdoughtie at anim.dreamworks.com  Fri May 23 23:41:29 2003
From: gdoughtie at anim.dreamworks.com (Gavin Doughtie)
Date: Fri, 23 May 2003 14:41:29 -0700
Subject: [C++-sig] instantiating python objects within C++
In-Reply-To: <a1e7d37248a9c4b31966633bceb4f2023ece7f6d@Orthosoft.ca>
References: <f98cbc39db7a493b8a6b06ee21bceb563ece6c1f@Orthosoft.ca> <20030523190127.GA17673@upl.cs.wisc.edu> <a1e7d37248a9c4b31966633bceb4f2023ece7f6d@Orthosoft.ca>
Message-ID: <3ECE9589.7020708@anim.dreamworks.com>

I just did this last week. You DO have to run the interpreter, which 
then loads a python script, which imports your exported C++ class that 
you've written (or generated) a wrapper class for that has the 
call_method implementations of your virtual functions. When you extract 
to a pointer of your base class, you've really got a pointer to the 
wrapper class which calls back into the python code.


Stefan Seefeld wrote:
> Hi Adam,
> 
> Adam Hupp wrote:
> 
>> Try looking at libs/python/test/embedding.cpp.  It has a nice example
>> of this usage.  
> 
> 
> thanks for the pointer. I looked, but the main question is still
> unanswered, as the example instantiates an object 'implemented' in
> python (derived from a C++ type). Do I really have to run the
> interpreter to instantiate a python-wrapper-object around my own type ?


-- 
Gavin Doughtie
DreamWorks SKG





From pjdurai at hotmail.com  Fri May 23 23:43:42 2003
From: pjdurai at hotmail.com (pj)
Date: Fri, 23 May 2003 15:43:42 -0600
Subject: [C++-sig] Re: instantiating python objects within C++
References: <f98cbc39db7a493b8a6b06ee21bceb563ece6c1f@Orthosoft.ca>
Message-ID: <bam4j6$lts$1@main.gmane.org>

I do not yet know the answer to the first part of your question.

For the second part, after you have instantiated the object,

you might call a method (defined by the user in a python program)

with

PyObject_CallMethod(ptrToPythonObject, "<method name>", "<printf like format
string>", ...)

Atleast this is how it worked in old C based extension writing.

hth

pj

"Stefan Seefeld" <stefan.seefeld at orthosoft.ca> wrote in message
news:f98cbc39db7a493b8a6b06ee21bceb563ece6c1f at Orthosoft.ca...
> hi there,
>
> I'v the feeling I'm not seeing the obvious, but...
>
>
> ...how can I instantiate a python object in C++ ?
>
> I'v defined a C++ class, wrapped it into a python
> class, and now want to call a python function
> using an object of that type. Read: I want to
> provide python 'callbacks' that let people interact
> with my C++ application, but in python.
>
> I'v set up the python interpreter and can run it
> successfully. All I'm missing is a way to instantiate
> objects of said type and inject them into the namespace
> that is passed to the PyRun_File call...
>
> Thanks a lot,
> Stefan






From gdoughtie at anim.dreamworks.com  Sat May 24 00:00:49 2003
From: gdoughtie at anim.dreamworks.com (Gavin Doughtie)
Date: Fri, 23 May 2003 15:00:49 -0700
Subject: [C++-sig] instantiating python objects within C++
In-Reply-To: <a1e7d37248a9c4b31966633bceb4f2023ece7f6d@Orthosoft.ca>
References: <f98cbc39db7a493b8a6b06ee21bceb563ece6c1f@Orthosoft.ca> <20030523190127.GA17673@upl.cs.wisc.edu> <a1e7d37248a9c4b31966633bceb4f2023ece7f6d@Orthosoft.ca>
Message-ID: <3ECE9A11.6020803@anim.dreamworks.com>

Here's some example code -- it works (if you put it in separate files 
and, you know, FIX it to work with your system), but I'm pretty green 
with all this and would love any constructive input on how to make it 
cleaner.


-- 
Gavin Doughtie
DreamWorks SKG

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: PythonInterpreterExample.cc
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20030523/7bfafab6/attachment.txt>

From rwgk at yahoo.com  Sat May 24 01:26:02 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 23 May 2003 16:26:02 -0700 (PDT)
Subject: [C++-sig] Re: Mac OS 10 success
In-Reply-To: <20030523162734-r01010800-e84e5ecb-0860-0108@12.100.89.43>
Message-ID: <20030523232602.41989.qmail@web20206.mail.yahoo.com>

--- Rene Rivera <grafik666 at redshift-software.com> wrote:
> I'll just update the existing one... But I have a question about GCC in your
> case. When you compile/install from sources where is it installed to? That
> is how can I find it as opposed to the built in c++?

We install all gcc's with, e.g., --prefix=/usr/local/gcc-3.3 because this gives
us a clean upgrade path. To select the desired gcc we use tiny setup scripts
that put, e.g., /usr/local/gcc-3.3/bin first in PATH and also extend
LD_LIBRARY_PATH or DYLD_LIBRARY_PATH. So what I normally do is something like
this:

login ...
setup gcc33
bjam ...

> It would not. Is it standard, or required, for the Python build as framework
> to go where you have it? If it is I can just use that and assume the Python
> build does the right thing.

The last time I looked at the Python documentation it said something along the
lines of --prefix not being fully supported under Mac OS 10. I.e. most if not
all people will probably install in the same place as I did.
 
> >> >Linking libboost_python.dylib (three commands):
> >> 
> >>     ### I'm fairly sure there are additional library path seetings here?
> >
> >Sorry, I don't understand what you mean here.
> 
> :-) In the current bjam toolset I have stuff for setting the load library
> search path so that it finds other libraries.
> 
> >I am not entirely sure I understand your question. Trial answer: I only
> could
> >get it to work when specifying the full path. My experiments with
> >-L/Library/Frameworks/.../2.3 failed. Maybe because Python doesn't exist
> with a
> >..dylib extension?
> >
> >> >   -framework /Library/Frameworks/Python.framework/Versions/2.3/Python
> 
> It's a question between:
>     -framework /Library/Framework/Python.framework/Version/2.3/Python
> or
>     -framework Python

I just tried the short form again and it does not work. I've tried -L... and
setting DYLD_LIBRARY_PATH.

> Ah, got it, it's just the link to the dylib bundle (without the .dylib). You
> would think the -bundle_loader... option would be sufficient :-(

Yes, you would...

> I'll do the modifications and check it in. My concerns where in modifying
> python.jam, without really being able to test it, as that affects all python
> builds, not just the darwin one.

OK, sounds good, please give me a word and I'll try it out.

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From gdoughtie at anim.dreamworks.com  Sat May 24 02:04:03 2003
From: gdoughtie at anim.dreamworks.com (Gavin Doughtie)
Date: Fri, 23 May 2003 17:04:03 -0700
Subject: [C++-sig] Automatic (implicit ?) type conversion for a data member
 of a struct.
In-Reply-To: <bab5ku$h98$1@main.gmane.org>
References: <bab5ku$h98$1@main.gmane.org>
Message-ID: <3ECEB6F3.7080906@anim.dreamworks.com>

Well, I'm trying to do the same thing, but I think I'm not understanding 
something basic. The PyObject* parameter passed to my Extractor's 
"execute" method is "0x3" or "0x4" or something like that.

I'd love some help on this.

Here's the relevant code:

// CString is an internally-developed string class that I want to do
// implicit conversions for

// Converter
struct cstring_to_str
{
     static PyObject* convert(cdm_base::CString const& inputStr)
     {
       return PyString_FromString(inputStr.ptr());
     }
};

struct CStringExtractor
{
   static CString foo;
   static CString& execute(PyObject *pyString)
   {
      handle<> strHandle(pyString);
      str strObj(strHandle);
      char *theString = extract< char* >(strObj);

	// Not very thread safe...
      foo = theString;
      return foo;
    }
};

cdm_base::CString CStringExtractor::foo = "Uninitialized";


// Module 
======================================================================
BOOST_PYTHON_MODULE(cdm_python)
{
	// this works fine
     to_python_converter<cdm_base::CString, cstring_to_str>();

	// THIS FAILS MISERABLY
     lvalue_from_pytype<CStringExtractor, &PyString_Type>();

//etc...
}
pj wrote:
> Greetings.
> 
> Generally how would I enable automatic conversion for a given C++ type ?
> 
> To be specific.
> 
> I know how to expose this class to Python and exposing a function returning
> this struct.
> Its pretty easy due to the power of boost-python.
> 
> class MyStruct
> {
>     std::string name;
> }
> 
> MyStruct fuc1();
> 
> 
> What I cant figure out is how would I do this if the 'name' is not a type
> understood by boost-python.
> say ..
> 
> class MyString;
> 
> class MyStruct
> {
>     MyString name;
> }
> 
> MyStruct fuc1();
> 
> I _dont_ want to wrap the whole 'MyString' class to Python.
> 
> I would like to expose 'MyStruct' to python so that the 'name' data member
> of
> MyStruct is _automatically_  _exposed_ as
> a python string ?
> 
> I have tried the basic documentation and couldnt find the information I
> need.
> 
> Appreciate your time.
> 
> cheers
> pj
> 
> 
> 
> 
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 

-- 
Gavin Doughtie
DreamWorks SKG
(818) 695-3821




From grafik666 at redshift-software.com  Sat May 24 09:03:19 2003
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Sat, 24 May 2003 02:03:19 -0500
Subject: [C++-sig] Re: Mac OS 10 success
In-Reply-To: <20030523232602.41989.qmail@web20206.mail.yahoo.com>
Message-ID: <20030524020320-r01010800-8cf51a33-0860-0108@12.100.89.43>

[2003-05-23] Ralf W. Grosse-Kunstleve wrote:
>
>OK, sounds good, please give me a word and I'll try it out.

OK the changes to BoostBuildV1 are in CVS now.

The two things you should need to set for it to work are the location of the
compiler and the version of python:

    bjam -sGCC_ROOT_DIRECTORY=/usr/local/gcc-3.3 -sPYTHON_VERSION=2.3 ...


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



From rwgk at yahoo.com  Sat May 24 17:07:38 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sat, 24 May 2003 08:07:38 -0700 (PDT)
Subject: [C++-sig] Re: Mac OS 10 success
In-Reply-To: <20030524020320-r01010800-8cf51a33-0860-0108@12.100.89.43>
Message-ID: <20030524150738.28721.qmail@web20205.mail.yahoo.com>


To David Abrahams: question for you at the end.


--- Rene Rivera <grafik666 at redshift-software.com> wrote:
> The two things you should need to set for it to work are the location of the
> compiler and the version of python:
> 
>     bjam -sGCC_ROOT_DIRECTORY=/usr/local/gcc-3.3 -sPYTHON_VERSION=2.3 ...

I had to make a few changes to darwin-tools.jam:

Index: darwin-tools.jam
===================================================================
RCS file: /cvsroot/boost/boost/tools/build/darwin-tools.jam,v
retrieving revision 1.6
diff -r1.6 darwin-tools.jam
93,94c93,94
< flags darwin CFLAGS : -Wno-long-double -no-cpp-precomp ;
< flags darwin C++FLAGS : -fcoalesce-templates ;
---
> #flags darwin CFLAGS : -Wno-long-double -no-cpp-precomp ;
> #flags darwin C++FLAGS : -fcoalesce-templates ;
187c187
<     $(.GCC_BIN_DIR)$(.GXX) -c -Wall -ftemplate-depth-100 -U$(UNDEFS)
-D$(DEFINES) $(CFLAGS) $(C++FLAGS) -I"$(HDRS)" -I"$(STDHDRS)" -o "$(<)" "$(>)"
---
>     $(.GCC_BIN_DIR)$(.GXX) -c -w -ftemplate-depth-120 -U$(UNDEFS)
-D$(DEFINES) $(CFLAGS) $(C++FLAGS) -I"$(HDRS)" -I"$(STDHDRS)" -o "$(<)" "$(>)"

The standard gcc 3.3 (as opposed to Apple's c++) does not support
-no-cpp-precomp and -fcoalesce-templates (results in errors).
-Wno-long-double is also not supported by gcc 3.3 (?).
-Wall generates an overwhelming amount of noise. For now let's use
-w until everything else is sorted out.

My command:

cd boost/libs/python/test
bjam -sGCC_ROOT_DIRECTORY=/usr/local_cci/gcc-3.3 -sPYTHON_VERSION=2.3
-sTOOLS=darwin -sBUILD=debug -sALL_LOCATE_TARGET=/net_coral/scratch1/rwgk/bjam
-sRUN_ALL_TESTS=1 -d+2 test

The full output is here:

http://cci.lbl.gov/~rwgk/tmp/bjam_mac_os_10_2003_05_24_0700.log

Remarks:

This sequence of commands issued by bjam has no effect and should be omitted:

   
DYLD_LIBRARY_PATH=/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config

    export DYLD_LIBRARY_PATH 

The options

    -Wl,-dylib_compatibility_version,1.31.0 -W,l-dylib_current_version,1.31.0

while linking libboost_python.dylib should be omitted unless we
establish a real versioning system (too much work for very little
benefit in my mind).

The rule for linking the embedding example does not work:

    /usr/local_cci/gcc-3.3/bin/g++  -g  -o
"/net_coral/scratch1/rwgk/bjam/libs/python/test/bin/embedding.test/darwin/debug/runtime-link-dynamic/embedding"

"/net_coral/scratch1/rwgk/bjam/libs/python/test/bin/embedding.test/darwin/debug/runtime-link-dynamic/embedding.o"
 \
     
-L"/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config"
-L"/net_coral/scratch1/rwgk/bjam/libs/python/build/bin/libboost_python.dylib/darwin/debug/runtime-link-dynamic/shared-linkable-true"
    -lpython2.3 -ldl -lutil -lboost_python  \
      -framework /Library/Frameworks/Python.framework/Versions/2.3/Python   

/usr/bin/ld: can't locate file for: -lpython2.3

I am not sure what to do here because I am not familiar with embedding,
but I think
-L"/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config"
has no effect and should be omitted everywhere.

These messages

/usr/bin/ld: Undefined symbols:
boost::python::converter::detail::registered_base<int volatile
const&>::converte
rs

can most likely be resolved by adding class_<dummy>(...) statements to
the source code. E.g.:

#if defined(__APPLE__) && defined(__MACH__) \
 && defined(__GNUC__) && __GNUC__ == 3 && __GNUC_MINOR__ == 3 &&
__GNU_PATCHLEVEL__ == 0
    class_<dummy>("_dummy", no_init);
#endif

David, OK to do this?

Note that there are no internal compiler errors while compiling the
regression tests. Pure luck!

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From grafik666 at redshift-software.com  Sat May 24 18:29:07 2003
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Sat, 24 May 2003 11:29:07 -0500
Subject: [C++-sig] Re: Mac OS 10 success
In-Reply-To: <20030524150738.28721.qmail@web20205.mail.yahoo.com>
Message-ID: <20030524112909-r01010800-6f64a1c7-0860-0108@12.100.89.43>

[2003-05-24] Ralf W. Grosse-Kunstleve wrote:

>--- Rene Rivera <grafik666 at redshift-software.com> wrote:
>> The two things you should need to set for it to work are the location of
the
>> compiler and the version of python:
>> 
>>     bjam -sGCC_ROOT_DIRECTORY=/usr/local/gcc-3.3 -sPYTHON_VERSION=2.3 ...
>
>I had to make a few changes to darwin-tools.jam:

OK, all those changes are now in CVS, in some form or other.

[snip]

>The rule for linking the embedding example does not work:
>
>    /usr/local_cci/gcc-3.3/bin/g++  -g  -o
>"/net_coral/scratch1/rwgk/bjam/libs/python/test/bin/embedding.test/darwin/debug/runtime-link-dynamic/embedding"
>
>"/net_coral/scratch1/rwgk/bjam/libs/python/test/bin/embedding.test/darwin/debug/runtime-link-dynamic/embedding.o"
> \
>     
>-L"/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config"
>-L"/net_coral/scratch1/rwgk/bjam/libs/python/build/bin/libboost_python.dylib/darwin/debug/runtime-link-dynamic/shared-linkable-true"
>    -lpython2.3 -ldl -lutil -lboost_python  \
>      -framework /Library/Frameworks/Python.framework/Versions/2.3/Python   
>
>/usr/bin/ld: can't locate file for: -lpython2.3
>
>I am not sure what to do here because I am not familiar with embedding,
>but I think
>-L"/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config"
>has no effect and should be omitted everywhere.

I have no clue either about embeding either. But in a hope of having it not
error I removed the -lpython2.3 for the embeding targets.


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



From milind_patil at hotmail.com  Sun May 25 02:45:19 2003
From: milind_patil at hotmail.com (Milind Patil)
Date: Sat, 24 May 2003 17:45:19 -0700
Subject: [C++-sig] Re: long long unsigned issue...
References: <b8uvp7$kp1$1@main.gmane.org> <uk7d8n8k7.fsf@boost-consulting.com> <b91g6e$me8$1@main.gmane.org> <u65oriktt.fsf@boost-consulting.com> <b91qci$oc6$1@main.gmane.org> <u1xzfiizj.fsf@boost-consulting.com> <b9292b$qru$1@main.gmane.org> <u65orxage.fsf@boost-consulting.com> <b96to4$d5$1@main.gmane.org> <uof2g6fhy.fsf@boost-consulting.com> <b9747j$vqv$1@main.gmane.org> <ufzns6czx.fsf@boost-consulting.com> <b97eg3$sod$1@main.gmane.org> <uvfwo2idm.fsf@boost-consulting.com> <b9s7dn$b0$1@main.gmane.org> <uu1boaql5.fsf@boost-consulting.com> <bajv6b$pe7$1@main.gmane.org>
Message-ID: <bap3jg$pts$1@main.gmane.org>

"Milind Patil" <milind_patil at hotmail.com> wrote in message
news:bajv6b$pe7$1 at main.gmane.org...
> Thanks Dave. The to_python conversion error has gone away.
>
> I am running accross a different issue now. My assumption was that once
> I had a way to convert python long to Y via long_, I should also be able
to handle
> statements like
>
> x = hello.Y(2, 4294967295)
>
> possibly after adding
>
> implicitly_convertible<int, Y_Wrapper>();

Sorry, I meant

implicitly_convertible<long_, Y_Wrapper>();

>
> But this does not work. Is my assumption wrong? Any pointers as to
> where to look for a solution?
>
> Thanks,
> Milind
>
> PS:
>
> Code reproduced here for reference:
>
> class Y {
>   public:
>     Y() : y(0L) { }
>     Y(int y) : y(y) { }
>     Y(long long unsigned int y) : y(y) { }
>     Y(int s, const Y & y) : y(y << s) { }
>     Y(Y const& rhs) : y(rhs.y) { }
>     virtual ~Y() { }
>
>     operator int() const { return y; }
>
>     void operator=(Y const& y) {
>         this->y = y.y;
>     }
>
>     long long unsigned int y;
> };
>
> The Wrapped boost part (hello.cpp):
>
> #include <boost/python/module.hpp>
> #include <boost/python/def.hpp>
>
> #include <boost/python.hpp>
> #include <hello.h>
>
> using namespace boost::python;
>
> namespace {
> struct Y_Wrapper: Y {
>     Y_Wrapper (PyObject* self_) : Y(), self(self_) {}
>     Y_Wrapper (PyObject* self_, int y) : Y(y), self(self_) {}
>     Y_Wrapper (PyObject* self_, long long unsigned int y) : Y(y),
> self(self_) {}
>     Y_Wrapper (PyObject* self_, int s,  const Y& y) : Y(s,y), self(self_)
{}
>     Y_Wrapper (PyObject* self_, const Y& y) : Y(y), self(self_) {}
>     Y_Wrapper (PyObject* self_, boost::python::long_ y) : Y(0),
self(self_)
> {printf("hello long_");}
>
>     PyObject* self;
> };
> }
>
> BOOST_PYTHON_MODULE(hello)
> {
>     class_< Y, Y_Wrapper >("Y", init<  >())
>         .def(init< const Y & >())
>         .def(init< int, const Y & >())
>         .def(init< int >())
>         .def(init< long long unsigned int >())
>         .def(init< long_ >())
>         .def_readwrite("y", &Y::y)
>         .def("__int__", &Y::operator int)
>     ;
>
>     implicitly_convertible<int, Y>();

Also,  remove above statement.

>     implicitly_convertible<long_, Y_Wrapper>();
> }
>
> The python script:
>
> import hello
>
> x = hello.Y(4294967295)
> print x.y
> z = hello.Y(2, 4294967295)
> print z.y






From domma at procoders.net  Sun May 25 12:59:06 2003
From: domma at procoders.net (Achim Domma (ProCoders))
Date: Sun, 25 May 2003 12:59:06 +0200
Subject: [C++-sig] using BOOST_PYTHON_STATIC_LIB
Message-ID: <FCEMIEFBFOIDAOJDEPIAAEIIFFAA.domma@procoders.net>

Hello,

is it still possible to use boost_python as static library? In config.hpp I
found BOOST_PYTHON_STATIC_LIB, but it seems not to be mentioned anywhere in
the documentation. I defined it like this in my Jamfile:

<vc7><*><define>BOOST_PYTHON_STATIC_LIB

Bjam is linking with libboost_python.lib then, but I get a lot of unresolved
externals, all refering to boost.python functions using
__declspec(dllimport) which seems wrong to me. Is it my fault or do I have
to use the shared library?

regards,
Achim




From seefeld at sympatico.ca  Sun May 25 16:05:48 2003
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Sun, 25 May 2003 10:05:48 -0400
Subject: [C++-sig] instantiating python objects within C++
In-Reply-To: <f98cbc39db7a493b8a6b06ee21bceb563ece6c1f@Orthosoft.ca>
References: <f98cbc39db7a493b8a6b06ee21bceb563ece6c1f@Orthosoft.ca>
Message-ID: <3ED0CDBC.8090509@sympatico.ca>

hi there,

to give this discussion another twist: ideally
I'd like to be able not only to instantiate the
(python wrapper) object in C++, I'd also like
to decouple the lifecycle of the C++ object and
its python wrapper.
I'd like to have my C++ object instantiated long
before the wrapper, i.e. I'd like to instantiate
the wrapper around an existing object for the
sole purpose of being able to manipulate it
from within a script that is temporarily loaded
and executed once, during the lifetime of the
application.

Is that possible ? If not, where can I look for
hints at how to add such functionality ? (intuition
tells me this should be easy to add, if it isn't
already present...)

Thanks for any hints,

		Stefan




From seefeld at sympatico.ca  Sun May 25 19:45:04 2003
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Sun, 25 May 2003 13:45:04 -0400
Subject: [C++-sig] instantiating python objects within C++
In-Reply-To: <f98cbc39db7a493b8a6b06ee21bceb563ece6c1f@Orthosoft.ca>
References: <f98cbc39db7a493b8a6b06ee21bceb563ece6c1f@Orthosoft.ca>
Message-ID: <3ED10120.1030900@sympatico.ca>

just for the record: I found the answer to my first
question, almost accidentally, in the tutorial:

http://www.boost.org/libs/python/doc/tutorial/doc/derived_object_types.html

at the bottom under "class_<T> as objects".

David, *please* put this stuff at a more prominent place, it really
deserves it !

Thanks a lot,
		Stefan




From rwgk at yahoo.com  Mon May 26 06:11:36 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 25 May 2003 21:11:36 -0700 (PDT)
Subject: [C++-sig] Re: Mac OS 10 success
In-Reply-To: <20030524112909-r01010800-6f64a1c7-0860-0108@12.100.89.43>
Message-ID: <20030526041136.72191.qmail@web20202.mail.yahoo.com>

--- Rene Rivera <grafik666 at redshift-software.com> wrote:
> OK, all those changes are now in CVS, in some form or other.

Cool! I think the toolset is pretty close now, although there are still quite a
few errors.

> >/usr/bin/ld: can't locate file for: -lpython2.3
> >
> >I am not sure what to do here because I am not familiar with embedding,
> >but I think
> >-L"/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config"
> >has no effect and should be omitted everywhere.
> 
> I have no clue either about embeding either. But in a hope of having it not
> error I removed the -lpython2.3 for the embeding targets.

The linker also doesn't know about -ldl and -lutil. After removing these there
is one undefined symbol, but it is almost certainly not due to missing
libraries since similar errors appears while linking some other extension
modules. Therefore I'd suggest that we remove -ldl and -lutil from the toolset.

Unfortunately the undefined symbols do not go away with my class_<dummy> trick.
In one case rearranging the code helped but in other cases I couldn't find a
workaround (I guess I am just lucky that all my own code works anyway). Maybe
the Boost.Python regression tests have to wait for another gcc release. In the
meantime we can keep submitting bug reports to GNU. At least we are far enough
now so that this is feasible.

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From grafik666 at redshift-software.com  Mon May 26 07:08:46 2003
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Mon, 26 May 2003 00:08:46 -0500
Subject: [C++-sig] Re: Mac OS 10 success
In-Reply-To: <20030526041136.72191.qmail@web20202.mail.yahoo.com>
Message-ID: <20030526000847-r01010800-7b0101a7-0860-0108@12.100.89.43>

[2003-05-25] Ralf W. Grosse-Kunstleve wrote:

>--- Rene Rivera <grafik666 at redshift-software.com> wrote:
>> >/usr/bin/ld: can't locate file for: -lpython2.3
>> >
>> >I am not sure what to do here because I am not familiar with embedding,
>> >but I think
>>
>-L"/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config"
>> >has no effect and should be omitted everywhere.
>> 
>> I have no clue either about embeding either. But in a hope of having it
not
>> error I removed the -lpython2.3 for the embeding targets.
>
>The linker also doesn't know about -ldl and -lutil. After removing these
there
>is one undefined symbol, but it is almost certainly not due to missing
>libraries since similar errors appears while linking some other extension
>modules. Therefore I'd suggest that we remove -ldl and -lutil from the
toolset.

Done :-)


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



From nikolai.kirsebom at siemens.no  Mon May 26 09:58:33 2003
From: nikolai.kirsebom at siemens.no (Kirsebom Nikolai)
Date: Mon, 26 May 2003 09:58:33 +0200
Subject: [C++-sig] Using boost for both embedding and extending.
Message-ID: <5B5544F322E5D211850F00A0C91DEF3B050DB584@osll007a.siemens.no>

Hi,
I'm trying to embed Python (2.2.2 later 2.3) in our application (MFC based,
VS 6.0, Windows 2000) and at the same time expose some of the applications
objects (datamodel), using Boost(v2).  If I run the code given below, it
'core dumps' due to the line "ab = v.GetMenuEntry()\n" in the first
PyRun_String statement.  Leaving out this python-statement, I'm able to (as
an example) extract the number for "e" as shown in the second PyRun_String
statement.

Quite sure it is an easy issue, however I've tried to copy the example of
'singleton' from the boost.python documentation, but obviously I must have
missed out something.

Thanks for any help.

Nikolai


--------------
#include "stdafx.h"

#include "Python.h"  //<<-- replaced when running in debug mode
#include <boost/python.hpp>

using namespace boost::python;

class DLEPRinterface {
public:
	DLEPRinterface();

	CString GetMenuEntry();
};

DLEPRinterface::DLEPRinterface()
{
}

CString DLEPRinterface::GetMenuEntry()
{
	return _T("The menu entry");
}

class Element {
public:
	Element();
	void SetNumber(int nbr);
	int GetNumber();

private:
	int m_Number;
};

Element::Element()
{
}

void Element::SetNumber(int nbr)
{
	m_Number = nbr;
}

int Element::GetNumber()
{
	return m_Number;
}

DLEPRinterface* getit() {
	static DLEPRinterface *v = NULL;
	if (DLEPRinterface == NULL) {
		v = new DLEPRinterface();
	}
	return v;
}


BOOST_PYTHON_MODULE(CppDocuLive)
{
	def("getit", getit,
return_value_policy<reference_existing_object>())
	;
	class_<DLEPRinterface>("DLEPRinterface")
		.def("GetMenuEntry", &DLEPRinterface::GetMenuEntry)
	;
	class_<Element>("Element")
		.def("SetNumber", &Element::SetNumber)
		.def("GetNumber", &Element::GetNumber)
	;
}


//TheClass
TheClass::TheClass()
{
}

TheClass::~TheClass()
{
}

CString TheClass::RunStmt()
{
	if (PyImport_AppendInittab("CppDocuLive", initCppDocuLive) == -1)
		throw std::runtime_error("Failed to add CppDocuLive to the
interpreter's builtin modules");
	
	Py_Initialize();

	handle<> main_module(borrowed( PyImport_AddModule("__main__")));
	handle<> main_namespace(borrowed(PyModule_GetDict(main_module.get())
));
	
	handle<> result(PyRun_String(
		"import CppDocuLive\n"
		"v = CppDocuLive.getit()\n"
		"ab = v.GetMenuEntry()\n"
		"e = CppDocuLive.Element()\n"
		"e.SetNumber(345)\n",
		Py_file_input, main_namespace.get(),main_namespace.get()));
	result.reset();

	PyObject *p = PyRun_String("e.GetNumber()",
Py_eval_input,main_namespace.get(), main_namespace.get());
	/* 
	.
	.
	.
	.
	*/    
    
    	Py_Finalize();

}
-----------------



From brett.calcott at paradise.net.nz  Mon May 26 10:28:28 2003
From: brett.calcott at paradise.net.nz (Brett Calcott)
Date: Mon, 26 May 2003 20:28:28 +1200
Subject: [C++-sig] Re: Using boost for both embedding and extending.
References: <5B5544F322E5D211850F00A0C91DEF3B050DB584@osll007a.siemens.no>
Message-ID: <basj4p$1oi$1@main.gmane.org>

>
> CString DLEPRinterface::GetMenuEntry()
> {
> return _T("The menu entry");
> }


GetMenuEntry() returns a CString. Boost.Python has no builtin converters for
this class. i.e. It does not know how to make a CString into a
python-object.

Try changing it to a std::string or a just a char const *const.

BTW, I can't see a try/catch statement -- are you sure it is dumping core,
or is it just raising an exception you don't catch?

Cheers,
Brett








From brett.calcott at paradise.net.nz  Mon May 26 10:41:11 2003
From: brett.calcott at paradise.net.nz (Brett Calcott)
Date: Mon, 26 May 2003 20:41:11 +1200
Subject: [C++-sig] registering simple conversions from/to python
Message-ID: <basjrh$4m2$1@main.gmane.org>

I'd like to pythonise my classes a little by allowing tuples to be passed to
and from the data values.

In python in would look something like this:

class C(object):
    def __init__(self, x=0.0, y=0.0):
        self.x = x
        self.y = y

    def get_xy(self):
        return self.x, self.y

    def set_xy(self, xy):
        self.x, self.y = xy

    xy = property(get_xy, set_xy)


I guess I would start by created a pair<x, x> object, and then register
inward and outward conversions for it.

Is there a simple recipe for registering these conversions?

Cheers,
Brett






From thor.arne.johansen at ibas.no  Mon May 26 10:47:06 2003
From: thor.arne.johansen at ibas.no (thor.arne.johansen at ibas.no)
Date: Mon, 26 May 2003 10:47:06 +0200
Subject: [C++-sig] instantiating python objects within C++
Message-ID: <OF79F9FB65.98F6B5EE-ONC1256D32.002FCF54@no>

Stefan wrote:
...
>I'd like to have my C++ object instantiated long
>before the wrapper, i.e. I'd like to instantiate
>the wrapper around an existing object for the
>sole purpose of being able to manipulate it
>from within a script that is temporarily loaded
>and executed once, during the lifetime of the
>application.
...

I have the same need, and after getting som help on this list I came up
with the following example:

http://mail.python.org/pipermail/c++-sig/2002-December/002833.html

I never got any feedback on this posting, so I don't know how 'good' the
example is, but it seems to work allright.

--
Thor Arne Johansen
Dept. Manager R&D
Ibas AS




From nikolai.kirsebom at siemens.no  Mon May 26 11:41:31 2003
From: nikolai.kirsebom at siemens.no (Kirsebom Nikolai)
Date: Mon, 26 May 2003 11:41:31 +0200
Subject: [C++-sig] =?windows-1252?Q?RE=3A_Re=3A_=C6C++-sig=C5_instantiating_pytho?=
 =?windows-1252?Q?n_objects_within_C++?=
Message-ID: <5B5544F322E5D211850F00A0C91DEF3B050DB5A3@osll007a.siemens.no>

Hei,
Tusen takk skal du ha.  Skal se p? det i kveld.
Nikolai Kirsebom


-----Original Message-----
From: thor.arne.johansen at ibas.no [mailto:thor.arne.johansen at ibas.no]
Sent: 26. mai 2003 10:47
To: c++-sig at python.org
Subject: Re: Re: ?C++-sig? instantiating python objects within C++



Stefan wrote:
...
>I'd like to have my C++ object instantiated long
>before the wrapper, i.e. I'd like to instantiate
>the wrapper around an existing object for the
>sole purpose of being able to manipulate it
>from within a script that is temporarily loaded
>and executed once, during the lifetime of the
>application.
...

I have the same need, and after getting som help on this list I came up
with the following example:

http://mail.python.org/pipermail/c++-sig/2002-December/002833.html

I never got any feedback on this posting, so I don't know how 'good' the
example is, but it seems to work allright.

--
Thor Arne Johansen
Dept. Manager R&D
Ibas AS


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



From beyer at imb-jena.de  Mon May 26 13:44:35 2003
From: beyer at imb-jena.de (Andreas Beyer)
Date: Mon, 26 May 2003 13:44:35 +0200
Subject: [C++-sig] Unicode strings
Message-ID: <3ED1FE23.5090604@imb-jena.de>

Hi,

Is it possible to convert a python unicode object to a C++ string object?
If yes: How do I do that?
If no: Would it be possible to include unicode support into the string 
wrapper class in Boost.Python?

Thanks,
	Andreas


PS: Apperently the following does not work:

class my_class
{
   ...
   void take_a_string(string);
   ...
}

Then in the wrapper:
   .def("take_a_string",   &my_class::take_a_string)

And finally in Python:
 >>> x = my_class()
 >>> x.take_a_string(unicode("something"))

-> TypeError







From phil at freehackers.org  Mon May 26 15:23:36 2003
From: phil at freehackers.org (Philippe Fremy)
Date: Mon, 26 May 2003 15:23:36 +0200
Subject: [C++-sig] list.len()
Message-ID: <200305261523.36319.phil@freehackers.org>

	Hi,

I am using boost 1.30 and I was surprised to discover that in 
boost::python::list, there is no len() method. Am I mistaken or is 
PyList_Size( my_list.ptr() ) the only way to get the length ?

If so, I suggest to add it in the future. It is very common to use the size 
of a list when operating upon it.

	regards,

	Philippe

-- 
You should not reinvent the wheel. 
Except when the first inventor made it square!




From dave at boost-consulting.com  Mon May 26 15:30:24 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 26 May 2003 09:30:24 -0400
Subject: [C++-sig] Re: method_call_expr not supported by dump_expr
References: <ubrxupv4r.fsf@boost-consulting.com> <20030523190447.80189.qmail@web20203.mail.yahoo.com>
Message-ID: <u8ystesy7.fsf@boost-consulting.com>

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

>
> The error message ends with:
>
> boost::python::optional<
> const
> double &, boost::mpl::void_, boost::mpl::void_, ... boost::mpl::void_>
>>::sequence2' is private
>
> I remember that this worked before you checked in the fairly massive set of
> fixes a couple of days ago. Did something nasty creep in?

Slightly.  Please check out boost/mpl/joint_view.hpp and try again.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Mon May 26 15:48:17 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 26 May 2003 09:48:17 -0400
Subject: [C++-sig] Re: linking problems with gcc and embedded python
References: <20030522232310.M34474@cyan.com>
Message-ID: <uy90tddjy.fsf@boost-consulting.com>

"Paul Querna" <chip at cyan.com> writes:

> First off, this code works fine in Windows using VC++ v6. (the
> pinnacle of all compilers! (hehe))

<g>

> This error reproduces in gcc 3.0.2(redhat 7.2) and 3.2.2(redhat
> 9.0).
>
> We are using boost 1.29.0. Upgrading to the latest CVS would be
> possible if it will fix this, but we would prefer not to have to go
> this route.(pain, suffering, death... etc)

I think you overestimate the pain.  Almost everything "just works
better" in 1.30.0.

> We are in the process of adding an embedded python interpreter to
> one of our server programs.
>
> We have built a boost python shared object that we dynamicly link to
> in our servers.  It seems to work fine for other things.
>
> Here are the linking errors we get: (be prepared... its ugly..)


In the future, please pass your ugly GCC error messages through Leor
Zolman's wonderful STLFilt formatting engine (www.bdsoft.com), to get:

../../../../UnixProjects/Plasma/Apps/plNetGameServer/plNetGameServer.dbg.lib.a(pyPythonMsg.dbg.o)(
        .gnu.linkonce.t.
        _ZN5boost6python6detail17make_function_auxIM11pyPythonMsgFSsvENS0_21default_call_policiesENS1_16args_from_python
        ENS_3mpl5list2ISsRS3_EENS8_5int_cILi0EEEEENS0_3api6objectET_RKT0_RKT1_RKT2_RKSt4pairIPKNS1_7keywordEST_ET3_+
        0x4d):
In function `boost::python::api::object
boost::python::detail::make_function_aux<
    basic_string<
        char,
        char_traits<char> 
    > (pyPythonMsg::*)(),
    boost::python::default_call_policies, 
    boost::python::detail::args_from_python,
    boost::mpl::list2<
            basic_string<
                char, char_traits<char>,
                allocator<char> >, 
            pyPythonMsg&
    >, 
    boost::mpl::int_c<(int)0>
>(
    string
    (pyPythonMsg::*)(), 
    boost::python::default_call_policies const&,
    boost::python::detail::args_from_python const&,
    boost::mpl::list2<
            basic_string<
                char, char_traits<char>,
                allocator<char> 
            >, 
    pyPythonMsg&> const&,
    pair<
            boost::python::detail::keyword const*,
            boost::python::detail::keyword const*
    > const&, 
    boost::mpl::int_c<(int)0>
)':

../../../../../StaticSDKs/XPlatform/boost_1_29_0/boost/function/function_base.hpp:246:
undefined reference to
`boost::python::objects::function_object(
     boost::function2<
         _object*, _object*,_object*
     > const&, 
     unsigned,
     pair<
          boost::python::detail::keyword const*,
          boost::python::detail::keyword const*
     > const&
)'

Looks to me like you're not linking to the Boost.Python shared
library.  Thats where that function is located.

> sniplet of part of the offending code:
>
> void pyPythonMsg::PythonModDef()
> {
>         class_<pyPythonMsg>("ptPythonMsg", init<>())
>                 .def("getContents",&pyPythonMsg::GetMsgContents)
>                 .def("setContents",&pyPythonMsg::SetMsgContents)
>                 .def("getSenderID",&pyPythonMsg::GetSenderID)
>                
> .def("getKey",&pyPythonMsg::GetKey,return_value_policy<manage_new_object>())
>                 .def("setKey",&pyPythonMsg::SetKey)
>                 .def("send",&pyPythonMsg::SendMessage)
>         ;
>         pyKey::PythonModDef();
> }
>
> If the defs are commented out, we do not get these linking errors.  

That's rather surprising.  These defs shouldn't be using that
function, since they don't expose any keyword arguments.

> The same code works great under windows and VC++. The code without
> the embedded python interpreter also works under both Windows and
> Linux.
>
> I have been looking over these errors, but I can't seem to find anything
> obvious that would be causing them.  

Normally I'd say it's not in your source code; they're link errors so
it's in the way you're assembling your application/module.

> For example, we aren't missing other boost python functions, the
> linker seems to find them, but somthing about these defs are causing
> the linker to not see the boost functions. We have tried quote a few
> variations, recompiled boost a couple times, linked to debug
> /nondebug.. etc., but can't seem to find anything that is causing
> this.

> Because of the nature of this server, I cannot release a full copy of its
> source for outside developers to test it. Sorry about that.  
>
> Any pointers or possible solutions, no matter how faint of a chance, would be
> greatly appreciated.

Aside from updating your Boost installation, which I highly recommend
anyway, you could think about explicitly specifying keywords in one of
those .def() calls so that it actually *tries* hard to get ahold of
that function and causes it to stay linked-in to the executable image.

See http://www.boost.org/libs/python/doc/v2/args.html#args-spec

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Mon May 26 15:52:10 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 26 May 2003 09:52:10 -0400
Subject: [C++-sig] Re: problem using global variable, static variable
References: <20030520074344.66900.qmail@web20201.mail.yahoo.com> <3EC9ED23.9030104@cirad.fr>
 <uiss4aqay.fsf@boost-consulting.com> <3ECEA9A5.1040705@globalite.com.br>
 <3ECECB9D.1010102@globalite.com.br>
Message-ID: <usmr1dddh.fsf@boost-consulting.com>

Nicodemus <nicodemus at globalite.com.br> writes:

> David, if you export a non-const global variable this way and change
> it in Python, the change won't happen in C++, right? 

Yep; nothing you can do about it.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From giulio.eulisse at cern.ch  Mon May 26 16:40:18 2003
From: giulio.eulisse at cern.ch (Giulio Eulisse)
Date: 26 May 2003 16:40:18 +0200
Subject: [C++-sig] missing boost::ref in pyste generated code?
Message-ID: <1053960018.16477.166.camel@lxcms25>

With the following piece of code:

--CUT-HERE--

#include <iostream>
using std::cout;
using std::endl;

class Ev {
public:
  Ev(int ii) : i(ii) {
    cout <<  "EV " << i << endl;
  }

  virtual ~Ev() {
    cout << "dead Ev " << i << endl;

  }

  int id() const { return i;}


  virtual void me() const=0;

private:
  int i;
};

class REv : public Ev {
public:
  REv(int ii) : Ev(ii){}

  virtual void me() const {
    cout <<  "ReV " << id() << endl;
  }
};

class AA {
public:
  AA() : i(1) {
    cout << "AA " << i << endl;
  }

  virtual ~AA() {
    cout << "dead AA " << i << endl;

  }

  int id() const { return i;}

  virtual void dump() {
    cout << "I'm a AA " << i << endl;
  }

  virtual void here(Ev* ev) const=0;
  virtual void there(Ev const&) const=0;

private:
  int i;
};



class BB : public AA {
public:
  BB(int jj=2) : j(jj) {
    cout << "BB " << j << endl;
  }

  virtual ~BB() {
    cout << "dead BB " << j << endl;

  }

  int jd() const { return j;}

  virtual void dump() {
    cout << "I'm a BB " << j << endl;
  }

  virtual void here(Ev* ev) const {
    cout << "I'm a BB " << j <<" ";
    ev->me();
  }
  virtual void there(Ev const& ev) const {
    cout << "I'm a BB " << j <<" ";
    ev.me();
  }

private:
  int j;
};


inline void hello(AA* a, int k) { REv v(k); a->here(&v);}
inline void hello2(AA* a, int k) { REv v(k); a->there(v);}
---END-CUT---

when pystified with 

---CUT-HERE---
Ev = Class("Ev","Utilities/UtExamples/python/btest.hh")
REv = Class("REv","Utilities/UtExamples/python/btest.hh")
AA = Class("AA","Utilities/UtExamples/python/btest.hh")
BB = Class("BB","Utilities/UtExamples/python/btest.hh")

hello = Function("hello","Utilities/UtExamples/python/btest.hh")
hello2 = Function("hello2","Utilities/UtExamples/python/btest.hh")

---CUT-HERE---

I get the following boostified code:

// Includes
====================================================================
#include <boost/python.hpp>
#include <Utilities/UtExamples/python/btest.hh>
#include <Utilities/UtExamples/python/stest.hh>

// Using
=======================================================================
using namespace boost::python;

// Declarations
================================================================


namespace  {


struct AA_Wrapper: AA
{
    AA_Wrapper(PyObject* self_, const AA & p0):
        AA(p0), self(self_) {}

    AA_Wrapper(PyObject* self_):
        AA(), self(self_) {}

    void dump() {
        call_method< void >(self, "dump");
    }

    void default_dump() {
        AA::dump();
    }

    void here(Ev * p0) const {
        call_method< void >(self, "here", p0); //should be 					      
//boost::ref(*p0)
    }

    void there(const Ev & p0) const {
        call_method< void >(self, "there", p0); //should be
						//boost::ref(p0)
    }

    PyObject* self;
};

struct Ev_Wrapper: Ev
{
    Ev_Wrapper(PyObject* self_, const Ev & p0):
        Ev(p0), self(self_) {}

    Ev_Wrapper(PyObject* self_, int p0):
        Ev(p0), self(self_) {}

    void me() const {
        call_method< void >(self, "me");
    }

    PyObject* self;
};

struct BB_Wrapper: BB
{
    BB_Wrapper(PyObject* self_, const BB & p0):
        BB(p0), self(self_) {}

    BB_Wrapper(PyObject* self_):
        BB(), self(self_) {}

    BB_Wrapper(PyObject* self_, int p0):
        BB(p0), self(self_) {}

    void dump() {
        call_method< void >(self, "dump");
    }

    void default_dump() {
        BB::dump();
    }

    void here(Ev * p0) const {
        call_method< void >(self, "here", p0); //should be 					      
//boost::ref(*p0)
    }

    void default_here(Ev * p0) const {
        BB::here(p0);
    }

    void there(const Ev & p0) const {
        call_method< void >(self, "there", p0);
    }

    void default_there(const Ev & p0) const {
        BB::there(p0);
    }

    PyObject* self;
};

struct REv_Wrapper: REv
{
    REv_Wrapper(PyObject* self_, const REv & p0):
        REv(p0), self(self_) {}

    REv_Wrapper(PyObject* self_, int p0):
        REv(p0), self(self_) {}

    void me() const {
        call_method< void >(self, "me");
    }

    void default_me() const {
        REv::me();
    }

    PyObject* self;
};



}// namespace


// Module
======================================================================
BOOST_PYTHON_MODULE(btest)
{
    class_< AA, boost::noncopyable, AA_Wrapper >("AA", init<  >())
        .def("id", &AA::id)
        .def("dump", &AA::dump, &AA_Wrapper::default_dump)
    ;

    class_< Ev, boost::noncopyable, Ev_Wrapper >("Ev", init< int >())
        .def("id", &Ev::id)
    ;

    class_< BB, bases< AA > , BB_Wrapper >("BB", init< const BB & >())
        .def(init< optional< int > >())
        .def("jd", &BB::jd)
        .def("dump", &BB::dump, &BB_Wrapper::default_dump)
        .def("here", &BB::here, &BB_Wrapper::default_here)
        .def("there", &BB::there, &BB_Wrapper::default_there)
    ;

    class_< REv, bases< Ev > , REv_Wrapper >("REv", init< const REv &
>())
        .def(init< int >())
        .def("me", &REv::me, &REv_Wrapper::default_me)
    ;

    class_< T >("T", init<  >())
        .def(init< const T & >())
    ;

    def("hello", &hello);
    def("hello2", &hello2);
}

---END---

this fails when doing the following in python:

>>> from PyUtExamples import *
>>>
>>> b = BB()
AA 1
BB 2
>>> hello2(b,4)
EV 4
dead Ev 4
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: No to_python (by-value) converter found for C++ type: 2Ev
>>>


as it seem to pass Ev by value, instead of passing it by reference.
We fixed it by adding boost::ref where indicated in the sourcecode as
otherwise it tries to pass things by value. Is this a bug or am I doing
something wrong?

Ciao,
Giulio




From dave at boost-consulting.com  Mon May 26 18:23:37 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 26 May 2003 12:23:37 -0400
Subject: [C++-sig] Re: instantiating python objects within C++
References: <f98cbc39db7a493b8a6b06ee21bceb563ece6c1f@Orthosoft.ca> <20030523190127.GA17673@upl.cs.wisc.edu>
 <a1e7d37248a9c4b31966633bceb4f2023ece7f6d@Orthosoft.ca>
 <3ECE9589.7020708@anim.dreamworks.com>
Message-ID: <ufzn1d6d2.fsf@boost-consulting.com>

Gavin Doughtie <gdoughtie at anim.dreamworks.com> writes:

> I just did this last week. You DO have to run the interpreter...

No, ya don't.

> ...which
> then loads a python script, which imports your exported C++ class that
> you've written (or generated) a wrapper class for that has the
> call_method implementations of your virtual functions. When you
> extract to a pointer of your base class, you've really got a pointer
> to the wrapper class which calls back into the python code.

Wow! That's really complicated!

See the last example at
http://www.boost.org/libs/python/doc/tutorial/doc/derived_object_types.html

    object FooClass
        = class_<Foo>("Foo", init<int, char const*>())
               .def( ... )
               ...
               ;

    object foo = FooClass(3, "hello");

Joel, we might want to do that example in two steps as shown above
just to make it crystal clear what's happening.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Mon May 26 18:26:53 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 26 May 2003 12:26:53 -0400
Subject: [C++-sig] Re: instantiating python objects within C++
References: <f98cbc39db7a493b8a6b06ee21bceb563ece6c1f@Orthosoft.ca> <3ED10120.1030900@sympatico.ca>
Message-ID: <u7k8dd67m.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> just for the record: I found the answer to my first
> question, almost accidentally, in the tutorial:
>
> http://www.boost.org/libs/python/doc/tutorial/doc/derived_object_types.html
>
> at the bottom under "class_<T> as objects".
>
> David, *please* put this stuff at a more prominent place, it really
> deserves it !

Stefan, *please* tell me what you think a more prominent place would
be!  Better yet, contribute a documentation patch!

[Maybe you should add it to Bruno's upcoming "Techniques" section?]

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Mon May 26 18:33:10 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 26 May 2003 12:33:10 -0400
Subject: [C++-sig] Re: instantiating python objects within C++
References: <f98cbc39db7a493b8a6b06ee21bceb563ece6c1f@Orthosoft.ca> <3ED0CDBC.8090509@sympatico.ca>
Message-ID: <u1xyld5x5.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> hi there,
>
> to give this discussion another twist: ideally
> I'd like to be able not only to instantiate the
> (python wrapper) object in C++, I'd also like
> to decouple the lifecycle of the C++ object and
> its python wrapper.
> I'd like to have my C++ object instantiated long
> before the wrapper, i.e. I'd like to instantiate
> the wrapper around an existing object for the
> sole purpose of being able to manipulate it
> from within a script that is temporarily loaded
> and executed once, during the lifetime of the
> application.
>
> Is that possible ? If not, where can I look for
> hints at how to add such functionality ? (intuition
> tells me this should be easy to add, if it isn't
> already present...)

Sure, no problem.  How do you want the object referenced?  By raw
pointer (unsafe):

        object wrapped_x(ptr(&x));
or
        object wrapped_x(ref(x));

        
by std::auto_ptr (safe), or by boost::shared_ptr (recommended for its
many advantages)?  for these two it's easiest to wrap the object as

      class_<Foo, boost::shared_ptr<Foo> >("Foo") ...

and then simply:

    object wrapped_x(some_shared_Foo_ptr);

Or you can expose the to-python converter manually with the technique
here:

  http://article.gmane.org/gmane.comp.python.c++/2846


HTH,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From rwgk at yahoo.com  Mon May 26 18:35:24 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 26 May 2003 09:35:24 -0700 (PDT)
Subject: [C++-sig] registering simple conversions from/to python
In-Reply-To: <basjrh$4m2$1@main.gmane.org>
Message-ID: <20030526163524.93789.qmail@web20207.mail.yahoo.com>

--- Brett Calcott <brett.calcott at paradise.net.nz> wrote:
> Is there a simple recipe for registering these conversions?

I do something like this all the time, although I wouldn't claim that it is
"simple." There are some hints here:

http://www.boost.org/libs/python/doc/v2/faq.html#question2

Alternative 2 seem most appropriate in your case. I would use
boost:array<double, 2> as the vehicle for your data. Look here for a complete
example:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/scitbx/array_family/boost_python/regression_test_ext.cpp?rev=1.3&content-type=text/vnd.viewcvs-markup

Look for:

    boost::python::to_python_converter<
      boost::array<int, 2>,
      scitbx::boost_python::container_conversions::to_tuple<
        boost::array<int, 2> > >();

And:

    scitbx::boost_python::container_conversions::from_python_sequence<
      boost::array<double, 3>,
      scitbx::boost_python::container_conversions::fixed_size_policy>();

To be able to use this copy the header file

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

to your own project. There are no dependencies for this file other than boost.

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From dave at boost-consulting.com  Mon May 26 18:39:37 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 26 May 2003 12:39:37 -0400
Subject: [C++-sig] Re: Recent changes to FAQ
References: <20030523210210.74986.qmail@web20207.mail.yahoo.com> <3ECED438.9030308@globalite.com.br>
Message-ID: <ullwtbr1y.fsf@boost-consulting.com>

Nicodemus <nicodemus at globalite.com.br> writes:

> Ops! Sorry about that, my fault. Fixed.
>
> The two missed links point to the Techniques section, that was not
> added yet. David, Joel, Ralf, you think that now that material is good
> enough for a checkin?
>
> Regards,
> Nicodemus.

Nicodemus,

Stop asking permission and go ahead!  We can always clean any
problems up later.

Thanks,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Mon May 26 18:41:53 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 26 May 2003 12:41:53 -0400
Subject: [C++-sig] Re: registering simple conversions from/to python
References: <basjrh$4m2$1@main.gmane.org>
Message-ID: <ufzn1bqy6.fsf@boost-consulting.com>

"Brett Calcott" <brett.calcott at paradise.net.nz> writes:

> I'd like to pythonise my classes a little by allowing tuples to be passed to
> and from the data values.
>
> In python in would look something like this:
>
> class C(object):
>     def __init__(self, x=0.0, y=0.0):
>         self.x = x
>         self.y = y
>
>     def get_xy(self):
>         return self.x, self.y
>
>     def set_xy(self, xy):
>         self.x, self.y = xy
>
>     xy = property(get_xy, set_xy)
>
>
> I guess I would start by created a pair<x, x> object, and then register
> inward and outward conversions for it.
>
> Is there a simple recipe for registering these conversions?

Brett,

I'm sorry, I can't tell what you're trying to do.  Could you please
show an example of your C++ class and how you'd like to use it from
Python?

Thanks,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From rwgk at yahoo.com  Mon May 26 18:45:25 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 26 May 2003 09:45:25 -0700 (PDT)
Subject: [C++-sig] Re: Mac OS 10 & type_with_alignment.hpp
In-Reply-To: <u65o2pv14.fsf@boost-consulting.com>
Message-ID: <20030526164525.7466.qmail@web20203.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> OK, please undo my suggested patch, and feel free to disable those
> asserts on MacOSX :(

Okey Dokey. According to this message:

http://mail-index.netbsd.org/port-powerpc/1999/12/29/0001.html

"PowerPC implementations operating in big-endian mode do not require strict
alignment." (Python sys.byteorder reports 'big'.)

Maybe that's the reason why the alignment calculator "fails?" If gcc doesn't
align anything anyway what else can one expect?

This leads me to suggest a relatively unspecific patch:

Index: type_with_alignment.hpp
===================================================================
RCS file: /cvsroot/boost/boost/boost/type_traits/type_with_alignment.hpp,v
retrieving revision 1.10
diff -u -r1.10 type_with_alignment.hpp
--- type_with_alignment.hpp     16 Apr 2003 13:36:07 -0000      1.10
+++ type_with_alignment.hpp     26 May 2003 05:47:03 -0000
@@ -110,8 +110,10 @@
 
     BOOST_STATIC_CONSTANT(std::size_t, found = alignment_of<align_t>::value);
 
+#if !(defined(__APPLE__) && defined(__MACH__) && defined(__GNUC__))
     BOOST_STATIC_ASSERT(found >= Align);
     BOOST_STATIC_ASSERT(found % Align == 0);
+#endif
 
  public:
     typedef align_t type;


However, this raises the question "why do we need all the metaprogramming
overhead if the result is meaningless anyway?" Here is a more radical
suggestion:

Index: type_with_alignment.hpp
===================================================================
RCS file: /cvsroot/boost/boost/boost/type_traits/type_with_alignment.hpp,v
retrieving revision 1.10
diff -u -r1.10 type_with_alignment.hpp
--- type_with_alignment.hpp     16 Apr 2003 13:36:07 -0000      1.10
+++ type_with_alignment.hpp     26 May 2003 16:38:11 -0000
@@ -96,6 +96,14 @@
 
 } // namespace detail

+#if defined(__APPLE__) && defined(__MACH__) && defined(__GNUC__)
+template <int Align>
+class type_with_alignment
+{
+  public:
+    typedef char type;
+};
+#else
 // This alignment method originally due to Brian Parker, implemented by David
 // Abrahams, and then ported here by Doug Gregor.
 template <int Align>
@@ -116,6 +124,7 @@
  public:
     typedef align_t type;
 };
+#endif

 #else


Both solutions work. Thoughts?

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From dave at boost-consulting.com  Mon May 26 18:35:57 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 26 May 2003 12:35:57 -0400
Subject: [C++-sig] Re: instantiating python objects within C++
References: <OF79F9FB65.98F6B5EE-ONC1256D32.002FCF54@no>
Message-ID: <ur86lbr82.fsf@boost-consulting.com>

thor.arne.johansen at ibas.no writes:

> Stefan wrote:
> ...
>>I'd like to have my C++ object instantiated long
>>before the wrapper, i.e. I'd like to instantiate
>>the wrapper around an existing object for the
>>sole purpose of being able to manipulate it
>>from within a script that is temporarily loaded
>>and executed once, during the lifetime of the
>>application.
> ...
>
> I have the same need, and after getting som help on this list I came up
> with the following example:
>
> http://mail.python.org/pipermail/c++-sig/2002-December/002833.html
>
> I never got any feedback on this posting, so I don't know how 'good'
> the example is, but it seems to work allright.

Oh, I'm sorry you didn't get any feedback.  Dirk, do you have
anything to say about this one?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From seefeld at sympatico.ca  Mon May 26 19:10:31 2003
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Mon, 26 May 2003 13:10:31 -0400
Subject: [C++-sig] Re: instantiating python objects within C++
References: <f98cbc39db7a493b8a6b06ee21bceb563ece6c1f@Orthosoft.ca> <20030523190127.GA17673@upl.cs.wisc.edu> <a1e7d37248a9c4b31966633bceb4f2023ece7f6d@Orthosoft.ca> <3ECE9589.7020708@anim.dreamworks.com> <ufzn1d6d2.fsf@boost-consulting.com>
Message-ID: <259efaf9a4356902509dfccdde0c857c3ed24806@Orthosoft.ca>

Hi David,

David Abrahams wrote:

>     object FooClass
>         = class_<Foo>("Foo", init<int, char const*>())
>                .def( ... )
>                ...
>                ;
> 
>     object foo = FooClass(3, "hello");
> 
> Joel, we might want to do that example in two steps as shown above
> just to make it crystal clear what's happening.

yes, the 'missing link' was that I didn't understand what the above
really meant for the python interpreter. For example right now I'm
not even instantiating that class explicitely, I use a callable's
'()' operator. The python interpreter then figures out that it should
create the so defined wrapper object and wrap it around my existing
foo instance.
That is something I didn't understand (and still don't in detail).
Explaining that in greater detail would surely help, not only to
use boost.python, but also to understand how all the magic works.

Thanks,
		Stefan







From seefeld at sympatico.ca  Mon May 26 19:11:08 2003
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Mon, 26 May 2003 13:11:08 -0400
Subject: [C++-sig] Re: instantiating python objects within C++
References: <f98cbc39db7a493b8a6b06ee21bceb563ece6c1f@Orthosoft.ca> <3ED10120.1030900@sympatico.ca> <u7k8dd67m.fsf@boost-consulting.com>
Message-ID: <37182fc77ece8dbe5371176cc7049b933ed2482a@Orthosoft.ca>

David Abrahams wrote:

> Stefan, *please* tell me what you think a more prominent place would
> be!  Better yet, contribute a documentation patch!
> 
> [Maybe you should add it to Bruno's upcoming "Techniques" section?]

ok, I'll have a look.

		Stefan







From rwgk at yahoo.com  Mon May 26 20:29:36 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 26 May 2003 11:29:36 -0700 (PDT)
Subject: [C++-sig] Re: method_call_expr not supported by dump_expr
In-Reply-To: <u8ystesy7.fsf@boost-consulting.com>
Message-ID: <20030526182936.71488.qmail@web20208.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> > The error message ends with:
> >
> > boost::python::optional<
> > const
> > double &, boost::mpl::void_, boost::mpl::void_, ... boost::mpl::void_>
> >>::sequence2' is private
> >
> > I remember that this worked before you checked in the fairly massive set of
> > fixes a couple of days ago. Did something nasty creep in?
> 
> Slightly.  Please check out boost/mpl/joint_view.hpp and try again.

The "is private" problem is fixed, thanks!
But now we've succeeded in creating an example where the gcc 3.3 ICE under Mac
OS 10 doesn't go away even if I try all my tricks. :-( :-(
I am working with the gcc developers...
Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From dave at boost-consulting.com  Mon May 26 20:44:32 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 26 May 2003 14:44:32 -0400
Subject: [C++-sig] Re: instantiating python objects within C++
References: <f98cbc39db7a493b8a6b06ee21bceb563ece6c1f@Orthosoft.ca> <20030523190127.GA17673@upl.cs.wisc.edu>
 <a1e7d37248a9c4b31966633bceb4f2023ece7f6d@Orthosoft.ca>
 <3ECE9589.7020708@anim.dreamworks.com>
 <ufzn1d6d2.fsf@boost-consulting.com>
 <259efaf9a4356902509dfccdde0c857c3ed24806@Orthosoft.ca>
Message-ID: <u1xylbl9r.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> Hi David,
>
> David Abrahams wrote:
>
>>     object FooClass
>>         = class_<Foo>("Foo", init<int, char const*>())
>>                .def( ... )
>>                ...
>>                ;
>>     object foo = FooClass(3, "hello");
>> Joel, we might want to do that example in two steps as shown above
>> just to make it crystal clear what's happening.
>
> yes, the 'missing link' was that I didn't understand what the above
> really meant for the python interpreter. 

The interpreter, if you mean the thing that executes Python
bytecodes, isn't running this at all.

> For example right now I'm not even instantiating that class
> explicitely, I use a callable's '()' operator. 

That's what    

               FooClass(3, "hello")

is.

> The python interpreter then figures out that it should create the so
> defined wrapper object and wrap it around my existing foo instance.

It's not really clear to me just what you mean.

> That is something I didn't understand (and still don't in detail).
> Explaining that in greater detail would surely help, not only to use
> boost.python, but also to understand how all the magic works.

Hmm.  Well, yeah, a description of the conversion mechanisms would be
good to have.  I've been meaning to write one for a while.
Unfortunately, most of my time is currently being taken by other
(paying) work, and it's hard to justify giving that project priority
right now.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From jbrandmeyer at earthlink.net  Mon May 26 21:47:35 2003
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: 26 May 2003 15:47:35 -0400
Subject: [C++-sig] def( str( self)) error
Message-ID: <1053978454.1491.41.camel@illuvatar>

I have a class that uses an overloaded << and >> operators for I/O. 
When I try to export that class with the member function .def( str(
self)), I get a 'no function for call to' error.  My operator has the
following signature in C++, and works just fine for the standard
streams, and stringstreams:

namespace std 
{
template<typename char_T, class traits>
basic_ostream<char_T, traits>&
operator<<( basic_ostream<char_T, traits>& stream, const
physics::vector& v); // Definition not shown for brevity.
} // !namespace std

I'm using G++ 3.2.2, with identical errors on Win32/MinGW and Debian
Sid.

Thanks,
Jonathan

error quote ---------------
no matching function for call to boost::python::class_<physics::vector,
boost::python::detail::not_specified, (two more
times)>::def(boost::python::str)
----------- end quote-----




From dave at boost-consulting.com  Mon May 26 22:01:16 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 26 May 2003 16:01:16 -0400
Subject: [C++-sig] Re: def( str( self)) error
References: <1053978454.1491.41.camel@illuvatar>
Message-ID: <uptm5a35f.fsf@boost-consulting.com>

Jonathan Brandmeyer <jbrandmeyer at earthlink.net> writes:

> I have a class that uses an overloaded << and >> operators for I/O. 
> When I try to export that class with the member function .def( str(
> self)), I get a 'no function for call to' error.  My operator has the
> following signature in C++, and works just fine for the standard
> streams, and stringstreams:
>
> namespace std 
> {
> template<typename char_T, class traits>
> basic_ostream<char_T, traits>&
> operator<<( basic_ostream<char_T, traits>& stream, const
> physics::vector& v); // Definition not shown for brevity.
> } // !namespace std
>
> I'm using G++ 3.2.2, with identical errors on Win32/MinGW and Debian
> Sid.

Well, you're not allowed to add definitions to std:: - your function
should go in namespace physics.  I'm not sure that would make a
difference though; it seems it should be found by Koenig Lookup
either way.

Bug reporting and help requests 101: Why don't you post a small
reproducible example, and at least give the full text of the error
message?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Mon May 26 22:07:32 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 26 May 2003 16:07:32 -0400
Subject: [C++-sig] Re: Automatic (implicit ?) type conversion for a data member of a
 struct.
References: <bab5ku$h98$1@main.gmane.org> <3ECEB6F3.7080906@anim.dreamworks.com>
Message-ID: <uk7cda2uz.fsf@boost-consulting.com>

Gavin Doughtie <gdoughtie at anim.dreamworks.com> writes:

> 	// THIS FAILS MISERABLY
>      lvalue_from_pytype<CStringExtractor, &PyString_Type>();

It's no wonder; a Python string object doesn't contain an instance of
a CString, so anythin which tries to get a CString lvalue out of it
is bound to reference invalid memory.

You need an rvalue from_python converter.  You can find out more
about those here:

    http://www.boost.org/libs/python/doc/v2/faq.html#question2

HTH,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Mon May 26 22:15:43 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 26 May 2003 16:15:43 -0400
Subject: [C++-sig] Re: Automatic (implicit ?) type conversion for a data member of a
 struct.
References: <bab5ku$h98$1@main.gmane.org>
Message-ID: <uel2la2hc.fsf@boost-consulting.com>

"pj" <pjdurai at hotmail.com> writes:

> Greetings.
>
> Generally how would I enable automatic conversion for a given C++ type ?
>
> To be specific.
>
> I know how to expose this class to Python and exposing a function returning
> this struct.
> Its pretty easy due to the power of boost-python.
>
> class MyStruct
> {
>     std::string name;
> }
>
> MyStruct fuc1();
>
>
> What I cant figure out is how would I do this if the 'name' is not a type
> understood by boost-python.
> say ..
>
> class MyString;
>
> class MyStruct
> {
>     MyString name;
> }
>
> MyStruct fuc1();
>
> I _dont_ want to wrap the whole 'MyString' class to Python.
>
> I would like to expose 'MyStruct' to python so that the 'name' data
> member of MyStruct is _automatically_ _exposed_ as a python string ?
>
> I have tried the basic documentation and couldnt find the
> information I need.
>
> Appreciate your time.

See my response to Gavin Doughtie about rvalue converters.  There's
one detail you have to keep in mind, though: normally class data
members are exposed as lvalues when you do,
e.g. def_readonly(&MyStruct::name), so that you can do something like:

     >>> x = MyStruct()
     >>> x.name.mutate() # modify x.name
     >>> x.name.value()

and see the expected result.  Of course MyString objects are special
and can only be converted Python strings which copy their data.  If
you just wrap "name" in the usual way you'll get runtime errors when
you try to access it as an lvalue because there are no registered
lvalue converters.  Instead you need to make a property and use call
policies, e.g.:

        .add_property(
            "name"
           , make_getter(
                &MyStruct::name
              , return_value_policy<return_by_value>())
           , make_setter(&MyStruct::name))

        ...

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Mon May 26 22:49:02 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 26 May 2003 16:49:02 -0400
Subject: [C++-sig] Re: Mac OS 10 & type_with_alignment.hpp
References: <u65o2pv14.fsf@boost-consulting.com> <20030526164525.7466.qmail@web20203.mail.yahoo.com>
Message-ID: <uznl94eo1.fsf@boost-consulting.com>

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

> --- David Abrahams <dave at boost-consulting.com> wrote:
>> OK, please undo my suggested patch, and feel free to disable those
>> asserts on MacOSX :(
>
> Okey Dokey. According to this message:
>
> http://mail-index.netbsd.org/port-powerpc/1999/12/29/0001.html
>
> "PowerPC implementations operating in big-endian mode do not require strict
> alignment." (Python sys.byteorder reports 'big'.)

They don't require it but they prefer it (for speed).

> Maybe that's the reason why the alignment calculator "fails?" If gcc doesn't
> align anything anyway what else can one expect?

Everything is aligned, just that the alignment may be no more than
1-byte ;-).  There's no reason it should assert if everything reports
1-byte alignment.  What's happening is that your type appears to have
a default alignment which does not evenly divide any alignment of a
POD type we could think of.

> This leads me to suggest a relatively unspecific patch:
>
> Index: type_with_alignment.hpp
> ===================================================================
> RCS file: /cvsroot/boost/boost/boost/type_traits/type_with_alignment.hpp,v
> retrieving revision 1.10
> diff -u -r1.10 type_with_alignment.hpp
> --- type_with_alignment.hpp     16 Apr 2003 13:36:07 -0000      1.10
> +++ type_with_alignment.hpp     26 May 2003 05:47:03 -0000
> @@ -110,8 +110,10 @@
>  
>      BOOST_STATIC_CONSTANT(std::size_t, found = alignment_of<align_t>::value);
>  
> +#if !(defined(__APPLE__) && defined(__MACH__) && defined(__GNUC__))
>      BOOST_STATIC_ASSERT(found >= Align);
>      BOOST_STATIC_ASSERT(found % Align == 0);
> +#endif
>  
>   public:
>      typedef align_t type;


How is that unspecific?

> However, this raises the question "why do we need all the metaprogramming
> overhead if the result is meaningless anyway?" Here is a more radical
> suggestion:
>
> Index: type_with_alignment.hpp
> ===================================================================
> RCS file: /cvsroot/boost/boost/boost/type_traits/type_with_alignment.hpp,v
> retrieving revision 1.10
> diff -u -r1.10 type_with_alignment.hpp
> --- type_with_alignment.hpp     16 Apr 2003 13:36:07 -0000      1.10
> +++ type_with_alignment.hpp     26 May 2003 16:38:11 -0000
> @@ -96,6 +96,14 @@
>  
>  } // namespace detail
>
> +#if defined(__APPLE__) && defined(__MACH__) && defined(__GNUC__)
> +template <int Align>
> +class type_with_alignment
> +{
> +  public:
> +    typedef char type;
> +};
> +#else
>  // This alignment method originally due to Brian Parker, implemented by David
>  // Abrahams, and then ported here by Doug Gregor.
>  template <int Align>
> @@ -116,6 +124,7 @@
>   public:
>      typedef align_t type;
>  };
> +#endif
>
>  #else
>
>
> Both solutions work. Thoughts?

You might find significant performance degradation from the 2nd
approach.  Lots of types probably still get the preferred
alignment with the 1st one.

---
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From brian at hypereyes.com  Mon May 26 23:06:35 2003
From: brian at hypereyes.com (Brian Luft)
Date: Mon, 26 May 2003 14:06:35 -0700
Subject: [C++-sig] Assertion Error using Pyste
In-Reply-To: <20030526200801.8280.49071.Mailman@mail.python.org>
Message-ID: <OPEPLKBBDKAJPDILJNJPIEEGCAAA.brian@hypereyes.com>

I am receiving an assertion error in Exporter.py, line 59, in
GetDeclaration:
assert len(decls) == 1


I am using Python 2.2, the most recent version of GCC_XML, on WinXP Pro.

Anyone know of any warning flags or tips to point me in the right direction?

Thanks
Brian





From nicodemus at globalite.com.br  Tue May 27 04:13:38 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Mon, 26 May 2003 18:13:38 -0800
Subject: [C++-sig] Re: Recent changes to FAQ
In-Reply-To: <ullwtbr1y.fsf@boost-consulting.com>
References: <20030523210210.74986.qmail@web20207.mail.yahoo.com> <3ECED438.9030308@globalite.com.br> <ullwtbr1y.fsf@boost-consulting.com>
Message-ID: <3ED2C9D2.3070805@globalite.com.br>

David Abrahams wrote:

>Nicodemus,
>
>Stop asking permission and go ahead!  We can always clean any
>problems up later.
>
>Thanks,
>

Done, I added the section to the quickdoc source file. Joel, could you 
regenerate the htmls with your quickdoc, since mine is slighly different 
than yours? Feedback is highly appreciated!

Regards,
Nicodemus.





From nicodemus at globalite.com.br  Tue May 27 04:15:31 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Mon, 26 May 2003 18:15:31 -0800
Subject: [C++-sig] Assertion Error using Pyste
In-Reply-To: <OPEPLKBBDKAJPDILJNJPIEEGCAAA.brian@hypereyes.com>
References: <OPEPLKBBDKAJPDILJNJPIEEGCAAA.brian@hypereyes.com>
Message-ID: <3ED2CA43.90906@globalite.com.br>

Brian Luft wrote:

>I am receiving an assertion error in Exporter.py, line 59, in
>GetDeclaration:
>assert len(decls) == 1
>
>
>I am using Python 2.2, the most recent version of GCC_XML, on WinXP Pro.
>
>Anyone know of any warning flags or tips to point me in the right direction?
>
>Thanks
>Brian
>

What Pyste version are you using? If you're not using the latest version 
from CVS, I suggest you do so: a bug that has been nailed recently could 
probably solve this problem.

Regards,
Nicodemus.





From rwgk at yahoo.com  Mon May 26 23:18:21 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 26 May 2003 14:18:21 -0700 (PDT)
Subject: [C++-sig] Re: Mac OS 10 & type_with_alignment.hpp
In-Reply-To: <uznl94eo1.fsf@boost-consulting.com>
Message-ID: <20030526211821.96439.qmail@web20201.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> > Both solutions work. Thoughts?
> 
> You might find significant performance degradation from the 2nd
> approach.  Lots of types probably still get the preferred
> alignment with the 1st one.

OK, I've checked in the patch that simply disables the static assertions.

I think of it as being "relatively unspecific" because it doesn't test for the
gcc version.

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From nicodemus at globalite.com.br  Tue May 27 04:18:52 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Mon, 26 May 2003 18:18:52 -0800
Subject: [C++-sig] exception specifiers and pyste
In-Reply-To: <3ECEAAC4.70308@globalite.com.br>
References: <3ECD5E92.9020308@anim.dreamworks.com> <3ECEAAC4.70308@globalite.com.br>
Message-ID: <3ED2CB0C.2060307@globalite.com.br>

Nicodemus wrote:

> Gavin Doughtie wrote:
>
>> So, I turned pyste loose on a C++ header that included "throw 
>> (AnException)" on a virtual method. Pyste generated a wrapper class 
>> that implemented a call_method<> implementation of the method, but 
>> did not automatically include the "throw" declaration, causing 
>> compilation of the generated C++ to fail with a "looser throw 
>> specifier for..." error.
>>
>> Is this a shortcoming of pyste?
>
>
> It's a shortcoming, I completely forgot about exception specifiers 
> while implementing Pyste. Thanks for the reminder Gavin.
>
> Regards,
> Nicodemus. 


Bad news: GCCXML doesn't seem to output this information... so the short 
term answer is that Pyste for now won't support it... sorry!

Regards,
Nicodemus.





From jbrandmeyer at earthlink.net  Mon May 26 23:21:27 2003
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: 26 May 2003 17:21:27 -0400
Subject: [C++-sig] Re: def( str( self)) error
In-Reply-To: <20030526200801.8280.49071.Mailman@mail.python.org>
References: <20030526200801.8280.49071.Mailman@mail.python.org>
Message-ID: <1053984087.1492.85.camel@illuvatar>

On Mon, 2003-05-26 at 16:08, David Abrahams wrote:

> From: David Abrahams <>
> Date: Mon, 26 May 2003 16:01:16 -0400
> Subject: [C++-sig] Re: def( str( self)) error
> Reply-To: c++-sig at python.org

> > I'm using G++ 3.2.2, with identical errors on Win32/MinGW and Debian
> > Sid.
> 
> Well, you're not allowed to add definitions to std:: - your function
> should go in namespace physics.  I'm not sure that would make a
> difference though; it seems it should be found by Koenig Lookup
> either way.

Done.

> Bug reporting and help requests 101: Why don't you post a small
> reproducible example, and at least give the full text of the error
> message?

Very well, here it is:
------ testme.cpp --------
#include <istream>
#include <ostream>
#include <boost/python.hpp>

namespace physics
{

class vector
{
public:
  double x, y, z;
};

template<typename char_T, class traits>
std::basic_ostream<char_T,traits>&
operator<<( std::basic_ostream<char_T,traits>& stream, const vector& v)
{
  std::basic_ostringstream<char_T,traits> s;
  s.copyfmt( stream);
  s.width( 0);

  s << "<" << v.x << "," << v.y << "," << v.z << ">";
  stream << s.str();

  return stream;
}

template< typename char_T, class traits>
std::basic_istream< char_T,traits>&
operator>>( std::basic_istream<char_T,traits>& stream, const vector& v)
{
  double x, y, z;
  char_T ch;

  stream >> ch;
  if (ch == '<') {
    stream >> x >> ch;
    if (ch == ',') {
      stream >> y >> ch;
      if (ch == ',') {
        stream >> z >> ch;
        v = vector( x, y, z);
      } else if (ch == '>') {
        v = vector( x, y);
      } else {
        stream.setstate( std::ios::failbit);
      }
    } else {
      stream.setstate( std::ios::failbit);
    }
  } else {
    stream.setstate( std::ios::failbit);
  }
  return stream;
}
} // !namespace physics

using namespace boost::python;

BOOST_PYTHON_MODULE(libphysics)
{
  class_< physics::vector>( "vector")
    .def( str( self))
    ;
}

compiled with:
$ g++-3.2 -c -o testme.lo -fpic -I/usr/include/python2.2 testme.cpp
testme.cpp: In function `void init_module_libphysics()':
testme.cpp:67: no matching function for call to `
   boost::python::class_<physics::vector,
boost::python::detail::not_specified,
   boost::python::detail::not_specified,
boost::python::detail::not_specified>
   ::def(boost::python::str)'







From jbrandmeyer at earthlink.net  Mon May 26 23:33:01 2003
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: 26 May 2003 17:33:01 -0400
Subject: [C++-sig] Re: def( str( self)) error
In-Reply-To: <1053984087.1492.85.camel@illuvatar>
References: <20030526200801.8280.49071.Mailman@mail.python.org>
	 <1053984087.1492.85.camel@illuvatar>
Message-ID: <1053984781.1492.88.camel@illuvatar>

On Mon, 2003-05-26 at 17:21, Jonathan Brandmeyer wrote:
> On Mon, 2003-05-26 at 16:08, David Abrahams wrote:
> > > I'm using G++ 3.2.2, with identical errors on Win32/MinGW and Debian
> > > Sid.

Almost forgot, I'm using Boost.Python version 1.30.0 on MinGW and
1.30.0-2 (debian patches, I suppose) on Debian.

-Jonathan




From gavin at doughtie.com  Tue May 27 00:13:20 2003
From: gavin at doughtie.com (Gavin Doughtie)
Date: Mon, 26 May 2003 15:13:20 -0700
Subject: [C++-sig] Re: instantiating python objects within C++
Message-ID: <3ED29180.8020302@doughtie.com>

So, I don't understand still --

If I want to

1) Write a class in C++
2) Write a wrapper class so that I can override its virtual functions in 
Python
3) Instantiate the C++ class with an arbitrary Python script that 
implements one of the overridden virtual functions *from C++*
and
4) Call the virtual function from C++ and get the Python implementation

I don't have to run the interpreter myself? boost::python will somehow 
do this for me??? Magic, I say! (cowers in fear from the miracle of fire)

Gavin

>> I just did this last week. You DO have to run the interpreter...
> 
> No, ya don't.
> 
>> ...which
>> then loads a python script, which imports your exported C++ class that
>> you've written (or generated) a wrapper class for that has the
>> call_method implementations of your virtual functions. When you
>> extract to a pointer of your base class, you've really got a pointer
>> to the wrapper class which calls back into the python code.
> 
> Wow! That's really complicated!
> 
> See the last example at
> http://www.boost.org/libs/python/doc/tutorial/doc/derived_object_types.html
> 
>     object FooClass
>         = class_<Foo>("Foo", init<int, char const*>())
>                .def( ... )
>                ...
>                ;
> 
>     object foo = FooClass(3, "hello");
> 
> Joel, we might want to do that example in two steps as shown above
> just to make it crystal clear what's happening.





From rwgk at yahoo.com  Tue May 27 00:37:17 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 26 May 2003 15:37:17 -0700 (PDT)
Subject: [C++-sig] Re: Recent changes to FAQ
In-Reply-To: <3ED2C9D2.3070805@globalite.com.br>
Message-ID: <20030526223717.68305.qmail@web20204.mail.yahoo.com>

--- Nicodemus <nicodemus at globalite.com.br> wrote:
> Done, I added the section to the quickdoc source file. Joel, could you 
> regenerate the htmls with your quickdoc, since mine is slighly different 
> than yours? Feedback is highly appreciated!

This looks great! I've corrected a minor typo.

I was thinking that C++ identifiers starting with an underscore are reserved
for the C++ implementation. Wouldn't it be safer to advertise a different
convention? E.g. I'm using _ext (core_ext, io_ext, etc.).

For multi-platform projects it can be problematic to mix Python sources and
compiled binaries in one directory. Fortunately it is quite easy to keep the
compiled extensions and the Python code separate. E.g.:

platform_specific_build_directory/ # binaries only
  sounds_boost/
    __init__.py
    core_ext.pyd
    io_ext.pyd

central_source_code_directory/
  sounds/ # the sources only
    __init__.py
    core.py
    io.py

The user has to add both the central_source_code_directory and the
platform_specific_build_directory to the PYTHONPATH.

In, e.g., core.py:

from sounds_boost.core_ext import *

Another trick that can be handy:

import sounds_boost.core_ext as ext

def point(x=0, y=0):
  return ext.point(x,y)

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From nikolai at micon.no  Tue May 27 01:40:46 2003
From: nikolai at micon.no (Nikolai Kirsebom)
Date: Tue, 27 May 2003 01:40:46 +0200
Subject: [C++-sig] Converting CString to/from std::string
Message-ID: <000001c323e0$3b4993b0$3693d9c1@micon2000>

I have a rather large set of C++ classes I want to make accessible
(initially only parts of some of the classes) from Python.  I cannot
change the classes as they are defined and used throughout a large
application.  Some of the methods take CString as parameters and others
return CString values.

Does anyone have suggestion on how I can convert these parameters so
that I can use Boost.Python to generate the wrapper code.

Thanks for any help.
Nikolai Kirsebom

PS: My posting earlier today
http://mail.python.org/pipermail/c++-sig/2003-May/004065.html has in the
example code a method returning a CString and this was the problem (as
correctly pointed out by Brett Calcott).

 




From seefeld at sympatico.ca  Tue May 27 01:53:29 2003
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Mon, 26 May 2003 19:53:29 -0400
Subject: [C++-sig] Re: instantiating python objects within C++
In-Reply-To: <u1xylbl9r.fsf@boost-consulting.com>
References: <f98cbc39db7a493b8a6b06ee21bceb563ece6c1f@Orthosoft.ca> <20030523190127.GA17673@upl.cs.wisc.edu> <a1e7d37248a9c4b31966633bceb4f2023ece7f6d@Orthosoft.ca> <3ECE9589.7020708@anim.dreamworks.com> <ufzn1d6d2.fsf@boost-consulting.com> <259efaf9a4356902509dfccdde0c857c3ed24806@Orthosoft.ca> <u1xylbl9r.fsf@boost-consulting.com>
Message-ID: <3ED2A8F9.8010109@sympatico.ca>

David Abrahams wrote:

>>The python interpreter then figures out that it should create the so
>>defined wrapper object and wrap it around my existing foo instance.
> 
> 
> It's not really clear to me just what you mean.

What I understood well from your tutorial was how to define python
type objects (wrappers around C++ classes) and how to inject them into
a given module. What I was missing was how to instantiate python
objects of these types. Once I'v seen it it appears quite 'natural' and
it was in fact such a simple construct that I was expecting. I guess
a simple example near the 'embedding' section in the tutorial would
clarify things a lot.

What I'm doing right now is this:

class Foo {/*...*/};


python::class_<Foo> foo_type("Foo");
      foo_type.add_property("value", &Foo::get_value, &Foo::set_value);

      python::object foo_wrapper = foo_type();
      main_namespace["object"] = foo_wrapper; // globale object, used later...

      FILE *fp = fopen("script.py", "r");
      python::handle<> result2(PyRun_File(fp, "script.py", Py_file_input,
                      main_namespace.ptr(), main_namespace.ptr()));

      python::object callable = python::extract<python::object>(main_namespace["set"]);
      callable(boost::reference_wrapper<Foo>(foo));

What I was missing here (and still don't really understand) is how the
definition of 'foo_type' above somewhere registers itself such that the call in the
last line will find it *at runtime*. That's what I was referring to with 'the python
interpreter'. Would 'python runtime' be a better term ?

> Hmm.  Well, yeah, a description of the conversion mechanisms would be
> good to have.

Absolutely, I guess that was the piece of the puzzle that I was missing.

Best regards,
		Stefan







From dave at boost-consulting.com  Tue May 27 02:16:06 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 26 May 2003 20:16:06 -0400
Subject: [C++-sig] Re: def( str( self)) error
References: <20030526200801.8280.49071.Mailman@mail.python.org> <1053984087.1492.85.camel@illuvatar>
Message-ID: <uptm5452x.fsf@boost-consulting.com>

Jonathan Brandmeyer <jbrandmeyer at earthlink.net> writes:

> using namespace boost::python;
>
> BOOST_PYTHON_MODULE(libphysics)
> {
>   class_< physics::vector>( "vector")
>     .def( str( self))
>     ;
> }
>
> compiled with:
> $ g++-3.2 -c -o testme.lo -fpic -I/usr/include/python2.2 testme.cpp
> testme.cpp: In function `void init_module_libphysics()':
> testme.cpp:67: no matching function for call to `
>    boost::python::class_<physics::vector,
> boost::python::detail::not_specified,
>    boost::python::detail::not_specified,
> boost::python::detail::not_specified>
>    ::def(boost::python::str)'

Easy workaround:

    BOOST_PYTHON_MODULE(libphysics)
    {
      class_< physics::vector>( "vector")
        .def( self_ns::str( self))
              ^^^^^^^^^
        ;
    }

GCC seems to have some problems with the Koenig Lookup rules :(.

-Dave
        
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Tue May 27 02:19:00 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 26 May 2003 20:19:00 -0400
Subject: [C++-sig] Re: Recent changes to FAQ
References: <3ED2C9D2.3070805@globalite.com.br> <20030526223717.68305.qmail@web20204.mail.yahoo.com>
Message-ID: <uk7cd44y3.fsf@boost-consulting.com>

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

> --- Nicodemus <nicodemus at globalite.com.br> wrote:
>> Done, I added the section to the quickdoc source file. Joel, could you 
>> regenerate the htmls with your quickdoc, since mine is slighly different 
>> than yours? Feedback is highly appreciated!
>
> This looks great! I've corrected a minor typo.
>
> I was thinking that C++ identifiers starting with an underscore are reserved
> for the C++ implementation. 

Only if they follow it with an uppercase letter or if they are at
global scope.


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From G.McCall at unsw.edu.au  Tue May 27 04:22:27 2003
From: G.McCall at unsw.edu.au (Grant McCall)
Date: Tue, 27 May 2003 12:22:27 +1000
Subject: [C++-sig] Chat rooms
Message-ID: <p05200f07baf87be6938d@[149.171.32.185]>

Did a search on chat rooms and turned up your page:

http://mail.python.org/pipermail/c++-sig/2002-May/001076.html

When I tried to access the advertised URL to see what you had on offer:

http://www.chat4webmasters.com/start.cfm

I got a notice that I was not authorised to access the site.

Your posting was from 2002, so is your Java chat room prog no longer available?

Thanks,

Grant



From rwgk at yahoo.com  Tue May 27 06:32:32 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 26 May 2003 21:32:32 -0700 (PDT)
Subject: [C++-sig] Re: Recent changes to FAQ
In-Reply-To: <uk7cd44y3.fsf@boost-consulting.com>
Message-ID: <20030527043232.47227.qmail@web20201.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> Only if they follow it with an uppercase letter or if they are at
> global scope.

Are the module names (e.g. _core in Bruno's examples) at global scope?
Thanks,
        Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From seefeld at sympatico.ca  Tue May 27 08:04:47 2003
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Tue, 27 May 2003 02:04:47 -0400
Subject: [C++-sig] how to obtain a (python) object's __name__ special attribute
Message-ID: <3ED2FFFF.1080402@sympatico.ca>

hi there,

I'v successfully read in a derived class definition from a python script
into my C++ application, and I have instantiated it. How can I now determine
the 'type name' of the object ? I try attr("__name__") but it appears
the __name__ attribute isn't visible as an ordinary attribute, i.e. this
call raises an exception.

Thanks,
		Stefan




From rwgk at yahoo.com  Tue May 27 08:46:19 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 26 May 2003 23:46:19 -0700 (PDT)
Subject: [C++-sig] Converting CString to/from std::string
In-Reply-To: <000001c323e0$3b4993b0$3693d9c1@micon2000>
Message-ID: <20030527064619.96193.qmail@web20206.mail.yahoo.com>

--- Nikolai Kirsebom <nikolai at micon.no> wrote:
> I have a rather large set of C++ classes I want to make accessible
> (initially only parts of some of the classes) from Python.  I cannot
> change the classes as they are defined and used throughout a large
> application.  Some of the methods take CString as parameters and others
> return CString values.
> 
> Does anyone have suggestion on how I can convert these parameters so
> that I can use Boost.Python to generate the wrapper code.

What do you want your CStrings to be in Python? Regular Python strings?
If you think "yes" remind yourself that Python strings are immutable.
I.e. if you have function signatures involving non-const references or
pointers to CString as arguments or return values the mapping from C++
CStrings to Python strings will not work very well.
More depending on your response.
Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From rwgk at yahoo.com  Tue May 27 08:52:50 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 26 May 2003 23:52:50 -0700 (PDT)
Subject: [C++-sig] how to obtain a (python) object's __name__ special attribute
In-Reply-To: <3ED2FFFF.1080402@sympatico.ca>
Message-ID: <20030527065250.98495.qmail@web20207.mail.yahoo.com>

--- Stefan Seefeld <seefeld at sympatico.ca> wrote:
> I'v successfully read in a derived class definition from a python script
> into my C++ application, and I have instantiated it. How can I now determine
> the 'type name' of the object ? I try attr("__name__") but it appears
> the __name__ attribute isn't visible as an ordinary attribute, i.e. this
> call raises an exception.

The object should have __class__, which should have a __name__:

>>> l = list()
>>> l.__class__.__name__
'list'
>>> l.__name__
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'list' object has no attribute '__name__'
>>> 

Could this be your problem?

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From dave at boost-consulting.com  Tue May 27 12:54:58 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 27 May 2003 06:54:58 -0400
Subject: [C++-sig] Re: Recent changes to FAQ
References: <uk7cd44y3.fsf@boost-consulting.com> <20030527043232.47227.qmail@web20201.mail.yahoo.com>
Message-ID: <u1xyk4q2l.fsf@boost-consulting.com>

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

> Are the module names (e.g. _core in Bruno's examples) at global scope?
> Thanks,
>         Ralf

They're not even C++ names!  I don't understand what the problem
might be.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Tue May 27 12:56:36 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 27 May 2003 06:56:36 -0400
Subject: [C++-sig] Re: Chat rooms
References: <p05200f07baf87be6938d@[149.171.32.185]>
Message-ID: <uvfvw3bff.fsf@boost-consulting.com>

Grant McCall <G.McCall at unsw.edu.au> writes:

> Did a search on chat rooms and turned up your page:
>
> http://mail.python.org/pipermail/c++-sig/2002-May/001076.html
>
> When I tried to access the advertised URL to see what you had on offer:
>
> http://www.chat4webmasters.com/start.cfm
>
> I got a notice that I was not authorised to access the site.
>
> Your posting was from 2002, so is your Java chat room prog no longer available?

Grant,

Nobody here is or ever was offering chat rooms; you only found that
message in our archives because our mailing list got spammed!

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From nikolai.kirsebom at siemens.no  Tue May 27 14:09:04 2003
From: nikolai.kirsebom at siemens.no (Kirsebom Nikolai)
Date: Tue, 27 May 2003 14:09:04 +0200
Subject: [C++-sig] Converting CString to/from std::string
Message-ID: <5B5544F322E5D211850F00A0C91DEF3B050DB65A@osll007a.siemens.no>


-----Original Message-----
From: Ralf W. Grosse-Kunstleve [mailto:rwgk at yahoo.com]
Sent: 27. mai 2003 08:46
To: c++-sig at python.org
Subject: Re: ?C++-sig? Converting CString to/from std::string


--- Nikolai Kirsebom <nikolai at micon.no> wrote:
> I have a rather large set of C++ classes I want to make accessible
> (initially only parts of some of the classes) from Python.  I cannot
> change the classes as they are defined and used throughout a large
> application.  Some of the methods take CString as parameters and others
> return CString values.
> 
> Does anyone have suggestion on how I can convert these parameters so
> that I can use Boost.Python to generate the wrapper code.

What do you want your CStrings to be in Python? Regular Python strings?
If you think "yes" remind yourself that Python strings are immutable.
I.e. if you have function signatures involving non-const references or
pointers to CString as arguments or return values the mapping from C++
CStrings to Python strings will not work very well.
More depending on your response.
Ralf


Some time ago I made a 'socket based' system (using BISON/FLEX for parsing)
where I expose C++ objects to python.  In this system CStrings are regular
Python strings.  So as an example I can write:
---------------------------------------------
C++:

class IF {
	CString MenuText;
	CString GetHelpText();
	int SetHelpText(CString s);
};

In Python:

o = IF()		# Behind the 'curtains' create a 'link' to a C++
object
print o.MenuText
s = o.GetHelpText(o.MenuText + "some text")
----------------------------------------------

So I would like something similar.

I'm very new to the Boost system and do not really have experience in C++
Template development so I find the Reference Manual somewhat difficult to
understand.  This may explain if I request 'dead easy' or 'impossible'
things.

Thanks for any help
Nikolai









From dave at boost-consulting.com  Tue May 27 14:44:31 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 27 May 2003 08:44:31 -0400
Subject: [C++-sig] Re: instantiating python objects within C++
References: <3ED29180.8020302@doughtie.com>
Message-ID: <ufzn01rv4.fsf@boost-consulting.com>

Gavin Doughtie <gavin at doughtie.com> writes:

> So, I don't understand still --
>
> If I want to
>
> 1) Write a class in C++
> 2) Write a wrapper class so that I can override its virtual functions
>    in Python
> 3) Instantiate the C++ class with an arbitrary Python script that
>    implements one of the overridden virtual functions *from C++*
> and
> 4) Call the virtual function from C++ and get the Python implementation
>
> I don't have to run the interpreter myself? boost::python will somehow
> do this for me??? 

No, the fact that you want to use a Python script in step 3 rules out
that possibility.  From his posting it wasn't clear that Stefan had
the same requirement, though.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Tue May 27 14:51:25 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 27 May 2003 08:51:25 -0400
Subject: [C++-sig] Re: instantiating python objects within C++
References: <f98cbc39db7a493b8a6b06ee21bceb563ece6c1f@Orthosoft.ca> <20030523190127.GA17673@upl.cs.wisc.edu>
 <a1e7d37248a9c4b31966633bceb4f2023ece7f6d@Orthosoft.ca>
 <3ECE9589.7020708@anim.dreamworks.com>
 <ufzn1d6d2.fsf@boost-consulting.com>
 <259efaf9a4356902509dfccdde0c857c3ed24806@Orthosoft.ca>
 <u1xylbl9r.fsf@boost-consulting.com> <3ED2A8F9.8010109@sympatico.ca>
Message-ID: <uadd81rjm.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> David Abrahams wrote:
>
>>>The python interpreter then figures out that it should create the so
>>>defined wrapper object and wrap it around my existing foo instance.
>> It's not really clear to me just what you mean.
>
> What I understood well from your tutorial was how to define python
> type objects (wrappers around C++ classes) and how to inject them into
> a given module. What I was missing was how to instantiate python
> objects of these types. Once I'v seen it it appears quite 'natural' and
> it was in fact such a simple construct that I was expecting. I guess
> a simple example near the 'embedding' section in the tutorial would
> clarify things a lot.

It's not really embedding-specific, but as I said before, we'd be
very happy to consider a doc patch from you.

> What I'm doing right now is this:
>
> class Foo {/*...*/};
>
>
> python::class_<Foo> foo_type("Foo");
>       foo_type.add_property("value", &Foo::get_value, &Foo::set_value);
>
>       python::object foo_wrapper = foo_type();
>       main_namespace["object"] = foo_wrapper; // globale object, used later...

    my_module.attr("object") = foo_wrapper; // equivalent

>       FILE *fp = fopen("script.py", "r");
>       python::handle<> result2(PyRun_File(fp, "script.py", Py_file_input,
>                       main_namespace.ptr(), main_namespace.ptr()));
>
>       python::object callable = python::extract<python::object>(main_namespace["set"]);

Why are you using extract<> here?  Isn't main_namespace a
boost::python::object whose operator[] returns an object?

>       callable(boost::reference_wrapper<Foo>(foo));
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    This is long-winded, and should be spelt: 

         boost::ref(foo)

    instead.
>
> What I was missing here (and still don't really understand) is how
> the definition of 'foo_type' above somewhere registers itself such
> that the call in the last line will find it *at runtime*. 

I still don't know what's going on because you've not shown a
definition for the name 'foo'.

> That's what I was referring to with 'the python interpreter'. Would
> 'python runtime' be a better term ?

Maybe.

>> Hmm.  Well, yeah, a description of the conversion mechanisms would be
>> good to have.
>
> Absolutely, I guess that was the piece of the puzzle that I was missing.

The Boost.Python shared library has a converter registry where all of
this information is stored.

HTH,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Tue May 27 16:17:26 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 27 May 2003 10:17:26 -0400
Subject: [C++-sig] Re: long long unsigned issue...
References: <b8uvp7$kp1$1@main.gmane.org> <uk7d8n8k7.fsf@boost-consulting.com>
 <b91g6e$me8$1@main.gmane.org> <u65oriktt.fsf@boost-consulting.com>
 <b91qci$oc6$1@main.gmane.org> <u1xzfiizj.fsf@boost-consulting.com>
 <b9292b$qru$1@main.gmane.org> <u65orxage.fsf@boost-consulting.com>
 <b96to4$d5$1@main.gmane.org> <uof2g6fhy.fsf@boost-consulting.com>
 <b9747j$vqv$1@main.gmane.org> <ufzns6czx.fsf@boost-consulting.com>
 <b97eg3$sod$1@main.gmane.org> <uvfwo2idm.fsf@boost-consulting.com>
 <b9s7dn$b0$1@main.gmane.org> <uu1boaql5.fsf@boost-consulting.com>
 <bajv6b$pe7$1@main.gmane.org>
Message-ID: <ud6i4zd6x.fsf@boost-consulting.com>

"Milind Patil" <milind_patil at hotmail.com> writes:

> Thanks Dave. The to_python conversion error has gone away.
>
> I am running accross a different issue now. My assumption was that once
> I had a way to convert python long to Y via long_, I should also be able to handle
> statements like
>
> x = hello.Y(2, 4294967295)
>
> possibly after adding
>
> implicitly_convertible<int, Y_Wrapper>();

How were you thinking the above implicitly_convertible call would
help, and which constructor overload did you expect it to pick?

> But this does not work. 

What does "does not work" mean?

> Is my assumption wrong? Any pointers as to where to look for a
> solution?

More information, please.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Tue May 27 16:25:44 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 27 May 2003 10:25:44 -0400
Subject: [C++-sig] Re: using BOOST_PYTHON_STATIC_LIB
References: <FCEMIEFBFOIDAOJDEPIAAEIIFFAA.domma@procoders.net>
Message-ID: <u4r3gzct3.fsf@boost-consulting.com>

"Achim Domma \(ProCoders\)" <domma at procoders.net> writes:

> Hello,
>
> is it still possible to use boost_python as static library? In config.hpp I
> found BOOST_PYTHON_STATIC_LIB, but it seems not to be mentioned anywhere in
> the documentation. I defined it like this in my Jamfile:
>
> <vc7><*><define>BOOST_PYTHON_STATIC_LIB
>
> Bjam is linking with libboost_python.lib then, but I get a lot of unresolved
> externals, all refering to boost.python functions using
> __declspec(dllimport) which seems wrong to me. Is it my fault or do I have
> to use the shared library?

You shouldn't have to use the shared library.  Oops, as far as I can
tell, if you're trying to use boost_python.lib from the bin-stage
directory, we have a problem: the import library for the Boost.Python
DLL has the same name, and overwrites the static library.  For the
time being, until we figure out how to fix this, you should dig into
the bin/... directories to find the static library build.

Rene, do you have a solution up your sleeve for this one?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Tue May 27 16:28:17 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 27 May 2003 10:28:17 -0400
Subject: [C++-sig] Re: list.len()
References: <200305261523.36319.phil@freehackers.org>
Message-ID: <uy90sxy4e.fsf@boost-consulting.com>

Philippe Fremy <phil at freehackers.org> writes:

> 	Hi,
>
> I am using boost 1.30 and I was surprised to discover that in 
> boost::python::list, there is no len() method. Am I mistaken or is 
> PyList_Size( my_list.ptr() ) the only way to get the length ?
>
> If so, I suggest to add it in the future. It is very common to use the size 
> of a list when operating upon it.

We should have it, but it should be a namespace-scope function, not a
method.  len(some_list) and len(some_tuple) should work equally well.
There are actually a whole suite of these functions which ought to be
in the library, added to namespace boost::python::api (see
boost/python/object_protocol.hpp for some examples).  Patches are
welcome, if they include user documentation and tests!

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From grafik666 at redshift-software.com  Tue May 27 17:11:38 2003
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Tue, 27 May 2003 10:11:38 -0500
Subject: [C++-sig] Re: using BOOST_PYTHON_STATIC_LIB
In-Reply-To: <u4r3gzct3.fsf@boost-consulting.com>
Message-ID: <20030527101140-r01010800-5e86989d-0860-0108@12.100.89.43>

[2003-05-27] David Abrahams wrote:

>"Achim Domma \(ProCoders\)" <domma at procoders.net> writes:
>
>> Hello,
>>
>> is it still possible to use boost_python as static library? In config.hpp
I
>> found BOOST_PYTHON_STATIC_LIB, but it seems not to be mentioned anywhere
in
>> the documentation. I defined it like this in my Jamfile:
>>
>> <vc7><*><define>BOOST_PYTHON_STATIC_LIB
>>
>> Bjam is linking with libboost_python.lib then, but I get a lot of
unresolved
>> externals, all refering to boost.python functions using
>> __declspec(dllimport) which seems wrong to me. Is it my fault or do I
have
>> to use the shared library?
>
>You shouldn't have to use the shared library.  Oops, as far as I can
>tell, if you're trying to use boost_python.lib from the bin-stage
>directory, we have a problem: the import library for the Boost.Python
>DLL has the same name, and overwrites the static library.  For the
>time being, until we figure out how to fix this, you should dig into
>the bin/... directories to find the static library build.
>
>Rene, do you have a solution up your sleeve for this one?

No trick solution needed. It should be putting the static lib to the
stage-bin with the "libboost_python.lib" name. At least that's what it looks
it does when I run the bjam in the libs/python/build directory. And from the
above message it looks like Achim is using that version of the lib.


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



From domma at procoders.net  Tue May 27 17:52:17 2003
From: domma at procoders.net (Achim Domma (ProCoders))
Date: Tue, 27 May 2003 17:52:17 +0200
Subject: [C++-sig] Re: using BOOST_PYTHON_STATIC_LIB
In-Reply-To: <20030527101140-r01010800-5e86989d-0860-0108@12.100.89.43>
Message-ID: <FCEMIEFBFOIDAOJDEPIAOENGFFAA.domma@procoders.net>

> No trick solution needed. It should be putting the static lib to the
> stage-bin with the "libboost_python.lib" name. At least that's
> what it looks
> it does when I run the bjam in the libs/python/build directory.
> And from the
> above message it looks like Achim is using that version of the lib.

Yes, that's true. I tried to use libboost_python.lib in the bin-stage
folder.

Achim




From domma at procoders.net  Tue May 27 17:55:53 2003
From: domma at procoders.net (Achim Domma (ProCoders))
Date: Tue, 27 May 2003 17:55:53 +0200
Subject: [C++-sig] Re: using BOOST_PYTHON_STATIC_LIB
In-Reply-To: <u4r3gzct3.fsf@boost-consulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIACENHFFAA.domma@procoders.net>

> You shouldn't have to use the shared library.

What does "shouldn't have to" mean? I know about the inter module support of
boost.python and wouldn't use a static version for 'normal' extension
modules. But I want to embed python in a COM object. If it's possible, I
would like to have no additional dll to ship. That's the reason for my
question: If it's supported, I would like to use it. If not, it's also no
problem.

Achim




From dave at boost-consulting.com  Tue May 27 17:57:53 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 27 May 2003 11:57:53 -0400
Subject: [C++-sig] Re: long long unsigned issue...
References: <b8uvp7$kp1$1@main.gmane.org> <uk7d8n8k7.fsf@boost-consulting.com>
 <b91g6e$me8$1@main.gmane.org> <u65oriktt.fsf@boost-consulting.com>
 <b91qci$oc6$1@main.gmane.org> <u1xzfiizj.fsf@boost-consulting.com>
 <b9292b$qru$1@main.gmane.org> <u65orxage.fsf@boost-consulting.com>
 <b96to4$d5$1@main.gmane.org> <uof2g6fhy.fsf@boost-consulting.com>
 <b9747j$vqv$1@main.gmane.org> <ufzns6czx.fsf@boost-consulting.com>
 <b97eg3$sod$1@main.gmane.org> <uvfwo2idm.fsf@boost-consulting.com>
 <b9s7dn$b0$1@main.gmane.org> <uu1boaql5.fsf@boost-consulting.com>
 <bajv6b$pe7$1@main.gmane.org> <ud6i4zd6x.fsf@boost-consulting.com>
Message-ID: <ud6i4xtz2.fsf@boost-consulting.com>

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

> "Milind Patil" <milind_patil at hotmail.com> writes:
>
>> Thanks Dave. The to_python conversion error has gone away.
>>
>> I am running accross a different issue now. My assumption was that once
>> I had a way to convert python long to Y via long_, I should also be able to handle
>> statements like
>>
>> x = hello.Y(2, 4294967295)
>>
>> possibly after adding
>>
>> implicitly_convertible<int, Y_Wrapper>();
>
> How were you thinking the above implicitly_convertible call would
> help, and which constructor overload did you expect it to pick?
>
>> But this does not work. 
>
> What does "does not work" mean?
>
>> Is my assumption wrong? Any pointers as to where to look for a
>> solution?
>
> More information, please.

One more note about this stuff: you have so many constructors and so
much potential for ambiguity it's hard to make sense of what you're
actually trying to achieve.  Maybe if you could say a little more
about that it would be easier to help you.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From wooley14 at yahoo.com  Tue May 27 18:34:28 2003
From: wooley14 at yahoo.com (Brian Luft)
Date: Tue, 27 May 2003 09:34:28 -0700 (PDT)
Subject: [C++-sig] Assertion Error using Pyste
In-Reply-To: <20030527001701.8466.62142.Mailman@mail.python.org>
Message-ID: <20030527163428.26925.qmail@web41406.mail.yahoo.com>

I am using the version that comes with Boost 1.30.0. 
I will certainly try the CVS version, thank you for
the tip

Brian

Nicodemus wrote:

What Pyste version are you using? If you're not using
the latest 
version 
from CVS, I suggest you do so: a bug that has been
nailed recently 
could 
probably solve this problem.

Regards,
Nicodemus.

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From dave at boost-consulting.com  Tue May 27 18:47:57 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 27 May 2003 12:47:57 -0400
Subject: [C++-sig] Re: using BOOST_PYTHON_STATIC_LIB
References: <u4r3gzct3.fsf@boost-consulting.com> <FCEMIEFBFOIDAOJDEPIACENHFFAA.domma@procoders.net>
Message-ID: <uvfvwwd36.fsf@boost-consulting.com>

"Achim Domma \(ProCoders\)" <domma at procoders.net> writes:

>> You shouldn't have to use the shared library.
>
> What does "shouldn't have to" mean? 

It means that linking to the static library is supposed to work.

> I know about the inter module support of boost.python and wouldn't
> use a static version for 'normal' extension modules. But I want to
> embed python in a COM object. If it's possible, I would like to have
> no additional dll to ship. That's the reason for my question: If
> it's supported, I would like to use it. If not, it's also no
> problem.

Well, it hasn't been tested recently, so I guess that means it's
likely to be broken :(.

But it's supposed to work.

As a matter of fact, it does work.  I just made the following change
to libs/python/test/Jamfile and ran the embedding test, which proves
it works:

    *** Jamfile.~1.59.~	Wed Mar 12 09:11:47 2003
    --- Jamfile	Tue May 27 12:44:23 2003
    ***************
    *** 55,65 ****
          boost-python-runtest $(name) : $(py) <pyd>$(modules) ;
      }

    ! run ../test/embedding.cpp <dll>../build/boost_python
        : # program args
        : # input files
        : # requirements
        $(PYTHON_PROPERTIES)
          <library-path>$(PYTHON_LIB_PATH)
            <$(gcc-compilers)><debug-python><library-path>$(CYGWIN_PYTHON_DEBUG_DLL_PATH)
              <$(gcc-compilers)><*><library-path>$(CYGWIN_PYTHON_DLL_PATH)
    --- 55,66 ----
          boost-python-runtest $(name) : $(py) <pyd>$(modules) ;
      }

    ! run ../test/embedding.cpp <lib>../build/boost_python
        : # program args
        : # input files
        : # requirements
        $(PYTHON_PROPERTIES)
    +     <define>BOOST_PYTHON_STATIC_LIB
          <library-path>$(PYTHON_LIB_PATH)
            <$(gcc-compilers)><debug-python><library-path>$(CYGWIN_PYTHON_DEBUG_DLL_PATH)
              <$(gcc-compilers)><*><library-path>$(CYGWIN_PYTHON_DLL_PATH)


So, as I said, I suspect name collision in the bin-stage directory.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Tue May 27 18:45:23 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 27 May 2003 12:45:23 -0400
Subject: [C++-sig] Re: using BOOST_PYTHON_STATIC_LIB
References: <u4r3gzct3.fsf@boost-consulting.com> <20030527101140-r01010800-5e86989d-0860-0108@12.100.89.43>
Message-ID: <u1xykxrrw.fsf@boost-consulting.com>

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

> [2003-05-27] David Abrahams wrote:
>
>>"Achim Domma \(ProCoders\)" <domma at procoders.net> writes:
>>
>>> Hello,
>>>
>>> is it still possible to use boost_python as static library? In config.hpp
> I
>>> found BOOST_PYTHON_STATIC_LIB, but it seems not to be mentioned anywhere
> in
>>> the documentation. I defined it like this in my Jamfile:
>>>
>>> <vc7><*><define>BOOST_PYTHON_STATIC_LIB
>>>
>>> Bjam is linking with libboost_python.lib then, but I get a lot of
> unresolved
>>> externals, all refering to boost.python functions using
>>> __declspec(dllimport) which seems wrong to me. Is it my fault or do I
> have
>>> to use the shared library?
>>
>>You shouldn't have to use the shared library.  Oops, as far as I can
>>tell, if you're trying to use boost_python.lib from the bin-stage
>>directory, we have a problem: the import library for the Boost.Python
>>DLL has the same name, and overwrites the static library.  For the
>>time being, until we figure out how to fix this, you should dig into
>>the bin/... directories to find the static library build.
>>
>>Rene, do you have a solution up your sleeve for this one?
>
> No trick solution needed. It should be putting the static lib to the
> stage-bin with the "libboost_python.lib" name. At least that's what it looks
> it does when I run the bjam in the libs/python/build directory. And from the
> above message it looks like Achim is using that version of the lib.

And how would that name differ from the name of the import library
used for libboost_python.dll?


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From grafik666 at redshift-software.com  Tue May 27 18:58:14 2003
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Tue, 27 May 2003 11:58:14 -0500
Subject: [C++-sig] Re: using BOOST_PYTHON_STATIC_LIB
In-Reply-To: <u1xykxrrw.fsf@boost-consulting.com>
Message-ID: <20030527115815-r01010800-64c2e213-0860-0108@12.100.89.43>

[2003-05-27] David Abrahams wrote:

>Rene Rivera <grafik666 at redshift-software.com> writes:
>
>> [2003-05-27] David Abrahams wrote:
>>
>>>"Achim Domma \(ProCoders\)" <domma at procoders.net> writes:
>>>
>>>> Hello,
>>>>
>>>> is it still possible to use boost_python as static library? In
config.hpp
>> I
>>>> found BOOST_PYTHON_STATIC_LIB, but it seems not to be mentioned
anywhere
>> in
>>>> the documentation. I defined it like this in my Jamfile:
>>>>
>>>> <vc7><*><define>BOOST_PYTHON_STATIC_LIB
>>>>
>>>> Bjam is linking with libboost_python.lib then, but I get a lot of
>> unresolved
>>>> externals, all refering to boost.python functions using
>>>> __declspec(dllimport) which seems wrong to me. Is it my fault or do I
>> have
>>>> to use the shared library?
>>>
>>>You shouldn't have to use the shared library.  Oops, as far as I can
>>>tell, if you're trying to use boost_python.lib from the bin-stage
>>>directory, we have a problem: the import library for the Boost.Python
>>>DLL has the same name, and overwrites the static library.  For the
>>>time being, until we figure out how to fix this, you should dig into
>>>the bin/... directories to find the static library build.
>>>
>>>Rene, do you have a solution up your sleeve for this one?
>>
>> No trick solution needed. It should be putting the static lib to the
>> stage-bin with the "libboost_python.lib" name. At least that's what it
looks
>> it does when I run the bjam in the libs/python/build directory. And from
the
>> above message it looks like Achim is using that version of the lib.
>
>And how would that name differ from the name of the import library
>used for libboost_python.dll?

Under Windows it produces:

    boost_python.dll
    boost_python.lib
    boost_python_debug.dll
    boost_python_debug.lib
    libboost_python.lib
    libboost_python_debug.lib

The significant part is that the static lib has the "lib" prefix.


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



From rwgk at yahoo.com  Tue May 27 18:59:31 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 27 May 2003 09:59:31 -0700 (PDT)
Subject: [C++-sig] Re: list.len()
In-Reply-To: <uy90sxy4e.fsf@boost-consulting.com>
Message-ID: <20030527165931.37181.qmail@web20210.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> We should have it, but it should be a namespace-scope function, not a
> method.  len(some_list) and len(some_tuple) should work equally well.
> There are actually a whole suite of these functions which ought to be
> in the library, added to namespace boost::python::api (see
> boost/python/object_protocol.hpp for some examples).  Patches are
> welcome, if they include user documentation and tests!

We have len() already. Look for "api_placeholder" and "len" in
boost/libs/python/src/object/pickle_support.cpp

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From grafik666 at redshift-software.com  Tue May 27 19:02:13 2003
From: grafik666 at redshift-software.com (Rene Rivera)
Date: Tue, 27 May 2003 12:02:13 -0500
Subject: [C++-sig] Re: using BOOST_PYTHON_STATIC_LIB
In-Reply-To: <uvfvwwd36.fsf@boost-consulting.com>
Message-ID: <20030527120214-r01010800-b66ed887-0860-0108@12.100.89.43>

[2003-05-27] David Abrahams wrote:

>"Achim Domma \(ProCoders\)" <domma at procoders.net> writes:
>
>>> You shouldn't have to use the shared library.
>>
>> What does "shouldn't have to" mean? 
>
>It means that linking to the static library is supposed to work.
>
>> I know about the inter module support of boost.python and wouldn't
>> use a static version for 'normal' extension modules. But I want to
>> embed python in a COM object. If it's possible, I would like to have
>> no additional dll to ship. That's the reason for my question: If
>> it's supported, I would like to use it. If not, it's also no
>> problem.
>
>Well, it hasn't been tested recently, so I guess that means it's
>likely to be broken :(.
>
>But it's supposed to work.
>
>As a matter of fact, it does work.  I just made the following change
>to libs/python/test/Jamfile and ran the embedding test, which proves
>it works:
>
>    *** Jamfile.~1.59.~    Wed Mar 12 09:11:47 2003
>    --- Jamfile    Tue May 27 12:44:23 2003
>    ***************
>    *** 55,65 ****
>          boost-python-runtest $(name) : $(py) <pyd>$(modules) ;
>      }
>
>    ! run ../test/embedding.cpp <dll>../build/boost_python
>        : # program args
>        : # input files
>        : # requirements
>        $(PYTHON_PROPERTIES)
>          <library-path>$(PYTHON_LIB_PATH)
>            
><$(gcc-compilers)><debug-python><library-path>$(CYGWIN_PYTHON_DEBUG_DLL_PATH)
>              <$(gcc-compilers)><*><library-path>$(CYGWIN_PYTHON_DLL_PATH)
>    --- 55,66 ----
>          boost-python-runtest $(name) : $(py) <pyd>$(modules) ;
>      }
>
>    ! run ../test/embedding.cpp <lib>../build/boost_python
>        : # program args
>        : # input files
>        : # requirements
>        $(PYTHON_PROPERTIES)
>    +     <define>BOOST_PYTHON_STATIC_LIB
>          <library-path>$(PYTHON_LIB_PATH)
>            
><$(gcc-compilers)><debug-python><library-path>$(CYGWIN_PYTHON_DEBUG_DLL_PATH)
>              <$(gcc-compilers)><*><library-path>$(CYGWIN_PYTHON_DLL_PATH)
>
>
>So, as I said, I suspect name collision in the bin-stage directory.

Perhaps you should show what the link command was with the above changes :-)

What I suspect is that Achim didn't do a clean when he switched. Since just
changing the <dll>.. to <lib> will NOT recompile the sources using the
library.


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



From giulio.eulisse at cern.ch  Tue May 27 19:04:00 2003
From: giulio.eulisse at cern.ch (Giulio Eulisse)
Date: 27 May 2003 19:04:00 +0200
Subject: [C++-sig] set_wrapper
Message-ID: <1054055040.19592.27.camel@lxcms25>

If I have a simple class

class A {}

and a function 

void f_A(void){...}

pyste's set_wrapper(A.f,"f_A") should, IMHO, generate

class_< A >("A", init<  >())
        .def(init< const A & >())
        .def("f", &f_A)
    ;
even if A::f() is not present. Is there a reason why it doesn't?

Thanks in advance,
Giulio




From stefan.seefeld at orthosoft.ca  Tue May 27 19:05:27 2003
From: stefan.seefeld at orthosoft.ca (Stefan Seefeld)
Date: Tue, 27 May 2003 13:05:27 -0400
Subject: [C++-sig] accessing the python type system
Message-ID: <8be22df0acd60639897b53a1aa74a17e3ed3986e@Orthosoft.ca>

hi there,

are there any functions/operators in boost.python to
let me access the python type system from within C++ ?

For example holding two python objects I'd like to test
whether one's type is derived from the other's type,
whether they are derived from a given type, i.e. things
like 'type', 'isinstance', etc.

Regards,
		Stefan




From rwgk at yahoo.com  Tue May 27 19:15:52 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 27 May 2003 10:15:52 -0700 (PDT)
Subject: [C++-sig] Re: Recent changes to FAQ
In-Reply-To: <u1xyk4q2l.fsf@boost-consulting.com>
Message-ID: <20030527171552.40630.qmail@web20210.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:
> 
> > Are the module names (e.g. _core in Bruno's examples) at global scope?
> > Thanks,
> >         Ralf
> 
> They're not even C++ names!  I don't understand what the problem
> might be.

Ah, OK, I forgot that the BOOST_PYTHON_MODULE macro prepends "init", so "_core"
ends up as the function name init_core(). Please disregard my remarks.
Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From rwgk at yahoo.com  Tue May 27 19:37:52 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 27 May 2003 10:37:52 -0700 (PDT)
Subject: [C++-sig] wrong semantics in boost/python/cast.hpp?
Message-ID: <20030527173752.98954.qmail@web20202.mail.yahoo.com>

When removing the "-w" option from the compilation command under Mac OS 10 the
g++ 3.3 compiler spits out the warning that is attached below. What do we think
about this?
Thanks,
        Ralf

Compilation command:

g++ -fPIC -ftemplate-depth-120 -DNDEBUG -O3 -DBOOST_PYTHON_MAX_BASES=2
-DBOOST_PYTHON_SOURCE -I/net_coral/scratch1/rwgk/bug/scitbx_2003_05_26/boost
-I/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3 -c -o
boost/libs/python/src/converter/arg_to_python_base.os
/net_coral/scratch1/rwgk/bug/scitbx_2003_05_26/boost/libs/python/src/converter/arg_to_python_base.cpp

Warning message:

BD Software STL Message Decryptor v2.35 for gcc
/net_coral/scratch1/rwgk/bug/scitbx_2003_05_26/boost/boost/python/cast.hpp: In
function
    `Target * boost::python::detail::upcast_impl(Source *, Target *) [with
Source = PyObject,
    Target = PyObject]':
/net_coral/scratch1/rwgk/bug/scitbx_2003_05_26/boost/boost/python/cast.hpp:92:
    instantiated from
    `PyObject * boost::python::upcast(PyObject *, PyObject *)'
/net_coral/scratch1/rwgk/bug/scitbx_2003_05_26/boost/boost/python/refcount.hpp:
    37:   instantiated from `void boost::python::xdecref(PyObject *)'
/net_coral/scratch1/rwgk/bug/scitbx_2003_05_26/boost/boost/python/handle.hpp:188
    :   instantiated from `boost::python::handle<PyObject>::~handle()'
/net_coral/scratch1/rwgk/bug/scitbx_2003_05_26/boost/libs/python/src/converter/
    arg_to_python_base.cpp:25:   instantiated from here       
/net_coral/scratch1/rwgk/bug/scitbx_2003_05_26/boost/boost/python/cast.hpp:81:
    warning: sorry:
semantics of inline function static data `const bool same' are wrong (
        you'll
wind up with multiple copies)
/net_coral/scratch1/rwgk/bug/scitbx_2003_05_26/boost/boost/python/cast.hpp:81:
    warning:
you can work around this by removing the initializer


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From rwgk at yahoo.com  Tue May 27 20:42:42 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 27 May 2003 11:42:42 -0700 (PDT)
Subject: [C++-sig] Converting CString to/from std::string
In-Reply-To: <5B5544F322E5D211850F00A0C91DEF3B050DB65A@osll007a.siemens.no>
Message-ID: <20030527184242.56902.qmail@web20210.mail.yahoo.com>

--- Kirsebom Nikolai <nikolai.kirsebom at siemens.no> wrote:
> Some time ago I made a 'socket based' system (using BISON/FLEX for parsing)
> where I expose C++ objects to python.  In this system CStrings are regular
> Python strings.

Attached is a small, self-contained demo extension module that shows how to do
what you want. Here is the corresponding trivial regression test:

from sandbx_boost import custom_string
assert custom_string.hello() == "Hello world."
assert custom_string.size("california") == 10

If you look at the code you will find:

1. A custom to_python converter (easy): custom_string_to_python_str

2. A custom lvalue converter (needs more code): custom_string_from_python_str

The custom converters are registered in the global Boost.Python registry near
the top of the module initialization function. Once flow control has passed
through the registration code the automatic conversions from and to Python
strings will work in any module imported in the same process.

HTH,
        Ralf

#include <boost/python/module.hpp>
#include <boost/python/def.hpp>
#include <boost/python/to_python_converter.hpp>

namespace sandbx { namespace {

  class custom_string
  {
    public:
      custom_string() {}
      custom_string(std::string const& value) : value_(value) {}
      std::string const& value() const { return value_; }
    private:
      std::string value_;
  };

  struct custom_string_to_python_str
  {
    static PyObject* convert(custom_string const& s)
    {
      return boost::python::incref(boost::python::object(s.value()).ptr());
    }
  };

  struct custom_string_from_python_str
  {
    custom_string_from_python_str()
    {
      boost::python::converter::registry::push_back(
        &convertible,
        &construct,
        boost::python::type_id<custom_string>());
    }

    static void* convertible(PyObject* obj_ptr)
    {
      if (!PyString_Check(obj_ptr)) return 0;
      return obj_ptr;
    }

    static void construct(
      PyObject* obj_ptr,
      boost::python::converter::rvalue_from_python_stage1_data* data)
    {
      const char* value = PyString_AsString(obj_ptr);
      if (value == 0) boost::python::throw_error_already_set();
      void* storage = (
        (boost::python::converter::rvalue_from_python_storage<custom_string>*)
          data)->storage.bytes;
      new (storage) custom_string(value);
      data->convertible = storage;
    }
  };

  custom_string hello() { return custom_string("Hello world."); }

  std::size_t size(custom_string const& s) { return s.value().size(); }

  void init_module()
  {
    using namespace boost::python;

    boost::python::to_python_converter<
      custom_string,
      custom_string_to_python_str>();

    custom_string_from_python_str();

    def("hello", hello);
    def("size", size);
  }

}} // namespace sandbx::<anonymous>

BOOST_PYTHON_MODULE(custom_string)
{
  sandbx::init_module();
}


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From dirk at gerrits.homeip.net  Tue May 27 21:06:11 2003
From: dirk at gerrits.homeip.net (Dirk Gerrits)
Date: Tue, 27 May 2003 21:06:11 +0200
Subject: [C++-sig] Re: instantiating python objects within C++
In-Reply-To: <ur86lbr82.fsf@boost-consulting.com>
References: <OF79F9FB65.98F6B5EE-ONC1256D32.002FCF54@no> <ur86lbr82.fsf@boost-consulting.com>
Message-ID: <bb0crb$19v$1@main.gmane.org>

David Abrahams wrote:
> thor.arne.johansen at ibas.no writes:
> 
> 
>>http://mail.python.org/pipermail/c++-sig/2002-December/002833.html
>>
>>I never got any feedback on this posting, so I don't know how 'good'
>>the example is, but it seems to work allright.
> 
> 
> Oh, I'm sorry you didn't get any feedback.  Dirk, do you have
> anything to say about this one?
> 

I remember seeing that post. But I didn't really know what to say about 
it then. Now that I've had more experience myself, I'll give it another 
whirl. :)

Well, with Boost.Python in its current form, this example is pretty 
good. I do have a some comments on stylistic C++ issues (#defines, 
printf, etc) but I assume that's not the kind of feedback you were 
hoping for. For the rest, I only have a few things to say:


Firstly, your use of PythonException seems unnecessary to me. Perhaps 
you didn't know, but Boost.Python already throws a C++ exception when a 
Python exception occurs (in most cases). You can find more info, and an 
example, in the tutorial: (URL might need some assembling)
http://boost.org/libs/python/doc/tutorial/doc/using_the_interpreter.html#exception_handling

In particular, you could write your import_module as this:

boost::python::handle<>
import_module(std::string const& module_name)
{
     return handle<>(
         PyImport_ImportModule(const_cast<char*>(module_name.c_str()) );
}

If PyImport_ImportModule fails, it returns 0, as you already know. The 
pointer passed to handle<>'s constructor will therefore be 0 as well. In 
turn, this will make it throw a boost::python::error_already_set 
exception. You can then catch this and use PyErr_Print, PyErr_Fetch 
(possible wrapped in a convenience function) or whatever.


Secondly, you can make the code clearer (and safer) by using handle<> 
and object where you currently use instead PyObject* and PY_XDECREF. 
Again, the details are in the tutorial: (URL might need some assembling) 
http://boost.org/libs/python/doc/tutorial/doc/using_the_interpreter.html#reference_counting_handles

For instance, your get_function would become:

boost::python::object
get_function(char const* func_name)
{
     using namespace boost::python;
     dict d(handle<>(PyModule_GetDict(module.get()));
     return d[func_name];
}

I hope you can imagine what it would do to a more complex piece of code, 
like the code from getExceptionDetail that you adapted.


Note that I didn't test any of the above code. I apologize if it doesn't 
quite work, but I hope you get the idea.


Lastly, I'd like to say that I've made a little class to be added to 
Boost.Python which would make this code a lot clearer and shorter still.

boost::python::interpreter will allow you to easily setup the 
interpreter, run scripts, evaluate expressions, etc. And all the while 
you'll be dealing with boost::python::objects, not PyObject*s and 
probably not even boost::python::handle<>s. There is however a 
Boost.Python bug to be fixed before this can be added.

hoping-that-was-helpful-ly yours,
Dirk Gerrits





From dave at boost-consulting.com  Tue May 27 21:15:59 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 27 May 2003 15:15:59 -0400
Subject: [C++-sig] Re: list.len()
References: <uy90sxy4e.fsf@boost-consulting.com> <20030527165931.37181.qmail@web20210.mail.yahoo.com>
Message-ID: <u3cj0dwuo.fsf@boost-consulting.com>

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

> --- David Abrahams <dave at boost-consulting.com> wrote:
>> We should have it, but it should be a namespace-scope function, not a
>> method.  len(some_list) and len(some_tuple) should work equally well.
>> There are actually a whole suite of these functions which ought to be
>> in the library, added to namespace boost::python::api (see
>> boost/python/object_protocol.hpp for some examples).  Patches are
>> welcome, if they include user documentation and tests!
>
> We have len() already. Look for "api_placeholder" and "len" in
> boost/libs/python/src/object/pickle_support.cpp

Hate to quibble, but...

Until it's documented and in a namespace with a permanent-sounding
name, it's still an unsupported feature and we don't really have it.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Tue May 27 21:16:55 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 27 May 2003 15:16:55 -0400
Subject: [C++-sig] Re: accessing the python type system
References: <8be22df0acd60639897b53a1aa74a17e3ed3986e@Orthosoft.ca>
Message-ID: <uwugcci8o.fsf@boost-consulting.com>

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

> hi there,
>
> are there any functions/operators in boost.python to
> let me access the python type system from within C++ ?
>
> For example holding two python objects I'd like to test
> whether one's type is derived from the other's type,
> whether they are derived from a given type, i.e. things
> like 'type', 'isinstance', etc.

These are more functions in the same category as len().  See my reply
to Philippe Fremy today on this list.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Tue May 27 21:24:49 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 27 May 2003 15:24:49 -0400
Subject: [C++-sig] Re: set_wrapper
References: <1054055040.19592.27.camel@lxcms25>
Message-ID: <ur86kchvi.fsf@boost-consulting.com>

Giulio Eulisse <giulio.eulisse at cern.ch> writes:

> If I have a simple class
>
> class A {}
>
> and a function 
>
> void f_A(void){...}
>
> pyste's set_wrapper(A.f,"f_A") should, IMHO, generate
>
> class_< A >("A", init<  >())
>         .def(init< const A & >())
>         .def("f", &f_A)
>     ;
> even if A::f() is not present. Is there a reason why it doesn't?

Maybe because that couldn't work.  Have you tried to compile and use
the wrapping code above from python?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Tue May 27 21:47:24 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 27 May 2003 15:47:24 -0400
Subject: [C++-sig] Re: wrong semantics in boost/python/cast.hpp?
References: <20030527173752.98954.qmail@web20202.mail.yahoo.com>
Message-ID: <ufzn0cgtv.fsf@boost-consulting.com>

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

> When removing the "-w" option from the compilation command under Mac OS 10 the
> g++ 3.3 compiler spits out the warning that is attached below. What do we think
> about this?
> Thanks,
>         Ralf
>
> Compilation command:
>     warning: sorry:
> semantics of inline function static data `const bool same' are wrong (
>         you'll
> wind up with multiple copies)
> /net_coral/scratch1/rwgk/bug/scitbx_2003_05_26/boost/boost/python/cast.hpp:81:
>     warning:

We think that the warning is wrong, but all the same, the "static"
keyword should be removed from the line in question.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From nicodemus at globalite.com.br  Wed May 28 04:07:17 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Tue, 27 May 2003 18:07:17 -0800
Subject: [C++-sig] Re: Recent changes to FAQ
In-Reply-To: <20030527171552.40630.qmail@web20210.mail.yahoo.com>
References: <20030527171552.40630.qmail@web20210.mail.yahoo.com>
Message-ID: <3ED419D5.2030102@globalite.com.br>

Ralf W. Grosse-Kunstleve wrote:

>--- David Abrahams <dave at boost-consulting.com> wrote:
>  
>
>>"Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:
>>
>>    
>>
>>>Are the module names (e.g. _core in Bruno's examples) at global scope?
>>>Thanks,
>>>        Ralf
>>>      
>>>
>>They're not even C++ names!  I don't understand what the problem
>>might be.
>>    
>>
>
>Ah, OK, I forgot that the BOOST_PYTHON_MODULE macro prepends "init", so "_core"
>ends up as the function name init_core(). Please disregard my remarks.
>Ralf
>

Just a little note: the leading underscore is a convention in Python, in 
the case where you have both code in extension modules and in pure 
Python. In the DLL directory of the Python distribution, you can see 
lots of files that follow that convention. 8)

Regards,
Nicodemus.




From nicodemus at globalite.com.br  Wed May 28 04:16:58 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Tue, 27 May 2003 18:16:58 -0800
Subject: [C++-sig] set_wrapper
In-Reply-To: <1054055040.19592.27.camel@lxcms25>
References: <1054055040.19592.27.camel@lxcms25>
Message-ID: <3ED41C1A.5000303@globalite.com.br>

Giulio Eulisse wrote:

>If I have a simple class
>
>class A {}
>
>and a function 
>
>void f_A(void){...}
>
>pyste's set_wrapper(A.f,"f_A") should, IMHO, generate
>
>class_< A >("A", init<  >())
>        .def(init< const A & >())
>        .def("f", &f_A)
>    ;
>even if A::f() is not present. Is there a reason why it doesn't?
>
>Thanks in advance,
>Giulio
>

Yeah, it doesn't have support to add methods to classes yet... I will 
look into it. You find the "set_wrapper" syntax good enough for this 
purpose, or perhaps an "add_method(name, func)" would be better?

Note also that the method you are trying to add must receive as first 
argument a reference or a pointer to the class, so your f_A function 
should be:

    void f_A(A&);

Regards,
Nicodemus.




From dirk at gerrits.homeip.net  Tue May 27 23:18:50 2003
From: dirk at gerrits.homeip.net (Dirk Gerrits)
Date: Tue, 27 May 2003 23:18:50 +0200
Subject: [C++-sig] Re: [newbie] Question on embedding/extending with boost::python
In-Reply-To: <bam1c6$27k$1@main.gmane.org>
References: <bam1c6$27k$1@main.gmane.org>
Message-ID: <bb0kk2$9q2$1@main.gmane.org>

Cross-posted to the C++ Sig. Please post all further replies there.

Chris Heald wrote:
> Hi all --
> 
> I'm working on an app that is going to be a C++ code engine which will be
> heavily extended through a series of Python scripts (objects, really). My
> desired requirements are as follows:
[snip]
> having trouble is with c and d - how do I give a Python app hooks into an
> existing C++ state machine? I know I can write an extension easily enough,
> but by my understanding, that will simply give the Python object access to a
> series of functions, and not the objects contained in the state machine that
> the interpreter is running under. I could use "pull" operations, wherein the
> C++ app polls the objects for changed state in a loop and updates its sate
> accordingly, but that seems that it wouldn't perform nearly so well as if
> the Python scripts were able to update the C++ state machine themselves, so
> I'm avoiding that route.

I'm not entirely sure what your problem is.

Have you looked at libs/python/test/embedding.cpp? It shows how your 
embedded interpreter can get access to the internals of the running C++ 
program. (Specifically, its classes.) Perhaps you can use that as a 
starting point?

> I had a co-worker suggest that I use Python as my primary execution
> environment instead of C++. While this would admittedly make some things
> easier, how much performance would I sacrifice with this route? I'm building
> a 3D application, and it doesn't seem that Python would be well-suited to
> such an application in terms of performance. There is potential for
> literally tens of thousands of instances of these objects to exist in this
> state machine, and I certainly don't want to hinder performance by moving
> the primary execution into an interpreted environment rather than a compiled
> environment.

Well, my common sense tells me that you may very well be right. But the 
important point is that there's really no way to tell, except for trying 
it out. (Profiling is the key.) And surely, writing the whole thing in 
Python (except for the critical sections) takes less time then writing 
the whole thing in C++ with just some things written in Python?

Taking this road could very well lead to disappointing performance as 
you say. But then you'd still have gained experience from making the 
Python prototype, and its C++ bits can most-likely be recycled anyway.

I don't really feel qualified to advise you to do one thing or the 
other. Embedding is sometimes the right/efficient way to do things, but 
such situations are becoming more and more rare. I am guessing that 
yours is such a situation, but you could argue that making a decision on 
such a guess is premature opimization (and therefore evil ;)). Perhaps 
others here can provide additional insights.

Regards,
Dirk Gerrits





From seefeld at sympatico.ca  Wed May 28 02:53:00 2003
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Tue, 27 May 2003 20:53:00 -0400
Subject: [C++-sig] Re: instantiating python objects within C++
In-Reply-To: <uadd81rjm.fsf@boost-consulting.com>
References: <f98cbc39db7a493b8a6b06ee21bceb563ece6c1f@Orthosoft.ca> <20030523190127.GA17673@upl.cs.wisc.edu> <a1e7d37248a9c4b31966633bceb4f2023ece7f6d@Orthosoft.ca> <3ECE9589.7020708@anim.dreamworks.com> <ufzn1d6d2.fsf@boost-consulting.com> <259efaf9a4356902509dfccdde0c857c3ed24806@Orthosoft.ca> <u1xylbl9r.fsf@boost-consulting.com> <3ED2A8F9.8010109@sympatico.ca> <uadd81rjm.fsf@boost-consulting.com>
Message-ID: <3ED4086C.1020502@sympatico.ca>

David Abrahams wrote:

> The Boost.Python shared library has a converter registry where all of
> this information is stored.

ok, this seems really to be the key. How does this work ? I'm a bit confused,
as conceptually the lines

BOOST_PYTHON_MODULE(Sandbox)
{
   python::class_<Base> base_type("Base");
   //...
}

create a type 'Sandbox.Base', i.e. the equivalent in C++ would be
something like 'Sandbox::Base'. However, 'Sandbox' isn't a type,
so I wonder how I can access the above type object from inside
C++.
Your example at the bottom of
http://www.boost.org/libs/python/doc/tutorial/doc/derived_object_types.html
hints a bit at how to instantiate such type objects, but I fail
to see how I could do that from within a different 'scope'.

What I'm really pondering about now is how to compare types, i.e.
if I'v obtained a type from a python script, and I want to
test whether this type derives from 'Sandbox.Base':

from Sandbox import *
class Derived(Base):
   def foobar(self): pass

I should be able to take the python::object that is the
(wrapper around the) python type, and compare it with the 'base_type'
from the above snippet, i.e. doing something like

python::handle<> result(PyRun_File(fp, const_cast<char *>(file.c_str()),
				   Py_file_input,
				   globals.ptr(), globals.ptr()));
python::object derived_type = globals["Derived"];

I want to compare 'derived_type' with 'base_type', for example using

Py_IsSubclass(derived_type.ptr(), base_type.ptr())

But how can I access 'base_type' ? It's a local variable in the scope of
'BOOST_PYTHON_MODULE(Sandbox), or is it ?

Kind regards,
		Stefan




From rwgk at yahoo.com  Wed May 28 08:32:31 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 27 May 2003 23:32:31 -0700 (PDT)
Subject: [C++-sig] Re: instantiating python objects within C++
In-Reply-To: <3ED4086C.1020502@sympatico.ca>
Message-ID: <20030528063231.18729.qmail@web20202.mail.yahoo.com>

--- Stefan Seefeld <seefeld at sympatico.ca> wrote:
> David Abrahams wrote:
> 
> > The Boost.Python shared library has a converter registry where all of
> > this information is stored.
> 
> ok, this seems really to be the key. How does this work ? I'm a bit confused,
> as conceptually the lines
> 
> BOOST_PYTHON_MODULE(Sandbox)
> {
>    python::class_<Base> base_type("Base");
>    //...
> }
> 
> create a type 'Sandbox.Base', i.e. the equivalent in C++ would be
> something like 'Sandbox::Base'. However, 'Sandbox' isn't a type,
> so I wonder how I can access the above type object from inside
> C++.

I cannot conclusively answer all your questions, but maybe I can help with one
piece of the puzzle: the central Boost.Python type conversion registry is *not*
scoped. It knows about your type only as, e.g., namespace1::namespace2::base.
If I understand correctly the class_<> constructor does two more or less
independent things (at runtime):

1. It registers the type conversions in the central registry with the C++ type
(in some form) as the key.

2. It adds a reference to the Python type (created at compile time!) to the
current scope().

I am sure the exact details are more involved and my view is maybe not 100%
accurate, but the mental model works for me.

Ralf


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com



From giulio.eulisse at cern.ch  Wed May 28 09:30:47 2003
From: giulio.eulisse at cern.ch (Giulio Eulisse)
Date: 28 May 2003 09:30:47 +0200
Subject: [C++-sig] set_wrapper
In-Reply-To: <3ED41C1A.5000303@globalite.com.br>
References: <1054055040.19592.27.camel@lxcms25> 
	<3ED41C1A.5000303@globalite.com.br>
Message-ID: <1054107047.20969.5.camel@lxcms25>

> Note also that the method you are trying to add must receive as first 
> argument a reference or a pointer to the class, so your f_A function 
> should be:
> 
>     void f_A(A&);

Yes, you are right, I miscopied the sample code I had, sorry. And I
agree with you that a add_method function would be more
self-explanatory. I tried to hack around the set_wrapper code in pyste
but I still have problems, when do you plan to implement such a feature?
Thanks in advance.

Ciao,
Giulio
PS: Are you aware of the fact that the CVS HEAD, as of yesterday, of
pyste is broken(at least in my case)?




From brett.calcott at paradise.net.nz  Wed May 28 11:52:37 2003
From: brett.calcott at paradise.net.nz (Brett Calcott)
Date: Wed, 28 May 2003 21:52:37 +1200
Subject: [C++-sig] Re: registering simple conversions from/to python
References: <basjrh$4m2$1@main.gmane.org> <ufzn1bqy6.fsf@boost-consulting.com>
Message-ID: <bb20vd$ser$1@main.gmane.org>

"David Abrahams" <dave at boost-consulting.com> wrote
>
> > I'd like to pythonise my classes a little by allowing tuples to be
> > passed to and from the data values.
> >
> > In python in would look something like this:
> >
> > class C(object):
> >     def __init__(self, x=0.0, y=0.0):
> >         self.x = x
> >         self.y = y
> >
> >     def get_xy(self):
> >         return self.x, self.y
> >
> >     def set_xy(self, xy):
> >         self.x, self.y = xy
> >
> >     xy = property(get_xy, set_xy)
> >
> >
> > I guess I would start by created a pair<x, x> object, and then
> > register inward and outward conversions for it.
> >
> > Is there a simple recipe for registering these conversions?
>
> Brett,
>
> I'm sorry, I can't tell what you're trying to do.  Could you please
> show an example of your C++ class and how you'd like to use it from
> Python?
>
Sorry, it was a little terse :)

The point is that in the python class above I can do this:

c = C()
c.x = 10.0
c.y = 5.0

But, with the property added, I can do this too:

c.xy = 10.0, 5.0

Which is kinda cool. I want to be able to do the same kind of thing from
C++. It is easy in boost_python to add a couple of data variables x and
y, but how to add the property wasn't obvious as I need to to be able to
unwrap and rewrap tuples/lists.

I think Ralf has supplied enough information to get me started.

Cheers,
Brett






From brett.calcott at paradise.net.nz  Wed May 28 11:59:19 2003
From: brett.calcott at paradise.net.nz (Brett Calcott)
Date: Wed, 28 May 2003 21:59:19 +1200
Subject: [C++-sig] Re: registering simple conversions from/to python
References: <basjrh$4m2$1@main.gmane.org> <20030526163524.93789.qmail@web20207.mail.yahoo.com>
Message-ID: <bb22lb$3gb$1@main.gmane.org>

"Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> wrote:
> > Is there a simple recipe for registering these conversions?
>
> I do something like this all the time, although I wouldn't claim that
> it is "simple." There are some hints here:
>
> http://www.boost.org/libs/python/doc/v2/faq.html#question2
>
> Alternative 2 seem most appropriate in your case. I would use
> boost:array<double, 2> as the vehicle for your data. Look here for a
> complete example:
>
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/scitbx/array_family/boost_python/regression_test_ext.cpp?rev=1.3&content-type=text/vnd.viewcvs-markup
>
> Look for:
>
>     boost::python::to_python_converter<
>       boost::array<int, 2>,
>       scitbx::boost_python::container_conversions::to_tuple<
>         boost::array<int, 2> > >();
>
> And:
>
>     scitbx::boost_python::container_conversions::from_python_sequence<
>       boost::array<double, 3>,
>       scitbx::boost_python::container_conversions::fixed_size_policy>();
>
> To be able to use this copy the header file
>
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/scitbx/include/scitbx/boost_python/container_conversions.h?rev=1.10&content-type=text/vnd.viewcvs-markup
>
> to your own project. There are no dependencies for this file other
> than boost.
>

Thanks, that looks like it will do the job. I had looked at this code
actually but I needed you to point out the relevant bits :)

Thanks for letting me plunder the code -- is something like this
worth putting back into the boost-python library?

Cheers,
Brett






From dave at boost-consulting.com  Wed May 28 12:47:22 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 28 May 2003 06:47:22 -0400
Subject: [C++-sig] Re: instantiating python objects within C++
References: <3ED4086C.1020502@sympatico.ca> <20030528063231.18729.qmail@web20202.mail.yahoo.com>
Message-ID: <usmqz9wlh.fsf@boost-consulting.com>

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

> --- Stefan Seefeld <seefeld at sympatico.ca> wrote:
>> David Abrahams wrote:
>> 
>> > The Boost.Python shared library has a converter registry where all of
>> > this information is stored.
>> 
>> ok, this seems really to be the key. How does this work ? I'm a bit confused,
>> as conceptually the lines
>> 
>> BOOST_PYTHON_MODULE(Sandbox)
>> {
>>    python::class_<Base> base_type("Base");
>>    //...
>> }
>> 
>> create a type 'Sandbox.Base', i.e. the equivalent in C++ would be
>> something like 'Sandbox::Base'. However, 'Sandbox' isn't a type,
>> so I wonder how I can access the above type object from inside
>> C++.
>
> I cannot conclusively answer all your questions, but maybe I can help with one
> piece of the puzzle: the central Boost.Python type conversion registry is *not*
> scoped. It knows about your type only as, e.g., namespace1::namespace2::base.
> If I understand correctly the class_<> constructor does two more or less
> independent things (at runtime):
>
> 1. It registers the type conversions in the central registry with the C++ type
> (in some form) as the key.
>
> 2. It adds a reference to the Python type (created at compile time!) to the
> current scope().

The Python type is created at runtime, ...

> I am sure the exact details are more involved and my view is maybe not 100%
> accurate, but the mental model works for me.

...but your mental model is basically correct.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Wed May 28 12:54:37 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 28 May 2003 06:54:37 -0400
Subject: [C++-sig] Re: instantiating python objects within C++
References: <f98cbc39db7a493b8a6b06ee21bceb563ece6c1f@Orthosoft.ca> <20030523190127.GA17673@upl.cs.wisc.edu>
 <a1e7d37248a9c4b31966633bceb4f2023ece7f6d@Orthosoft.ca>
 <3ECE9589.7020708@anim.dreamworks.com>
 <ufzn1d6d2.fsf@boost-consulting.com>
 <259efaf9a4356902509dfccdde0c857c3ed24806@Orthosoft.ca>
 <u1xylbl9r.fsf@boost-consulting.com> <3ED2A8F9.8010109@sympatico.ca>
 <uadd81rjm.fsf@boost-consulting.com> <3ED4086C.1020502@sympatico.ca>
Message-ID: <un0h79w9e.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> David Abrahams wrote:
>
>> The Boost.Python shared library has a converter registry where all of
>> this information is stored.
>
> ok, this seems really to be the key. How does this work ? 

You can "use the source, Luke" if you want to know how it's
implemented ;-)

> I'm a bit confused, as conceptually the lines
>
> BOOST_PYTHON_MODULE(Sandbox)
> {
>    python::class_<Base> base_type("Base");
>    //...
> }
>
> create a type 'Sandbox.Base', i.e. the equivalent in C++ would be
> something like 'Sandbox::Base'. However, 'Sandbox' isn't a type,

...right...

> so I wonder how I can access the above type object from inside C++.

I don't see what Sandbox being a type or a module has to do with it.
A Python type is just a kind of Python object.  When the class_< ... >
instantiation creates it, it holds onto it as well.

> Your example at the bottom of
> http://www.boost.org/libs/python/doc/tutorial/doc/derived_object_types.html
> hints a bit at how to instantiate such type objects, but I fail
> to see how I could do that from within a different 'scope'.

I don't know what you mean by 'scope' here.  Can't you spell out
explicitly what it is you'd like to do?  Code helps.

> What I'm really pondering about now is how to compare types, i.e.
> if I'v obtained a type from a python script, and I want to test
> whether this type derives from 'Sandbox.Base':
>
> from Sandbox import *
> class Derived(Base):
>    def foobar(self): pass
>
> I should be able to take the python::object that is the
> (wrapper around the) python type, and compare it with the 'base_type'
> from the above snippet, i.e. doing something like
>
> python::handle<> result(PyRun_File(fp, const_cast<char *>(file.c_str()),
> 				   Py_file_input,
> 				   globals.ptr(), globals.ptr()));
> python::object derived_type = globals["Derived"];
>
> I want to compare 'derived_type' with 'base_type', for example using
>
> Py_IsSubclass(derived_type.ptr(), base_type.ptr())
>
> But how can I access 'base_type' ? It's a local variable in the
> scope of 'BOOST_PYTHON_MODULE(Sandbox), or is it ?

Of course it is, the way you've written it.  You can always keep a
python::object 'save_base_type' around and assign into it:

       save_base_type = base_type;

A more-elegant way to hang onto it is:

python::object base_type;
BOOST_PYTHON_MODULE(Sandbox)
{
   base_type
       = python::class_<Base>("Base")
            .def(...)
            ...
            ;
}

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From brett.calcott at paradise.net.nz  Wed May 28 13:03:07 2003
From: brett.calcott at paradise.net.nz (Brett Calcott)
Date: Wed, 28 May 2003 23:03:07 +1200
Subject: [C++-sig] Re: [newbie] Question on embedding/extending with boost::python
References: <bam1c6$27k$1@main.gmane.org> <bb0kk2$9q2$1@main.gmane.org>
Message-ID: <bb24tg$d4f$1@main.gmane.org>

"Dirk Gerrits" <dirk at gerrits.homeip.net> wrote:
>
> Chris Heald wrote:
> > Hi all --
> >
> > I'm working on an app that is going to be a C++ code engine which
> > will be heavily extended through a series of Python scripts
> > (objects, really). My desired requirements are as follows:
> [snip]
> > having trouble is with c and d - how do I give a Python app hooks
> > into an existing C++ state machine? I know I can write an extension
> > easily enough, but by my understanding, that will simply give the
> > Python object access to a series of functions, and not the objects
> > contained in the state machine that the interpreter is running
> > under. I could use "pull" operations, wherein the C++ app polls the
> > objects for changed state in a loop and updates its sate
> > accordingly, but that seems that it wouldn't perform nearly so well
> > as if the Python scripts were able to update the C++ state machine
> > themselves, so I'm avoiding that route.
>
> I'm not entirely sure what your problem is.
>
> Have you looked at libs/python/test/embedding.cpp? It shows how your
> embedded interpreter can get access to the internals of the running
> C++ program. (Specifically, its classes.) Perhaps you can use that as
> a starting point?
>
> > I had a co-worker suggest that I use Python as my primary execution
> > environment instead of C++. While this would admittedly make some
> > things easier, how much performance would I sacrifice with this
> > route? I'm building a 3D application, and it doesn't seem that
> > Python would be well-suited to such an application in terms of
> > performance. There is potential for literally tens of thousands of
> > instances of these objects to exist in this state machine, and I
> > certainly don't want to hinder performance by moving the primary
> > execution into an interpreted environment rather than a compiled
> > environment.
>
> Well, my common sense tells me that you may very well be right. But
> the important point is that there's really no way to tell, except for
> trying it out. (Profiling is the key.) And surely, writing the whole
> thing in Python (except for the critical sections) takes less time
> then writing the whole thing in C++ with just some things written in
> Python?
>
> Taking this road could very well lead to disappointing performance as
> you say. But then you'd still have gained experience from making the
> Python prototype, and its C++ bits can most-likely be recycled anyway.
>
> I don't really feel qualified to advise you to do one thing or the
> other. Embedding is sometimes the right/efficient way to do things,
> but such situations are becoming more and more rare. I am guessing
> that yours is such a situation, but you could argue that making a
> decision on such a guess is premature opimization (and therefore evil
> ;)). Perhaps others here can provide additional insights.
>

I'm just about to head down a similar path. I have written some fairly
intensive multi-agent simulations in C++, and I am now moving my primary
development to python -- with a core engine being written in C++.

I had previously embedded python in my c++ app so that I could script my
agents, but the result was very slow as this effectively did this
(vastly simplified)

while (engine_running)
{
    for (agents_container:iterator a = agents.begin(); a !=
        agents.end(); ++a)
    {
        // here we call out to python for each agent
        (*a).update_yourself_via_python()
        update_visual_stuff()
    }
}

The calls to python are in the inner loop and this is slow.

What I am doing now is different - I am constructng an engine in C++,
making all the agents and world parameters accessible to python, BUT
the update main loop remains entirely in C++:

import engine # boost python module

while engine_running:
    engine.cycle()

What do I get out of this?

It makes it really easy to do all the mundane configuration stuff in
python. Hence I can do this...

for i in range(100):
    a = engine.Agent() # a C++ object export to python
    a.size = 10
    a.speed = 4
    a.x = random.uniform(0, 100)
    a.y = random.uniform(0, 100)
    engine.add_agent(a)

...because I don't care how fast the setup takes. I can also pause the
engine and inspect my agents, and interactively change them. Again
something that may be relatively slow because of all the python calls,
but it doesn't matter because it is happening in "user time" - whilst I
am interacting with it.

I can also change this stuff without going through any recompilation.

So, the framework, interface, and configuration are all in python, but
the bit that needs to be fast - cycling through thousands of agents and
updating them for each time step - is all in c++.

Anyway, that's the plan.. it's early days yet.

So...
What bits do you want to happen in python? And where do these lie in the
your program update loop (assuming it is some interactive graphics
program). I think you need to avoid crossing the python/C++ inside any
inner loops.


HTH,
Brett






From dave at boost-consulting.com  Wed May 28 13:17:31 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 28 May 2003 07:17:31 -0400
Subject: [C++-sig] Re: registering simple conversions from/to python
References: <basjrh$4m2$1@main.gmane.org> <ufzn1bqy6.fsf@boost-consulting.com>
 <bb20vd$ser$1@main.gmane.org>
Message-ID: <uznl78gms.fsf@boost-consulting.com>

"Brett Calcott" <brett.calcott at paradise.net.nz> writes:

> "David Abrahams" <dave at boost-consulting.com> wrote
>>
>> > I'd like to pythonise my classes a little by allowing tuples to be
>> > passed to and from the data values.
>> >
>> > In python in would look something like this:
>> >
>> > class C(object):
>> >     def __init__(self, x=0.0, y=0.0):
>> >         self.x = x
>> >         self.y = y
>> >
>> >     def get_xy(self):
>> >         return self.x, self.y
>> >
>> >     def set_xy(self, xy):
>> >         self.x, self.y = xy
>> >
>> >     xy = property(get_xy, set_xy)
>> >
>> >
>> > I guess I would start by created a pair<x, x> object, and then
>> > register inward and outward conversions for it.
>> >
>> > Is there a simple recipe for registering these conversions?
>>
>> Brett,
>>
>> I'm sorry, I can't tell what you're trying to do.  Could you please
>> show an example of your C++ class and how you'd like to use it from
>> Python?
>>
> Sorry, it was a little terse :)
>
> The point is that in the python class above I can do this:
>
> c = C()
> c.x = 10.0
> c.y = 5.0
>
> But, with the property added, I can do this too:
>
> c.xy = 10.0, 5.0
>
> Which is kinda cool. I want to be able to do the same kind of thing from
> C++. It is easy in boost_python to add a couple of data variables x and
> y, but how to add the property wasn't obvious as I need to to be able to
> unwrap and rewrap tuples/lists.
>
> I think Ralf has supplied enough information to get me started.

Ralf's info is good, but it appears to have nothing to do with this
problem.

All you need is to use the add_property method with a function which
takes a tuple:


      void set_xy(C& c, boost::python::tuple xy)
      {
          c.x = xy[0];
          c.y = xy[1];
          // should check that xy is only 2 elements long here
      }

      boost::python::tuple get_xy(C& c)
      {
           return boost::python::make_tuple(c.x, c.y);
      }

      class_<C>("C")
          .add_property("xy", get_xy, set_xy)
          ;

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From domma at procoders.net  Wed May 28 14:13:39 2003
From: domma at procoders.net (Achim Domma (ProCoders))
Date: Wed, 28 May 2003 14:13:39 +0200
Subject: [C++-sig] Re: using BOOST_PYTHON_STATIC_LIB
In-Reply-To: <20030527120214-r01010800-b66ed887-0860-0108@12.100.89.43>
Message-ID: <FCEMIEFBFOIDAOJDEPIAOEPNFFAA.domma@procoders.net>

> What I suspect is that Achim didn't do a clean when he switched.
> Since just
> changing the <dll>.. to <lib> will NOT recompile the sources using the
> library.

Thanks! It works now, so it must have been a mistake of this kind. After
rebuilding everything, I don't get unresolved externals anymore. I thought I
had done this before, but it seems that I have missed something.

Achim




From brett.calcott at paradise.net.nz  Wed May 28 14:35:57 2003
From: brett.calcott at paradise.net.nz (Brett Calcott)
Date: Thu, 29 May 2003 00:35:57 +1200
Subject: [C++-sig] Re: registering simple conversions from/to python
References: <basjrh$4m2$1@main.gmane.org> <ufzn1bqy6.fsf@boost-consulting.com> <bb20vd$ser$1@main.gmane.org> <uznl78gms.fsf@boost-consulting.com>
Message-ID: <bb2ac2$8be$1@main.gmane.org>


"David Abrahams" <dave at boost-consulting.com> wrote:
> > ...<snip>
> >
> > I think Ralf has supplied enough information to get me started.
>
> Ralf's info is good, but it appears to have nothing to do with this
> problem.
>
> All you need is to use the add_property method with a function which
> takes a tuple:
>
>
>       void set_xy(C& c, boost::python::tuple xy)
>       {
>           c.x = xy[0];
>           c.y = xy[1];
>
-- it needs this:
            c.x = extract<double>(xy[0]);
            c.y = extract<double>(xy[1]);

>           // should check that xy is only 2 elements long here
>       }
>
>       boost::python::tuple get_xy(C& c)
>       {
>            return boost::python::make_tuple(c.x, c.y);
>       }
>
>       class_<C>("C")
>           .add_property("xy", get_xy, set_xy)
>           ;
>

Wow! I was off on some wild goose chase making things complicated,
thinking I had to write custom converters..

This has got to count as one very funky technique. I expose my class,
and then add a bunch of pythonic functionality to it by declaring
functions of this kind.

Cheers, I'm off to bed.
Brett







From seefeld at sympatico.ca  Wed May 28 14:54:32 2003
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 28 May 2003 08:54:32 -0400
Subject: [C++-sig] Re: instantiating python objects within C++
References: <f98cbc39db7a493b8a6b06ee21bceb563ece6c1f@Orthosoft.ca> <20030523190127.GA17673@upl.cs.wisc.edu> <a1e7d37248a9c4b31966633bceb4f2023ece7f6d@Orthosoft.ca> <3ECE9589.7020708@anim.dreamworks.com> <ufzn1d6d2.fsf@boost-consulting.com> <259efaf9a4356902509dfccdde0c857c3ed24806@Orthosoft.ca> <u1xylbl9r.fsf@boost-consulting.com> <3ED2A8F9.8010109@sympatico.ca> <uadd81rjm.fsf@boost-consulting.com> <3ED4086C.1020502@sympatico.ca> <un0h79w9e.fsf@boost-consulting.com>
Message-ID: <888dbabbba2faf2cfa95143a340efcb93ed4af34@Orthosoft.ca>

David Abrahams wrote:

> I don't see what Sandbox being a type or a module has to do with it.
> A Python type is just a kind of Python object.  When the class_< ... >
> instantiation creates it, it holds onto it as well.

I see. My misunderstanding was that I thought the type would really
contain the scope, i.e. 'Sandbox.Base' wouldn't be the same type as
'Foobar.Base'. That's why I assumed the scope being a type would make
a difference.

> Of course it is, the way you've written it.  You can always keep a
> python::object 'save_base_type' around and assign into it:
> 
>        save_base_type = base_type;
> 
> A more-elegant way to hang onto it is:
> 
> python::object base_type;
> BOOST_PYTHON_MODULE(Sandbox)
> {
>    base_type
>        = python::class_<Base>("Base")
>             .def(...)
>             ...
>             ;
> }

cool. Again, I thought that this wasn't possible or else Sandbox.Base
would have to be the same as Foobar.Base. But if python doesn't care
for the scope itself when determining the type it's indeed the same.

Thanks a lot !

I'll try to get some remaining things straightened out, then I'll
see whether I can submit some examples for the tutorial.

Regards,
		Stefan





From seefeld at sympatico.ca  Wed May 28 15:02:05 2003
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 28 May 2003 09:02:05 -0400
Subject: [C++-sig] Re: accessing the python type system
References: <8be22df0acd60639897b53a1aa74a17e3ed3986e@Orthosoft.ca> <uwugcci8o.fsf@boost-consulting.com>
Message-ID: <36fee152f6305c4584d857754653a3823ed4b0f8@Orthosoft.ca>

David Abrahams wrote:
> Stefan Seefeld <stefan.seefeld at orthosoft.ca> writes:
> 
> 
>>hi there,
>>
>>are there any functions/operators in boost.python to
>>let me access the python type system from within C++ ?
>>
>>For example holding two python objects I'd like to test
>>whether one's type is derived from the other's type,
>>whether they are derived from a given type, i.e. things
>>like 'type', 'isinstance', etc.
> 
> 
> These are more functions in the same category as len().  See my reply
> to Philippe Fremy today on this list.

What about a 'type object' similar to 'type_info', i.e. with
a 'name()' accessor and comparison operators ?

Stefan





From rwgk at yahoo.com  Wed May 28 16:23:24 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 28 May 2003 07:23:24 -0700 (PDT)
Subject: [C++-sig] Re: registering simple conversions from/to python
In-Reply-To: <bb22lb$3gb$1@main.gmane.org>
Message-ID: <20030528142324.26285.qmail@web20210.mail.yahoo.com>

--- Brett Calcott <brett.calcott at paradise.net.nz> wrote:
> Thanks for letting me plunder the code -- is something like this
> worth putting back into the boost-python library?

I think that's where it should be, but I will not have the time to write the
required documentation any time soon, sorry. If someone wants to volunteer that
would be great (I could help a little). On the other hand if someone wants to
volunteer I'd put the builtin wrappers such as len(), hasattr(), isinstance()
etc. at a higher priority... as always, more to do than one can hope to get
done.
Ralf


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com



From dave at boost-consulting.com  Wed May 28 16:52:51 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 28 May 2003 10:52:51 -0400
Subject: [C++-sig] Re: registering simple conversions from/to python
References: <basjrh$4m2$1@main.gmane.org> <ufzn1bqy6.fsf@boost-consulting.com>
 <bb20vd$ser$1@main.gmane.org> <uznl78gms.fsf@boost-consulting.com>
 <bb2ac2$8be$1@main.gmane.org>
Message-ID: <uof1n86nw.fsf@boost-consulting.com>

"Brett Calcott" <brett.calcott at paradise.net.nz> writes:

> Wow! I was off on some wild goose chase making things complicated,
> thinking I had to write custom converters..
>
> This has got to count as one very funky technique. I expose my class,
> and then add a bunch of pythonic functionality to it by declaring
> functions of this kind.

Heck, you can even do this stuff to your extensions classes in pure
Python.  See http://attachments.gmane.org/zip00608.zip.att (save as
.zip file and unpack).

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Wed May 28 17:04:56 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 28 May 2003 11:04:56 -0400
Subject: [C++-sig] Re: accessing the python type system
References: <8be22df0acd60639897b53a1aa74a17e3ed3986e@Orthosoft.ca> <uwugcci8o.fsf@boost-consulting.com>
 <36fee152f6305c4584d857754653a3823ed4b0f8@Orthosoft.ca>
Message-ID: <uisrv863r.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> David Abrahams wrote:
>> Stefan Seefeld <stefan.seefeld at orthosoft.ca> writes:
>> 
>>>hi there,
>>>
>>>are there any functions/operators in boost.python to
>>>let me access the python type system from within C++ ?
>>>
>>>For example holding two python objects I'd like to test
>>>whether one's type is derived from the other's type,
>>>whether they are derived from a given type, i.e. things
>>>like 'type', 'isinstance', etc.
>> These are more functions in the same category as len().  See my reply
>> to Philippe Fremy today on this list.
>
> What about a 'type object' similar to 'type_info', i.e. with
> a 'name()' accessor and comparison operators ?

Well, if you have isinstance you don't need that.

In principle, there's no reason we shouldn't have something like you
propose, only it should be a wrapper around Python's 'type' just the
same way that boost::python::dict is a wrapper around Python's
'dict'...

...but once you start go go down that road you get in trouble.  Python
makes type(x) return a reference to x.__class__ (unless x is a
"classic" instance, in which case it returns "instance").  Because
type(type(x)) also has to work (get x's metatype), it can't have a
regular copy constructor.  When copies of an object are not equivalent
to the original in C++ it plays havoc.

I guess 'type' would have to be an instance of a class derived from
boost::python::object, whose unary function call operator returns its
argument's type.  I wouldn't want a 'name()' function because Python
type objects don't have that:

    >>> class X(object): pass
    ...
    >>> X.name()
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    AttributeError: type object 'X' has no attribute 'name'
    >>> X.__name__
    'X'

The equivalent in C++ would be X.attr("__name__")

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From seefeld at sympatico.ca  Wed May 28 17:58:19 2003
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 28 May 2003 11:58:19 -0400
Subject: [C++-sig] Re: accessing the python type system
References: <8be22df0acd60639897b53a1aa74a17e3ed3986e@Orthosoft.ca> <uwugcci8o.fsf@boost-consulting.com> <36fee152f6305c4584d857754653a3823ed4b0f8@Orthosoft.ca> <uisrv863r.fsf@boost-consulting.com>
Message-ID: <4044bacd7ee866c6aba323bb1a8234373ed4d9c2@Orthosoft.ca>

David Abrahams wrote:

>>What about a 'type object' similar to 'type_info', i.e. with
>>a 'name()' accessor and comparison operators ?
> 
> 
> Well, if you have isinstance you don't need that.

but 'isinstance' requires a type object to be passed, whether 'name()'
would permit to query that (or a 'stringified form' of it) from the
object in question.

> In principle, there's no reason we shouldn't have something like you
> propose, only it should be a wrapper around Python's 'type' just the
> same way that boost::python::dict is a wrapper around Python's
> 'dict'...

that's precisely what I have in mind.

> ...but once you start go go down that road you get in trouble.  Python
> makes type(x) return a reference to x.__class__ (unless x is a
> "classic" instance, in which case it returns "instance").  Because
> type(type(x)) also has to work (get x's metatype), it can't have a
> regular copy constructor.

Sorry, I don't understand that. the Python C Api provides 'type
objects', so ultimately I would arrive at a single root of that
'instance' <-> 'type' tree, i.e. the top node is a unique type
(a 'type type', actually). If I can't copy it there should be a
(possibly hidden) global instance (singleton ?) that is referenced
each time I access it, or else I make copies of it. In any case
the key is to define what 'equal' or 'identity' means.

> When copies of an object are not equivalent
> to the original in C++ it plays havoc.

yeah, so we need a well defined concept of comparison.

> I guess 'type' would have to be an instance of a class derived from
> boost::python::object, whose unary function call operator returns its
> argument's type.  I wouldn't want a 'name()' function because Python
> type objects don't have that:

agreed. I would be a concenience only.

Regards,
		Stefan






From rwgk at yahoo.com  Wed May 28 18:08:54 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 28 May 2003 09:08:54 -0700 (PDT)
Subject: [C++-sig] Re: registering simple conversions from/to python
In-Reply-To: <bb2ac2$8be$1@main.gmane.org>
Message-ID: <20030528160854.14417.qmail@web20206.mail.yahoo.com>

--- Brett Calcott <brett.calcott at paradise.net.nz> wrote:
> Wow! I was off on some wild goose chase making things complicated,
> thinking I had to write custom converters..

Hey, hey, hey... not so fast!
The add_property approach is cute but doesn't scale. Soon you will find that
you want to add, multiply, divide, etc. using operator overloading and that you
need a whole bunch of other member functions. Without the automatic from/to
Python tuple conversions you will have to write funky wrappers for each of your
overloaded operators or member functions. The custom converters are very
efficient in consolidating this clutter in one central place.

Besides, I forgot to point out this little helper at the bottom of
container_conversions.h:

#include <somewhere/container_conversions.h>
scitbx::boost_python::container_conversions::tuple_mapping_fixed_size<
  boost::array<double, 2> >();

One include and one line of code (in one of your module initialization
functions), that's all you need. In terms of code-to-write it beats the
add_property approach by an order of magnitude. Now move away from artificially
chopping your coordinate object into pieces (.x, .y) only to put it back
together later (.xy) and everything will magically fall into place (untested):

class C
{
  boost::array<double, 2> xy;
  
  C() {}
  C(boost::array<double, 2> const& xy_) : xy(xy_) {}

  boost::array<double, 2>
  operator+(boost::array<double, 2> const& other)
  {
    boost::array<double, 2> result;
    result[0] = xy[0] + other[0];
    result[1] = xy[1] + other[1];
    return result;
  }

  //etc.
};

class_<C>("C")
  .def(init<boost::array<double, 2> >())
  .def(self + self)
;

Ralf


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com



From dave at boost-consulting.com  Wed May 28 19:37:16 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 28 May 2003 13:37:16 -0400
Subject: [C++-sig] Re: registering simple conversions from/to python
References: <bb2ac2$8be$1@main.gmane.org> <20030528160854.14417.qmail@web20206.mail.yahoo.com>
Message-ID: <uk7cb6khf.fsf@boost-consulting.com>

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

> --- Brett Calcott <brett.calcott at paradise.net.nz> wrote:
>> Wow! I was off on some wild goose chase making things complicated,
>> thinking I had to write custom converters..
>
> Hey, hey, hey... not so fast!
>
> The add_property approach is cute but doesn't scale. Soon you will find that
> you want to add, multiply, divide, etc. using operator overloading and that you
> need a whole bunch of other member functions. 

Ralf, I think you are assuming a *lot* about what Brett wants to
accomplish.  The one example he showed gives me no reason to believe
that he wants to convert whole classes to/from Python tuples.  Maybe
he does really want that, and I just missed something... all he *said*
he wanted was:

  >>> obj.name_corresponding_to_several_cplusplus_data_members = some_tuple

For which to/from tuple conversions are little or no help.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Wed May 28 19:46:17 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 28 May 2003 13:46:17 -0400
Subject: [C++-sig] Re: accessing the python type system
References: <8be22df0acd60639897b53a1aa74a17e3ed3986e@Orthosoft.ca> <uwugcci8o.fsf@boost-consulting.com>
 <36fee152f6305c4584d857754653a3823ed4b0f8@Orthosoft.ca>
 <uisrv863r.fsf@boost-consulting.com>
 <4044bacd7ee866c6aba323bb1a8234373ed4d9c2@Orthosoft.ca>
Message-ID: <uel2j6k2e.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> David Abrahams wrote:
>
>>>What about a 'type object' similar to 'type_info', i.e. with
>>>a 'name()' accessor and comparison operators ?
>> Well, if you have isinstance you don't need that.
>
> but 'isinstance' requires a type object to be passed, whether 'name()'
> would permit to query that (or a 'stringified form' of it) from the
> object in question.
>
>> In principle, there's no reason we shouldn't have something like you
>> propose, only it should be a wrapper around Python's 'type' just the
>> same way that boost::python::dict is a wrapper around Python's
>> 'dict'...
>
> that's precisely what I have in mind.
>
>> ...but once you start go go down that road you get in trouble.  Python
>> makes type(x) return a reference to x.__class__ (unless x is a
>> "classic" instance, in which case it returns "instance").  Because
>> type(type(x)) also has to work (get x's metatype), it can't have a
>> regular copy constructor.
>
> Sorry, I don't understand that. 

If boost::python::type is a class like boost::python::dict is, then
type(x) is an instance of that class (OK so far) but type(type(x))
invokes type's copy constructor.  Those are just the syntax rules of
C++.  In order to be consistent with Python, type(type(x)) != type(x)
for most x,

    >>> type([])
    <type 'list'>
    >>> type(type([]))
    <type 'type'>

but that implies type's copy constructor doesn't make equivalent
copies (very bad in C++).

> the Python C Api provides 'type objects', so ultimately I would
> arrive at a single root of that 'instance' <-> 'type' tree

That makes no sense to me.  What is travelling up the tree to arrive
anywhere?

> , i.e. the top node is a unique type (a 'type type', actually). 

Yes, that's true but irrelevant AFAICT.

> If I can't copy it there should be a (possibly hidden) global
> instance (singleton ?)  that is referenced each time I access it, or
> else I make copies of it.

That's what I'm saying below

> In any case the key is to define what 'equal' or 'identity' means.

No, it's very clear what it means for two types to be identical.  They
have to be the same object.

>> When copies of an object are not equivalent to the original in C++
>> it plays havoc.
>
> yeah, so we need a well defined concept of comparison.

I don't think that's relevant, but it's already well-defined

    >>> list < tuple
    1
    >>> type([]) < type(())
    1

>> I guess 'type' would have to be an instance of a class derived from
>> boost::python::object, whose unary function call operator returns its
>> argument's type.  I wouldn't want a 'name()' function because Python
>> type objects don't have that:
>
> agreed. I would be a concenience only.
>

Patches welcome,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Wed May 28 20:05:26 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 28 May 2003 14:05:26 -0400
Subject: [C++-sig] Support for Indexing and Iteration Safety
Message-ID: <u65nv6j6h.fsf@boost-consulting.com>

I have some ideas about how to better support the indexing operator[]
and related thoughts about the safety of iterators.  Rather than
following my usual practice of posting a big tome about it which will
overwhelm everyone so they don't respond ;->, let me just point out a
few problems with the current Boost.Python implementation.  You let me
know if you care about any of these issues:

     1. Unlike most of the other operators, which can be wrapped using
        "self op other", there's no easy way to wrap the indexing
        operator.  You end up having to write your own __getitem__
        and __setitem__ functions.

     2. You also have to implement the code which raises an exception
        if the index is out of range or the key is not found (in case
        you're implementing a mapping).  If you forget, your extension
        class is prone to crashes and accessing invalid data.

     3. Even if you get that right, you may still be prone to crashes.
        Suppose you're wrapping a std::vector<SomeBigObject>.  If you
        want to support syntax like:

           >>> foo = vector_SomeBigObject(15)
           >>> foo[10].bar = 3 # modify an element in-place
        
        or if you just want to avoid unneccessarily copying the
        SomeBigObject element when you access it:

           >>> x = foo[10].bar

        then you have to use return_internal_reference in your
        __getitem__. All well and good. Even if you do:

           >>> del foo
           >>> print x

        your x is still valid because of the call policy; it is kept
        alive.  On the other hand, what if you do:

           >>> del foo[10]  # erase the 10th item
           >>> print x

        In this case it crashes, or prints bogus data, because there's
        no linkage between modifications to the *state* of foo and
        the x object.  Another case:

           >>> x = foo[10]
           >>> foo[10] = y
           >>> print x, y

        Now you'll see that x and y are always identical, because x
        refers to the place in the array where you've written the
        value of y.

     4. Similar problem with exposed iterators:

           >>> for x in some_vec:
           ...     if x.test_something():
           ...         x.foo = 3
           ...     else:
           ...         some_vec.pop_back()

         Even if your iterator uses return_internal_reference to keep
         some_vec alive during iteration and allow in-place
         modification of the data it references, it does nothing to
         ensure that things are OK when the *contents* of some_vec
         change out from under you.  The above could lead to a crash
         or bogus results.
     
These problems are not vector-specific.  I have some ideas about
addressing them but I'm not sure how far to go, and first I want to
know how many people care.

Thanks for reading,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From seefeld at sympatico.ca  Wed May 28 20:14:31 2003
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 28 May 2003 14:14:31 -0400
Subject: [C++-sig] Re: accessing the python type system
References: <8be22df0acd60639897b53a1aa74a17e3ed3986e@Orthosoft.ca> <uwugcci8o.fsf@boost-consulting.com> <36fee152f6305c4584d857754653a3823ed4b0f8@Orthosoft.ca> <uisrv863r.fsf@boost-consulting.com> <4044bacd7ee866c6aba323bb1a8234373ed4d9c2@Orthosoft.ca> <uel2j6k2e.fsf@boost-consulting.com>
Message-ID: <dfdefa07af1558a65ccf00792a5083a33ed4f9ac@Orthosoft.ca>

David Abrahams wrote:

> If boost::python::type is a class like boost::python::dict is, then
> type(x) is an instance of that class (OK so far) but type(type(x))
> invokes type's copy constructor.  Those are just the syntax rules of
> C++.  In order to be consistent with Python, type(type(x)) != type(x)
> for most x,
> 
>     >>> type([])
>     <type 'list'>
>     >>> type(type([]))
>     <type 'type'>
> 
> but that implies type's copy constructor doesn't make equivalent
> copies (very bad in C++).

That's where I'm lost. I don't see the copy constructor involved here.
Assuming boost::python::type IS-A boost::pyton::object, and there is
a way to generate a boost::python::type for each boost::python::object
("it's type"), which means you would be able to hold a 
boost::python::type describing another boost::python::type's type (i.e.
the result of 'type(type([]))'.

What do you want to copy here ?
Or in diagram form:

  py_object       ->       py_type
     ^                       ^
     |                       |
python::object        python::type

holding a python::object, you can construct a python::type object
by accessing the 'py_type' object with 'PyObject_Type(object.ptr())'
and wrapping this into a newly created python::type object.

That would work no matter whether the original python::object was
actually a type or an instance.

Then you could define comparison operators like:

bool operator == (const python::type &t1, const python::type &t2)
{
   return t1.ptr() == t2.ptr(); // assuming only one python object exists
                                // per type
}

and

bool operator <= (const python::type &t1, const python::type &t2)
{
   return PyObject_Subclass(t1, t2);
}

etc....

>>the Python C Api provides 'type objects', so ultimately I would
>>arrive at a single root of that 'instance' <-> 'type' tree
> 
> 
> That makes no sense to me.  What is travelling up the tree to arrive
> anywhere?

sorry for not being clear. I was drawing a tree in my mind where
parent nodes are types and child nodes are instances of those types.
It would be a tree (well, actually onle two levels deep) since the
root node would be a 'meta type', its children would be 'types', and
their children would be 'instances'. All I meant to say was that you
either walk up that tree when calling 'type(object)', or you stay
where you are (i.e. the 'type' operator is idempotent when applied to
a 'meta type').

What am I missing ?

Regards,
		Stefan




From rwgk at yahoo.com  Wed May 28 20:15:19 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 28 May 2003 11:15:19 -0700 (PDT)
Subject: [C++-sig] Re: registering simple conversions from/to python
In-Reply-To: <uk7cb6khf.fsf@boost-consulting.com>
Message-ID: <20030528181519.38003.qmail@web20209.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> For which to/from tuple conversions are little or no help.

I am just trying to show possible paths to follow so he can make educated
decisions.
Ralf


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com



From dave at boost-consulting.com  Wed May 28 23:30:59 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 28 May 2003 17:30:59 -0400
Subject: [C++-sig] Re: accessing the python type system
References: <8be22df0acd60639897b53a1aa74a17e3ed3986e@Orthosoft.ca> <uwugcci8o.fsf@boost-consulting.com>
 <36fee152f6305c4584d857754653a3823ed4b0f8@Orthosoft.ca>
 <uisrv863r.fsf@boost-consulting.com>
 <4044bacd7ee866c6aba323bb1a8234373ed4d9c2@Orthosoft.ca>
 <uel2j6k2e.fsf@boost-consulting.com>
 <dfdefa07af1558a65ccf00792a5083a33ed4f9ac@Orthosoft.ca>
Message-ID: <uel2i69nw.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> David Abrahams wrote:
>
>> If boost::python::type is a class like boost::python::dict is, then
>> type(x) is an instance of that class (OK so far) but type(type(x))
>> invokes type's copy constructor.  Those are just the syntax rules of
>> C++.  In order to be consistent with Python, type(type(x)) != type(x)
>> for most x,
>>     >>> type([])
>>     <type 'list'>
>>     >>> type(type([]))
>>     <type 'type'>
>> but that implies type's copy constructor doesn't make equivalent
>> copies (very bad in C++).
>
> That's where I'm lost. I don't see the copy constructor involved
> here.


the copy constructor signature is

  type( type const& )

the result of:

  type( x )

is to construct a temporary 'type' object, passing argument x.

therefore, the type of 

 type( x )

is 'type'

and if we pass that expression as a constructor argument to
type:

 type( type( x ) )
       ^^^^^^^^^-------has type 'type'

then we are constructing a temporary 'type' object, passing an
argument of type 'type'.  Ergo the copy constructor of 'type' is
called.  If we make it act like it does in Python, it will be a very
strange and dangerous c-ctor indeed.

> Assuming boost::python::type IS-A boost::pyton::object

Do you mean "is-an-instance-of?"  The scenario that causes a problem
is when boost::python::type is a class, just like boost::python::dict,
boost::python::tuple, et al.

> and there is a way to generate a boost::python::type for each
> boost::python::object ("it's type")

I guess you don't mean is-an-instance-of, because if you generate
several boost::python::type, objects, it must be a class.

> which means you would be able to hold a boost::python::type
> describing another boost::python::type's type (i.e.  the result of
> 'type(type([]))'.
>
> What do you want to copy here ?

I don't want to copy anything.  I have no choice; type(type(x)) calls
type's copy constructor.  I hope that's clear by now.

> Or in diagram form:
>
>   py_object       ->       py_type
>      ^                       ^
>      |                       |
> python::object        python::type


What are those things on the first line of the diagram?

> holding a python::object, you can construct a python::type object
> by accessing the 'py_type' object with 'PyObject_Type(object.ptr())'
> and wrapping this into a newly created python::type object.
>
> That would work no matter whether the original python::object was
> actually a type or an instance.

No duh.

> Then you could define comparison operators like:
>
> bool operator == (const python::type &t1, const python::type &t2)
> {
>    return t1.ptr() == t2.ptr(); // assuming only one python object exists
>                                 // per type
> }
>
> and
>
> bool operator <= (const python::type &t1, const python::type &t2)
> {
>    return PyObject_Subclass(t1, t2);
> }

Why bother?  If type were derived from object the operators would
already be available.

>>>the Python C Api provides 'type objects', so ultimately I would
>>>arrive at a single root of that 'instance' <-> 'type' tree
>> That makes no sense to me.  What is travelling up the tree to arrive
>> anywhere?
>
> sorry for not being clear. I was drawing a tree in my mind where
> parent nodes are types and child nodes are instances of those types.
> It would be a tree (well, actually onle two levels deep) since the
> root node would be a 'meta type', its children would be 'types', and
> their children would be 'instances'. All I meant to say was that you
> either walk up that tree when calling 'type(object)', or you stay
> where you are (i.e. the 'type' operator is idempotent when applied to
> a 'meta type').

No, it's not:

    class xyzmeta(type):
      def __init__(self, name, bases, dict):
           dict['x'] = 1
           dict['y'] = 1
           dict['z'] = 1
           return type.__call__(self,name,bases,dict)

    class XYZ(object):
        __metaclass__ = xyzmeta


    class xyzzy(XYZ): pass

    x = xyzzy()
    print 'class:',type(x)
    print 'metaclass:',type(type(x))
    print 'metametaclass:',type(type(type(x)))

>
> What am I missing ?

Seems like just about everything <wink>
But don't feel bad; nobody understands me.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dirk at gerrits.homeip.net  Thu May 29 00:07:32 2003
From: dirk at gerrits.homeip.net (Dirk Gerrits)
Date: Thu, 29 May 2003 00:07:32 +0200
Subject: [C++-sig] Re: [newbie] Question on embedding/extending with boost::python
In-Reply-To: <bb24tg$d4f$1@main.gmane.org>
References: <bam1c6$27k$1@main.gmane.org> <bb0kk2$9q2$1@main.gmane.org> <bb24tg$d4f$1@main.gmane.org>
Message-ID: <bb3brb$qgq$1@main.gmane.org>

Brett Calcott wrote:
> "Dirk Gerrits" <dirk at gerrits.homeip.net> wrote:
> 
>>Chris Heald wrote:
 >
[snip]
> 
> I had previously embedded python in my c++ app so that I could script my
> agents, but the result was very slow as this effectively did this
> (vastly simplified)
> 
> while (engine_running)
> {
>     for (agents_container:iterator a = agents.begin(); a !=
>         agents.end(); ++a)
>     {
>         // here we call out to python for each agent
>         (*a).update_yourself_via_python()
>         update_visual_stuff()
>     }
> }
> 
> The calls to python are in the inner loop and this is slow.

Well I suppose you could expose a visual_stuff_updating_iterator to 
Python, but extending is of course a much easier and cleaner.

> What I am doing now is different - I am constructng an engine in C++,
> making all the agents and world parameters accessible to python, BUT
> the update main loop remains entirely in C++:
> 
> import engine # boost python module
> 
> while engine_running:
>     engine.cycle()

I'm not sure I follow. Is engine.cycle() still doing a 
a->update_yourself_via_python() for every agent? Then where's the 
speedup compared to the embedded approach?

Regards,
Dirk Gerrits





From nicodemus at globalite.com.br  Thu May 29 06:18:38 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Wed, 28 May 2003 20:18:38 -0800
Subject: [C++-sig] set_wrapper
In-Reply-To: <1054107047.20969.5.camel@lxcms25>
References: <1054055040.19592.27.camel@lxcms25> 	<3ED41C1A.5000303@globalite.com.br> <1054107047.20969.5.camel@lxcms25>
Message-ID: <3ED58A1E.1080408@globalite.com.br>

Giulio Eulisse wrote:

>>Note also that the method you are trying to add must receive as first 
>>argument a reference or a pointer to the class, so your f_A function 
>>should be:
>>
>>    void f_A(A&);
>>    
>>
>
>Yes, you are right, I miscopied the sample code I had, sorry. And I
>agree with you that a add_method function would be more
>self-explanatory. I tried to hack around the set_wrapper code in pyste
>but I still have problems, when do you plan to implement such a feature?
>
Yeah, I agree add_method would be better too. I probably will implement 
it in a couple of days, is that good enough for you?

>Thanks in advance.
>
>Ciao,
>Giulio
>PS: Are you aware of the fact that the CVS HEAD, as of yesterday, of
>pyste is broken(at least in my case)?
>  
>

I always run all tests before commiting any code... could you post an 
example that doesn't work? I can add it to the test suite then, it would 
help a lot.

Regards,
Nicodemus.




From Paul_Kunz at SLAC.Stanford.EDU  Thu May 29 02:54:18 2003
From: Paul_Kunz at SLAC.Stanford.EDU (Paul F. Kunz)
Date: Wed, 28 May 2003 17:54:18 -0700
Subject: [C++-sig] Re: method_call_expr not supported by dump_expr
References: <20030522170051.51453.qmail@web20204.mail.yahoo.com>
Message-ID: <200305290054.h4T0sIX26429@libra3.slac.stanford.edu>

   So what is the final recommendation for this problem with gcc
3.3?.   My code has an INSTALL file which tries to recommend what to
do for users of gcc 3.3.   I would like to give them a recommendation
considered best (least worst) by Boost.Python authors.



From milind_patil at hotmail.com  Thu May 29 04:31:51 2003
From: milind_patil at hotmail.com (Milind Patil)
Date: Wed, 28 May 2003 19:31:51 -0700
Subject: [C++-sig] Re: long long unsigned issue...
References: <b8uvp7$kp1$1@main.gmane.org> <uk7d8n8k7.fsf@boost-consulting.com> <b91g6e$me8$1@main.gmane.org> <u65oriktt.fsf@boost-consulting.com> <b91qci$oc6$1@main.gmane.org> <u1xzfiizj.fsf@boost-consulting.com> <b9292b$qru$1@main.gmane.org> <u65orxage.fsf@boost-consulting.com> <b96to4$d5$1@main.gmane.org> <uof2g6fhy.fsf@boost-consulting.com> <b9747j$vqv$1@main.gmane.org> <ufzns6czx.fsf@boost-consulting.com> <b97eg3$sod$1@main.gmane.org> <uvfwo2idm.fsf@boost-consulting.com> <b9s7dn$b0$1@main.gmane.org> <uu1boaql5.fsf@boost-consulting.com> <bajv6b$pe7$1@main.gmane.org> <ud6i4zd6x.fsf@boost-consulting.com> <ud6i4xtz2.fsf@boost-consulting.com>
Message-ID: <bb3rao$71p$1@main.gmane.org>

"David Abrahams" <dave at boost-consulting.com> wrote in message
news:ud6i4xtz2.fsf at boost-consulting.com...
> David Abrahams <dave at boost-consulting.com> writes:
>
> One more note about this stuff: you have so many constructors and so
> much potential for ambiguity it's hard to make sense of what you're
> actually trying to achieve.  Maybe if you could say a little more
> about that it would be easier to help you.
>
> -- 
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com

The C++ library that I am wrapping is part of a testbench library for verification of
RTL designs of ASICs. The library has bit vector signal (to connect to rtl signals)
classes, concurrency classes, randomization classes etc. Supporting scripting
in the verification environment is going to be a great productivity booster, I think.
And hence the attempt to use boost python.

I used pyste (thanks to Nicodemus) to jump start the wrapping process. I have a
use case model in mind that I am hand crafting the wrappers to now.

Looking at just the signal class, it has constructors for
a) Constructing signals of given width eg. signal(23,0) -- a 24 bit signal,
    signal(23,0, 0xffffff) -- a 24 bit signal with value 0xffffff,
b) Constructors for constants eg. signal(0x00ffffff) -- 24 bit signal, etc.
c) Constructors from character representation, long long, long, and
    int representations of numbers.
d) copy, default etc.

Other requirements of python signal class are:
a) handling 4state: bits can be 0, 1, X or Z.
b) slice set and get ie. sig[18:4] = 2; sig[:] = 4;
c) ability to convert from and to python long.

Anyway the above was a little introduction to
the big picture at my end.

Coming to issue with long_ conversion that I have had.
I constructed a toy example to experiment with the long_
conversion issue. Recapping, given the class

class Y {
   public:
     Y() : y(0L) { }
     Y(int y) : y(y) { }
     Y(long long unsigned int y) : y(y) { }
     Y(int s, const Y & y) : y(y << s) { }
     Y(Y const& rhs) : y(rhs.y) { }
     virtual ~Y() { }

     operator int() const { return y; }

     void operator=(Y const& y) {
         this->y = y.y;
     }

     long long unsigned int y;
 };

that I would like to wrap to python:

BOOST_PYTHON_MODULE(hello)
{
    class_< Y, Y_Wrapper >("Y", init<  >())
        .def(init< const Y & >())
        .def(init< int, const Y & >())
        .def(init< int >())
        .def(init< long long unsigned int >())
        .def_readwrite("y", &Y::y)
        .def("__int__", &Y::operator int)
     ;
     impilcitly_convertible<int, Y>();
}

The implicitly_converitble above is to facilitate conversion
to Y(int, &Y) for python x = hello.Y(2, 24) etc.
I wanted to add conversion capability from and to python
long_ which was possible via a wrapper class (again, something
that pyste originally generated):

 namespace {
 struct Y_Wrapper: Y {
     Y_Wrapper (PyObject* self_) : Y(), self(self_) {}
     Y_Wrapper (PyObject* self_, int y) : Y(y), self(self_) {}
     Y_Wrapper (PyObject* self_, long long unsigned int y) : Y(y), self(self_) {}
     Y_Wrapper (PyObject* self_, int s,  const Y& y) : Y(s,y), self(self_) {}
     Y_Wrapper (PyObject* self_, const Y& y) : Y(y), self(self_) {}
     Y_Wrapper (PyObject* self_, boost::python::long_ y) : Y(0), self(self_) {printf("hello
long_");}

     PyObject* self;
 };
}

and adding

         .def(init< long_ >())

to module definition.

So far so good. With your recent fixes it works perfectly for python construction
of Y from long  eg. x = hello.Y(4294967295) -- this is the type b constructor in the
constructors I enumerated above. But if I want to construct signals of given width,
then I would have x = signal(127,0, 4294967295), or x = hello.Y(127, 4294967295)
for the toy example. This statement will cause a runtime exception fault
saying that "OverflowError: long int too large to convert to int", probably because it
is trying construct to Y(int s,  const Y& y) and does not know how to make long_
to Y! My question here was :

Now that we have a long_ to Y_Wrapper constructor
and that class_ Y has Y_Wrapper as one of the bases, is it possible to use an
implicity_convertible<long_, Y_Wrapper>(); to be able to facilitate the conversion?

I am not comletely dead in water:
I have added a .def(init<int, long_>) to module definition and a
Y_Wrapper(PyObject* self_, int s,  boost::python::long_ y)
to Y_Wrapper to get around the inability to do a
implicitly_convertible<long_ Y_Wrapper>() to effect the conversion.
This works for me right now. I once again thank you for helping me
with the issue I had.

If you have read so far, I had some more observations as a user:

Some of the use case scenarios for boost python are:

a) Expose C++ classes as python classes alone. User will not derive
    from the exposed classes.
b) Expose C++ classes as derivable classes in python.
c) Embedded scenarios with above two where it goes c++ to python to c++
    back etc.
d) Expose C++ classes as derived or as convertible to python types (numeric,
    tuples, str etc.)

My particular use case is a) and d). And there is adequate
documentation/information to be able to be able to figure it out but it is
difficult. Perhaps the document can handle c) and d) a little more?
Anything I can help with?

Thanks again,
Milind






From rwgk at yahoo.com  Thu May 29 07:56:57 2003
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 28 May 2003 22:56:57 -0700 (PDT)
Subject: [C++-sig] Re: method_call_expr not supported by dump_expr
In-Reply-To: <200305290054.h4T0sIX26429@libra3.slac.stanford.edu>
Message-ID: <20030529055657.45774.qmail@web20201.mail.yahoo.com>

--- "Paul F. Kunz" <Paul_Kunz at SLAC.Stanford.EDU> wrote:
>    So what is the final recommendation for this problem with gcc
> 3.3?.   My code has an INSTALL file which tries to recommend what to
> do for users of gcc 3.3.   I would like to give them a recommendation
> considered best (least worst) by Boost.Python authors.

The current boost CVS head works with gcc 3.3 under Linux*, and if you are
lucky also under Mac OS X**. The problem mentioned in the subject was fixed by
removing the sizeof's in:
    boost/boost/python/converter/as_to_python_function.hpp
Compare with the version in CVS.

*Linux: but the optimizer (-O3) breaks some of our regression tests.

**Mac: if you are lucky to avoid internal compiler errors (gcc bug 10922). Once
I got very lucky and managed to compile almost everything with -O3, but then
almost all our regression tests failed.

My grand conclusion: avoid gcc 3.3 as much as you can.

Ralf


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com



From giulio.eulisse at cern.ch  Thu May 29 10:49:39 2003
From: giulio.eulisse at cern.ch (Giulio Eulisse)
Date: Thu, 29 May 2003 10:49:39 +0200
Subject: [C++-sig] set_wrapper
In-Reply-To: <3ED58A1E.1080408@globalite.com.br>
Message-ID: <7BE4E13D-91B2-11D7-B381-000393BD5E3A@cern.ch>

> Yeah, I agree add_method would be better too. I probably will 
> implement it in a couple of days, is that good enough for you?

Since I'm on vacation (and I don't pay you ;-) ) that would be 
perfect...We have found some other strange behaviours (did you get the 
message about the missing boost::ref?) but right now I don't have time 
to write simple examples.

> I always run all tests before commiting any code... could you post an 
> example that doesn't work? I can add it to the test suite then, it 
> would help a lot.
>
mmmm...that is strange...Any of my old code breaks...But again, I don't 
have any handy....

Ciao and thanks for all your help and kindness,
Giulio




From brett.calcott at paradise.net.nz  Thu May 29 12:39:29 2003
From: brett.calcott at paradise.net.nz (Brett Calcott)
Date: Thu, 29 May 2003 22:39:29 +1200
Subject: [C++-sig] Re: Re: registering simple conversions from/to python
References: <uk7cb6khf.fsf@boost-consulting.com> <20030528181519.38003.qmail@web20209.mail.yahoo.com>
Message-ID: <bb4nt3$srj$1@main.gmane.org>


>
> I am just trying to show possible paths to follow so he can make
> educated decisions.
> Ralf
>
>

My thanks to you both. Both these techniques are going to be useful to
me.

Cheers,
Brett






From gideon at computer.org  Thu May 29 12:43:24 2003
From: gideon at computer.org (gideon may)
Date: Thu, 29 May 2003 12:43:24 +0200
Subject: [C++-sig] OpenSceneGraph bindings now hosted at sourceforge.
Message-ID: <58474582.1054212204@localhost>

Dear Dave,

The OpenSceneGraph bindings are now hosted at 
<http://sourceforge.net/projects/pyosg>
Could you be so kind and update the boost.python projects page ?

Thanks,

gideon



From brett.calcott at paradise.net.nz  Thu May 29 13:01:24 2003
From: brett.calcott at paradise.net.nz (Brett Calcott)
Date: Thu, 29 May 2003 23:01:24 +1200
Subject: [C++-sig] Re: [newbie] Question on embedding/extending with boost::python
References: <bam1c6$27k$1@main.gmane.org> <bb0kk2$9q2$1@main.gmane.org> <bb24tg$d4f$1@main.gmane.org> <bb3brb$qgq$1@main.gmane.org>
Message-ID: <bb4ple$3ct$1@main.gmane.org>

"Dirk Gerrits" <dirk at gerrits.homeip.net> wrote:
> Brett Calcott wrote:
> >
> > I had previously embedded python in my c++ app so that I could
> > script my agents, but the result was very slow as this effectively
> > did this (vastly simplified)
> >
> > while (engine_running)
> > {
> >     for (agents_container:iterator a = agents.begin(); a !=
> >         agents.end(); ++a)
> >     {
> >         // here we call out to python for each agent
> >         (*a).update_yourself_via_python()
> >         update_visual_stuff()
> >     }
> > }
> >
> > The calls to python are in the inner loop and this is slow.
>
> Well I suppose you could expose a visual_stuff_updating_iterator to
> Python, but extending is of course a much easier and cleaner.

Not sure I follow what you mean here..


>
> > What I am doing now is different - I am constructng an engine in
> > C++, making all the agents and world parameters accessible to
> > python, BUT the update main loop remains entirely in C++:
> >
> > import engine # boost python module
> >
> > while engine_running:
> >     engine.cycle()
>
> I'm not sure I follow. Is engine.cycle() still doing a
> a->update_yourself_via_python() for every agent? Then where's the
> speedup compared to the embedded approach?
>
>

No, it's not. The engine.cycle() function never calls back to python.

Let me try and clarify.

The big difference in what I am doing now is how I am using python -- it
is serving a completely different role in my software development.

Before, I wrote everything in C++ - and python was playing the role of
allowing me to script the actions of my agents. I was using python
because it allowed me to change the behaviour of my agents without
recompiling. The degree to which I benefitted from python was the ease
with which I could quickly change the behaviour of my agents -- the
problem was that it slowed the simulation down.

Now, I am using python to construct the entire framework, and I am
writing the agents, including their "update" function, in C++. The
advantage I get from this is the speed of development of all the support
framework, including inspection/pickling/scripted setups, and the power
and ease of the entire python library. However, the core engine that has
to be quick will be in C++. Now, I don't get the advantage of being able
to script my agents behaviour, that is still in C++, but I get a
headstart on everything else.

Of course, it is not as bad as that. I can still parameterise the agents
behaviour and set those parameters interactively in python and, as
before, I can still choose to use an agent that is extensible in python
and really slow, but just for the purpose of testing -- then I can push
the code back to C++. This is particularly easy with the boost_python
stuff.

To summarise -- that big change is in how I look at python. Before, I
saw C++ as a serious development framework, and python as a scripting
language for doing the little bits of my app that I wanted to change
quickly. Now, I see python as an incredibly fast development framework,
and C++ as something to make the computationally intensive bits of my
app go faster.

So I things have sort of been stood on their head.  I still love C++,
but I can make stuff happen so much more quickly in python.

Cheers,
Brett























From brett.calcott at paradise.net.nz  Thu May 29 13:15:46 2003
From: brett.calcott at paradise.net.nz (Brett Calcott)
Date: Thu, 29 May 2003 23:15:46 +1200
Subject: [C++-sig] Re: Support for Indexing and Iteration Safety
References: <u65nv6j6h.fsf@boost-consulting.com>
Message-ID: <bb4q13$50f$1@main.gmane.org>

"David Abrahams" <dave at boost-consulting.com> wrote:
>
> I have some ideas about how to better support the indexing operator[]
> and related thoughts about the safety of iterators.  Rather than
> following my usual practice of posting a big tome about it which will
> overwhelm everyone so they don't respond ;->, let me just point out a
> few problems with the current Boost.Python implementation.  You let me
> know if you care about any of these issues:
>
>      1. Unlike most of the other operators, which can be wrapped using
>         "self op other", there's no easy way to wrap the indexing
>         operator.  You end up having to write your own __getitem__
>         and __setitem__ functions.
>
>      2. You also have to implement the code which raises an exception
>         if the index is out of range or the key is not found (in case
>         you're implementing a mapping).  If you forget, your extension
>         class is prone to crashes and accessing invalid data.
>
>      3. Even if you get that right, you may still be prone to crashes.
>         Suppose you're wrapping a std::vector<SomeBigObject>.  If you
>         want to support syntax like:
>
>            >>> foo = vector_SomeBigObject(15)
>            >>> foo[10].bar = 3 # modify an element in-place
>
>         or if you just want to avoid unneccessarily copying the
>         SomeBigObject element when you access it:
>
>            >>> x = foo[10].bar
>
>         then you have to use return_internal_reference in your
>         __getitem__. All well and good. Even if you do:
>
>            >>> del foo
>            >>> print x
>
>         your x is still valid because of the call policy; it is kept
>         alive.  On the other hand, what if you do:
>
>            >>> del foo[10]  # erase the 10th item
>            >>> print x
>
>         In this case it crashes, or prints bogus data, because there's
>         no linkage between modifications to the *state* of foo and
>         the x object.  Another case:
>
>            >>> x = foo[10]
>            >>> foo[10] = y
>            >>> print x, y
>
>         Now you'll see that x and y are always identical, because x
>         refers to the place in the array where you've written the
>         value of y.
>
>      4. Similar problem with exposed iterators:
>
>            >>> for x in some_vec:
>            ...     if x.test_something():
>            ...         x.foo = 3
>            ...     else:
>            ...         some_vec.pop_back()
>
>          Even if your iterator uses return_internal_reference to keep
>          some_vec alive during iteration and allow in-place
>          modification of the data it references, it does nothing to
>          ensure that things are OK when the *contents* of some_vec
>          change out from under you.  The above could lead to a crash
>          or bogus results.
>
> These problems are not vector-specific.  I have some ideas about
> addressing them but I'm not sure how far to go, and first I want to
> know how many people care.
>

I'm haven't gone far enough in what I am doing to encounter these
problems, but for what its worth, at the moment I would have done the
following:

    if something is lightweight, return a copy
    if it is big, use shared_ptr

Which means that the above problems 3 & 4 would not occur. And 1 & 2
don't really seem that onerous a task. So I guess I don't 'care' that
much.

Of course, I reserve the right to change my opinion at any moment if I
encounter problems :)

ciao,
Brett

"David Abrahams" <dave at boost-consulting.com> wrote:
>
> I have some ideas about how to better support the indexing operator[]
> and related thoughts about the safety of iterators.  Rather than
> following my usual practice of posting a big tome about it which will
> overwhelm everyone so they don't respond ;->, let me just point out a
> few problems with the current Boost.Python implementation.  You let me
> know if you care about any of these issues:
>
>      1. Unlike most of the other operators, which can be wrapped using
>         "self op other", there's no easy way to wrap the indexing
>         operator.  You end up having to write your own __getitem__ and
>         __setitem__ functions.
>
>      2. You also have to implement the code which raises an exception
>         if the index is out of range or the key is not found (in case
>         you're implementing a mapping).  If you forget, your extension
>         class is prone to crashes and accessing invalid data.
>
>      3. Even if you get that right, you may still be prone to crashes.
>         Suppose you're wrapping a std::vector<SomeBigObject>.  If you
>         want to support syntax like:
>
>            >>> foo = vector_SomeBigObject(15)
>            >>> foo[10].bar = 3 # modify an element in-place
>
>         or if you just want to avoid unneccessarily copying the
>         SomeBigObject element when you access it:
>
>            >>> x = foo[10].bar
>
>         then you have to use return_internal_reference in your
>         __getitem__. All well and good. Even if you do:
>
>            >>> del foo
>            >>> print x
>
>         your x is still valid because of the call policy; it is kept
>         alive.  On the other hand, what if you do:
>
>            >>> del foo[10]  # erase the 10th item
>            >>> print x
>
>         In this case it crashes, or prints bogus data, because there's
>         no linkage between modifications to the *state* of foo and
>         the x object.  Another case:
>
>            >>> x = foo[10]
>            >>> foo[10] = y
>            >>> print x, y
>
>         Now you'll see that x and y are always identical, because x
>         refers to the place in the array where you've written the
>         value of y.
>
>      4. Similar problem with exposed iterators:
>
>            >>> for x in some_vec:
>            ...     if x.test_something():
>            ...         x.foo = 3
>            ...     else:
>            ...         some_vec.pop_back()
>
>          Even if your iterator uses return_internal_reference to keep
>          some_vec alive during iteration and allow in-place
>          modification of the data it references, it does nothing to
>          ensure that things are OK when the *contents* of some_vec
>          change out from under you.  The above could lead to a crash
>          or bogus results.
>
> These problems are not vector-specific.  I have some ideas about
> addressing them but I'm not sure how far to go, and first I want to
> know how many people care.
>

I'm haven't gone far enough in what I am doing to encounter these
problems, but for what its worth, at the moment I would have done the
following:

    if something is lightweight, return a copy
    if it is big, use shared_ptr

Which means that the above problems 3 & 4 would not occur. And 1 & 2
don't really seem that onerous a task. So I guess I don't 'care' that
much.

Of course, I reserve the right to change my opinion at any moment if I
encounter problems :)

ciao,
Brett






From dave at boost-consulting.com  Thu May 29 15:09:50 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 29 May 2003 09:09:50 -0400
Subject: [C++-sig] Re: long long unsigned issue...
References: <b8uvp7$kp1$1@main.gmane.org> <uk7d8n8k7.fsf@boost-consulting.com>
 <b91g6e$me8$1@main.gmane.org> <u65oriktt.fsf@boost-consulting.com>
 <b91qci$oc6$1@main.gmane.org> <u1xzfiizj.fsf@boost-consulting.com>
 <b9292b$qru$1@main.gmane.org> <u65orxage.fsf@boost-consulting.com>
 <b96to4$d5$1@main.gmane.org> <uof2g6fhy.fsf@boost-consulting.com>
 <b9747j$vqv$1@main.gmane.org> <ufzns6czx.fsf@boost-consulting.com>
 <b97eg3$sod$1@main.gmane.org> <uvfwo2idm.fsf@boost-consulting.com>
 <b9s7dn$b0$1@main.gmane.org> <uu1boaql5.fsf@boost-consulting.com>
 <bajv6b$pe7$1@main.gmane.org> <ud6i4zd6x.fsf@boost-consulting.com>
 <ud6i4xtz2.fsf@boost-consulting.com> <bb3rao$71p$1@main.gmane.org>
Message-ID: <uy90p3nmp.fsf@boost-consulting.com>

"Milind Patil" <milind_patil at hotmail.com> writes:

> Coming to issue with long_ conversion that I have had.
> I constructed a toy example to experiment with the long_
> conversion issue. Recapping, given the class
>
> class Y {
>    public:
>      Y() : y(0L) { }
>      Y(int y) : y(y) { }
>      Y(long long unsigned int y) : y(y) { }
>      Y(int s, const Y & y) : y(y << s) { }
>      Y(Y const& rhs) : y(rhs.y) { }
>      virtual ~Y() { }
>
>      operator int() const { return y; }
>
>      void operator=(Y const& y) {
>          this->y = y.y;
>      }
>
>      long long unsigned int y;
>  };

My point is that this is a *very* big toy, with lots of constructors
which look like they could potentially contend for the same input
arguments.  Can't you reduce the problem you're having a little bit
more?

> that I would like to wrap to python:
>
> BOOST_PYTHON_MODULE(hello)
> {
>     class_< Y, Y_Wrapper >("Y", init<  >())
>         .def(init< const Y & >())
>         .def(init< int, const Y & >())
>         .def(init< int >())
>         .def(init< long long unsigned int >())
>         .def_readwrite("y", &Y::y)
>         .def("__int__", &Y::operator int)
>      ;
>      impilcitly_convertible<int, Y>();
> }
>
> The implicitly_converitble above is to facilitate conversion
> to Y(int, &Y) for python x = hello.Y(2, 24) etc.
> I wanted to add conversion capability from and to python
> long_ 

Do you need *implicit* conversion capability?  Remember that implicit
conversions are generally un-Pythonic.

> which was possible via a wrapper class (again, something
> that pyste originally generated):
>
>  namespace {
>  struct Y_Wrapper: Y {
>      Y_Wrapper (PyObject* self_) : Y(), self(self_) {}
>      Y_Wrapper (PyObject* self_, int y) : Y(y), self(self_) {}
>      Y_Wrapper (PyObject* self_, long long unsigned int y) : Y(y), self(self_) {}
>      Y_Wrapper (PyObject* self_, int s,  const Y& y) : Y(s,y), self(self_) {}
>      Y_Wrapper (PyObject* self_, const Y& y) : Y(y), self(self_) {}
>      Y_Wrapper (PyObject* self_, boost::python::long_ y) : Y(0), self(self_) {printf("hello
> long_");}
>
>      PyObject* self;
>  };
> }
>
> and adding
>
>          .def(init< long_ >())
>
> to module definition.
>
> So far so good. With your recent fixes it works perfectly for python
> construction of Y from long eg. x = hello.Y(4294967295) -- this is
> the type b constructor in the constructors I enumerated above. But
> if I want to construct signals of given width, then I would have x =
> signal(127,0, 4294967295), or x = hello.Y(127, 4294967295) for the
> toy example. This statement will cause a runtime exception fault
> saying that "OverflowError: long int too large to convert to int",
> probably because it is trying construct to Y(int s, const Y& y) and
> does not know how to make long_ to Y! My question here was :
>
> Now that we have a long_ to Y_Wrapper constructor
> and that class_ Y has Y_Wrapper as one of the bases

You got that backwards.  Y is the base of Y_Wrapper.

> is it possible to use an implicity_convertible<long_, Y_Wrapper>();
> to be able to facilitate the conversion?

No, precisely because Y_Wrapper is not a base of Y.

The right solution to this problem is to provide for something Ralf
has been requesting for some time:  the ability to inject new
constructors into a class, just the way we can inject methods that
aren't built from member functions.  Something like:

Y Y_from_pylong(long_ y)
{
    return Y(extract<unsigned long long>(y));
}

       ...
       .def("__init__", constructor(Y_from_pylong))

> I am not comletely dead in water:
> I have added a .def(init<int, long_>) to module definition and a
> Y_Wrapper(PyObject* self_, int s,  boost::python::long_ y)
> to Y_Wrapper to get around the inability to do a
> implicitly_convertible<long_ Y_Wrapper>() to effect the conversion.
> This works for me right now. I once again thank you for helping me
> with the issue I had.
>
> If you have read so far, I had some more observations as a user:
>
> Some of the use case scenarios for boost python are:
>
> a) Expose C++ classes as python classes alone. User will not derive
>     from the exposed classes.
> b) Expose C++ classes as derivable classes in python.

a and b are equivalent as far as the library is concerned.

> c) Embedded scenarios with above two where it goes c++ to python to c++
>     back etc.

Anything with, e.g., overridable virtual functions fits that picture.
It has nothing to do with embedding AFAICT... or am I missing
something?

> d) Expose C++ classes as derived or as convertible to python types (numeric,
>     tuples, str etc.)

Case d can be combined with any of the other cases.

> My particular use case is a) and d). And there is adequate
> documentation/information to be able to be able to figure it out but it is
> difficult. Perhaps the document can handle c) and d) a little more?

I'm confused.  Why do you want more info on c) if you don't use
Boost.Python that way?

> Anything I can help with?

Better support for your use cases has to come from two ends:
implementation and documentation.  Part of the reason that d) isn't
better-documented is that its current implementation is too
complicated and low-level to expose to users.  All of this can be
fixed by funding some library development.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Thu May 29 15:14:52 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 29 May 2003 09:14:52 -0400
Subject: [C++-sig] Re: OpenSceneGraph bindings now hosted at sourceforge.
References: <58474582.1054212204@localhost>
Message-ID: <usmqx3neb.fsf@boost-consulting.com>

gideon may <gideon at computer.org> writes:

> Dear Dave,
>
> The OpenSceneGraph bindings are now hosted at
> <http://sourceforge.net/projects/pyosg>
> Could you be so kind and update the boost.python projects page ?

Done, Thanks!

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Thu May 29 15:17:14 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 29 May 2003 09:17:14 -0400
Subject: [C++-sig] Projects Page Reminder
Message-ID: <un0h53nad.fsf@boost-consulting.com>

If you have a project using Boost.Python, and you wouldn't mind if it
were listed at http://www.boost.org/libs/python/doc/projects.html,
please send or post the text of an entry for that page!

Thank you very much for your support,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Thu May 29 15:42:00 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 29 May 2003 09:42:00 -0400
Subject: [C++-sig] Re: Support for Indexing and Iteration Safety
References: <u65nv6j6h.fsf@boost-consulting.com> <bb4q13$50f$1@main.gmane.org>
Message-ID: <uhe7d3m53.fsf@boost-consulting.com>

"Brett Calcott" <brett.calcott at paradise.net.nz> writes:

<snip my entire posting quoted>

> I'm haven't gone far enough in what I am doing to encounter these
> problems, but for what its worth, at the moment I would have done the
> following:
>
>     if something is lightweight, return a copy
>     if it is big, use shared_ptr
>
> Which means that the above problems 3 & 4 would not occur. 

That is only true if you can modify your vector to be a
vector<shared_ptr<SomeBigObject> >.  Often, the implementation of code
being wrapped can't be intrusively changed in that way.  Furthermore,
even if it's lightweight, returning a copy gets you unpredictable
behavior like:

      >>> v[3].foo = 1
      >>> v[3].foo
      22

because you've only set the attribute on the copy.

> And 1 & 2 don't really seem that onerous a task. So I guess I don't
> 'care' that much.

Hmm, this might be a case of "those sophisticated enough to know what
I'm talking about also know how to avoid the problems."

Where are all the other respondents?  I know a number of people have
tried to wrap things with array indexing in the past...

http://aspn.activestate.com/ASPN/Mail/Message/1428806
http://aspn.activestate.com/ASPN/Mail/Message/1465837
http://aspn.activestate.com/ASPN/Mail/Message/1227141
http://aspn.activestate.com/ASPN/Mail/Message/1227504
http://aspn.activestate.com/ASPN/Mail/Message/1431504
http://aspn.activestate.com/ASPN/Mail/Message/1425273
http://aspn.activestate.com/ASPN/Mail/Message/1227378

> Of course, I reserve the right to change my opinion at any moment if I
> encounter problems :)

Did I change your mind yet? ;->

<snip a duplicate copy of the entire foregoing text>


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From domma at procoders.net  Thu May 29 15:51:14 2003
From: domma at procoders.net (Achim Domma (ProCoders))
Date: Thu, 29 May 2003 15:51:14 +0200
Subject: [C++-sig] Projects Page Reminder
In-Reply-To: <un0h53nad.fsf@boost-consulting.com>
Message-ID: <FCEMIEFBFOIDAOJDEPIAEECMFGAA.domma@procoders.net>

> If you have a project using Boost.Python, and you wouldn't mind if it
> were listed at http://www.boost.org/libs/python/doc/projects.html,
> please send or post the text of an entry for that page!

PythonMagick ist already on the page, but I forgot to send you an update:
The project is now located at http://www.procoders.net/pythonmagick and it
uses GraphicsMagick (http://www.graphicsmagick.org). ImageMagick isn't used
anymore.

regards,
Achim




From dave at boost-consulting.com  Thu May 29 15:59:56 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 29 May 2003 09:59:56 -0400
Subject: [C++-sig] Re: Projects Page Reminder
References: <un0h53nad.fsf@boost-consulting.com> <FCEMIEFBFOIDAOJDEPIAEECMFGAA.domma@procoders.net>
Message-ID: <u65nt3lb7.fsf@boost-consulting.com>

"Achim Domma \(ProCoders\)" <domma at procoders.net> writes:

>> If you have a project using Boost.Python, and you wouldn't mind if it
>> were listed at http://www.boost.org/libs/python/doc/projects.html,
>> please send or post the text of an entry for that page!
>
> PythonMagick ist already on the page, but I forgot to send you an update:
> The project is now located at http://www.procoders.net/pythonmagick and it
> uses GraphicsMagick (http://www.graphicsmagick.org). ImageMagick isn't used
> anymore.

Thanks, Achim!

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Thu May 29 16:01:49 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 29 May 2003 10:01:49 -0400
Subject: [C++-sig] Re: Support for Indexing and Iteration Safety
References: <u65nv6j6h.fsf@boost-consulting.com> <bb4q13$50f$1@main.gmane.org>
 <uhe7d3m53.fsf@boost-consulting.com>
Message-ID: <uznl526nm.fsf@boost-consulting.com>

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

> Hmm, this might be a case of "those sophisticated enough to know what
> I'm talking about also know how to avoid the problems."

I probably should have said "dance around the problems".  In other
words, if you understand the issues you probably know what the C++
wrapping code is doing under-the-covers enough to understand how to
avoid problems when using it from Python.  But that doesn't mean your
users won't crash the interpreter and loose all *their* work!

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From nicodemus at globalite.com.br  Thu May 29 21:48:13 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Thu, 29 May 2003 11:48:13 -0800
Subject: [C++-sig] Re: Projects Page Reminder
In-Reply-To: <u65nt3lb7.fsf@boost-consulting.com>
References: <un0h53nad.fsf@boost-consulting.com> <FCEMIEFBFOIDAOJDEPIAEECMFGAA.domma@procoders.net> <u65nt3lb7.fsf@boost-consulting.com>
Message-ID: <3ED663FD.3070303@globalite.com.br>

David Abrahams wrote:

>"Achim Domma \(ProCoders\)" <domma at procoders.net> writes:
>
>  
>
>>>If you have a project using Boost.Python, and you wouldn't mind if it
>>>were listed at http://www.boost.org/libs/python/doc/projects.html,
>>>please send or post the text of an entry for that page!
>>>      
>>>
>>PythonMagick ist already on the page, but I forgot to send you an update:
>>The project is now located at http://www.procoders.net/pythonmagick and it
>>uses GraphicsMagick (http://www.graphicsmagick.org). ImageMagick isn't used
>>anymore.
>>    
>>
>
>Thanks, Achim!
>

Dave, my company uses Boost.Python extensively... we create programs 
related to engenering problems, mostly to the oil industry, but it's all 
closed source. You think it would be interesting to put this in the page 
too? I can send more info then.






From seefeld at sympatico.ca  Thu May 29 17:17:08 2003
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 29 May 2003 11:17:08 -0400
Subject: [C++-sig] Re: accessing the python type system
References: <8be22df0acd60639897b53a1aa74a17e3ed3986e@Orthosoft.ca> <uwugcci8o.fsf@boost-consulting.com> <36fee152f6305c4584d857754653a3823ed4b0f8@Orthosoft.ca> <uisrv863r.fsf@boost-consulting.com> <4044bacd7ee866c6aba323bb1a8234373ed4d9c2@Orthosoft.ca> <uel2j6k2e.fsf@boost-consulting.com> <dfdefa07af1558a65ccf00792a5083a33ed4f9ac@Orthosoft.ca> <uel2i69nw.fsf@boost-consulting.com>
Message-ID: <9a7b8d9b4ab3af20d362529dc4edd1cd3ed621bd@Orthosoft.ca>

Hi David,

David Abrahams wrote:

>>which means you would be able to hold a boost::python::type
>>describing another boost::python::type's type (i.e.  the result of
>>'type(type([]))'.
>>
>>What do you want to copy here ?
> 
> 
> I don't want to copy anything.  I have no choice; type(type(x)) calls
> type's copy constructor.  I hope that's clear by now.

'type(x)' is a python expression, right ? The equivalent in C is

PyObject *the_type = PyObject_Type(the_object);

so your statement seems to imply that there already is some C++ wrapper
code encapsulating a call to PyObject_Type, and resulting in some class'
copy constructor to be called. Where can I find that ?

I was assuming that the C++ API would provide a function somewhat
similar to

object type(const object &o)
{
   return object(borrowed(PyObject_Type(o.ptr())));
}

or, with a suitable 'type' class defined,

type get_type(const object &o)
{
   return type(borrowed(PyObject_Type(o.ptr())));
}

in which case there is no copy constructor anywhere.


>>Or in diagram form:
>>
>>  py_object       ->       py_type
>>     ^                       ^
>>     |                       |
>>python::object        python::type
> 
> 
> 
> What are those things on the first line of the diagram?

the actual python objects (of type 'PyObject').

>     print 'class:',type(x)
>     print 'metaclass:',type(type(x))
>     print 'metametaclass:',type(type(type(x)))

fine, the last line tells me that the 'metametaclass' is a 'type'.
Applying the 'type' operator to that still returns 'type'. It's just
one level higher up than what I described. So what ?

All I was trying to get at is that a way to look at this is as a
single rooted tree, where each parent node is the 'metaclass' of its
respective child nodes.

>>What am I missing ?
> 
> 
> Seems like just about everything <wink>
> But don't feel bad; nobody understands me.

Ok, still trying...;-)

Regards,
		Stefan





From domma at procoders.net  Thu May 29 17:20:11 2003
From: domma at procoders.net (Achim Domma (ProCoders))
Date: Thu, 29 May 2003 17:20:11 +0200
Subject: [C++-sig] embedding: getting exception information?
Message-ID: <FCEMIEFBFOIDAOJDEPIAOECPFGAA.domma@procoders.net>

Hi,

I'm embedding python in a COM object and want to get the information usually
printed via PyErr_Print. I tried code like this:

dict ns(... dict of __main__ like in the example ...);
try {
    handle<>(PyRun_String("import non_existing_module\n",
    Py_file_input,ns.ptr(),ns.ptr()));
} catch (error_already_set) {
    // try to write error information to StringIO buffer
    PyRun_String("import traceback,sys,StringIO\n"
    "buf = StringIO.StringIO()\n"
    "traceback.print_tb(sys.exc_info()[2],None,buf)\n"
    "error = buf.getvalue()\n",
    Py_file_input,ns.ptr(),ns.ptr());
    PyErr_Clear();
    std::string error = extract<std::string>(ns["error"]);
}

I tried also to use extract<const char*> but in both cases I get an
exception in this line. I first tried to get the error information using the
C API, but I could not find a solution. Af a little bit of googling I found
this solution, but I don't know if it's ok: There is still an active
exception, so could I safely continue to use the interpreter to output the
error?
Has somebody an working example on how to get the traceback or could point
me to the right direction?

regards,
Achim




From dave at boost-consulting.com  Thu May 29 17:21:00 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 29 May 2003 11:21:00 -0400
Subject: [C++-sig] Re: Projects Page Reminder
References: <un0h53nad.fsf@boost-consulting.com> <FCEMIEFBFOIDAOJDEPIAEECMFGAA.domma@procoders.net>
 <u65nt3lb7.fsf@boost-consulting.com> <3ED663FD.3070303@globalite.com.br>
Message-ID: <uu1bd22zn.fsf@boost-consulting.com>

Nicodemus <nicodemus at globalite.com.br> writes:

> Dave, my company uses Boost.Python extensively... we create programs
> related to engenering problems, mostly to the oil industry, but it's
> all closed source. You think it would be interesting to put this in
> the page too? I can send more info then.

Definitely.  The page is not exclusively about open-source projects.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Thu May 29 17:35:37 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 29 May 2003 11:35:37 -0400
Subject: [C++-sig] Re: accessing the python type system
References: <8be22df0acd60639897b53a1aa74a17e3ed3986e@Orthosoft.ca> <uwugcci8o.fsf@boost-consulting.com>
 <36fee152f6305c4584d857754653a3823ed4b0f8@Orthosoft.ca>
 <uisrv863r.fsf@boost-consulting.com>
 <4044bacd7ee866c6aba323bb1a8234373ed4d9c2@Orthosoft.ca>
 <uel2j6k2e.fsf@boost-consulting.com>
 <dfdefa07af1558a65ccf00792a5083a33ed4f9ac@Orthosoft.ca>
 <uel2i69nw.fsf@boost-consulting.com>
 <9a7b8d9b4ab3af20d362529dc4edd1cd3ed621bd@Orthosoft.ca>
Message-ID: <uof1l22ba.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> Hi David,
>
> David Abrahams wrote:
>
>>>which means you would be able to hold a boost::python::type
>>>describing another boost::python::type's type (i.e.  the result of
>>>'type(type([]))'.
>>>
>>>What do you want to copy here ?
>> I don't want to copy anything.  I have no choice; type(type(x)) calls
>> type's copy constructor.  I hope that's clear by now.
>
> 'type(x)' is a python expression, right ? 

The question was how to reflect that in the Boost.Python library, so
in the sentence above, no: type(x) is a C++ expression.

> The equivalent in C is
>
> PyObject *the_type = PyObject_Type(the_object);
>
> so your statement seems to imply that there already is some C++ wrapper
> code encapsulating a call to PyObject_Type, and resulting in some class'
> copy constructor to be called. Where can I find that ?

It doesn't exist.  I was responding speculatively to your request:

   "For example holding two python objects I'd like to test whether
   one's type is derived from the other's type, whether they are
   derived from a given type, i.e. things like 'type', 'isinstance',
   etc."

In Python, 'type' is a type, so the most obvious way to reflect that
in C++ would be with a class called 'type', just as we have a class
called tuple in C++ whose constructor performs conversion to a tuple:

   x = tuple(some_list);

when I wrote the following, I was pointing out that it doesn't work:

    "In principle, there's no reason we shouldn't have something like
    you propose, only it should be a wrapper around Python's 'type'
    just the same way that boost::python::dict is a wrapper around
    Python's 'dict'...  but once you start go go down that road you
    get in trouble."

> I was assuming that the C++ API would provide a function somewhat
> similar to
>
> object type(const object &o)
> {
>    return object(borrowed(PyObject_Type(o.ptr())));
> }

I've been trying to say that I think the right answer is to provide a
boost::python::object called 'type', something like:

   object const type = extract<object>(PyTypeObject*);

so you could do:

   object y = type(x);

> or, with a suitable 'type' class defined,
>
> type get_type(const object &o)
> {
>    return type(borrowed(PyObject_Type(o.ptr())));
> }
>
> in which case there is no copy constructor anywhere.

The latter doesn't work, for all the reasons I've been listing.  Users
will expect to be able to do:

      object y = type(x);

which leads directly to the copy constructor problem.

Your statement that there's no copy ctor above is also not true; the
type object is copied when it is returned (though that copy may be
elided).  That is not just an irrelevant nitpick - if type(type(x)) is
not equivalent to type(x) you will get some very strange results.

>>>Or in diagram form:
>>>
>>>  py_object       ->       py_type
>>>     ^                       ^
>>>     |                       |
>>>python::object        python::type
>> What are those things on the first line of the diagram?
>
> the actual python objects (of type 'PyObject').

I see no reason not to use boost::python::object for both roles.

>>     print 'class:',type(x)
>>     print 'metaclass:',type(type(x))
>>     print 'metametaclass:',type(type(type(x)))
>
> fine, the last line tells me that the 'metametaclass' is a 'type'.
> Applying the 'type' operator to that still returns 'type'. It's just
> one level higher up than what I described. So what ?

So I can make it as many levels higher as I like; you said that type
applied to a metaclass is idempotent.  It just isn't true.

> All I was trying to get at is that a way to look at this is as a
> single rooted tree, where each parent node is the 'metaclass' of its
> respective child nodes.

OK, I think I understand how the Python type system is
organized...  again, I'm not sure what your point is.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From phil at freehackers.org  Thu May 29 17:38:47 2003
From: phil at freehackers.org (Philippe Fremy)
Date: Thu, 29 May 2003 17:38:47 +0200
Subject: [C++-sig] Projects Page Reminder
In-Reply-To: <un0h53nad.fsf@boost-consulting.com>
References: <un0h53nad.fsf@boost-consulting.com>
Message-ID: <200305291738.47300.phil@freehackers.org>

On Thursday 29 May 2003 15:17, David Abrahams wrote:
> If you have a project using Boost.Python, and you wouldn't mind if it
> were listed at http://www.boost.org/libs/python/doc/projects.html,
> please send or post the text of an entry for that page!

You can add jayacard:

www.jayacard.org

Jayacard aims at developing a secure portable open source operating system 
for contactless smart cards and a complete suite of high quality 
development tools to ease smart card OS and application development.

The core of the smart card reader management is written in C++ but all the 
development tools are written in the friendly python language. Boost plays 
the fundamental role of binding the tools to our core smart card reader 
library.

	regards,

	Philippe

-- 
Free the mallocs!




From dave at boost-consulting.com  Thu May 29 17:39:46 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 29 May 2003 11:39:46 -0400
Subject: [C++-sig] Re: embedding: getting exception information?
References: <FCEMIEFBFOIDAOJDEPIAOECPFGAA.domma@procoders.net>
Message-ID: <uisrt224d.fsf@boost-consulting.com>

"Achim Domma \(ProCoders\)" <domma at procoders.net> writes:

> Hi,
>
> I'm embedding python in a COM object and want to get the information usually
> printed via PyErr_Print. I tried code like this:
>
> dict ns(... dict of __main__ like in the example ...);
> try {
>     handle<>(PyRun_String("import non_existing_module\n",
>     Py_file_input,ns.ptr(),ns.ptr()));
> } catch (error_already_set) {
>     // try to write error information to StringIO buffer
>     PyRun_String("import traceback,sys,StringIO\n"
>     "buf = StringIO.StringIO()\n"
>     "traceback.print_tb(sys.exc_info()[2],None,buf)\n"
>     "error = buf.getvalue()\n",
>     Py_file_input,ns.ptr(),ns.ptr());
>     PyErr_Clear();
>     std::string error = extract<std::string>(ns["error"]);
> }
>
> I tried also to use extract<const char*> but in both cases I get an
> exception in this line. 

What exception, and what message is associated with it?
Are you sure that buf is a Python string?

> I first tried to get the error information using the C API, but I
> could not find a solution. Af a little bit of googling I found this
> solution, but I don't know if it's ok: There is still an active
> exception, so could I safely continue to use the interpreter to
> output the error?  

That's what Python itself does, so I'm sure it's OK... though you
probably should do it inside a try block in case there's another
exception ;-)

> Has somebody an working example on how to get the traceback or could
> point me to the right direction?

Did you look at the embedding example in
$BOOST_ROOT/libs/python/test/embedding?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From gdoughtie at anim.dreamworks.com  Thu May 29 18:13:36 2003
From: gdoughtie at anim.dreamworks.com (Gavin Doughtie)
Date: Thu, 29 May 2003 09:13:36 -0700
Subject: [C++-sig] embedding: getting exception information?
In-Reply-To: <FCEMIEFBFOIDAOJDEPIAOECPFGAA.domma@procoders.net>
References: <FCEMIEFBFOIDAOJDEPIAOECPFGAA.domma@procoders.net>
Message-ID: <3ED631B0.8090003@anim.dreamworks.com>

Here's what I did:

std::string PythonInterpreterImpl::pythonError() const
{
   PyObject* errType(NULL);
   PyObject* errValue(NULL);
   PyObject* errTraceback(NULL);

   PyErr_Fetch(&errType, &errValue, &errTraceback);
   if (NULL == errValue)
     {
       return "Unknown Python Error";
     }

   handle<> errHandle(errValue);
   str errObj(errHandle);
   char *errMsg = extract< char* >(errObj);
   return errMsg;
}

Achim Domma (ProCoders) wrote:
> Hi,
> 
> I'm embedding python in a COM object and want to get the information usually
> printed via PyErr_Print. I tried code like this:
> 
> dict ns(... dict of __main__ like in the example ...);
> try {
>     handle<>(PyRun_String("import non_existing_module\n",
>     Py_file_input,ns.ptr(),ns.ptr()));
> } catch (error_already_set) {
>     // try to write error information to StringIO buffer
>     PyRun_String("import traceback,sys,StringIO\n"
>     "buf = StringIO.StringIO()\n"
>     "traceback.print_tb(sys.exc_info()[2],None,buf)\n"
>     "error = buf.getvalue()\n",
>     Py_file_input,ns.ptr(),ns.ptr());
>     PyErr_Clear();
>     std::string error = extract<std::string>(ns["error"]);
> }
> 
> I tried also to use extract<const char*> but in both cases I get an
> exception in this line. I first tried to get the error information using the
> C API, but I could not find a solution. Af a little bit of googling I found
> this solution, but I don't know if it's ok: There is still an active
> exception, so could I safely continue to use the interpreter to output the
> error?
> Has somebody an working example on how to get the traceback or could point
> me to the right direction?
> 
> regards,
> Achim
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 

-- 
Gavin Doughtie
DreamWorks SKG
(818) 695-3821




From seefeld at sympatico.ca  Thu May 29 19:12:38 2003
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 29 May 2003 13:12:38 -0400
Subject: [C++-sig] Re: accessing the python type system
References: <8be22df0acd60639897b53a1aa74a17e3ed3986e@Orthosoft.ca> <uwugcci8o.fsf@boost-consulting.com> <36fee152f6305c4584d857754653a3823ed4b0f8@Orthosoft.ca> <uisrv863r.fsf@boost-consulting.com> <4044bacd7ee866c6aba323bb1a8234373ed4d9c2@Orthosoft.ca> <uel2j6k2e.fsf@boost-consulting.com> <dfdefa07af1558a65ccf00792a5083a33ed4f9ac@Orthosoft.ca> <uel2i69nw.fsf@boost-consulting.com> <9a7b8d9b4ab3af20d362529dc4edd1cd3ed621bd@Orthosoft.ca> <uof1l22ba.fsf@boost-consulting.com>
Message-ID: <dc71aee820b4193bd559e2c3e9a4bf7d3ed63cd3@Orthosoft.ca>

David Abrahams wrote:

> I've been trying to say that I think the right answer is to provide a
> boost::python::object called 'type', something like:
> 
>    object const type = extract<object>(PyTypeObject*);
> 
> so you could do:
> 
>    object y = type(x);

oh, now I understand (at least partly). But this last line really
*creates* a type object given another object. So I don't understand
why 'type' has to be an object. Why not simply make it a function ?
Users' expectations would still be satisfied (the last line above
would still be valid), but no copy ctor is called.

Regards,
		Stefan




From dave at boost-consulting.com  Thu May 29 19:39:09 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 29 May 2003 13:39:09 -0400
Subject: [C++-sig] Re: accessing the python type system
References: <8be22df0acd60639897b53a1aa74a17e3ed3986e@Orthosoft.ca> <uwugcci8o.fsf@boost-consulting.com>
 <36fee152f6305c4584d857754653a3823ed4b0f8@Orthosoft.ca>
 <uisrv863r.fsf@boost-consulting.com>
 <4044bacd7ee866c6aba323bb1a8234373ed4d9c2@Orthosoft.ca>
 <uel2j6k2e.fsf@boost-consulting.com>
 <dfdefa07af1558a65ccf00792a5083a33ed4f9ac@Orthosoft.ca>
 <uel2i69nw.fsf@boost-consulting.com>
 <9a7b8d9b4ab3af20d362529dc4edd1cd3ed621bd@Orthosoft.ca>
 <uof1l22ba.fsf@boost-consulting.com>
 <dc71aee820b4193bd559e2c3e9a4bf7d3ed63cd3@Orthosoft.ca>
Message-ID: <uhe7dzm82.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> David Abrahams wrote:
>
>> I've been trying to say that I think the right answer is to provide a
>> boost::python::object called 'type', something like:
>>    object const type = extract<object>(PyTypeObject*);
>> so you could do:
>>    object y = type(x);
>
> oh, now I understand (at least partly). But this last line really
> *creates* a type object given another object. So I don't understand
> why 'type' has to be an object. Why not simply make it a function ?

Because it's an object in Python.  You should be able to say:

        if (x.attr("__class__") == type)
        {
            // whatever
        }

for example.  Or

    type.attr("__doc__")

or...

> Users' expectations would still be satisfied (the last line above
> would still be valid), 

Not all of them.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From mike at bindkey.com  Thu May 29 19:43:30 2003
From: mike at bindkey.com (Mike Rovner)
Date: Thu, 29 May 2003 10:43:30 -0700
Subject: [C++-sig] Re: Support for Indexing and Iteration Safety
References: <u65nv6j6h.fsf@boost-consulting.com>
Message-ID: <bb5grm$lgb$1@main.gmane.org>

"David Abrahams" <dave at boost-consulting.com> wrote in message
news:u65nv6j6h.fsf at boost-consulting.com...
>      1. Unlike most of the other operators, which can be wrapped using
>         "self op other", there's no easy way to wrap the indexing
>         operator.  You end up having to write your own __getitem__
>         and __setitem__ functions.

I don't see any _general_ way to automate that, however it might be worth
for STL containers.
Probably simplistic approach will do; any advanced person can do that
himself and starters will benefit right out of the box.

inline void IndexError()
  { PyErr_SetString(PyExc_IndexError,"Index too large");
throw_error_already_set(); }

template<class T>
struct std_item
{
  typedef typename T::value_type Value;

  static Value const& get(T& x, int n) {
    if( n<0 ) n+=x.size();
    if( n<x.size() && n>=0 ) return x[n];
    IndexError(); }

  static void set(T& x, int n, const Value& val) {
    if( n<0 ) n+=x.size();
    if( n<x.size() && n>=0 ) x[n]=val;
    else IndexError(); }

  static void del(T& x, int n) {
    if( n<0 ) n+=x.size();
    if( n<x.size() && n>=0 ) x.erase(&x[n]);
    else IndexError(); }
};

>      2. You also have to implement the code which raises an exception
>         if the index is out of range or the key is not found (in case
>         you're implementing a mapping).  If you forget, your extension
>         class is prone to crashes and accessing invalid data.

Ditto.

>      3. Even if you get that right, you may still be prone to crashes.
>         Suppose you're wrapping a std::vector<SomeBigObject>.  If you
>         want to support syntax like:

Let's return to basics. What is foo[10]? In C++ it's a memory chunk, in
Python it's an object.
To overcome that difference I propose to introduce differenciation in
wrapping, a la it is in Python: there are tuples and lists; mutable and
immutable. So let user decide what he wants out of foo[10] - mutable object
(a copy), or readonly - an inplace reference.
Again please don't argue about general ineffiency, IMHO better safe than
sorry ..egh crash.
I take for granted that some _simple_ enought way to override that default
behaviour with custom is provided.

>      4. Similar problem with exposed iterators:

Same.

> These problems are not vector-specific.  I have some ideas about
> addressing them but I'm not sure how far to go, and first I want to
> know how many people care.

My 0.02. Hope I made my point clear.

Mike Rovner






From dave at boost-consulting.com  Thu May 29 21:03:24 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 29 May 2003 15:03:24 -0400
Subject: [C++-sig] Re: Support for Indexing and Iteration Safety
In-Reply-To: <001901c32609$d293f960$1500a8c0@MIKE> (Mike Rovner's message of
 "Thu, 29 May 2003 10:43:30 -0700")
References: <001901c32609$d293f960$1500a8c0@MIKE>
Message-ID: <u4r3dzibn.fsf@boost-consulting.com>

Mike, please take this discussion to the C++-sig...

"Mike Rovner" <mike at bindkey.com> writes:

> "David Abrahams" <dave at boost-consulting.com> wrote in message
> news:u65nv6j6h.fsf at boost-consulting.com...
>>      1. Unlike most of the other operators, which can be wrapped using
>>         "self op other", there's no easy way to wrap the indexing
>>         operator.  You end up having to write your own __getitem__
>>         and __setitem__ functions.
>
> I don't see any _general_ way to automate that, however it might be worth
> for STL containers.
> Probably simplistic approach will do; any advanced person can do that
> himself and starters will benefit right out of the box.
>
> inline void IndexError()
>   { PyErr_SetString(PyExc_IndexError,"Index too large");
> throw_error_already_set(); }
>
> template<class T>
> struct std_item
> {
>   typedef typename T::value_type Value;
>
>   static Value const& get(T& x, int n) {
>     if( n<0 ) n+=x.size();
>     if( n<x.size() && n>=0 ) return x[n];
>     IndexError(); }
>
>   static void set(T& x, int n, const Value& val) {
>     if( n<0 ) n+=x.size();
>     if( n<x.size() && n>=0 ) x[n]=val;
>     else IndexError(); }
>
>   static void del(T& x, int n) {
>     if( n<0 ) n+=x.size();
>     if( n<x.size() && n>=0 ) x.erase(&x[n]);
>     else IndexError(); }             ^^^^^
> };                                   ^^^^^
                                   Doesn't work (not an iterator).

I have something a little less simplistic in mind.  Why shouldn't
everyone benefit? ;-)

>>      2. You also have to implement the code which raises an exception
>>         if the index is out of range or the key is not found (in case
>>         you're implementing a mapping).  If you forget, your extension
>>         class is prone to crashes and accessing invalid data.
>
> Ditto.
>
>>      3. Even if you get that right, you may still be prone to crashes.
>>         Suppose you're wrapping a std::vector<SomeBigObject>.  If you
>>         want to support syntax like:
>
> Let's return to basics. What is foo[10]? In C++ it's a memory chunk

I think you mean an lvalue.  That really depends what foo is.  See
vector<bool> for example.

> in Python it's an object.  To overcome that difference I propose to
> introduce differenciation in wrapping, a la it is in Python: there
> are tuples and lists; mutable and immutable. So let user decide what
> he wants out of foo[10] - mutable object (a copy), or readonly - an
> inplace reference.  

Of course the user will have a choice; she already does, using call
policies.  I take choice for granted.  The problem is that an "inplace
reference" as it stands now is not safe, and sometimes you need an
inplace reference.

> Again please don't argue about general ineffiency, IMHO better safe
> than sorry ..egh crash.  

Some people care about efficiency.  If their wrapped program is too
slow we may as well have not provided the wrapper in the first place.
But anyway, efficiency is only one of two obvious reasons to use an
"inplace reference", so it doesn't really matter if you discount that
as an argument.

> I take for granted that some _simple_ enought way to override that
> default behaviour with custom is provided.
>
>>      4. Similar problem with exposed iterators:
>
> Same.

You are not addressing the problem.  The question is:

    is it acceptable that Python users of extension classes should be
    subject to unpredictable behavior and/or crashes when using
    wrapped arrays, mappings, and iterators?

I think the answer should be a loud "no", but from the lack of a
general outcry it seems I might be wrong.

>> These problems are not vector-specific.  I have some ideas about
>> addressing them but I'm not sure how far to go, and first I want to
>> know how many people care.
>
> My 0.02. Hope I made my point clear.

Not really.  The clearest message I can discern is "there's really not
much of a problem". Is that really what you're saying?




From mike at bindkey.com  Thu May 29 22:30:25 2003
From: mike at bindkey.com (Mike Rovner)
Date: Thu, 29 May 2003 13:30:25 -0700
Subject: [C++-sig] Re: Support for Indexing and Iteration Safety
References: <001901c32609$d293f960$1500a8c0@MIKE> <u4r3dzibn.fsf@boost-consulting.com>
Message-ID: <bb5qkl$gks$1@main.gmane.org>

"David Abrahams" <dave at boost-consulting.com> wrote in message
news:u4r3dzibn.fsf at boost-consulting.com...
> Mike, please take this discussion to the C++-sig...
It is there. I did courtesy CC: when posted to -sig because original mail
felt into my e-mail inbox. ;)

> >   static void del(T& x, int n) {
> >     if( n<0 ) n+=x.size();
> >     if( n<x.size() && n>=0 ) x.erase(&x[n]);
> >     else IndexError(); }             ^^^^^
> > };                                   ^^^^^
>                                    Doesn't work (not an iterator).
Sorry. I'm spoiled by MSVC. Hope x.erase( Container<T>::iterator(&x[n]) )
will do?
(with proper Container type)

> I have something a little less simplistic in mind.  Why shouldn't
> everyone benefit? ;-)

It will be very nice thing to have.

> > My 0.02. Hope I made my point clear.
>
> Not really.  The clearest message I can discern is "there's really not
> much of a problem". Is that really what you're saying?

Not really. In my case I made it so with very simplistic approach AND
reducing my usage pattern.
I recall my surprise it isn't in place and sure agree with your answer "loud
NO" to any unpredictable behavior.
So I understand why it's better not to have then have unreliable.
I tried to argue in support of having something shall be reliable out of the
box.
For that goal it may be not the fastest and not the simplest.

Mike






From mike at bindkey.com  Thu May 29 22:44:09 2003
From: mike at bindkey.com (Mike Rovner)
Date: Thu, 29 May 2003 13:44:09 -0700
Subject: [C++-sig] Re: Support for Indexing and Iteration Safety
References: <u65nv6j6h.fsf@boost-consulting.com>
Message-ID: <bb5rec$jqg$1@main.gmane.org>

>            >>> x = foo[10].bar
>            >>> del foo[10]  # erase the 10th item
>            >>> print x

What about having x a weak reference which del will reset to None.

>            >>> x = foo[10]
>            >>> foo[10] = y
>            >>> print x, y
>
>         Now you'll see that x and y are always identical, because x
>         refers to the place in the array where you've written the
>         value of y.

It's ok, because Python have explicit copy semantics
The list isn't the only model.

>      4. Similar problem with exposed iterators:
>          change out from under you.  The above could lead to a crash
>          or bogus results.

bogus results are ok because it's the same as in Python - changing a list
under loop can lead to skiping an element or visiting it twice.

> know how many people care.

I think if it will put some restriction on usage it is ok with me.

Mike






From dave at boost-consulting.com  Thu May 29 23:51:33 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 29 May 2003 17:51:33 -0400
Subject: [C++-sig] Re: Support for Indexing and Iteration Safety
References: <001901c32609$d293f960$1500a8c0@MIKE> <u4r3dzibn.fsf@boost-consulting.com>
 <bb5qkl$gks$1@main.gmane.org>
Message-ID: <ufzmxxvyy.fsf@boost-consulting.com>

"Mike Rovner" <mike at bindkey.com> writes:

> "David Abrahams" <dave at boost-consulting.com> wrote in message
> news:u4r3dzibn.fsf at boost-consulting.com...
>> Mike, please take this discussion to the C++-sig...
> It is there. I did courtesy CC: when posted to -sig because original mail
> felt into my e-mail inbox. ;)
>
>> >   static void del(T& x, int n) {
>> >     if( n<0 ) n+=x.size();
>> >     if( n<x.size() && n>=0 ) x.erase(&x[n]);
>> >     else IndexError(); }             ^^^^^
>> > };                                   ^^^^^
>>                                    Doesn't work (not an iterator).
> Sorry. I'm spoiled by MSVC. Hope x.erase( Container<T>::iterator(&x[n]) )
> will do?
> (with proper Container type)

No, it won't.  Not even with VC7. Something wrong with
x.erase(x.begin() + n)?

>> I have something a little less simplistic in mind.  Why shouldn't
>> everyone benefit? ;-)
>
> It will be very nice thing to have.
>
>> > My 0.02. Hope I made my point clear.
>>
>> Not really.  The clearest message I can discern is "there's really not
>> much of a problem". Is that really what you're saying?
>
> Not really. In my case I made it so with very simplistic approach
> AND reducing my usage pattern.  I recall my surprise it isn't in
> place and sure agree with your answer "loud NO" to any unpredictable
> behavior.  So I understand why it's better not to have then have
> unreliable.  I tried to argue in support of having something shall
> be reliable out of the box.  

I thought you were arguing for "return by value" as a default.  If we
accept the argument for "return by value" we are left unable to modify
array elements:

     foo[x].bar = 1

If we accept simplistic return-by-reference we get a lack of safety.

> For that goal it may be not the fastest and not the simplest.

Agreed.




From dave at boost-consulting.com  Fri May 30 00:00:30 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 29 May 2003 18:00:30 -0400
Subject: [C++-sig] Re: Support for Indexing and Iteration Safety
References: <u65nv6j6h.fsf@boost-consulting.com> <bb5rec$jqg$1@main.gmane.org>
Message-ID: <u4r3dxvk1.fsf@boost-consulting.com>

"Mike Rovner" <mike at bindkey.com> writes:

>>            >>> x = foo[10].bar
>>            >>> del foo[10]  # erase the 10th item
>>            >>> print x
>
> What about having x a weak reference which del will reset to None.

I considered that, but is that really Pythonic and unsurprising?
Anyway, it's not much easier to make work than the one which copies
the referenced object when its position is invalidated.

>>            >>> x = foo[10]
>>            >>> foo[10] = y
>>            >>> print x, y
>>
>>         Now you'll see that x and y are always identical, because x
>>         refers to the place in the array where you've written the
>>         value of y.
>
> It's ok, because Python have explicit copy semantics
> The list isn't the only model.

Huh?  How does "explicit copy semantics" change anything?
What does this have to do with "the list"?

>>      4. Similar problem with exposed iterators:
>>          change out from under you.  The above could lead to a crash
>>          or bogus results.
>
> bogus results are ok because it's the same as in Python - changing a list
> under loop can lead to skiping an element or visiting it twice.

Yes, but it will never crash.

>> know how many people care.
>
> I think if it will put some restriction on usage it is ok with me.

Do you mean to say that it's OK to expose the user to crashes as long
as we tell him what he's allowed to do, and only crash if he disobeys?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From mike at bindkey.com  Fri May 30 00:41:21 2003
From: mike at bindkey.com (Mike Rovner)
Date: Thu, 29 May 2003 15:41:21 -0700
Subject: [C++-sig] Re: Support for Indexing and Iteration Safety
References: <u65nv6j6h.fsf@boost-consulting.com> <bb5rec$jqg$1@main.gmane.org> <u4r3dxvk1.fsf@boost-consulting.com>
Message-ID: <bb62a5$j2p$1@main.gmane.org>

"David Abrahams" <dave at boost-consulting.com> wrote in message
news:u4r3dxvk1.fsf at boost->
> >>            >>> x = foo[10].bar
> >>            >>> del foo[10]  # erase the 10th item
> >>            >>> print x
> >
> > What about having x a weak reference which del will reset to None.
> I considered that, but is that really Pythonic and unsurprising?

IMHO yes

> Anyway, it's not much easier to make work than the one which copies
> the referenced object when its position is invalidated.

Instead of making x a copy on the fly? Refusing to del?
I think both of them less pythonic.

> >>            >>> x = foo[10]
> >>            >>> foo[10] = y
> >>            >>> print x, y
> >>
> >>         Now you'll see that x and y are always identical, because x
> >>         refers to the place in the array where you've written the
> >>         value of y.
> >
> > It's ok, because Python have explicit copy semantics
> > The list isn't the only model.
>
> Huh?  How does "explicit copy semantics" change anything?
> What does this have to do with "the list"?

I mean foo[10] is not (foo.as_list())[10]
if I assume foo[10] ia an object, then
x=foo[10] is making a reference to it (in python) like x=a
Then a=y will make x and a both reference to y.

Well, it doesn't sound clear even to me :) Sorry.
I'm trying to tell than foo[10] may be considered not a 10th element of LIST
foo
and in that case asking for explicit copy is wholeheart pythonic.

> >>      4. Similar problem with exposed iterators:
> >>          change out from under you.  The above could lead to a crash
> >>          or bogus results.
> >
> > bogus results are ok because it's the same as in Python - changing a
list
> > under loop can lead to skiping an element or visiting it twice.
>
> Yes, but it will never crash.

> > I think if it will put some restriction on usage it is ok with me.
>
> Do you mean to say that it's OK to expose the user to crashes as long
> as we tell him what he's allowed to do, and only crash if he disobeys?

Yes if that will not be the default, but explicitly asked for (for speed
reasons may be).

Regards,
Mike






From gilles.orazi at varianinc.com  Fri May 30 11:05:33 2003
From: gilles.orazi at varianinc.com (Gilles Orazi)
Date: Fri, 30 May 2003 11:05:33 +0200
Subject: [C++-sig] [newbie] Failing to test boost.python under cygwin
Message-ID: <000b01c3268a$a4799680$6dc8be0a@NICOIS>

Hello,

 

I am trying to build the Boost.Python examples under cygwin and faces
some problems. 

I set the environement variables like that (taken from a post in the
archives) :

 

export PYTHON='E:\cygwin\bin\python.exe'

export PYTHON_ROOT='E:\cygwin\lib\python2.2'

export PYTHON_VERSION='2.2'

export PYTHON_INCLUDES='E:\cygwin\usr\include\python2.2'

export PYTHON_LIB_PATH='E:\cygwin\lib\python2.2\config'

export PYTHON_STDLIB_PATH='E:\cygwin\lib\python2.2'

export GCC_PYTHON_ROOT='E:\cygwin\usr'

 

This is what I get :

 

$ bjam -sTOOLS=gcc test

don't know how to make <libs!python!example>test_getting_started1.py

don't know how to make E:\cygwin\bin\python.exe

don't know how to make <libs!python!example>test_getting_started2.py

...found 1922 targets...

...can't find 3 targets...

...can't make 2 targets...

...skipped
<libs!python!example/test1.test/gcc/debug/runtime-link-dynamic>test1.

test for lack of <libs!python!example>test_getting_started1.py...

...skipped
<libs!python!example/test2.test/gcc/debug/runtime-link-dynamic>test2.

test for lack of <libs!python!example>test_getting_started2.py...

...skipped 2 targets...

 

What's going wrong here ?

 

Thanks by advance for your help.

---

Gilles

 

 

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

From brett.calcott at paradise.net.nz  Fri May 30 14:35:29 2003
From: brett.calcott at paradise.net.nz (Brett Calcott)
Date: Sat, 31 May 2003 00:35:29 +1200
Subject: [C++-sig] Re: Support for Indexing and Iteration Safety
References: <u65nv6j6h.fsf@boost-consulting.com> <bb4q13$50f$1@main.gmane.org> <uhe7d3m53.fsf@boost-consulting.com>
Message-ID: <bb7jcm$p59$1@main.gmane.org>

>
> <snip my entire posting quoted>

oops, apologies for the noise.

>
> > I'm haven't gone far enough in what I am doing to encounter these
> > problems, but for what its worth, at the moment I would have done
> > the following:
> >
> >     if something is lightweight, return a copy
> >     if it is big, use shared_ptr
> >
> > Which means that the above problems 3 & 4 would not occur.
>
> That is only true if you can modify your vector to be a
> vector<shared_ptr<SomeBigObject> >.  Often, the implementation of code
> being wrapped can't be intrusively changed in that way.  -

Right -- but in my case, I'm writing that code as well, so I can be as
intrusive as I want (you did ask if it bothered *me*)

> Furthermore, even if it's lightweight, returning a copy gets you
> unpredictable behavior like:
>
>       >>> v[3].foo = 1
>       >>> v[3].foo
>       22
>
> because you've only set the attribute on the copy.
>

It won't crash, but it is annoying. Okay, *really* annoying.

>
> Did I change your mind yet? ;->
>
If you could solve the above problem it would be great. But I can live
without it.

I realise I am in a somewhat unique position though. I am the producer
of the C++ lib, and the python lib - AND I am the only consumer. So I
can live happily with workarounds. If I was publishing my material for
general consumption, I might be thinking differently.


> <snip a duplicate copy of the entire foregoing text>
>
Ugh -- must learn decent newsreader and stop cutting and pasting.






From gdoughtie at anim.dreamworks.com  Fri May 30 19:41:46 2003
From: gdoughtie at anim.dreamworks.com (Gavin Doughtie)
Date: Fri, 30 May 2003 10:41:46 -0700
Subject: [C++-sig] custom less than operator?
 to_python_converter for multiple destination
 types?
Message-ID: <3ED797DA.5070501@anim.dreamworks.com>

So, I'm wrapping a class that defines "<" as an internal class with a 
bool operator() like so:

struct Baz
{
	struct Less
	{
		bool operator() (const Baz& a, const Baz& b) const;
	}
};

Inconveniently, it also does NOT define operator < in Baz. How would I 
wrap this to make Baz objects in Python use Baz::Less::operator() as the 
  < operator?

-- 
Gavin Doughtie
DreamWorks SKG
(818) 695-3821




From dirk at gerrits.homeip.net  Fri May 30 21:45:58 2003
From: dirk at gerrits.homeip.net (Dirk Gerrits)
Date: Fri, 30 May 2003 21:45:58 +0200
Subject: [C++-sig] Re: [newbie] Question on embedding/extending with boost::python
In-Reply-To: <bb4ple$3ct$1@main.gmane.org>
References: <bam1c6$27k$1@main.gmane.org> <bb0kk2$9q2$1@main.gmane.org> <bb24tg$d4f$1@main.gmane.org> <bb3brb$qgq$1@main.gmane.org> <bb4ple$3ct$1@main.gmane.org>
Message-ID: <bb8c9p$g8u$1@main.gmane.org>

Brett Calcott wrote:
> "Dirk Gerrits" <dirk at gerrits.homeip.net> wrote:
> 
>>Brett Calcott wrote:
>>
>>>I had previously embedded python in my c++ app so that I could
>>>script my agents, but the result was very slow as this effectively
>>>did this (vastly simplified)
>>>
[snip]
>>>
>>>The calls to python are in the inner loop and this is slow.
>>
>>Well I suppose you could expose a visual_stuff_updating_iterator to
>>Python, but extending is of course a much easier and cleaner.
> 
> 
> Not sure I follow what you mean here..

Well I just thought you could let Python drive the loop by exposing the 
agents.begin()/end() range as an iterator, possibly with the visual 
stuff updating built into it. But if it would be more efficient at all, 
it would probably not be by much. As I said, your current solution is 
much nicer (and efficient).

[snip]

>>I'm not sure I follow. Is engine.cycle() still doing a
>>a->update_yourself_via_python() for every agent? Then where's the
>>speedup compared to the embedded approach?
>>
> 
> No, it's not. The engine.cycle() function never calls back to python.
> 
> Let me try and clarify.
> 
[snip]
> 
> To summarise -- that big change is in how I look at python. Before, I
> saw C++ as a serious development framework, and python as a scripting
> language for doing the little bits of my app that I wanted to change
> quickly. Now, I see python as an incredibly fast development framework,
> and C++ as something to make the computationally intensive bits of my
> app go faster.
> 
> So I things have sort of been stood on their head.  I still love C++,
> but I can make stuff happen so much more quickly in python.

I think most (all?) using this SIG can agree to that. :)

Regards,
Dirk Gerrits





From dave at boost-consulting.com  Fri May 30 22:29:44 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 30 May 2003 16:29:44 -0400
Subject: [C++-sig] Re: custom less than operator? to_python_converter for multiple
 destination types?
References: <3ED797DA.5070501@anim.dreamworks.com>
Message-ID: <u8ysow53b.fsf@boost-consulting.com>

Gavin Doughtie <gdoughtie at anim.dreamworks.com> writes:

> So, I'm wrapping a class that defines "<" as an internal class with a
> bool operator() like so:
>
> struct Baz
> {
> 	struct Less
> 	{
> 		bool operator() (const Baz& a, const Baz& b) const;
> 	}
> };
>
> Inconveniently, it also does NOT define operator < in Baz. How would I
> wrap this to make Baz objects in Python use Baz::Less::operator() as
> the < operator?



bool BazLess(Baz const& a, Baz const& b)  { return Baz::Less()(a,b); }

class <Baz>("Baz")
    .def("__lt__", BazLess)
    ...



HTH,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From gdoughtie at anim.dreamworks.com  Fri May 30 22:38:11 2003
From: gdoughtie at anim.dreamworks.com (Gavin Doughtie)
Date: Fri, 30 May 2003 13:38:11 -0700
Subject: [C++-sig] Re: custom less than operator? to_python_converter
 for multiple destination types?
In-Reply-To: <u8ysow53b.fsf@boost-consulting.com>
References: <3ED797DA.5070501@anim.dreamworks.com> <u8ysow53b.fsf@boost-consulting.com>
Message-ID: <3ED7C133.3000209@anim.dreamworks.com>

OK, that's exactly what I ended up doing. Just thinking there might be 
something niftier.

Gavin

David Abrahams wrote:
> Gavin Doughtie <gdoughtie at anim.dreamworks.com> writes:
> 
> 
>>So, I'm wrapping a class that defines "<" as an internal class with a
>>bool operator() like so:
>>
>>struct Baz
>>{
>>	struct Less
>>	{
>>		bool operator() (const Baz& a, const Baz& b) const;
>>	}
>>};
>>
>>Inconveniently, it also does NOT define operator < in Baz. How would I
>>wrap this to make Baz objects in Python use Baz::Less::operator() as
>>the < operator?
> 
> 
> 
> 
> bool BazLess(Baz const& a, Baz const& b)  { return Baz::Less()(a,b); }
> 
> class <Baz>("Baz")
>     .def("__lt__", BazLess)
>     ...
> 
> 
> 
> HTH,

-- 
Gavin Doughtie
DreamWorks SKG
(818) 695-3821




From nicodemus at globalite.com.br  Sat May 31 04:20:14 2003
From: nicodemus at globalite.com.br (Nicodemus)
Date: Fri, 30 May 2003 18:20:14 -0800
Subject: [C++-sig] missing boost::ref in pyste generated code?
In-Reply-To: <1053960018.16477.166.camel@lxcms25>
References: <1053960018.16477.166.camel@lxcms25>
Message-ID: <3ED8115E.7060605@globalite.com.br>


Giulio Eulisse wrote:

>as it seem to pass Ev by value, instead of passing it by reference.
>We fixed it by adding boost::ref where indicated in the sourcecode as
>otherwise it tries to pass things by value. Is this a bug or am I doing
>something wrong?
>  
>

Sorry for missing this post, Giulio!

Pyste doesn't do it because it's not safe, otherwise Boost.Python would 
do that by default. Dave can elaborate better on that.





From camelo at esss.com.br  Fri May 30 23:25:31 2003
From: camelo at esss.com.br (Marcelo A. Camelo)
Date: Fri, 30 May 2003 18:25:31 -0300
Subject: [C++-sig] Attempted a typeid of NULL pointer!
In-Reply-To: <3ED7C133.3000209@anim.dreamworks.com>
Message-ID: <01d401c326f1$fffefa60$0d00000a@esss.com.br>

Hi!

A simple one: I'm trying to wrap a function that returns 
a shared_ptr of a wrapped type (this type has been wrapped
with shared_ptr as its held_type). Everything goes fine
as long as the shared_ptr holds a valid pointer. If its
value is NULL (which is a valid value within the wrapped 
C++ context), it raises the following exception:

	RuntimeError: Attempted a typeid of NULL pointer!

Shouldn't it return None?

 

Marcelo A. Camelo, M. Eng. - Project Leader
ESSS - Engineering Simulation and Scientific Software
 
E-mail: camelo at esss.com.br
Phone: +55-48-239-2226
 




From gdoughtie at anim.dreamworks.com  Fri May 30 23:42:02 2003
From: gdoughtie at anim.dreamworks.com (Gavin Doughtie)
Date: Fri, 30 May 2003 14:42:02 -0700
Subject: [C++-sig] Custom exceptions
Message-ID: <3ED7D02A.7030900@anim.dreamworks.com>

So, let's say I want to register a custom exception which python code 
can catch, thusly:

try:
	doSomething()
except mymodule.MyException e:
	print e

Is there anything in boost python that makes setting this up easy? I've 
got a working exception translator and everything, but I don't see 
anything equivalent to putting 
"PyErr_NewException("mymodule.MyException", NULL, NULL)" into the system 
dictionary during module initialization.

Or am I just working too hard again?

-- 
Gavin Doughtie
DreamWorks SKG





From dave at boost-consulting.com  Sat May 31 04:15:20 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 30 May 2003 22:15:20 -0400
Subject: [C++-sig] Re: Attempted a typeid of NULL pointer!
References: <3ED7C133.3000209@anim.dreamworks.com> <01d401c326f1$fffefa60$0d00000a@esss.com.br>
Message-ID: <uadd3vp3b.fsf@boost-consulting.com>

"Marcelo A. Camelo" <camelo at esss.com.br> writes:

> Hi!
>
> A simple one: I'm trying to wrap a function that returns 
> a shared_ptr of a wrapped type (this type has been wrapped
> with shared_ptr as its held_type). Everything goes fine
> as long as the shared_ptr holds a valid pointer. If its
> value is NULL (which is a valid value within the wrapped 
> C++ context), it raises the following exception:
>
> 	RuntimeError: Attempted a typeid of NULL pointer!
>
> Shouldn't it return None?

Boost Version?  CVS?  Code for reproducing the problem?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From gaiacrtn at free.fr  Sat May 31 11:22:18 2003
From: gaiacrtn at free.fr (Baptiste Lepilleur)
Date: Sat, 31 May 2003 11:22:18 +0200
Subject: [C++-sig] Re: Attempted a typeid of NULL pointer!
References: <3ED7C133.3000209@anim.dreamworks.com> <01d401c326f1$fffefa60$0d00000a@esss.com.br> <uadd3vp3b.fsf@boost-consulting.com>
Message-ID: <030801c32756$228afa70$469ac2d4@gaia>

I've run into the same issue yesterday. I'm using boost 1.30 with MSVC 6.

This problem arise when trying to obtain a default constructed shared_ptr in
python. It seems that the conversion of a null shared_ptr to None is not
handled. Though, I don't know if this feature is supported (the unit-test
for shared_ptr is too complicated for me to understand).


Here is the python code. It only fail when 'statement.elseStatement' is a
NULL shared_ptr.
    def visitIfStatement( self, statement ):
        self._visitScopedSubstatement( statement.thenStatement )

        if statement.elseStatement:        # C++ property which is a
shared_ptr
            self._visitScopedSubstatement( statement.elseStatement )
---
  File "C:\prg\vc\Rfta\src\pyrfta\test\rfta\codeanalysis.py", line 39, in
visitIfStatement
    if statement.elseStatement:
RuntimeError: Attempted a typeid of NULL pointer!
---

Notes that using explicit comparison against None also fail:
        if None != statement.elseStatement:


The IfStatement C++ class.

typedef boost::shared_ptr<Statement> StatementPtr;
typedef boost::shared_ptr<IfStatement> IfStatementPtr;

class RFTA_API IfStatement : public ConditionStatement
{
public:
// ...
   StatementPtr getElseStatement() const;

private:
    StatementPtr elseStatement_;
};

The code used to expose the IfStatement:
   class_<IfStatement, IfStatementPtr, bases<ConditionStatement>,
boost::noncopyable>( "IfStatement",

init<ExpressionPtr, StatementPtr>() )
     .def( init<ExpressionPtr, StatementPtr, StatementPtr>() )
// ...
     .add_property( "elseStatement", &IfStatement::getElseStatement,
                                     &IfStatement::setElseStatement )
     ;

Baptiste.

----- Original Message ----- 
From: "David Abrahams" <dave at boost-consulting.com>
To: <c++-sig at python.org>
Sent: Saturday, May 31, 2003 4:15 AM
Subject: [C++-sig] Re: Attempted a typeid of NULL pointer!


> "Marcelo A. Camelo" <camelo at esss.com.br> writes:
>
> > Hi!
> >
> > A simple one: I'm trying to wrap a function that returns
> > a shared_ptr of a wrapped type (this type has been wrapped
> > with shared_ptr as its held_type). Everything goes fine
> > as long as the shared_ptr holds a valid pointer. If its
> > value is NULL (which is a valid value within the wrapped
> > C++ context), it raises the following exception:
> >
> > RuntimeError: Attempted a typeid of NULL pointer!
> >
> > Shouldn't it return None?
>
> Boost Version?  CVS?  Code for reproducing the problem?
>
> -- 
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com




From milind_patil at hotmail.com  Sat May 31 17:28:05 2003
From: milind_patil at hotmail.com (Milind Patil)
Date: Sat, 31 May 2003 08:28:05 -0700
Subject: [C++-sig] Re: Projects Page Reminder
References: <un0h53nad.fsf@boost-consulting.com>
Message-ID: <bbahi9$222$1@main.gmane.org>

Testbuilder, www.testbuilder.net, is a C++ class library that extends C++
into an advanced testbench development language
for verifying RTL (Register Transfer Languag) designs of ASICs.

The current project is an attempt to extend testbuilder into python. Boost
python and pyste has made this extension development

(testbuilder c++ is a very large library) extremely fast and easy. The
python extension will ultimately be released into public domain.



Thanks,

Milind






From dave at boost-consulting.com  Sat May 31 18:29:33 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 31 May 2003 12:29:33 -0400
Subject: [C++-sig] Re: Attempted a typeid of NULL pointer!
References: <3ED7C133.3000209@anim.dreamworks.com> <01d401c326f1$fffefa60$0d00000a@esss.com.br>
 <uadd3vp3b.fsf@boost-consulting.com> <030801c32756$228afa70$469ac2d4@gaia>
Message-ID: <u3civkrki.fsf@boost-consulting.com>

"Baptiste Lepilleur" <gaiacrtn at free.fr> writes:

> I've run into the same issue yesterday. I'm using boost 1.30 with MSVC 6.
>
> This problem arise when trying to obtain a default constructed shared_ptr in
> python. It seems that the conversion of a null shared_ptr to None is not
> handled. Though, I don't know if this feature is supported (the unit-test
> for shared_ptr is too complicated for me to understand).
>
>
> Here is the python code. It only fail when 'statement.elseStatement' is a
> NULL shared_ptr.
>     def visitIfStatement( self, statement ):
>         self._visitScopedSubstatement( statement.thenStatement )
>
>         if statement.elseStatement:        # C++ property which is a
> shared_ptr
>             self._visitScopedSubstatement( statement.elseStatement )
> ---
>   File "C:\prg\vc\Rfta\src\pyrfta\test\rfta\codeanalysis.py", line 39, in
> visitIfStatement
>     if statement.elseStatement:
> RuntimeError: Attempted a typeid of NULL pointer!
> ---
>
> Notes that using explicit comparison against None also fail:
>         if None != statement.elseStatement:

OK, I'm working on a fix.  I'll let you know when it's done.  Thanks
for the bug reports.

[By the way...  This is no way to report such a simple bug as simple
as this one.  In order to use your code I have to fill in lots of
missing details, like the definition of ConditionStatement, so I
didn't use the code at all.  It's not much better than the previous
post which gave no information about how to reproduce the problem.]

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Sat May 31 18:40:46 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 31 May 2003 12:40:46 -0400
Subject: [C++-sig] Re: Attempted a typeid of NULL pointer!
References: <3ED7C133.3000209@anim.dreamworks.com> <01d401c326f1$fffefa60$0d00000a@esss.com.br>
 <uadd3vp3b.fsf@boost-consulting.com> <030801c32756$228afa70$469ac2d4@gaia>
 <u3civkrki.fsf@boost-consulting.com>
Message-ID: <uwug7jchd.fsf@boost-consulting.com>

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

> OK, I'm working on a fix.  I'll let you know when it's done.  Thanks
> for the bug reports.

OK, it's in the CVS.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




From dave at boost-consulting.com  Sat May 31 21:06:17 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 31 May 2003 15:06:17 -0400
Subject: [C++-sig] Re: [newbie] Failing to test boost.python under cygwin
References: <000b01c3268a$a4799680$6dc8be0a@NICOIS>
Message-ID: <ur86fj5qu.fsf@boost-consulting.com>

"Gilles Orazi" <gilles.orazi at varianinc.com> writes:

> I set the environement variables like that (taken from a post in the
> archives) :

You can't just copy something out of a post in the message archives
and expect it to work, since everyone's configuration is different.
Did you read
http://www.boost.org/libs/python/doc/building.html#configuration ?

> export PYTHON='E:\cygwin\bin\python.exe'
>
> export PYTHON_ROOT='E:\cygwin\lib\python2.2'
>
> export PYTHON_VERSION='2.2'
>
> export PYTHON_INCLUDES='E:\cygwin\usr\include\python2.2'
>
> export PYTHON_LIB_PATH='E:\cygwin\lib\python2.2\config'
>
> export PYTHON_STDLIB_PATH='E:\cygwin\lib\python2.2'
>
> export GCC_PYTHON_ROOT='E:\cygwin\usr'

When building from Cygwin, you should use a version of bjam built
under Cygwin and use Cygwin-style paths.  Paradoxically, you don't
need the variables listed in the link above that begin with
CYGWIN_...; those are just for when you're using Cygwin GCC from a
regular windows build of bjam.  On my Python installation, it's
sufficient to do:

    export PYTHON_ROOT=/usr

and let the defaults for all the other settings take effect.

HTH,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com