From xin at xlevus.net  Thu Jul  1 08:41:51 2004
From: xin at xlevus.net (xin)
Date: Wed, 30 Jun 2004 23:41:51 -0700
Subject: [C++-sig] Accessing C++ values from within Python
Message-ID: <cbu8sl$jkr$1@sea.gmane.org>

Hi.
I have a setup such as the following:

class object {
public:
	void doSomthingElse();
	float x;
	float *y;
	Somthing SomePyScript;
};

int main()
{
	object *array = new object[10]; // size of array is only an example
	for (int i = 0; i < 10; i++)
	{
		array[i].y = new float[array[i]]
		RunPythonScript(array[i]);
	}
	return 1;
}

Where:
  - " Somting SomePyScript; " Is some reference to a python script that is 
affiliated with this instance of the class (varies from instance to instance)
  - " RunPythonScript(array[i]); " Is some method of running the python script 
that is affiliated with the instance array[i].

My intention is that the python scripts change values within the class 'object'
e.g. The python code sets 'x' to equal 0.9. And then sets each value of y to 
equal a muliple of 9. (y[0] = 0, y[1] = 9, y[2] = 18, ... ,y[100] = 900 etc...)

Is this at all possible? Is it possible without moving all the memory from one 
place, to another area accessable by both python and then back again? If so how 
would I go about doing it?

I've tried all sorts of methods of attempting this, but have had no luck. Any 
help would be appreciated.

Thanks.




From faheem at email.unc.edu  Thu Jul  1 05:43:16 2004
From: faheem at email.unc.edu (Faheem Mitha)
Date: Thu, 1 Jul 2004 03:43:16 +0000 (UTC)
Subject: [C++-sig] Re: compile errors with embedding example from tutorial
References: <slrncdv7fb.om1.faheem@Chrestomanci.home.earth>
	<2096514e040627214639a53ca5@mail.gmail.com>
	<slrnce0mgb.om1.faheem@Chrestomanci.home.earth>
	<2096514e04062813561ceb1d79@mail.gmail.com>
	<slrnce17gj.om1.faheem@Chrestomanci.home.earth>
	<uhdsutl9n.fsf@boost-consulting.com>
Message-ID: <slrnce722k.om1.faheem@Chrestomanci.home.earth>

On Tue, 29 Jun 2004 11:51:48 -0400, David Abrahams
<dave at boost-consulting.com> wrote:

> Faheem Mitha <faheem at email.unc.edu> writes:
>
>> On Mon, 28 Jun 2004 15:56:13 -0500, Chad Austin <caustin at gmail.com> wrote:
>>> On Mon, 28 Jun 2004 17:48:59 +0000 (UTC), Faheem Mitha
>>> <faheem at email.unc.edu> wrote:
>>>> 
>>>> On Sun, 27 Jun 2004 23:46:06 -0500, Chad Austin <caustin at gmail.com> wrote:
>>
>>> Nope, sorry...  I had a problem similar to that in that __builtins__
>>> wasn't getting set in my modules, but I was doing some weird stuff. 
>>> You may want to at least check that __builtins__ is set in your
>>> script.
>>
>> How should I do that? I thought that
>>
>> handle<> main_module(borrowed( PyImport_AddModule("__main__") ));
>> handle<> main_namespace(borrowed( PyModule_GetDict(main_module.get())));
>>
>> should do the trick, though I don't really understand what these lines
>> do. 
>
> What specifically are you confused about? Did you check the docs?  

Yes. Lots. I've got multiple windows open in my (tabbed) browser) with
various bits of the tutorial, the reference manual, and various
googled past messages from the mailing list, and I've been looking at
these all weekend. There are various things that are fuzzy, but for
the moment I'd just like to concentrate on getting an example compiled
and working.

> I don't know why you'd do it that way when you can write:

Well, this is direct from the tutorial.

>   object main_module(handle<>(borrowed( PyImport_AddModule("__main__"))));
>   object main_namespace = main_module.attr("__dict__");
>
> instead.

This does not compile with gcc 3.3.4 on Debian. I get the following
errors:

embed.cc:29: error: variable declaration is not allowed here
embed.cc:30: error: request for member `attr' in `main_module', which
is of non-aggregate type `boost::python::api::object ()()'
error: command 'gcc' failed with exit status 1

with the code

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

void foo()
{
  Py_Initialize(); 
  object main_module(handle<>(borrowed
	(PyImport_AddModule("__main__"))));
  object main_namespace = main_module.attr("__dict__"); 
  (handle<>( PyRun_String("hello = file('hello.txt', 'w')\n"
			 "hello.write('Hello world!')\n"
                           "hello.close()", Py_file_input,
                           main_namespace.ptr(),main_namespace.ptr())));    
    Py_Finalize();
}

BOOST_PYTHON_MODULE(embed)
{
  def("foo",foo);
}
*************************************************************************

I thought that perhaps I had the wrong compiler flags, so I tried it
with bjam and the Boost Build system, and I get the same errors.

However, if I replace

object main_module(handle<>(borrowed
	(PyImport_AddModule("__main__"))));

by  

object main_module = object(handle<>(borrowed
	( PyImport_AddModule("__main__"))));

as suggested in a recent post of yours, it compiles. If this is a gcc
bug, as you say, has it been reported? If you can briefly explain to
me what the bug is, I'd be happy to send in a report, unless it has
already been fixed in gcc 3.4. (Can anyone check this?)

However, like the earlier code I was using, it fails to run.

Ie. I get the following errors when I try to load the code:
***************************************************************************
In [2]: embed.foo()
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)

/home/faheem/wc/corrmodel/boost/<console>

/home/faheem/wc/corrmodel/boost/<string>

NameError: name 'file' is not defined
*****************************************************************************

It cannot find the built-in `file'. Any suggestions about what is wrong
here, and how to fix it? I am keen to try and get at least some basic
examples of embedding working.

Can anyone reproduce this problem on Linux with gcc?

Unfortunately, I have other problems with the version I compiled using
Boost Build, so I can't currently test that. (Subject for another
message.)

I think that once I have a few examples working on Debian, I will
contribute basic examples along with build instructions to the Debian
package, if they will take it. It may be useful for other people.

>> I wonder if the fact that I am calling the interpreter inside an
>> extension module is causing any problems.

> Certainly not.  Calling the interpreter inside an extension module
is normal.

Good to know. Well, if that is not the problem, I am not sure what it
could be. Please help.

                                                             Faheem.




From caustin at gmail.com  Thu Jul  1 05:00:19 2004
From: caustin at gmail.com (Chad Austin)
Date: Wed, 30 Jun 2004 22:00:19 -0500
Subject: [C++-sig] Re: Calling a python function from C++ (from Jeff Holle)
In-Reply-To: <cbvbt6$k5r$1@sea.gmane.org>
References: <40E142ED.2030603@verizon.net> <cbutac$gs6$1@sea.gmane.org>
	<cbvbt6$k5r$1@sea.gmane.org>
Message-ID: <2096514e0406302000530e12e0@mail.gmail.com>

Straight from my codebase:

    std::string getPythonErrorString() {
        // Extra paranoia...
        if (!PyErr_Occurred()) {
            return "No Python error";
        }

        PyObject *type, *value, *traceback;
        PyErr_Fetch(&type, &value, &traceback);
        PyErr_Clear();

        std::string message = "Python error: ";
        if (type) {
            type = PyObject_Str(type);
            message += PyString_AsString(type);
        }
        if (value) {
            value = PyObject_Str(value);
            message += ": ";
            message += PyString_AsString(value);
        }
        Py_XDECREF(type);
        Py_XDECREF(value);
        Py_XDECREF(traceback);

        return message;
    }

    void checkForPythonError() {
        if (PyErr_Occurred()) {
            throw PythonError(getPythonErrorString());
        }
    }

    void requirePythonError() {
        if (!PyErr_Occurred()) {
            throw PythonError("Boost.Python exception, "
                              "but no Python error set.");
        }
    }

...

    PYR_DEFINE_RUNTIME_ERROR(PythonError);

    std::string getPythonErrorString();
    void checkForPythonError();
    void requirePythonError();

    /**
     * Allows us to check for Python errors at the end of a Python
     * code block whether control left the end of the block or
     * 'return' was used.
     */
    struct PythonCodeErrorSentry {
        ~PythonCodeErrorSentry() {
            if (!std::uncaught_exception()) {
                checkForPythonError();
            }
        }
    };

    #define PYR_NO_UNUSED_WARNING(x) ((void)&(x))

    #define PYR_BEGIN_PYTHON_CODE()                          \
        try {                                                \
            PythonCodeErrorSentry sentry__;                  \
            PYR_NO_UNUSED_WARNING(sentry__);  // silly gcc

    #define PYR_END_PYTHON_CODE()                            \
        }                                                    \
        catch (const boost::python::error_already_set&) {    \
            requirePythonError();                            \
            throw PythonError(getPythonErrorString());       \
        }


May have bugs, but it should give you an idea of what to do.  Notice I
don't do anything with the stacktrace object yet, but it wouldn't take
much more work.

HTH,
Chad


On Wed, 30 Jun 2004 02:39:46 -0400, Jeffrey Holle
<jeff.holle at verizon.net> wrote:
> 
> Given what the name of this exception, I assume there is a source of
> information to obtain useful information about it.
> To this end, I've dug a bit into the Python C API and found the added
> the following to my code example:
> 
>    catch (error_already_set& x) {
>         PyObject *err_type,*err_value,*err_traceback;
>         PyErr_Fetch(&err_type,&err_value,&err_traceback);
>          cout << "something bad happened" << endl;
>      }
> 
> While I see that err_type and error_value are not null pointers after
> the call to PyErr_Fetch, I don't know what to do with either to get at a
> useful message.
> Can anybody provide any hints?
> 
> 
> 
> Jeffrey Holle wrote:
> > I've explored whats actually going on some with my debugger and now see
> > what is being thrown.
> > It is "error_already_set".  This is a trivial object (it has no
> > attributes at all), and isn't much better than "catch (...)".
> > However, its name implies something.  Is there a meaningful error
> > message set somewhere else that can be accessed within the catch clause
> > of "error_already_set"?
> >
> > Jeff Holle wrote:
> >
> >>>
> >>>
> >>>> An underlining concern I have is error handling.  When
> >>>> PyImport_ImportModule fails, a NULL pointer is returned.
> >>>> Seems like the underlining machinery in "handle<>" is intolerant of
> >>>> this.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> What makes you say that?
> >>>
> >> You are correct about the success in compiling your much cleaner
> >> example, and it works :-) , but has a flaw.
> >>
> >> When I hide the needed python script, the call to
> >> PyImport_ImportModule returns NULL.
> >> When this occurres, both your example and what I had created, but
> >> commented out throws something because I can catch it with
> >> "catch(...)".  I don't however know how to be more specific.  Any
> >> hints?  Whatever it is, it doesn't inherit from "exception".
> >>
> >> If I was operating on windows, I would anticipate it was a "structured
> >> exception", or whatever Microsoft calls their propritary stuff.  Don't
> >> know of the equivalent on linux though.  Without the "catch (...)",
> >> the command line program exits with "Aborted".
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>



From gfilla at gmail.com  Thu Jul  1 07:52:03 2004
From: gfilla at gmail.com (Drew Ferraro)
Date: Thu, 1 Jul 2004 01:52:03 -0400
Subject: [C++-sig] please help with simple program crashing
Message-ID: <352b386804063022526df14a1e@mail.gmail.com>

hi,

ive recently trying to add a scripting system to a game i am making..
anyway, ive started to learn python and am trying to figure out how to
embed it in my game. i have gotten a C++ function to work from inside
C++ but called from python via PyRun_SimpleString(),,, i can send
commands directly to the intepreter with that function, but im having
a problem
 with PyRun_SimpleFile(). im trying to execute a python script with
this function, but its crashing when it gets to this line:

 PyRun_SimpleFile(fp,"test.py");

i cant figure out what im doing wrong. here is the source. any help is
greatly appreciated!!

#include <boost/python.hpp>
#include <iostream>
#include <stdio.h>


using namespace std;
using namespace boost::python;


#ifdef _WIN32
#pragma comment(lib,"boost_python.lib");
#endif

int main()
{

   Py_Initialize();
   
   FILE *fp = NULL;
   fp = fopen("test.py", "r");
 
   if(fp == NULL)
	  return 1;

   PyRun_SimpleFile(fp,"test.py");

   Py_Finalize();
 
   system("PAUSE");

   return 0;
}

thanks for any help! also, i tried not opening the file myself, and
just sending PR_SF() a NULL FILE*... it didnt crash! instead, in the
console it said there was a syntax error and printed out some garbage
characters... i dont think theres a syntax error, "text.py" entire
file just says print "hello world"

thanks again!



From dave at boost-consulting.com  Thu Jul  1 15:48:03 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 01 Jul 2004 09:48:03 -0400
Subject: [C++-sig] Re: Calling a python function from C++ (from Jeff Holle)
References: <40E142ED.2030603@verizon.net> <cbutac$gs6$1@sea.gmane.org>
Message-ID: <uu0wrdejw.fsf@boost-consulting.com>

Jeffrey Holle <jeff.holle at verizon.net> writes:

> I've explored whats actually going on some with my debugger and now
> see what is being thrown.
> It is "error_already_set".  

Yes; did you miss my posting?
http://article.gmane.org/gmane.comp.python.c%2B%2B/6662

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com




From dave at boost-consulting.com  Thu Jul  1 15:49:59 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 01 Jul 2004 09:49:59 -0400
Subject: [C++-sig] Re: Calling a python function from C++ (from Jeff Holle)
References: <40E142ED.2030603@verizon.net> <cbutac$gs6$1@sea.gmane.org>
	<cbvbt6$k5r$1@sea.gmane.org>
	<2096514e0406302000530e12e0@mail.gmail.com>
Message-ID: <uoemzdego.fsf@boost-consulting.com>

Chad Austin <caustin at gmail.com> writes:

>     std::string getPythonErrorString();
>     void checkForPythonError();
>     void requirePythonError();
>
>     /**
>      * Allows us to check for Python errors at the end of a Python
>      * code block whether control left the end of the block or
>      * 'return' was used.
>      */
>     struct PythonCodeErrorSentry {
>         ~PythonCodeErrorSentry() {
>             if (!std::uncaught_exception()) {
>                 checkForPythonError();
>             }
>         }
>     };

Watch that you don't ever destroy one of these from within a catch
block (directly or indirectly), because std::uncaught_exception() will
be false at that point.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com




From dave at boost-consulting.com  Thu Jul  1 15:52:59 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 01 Jul 2004 09:52:59 -0400
Subject: [C++-sig] Re: please help with simple program crashing
References: <352b386804063022526df14a1e@mail.gmail.com>
Message-ID: <uisd7debo.fsf@boost-consulting.com>

Drew Ferraro <gfilla at gmail.com> writes:

> hi,
>
> ive recently trying to add a scripting system to a game i am making..
> anyway, ive started to learn python and am trying to figure out how to
> embed it in my game. i have gotten a C++ function to work from inside
> C++ but called from python via PyRun_SimpleString(),,, i can send
> commands directly to the intepreter with that function, but im having
> a problem
>  with PyRun_SimpleFile(). im trying to execute a python script with
> this function, but its crashing when it gets to this line:
>
>  PyRun_SimpleFile(fp,"test.py");
>
> i cant figure out what im doing wrong. here is the source. any help is
> greatly appreciated!!

One likely possibility is that your Python was built with a different
C/C++ standard library than your program, so they have different
ideas of what a FILE is supposed to be.  Also, Boost.Python is
incompatible with Py_Finalize... though it's not clear why you're
linking with Boost.Python anyway, since you're not using it.

> #include <boost/python.hpp>
> #include <iostream>
> #include <stdio.h>
>
>
> using namespace std;
> using namespace boost::python;
>
>
> #ifdef _WIN32
> #pragma comment(lib,"boost_python.lib");
> #endif
>
> int main()
> {
>
>    Py_Initialize();
>    
>    FILE *fp = NULL;
>    fp = fopen("test.py", "r");
>  
>    if(fp == NULL)
> 	  return 1;
>
>    PyRun_SimpleFile(fp,"test.py");
>
>    Py_Finalize();
>  
>    system("PAUSE");
>
>    return 0;
> }
>
> thanks for any help! also, i tried not opening the file myself, and
> just sending PR_SF() a NULL FILE*... it didnt crash! instead, in the
> console it said there was a syntax error and printed out some garbage
> characters... i dont think theres a syntax error, "text.py" entire
> file just says print "hello world"
>
> thanks again!

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com




From wirawan at camelot.physics.wm.edu  Thu Jul  1 17:59:56 2004
From: wirawan at camelot.physics.wm.edu (Wirawan Purwanto)
Date: Thu, 1 Jul 2004 11:59:56 -0400 (EDT)
Subject: [C++-sig] Problem: boost_python 1.31 (release) causes huge memory
	allocation
Message-ID: <Pine.LNX.4.60.0407011159000.3071@wirawan0.lan>

Hi,

Just a compliment, first: I am very new to boost::python library. I'm really 
impressed at the ease of use of that library. I have an existing code that I 
want to "manipulate" via python, and it only took me a few tests to get the 
simple interface up and running!

Now is the meat. :) To highlight where the questions are, I put "QUESTION:" at 
the beginning of the paragraph, below. Sorry if the detail is too long.

I am using Mandrake Linux 10 (kernel = 2.6.3-7mdk, gcc = 3.3.2-6mdk) and boost 
library version 1.31.0 (official release). I compiled the *whole* boost library 
using bjam, as directed in the website. The first attempt to "wrap" my code 
with boost::python went fine. Here's the wrapper initialization code:

BOOST_PYTHON_MODULE(HubbardGP)
{
     using namespace boost::python;

     TBH_PY_DEBUG(("Initializing HubbardGP module interface\n"));
     class_<HubbardGP>("HubbardGP")
         .def("OpenFiles", &HubbardGP::OpenFiles)
         .def("Solve", &HubbardGP::Solve)
         .def("ReportResults", &HubbardGP::ReportResults)
//        .add_property("ndim", &HubbardGP::ndim_pyget)
         ;
     TBH_PY_DEBUG(("Done initializing HubbardGP module interface\n"));
}

Please disregard "TBH_PY_DEBUG" there--it just calls C's printf function to 
print the string on the screen.

I built my shared object (HubbardGP.so) using make(1) for a stupid reason: I 
still don't understand completely bjam's quirks. I linked against the "release" 
version of libboost_python-gcc.so, in this way:

$ g++ -L/usr/local/lib -fPIC -Wall -ftemplate-depth-100 \
                -g -O0 -DDEBUG \
                -DBOOST_PYTHON_DYNAMIC_LIB \
                -DTBHQMC_MAKE_BOOST_PYTHON_MODULE \
                -DTBH_NDIM=1 -DTBH_USE_FFTW3 -D__section__=1 \
                -Isrc -Isrc/cp.inc \
                -I/usr/local/boost-1.31.0/include/boost-1_31 \
                -I/usr/include/python2.3 \
                -c src/test-lattice-params.cpp -o objs/HubbardGP.o

$ g++ -L/usr/local/lib -shared -Wall -static-libgcc \
                -llapack -lcblas -lf77blas -latlas -lfftw3 \
                -lg2c \
                -lboost_python-gcc \
                -L/usr/local/boost-1.31.0/lib \
                objs/HubbardGP.o -o HubbardGP.so

Do you see the difference? My code was compiled using DEBUG switch (and -O0), 
but then linked to the RELEASE variant of the boost::python lib.

QUESTION: is this an acceptable practice? I'm wondering if the DEBUG code must 
always be linked against the DEBUG boost::python lib and vice versa.

QUESTION: Without the .addproperty() stuff (that's commented in the snippet 
above), the code runs fine. But when I added the .addproperty() line, a 
calamity happens: when I was about to instantiate HubbardGP object, the 
computer froze. When I checked using top(1), the python program tries to 
allocate a huge chunk of memory, which did NOT happen before the .addproperty() 
is added in my wrapper. I re-ran strace(1), and found that the program (either 
python or the boost_python lib, or remotely possibly my own code?) attempted to 
allocate ~590MB of memory. Here's the strace(1) output, when I forcibly LIMIT 
the amount of vmem available to the program to 250 MB only:

[del]
   write(1, "Initializing HubbardGP module in"..., 40Initializing HubbardGP
   module interface) = 40
   write(1, "Done initializing HubbardGP modu"..., 45Done initializing
   HubbardGP module interface) = 45
   close(3)                                = 0
   futex(0x804a998, FUTEX_WAKE, 1)         = 0
   write(1, "Creating an instance of HubbardG"..., 34Creating an instance
   of HubbardGP) = 34
> mmap2(NULL, 595271680, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
> 0) = -1 ENOMEM (Cannot allocate memory)
   brk(0)                                  = 0x80d6000
   brk(0x2b888000)                         = 0x80d6000
> mmap2(NULL, 595406848, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
> 0) = -1 ENOMEM (Cannot allocate memory)
   mmap2(NULL, 2097152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE,
   -1, 0) = 0x87cb5000
   munmap(0x87cb5000, 307200)              = 0
   munmap(0x87e00000, 741376)              = 0
   mprotect(0x87d00000, 135168, PROT_READ|PROT_WRITE) = 0
> mmap2(NULL, 595271680, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
> 0) = -1 ENOMEM (Cannot allocate memory)
   futex(0x401edaf4, FUTEX_WAKE, 2147483647) = 0
   futex(0x402207d4, FUTEX_WAKE, 2147483647) = 0
   write(2, "Traceback (most recent call last"..., 35Traceback (most recent
   call last):) = 35
   open("test-lattice-params.py", O_RDONLY|O_LARGEFILE) = 3
   write(2, "  File \"test-lattice-params.py\","..., 46  File
   "test-lattice-params.py", line 4, in ?) = 46
   fstat64(3, {st_mode=S_IFREG|0644, st_size=267, ...}) = 0
   mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
   0) = 0xab5b2000
   read(3, "import HubbardGP\n\nprint \"Creatin"..., 4096) = 267
   write(2, "    ", 4    )                     = 4
   write(2, "H = HubbardGP.HubbardGP()\n", 26H = HubbardGP.HubbardGP()
   ) = 26
   close(3)                                = 0
   munmap(0xab5b2000, 4096)                = 0
   write(2, "MemoryError", 11MemoryError)             = 11
   write(2, "\n", 1
   )                       = 1
[del]

There are 3 points when it tries to allocate huge amount of memory.

Now, I'm too new to both python and boost::python. Could you help me with this? 
I don't believe that my code was the one doing the mess. I tend to think that 
somehow the compiled boost_python code was acting up here. But I can't debug 
the code easily, as it involves running python itself in the debugger. How do 
you debug such a problem? Using python debugger is also not possible, since I 
don't think it allows going down to the C++-level code.

As a workaround, I could only link my HubbardGP.so against the DEBUG variant 
(libboost_python-gcc-d.so). Then the code went fine, even with .add_property() 
there.

I tried once to regenerate the problem using a much smaller testcase, but the 
problem (huge mmap2) didn't show up.

As a reference, here's my python test code:

import HubbardGP
print "Creating an instance of HubbardGP"
H = HubbardGP.HubbardGP()
print "Done, now opening files"
x = H.OpenFiles("/tmp/file1.txt", "/tmp/file2.txt", "/tmp/file3.txt")
print "x is %d" % x
H.Solve()
print "NOW REPORTING RESULTS:"
H.ReportResults()

I would appreciate if someone helps me out in this respect.
The full source code of the wrapped C++ object is available if you need to look 
into it. But it's way too large to post here.

Thanks,
Wirawan





From graeme.lufkin at gmail.com  Thu Jul  1 18:05:32 2004
From: graeme.lufkin at gmail.com (Graeme Lufkin)
Date: Thu, 1 Jul 2004 09:05:32 -0700
Subject: [C++-sig] Re: compile errors with embedding example from tutorial
In-Reply-To: <slrnce722k.om1.faheem@Chrestomanci.home.earth>
References: <slrncdv7fb.om1.faheem@Chrestomanci.home.earth>
	<2096514e040627214639a53ca5@mail.gmail.com>
	<slrnce0mgb.om1.faheem@Chrestomanci.home.earth>
	<2096514e04062813561ceb1d79@mail.gmail.com>
	<slrnce17gj.om1.faheem@Chrestomanci.home.earth>
	<uhdsutl9n.fsf@boost-consulting.com>
	<slrnce722k.om1.faheem@Chrestomanci.home.earth>
Message-ID: <4d3b9ecb04070109051b127d80@mail.gmail.com>

    I've had similar problems, and have slogged my way to figuring
them out.  The tutorial is wrong, at least on gcc 3.2.3.
  Here's what you want:  After calling Py_Initialize(), you should get
the Python main namespace object by doing:

handle<> main_module(borrowed( PyImport_AddModule("__main__") ));
dict main_namespace = extract<dict>(PyModule_GetDict(main_module.get()));

The first line gets a pointer to the '__main__' module object and
stores it as a borrowed reference in a handle.  The second line gets
the dictionary of the '__main__' module and puts it in a dict C++
object.  You should now use this dictionary as the globals and locals
of PyRun_* functions that you call.  For example:
handle<> unused(PyRun_String("import yourModuleNameHere",
Py_file_input, main_namespace.ptr(), main_namespace.ptr()));
handle<> unused2(PyRun_String("f = file('test_output', 'w')",
Py_file_input, main_namespace.ptr(), main_namespace.ptr()));

You need to name the handle<> objects, even though you don't use them.
 If not, while you may think you're creating an anonymous temporary
that will immediately get destructed, the compiler thinks you're
declaring a function and gets very confused.

Hope this helps.  As usual, I invoke the great spirit of Dave Abrahams
to correct/clarify anything I've said that's not quite right or
misleading.  Good luck

-- 
    -- Graeme
    graeme.lufkin at gmail.com



From dave at boost-consulting.com  Thu Jul  1 18:56:59 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 01 Jul 2004 12:56:59 -0400
Subject: [C++-sig] Re: Problem: boost_python 1.31 (release) causes huge
 memory allocation
References: <Pine.LNX.4.60.0407011159000.3071@wirawan0.lan>
Message-ID: <un02ju0mc.fsf@boost-consulting.com>

Wirawan Purwanto <wirawan at camelot.physics.wm.edu> writes:

> Hi,
>
> Just a compliment, first: I am very new to boost::python library. I'm
> really impressed at the ease of use of that library. I have an
> existing code that I want to "manipulate" via python, and it only took
> me a few tests to get the simple interface up and running!

Thanks!

> I built my shared object (HubbardGP.so) using make(1) for a stupid
> reason: I still don't understand completely bjam's quirks. I linked
> against the "release" version of libboost_python-gcc.so, in this way:
>
> $ g++ -L/usr/local/lib -fPIC -Wall -ftemplate-depth-100 \
>                 -g -O0 -DDEBUG \
>                 -DBOOST_PYTHON_DYNAMIC_LIB \
>                 -DTBHQMC_MAKE_BOOST_PYTHON_MODULE \
>                 -DTBH_NDIM=1 -DTBH_USE_FFTW3 -D__section__=1 \
>                 -Isrc -Isrc/cp.inc \
>                 -I/usr/local/boost-1.31.0/include/boost-1_31 \
>                 -I/usr/include/python2.3 \
>                 -c src/test-lattice-params.cpp -o objs/HubbardGP.o
>
> $ g++ -L/usr/local/lib -shared -Wall -static-libgcc \
>                 -llapack -lcblas -lf77blas -latlas -lfftw3 \
>                 -lg2c \
>                 -lboost_python-gcc \
>                 -L/usr/local/boost-1.31.0/lib \
>                 objs/HubbardGP.o -o HubbardGP.so
>
> Do you see the difference? My code was compiled using DEBUG switch
> (and -O0), but then linked to the RELEASE variant of the boost::python
> lib.
>
> QUESTION: is this an acceptable practice? I'm wondering if the DEBUG
> code must always be linked against the DEBUG boost::python lib and
> vice versa.

The preprocessor symbol "DEBUG" means nothing to Boost.Python one way
or the other.

To get the right compilation/link command lines, build the example
projects using bjam -d+2 or just trial-run the build with bjam -n -a
and copy those down.  I can't vouch for your bulid being correct otherwise.

> QUESTION: Without the .addproperty() stuff (that's commented in the
> snippet above), the code runs fine. But when I added the
> .addproperty() line, a calamity happens: when I was about to
> instantiate HubbardGP object, the computer froze. 

<snip>

> Now, I'm too new to both python and boost::python. Could you help me
> with this? 

I have no clue.

> I don't believe that my code was the one doing the mess. I
> tend to think that somehow the compiled boost_python code was acting
> up here. 

Always blame the other guy ;-)

> But I can't debug the code easily, as it involves running
> python itself in the debugger. How do you debug such a problem? 

I run Python itself in the debugger.  What's so hard about that?

> Using python debugger is also not possible, since I don't think it
> allows going down to the C++-level code.
>
> As a workaround, I could only link my HubbardGP.so against the DEBUG
> variant (libboost_python-gcc-d.so). Then the code went fine, even with
> .add_property() there.

Sounds like you got your build commands wrong.  Never fails.  Use bjam
first, then once you get that right, you can do whatever you want.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com




From dave at boost-consulting.com  Thu Jul  1 18:50:45 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 01 Jul 2004 12:50:45 -0400
Subject: [C++-sig] Re: compile errors with embedding example from tutorial
References: <slrncdv7fb.om1.faheem@Chrestomanci.home.earth>
	<2096514e040627214639a53ca5@mail.gmail.com>
	<slrnce0mgb.om1.faheem@Chrestomanci.home.earth>
	<2096514e04062813561ceb1d79@mail.gmail.com>
	<slrnce17gj.om1.faheem@Chrestomanci.home.earth>
	<uhdsutl9n.fsf@boost-consulting.com>
	<slrnce722k.om1.faheem@Chrestomanci.home.earth>
	<4d3b9ecb04070109051b127d80@mail.gmail.com>
Message-ID: <usmcbu0wq.fsf@boost-consulting.com>

Graeme Lufkin <graeme.lufkin at gmail.com> writes:

>     I've had similar problems, and have slogged my way to figuring
> them out.  The tutorial is wrong, at least on gcc 3.2.3.

I think the tutorial is right in CVS.  Have you checked that?

http://www.boost-consulting.com/boost/libs/python/

>   Here's what you want:  After calling Py_Initialize(), you should get
> the Python main namespace object by doing:
>
> handle<> main_module(borrowed( PyImport_AddModule("__main__") ));
> dict main_namespace = extract<dict>(PyModule_GetDict(main_module.get()));

Seems harder than neccessary.

object main_module = object(handle<> (borrowed(
                        PyImport_AddModule("__main__") )));

object main_namespace = main_module.attr("__dict__");

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com




From gfilla at gmail.com  Thu Jul  1 19:17:54 2004
From: gfilla at gmail.com (Drew Ferraro)
Date: Thu, 1 Jul 2004 13:17:54 -0400
Subject: [C++-sig] Re: please help with simple program crashing
In-Reply-To: <uisd7debo.fsf@boost-consulting.com>
References: <352b386804063022526df14a1e@mail.gmail.com>
	<uisd7debo.fsf@boost-consulting.com>
Message-ID: <352b386804070110177d50d3a7@mail.gmail.com>

hi dave,

thanks for your reply! this might sound stupid, but could you tell me
what i should do then to have them both use the same standard library?
im using visual studio .net 2003 if that matters. also, what is the
alternative to Py_Finalize, and why is it incompatible but the other
Py_XXX function are not ? thanks for any help! ps, i have boost
included because i was just using it to do some other stuff (i was
actually able to call a C++ function through the Py_SimpleString()
function...)

On Thu, 01 Jul 2004 09:52:59 -0400, David Abrahams
<dave at boost-consulting.com> wrote:
> 
> Drew Ferraro <gfilla at gmail.com> writes:
> 
> > hi,
> >
> > ive recently trying to add a scripting system to a game i am making..
> > anyway, ive started to learn python and am trying to figure out how to
> > embed it in my game. i have gotten a C++ function to work from inside
> > C++ but called from python via PyRun_SimpleString(),,, i can send
> > commands directly to the intepreter with that function, but im having
> > a problem
> >  with PyRun_SimpleFile(). im trying to execute a python script with
> > this function, but its crashing when it gets to this line:
> >
> >  PyRun_SimpleFile(fp,"test.py");
> >
> > i cant figure out what im doing wrong. here is the source. any help is
> > greatly appreciated!!
> 
> One likely possibility is that your Python was built with a different
> C/C++ standard library than your program, so they have different
> ideas of what a FILE is supposed to be.  Also, Boost.Python is
> incompatible with Py_Finalize... though it's not clear why you're
> linking with Boost.Python anyway, since you're not using it.
> 
> > #include <boost/python.hpp>
> > #include <iostream>
> > #include <stdio.h>
> >
> >
> > using namespace std;
> > using namespace boost::python;
> >
> >
> > #ifdef _WIN32
> > #pragma comment(lib,"boost_python.lib");
> > #endif
> >
> > int main()
> > {
> >
> >    Py_Initialize();
> >
> >    FILE *fp = NULL;
> >    fp = fopen("test.py", "r");
> >
> >    if(fp == NULL)
> >         return 1;
> >
> >    PyRun_SimpleFile(fp,"test.py");
> >
> >    Py_Finalize();
> >
> >    system("PAUSE");
> >
> >    return 0;
> > }
> >
> > thanks for any help! also, i tried not opening the file myself, and
> > just sending PR_SF() a NULL FILE*... it didnt crash! instead, in the
> > console it said there was a syntax error and printed out some garbage
> > characters... i dont think theres a syntax error, "text.py" entire
> > file just says print "hello world"
> >
> > thanks again!
> 
> --
> Dave Abrahams
> Boost Consulting
> http://www.boost-consulting.com
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>



From jeff.holle at verizon.net  Thu Jul  1 05:36:21 2004
From: jeff.holle at verizon.net (Jeffrey Holle)
Date: Wed, 30 Jun 2004 23:36:21 -0400
Subject: [C++-sig] boost::python embedding error handling
Message-ID: <cc1lh7$2eo$1@sea.gmane.org>

The good news is that now I can get useful error messages from 
boost::python, I'm more than willing to use it.  Its a keeper!

I would like to provide some critism of the 
boost::python::error_already_set exceptions.

1.  It doesn't inherit from std::exception.

2.  It provides no information.

On the other hand, its concept of obtaining error information from the 
python interpreter is soundly a good idea.  Its just isn't finished.

I've written what I would consider a replacement for it and attached it.
Note that the code it its constuctor is pretty much what Chad Austin 
contributed to this news group.  Thanks.

To use it, I will need to place a try clause around all boost::python 
embedding code with the following catch clause:

  catch (error_already_set&) {
    throw python_error();
  }

I consider this acceptable, but it would be better to not need it.

In critism of python_error:

1.  It inherits from std::runtime_error.  It can be argued, I think, 
that it should be std::exception instead.  Becaue std::runtime_error 
doesn't provide protected access to its string attribute, I've had to 
provide one in python_error.  This means there is need for a "what" 
method implementation and that runtime_error's attribute is wasted bagage.

2.  It arguably does too much in its constructor.  This is a convenence 
issue for me.  Constructed at a lower level, it could easily be changed.

3.  Chad's code assumes that the python objects returned from 
PyErr_Fetch are strings.  I do not know if this assumption is safe. 
I've seen code on the web that does not make it.

4.  As Chad indicated, his code presently doesn't handle the traceback 
info.  I plan to add this to python_error as a seperate attribute and 
accessor, eventually ...


-------------- next part --------------
A non-text attachment was scrubbed...
Name: python_error.cpp
Type: text/x-c++
Size: 832 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20040630/f42c1c97/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: python_error.h
Type: text/x-c-header
Size: 428 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20040630/f42c1c97/attachment-0001.bin>

From faheem at email.unc.edu  Thu Jul  1 22:19:37 2004
From: faheem at email.unc.edu (Faheem Mitha)
Date: Thu, 1 Jul 2004 20:19:37 +0000 (UTC)
Subject: [C++-sig] Re: compile errors with embedding example from tutorial
References: <slrncdv7fb.om1.faheem@Chrestomanci.home.earth>
	<2096514e040627214639a53ca5@mail.gmail.com>
	<slrnce0mgb.om1.faheem@Chrestomanci.home.earth>
	<2096514e04062813561ceb1d79@mail.gmail.com>
	<slrnce17gj.om1.faheem@Chrestomanci.home.earth>
	<uhdsutl9n.fsf@boost-consulting.com>
	<slrnce722k.om1.faheem@Chrestomanci.home.earth>
	<4d3b9ecb04070109051b127d80@mail.gmail.com>
Message-ID: <slrnce8sep.eo3.faheem@Chrestomanci.home.earth>

On Thu, 1 Jul 2004 09:05:32 -0700, Graeme Lufkin
<graeme.lufkin at gmail.com> wrote:

>     I've had similar problems, and have slogged my way to figuring
> them out.  The tutorial is wrong, at least on gcc 3.2.3.
>   Here's what you want:  After calling Py_Initialize(), you should get
> the Python main namespace object by doing:
>
> handle<> main_module(borrowed( PyImport_AddModule("__main__") ));
> dict main_namespace = extract<dict>(PyModule_GetDict(main_module.get()));

I think this should be main_module.ptr() since main_module is an object.

> The first line gets a pointer to the '__main__' module object and
> stores it as a borrowed reference in a handle.  The second line gets
> the dictionary of the '__main__' module and puts it in a dict C++
> object.  You should now use this dictionary as the globals and locals
> of PyRun_* functions that you call.  For example:
> handle<> unused(PyRun_String("import yourModuleNameHere",
> Py_file_input, main_namespace.ptr(), main_namespace.ptr()));
> handle<> unused2(PyRun_String("f = file('test_output', 'w')",
> Py_file_input, main_namespace.ptr(), main_namespace.ptr()));
>
> You need to name the handle<> objects, even though you don't use them.
>  If not, while you may think you're creating an anonymous temporary
> that will immediately get destructed, the compiler thinks you're
> declaring a function and gets very confused.
>
> Hope this helps.  As usual, I invoke the great spirit of Dave Abrahams
> to correct/clarify anything I've said that's not quite right or
> misleading.  Good luck

I'm trying with

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

void foo()
{
  Py_Initialize();
  
  object main_module =
object(handle<>(borrowed(PyImport_AddModule("__main__"))));

  dict main_namespace = extract<dict>(PyModule_GetDict(main_module.ptr()));

  handle<> unused(PyRun_String("hello = file('hello.txt', 'w')\n"
			  "hello.write('Hello world!')\n"
			  "hello.close()", Py_file_input,
			  main_namespace.ptr(),main_namespace.ptr()));
    Py_Finalize();
}

BOOST_PYTHON_MODULE(embed)
{
  def("foo",foo);
}
*******************************************************************************

This compiles, but I get the same error as before, namely

NameError: name 'file' is not defined

Does this work correctly for you? I'm wondering if there is some issue
with my compiler flags. I'm trying to get Boost.Build to work but
there are some linking problems.

                                                           Faheem.




From faheem at email.unc.edu  Thu Jul  1 22:34:49 2004
From: faheem at email.unc.edu (Faheem Mitha)
Date: Thu, 1 Jul 2004 20:34:49 +0000 (UTC)
Subject: [C++-sig] Re: compile errors with embedding example from tutorial
References: <slrncdv7fb.om1.faheem@Chrestomanci.home.earth>
	<2096514e040627214639a53ca5@mail.gmail.com>
	<slrnce0mgb.om1.faheem@Chrestomanci.home.earth>
	<2096514e04062813561ceb1d79@mail.gmail.com>
	<slrnce17gj.om1.faheem@Chrestomanci.home.earth>
	<uhdsutl9n.fsf@boost-consulting.com>
	<slrnce722k.om1.faheem@Chrestomanci.home.earth>
	<4d3b9ecb04070109051b127d80@mail.gmail.com>
	<usmcbu0wq.fsf@boost-consulting.com>
Message-ID: <slrnce8tb8.eo3.faheem@Chrestomanci.home.earth>

On Thu, 01 Jul 2004 12:50:45 -0400, David Abrahams
<dave at boost-consulting.com> wrote:

> Graeme Lufkin <graeme.lufkin at gmail.com> writes:
>
>>     I've had similar problems, and have slogged my way to figuring
>> them out.  The tutorial is wrong, at least on gcc 3.2.3.
>
> I think the tutorial is right in CVS.  Have you checked that?
>
> http://www.boost-consulting.com/boost/libs/python/
>
>>   Here's what you want:  After calling Py_Initialize(), you should get
>> the Python main namespace object by doing:
>>
>> handle<> main_module(borrowed( PyImport_AddModule("__main__") ));
>> dict main_namespace = extract<dict>(PyModule_GetDict(main_module.get()));
>
> Seems harder than neccessary.
>
> object main_module = object(handle<> (borrowed(
>                         PyImport_AddModule("__main__") )));
>
> object main_namespace = main_module.attr("__dict__");

http://www.boost-consulting.com/boost/libs/python/doc/tutorial/doc
					/using_the_interpreter.html

uses

 object main_module(
        handle<>(borrowed(PyImport_AddModule("__main__"))));

instead, which does not compile with gcc 3.3, at least for me.

In any case, as I already said, even when this compiles correctly, it
still does not seem to execute the interpreter correctly, ie. I get
the error

NameError: name 'file' is not defined

Can you suggest what might be the problem here?

                                                        Faheem.




From graeme.lufkin at gmail.com  Thu Jul  1 22:52:17 2004
From: graeme.lufkin at gmail.com (Graeme Lufkin)
Date: Thu, 1 Jul 2004 13:52:17 -0700
Subject: [C++-sig] Re: compile errors with embedding example from tutorial
In-Reply-To: <slrnce8sep.eo3.faheem@Chrestomanci.home.earth>
References: <slrncdv7fb.om1.faheem@Chrestomanci.home.earth>
	<2096514e040627214639a53ca5@mail.gmail.com>
	<slrnce0mgb.om1.faheem@Chrestomanci.home.earth>
	<2096514e04062813561ceb1d79@mail.gmail.com>
	<slrnce17gj.om1.faheem@Chrestomanci.home.earth>
	<uhdsutl9n.fsf@boost-consulting.com>
	<slrnce722k.om1.faheem@Chrestomanci.home.earth>
	<4d3b9ecb04070109051b127d80@mail.gmail.com>
	<slrnce8sep.eo3.faheem@Chrestomanci.home.earth>
Message-ID: <4d3b9ecb0407011352f11f078@mail.gmail.com>

On Thu, 1 Jul 2004 20:19:37 +0000 (UTC), Faheem Mitha
<faheem at email.unc.edu> wrote:
>  
> >     I've had similar problems, and have slogged my way to figuring
> > them out.  The tutorial is wrong, at least on gcc 3.2.3.
> >   Here's what you want:  After calling Py_Initialize(), you should get
> > the Python main namespace object by doing:
> >
> > handle<> main_module(borrowed( PyImport_AddModule("__main__") ));
> > dict main_namespace = extract<dict>(PyModule_GetDict(main_module.get()));
> 
> I think this should be main_module.ptr() since main_module is an object.

   In my example it's a handle<>, so get() is correct.  In Dave's (and
your) examples, it's an object, so ptr() is correct.

> I'm trying with
> 
> ******************************************************************************
> #include <boost/python.hpp>
> using namespace boost::python;
> 
> void foo()
> {
>   Py_Initialize();
>   
>   object main_module =
> object(handle<>(borrowed(PyImport_AddModule("__main__"))));
> 
>   dict main_namespace = extract<dict>(PyModule_GetDict(main_module.ptr()));
> 
>   handle<> unused(PyRun_String("hello = file('hello.txt', 'w')\n"
>                           "hello.write('Hello world!')\n"
>                           "hello.close()", Py_file_input,
>                           main_namespace.ptr(),main_namespace.ptr()));
>     Py_Finalize();
> }
> 
> BOOST_PYTHON_MODULE(embed)
> {
>   def("foo",foo);
> }
> *******************************************************************************
> 
> This compiles, but I get the same error as before, namely
> 
> NameError: name 'file' is not defined
> 
> Does this work correctly for you? I'm wondering if there is some issue
> with my compiler flags. I'm trying to get Boost.Build to work but
> there are some linking problems.

  First, your extension module should never call Py_Initialize() or
Py_Finalize(), as Python will already be initialized by the time
you're running methods in it.  I think what you want is foo() to be
main(), with no extension module stuff needed.  Also, Boost.Python and
Py_Finalize() don't play nice, so never call it (check the list
archive for details, I don't really understand why myself).
  Second, yes this compiles and runs correctly for me, after removing
the Py_Initialize and Py_Finalize calls.
  Third, you definitely need to use Boost.Build for a few sample
programs before you think about switching back to Makefiles.  I share
your frustration at Boost.Build sometimes, but it does a particular
job admirably.  I submitted some patches to the docs and the Jamfile
rules a while ago that were aimed at making it easier to use
Boost.Build for extensions and embedded apps.  Dave hasn't gotten back
to me yet. (Hint hint)
-- 
    -- Graeme
    graeme.lufkin at gmail.com



From faheem at email.unc.edu  Fri Jul  2 00:48:24 2004
From: faheem at email.unc.edu (Faheem Mitha)
Date: Thu, 1 Jul 2004 22:48:24 +0000 (UTC)
Subject: [C++-sig] Re: compile errors with embedding example from tutorial
References: <slrncdv7fb.om1.faheem@Chrestomanci.home.earth>
	<2096514e040627214639a53ca5@mail.gmail.com>
	<slrnce0mgb.om1.faheem@Chrestomanci.home.earth>
	<2096514e04062813561ceb1d79@mail.gmail.com>
	<slrnce17gj.om1.faheem@Chrestomanci.home.earth>
	<uhdsutl9n.fsf@boost-consulting.com>
	<slrnce722k.om1.faheem@Chrestomanci.home.earth>
	<4d3b9ecb04070109051b127d80@mail.gmail.com>
	<slrnce8sep.eo3.faheem@Chrestomanci.home.earth>
	<4d3b9ecb0407011352f11f078@mail.gmail.com>
Message-ID: <slrnce955o.eo3.faheem@Chrestomanci.home.earth>

On Thu, 1 Jul 2004 13:52:17 -0700, Graeme Lufkin
<graeme.lufkin at gmail.com> wrote:

> On Thu, 1 Jul 2004 20:19:37 +0000 (UTC), Faheem Mitha
> <faheem at email.unc.edu> wrote:
>>  
>> >     I've had similar problems, and have slogged my way to figuring
>> > them out.  The tutorial is wrong, at least on gcc 3.2.3.
>> >   Here's what you want:  After calling Py_Initialize(), you should get
>> > the Python main namespace object by doing:
>> >
>> > handle<> main_module(borrowed( PyImport_AddModule("__main__") ));
>> > dict main_namespace = extract<dict>(PyModule_GetDict(main_module.get()));
>> 
>> I think this should be main_module.ptr() since main_module is an object.
>
>    In my example it's a handle<>, so get() is correct.  In Dave's (and
> your) examples, it's an object, so ptr() is correct.

Ok. Sorry. I stand corrected.

>> I'm trying with
>> 
>> ******************************************************************************
>> #include <boost/python.hpp>
>> using namespace boost::python;
>> 
>> void foo()
>> {
>>   Py_Initialize();
>>   
>>   object main_module =
>> object(handle<>(borrowed(PyImport_AddModule("__main__"))));
>> 
>>   dict main_namespace = extract<dict>(PyModule_GetDict(main_module.ptr()));
>> 
>>   handle<> unused(PyRun_String("hello = file('hello.txt', 'w')\n"
>>                           "hello.write('Hello world!')\n"
>>                           "hello.close()", Py_file_input,
>>                           main_namespace.ptr(),main_namespace.ptr()));
>>     Py_Finalize();
>> }
>> 
>> BOOST_PYTHON_MODULE(embed)
>> {
>>   def("foo",foo);
>> }
>> *******************************************************************************
>> 
>> This compiles, but I get the same error as before, namely
>> 
>> NameError: name 'file' is not defined
>> 
>> Does this work correctly for you? I'm wondering if there is some issue
>> with my compiler flags. I'm trying to get Boost.Build to work but
>> there are some linking problems.
>
>   First, your extension module should never call Py_Initialize() or
> Py_Finalize(), as Python will already be initialized by the time
> you're running methods in it.  I think what you want is foo() to be
> main(), with no extension module stuff needed.  Also, Boost.Python and
> Py_Finalize() don't play nice, so never call it (check the list
> archive for details, I don't really understand why myself).

>   Second, yes this compiles and runs correctly for me, after removing
> the Py_Initialize and Py_Finalize calls.

Just to make sure we are on the same page here. I want to run the
interpreter inside an extension module. In other words, I want an
extension module called embed.so, not an executable called embed.

>   Third, you definitely need to use Boost.Build for a few sample
> programs before you think about switching back to Makefiles.  I share
> your frustration at Boost.Build sometimes, but it does a particular
> job admirably.  I submitted some patches to the docs and the Jamfile
> rules a while ago that were aimed at making it easier to use
> Boost.Build for extensions and embedded apps.  Dave hasn't gotten back
> to me yet. (Hint hint)

Up to now I had been using distutils for extension modules, which has
worked fine for examples which don't embed the interpreter. It doesn't
seem to be working for this example, though.

I've been trying to use Boost.Build for this example. I added a
section to libs/python/example/Jamfile as follows. 

*******************************************************************
# ----- embed -------

# Declare a Python extension called embed
extension embed
:  # sources
        embed.cc

  # requirements and dependencies for Boost.Python extensions
  <template>@boost/libs/python/build/extension
  ;
*******************************************************************

This builds fine, but when I try to load it, I get

In [1]: import embed
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call
last)

/usr/local/src/libboost-python1.31.0/boost-1.31.0/libs/
python/example/bin/example/embed.so/gcc/debug/shared-linkable-true/<console>

ImportError: libboost_python.so.1.31.0: cannot open shared object
file: No such file or directory

Any idea how to fix this? Debian has /usr/lib/libboost_python.so and
libboost_python-gcc-mt-1_31.so, where the former is a symbolic link to
the latter.

There seems to be some gcc.mak files floating around, and it looks
like I could modify the shared libs line appropriately, but I am not
sure which file I need to modify.

In any case, could you tell me what the compile lines you are using
for the example above are? I could try it and see.

                                                              Faheem.




From graeme.lufkin at gmail.com  Fri Jul  2 01:12:13 2004
From: graeme.lufkin at gmail.com (Graeme Lufkin)
Date: Thu, 1 Jul 2004 16:12:13 -0700
Subject: [C++-sig] Re: compile errors with embedding example from tutorial
In-Reply-To: <slrnce955o.eo3.faheem@Chrestomanci.home.earth>
References: <slrncdv7fb.om1.faheem@Chrestomanci.home.earth>
	<2096514e040627214639a53ca5@mail.gmail.com>
	<slrnce0mgb.om1.faheem@Chrestomanci.home.earth>
	<2096514e04062813561ceb1d79@mail.gmail.com>
	<slrnce17gj.om1.faheem@Chrestomanci.home.earth>
	<uhdsutl9n.fsf@boost-consulting.com>
	<slrnce722k.om1.faheem@Chrestomanci.home.earth>
	<4d3b9ecb04070109051b127d80@mail.gmail.com>
	<slrnce8sep.eo3.faheem@Chrestomanci.home.earth>
	<4d3b9ecb0407011352f11f078@mail.gmail.com>
	<slrnce955o.eo3.faheem@Chrestomanci.home.earth>
Message-ID: <4d3b9ecb040701161250ac13eb@mail.gmail.com>

	Okay, so you're embedding in your extension.  I don't think you need
to call Py_Initialize(), as this should already have been done by the
python executable that you start to import your module.  I don't think
it's wrong to call it multiple times, but should be unnecessary.

On Thu, 1 Jul 2004 22:48:24 +0000 (UTC), Faheem Mitha
<faheem at email.unc.edu> wrote:
> In [1]: import embed
> ---------------------------------------------------------------------------
> ImportError                               Traceback (most recent call
> last)
> 
> /usr/local/src/libboost-python1.31.0/boost-1.31.0/libs/
> python/example/bin/example/embed.so/gcc/debug/shared-linkable-true/<console>
> 
> ImportError: libboost_python.so.1.31.0: cannot open shared object
> file: No such file or directory
> 
> Any idea how to fix this? Debian has /usr/lib/libboost_python.so and
> libboost_python-gcc-mt-1_31.so, where the former is a symbolic link to
> the latter.

   This looks like libbost isn't in your LD_LIBRARY_PATH.  When you
make a Python extension with the 'extension' target in Boost.Build, it
will build a copy of libboost and your extension (look in the bin
directory).  This one is the one that your extension gets linked
against, and so is the one it's looking for when you import the
module.  Since you've got Debian's version of the compiled Boost
libraries installed, it might be better to link against them.  You can
do that with a Jamfile entry similar to:

extension getting_started1-external
	: getting_started1.cpp
	<find-library>boost_python
	;

Since you're doing embedding in the extension, you probably also need
the embedding flags, so it would look like:

extension embed_in_extend_test
	: embed_in_extend.cpp
	<find-library>boost_python
	$(BOOST_PYTHON_V2_PROPERTIES)
	<find-library>$(PYTHON_EMBEDDED_LIBRARY)
	;

where $(BOOST_PYTHON_V2_PROPERTIES) and $(PYTHON_EMBEDDED_LIBRARY) are
variables that are defined by the Boost.Python library Jamfile.

The Jamfile entry for the test I ran (that compiled and ran fine) is:
exe simpletest
	:
	simpletest.cpp
	: $(BOOST_PYTHON_V2_PROPERTIES)
	<find-library>$(PYTHON_EMBEDDED_LIBRARY)
	<find-library>boost_python-gcc
	<library-path>$(HOME)/Projects/boost_install/lib
	;
Note the different name for the shared library to link against, that's
because I'm using the libraries built by running bjam in the root of
my Boost installation.  They got put in a different directory (which
is also in my LD_LIBRARY_PATH), so I add that to the list of linker
paths.
-- 
    -- Graeme
    graeme.lufkin at gmail.com



From wirawan0 at softhome.net  Fri Jul  2 01:20:11 2004
From: wirawan0 at softhome.net (Wirawan Purwanto)
Date: Thu, 1 Jul 2004 19:20:11 -0400 (EDT)
Subject: [C++-sig] Re: Problem: boost_python 1.31 (release) causes huge
	memory allocation
Message-ID: <Pine.LNX.4.60.0407011848440.10649@wirawan0.lan>


> To get the right compilation/link command lines, build the example
> projects using bjam -d+2 or just trial-run the build with bjam -n -a
> and copy those down.  I can't vouch for your bulid being correct otherwise.
>
>> QUESTION: Without the .addproperty() stuff (that's commented in the
>> snippet above), the code runs fine. But when I added the
>> .addproperty() line, a calamity happens: when I was about to
>> instantiate HubbardGP object, the computer froze.
>

<snip>

>
>> I don't believe that my code was the one doing the mess. I
>> tend to think that somehow the compiled boost_python code was acting
>> up here.
>
> Always blame the other guy ;-)

Well, sorry if this offended you. :) I didn't mean to belittle your 
program in any way. May be there's a bad interaction between
libboost_python.so and my code, probably?

>> But I can't debug the code easily, as it involves running
>> python itself in the debugger. How do you debug such a problem?
>
> I run Python itself in the debugger.  What's so hard about that?

Nothing, of course. ;) But remember that I use a precompiled python from 
Mandrake. There is no debug code available, IIRC. I couldn't do 
single-step within the python itself. But this is not an issue. What I 
wanted to do is to put some breakpoints in both my code and 
libboost_python.so. Now, how do I set the breakpoint on such dynamic 
libraries? The symbol may not have been loaded by that time, and I've 
never debugged in this way before.

>> Using python debugger is also not possible, since I don't think it
>> allows going down to the C++-level code.
>>
>> As a workaround, I could only link my HubbardGP.so against the DEBUG
>> variant (libboost_python-gcc-d.so). Then the code went fine, even with
>> .add_property() there.
>
> Sounds like you got your build commands wrong.  Never fails.  Use bjam
> first, then once you get that right, you can do whatever you want.

I'm not sure if the build is the one to blame. In fact, I did what you 
suggested (i.e. to run bjam by showing the actual command-line executed), 
and copied them to my makefile. I will try to get a Jamfile written for my 
code. Once done, I'll get back to you.

Thanks,
Wirawan



From greg.landrum at gmail.com  Fri Jul  2 02:31:42 2004
From: greg.landrum at gmail.com (Greg Landrum)
Date: Thu, 1 Jul 2004 17:31:42 -0700
Subject: [C++-sig] Re: Problem: boost_python 1.31 (release) causes huge
	memory allocation
In-Reply-To: <Pine.LNX.4.60.0407011848440.10649@wirawan0.lan>
References: <Pine.LNX.4.60.0407011848440.10649@wirawan0.lan>
Message-ID: <60825b0f040701173171b7dd1c@mail.gmail.com>

On Thu, 1 Jul 2004 19:20:11 -0400 (EDT), Wirawan Purwanto
<wirawan0 at softhome.net> wrote:
> 
> Nothing, of course. ;) But remember that I use a precompiled python from
> Mandrake. There is no debug code available, IIRC. I couldn't do
> single-step within the python itself. But this is not an issue. What I
> wanted to do is to put some breakpoints in both my code and
> libboost_python.so. Now, how do I set the breakpoint on such dynamic
> libraries? The symbol may not have been loaded by that time, and I've
> never debugged in this way before.

If you run gdb on python itself, you can try setting the breakpoint
right away, newer versions of gdb will give you a message like this:
Make breakpoint pending on future shared library load? (y or [n])
just reply 'y' and everything should work ok.

If you have an older version of gdb,  wait until after your .so has
been loaded (after you do an import) and then set the breakpoint.

It's not the nicest solution, but it works just fine (YMMV, of course).

-greg



From jeff.holle at verizon.net  Thu Jul  1 14:09:52 2004
From: jeff.holle at verizon.net (Jeffrey Holle)
Date: Thu, 01 Jul 2004 08:09:52 -0400
Subject: [C++-sig] Re: please help with simple program crashing
In-Reply-To: <352b386804070110177d50d3a7@mail.gmail.com>
References: <352b386804063022526df14a1e@mail.gmail.com>	<uisd7debo.fsf@boost-consulting.com>
	<352b386804070110177d50d3a7@mail.gmail.com>
Message-ID: <40E3FF10.6030301@verizon.net>

Calling Py_Finalize shuts done the python interpreter.
I suspect that is why you were told its not compatiable to boost.python, 
since it uses this resource.

Drew Ferraro wrote:
> hi dave,
> 
> thanks for your reply! this might sound stupid, but could you tell me
> what i should do then to have them both use the same standard library?
> im using visual studio .net 2003 if that matters. also, what is the
> alternative to Py_Finalize, and why is it incompatible but the other
> Py_XXX function are not ? thanks for any help! ps, i have boost
> included because i was just using it to do some other stuff (i was
> actually able to call a C++ function through the Py_SimpleString()
> function...)
> 
> On Thu, 01 Jul 2004 09:52:59 -0400, David Abrahams
> <dave at boost-consulting.com> wrote:
> 
>>Drew Ferraro <gfilla at gmail.com> writes:
>>
>>
>>>hi,
>>>
>>>ive recently trying to add a scripting system to a game i am making..
>>>anyway, ive started to learn python and am trying to figure out how to
>>>embed it in my game. i have gotten a C++ function to work from inside
>>>C++ but called from python via PyRun_SimpleString(),,, i can send
>>>commands directly to the intepreter with that function, but im having
>>>a problem
>>> with PyRun_SimpleFile(). im trying to execute a python script with
>>>this function, but its crashing when it gets to this line:
>>>
>>> PyRun_SimpleFile(fp,"test.py");
>>>
>>>i cant figure out what im doing wrong. here is the source. any help is
>>>greatly appreciated!!
>>
>>One likely possibility is that your Python was built with a different
>>C/C++ standard library than your program, so they have different
>>ideas of what a FILE is supposed to be.  Also, Boost.Python is
>>incompatible with Py_Finalize... though it's not clear why you're
>>linking with Boost.Python anyway, since you're not using it.
>>
>>
>>>#include <boost/python.hpp>
>>>#include <iostream>
>>>#include <stdio.h>
>>>
>>>
>>>using namespace std;
>>>using namespace boost::python;
>>>
>>>
>>>#ifdef _WIN32
>>>#pragma comment(lib,"boost_python.lib");
>>>#endif
>>>
>>>int main()
>>>{
>>>
>>>   Py_Initialize();
>>>
>>>   FILE *fp = NULL;
>>>   fp = fopen("test.py", "r");
>>>
>>>   if(fp == NULL)
>>>        return 1;
>>>
>>>   PyRun_SimpleFile(fp,"test.py");
>>>
>>>   Py_Finalize();
>>>
>>>   system("PAUSE");
>>>
>>>   return 0;
>>>}
>>>
>>>thanks for any help! also, i tried not opening the file myself, and
>>>just sending PR_SF() a NULL FILE*... it didnt crash! instead, in the
>>>console it said there was a syntax error and printed out some garbage
>>>characters... i dont think theres a syntax error, "text.py" entire
>>>file just says print "hello world"
>>>
>>>thanks again!
>>
>>--
>>Dave Abrahams
>>Boost Consulting
>>http://www.boost-consulting.com
>>
>>_______________________________________________
>>C++-sig mailing list
>>C++-sig at python.org
>>http://mail.python.org/mailman/listinfo/c++-sig
>>



From dave at boost-consulting.com  Fri Jul  2 05:32:09 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 01 Jul 2004 23:32:09 -0400
Subject: [C++-sig] Re: compile errors with embedding example from tutorial
References: <slrncdv7fb.om1.faheem@Chrestomanci.home.earth>
	<2096514e040627214639a53ca5@mail.gmail.com>
	<slrnce0mgb.om1.faheem@Chrestomanci.home.earth>
	<2096514e04062813561ceb1d79@mail.gmail.com>
	<slrnce17gj.om1.faheem@Chrestomanci.home.earth>
	<uhdsutl9n.fsf@boost-consulting.com>
	<slrnce722k.om1.faheem@Chrestomanci.home.earth>
	<4d3b9ecb04070109051b127d80@mail.gmail.com>
	<usmcbu0wq.fsf@boost-consulting.com>
	<slrnce8tb8.eo3.faheem@Chrestomanci.home.earth>
Message-ID: <uy8m3ozie.fsf@boost-consulting.com>

Faheem Mitha <faheem at email.unc.edu> writes:

>
> http://www.boost-consulting.com/boost/libs/python/doc/tutorial/doc
> 					/using_the_interpreter.html
>
> uses
>
>  object main_module(
>         handle<>(borrowed(PyImport_AddModule("__main__"))));
>
> instead, which does not compile with gcc 3.3, at least for me.

GCC bug, as I've already said.

> In any case, as I already said, even when this compiles correctly, it
> still does not seem to execute the interpreter correctly, ie. I get
> the error
>
> NameError: name 'file' is not defined
>
> Can you suggest what might be the problem here?

Nope, sorry.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com




From dave at boost-consulting.com  Fri Jul  2 05:34:06 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 01 Jul 2004 23:34:06 -0400
Subject: [C++-sig] Re: please help with simple program crashing
References: <352b386804063022526df14a1e@mail.gmail.com>
	<uisd7debo.fsf@boost-consulting.com>
	<352b386804070110177d50d3a7@mail.gmail.com>
Message-ID: <usmcbozf5.fsf@boost-consulting.com>

Drew Ferraro <gfilla at gmail.com> writes:

> hi dave,
>
> thanks for your reply! this might sound stupid, but could you tell me
> what i should do then to have them both use the same standard library?
> im using visual studio .net 2003 if that matters. 

Yes, it matters.  You need to rebuild your python with that compiler
or resign yourself to not passing FILE* between python and your
extension module.

> also, what is the
> alternative to Py_Finalize

Simply not calling it.


> , and why is it incompatible but the other Py_XXX function are not ?

see http://www.boost.org/libs/python/todo.html#pyfinalize-safety


-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com




From dave at boost-consulting.com  Fri Jul  2 05:40:04 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 01 Jul 2004 23:40:04 -0400
Subject: [C++-sig] Re: boost::python embedding error handling
References: <cc1lh7$2eo$1@sea.gmane.org>
Message-ID: <un02joz57.fsf@boost-consulting.com>

Jeffrey Holle <jeff.holle at verizon.net> writes:

> The good news is that now I can get useful error messages from
> boost::python, I'm more than willing to use it.  Its a keeper!
>
> I would like to provide some critism of the
> boost::python::error_already_set exceptions.
>
> 1.  It doesn't inherit from std::exception.

So what?

> 2.  It provides no information.

Incorrect.  Its type provides the information that Python has the rest
of the information.

> On the other hand, its concept of obtaining error information from
> the python interpreter is soundly a good idea.  Its just isn't
> finished.
>
> I've written what I would consider a replacement for it and attached
> it.  Note that the code it its constuctor is pretty much what Chad
> Austin contributed to this news group.  Thanks.

I don't consider replacing an exception whose constructor can't fail
with one whose constructor can fail to be an improvement.  Especially
not an exception whose copy-ctor can throw exceptions, which is just
plain evil because it might cause termination during stack
unwinding.  

You might want to read http://www.boost.org/more/error_handling.html I
realize I'm not taking my own advice to derive from std::exception.  

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com




From faheem at email.unc.edu  Fri Jul  2 06:22:07 2004
From: faheem at email.unc.edu (Faheem Mitha)
Date: Fri, 2 Jul 2004 04:22:07 +0000 (UTC)
Subject: [C++-sig] Re: compile errors with embedding example from tutorial
References: <slrncdv7fb.om1.faheem@Chrestomanci.home.earth>
	<2096514e040627214639a53ca5@mail.gmail.com>
	<slrnce0mgb.om1.faheem@Chrestomanci.home.earth>
	<2096514e04062813561ceb1d79@mail.gmail.com>
	<slrnce17gj.om1.faheem@Chrestomanci.home.earth>
	<uhdsutl9n.fsf@boost-consulting.com>
	<slrnce722k.om1.faheem@Chrestomanci.home.earth>
	<4d3b9ecb04070109051b127d80@mail.gmail.com>
	<slrnce8sep.eo3.faheem@Chrestomanci.home.earth>
	<4d3b9ecb0407011352f11f078@mail.gmail.com>
	<slrnce955o.eo3.faheem@Chrestomanci.home.earth>
	<4d3b9ecb040701161250ac13eb@mail.gmail.com>
Message-ID: <slrnce9one.om1.faheem@Chrestomanci.home.earth>

On Thu, 1 Jul 2004 16:12:13 -0700, Graeme Lufkin
<graeme.lufkin at gmail.com> wrote:

> 	Okay, so you're embedding in your extension.  I don't think you need
> to call Py_Initialize(), as this should already have been done by the
> python executable that you start to import your module.  I don't think
> it's wrong to call it multiple times, but should be unnecessary.
>
> On Thu, 1 Jul 2004 22:48:24 +0000 (UTC), Faheem Mitha
> <faheem at email.unc.edu> wrote:
>> In [1]: import embed
>> ---------------------------------------------------------------------------
>> ImportError                               Traceback (most recent call
>> last)
>> 
>> /usr/local/src/libboost-python1.31.0/boost-1.31.0/libs/
>> python/example/bin/example/embed.so/gcc/debug/shared-linkable-true/<console>
>> 
>> ImportError: libboost_python.so.1.31.0: cannot open shared object
>> file: No such file or directory
>> 
>> Any idea how to fix this? Debian has /usr/lib/libboost_python.so and
>> libboost_python-gcc-mt-1_31.so, where the former is a symbolic link to
>> the latter.
>
>    This looks like libbost isn't in your LD_LIBRARY_PATH.  When you
> make a Python extension with the 'extension' target in Boost.Build, it
> will build a copy of libboost and your extension (look in the bin
> directory).  This one is the one that your extension gets linked
> against, and so is the one it's looking for when you import the
> module.  Since you've got Debian's version of the compiled Boost
> libraries installed, it might be better to link against them.  

Yes, I just realised that this is what was going on.

> You can do that with a Jamfile entry similar to:

> extension getting_started1-external
> 	: getting_started1.cpp
> 	<find-library>boost_python
> 	;
>
> Since you're doing embedding in the extension, you probably also need
> the embedding flags, so it would look like:
>
> extension embed_in_extend_test
> 	: embed_in_extend.cpp
> 	<find-library>boost_python
> 	$(BOOST_PYTHON_V2_PROPERTIES)
> 	<find-library>$(PYTHON_EMBEDDED_LIBRARY)
> 	;
>
> where $(BOOST_PYTHON_V2_PROPERTIES) and $(PYTHON_EMBEDDED_LIBRARY) are
> variables that are defined by the Boost.Python library Jamfile.
>
> The Jamfile entry for the test I ran (that compiled and ran fine) is:
> exe simpletest
> 	:
> 	simpletest.cpp
> 	: $(BOOST_PYTHON_V2_PROPERTIES)
> 	<find-library>$(PYTHON_EMBEDDED_LIBRARY)
> 	<find-library>boost_python-gcc
> 	<library-path>$(HOME)/Projects/boost_install/lib
> 	;
> Note the different name for the shared library to link against, that's
> because I'm using the libraries built by running bjam in the root of
> my Boost installation.  They got put in a different directory (which
> is also in my LD_LIBRARY_PATH), so I add that to the list of linker
> paths.

This is very useful information. Thanks.

Ok. I am able to successfully build and run an executable, using a
recipe similar to the one you provided. It creates a file called
hello.txt in the directory.

However, I still cannot get a Python extension module with the
interpreter imbedded to work, however. I still get the same error as
before.

Details below. Again, I really appreciate your help.

The extension module file follows. When I try to load this I get

In [1]: import embed_ext

In [2]: embed_ext.foo()
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call
last)

/usr/local/src/boost/boost-1.31.0/libs/python/example/
bin/example/embed_ext.so/gcc/debug/shared-linkable-true/<console>

/usr/local/src/boost/boost-1.31.0/libs/python/example/
bin/example/embed_ext.so/gcc/debug/shared-linkable-true/<string>

NameError: name 'file' is not defined

So there is still some problem.  It is not clear from your message
whether you actually built and tried to run the extension module with
the embedded interpreter. If you have not, then I'd be much obliged if
you try out the following code, and see if you can reproduce this
problem.

Any idea what I am doing wrong at this point?

                                                 Thanks, Faheem.

The extension module file:
********************************************************************
embed_ext.cc
********************************************************************
#include <boost/python.hpp>
using namespace boost::python;

void foo()
{
  handle<> main_module(borrowed( PyImport_AddModule("__main__") ));
  dict main_namespace =
extract<dict>(PyModule_GetDict(main_module.get()));
  handle<> unused(PyRun_String("hello = file('hello. txt', 'w')\n"
                                 "hello.write('Hello world!')\n"
                               "hello.close()", Py_file_input,
                               main_namespace.ptr(),main_namespace.ptr()));
}

BOOST_PYTHON_MODULE(embed_ext)
{
  def("foo",foo);
}
******************************************************************

The executable file:
******************************************************************
embed.cc
******************************************************************
#include <boost/python.hpp>
using namespace boost::python;

int main()
{
  Py_Initialize();

  handle<> main_module(borrowed( PyImport_AddModule("__main__") ));
  dict main_namespace = extract<dict>(PyModule_GetDict(main_module.get()));
  handle<> unused(PyRun_String("hello = file('hello. txt', 'w')\n"
                                 "hello.write('Hello world!')\n"
                               "hello.close()", Py_file_input,
                               main_namespace.ptr(),main_namespace.ptr()));
  Py_Finalize();
}
********************************************************************

The Jamfile:
********************************************************************
Jamfile
********************************************************************

# This is the top of our own project tree
project-root ;

# Include definitions needed for Python modules
import python ;

# Declare an executable called embed
exe embed
        :
        embed.cc
        : $(BOOST_PYTHON_V2_PROPERTIES)
        <find-library>$(PYTHON_EMBEDDED_LIBRARY)
        <find-library>boost_python
        <find-library>python2.3
        ;

# Declare a Python extension called embed_ext
extension embed_ext
        :
        embed_ext.cc
        : $(BOOST_PYTHON_V2_PROPERTIES)
        <find-library>$(PYTHON_EMBEDDED_LIBRARY)
        <find-library>boost_python
        <find-library>python2.3	
        ;
***********************************************************************




From strawman at astraw.com  Fri Jul  2 08:00:45 2004
From: strawman at astraw.com (Andrew Straw)
Date: Thu, 01 Jul 2004 23:00:45 -0700
Subject: [C++-sig] newbie question: name mangling issue
Message-ID: <40E4FA0D.7090503@astraw.com>

Hi,

I'm a Boost(.Python) newbie and have long since forgotten most C++. 
However, trying to wrap a few bits of the opencv library, I'm getting a 
strange issue beyond my capabilities, and it seemingly involves name 
mangling.  Here's the error:

computer$ LD_LIBRARY_PATH="/usr/local/lib" python -c "import cvaux"
Traceback (most recent call last):
  File "<string>", line 1, in ?
ImportError: ./cvaux.so: undefined symbol: _ZTI13CvCalibFilter

"cvaux" is the name of the module I'm creating with Boost.Python. Here's 
the source, boost_cvaux.cpp:

#--------------------------------------------------
#include <cvaux.h>

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

class CvCalibFilterWrap : public CvCalibFilter
{
public:
  CvCalibFilterWrap(PyObject* self_)
    : self(self_) {}
private:
  PyObject* self;
};

BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS(CvCalibFilter_Stop_overloads, 
CvCalibFilter::Stop, 0, 1)

BOOST_PYTHON_MODULE(cvaux)
{
  class_<CvCalibFilter, CvCalibFilterWrap, 
boost::noncopyable>("CvCalibFilter",
                                   "This is CvCalibFilter's docstring")
    .def("SetCameraCount", &CvCalibFilter::SetCameraCount)
    .def("GetCameraCount", &CvCalibFilter::GetCameraCount)
    .def("SetFrames", &CvCalibFilter::SetFrames)
    .def("Stop", &CvCalibFilter::Stop,
     CvCalibFilter_Stop_overloads(args(false), "Stop's docstring")
     [return_internal_reference<>()])
    ;
}
#--------------------------------------------------

Here's the relevant bit from cvaux.h:


#--------------------------------------------------
class CVAUX_DLL_ENTRY CvCalibFilter
{
public:
    /* Constructor & destructor */
    CvCalibFilter();
    virtual ~CvCalibFilter();
    /* (snipped) */
}
#--------------------------------------------------

Here's a few lines from "strings /usr/local/lib/libcvaux.so | grep 
CvCalibFilter":
_ZTV13CvCalibFilter
_ZN13CvCalibFilterD1Ev
_ZN13CvCalibFilterD0Ev

So, it seems that an identifier very close to the unresolved 
"_ZTI13CvCalibFilter" is in the .so, but it is not quite exactly the same.

I've recently re-complied opencv from source just to be sure I'm using 
the same version of gcc/g++ (3.3.4 Debian), and I still get the same error.

Finally, here's my Jamfile:
#--------------------------------------------------
# This is the top of our own project tree
project-root ;

#   Include definitions needed for Python modules
import python ;

extension cvaux                     # Declare a Python extension
: # sources
    boost_cvaux.cpp
: # requirements
    <sysinclude>/usr/local/include/opencv
        <find-library>opencv
        <find-library>cvaux
        <find-library>boost_python
  ;
#--------------------------------------------------


I've tried to follow the examples.  Am I doing something wrong?  How can 
I fix this?

TIA+Cheers!
Andrew



From joel at boost-consulting.com  Fri Jul  2 08:57:27 2004
From: joel at boost-consulting.com (Joel de Guzman)
Date: Fri, 02 Jul 2004 14:57:27 +0800
Subject: [C++-sig] Re: compile errors with embedding example from tutorial
In-Reply-To: <slrnce9one.om1.faheem@Chrestomanci.home.earth>
References: <slrncdv7fb.om1.faheem@Chrestomanci.home.earth>	<2096514e040627214639a53ca5@mail.gmail.com>	<slrnce0mgb.om1.faheem@Chrestomanci.home.earth>	<2096514e04062813561ceb1d79@mail.gmail.com>	<slrnce17gj.om1.faheem@Chrestomanci.home.earth>	<uhdsutl9n.fsf@boost-consulting.com>	<slrnce722k.om1.faheem@Chrestomanci.home.earth>	<4d3b9ecb04070109051b127d80@mail.gmail.com>	<slrnce8sep.eo3.faheem@Chrestomanci.home.earth>	<4d3b9ecb0407011352f11f078@mail.gmail.com>	<slrnce955o.eo3.faheem@Chrestomanci.home.earth>	<4d3b9ecb040701161250ac13eb@mail.gmail.com>
	<slrnce9one.om1.faheem@Chrestomanci.home.earth>
Message-ID: <40E50757.4030708@boost-consulting.com>

Faheem Mitha wrote:

> However, I still cannot get a Python extension module with the
> interpreter imbedded to work, however. I still get the same error as
> before.

Hi Faheem,

The code in the tutorial can be found in the test/embedding.cpp/py
You can find a function called test_tutorial() there:

void
test_tutorial()
{
     using namespace boost::python;

     object main_module(
         handle<>(borrowed(PyImport_AddModule("__main__"))));

     object main_namespace = main_module.attr("__dict__");

     handle<>(PyRun_String(

         "hello = file('hello.txt', 'w')\n"
         "hello.write('Hello world!')\n"
         "hello.close()"

       , Py_file_input
       , main_namespace.ptr()
       , main_namespace.ptr())
     );
}

AFAIK, the code is passing the regression tests. Perhaps you can use
the test example as a staring point?

HTH,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net



From gfilla at gmail.com  Fri Jul  2 09:44:42 2004
From: gfilla at gmail.com (Drew Ferraro)
Date: Fri, 2 Jul 2004 03:44:42 -0400
Subject: [C++-sig] Re: please help with simple program crashing
In-Reply-To: <usmcbozf5.fsf@boost-consulting.com>
References: <352b386804063022526df14a1e@mail.gmail.com>
	<uisd7debo.fsf@boost-consulting.com>
	<352b386804070110177d50d3a7@mail.gmail.com>
	<usmcbozf5.fsf@boost-consulting.com>
Message-ID: <352b38680407020044c853b55@mail.gmail.com>

thanks for your reply. i actually did build python with this compile
though. i was reading the instructions, and it told me of a VC6
project which had everything set up so i could just open it and
compile it. well i opened it up, it converted to the 7.1 version.. i
was able to compile it in both debug and release mode.. then i put the
lib files in my vc/lib7 directory.. i was able to get other code to
work, but SimpleFile is making it crash like this. i just dont know
what the problem could be if i do have the right version... thanks for
anymore help!!

On Thu, 01 Jul 2004 23:34:06 -0400, David Abrahams
<dave at boost-consulting.com> wrote:
> 
> Drew Ferraro <gfilla at gmail.com> writes:
> 
> > hi dave,
> >
> > thanks for your reply! this might sound stupid, but could you tell me
> > what i should do then to have them both use the same standard library?
> > im using visual studio .net 2003 if that matters.
> 
> Yes, it matters.  You need to rebuild your python with that compiler
> or resign yourself to not passing FILE* between python and your
> extension module.
> 
> > also, what is the
> > alternative to Py_Finalize
> 
> Simply not calling it.
> 
> 
> > , and why is it incompatible but the other Py_XXX function are not ?
> 
> see http://www.boost.org/libs/python/todo.html#pyfinalize-safety
> 
> 
> 
> 
> --
> Dave Abrahams
> Boost Consulting
> http://www.boost-consulting.com
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>



From gfilla at gmail.com  Fri Jul  2 10:07:51 2004
From: gfilla at gmail.com (Drew Ferraro)
Date: Fri, 2 Jul 2004 04:07:51 -0400
Subject: [C++-sig] Re: please help with simple program crashing
In-Reply-To: <352b38680407020044c853b55@mail.gmail.com>
References: <352b386804063022526df14a1e@mail.gmail.com>
	<uisd7debo.fsf@boost-consulting.com>
	<352b386804070110177d50d3a7@mail.gmail.com>
	<usmcbozf5.fsf@boost-consulting.com>
	<352b38680407020044c853b55@mail.gmail.com>
Message-ID: <352b3868040702010712588e1d@mail.gmail.com>

now that i think about it... you were talking about the python library
when i was talking about the boost::python library. i just dont
understand though.. are you talking about the Python C++ libs? why
would they use a different FILE*, i mean, wouldnt there libs link to
my headers ? and how would i go about making them use the same version
anyway? i have Python 2.3 and visual studio 7.1... thanks for anymore
help!!!

On Fri, 2 Jul 2004 03:44:42 -0400, Drew Ferraro <gfilla at gmail.com> wrote:
> 
> thanks for your reply. i actually did build python with this compile
> though. i was reading the instructions, and it told me of a VC6
> project which had everything set up so i could just open it and
> compile it. well i opened it up, it converted to the 7.1 version.. i
> was able to compile it in both debug and release mode.. then i put the
> lib files in my vc/lib7 directory.. i was able to get other code to
> work, but SimpleFile is making it crash like this. i just dont know
> what the problem could be if i do have the right version... thanks for
> anymore help!!
> 
> 
> On Thu, 01 Jul 2004 23:34:06 -0400, David Abrahams
> <dave at boost-consulting.com> wrote:
> >
> > Drew Ferraro <gfilla at gmail.com> writes:
> >
> > > hi dave,
> > >
> > > thanks for your reply! this might sound stupid, but could you tell me
> > > what i should do then to have them both use the same standard library?
> > > im using visual studio .net 2003 if that matters.
> >
> > Yes, it matters.  You need to rebuild your python with that compiler
> > or resign yourself to not passing FILE* between python and your
> > extension module.
> >
> > > also, what is the
> > > alternative to Py_Finalize
> >
> > Simply not calling it.
> >
> >
> > > , and why is it incompatible but the other Py_XXX function are not ?
> >
> > see http://www.boost.org/libs/python/todo.html#pyfinalize-safety
> >
> >
> >
> >
> > --
> > Dave Abrahams
> > Boost Consulting
> > http://www.boost-consulting.com
> >
> > _______________________________________________
> > C++-sig mailing list
> > C++-sig at python.org
> > http://mail.python.org/mailman/listinfo/c++-sig
> >
>



From dave at boost-consulting.com  Fri Jul  2 14:50:44 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 02 Jul 2004 08:50:44 -0400
Subject: [C++-sig] Re: please help with simple program crashing
References: <352b386804063022526df14a1e@mail.gmail.com>
	<uisd7debo.fsf@boost-consulting.com>
	<352b386804070110177d50d3a7@mail.gmail.com>
	<usmcbozf5.fsf@boost-consulting.com>
	<352b38680407020044c853b55@mail.gmail.com>
	<352b3868040702010712588e1d@mail.gmail.com>
Message-ID: <upt7eo9nf.fsf@boost-consulting.com>

Drew Ferraro <gfilla at gmail.com> writes:

> now that i think about it... you were talking about the python
> library

Yes.

> when i was talking about the boost::python library. i just dont
> understand though.. are you talking about the Python C++ libs? why
> would they use a different FILE*, i mean, wouldnt there libs link to
> my headers ? 

?? Libraries don't link to headers.

> and how would i go about making them use the same version
> anyway? 

Rebuild Python from source with vc7.1.  I can't say it any more
clearly.


-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com




From dave at boost-consulting.com  Fri Jul  2 14:57:05 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 02 Jul 2004 08:57:05 -0400
Subject: [C++-sig] Re: newbie question: name mangling issue
References: <40E4FA0D.7090503@astraw.com>
Message-ID: <ueknuo9cu.fsf@boost-consulting.com>

Andrew Straw <strawman at astraw.com> writes:

> Here's a few lines from "strings /usr/local/lib/libcvaux.so | grep
> CvCalibFilter":
> _ZTV13CvCalibFilter
> _ZN13CvCalibFilterD1Ev
> _ZN13CvCalibFilterD0Ev
>
> So, it seems that an identifier very close to the unresolved
> "_ZTI13CvCalibFilter" is in the .so, but it is not quite exactly the
> same.

Running c++filt over your message descrambles those identifiers:

   vtable for CvCalibFilter
   CvCalibFilter::~CvCalibFilter()
   CvCalibFilter::~CvCalibFilter()

   So, it seems that an identifier very close to the unresolved
   "typeinfo for CvCalibFilter" is in the .so, but it is not quite
   exactly the same.

My guess is that either:

   1. You have turned off RTTI in your compiler options and need to
      turn it back on.

   2. You have left out the definition of one of CvCalibFilter's
      (probably virtual) member functions

Otherwise you almost certainly have found a compiler bug and there's
not much I can do to help you.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com




From dave at boost-consulting.com  Fri Jul  2 14:51:56 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 02 Jul 2004 08:51:56 -0400
Subject: [C++-sig] Re: compile errors with embedding example from tutorial
References: <slrncdv7fb.om1.faheem@Chrestomanci.home.earth>
	<2096514e040627214639a53ca5@mail.gmail.com>
	<slrnce0mgb.om1.faheem@Chrestomanci.home.earth>
	<2096514e04062813561ceb1d79@mail.gmail.com>
	<slrnce17gj.om1.faheem@Chrestomanci.home.earth>
	<uhdsutl9n.fsf@boost-consulting.com>
	<slrnce722k.om1.faheem@Chrestomanci.home.earth>
	<4d3b9ecb04070109051b127d80@mail.gmail.com>
	<slrnce8sep.eo3.faheem@Chrestomanci.home.earth>
	<4d3b9ecb0407011352f11f078@mail.gmail.com>
	<slrnce955o.eo3.faheem@Chrestomanci.home.earth>
	<4d3b9ecb040701161250ac13eb@mail.gmail.com>
	<slrnce9one.om1.faheem@Chrestomanci.home.earth>
Message-ID: <uk6xmo9lf.fsf@boost-consulting.com>

Faheem Mitha <faheem at email.unc.edu> writes:

> This is very useful information. Thanks.
>
> Ok. I am able to successfully build and run an executable, using a
> recipe similar to the one you provided. It creates a file called
> hello.txt in the directory.
>
> However, I still cannot get a Python extension module with the
> interpreter imbedded to work, however. I still get the same error as
> before.

Have you looked at libs/python/test/embedding.cpp in your Boost
distribution?

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com




From faheem at email.unc.edu  Fri Jul  2 17:27:08 2004
From: faheem at email.unc.edu (Faheem Mitha)
Date: Fri, 2 Jul 2004 15:27:08 +0000 (UTC)
Subject: [C++-sig] Re: compile errors with embedding example from tutorial
References: <slrncdv7fb.om1.faheem@Chrestomanci.home.earth>
	<2096514e040627214639a53ca5@mail.gmail.com>
	<slrnce0mgb.om1.faheem@Chrestomanci.home.earth>
	<2096514e04062813561ceb1d79@mail.gmail.com>
	<slrnce17gj.om1.faheem@Chrestomanci.home.earth>
	<uhdsutl9n.fsf@boost-consulting.com>
	<slrnce722k.om1.faheem@Chrestomanci.home.earth>
	<4d3b9ecb04070109051b127d80@mail.gmail.com>
	<slrnce8sep.eo3.faheem@Chrestomanci.home.earth>
	<4d3b9ecb0407011352f11f078@mail.gmail.com>
	<slrnce955o.eo3.faheem@Chrestomanci.home.earth>
	<4d3b9ecb040701161250ac13eb@mail.gmail.com>
	<slrnce9one.om1.faheem@Chrestomanci.home.earth>
	<40E50757.4030708@boost-consulting.com>
Message-ID: <slrnceavmc.om1.faheem@Chrestomanci.home.earth>

On Fri, 02 Jul 2004 14:57:27 +0800, Joel de Guzman
<joel at boost-consulting.com> wrote:

> Faheem Mitha wrote:
>
>> However, I still cannot get a Python extension module with the
>> interpreter imbedded to work, however. I still get the same error as
>> before.
>
> Hi Faheem,
>
> The code in the tutorial can be found in the test/embedding.cpp/py
> You can find a function called test_tutorial() there:
>
> void
> test_tutorial()
> {
>      using namespace boost::python;
>
>      object main_module(
>          handle<>(borrowed(PyImport_AddModule("__main__"))));
>
>      object main_namespace = main_module.attr("__dict__");
>
>      handle<>(PyRun_String(
>
>          "hello = file('hello.txt', 'w')\n"
>          "hello.write('Hello world!')\n"
>          "hello.close()"
>
>        , Py_file_input
>        , main_namespace.ptr()
>        , main_namespace.ptr())
>      );
>}
>
> AFAIK, the code is passing the regression tests. Perhaps you can use
> the test example as a staring point?

Thanks. However, I am not sure which version of the test/embedding.cpp
you are referring to. The version at
http://www.boost.org/libs/python/test/embedding.cpp which I assume is
the current CVS, is the same as the version in 1.31, and neither of
them have the code you refer to.

In any case, does the code you refer to define an extension module
which embeds the interpreter and can be called from Python? Because
that is the case I am interested in. I have been unable to find any
examples out there along these lines, despite some effort.

The current version of test/embedding.cpp that I have seen is a C++
executable, and the extension module defined there is called within
the interpreter that is embedded in this executable. This is not the
same as what I am trying to do.

                                                          Faheem.




From faheem at email.unc.edu  Fri Jul  2 17:38:31 2004
From: faheem at email.unc.edu (Faheem Mitha)
Date: Fri, 2 Jul 2004 15:38:31 +0000 (UTC)
Subject: [C++-sig] Re: compile errors with embedding example from tutorial
References: <slrncdv7fb.om1.faheem@Chrestomanci.home.earth>
	<2096514e040627214639a53ca5@mail.gmail.com>
	<slrnce0mgb.om1.faheem@Chrestomanci.home.earth>
	<2096514e04062813561ceb1d79@mail.gmail.com>
	<slrnce17gj.om1.faheem@Chrestomanci.home.earth>
	<uhdsutl9n.fsf@boost-consulting.com>
	<slrnce722k.om1.faheem@Chrestomanci.home.earth>
	<4d3b9ecb04070109051b127d80@mail.gmail.com>
	<slrnce8sep.eo3.faheem@Chrestomanci.home.earth>
	<4d3b9ecb0407011352f11f078@mail.gmail.com>
	<slrnce955o.eo3.faheem@Chrestomanci.home.earth>
	<4d3b9ecb040701161250ac13eb@mail.gmail.com>
	<slrnce9one.om1.faheem@Chrestomanci.home.earth>
	<40E50757.4030708@boost-consulting.com>
	<slrnceavmc.om1.faheem@Chrestomanci.home.earth>
Message-ID: <slrnceb0bm.jco.faheem@Chrestomanci.home.earth>

On Fri, 2 Jul 2004 15:27:08 +0000 (UTC), Faheem Mitha
<faheem at email.unc.edu> wrote:

>
> Thanks. However, I am not sure which version of the test/embedding.cpp
> you are referring to. The version at
> http://www.boost.org/libs/python/test/embedding.cpp which I assume is
> the current CVS, is the same as the version in 1.31, and neither of
> them have the code you refer to.
>
> In any case, does the code you refer to define an extension module
> which embeds the interpreter and can be called from Python? Because
> that is the case I am interested in. I have been unable to find any
> examples out there along these lines, despite some effort.
>
> The current version of test/embedding.cpp that I have seen is a C++
> executable, and the extension module defined there is called within
> the interpreter that is embedded in this executable. This is not the
> same as what I am trying to do.

Having found this code on the net (by doing a Google search) I see
that it indeed does not satisfy the criteria I described. There is no
extension module here. It defines some functions which imbed the
interpreter and then executes them in main. 

Does the case I described even work? I am not interested in an
executable. Like I said, I have yet to see any examples out there.

Maybe I'm missing something. I don't see what, though.

                                                          Faheem. 




From caustin at gmail.com  Fri Jul  2 17:43:29 2004
From: caustin at gmail.com (Chad Austin)
Date: Fri, 2 Jul 2004 10:43:29 -0500
Subject: [C++-sig] Re: compile errors with embedding example from tutorial
In-Reply-To: <slrnceavmc.om1.faheem@Chrestomanci.home.earth>
References: <slrncdv7fb.om1.faheem@Chrestomanci.home.earth>
	<2096514e040627214639a53ca5@mail.gmail.com>
	<slrnce0mgb.om1.faheem@Chrestomanci.home.earth>
	<2096514e04062813561ceb1d79@mail.gmail.com>
	<slrnce17gj.om1.faheem@Chrestomanci.home.earth>
	<uhdsutl9n.fsf@boost-consulting.com>
	<slrnce722k.om1.faheem@Chrestomanci.home.earth>
	<4d3b9ecb04070109051b127d80@mail.gmail.com>
	<slrnce8sep.eo3.faheem@Chrestomanci.home.earth>
	<4d3b9ecb0407011352f11f078@mail.gmail.com>
	<slrnce955o.eo3.faheem@Chrestomanci.home.earth>
	<4d3b9ecb040701161250ac13eb@mail.gmail.com>
	<slrnce9one.om1.faheem@Chrestomanci.home.earth>
	<40E50757.4030708@boost-consulting.com>
	<slrnceavmc.om1.faheem@Chrestomanci.home.earth>
Message-ID: <2096514e040702084310df702c@mail.gmail.com>

Faheem:  I think you're confused about one point.  All extension
modules "embed the interpreter".  Since Python has loaded them, they
all have access to the Python/C API and can do what they wish with it.
 Your real problem is that you don't seem to have the 'file' builtin. 
You should put more work into trying to decompose and solve that
problem.

Now that I think about it, perhaps your extension module doesn't have
direct access to the builtins, while __main__ does.  Try changing your
hard-coded script to:

          "from __builtin__ import *\n"
          "hello = file('hello.txt', 'w')\n"
          "hello.write('Hello world!')\n"
          "hello.close()"

Chad

On Fri, 2 Jul 2004 15:27:08 +0000 (UTC), Faheem Mitha
<faheem at email.unc.edu> wrote:
> 
> On Fri, 02 Jul 2004 14:57:27 +0800, Joel de Guzman
> <joel at boost-consulting.com> wrote:
> 
> > Faheem Mitha wrote:
> >
> >> However, I still cannot get a Python extension module with the
> >> interpreter imbedded to work, however. I still get the same error as
> >> before.
> >
> > Hi Faheem,
> >
> > The code in the tutorial can be found in the test/embedding.cpp/py
> > You can find a function called test_tutorial() there:
> >
> > void
> > test_tutorial()
> > {
> >      using namespace boost::python;
> >
> >      object main_module(
> >          handle<>(borrowed(PyImport_AddModule("__main__"))));
> >
> >      object main_namespace = main_module.attr("__dict__");
> >
> >      handle<>(PyRun_String(
> >
> >          "hello = file('hello.txt', 'w')\n"
> >          "hello.write('Hello world!')\n"
> >          "hello.close()"
> >
> >        , Py_file_input
> >        , main_namespace.ptr()
> >        , main_namespace.ptr())
> >      );
> >}
> >
> > AFAIK, the code is passing the regression tests. Perhaps you can use
> > the test example as a staring point?
> 
> Thanks. However, I am not sure which version of the test/embedding.cpp
> you are referring to. The version at
> http://www.boost.org/libs/python/test/embedding.cpp which I assume is
> the current CVS, is the same as the version in 1.31, and neither of
> them have the code you refer to.
> 
> In any case, does the code you refer to define an extension module
> which embeds the interpreter and can be called from Python? Because
> that is the case I am interested in. I have been unable to find any
> examples out there along these lines, despite some effort.
> 
> The current version of test/embedding.cpp that I have seen is a C++
> executable, and the extension module defined there is called within
> the interpreter that is embedded in this executable. This is not the
> same as what I am trying to do.
> 
>                                                           Faheem.
> 
> 
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 


-- 
Chad Austin
http://aegisknight.org/



From faheem at email.unc.edu  Fri Jul  2 18:18:59 2004
From: faheem at email.unc.edu (Faheem Mitha)
Date: Fri, 2 Jul 2004 16:18:59 +0000 (UTC)
Subject: [C++-sig] Re: compile errors with embedding example from tutorial
References: <slrncdv7fb.om1.faheem@Chrestomanci.home.earth>
	<2096514e040627214639a53ca5@mail.gmail.com>
	<slrnce0mgb.om1.faheem@Chrestomanci.home.earth>
	<2096514e04062813561ceb1d79@mail.gmail.com>
	<slrnce17gj.om1.faheem@Chrestomanci.home.earth>
	<uhdsutl9n.fsf@boost-consulting.com>
	<slrnce722k.om1.faheem@Chrestomanci.home.earth>
	<4d3b9ecb04070109051b127d80@mail.gmail.com>
	<slrnce8sep.eo3.faheem@Chrestomanci.home.earth>
	<4d3b9ecb0407011352f11f078@mail.gmail.com>
	<slrnce955o.eo3.faheem@Chrestomanci.home.earth>
	<4d3b9ecb040701161250ac13eb@mail.gmail.com>
	<slrnce9one.om1.faheem@Chrestomanci.home.earth>
	<40E50757.4030708@boost-consulting.com>
	<slrnceavmc.om1.faheem@Chrestomanci.home.earth>
	<2096514e040702084310df702c@mail.gmail.com>
Message-ID: <slrnceb2nj.jco.faheem@Chrestomanci.home.earth>

On Fri, 2 Jul 2004 10:43:29 -0500, Chad Austin <caustin at gmail.com> wrote:
> Faheem:  I think you're confused about one point.  All extension
> modules "embed the interpreter".  Since Python has loaded them, they
> all have access to the Python/C API and can do what they wish with it.

If you say so. I'm too ignorant about how these things work to have an
opinion.

>  Your real problem is that you don't seem to have the 'file' builtin. 
> You should put more work into trying to decompose and solve that
> problem.

I've been trying...  Actually, I don't think I have ever put so much
effort before into getting a library working.

> Now that I think about it, perhaps your extension module doesn't have
> direct access to the builtins, while __main__ does.  Try changing your
> hard-coded script to:
>
>           "from __builtin__ import *\n"
>           "hello = file('hello.txt', 'w')\n"
>           "hello.write('Hello world!')\n"
>           "hello.close()"

I've tried this already.  I think someone else suggested this. I get
(after building with bjam):

**************************************************************************
In [1]: import embed_ext

In [2]: embed_ext.foo()
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)

/usr/local/src/boost/boost-1.31.0/libs/python/example/
bin/example/embed_ext.so/gcc/debug/shared-linkable-true/<console>

/usr/local/src/boost/boost-1.31.0/libs/python/example/
bin/example/embed_ext.so/gcc/debug/shared-linkable-true/<string>

ImportError: __import__ not found

**************************************************************************

I don't know what this means. :-( . Perhaps simply that it does not
have the `import' builtin available to import `__builtin__'. :-) Have
you been able to reproduce any of these results? Thanks.

                                                                       Faheem.




From jbrandmeyer at earthlink.net  Fri Jul  2 18:28:34 2004
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Fri, 02 Jul 2004 12:28:34 -0400
Subject: [C++-sig] Default Numeric module
Message-ID: <1088785714.10104.5.camel@illuvatar>

It seems that the documentation and actual behavior or the
numeric::array class do not agree with each other.  The documentation
states that Numeric.ArrayType will be used in preference to
numarray.NDArray when both are available, however the opposite is true.

I can commit a trivial patch to correct the implementation, unless it is
the documentation that is in error.

Thanks,
Jonathan Brandmeyer




From caustin at gmail.com  Fri Jul  2 18:48:43 2004
From: caustin at gmail.com (Chad Austin)
Date: Fri, 2 Jul 2004 11:48:43 -0500
Subject: [C++-sig] Re: compile errors with embedding example from tutorial
In-Reply-To: <slrnceb2nj.jco.faheem@Chrestomanci.home.earth>
References: <slrncdv7fb.om1.faheem@Chrestomanci.home.earth>
	<2096514e040627214639a53ca5@mail.gmail.com>
	<slrnce0mgb.om1.faheem@Chrestomanci.home.earth>
	<2096514e04062813561ceb1d79@mail.gmail.com>
	<slrnce17gj.om1.faheem@Chrestomanci.home.earth>
	<uhdsutl9n.fsf@boost-consulting.com>
	<slrnce722k.om1.faheem@Chrestomanci.home.earth>
	<4d3b9ecb04070109051b127d80@mail.gmail.com>
	<slrnce8sep.eo3.faheem@Chrestomanci.home.earth>
	<4d3b9ecb0407011352f11f078@mail.gmail.com>
	<slrnce955o.eo3.faheem@Chrestomanci.home.earth>
	<4d3b9ecb040701161250ac13eb@mail.gmail.com>
	<slrnce9one.om1.faheem@Chrestomanci.home.earth>
	<40E50757.4030708@boost-consulting.com>
	<slrnceavmc.om1.faheem@Chrestomanci.home.earth>
	<2096514e040702084310df702c@mail.gmail.com>
	<slrnceb2nj.jco.faheem@Chrestomanci.home.earth>
Message-ID: <2096514e0407020948342cf622@mail.gmail.com>

Heh, I've run into that problem before too.  You may have to do the
import with PyImport_Import or whatever it is.  (The C equivalent of
__import__)

Oddly enough, I'm not seeing any of the problems you are.  See the
attached files.  Works fine for me.

Chad at basilisk ~/tmp/bp
$ scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
g++ -DBOOST_PYTHON_STATIC_LIB -DBOOST_PYTHON_NO_TEMPLATE_EXPORT -I/usr/local/inc
lude/boost-1_31 -I/usr/include/python2.3 -c -o hello.os hello.cpp
g++ -shared -o hello.dll hello.os -L/usr/lib/python2.3/config -L/usr/local/lib -
lboost_python-gcc -lpython2.3
scons: done building targets.

Chad at basilisk ~/tmp/bp
$ python
Python 2.3.4 (#1, Jun 13 2004, 11:21:03)
[GCC 3.3.1 (cygming special)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import hello
>>> w = hello.World()
>>> w.run()
>>> import os
>>> os.system('cat hello.txt')
Hello world!0
>>>


On Fri, 2 Jul 2004 16:18:59 +0000 (UTC), Faheem Mitha
<faheem at email.unc.edu> wrote:
> 
> On Fri, 2 Jul 2004 10:43:29 -0500, Chad Austin <caustin at gmail.com> wrote:
> > Now that I think about it, perhaps your extension module doesn't have
> > direct access to the builtins, while __main__ does.  Try changing your
> > hard-coded script to:
> >
> >           "from __builtin__ import *\n"
> >           "hello = file('hello.txt', 'w')\n"
> >           "hello.write('Hello world!')\n"
> >           "hello.close()"
> 
> I've tried this already.  I think someone else suggested this. I get
> (after building with bjam):
> 
> **************************************************************************
> In [1]: import embed_ext
> 
> In [2]: embed_ext.foo()
> ---------------------------------------------------------------------------
> ImportError                               Traceback (most recent call last)
> 
> /usr/local/src/boost/boost-1.31.0/libs/python/example/
> bin/example/embed_ext.so/gcc/debug/shared-linkable-true/<console>
> 
> /usr/local/src/boost/boost-1.31.0/libs/python/example/
> bin/example/embed_ext.so/gcc/debug/shared-linkable-true/<string>
> 
> ImportError: __import__ not found
> 
> **************************************************************************
> 
> I don't know what this means. :-( . Perhaps simply that it does not
> have the `import' builtin available to import `__builtin__'. :-) Have
> you been able to reproduce any of these results? Thanks.
> 
> 
> 
>                                                                        Faheem.
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 


-- 
Chad Austin
http://aegisknight.org/
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: hello.cpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20040702/a8383820/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SConstruct
Type: application/octet-stream
Size: 419 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20040702/a8383820/attachment.obj>

From strawman at astraw.com  Fri Jul  2 19:44:03 2004
From: strawman at astraw.com (Andrew Straw)
Date: Fri, 02 Jul 2004 10:44:03 -0700
Subject: [C++-sig] Re: newbie question: name mangling issue
In-Reply-To: <ueknuo9cu.fsf@boost-consulting.com>
References: <40E4FA0D.7090503@astraw.com> <ueknuo9cu.fsf@boost-consulting.com>
Message-ID: <40E59EE3.5030201@astraw.com>


>My guess is that either:
>
>   1. You have turned off RTTI in your compiler options and need to
>      turn it back on.
>
>   2. You have left out the definition of one of CvCalibFilter's
>      (probably virtual) member functions
>  
>
#1 it was.  Thanks for your quick response.  It saved me days of pain, 
I'm sure.

Remembering why I like Python:
Andrew



From graeme.lufkin at gmail.com  Fri Jul  2 21:21:07 2004
From: graeme.lufkin at gmail.com (Graeme Lufkin)
Date: Fri, 2 Jul 2004 12:21:07 -0700
Subject: [C++-sig] Re: compile errors with embedding example from tutorial
In-Reply-To: <2096514e0407020948342cf622@mail.gmail.com>
References: <slrncdv7fb.om1.faheem@Chrestomanci.home.earth>
	<2096514e040627214639a53ca5@mail.gmail.com>
	<slrnce0mgb.om1.faheem@Chrestomanci.home.earth>
	<2096514e04062813561ceb1d79@mail.gmail.com>
	<slrnce17gj.om1.faheem@Chrestomanci.home.earth>
	<uhdsutl9n.fsf@boost-consulting.com>
	<slrnce722k.om1.faheem@Chrestomanci.home.earth>
	<4d3b9ecb04070109051b127d80@mail.gmail.com>
	<slrnce8sep.eo3.faheem@Chrestomanci.home.earth>
	<4d3b9ecb0407011352f11f078@mail.gmail.com>
	<slrnce955o.eo3.faheem@Chrestomanci.home.earth>
	<4d3b9ecb040701161250ac13eb@mail.gmail.com>
	<slrnce9one.om1.faheem@Chrestomanci.home.earth>
	<40E50757.4030708@boost-consulting.com>
	<slrnceavmc.om1.faheem@Chrestomanci.home.earth>
	<2096514e040702084310df702c@mail.gmail.com>
	<slrnceb2nj.jco.faheem@Chrestomanci.home.earth>
	<2096514e0407020948342cf622@mail.gmail.com>
Message-ID: <4d3b9ecb040702122186cdd1b@mail.gmail.com>

    I'm interested to see you're using SCons to build your modules. 
Would you mind posting a short account of your experience using SCons,
both in general and with Boost.Python?  I still wrestle with Makefile
vs Boost.Build vs tearing-my-hair-out every once in while.  A more
complicate SConstruct file would be great to look at too.  Thanks

On Fri, 2 Jul 2004 11:48:43 -0500, Chad Austin <caustin at gmail.com> wrote:
> Chad at basilisk ~/tmp/bp
> $ scons
> scons: Reading SConscript files ...
> scons: done reading SConscript files.
> scons: Building targets ...
> g++ -DBOOST_PYTHON_STATIC_LIB -DBOOST_PYTHON_NO_TEMPLATE_EXPORT -I/usr/local/inc
> lude/boost-1_31 -I/usr/include/python2.3 -c -o hello.os hello.cpp
> g++ -shared -o hello.dll hello.os -L/usr/lib/python2.3/config -L/usr/local/lib -
> lboost_python-gcc -lpython2.3
> scons: done building targets.
> 

-- 
    -- Graeme
    graeme.lufkin at gmail.com



From caustin at gmail.com  Fri Jul  2 22:02:49 2004
From: caustin at gmail.com (Chad Austin)
Date: Fri, 2 Jul 2004 15:02:49 -0500
Subject: [C++-sig] Python, Boost.Python, and SCons
In-Reply-To: <4d3b9ecb040702122186cdd1b@mail.gmail.com>
References: <slrncdv7fb.om1.faheem@Chrestomanci.home.earth>
	<2096514e040627214639a53ca5@mail.gmail.com>
	<slrnce0mgb.om1.faheem@Chrestomanci.home.earth>
	<2096514e04062813561ceb1d79@mail.gmail.com>
	<slrnce17gj.om1.faheem@Chrestomanci.home.earth>
	<uhdsutl9n.fsf@boost-consulting.com>
	<slrnce722k.om1.faheem@Chrestomanci.home.earth>
	<4d3b9ecb04070109051b127d80@mail.gmail.com>
	<slrnce8sep.eo3.faheem@Chrestomanci.home.earth>
	<4d3b9ecb0407011352f11f078@mail.gmail.com>
	<slrnce955o.eo3.faheem@Chrestomanci.home.earth>
	<4d3b9ecb040701161250ac13eb@mail.gmail.com>
	<slrnce9one.om1.faheem@Chrestomanci.home.earth>
	<40E50757.4030708@boost-consulting.com>
	<slrnceavmc.om1.faheem@Chrestomanci.home.earth>
	<2096514e040702084310df702c@mail.gmail.com>
	<slrnceb2nj.jco.faheem@Chrestomanci.home.earth>
	<2096514e0407020948342cf622@mail.gmail.com>
	<4d3b9ecb040702122186cdd1b@mail.gmail.com>
Message-ID: <2096514e04070213025c09e3d3@mail.gmail.com>

Hey Graeme,

SCons is awesome!  (Bias note: I've been one of the developers since
shortly after the project went public.  But that's because I
immediately saw how much better a build tool using Python syntax is
than make.  Or pretty much anything, really.)  I use it to build every
project I start, especially the larger ones.  The focus on build
reliability and one global dependency tree is great.  You almost never
have to do an scons -c and scons in order to get a correct build.  And
when you do have to clean in order to verify it's correct, something
is buggy.  :)

Another advantage of SCons is Steven Knight, the guy who originally
created it.  He's an incredibly awesome manager and a nice guy all
around.  If you feel good about SCons, he does too.  If you don't feel
good, he and the rest of the community try to make SCons a little
nicer.

The SConstruct I attached is a total hackjob so I could get something
compiling as fast as possible.  A better one might look like:

def python_tool(env):
    pybase = 'python%s' % sys.version[0:3]
    env.Append(CPPPATH=[os.path.join(sys.prefix, 'include', pybase)],
               LIBPATH=[os.path.join(sys.prefix, 'lib', pybase, 'config')],
               LIBS=['lib%s' % pybase])
    if env['PLATFORM'] not in ['cygwin', 'win32']:
        env.Append(LIBS=['util'])

def boost_python_tool(env):
    env.Append(CPPDEFINES=['BOOST_PYTHON_STATIC_LIB',
                           'BOOST_PYTHON_STATIC_MODULE'],
               CPPPATH=['$boostIncludes'],  # boostIncludes is a PathOption
               LIBS=['boost_python-gcc'])

import os
env = Environment(ENV=os.environ, tools=['default', python_tool,
boost_python_tool])
env.SharedLibrary('hello', 'hello.cpp')

Then you could start to migrate in options (via the Options object)
and platform tests (via testing env['PLATFORM'] and such.

On this list, I keep hearing this vibe "you should use bjam to make
sure you get the voodoo build commands right, otherwise things will
fail in unpredictable ways."  I've never had a problem (win32, cygwin,
linux), though.  I just define BOOST_PYTHON_STATIC_LIB,
BOOST_PYTHON_STATIC_MODULE (for embedding), and
BOOST_PYTHON_NO_TEMPLATE_EXPORT (although this is kinda broken in
1.31).  Use SharedLibrary if you're building an extension module, etc.

Chad

On Fri, 2 Jul 2004 12:21:07 -0700, Graeme Lufkin
<graeme.lufkin at gmail.com> wrote:
> 
>     I'm interested to see you're using SCons to build your modules.
> Would you mind posting a short account of your experience using SCons,
> both in general and with Boost.Python?  I still wrestle with Makefile
> vs Boost.Build vs tearing-my-hair-out every once in while.  A more
> complicate SConstruct file would be great to look at too.  Thanks
> 
> On Fri, 2 Jul 2004 11:48:43 -0500, Chad Austin <caustin at gmail.com> wrote:
> > Chad at basilisk ~/tmp/bp
> > $ scons
> > scons: Reading SConscript files ...
> > scons: done reading SConscript files.
> > scons: Building targets ...
> > g++ -DBOOST_PYTHON_STATIC_LIB -DBOOST_PYTHON_NO_TEMPLATE_EXPORT -I/usr/local/inc
> > lude/boost-1_31 -I/usr/include/python2.3 -c -o hello.os hello.cpp
> > g++ -shared -o hello.dll hello.os -L/usr/lib/python2.3/config -L/usr/local/lib -
> > lboost_python-gcc -lpython2.3
> > scons: done building targets.
> >
> 
> --
>     -- Graeme
>     graeme.lufkin at gmail.com
> 
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 


-- 
Chad Austin
http://aegisknight.org/



From faheem at email.unc.edu  Fri Jul  2 23:25:01 2004
From: faheem at email.unc.edu (Faheem Mitha)
Date: Fri, 2 Jul 2004 21:25:01 +0000 (UTC)
Subject: [C++-sig] Re: compile errors with embedding example from tutorial
References: <slrncdv7fb.om1.faheem@Chrestomanci.home.earth>
	<2096514e040627214639a53ca5@mail.gmail.com>
	<slrnce0mgb.om1.faheem@Chrestomanci.home.earth>
	<2096514e04062813561ceb1d79@mail.gmail.com>
	<slrnce17gj.om1.faheem@Chrestomanci.home.earth>
	<uhdsutl9n.fsf@boost-consulting.com>
	<slrnce722k.om1.faheem@Chrestomanci.home.earth>
	<4d3b9ecb04070109051b127d80@mail.gmail.com>
	<slrnce8sep.eo3.faheem@Chrestomanci.home.earth>
	<4d3b9ecb0407011352f11f078@mail.gmail.com>
	<slrnce955o.eo3.faheem@Chrestomanci.home.earth>
	<4d3b9ecb040701161250ac13eb@mail.gmail.com>
	<slrnce9one.om1.faheem@Chrestomanci.home.earth>
	<40E50757.4030708@boost-consulting.com>
	<slrnceavmc.om1.faheem@Chrestomanci.home.earth>
	<2096514e040702084310df702c@mail.gmail.com>
	<slrnceb2nj.jco.faheem@Chrestomanci.home.earth>
	<2096514e0407020948342cf622@mail.gmail.com>
Message-ID: <slrncebklc.eo3.faheem@Chrestomanci.home.earth>

On Fri, 2 Jul 2004 11:48:43 -0500, Chad Austin <caustin at gmail.com> wrote:
> ------=_Part_96_10773503.1088786923701
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> Heh, I've run into that problem before too.  You may have to do the
> import with PyImport_Import or whatever it is.  (The C equivalent of
> __import__)

You mean use PyImport_Import to import __builtin__? Can you tell me
what the correct syntax for this would be?

> Oddly enough, I'm not seeing any of the problems you are.  See the
> attached files.  Works fine for me.
>
> Chad at basilisk ~/tmp/bp
> $ scons
> scons: Reading SConscript files ...
> scons: done reading SConscript files.
> scons: Building targets ...
> g++ -DBOOST_PYTHON_STATIC_LIB -DBOOST_PYTHON_NO_TEMPLATE_EXPORT -I/usr/local/inc
> lude/boost-1_31 -I/usr/include/python2.3 -c -o hello.os hello.cpp
> g++ -shared -o hello.dll hello.os -L/usr/lib/python2.3/config -L/usr/local/lib -
> lboost_python-gcc -lpython2.3
> scons: done building targets.
>
> Chad at basilisk ~/tmp/bp
> $ python
> Python 2.3.4 (#1, Jun 13 2004, 11:21:03)
> [GCC 3.3.1 (cygming special)] on cygwin
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import hello
>>>> w = hello.World()
>>>> w.run()
>>>> import os
>>>> os.system('cat hello.txt')
> Hello world!0

Hi.

I tried using the second Scons file you posted. I had to add `import
sys' at the beginning.

For some reason it builds a file called libhello.so. I renamed it to
hello.so. Do you know why it is generating a file called libhello.so
and how to get it to output to hello.so?

Anyway, I get the same problem with your code as I do with mine,
namely

In [1]: import hello

In [2]: foo = hello.World()

In [3]: foo.run()
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call
last)

/home/faheem/wc/corrmodel/boost/<console>

/home/faheem/wc/corrmodel/boost/<string>

NameError: name 'file' is not defined

I also used Boost.Build and got the same problem. I wonder what is
going on. Possibly some configuration issue with my system. Maybe I
should harass the Debian maintainers of Boost.Python about this. :-)

I figure that it is worth while trying to figure out how to import
__builtin__ somehow. If anyone has specific suggestions about the
syntax, let me know. I'm pretty clueless.

Scons looks cool. The last time I looked at it I didn't know any
Python. Maybe it is time to take a look again.

Thanks for your help.
                                                          Faheem.




From rwgk at yahoo.com  Sat Jul  3 00:26:43 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 2 Jul 2004 15:26:43 -0700 (PDT)
Subject: [C++-sig] Python, Boost.Python, and SCons
In-Reply-To: <2096514e04070213025c09e3d3@mail.gmail.com>
Message-ID: <20040702222643.59804.qmail@web20225.mail.yahoo.com>

--- Chad Austin <caustin at gmail.com> wrote:
> SCons is awesome!

SCons is awesome indeed! I am using it ever since the repository support was
added (0.08 or so). However, there is one thing I have to hack around: the
implicit dependency scan of the boost tree is horribly slow on some older
platforms (minutes before the first compilation command is issued) and even on
new platforms I find the waits very annoying when I am in a debug/recompile
cycle. 18 months ago or so I submitted a patch that allowed me to turn the
implicit dependency scan on/off for selected subdirectories. However, the SCons
people didn't even buy into the idea, let alone the patch. Right now I resort
to the trick where I add include paths to CPPFLAGS instead of CPPPATH. It is
not pretty at all because I have remember to do this in each and every
Environment, and it is difficult to pinpoint where I might have forgotten to do
so. Since you are a SCons developer that is also using Boost: don't you have
the same problem? Is there a chance that SCons will at some point provide a
rational scheme for turning the implicit dependency scan on/off in selected
subdirectories that are known to be static? Is there an alternative that I
missed?

Ralf


	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 



From strawman at astraw.com  Sat Jul  3 03:26:43 2004
From: strawman at astraw.com (Andrew Straw)
Date: Fri, 02 Jul 2004 18:26:43 -0700
Subject: [C++-sig] newbie question: converting double* arrays
Message-ID: <40E60B53.3060502@astraw.com>

Continuing the newbie questions:

I'm trying to call a C++ method which takes a double* as an argument.  
(I'm sure this isn't the best C++ style, but it isn't my library I'm 
wrapping!)

After spending the day continuing up the Boost.Python and C++ learning 
curves, I've come up with the very non-ideal solution. It's particularly 
bad because even this hack doesn't compile! So, I seek feedback as to 
either 1) the Right Way to do it or 2) how to fix my presumably simple 
error:

I know the function expects an array of 3 doubles, so I created this hack:

// ---- pyopencv.hpp
class Doubles3
{
public:
  Doubles3(double a, double b, double c);
  double* Get();
protected:
  double values [3];
};

// ---- pyopencv.cpp
#include "pyopencv.hpp"
#include <boost/python/suite/indexing/vector_indexing_suite.hpp>
#include <boost/python.hpp>
#include <boost/python/numeric.hpp>
#include <boost/python/tuple.hpp>

Doubles3::Doubles3(double a, double b, double c) { values[0]=a; 
values[1]=b; values[2]=c; }
double* Doubles3::Get() { return values; }

using namespace boost::python;

BOOST_PYTHON_MODULE(pyopencv)
{ 

  class_<Doubles3>("Doubles3", init<double,double,double>())
    .def("Get",&Doubles3::Get)
    //.def("Get",&Doubles3::Get,return_internal_reference<>())
    ;

  class_<std::vector<double> >("vector_of_double")  // Could this be the 
start of the Right Way?
    .def(vector_indexing_suite<std::vector<double> >())
    ;
}


The error in this case is:
/home/astraw/other-peoples-src/boost_1_31_0/boost/python/detail/invoke.hpp:89: 
error: no
   match for call to `(const
   
boost::python::detail::specify_a_return_value_policy_to_wrap_functions_returning<double*>
   ) (double*)'

And if I try the other .def (commented out above), I get:
/home/astraw/other-peoples-src/boost_1_31_0/boost/python/object/make_instance.hpp:25: 
error: invalid
   application of `sizeof' to an incomplete type

So, I tried putting "double*" between () in 
return_internal_reference<>(), but this didn't help...  I'm in pretty 
deep into C++, as you can tell, but I should think this would be easy, 
even if it's not the best C++ style.  Please help!

For completeness' sake, here's what I'm trying to wrap:

// ---- original method I'm wrapping (in cvaux.h)
class CVAUX_DLL_ENTRY CvCalibFilter
{
public:
    virtual bool
        SetEtalon( CvCalibEtalonType etalonType, double* etalonParams,
                   int pointCount = 0, CvPoint2D32f* points = 0 );
}

// ---- relevant snippet from boosst_cvaux.cpp
BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS(CvCalibFilter_SetEtalon_overloads, 
CvCalibFilter::SetEtalon, 2, 4)
BOOST_PYTHON_MODULE(cvaux)
{
  class_<CvCalibFilter, CvCalibFilterWrap, 
boost::noncopyable>("CvCalibFilter",
                                   "This is CvCalibFilter's docstring")

    .def("SetEtalon", &CvCalibFilter::SetEtalon,
     CvCalibFilter_SetEtalon_overloads())
}



From jbrandmeyer at earthlink.net  Sat Jul  3 04:07:43 2004
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Fri, 02 Jul 2004 22:07:43 -0400
Subject: [C++-sig] Python, Boost.Python, and SCons
In-Reply-To: <20040702222643.59804.qmail@web20225.mail.yahoo.com>
References: <20040702222643.59804.qmail@web20225.mail.yahoo.com>
Message-ID: <1088820463.11747.4.camel@illuvatar>

On Fri, 2004-07-02 at 18:26, Ralf W. Grosse-Kunstleve wrote:
> --- Chad Austin <caustin at gmail.com> wrote:
> > SCons is awesome!
> 
> SCons is awesome indeed! I am using it ever since the repository support was
> added (0.08 or so). However, there is one thing I have to hack around: the
> implicit dependency scan of the boost tree is horribly slow on some older
> platforms (minutes before the first compilation command is issued) and even on
> new platforms I find the waits very annoying when I am in a debug/recompile
> cycle.

I've only recently started learning how to use Scons, and not with Boost
yet.  There is a way to use timestamps rather than md5 hashes to check
dependency relationships.
SourceSignatures('timestamp')

Does that help?  This sounds like a major scalability problem to me.

-Jonathan




From dave at boost-consulting.com  Sat Jul  3 04:19:17 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 02 Jul 2004 22:19:17 -0400
Subject: [C++-sig] Re: compile errors with embedding example from tutorial
References: <slrncdv7fb.om1.faheem@Chrestomanci.home.earth>
	<2096514e040627214639a53ca5@mail.gmail.com>
	<slrnce0mgb.om1.faheem@Chrestomanci.home.earth>
	<2096514e04062813561ceb1d79@mail.gmail.com>
	<slrnce17gj.om1.faheem@Chrestomanci.home.earth>
	<uhdsutl9n.fsf@boost-consulting.com>
	<slrnce722k.om1.faheem@Chrestomanci.home.earth>
	<4d3b9ecb04070109051b127d80@mail.gmail.com>
	<slrnce8sep.eo3.faheem@Chrestomanci.home.earth>
	<4d3b9ecb0407011352f11f078@mail.gmail.com>
	<slrnce955o.eo3.faheem@Chrestomanci.home.earth>
	<4d3b9ecb040701161250ac13eb@mail.gmail.com>
	<slrnce9one.om1.faheem@Chrestomanci.home.earth>
	<40E50757.4030708@boost-consulting.com>
	<slrnceavmc.om1.faheem@Chrestomanci.home.earth>
Message-ID: <uisd5g7dm.fsf@boost-consulting.com>

Faheem Mitha <faheem at email.unc.edu> writes:

>
> Thanks. However, I am not sure which version of the test/embedding.cpp
> you are referring to. 

The one in the current CVS.

> The version at
> http://www.boost.org/libs/python/test/embedding.cpp which I assume is
> the current CVS, 

It is not.

> is the same as the version in 1.31, and neither of
> them have the code you refer to.

Get the current CVS.
http://www.boost.org/more/getting_started.html#CVS

> In any case, does the code you refer to define an extension module
> which embeds the interpreter 

What do you mean by "embeds the interpreter?"  Normally "embedding"
means a stand-alone application calls the Python interpreter.  When an
extension module calls the Python interpreter it's just more
"extending" (unless you're talking about multiple interpreter
instances, in which case you should ask on comp.lang.python -- almost
nobody knows how to handle that correctly).

> and can be called from Python? Because
> that is the case I am interested in. I have been unable to find any
> examples out there along these lines, despite some effort.
>
> The current version of test/embedding.cpp that I have seen is a C++
> executable, and the extension module defined there is called within
> the interpreter that is embedded in this executable. This is not the
> same as what I am trying to do.

Just make a regular extension module and call the interpreter.
Nothing to it.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com




From dave at boost-consulting.com  Sat Jul  3 04:22:01 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 02 Jul 2004 22:22:01 -0400
Subject: [C++-sig] Re: Default Numeric module
References: <1088785714.10104.5.camel@illuvatar>
Message-ID: <ud63dg792.fsf@boost-consulting.com>

Jonathan Brandmeyer <jbrandmeyer at earthlink.net> writes:

> It seems that the documentation and actual behavior or the
> numeric::array class do not agree with each other.  The documentation
> states that Numeric.ArrayType will be used in preference to
> numarray.NDArray when both are available, however the opposite is true.
>
> I can commit a trivial patch to correct the implementation, unless it is
> the documentation that is in error.

Please do.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com




From jbrandmeyer at earthlink.net  Sat Jul  3 06:19:09 2004
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Sat, 03 Jul 2004 00:19:09 -0400
Subject: [C++-sig] Python, Boost.Python, and SCons
In-Reply-To: <1088820463.11747.4.camel@illuvatar>
References: <20040702222643.59804.qmail@web20225.mail.yahoo.com>
	<1088820463.11747.4.camel@illuvatar>
Message-ID: <1088828349.15836.9.camel@illuvatar>

On Fri, 2004-07-02 at 22:07, Jonathan Brandmeyer wrote:
> On Fri, 2004-07-02 at 18:26, Ralf W. Grosse-Kunstleve wrote:
> > --- Chad Austin <caustin at gmail.com> wrote:
> > > SCons is awesome!
> > 
> > SCons is awesome indeed! I am using it ever since the repository support was
> > added (0.08 or so). However, there is one thing I have to hack around: the
> > implicit dependency scan of the boost tree is horribly slow on some older
> > platforms (minutes before the first compilation command is issued) and even on
> > new platforms I find the waits very annoying when I am in a debug/recompile
> > cycle.
> 
> I've only recently started learning how to use Scons, and not with Boost
> yet.  There is a way to use timestamps rather than md5 hashes to check
> dependency relationships.
> SourceSignatures('timestamp')
> 
> Does that help?  This sounds like a major scalability problem to me.

Never mind, I see now that you mean the preprocessor's scanning to
generate the dependency tree.  Ungh.

-Jonathan




From caustin at gmail.com  Sat Jul  3 10:14:18 2004
From: caustin at gmail.com (Chad Austin)
Date: Sat, 3 Jul 2004 03:14:18 -0500
Subject: [C++-sig] Python, Boost.Python, and SCons
In-Reply-To: <20040702222643.59804.qmail@web20225.mail.yahoo.com>
References: <20040702222643.59804.qmail@web20225.mail.yahoo.com>
Message-ID: <2096514e04070301146ec531e1@mail.gmail.com>

(If this thread is getting off-topic, maybe we should move it to the
SCons lists.)

Hi Ralf,

In my experience, the dependency scan for boost.python hasn't been
that bad...  but maybe that's because my primary machine is a dual
xeon 2.8.  I remember your patch, but I don't remember why we
disagreed with it...  I could see them buying into your patch if you
were persistent enough and had a strong enough argument.  I don't
remember how you implemented it, but maybe a good way would be to use
an environment variable [SCAN_CPP_IGNORE_PATH?] that the CScanner uses
to filter the directories it scans it.

Chad

p.s.  Have you tried always using the --implicit-cache option?  That
usually works wonders, and very rarely results in an incorrect build.

On Fri, 2 Jul 2004 15:26:43 -0700 (PDT), Ralf W. Grosse-Kunstleve
<rwgk at yahoo.com> wrote:
> --- Chad Austin <caustin at gmail.com> wrote:
> > SCons is awesome!
> 
> SCons is awesome indeed! I am using it ever since the repository support was
> added (0.08 or so). However, there is one thing I have to hack around: the
> implicit dependency scan of the boost tree is horribly slow on some older
> platforms (minutes before the first compilation command is issued) and even on
> new platforms I find the waits very annoying when I am in a debug/recompile
> cycle. 18 months ago or so I submitted a patch that allowed me to turn the
> implicit dependency scan on/off for selected subdirectories. However, the SCons
> people didn't even buy into the idea, let alone the patch. Right now I resort
> to the trick where I add include paths to CPPFLAGS instead of CPPPATH. It is
> not pretty at all because I have remember to do this in each and every
> Environment, and it is difficult to pinpoint where I might have forgotten to do
> so. Since you are a SCons developer that is also using Boost: don't you have
> the same problem? Is there a chance that SCons will at some point provide a
> rational scheme for turning the implicit dependency scan on/off in selected
> subdirectories that are known to be static? Is there an alternative that I
> missed?
> 
> Ralf
> 
> 
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - 100MB free storage!
> http://promotions.yahoo.com/new_mail
> 
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 


-- 
Chad Austin
http://aegisknight.org/



From dave at boost-consulting.com  Sat Jul  3 17:08:06 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 03 Jul 2004 11:08:06 -0400
Subject: [C++-sig] Re: [Boost-python-cvs] CVS: boost/libs/python/src
 numeric.cpp,1.2,1.3
In-Reply-To: <E1Bgbbq-00080H-4J@sc8-pr-cvs1.sourceforge.net> (Jonathan
	Brandmeyer's message of "Fri, 02 Jul 2004 20:54:38 -0700")
References: <E1Bgbbq-00080H-4J@sc8-pr-cvs1.sourceforge.net>
Message-ID: <ufz89dt7t.fsf@boost-consulting.com>

Jonathan Brandmeyer <jbrandmeyer at users.sourceforge.net> writes:

> Update of /cvsroot/boost/boost/libs/python/src
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv30661
>
> Modified Files:
> 	numeric.cpp 
> Log Message:
> Use Numeric.ArrayType in preference to numarray.NDArray, in accordance 
> with the documentation.

Ugh.  Jonathan, I'm sorry; it's the documentation that was wrong.
numarray is the replacement for Numeric and should be preferred.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com




From dleary at gmail.com  Sat Jul  3 17:53:12 2004
From: dleary at gmail.com (Dusty Leary)
Date: Sat, 3 Jul 2004 11:53:12 -0400
Subject: [C++-sig] Re: implicitly_convertible and char*
In-Reply-To: <uu0wtoonw.fsf@boost-consulting.com>
References: <81c509c040629130556f7312d@mail.gmail.com>
	<20040629205654.59109.qmail@web20212.mail.yahoo.com>
	<uu0wtoonw.fsf@boost-consulting.com>
Message-ID: <81c509c04070308535c33b72e@mail.gmail.com>

so, any news on this?


On Tue, 29 Jun 2004 20:49:39 -0400, David Abrahams
<dave at boost-consulting.com> wrote:
> "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:
> 
> > I don't really feel competent in this matter, but I believe char const* and
> > const char* are two different things. Did you try it with "const char*"?
> 
> They are the same thing.
> 
> 
> 
> --
> Dave Abrahams
> Boost Consulting
> http://www.boost-consulting.com
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>



From s_sourceforge at nedprod.com  Sat Jul  3 19:07:56 2004
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 03 Jul 2004 18:07:56 +0100
Subject: [C++-sig] Re: compile errors with embedding example from tutorial
In-Reply-To: <4d3b9ecb040702122186cdd1b@mail.gmail.com>
References: <2096514e0407020948342cf622@mail.gmail.com>
Message-ID: <40E6F5FC.16639.1263850@localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2 Jul 2004 at 12:21, Graeme Lufkin wrote:

>     I'm interested to see you're using SCons to build your modules.
> Would you mind posting a short account of your experience using SCons,
> both in general and with Boost.Python?  I still wrestle with Makefile
> vs Boost.Build vs tearing-my-hair-out every once in while.  A more
> complicate SConstruct file would be great to look at too.  Thanks

I'll also add my ha'pennies worth and say SCons is great. And like 
everyone, all my SConstruct files feel really hacky and I prefer not 
showing them to people - but that said, changing them is a cinch and 
it's SOOO much more flexible than any other build system I've ever 
used.

I'd really like it if Ralf's SConstruct files for Boost came with 
Boost. Thoughts?

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBQObn7MEcvDLFGKbPEQIFGACfV1C17ZqPq9xMbsDPgcu5MdPL4vsAn2RU
gY2luoKcoBLORPSIcoAH367D
=98W2
-----END PGP SIGNATURE-----



From jeff.holle at verizon.net  Sun Jul  4 04:24:42 2004
From: jeff.holle at verizon.net (Jeffrey Holle)
Date: Sat, 03 Jul 2004 22:24:42 -0400
Subject: [C++-sig] Re: Calling a python function from C++ (from Jeff Holle)
In-Reply-To: <2096514e0406302000530e12e0@mail.gmail.com>
References: <40E142ED.2030603@verizon.net>
	<cbutac$gs6$1@sea.gmane.org>	<cbvbt6$k5r$1@sea.gmane.org>
	<2096514e0406302000530e12e0@mail.gmail.com>
Message-ID: <40E76A6A.1010309@verizon.net>

I want to thank you for this.

I've attempted to improve it, based on code I've found on the internet.
It basically adds "Extra Extraa paranoia" about the nature of whats 
returned from PyErr_Fetch.  Don't know if this level of paranoia is 
needed.  But I try to assume nothing.

I've attempted to tackle the traceback info too.  At this point I don't 
believe its possible because of inadequeses in the Python "C" API.

The one traceset specific function that I do use is undocumented, and it 
just verifies that the python object is really a traceback object.

If you, or anybody, have a different opinion, I'd like to know about it.

My code, modified your example is:

   // Extra paranoia...
   if (!PyErr_Occurred()) {
     return;
   }
   // PyErr_Print();
   PyObject *type = NULL, *value = NULL, *traceback = NULL, *pyString = 
NULL;
   PyErr_Fetch(&type, &value, &traceback);
   PyErr_Clear();
   _M_msg = "Python error: ";
   if (type != NULL && (pyString=PyObject_Str(type))!=NULL && 
(PyString_Check(pyString)))
     _M_msg += PyString_AsString(pyString);
   else
     _M_msg += "<unknown exception type> ";
   Py_XDECREF(pyString);
   if (value != NULL && (pyString=PyObject_Str(value))!=NULL && 
(PyString_Check(pyString))) {
     _M_msg += ": ";
     _M_msg += PyString_AsString(value);
   } else
     _M_msg += "<unknown exception date> ";
   Py_XDECREF(pyString);
   if (traceback != NULL && PyTraceBack_Check(traceback)) {
     // what belongs here? TBD
   }
   Py_XDECREF(type);
   Py_XDECREF(value);
   Py_XDECREF(traceback);




Chad Austin wrote:
> Straight from my codebase:
> 
>     std::string getPythonErrorString() {
>         // Extra paranoia...
>         if (!PyErr_Occurred()) {
>             return "No Python error";
>         }
> 
>         PyObject *type, *value, *traceback;
>         PyErr_Fetch(&type, &value, &traceback);
>         PyErr_Clear();
> 
>         std::string message = "Python error: ";
>         if (type) {
>             type = PyObject_Str(type);
>             message += PyString_AsString(type);
>         }
>         if (value) {
>             value = PyObject_Str(value);
>             message += ": ";
>             message += PyString_AsString(value);
>         }
>         Py_XDECREF(type);
>         Py_XDECREF(value);
>         Py_XDECREF(traceback);
> 
>         return message;
>     }
> 
>     void checkForPythonError() {
>         if (PyErr_Occurred()) {
>             throw PythonError(getPythonErrorString());
>         }
>     }
> 
>     void requirePythonError() {
>         if (!PyErr_Occurred()) {
>             throw PythonError("Boost.Python exception, "
>                               "but no Python error set.");
>         }
>     }
> 
> ...
> 
>     PYR_DEFINE_RUNTIME_ERROR(PythonError);
> 
>     std::string getPythonErrorString();
>     void checkForPythonError();
>     void requirePythonError();
> 
>     /**
>      * Allows us to check for Python errors at the end of a Python
>      * code block whether control left the end of the block or
>      * 'return' was used.
>      */
>     struct PythonCodeErrorSentry {
>         ~PythonCodeErrorSentry() {
>             if (!std::uncaught_exception()) {
>                 checkForPythonError();
>             }
>         }
>     };
> 
>     #define PYR_NO_UNUSED_WARNING(x) ((void)&(x))
> 
>     #define PYR_BEGIN_PYTHON_CODE()                          \
>         try {                                                \
>             PythonCodeErrorSentry sentry__;                  \
>             PYR_NO_UNUSED_WARNING(sentry__);  // silly gcc
> 
>     #define PYR_END_PYTHON_CODE()                            \
>         }                                                    \
>         catch (const boost::python::error_already_set&) {    \
>             requirePythonError();                            \
>             throw PythonError(getPythonErrorString());       \
>         }
> 
> 
> May have bugs, but it should give you an idea of what to do.  Notice I
> don't do anything with the stacktrace object yet, but it wouldn't take
> much more work.
> 
> HTH,
> Chad
> 
> 
> On Wed, 30 Jun 2004 02:39:46 -0400, Jeffrey Holle
> <jeff.holle at verizon.net> wrote:
> 
>>Given what the name of this exception, I assume there is a source of
>>information to obtain useful information about it.
>>To this end, I've dug a bit into the Python C API and found the added
>>the following to my code example:
>>
>>   catch (error_already_set& x) {
>>        PyObject *err_type,*err_value,*err_traceback;
>>        PyErr_Fetch(&err_type,&err_value,&err_traceback);
>>         cout << "something bad happened" << endl;
>>     }
>>
>>While I see that err_type and error_value are not null pointers after
>>the call to PyErr_Fetch, I don't know what to do with either to get at a
>>useful message.
>>Can anybody provide any hints?
>>
>>
>>
>>Jeffrey Holle wrote:
>>
>>>I've explored whats actually going on some with my debugger and now see
>>>what is being thrown.
>>>It is "error_already_set".  This is a trivial object (it has no
>>>attributes at all), and isn't much better than "catch (...)".
>>>However, its name implies something.  Is there a meaningful error
>>>message set somewhere else that can be accessed within the catch clause
>>>of "error_already_set"?
>>>
>>>Jeff Holle wrote:
>>>
>>>
>>>>>
>>>>>>An underlining concern I have is error handling.  When
>>>>>>PyImport_ImportModule fails, a NULL pointer is returned.
>>>>>>Seems like the underlining machinery in "handle<>" is intolerant of
>>>>>>this.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>What makes you say that?
>>>>>
>>>>
>>>>You are correct about the success in compiling your much cleaner
>>>>example, and it works :-) , but has a flaw.
>>>>
>>>>When I hide the needed python script, the call to
>>>>PyImport_ImportModule returns NULL.
>>>>When this occurres, both your example and what I had created, but
>>>>commented out throws something because I can catch it with
>>>>"catch(...)".  I don't however know how to be more specific.  Any
>>>>hints?  Whatever it is, it doesn't inherit from "exception".
>>>>
>>>>If I was operating on windows, I would anticipate it was a "structured
>>>>exception", or whatever Microsoft calls their propritary stuff.  Don't
>>>>know of the equivalent on linux though.  Without the "catch (...)",
>>>>the command line program exits with "Aborted".
>>
>>_______________________________________________
>>C++-sig mailing list
>>C++-sig at python.org
>>http://mail.python.org/mailman/listinfo/c++-sig
>>



From jbrandmeyer at earthlink.net  Sat Jul  3 19:28:38 2004
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Sat, 03 Jul 2004 13:28:38 -0400
Subject: [C++-sig] Re: [Boost-python-cvs] CVS: boost/libs/python/src
	numeric.cpp,1.2,1.3
In-Reply-To: <ufz89dt7t.fsf@boost-consulting.com>
References: <E1Bgbbq-00080H-4J@sc8-pr-cvs1.sourceforge.net>
	<ufz89dt7t.fsf@boost-consulting.com>
Message-ID: <1088875718.2931.2.camel@illuvatar>

On Sat, 2004-07-03 at 11:08, David Abrahams wrote:
> Jonathan Brandmeyer <jbrandmeyer at users.sourceforge.net> writes:
> 
> > Update of /cvsroot/boost/boost/libs/python/src
> > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv30661
> >
> > Modified Files:
> > 	numeric.cpp 
> > Log Message:
> > Use Numeric.ArrayType in preference to numarray.NDArray, in accordance 
> > with the documentation.
> 
> Ugh.  Jonathan, I'm sorry; it's the documentation that was wrong.
> numarray is the replacement for Numeric and should be preferred.

I've reverted the change and fixed the documentation.  I was operating
on the idea that Numeric would be preferred since numarray is not yet
done.

-Jonathan




From ingo at fargonauten.de  Sat Jul  3 19:33:51 2004
From: ingo at fargonauten.de (Ingo Luetkebohle)
Date: Sat, 3 Jul 2004 19:33:51 +0200
Subject: [C++-sig] Re: compile errors with embedding example from tutorial
In-Reply-To: <40E6F5FC.16639.1263850@localhost>
References: <2096514e0407020948342cf622@mail.gmail.com>
	<40E6F5FC.16639.1263850@localhost>
Message-ID: <20040703173351.GA7191@fargonauten.de>

On Sat, Jul 03, 2004 at 06:07:56PM +0100, Niall Douglas wrote:
> I'll also add my ha'pennies worth and say SCons is great. And like 
> everyone, all my SConstruct files feel really hacky

Yay :)

And if you think your SConstruct files are hacky, try looking at a
couple of automake or configure scripts sometime ;-)

Ingo



From dave at boost-consulting.com  Sat Jul  3 20:17:27 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 03 Jul 2004 14:17:27 -0400
Subject: [C++-sig] Re: newbie question: converting double* arrays
References: <40E60B53.3060502@astraw.com>
Message-ID: <uwu1larbc.fsf@boost-consulting.com>

Andrew Straw <strawman at astraw.com> writes:

> The error in this case is:
> /home/astraw/other-peoples-src/boost_1_31_0/boost/python/detail/invoke.hpp:89:
> error: no
>    match for call to `(const
>    boost::python::detail::specify_a_return_value_policy_to_wrap_functions_returning<double*>
>    ) (double*)'

The issue in this case isn't a double* argument.  As indicated by the
error message, it's the double* return.  How would you like that to be
converted to Python?

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com




From dave at boost-consulting.com  Sat Jul  3 20:19:27 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 03 Jul 2004 14:19:27 -0400
Subject: [C++-sig] Re: implicitly_convertible and char*
References: <81c509c040629130556f7312d@mail.gmail.com>
	<20040629205654.59109.qmail@web20212.mail.yahoo.com>
	<uu0wtoonw.fsf@boost-consulting.com>
	<81c509c04070308535c33b72e@mail.gmail.com>
Message-ID: <uoemxar80.fsf@boost-consulting.com>

Dusty Leary <dleary at gmail.com> writes:

> so, any news on this?

What news grould there be?  char const* and const char* are the same
thing, so trying it won't make any difference.

> On Tue, 29 Jun 2004 20:49:39 -0400, David Abrahams
> <dave at boost-consulting.com> wrote:
>> "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:
>> 
>> > I don't really feel competent in this matter, but I believe char const* and
>> > const char* are two different things. Did you try it with "const char*"?
>> 
>> They are the same thing.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com




From dleary at gmail.com  Sat Jul  3 20:23:07 2004
From: dleary at gmail.com (Dusty Leary)
Date: Sat, 3 Jul 2004 14:23:07 -0400
Subject: [C++-sig] Re: implicitly_convertible and char*
In-Reply-To: <uoemxar80.fsf@boost-consulting.com>
References: <81c509c040629130556f7312d@mail.gmail.com>
	<20040629205654.59109.qmail@web20212.mail.yahoo.com>
	<uu0wtoonw.fsf@boost-consulting.com>
	<81c509c04070308535c33b72e@mail.gmail.com>
	<uoemxar80.fsf@boost-consulting.com>
Message-ID: <81c509c040703112342091c2c@mail.gmail.com>

yeah, that was an unrelated side note that someone else brought up... 
the issue is that implicity_convertible<X, const char*> is not working


On Sat, 03 Jul 2004 14:19:27 -0400, David Abrahams
<dave at boost-consulting.com> wrote:
> Dusty Leary <dleary at gmail.com> writes:
> 
> > so, any news on this?
> 
> What news grould there be?  char const* and const char* are the same
> thing, so trying it won't make any difference.
> 
> 
> 
> > On Tue, 29 Jun 2004 20:49:39 -0400, David Abrahams
> > <dave at boost-consulting.com> wrote:
> >> "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:
> >>
> >> > I don't really feel competent in this matter, but I believe char const* and
> >> > const char* are two different things. Did you try it with "const char*"?
> >>
> >> They are the same thing.
> 
> --
> Dave Abrahams
> Boost Consulting
> http://www.boost-consulting.com
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>



From xin at xlevus.net  Mon Jul  5 01:47:04 2004
From: xin at xlevus.net (xin)
Date: Sun, 04 Jul 2004 16:47:04 -0700
Subject: [C++-sig] Re: Accessing C++ values from within Python
In-Reply-To: <40E26BF7.6070809@verizon.net>
References: <cbu8sl$jkr$1@sea.gmane.org> <40E26BF7.6070809@verizon.net>
Message-ID: <cc8243$ifa$1@sea.gmane.org>

I finally got around to trying to get this to work, as I am unable to get bjam 
to operate correctly I tried to implement it in my existing code.
Unfortunately I get problems with the getPythonFunction() function. When I ran 
it, the application would abort.

After playing around a bit I ended up with :
PyObject *getPythonFunction(const char *moduleName, const char *functionName)
{
    PyObject *pModule = PyImport_ImportModule((char *)moduleName);
}
And I got the error when I ran it:
Exception exceptions.ImportError: 'No module named testScript.py' in 'garbage 
collection' ignored
Fatal Python error: unexpected exception during garbage collection Aborted

Any comments/suggestions?

Jeffrey Holle wrote:
> I'm sending the source of a simple project that does what I believe you 
> are trying to do.
> 
> In Main.cpp, note the use of call, and the use of ref within it.
> The former does all the "magic" of converting C++ objects to/from python.
> The later causes the C++ object to be passed by reference, allowing the 
> python script to alter C++ object attributes.
> 
> 
> xin wrote:
> 
>> Hi.
>> I have a setup such as the following:
>>
>> class object {
>> public:
>>     void doSomthingElse();
>>     float x;
>>     float *y;
>>     Somthing SomePyScript;
>> };
>>
>> int main()
>> {
>>     object *array = new object[10]; // size of array is only an example
>>     for (int i = 0; i < 10; i++)
>>     {
>>         array[i].y = new float[array[i]]
>>         RunPythonScript(array[i]);
>>     }
>>     return 1;
>> }
>>
>> Where:
>>  - " Somting SomePyScript; " Is some reference to a python script that 
>> is affiliated with this instance of the class (varies from instance to 
>> instance)
>>  - " RunPythonScript(array[i]); " Is some method of running the python 
>> script that is affiliated with the instance array[i].
>>
>> My intention is that the python scripts change values within the class 
>> 'object'
>> e.g. The python code sets 'x' to equal 0.9. And then sets each value 
>> of y to equal a muliple of 9. (y[0] = 0, y[1] = 9, y[2] = 18, ... 
>> ,y[100] = 900 etc...)
>>
>> Is this at all possible? Is it possible without moving all the memory 
>> from one place, to another area accessable by both python and then 
>> back again? If so how would I go about doing it?
>>
>> I've tried all sorts of methods of attempting this, but have had no 
>> luck. Any help would be appreciated.
>>
>> Thanks.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig




From rwgk at yahoo.com  Sun Jul  4 08:41:38 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sat, 3 Jul 2004 23:41:38 -0700 (PDT)
Subject: [C++-sig] Python, Boost.Python, and SCons
In-Reply-To: <2096514e04070301146ec531e1@mail.gmail.com>
Message-ID: <20040704064138.28360.qmail@web20207.mail.yahoo.com>

--- Chad Austin <caustin at gmail.com> wrote:
> In my experience, the dependency scan for boost.python hasn't been
> that bad...

If you just build libboost_python.so and maybe a couple of extensions it is not
bad at all... but see below.

> but maybe that's because my primary machine is a dual
> xeon 2.8.

I have the same machine here, with RH8.

> p.s.  Have you tried always using the --implicit-cache option?  That
> usually works wonders, and very rarely results in an incorrect build.

Here are the timings if I configure our build system to compile "everything"
(maybe 150k lines + Boost) and do a "no-op" build (everything up to date) with
the full implicit dependency scan enabled, and all files on a local disk:

% time libtbx.scons .
scons: Reading SConscript files ...
Compiling distributed version of phaser
scons: done reading SConscript files.
scons: Building targets ...
scons: `.' is up to date.
scons: done building targets.
57.200u 6.450s 1:03.74 99.8%    0+0k 0+0io 1394pf+0w
% time libtbx.scons --implicit-cache .
scons: Reading SConscript files ...
Compiling distributed version of phaser
scons: done reading SConscript files.
scons: Building targets ...
scons: `.' is up to date.
scons: done building targets.
57.600u 6.480s 1:04.21 99.7%    0+0k 0+0io 1394pf+0w

And here the same but with the implicit dependency scan disabled for the Boost
subdirectory, using the CPPFLAGS trick:

% time libtbx.scons .
scons: Reading SConscript files ...
libtbx.scons: implicit dependency scan disabled for directory
/net/worm/scratch1/rwgk/dist/boost
Compiling distributed version of phaser
scons: done reading SConscript files.
scons: Building targets ...
scons: `.' is up to date.
scons: done building targets.
15.540u 1.340s 0:17.41 96.9%    0+0k 0+0io 1402pf+0w
% time libtbx.scons --implicit-cache .
scons: Reading SConscript files ...
libtbx.scons: implicit dependency scan disabled for directory
/net/worm/scratch1/rwgk/dist/boost
Compiling distributed version of phaser
scons: done reading SConscript files.
scons: Building targets ...
scons: `.' is up to date.
scons: done building targets.
15.350u 1.330s 0:16.88 98.8%    0+0k 0+0io 1402pf+0w

Four times faster! Cool?

--implicit-cache doesn't seem to do anything for me. Am I using this option
incorrectly?

> I remember your patch, but I don't remember why we disagreed with it...

My initial patch/suggestion was to introduce a global registry that the scanner
uses to decide where to prune the search for implicit dependencies. The
registry had switches to turn the scan on/off.

> I could see them buying into your patch if you
> were persistent enough and had a strong enough argument.  I don't
> remember how you implemented it, but maybe a good way would be to use
> an environment variable [SCAN_CPP_IGNORE_PATH?] that the CScanner uses
> to filter the directories it scans it.

That sounds like a great idea! Why didn't I think of that? :-) It is not quite
as global as I had in mind initially; one still has to be careful to define the
paths in all Environment instances. However, our usage pattern has evolved over
time is to use env.Copy() anyway to get common settings from a basic
Environment instance. I.e. your idea appears to be a perfect fit. I'd just have
to add the SCAN_CPP_IGNORE_PATH to our basic environment.

Do you have an idea how much is involved in adding the SCAN_CPP_IGNORE_PATH
feature? Would it be a local patch in the scanner, or does the general
framework need to be patched in several places to provide the necessary
support?

Ralf



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 



From rwgk at yahoo.com  Sun Jul  4 09:05:14 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 4 Jul 2004 00:05:14 -0700 (PDT)
Subject: [C++-sig] Python, Boost.Python, and SCons
In-Reply-To: <1088828349.15836.9.camel@illuvatar>
Message-ID: <20040704070514.44776.qmail@web20203.mail.yahoo.com>

--- Jonathan Brandmeyer <jbrandmeyer at earthlink.net> wrote:
> > I've only recently started learning how to use Scons, and not with Boost
> > yet.  There is a way to use timestamps rather than md5 hashes to check
> > dependency relationships.
> > SourceSignatures('timestamp')

The last time I tried (about 18 months ago) it didn't help. I believe the
problem is that the scanner still has to traverse the files, looking for the
#include directives. I didn't try combining timestamps and --implicit-cache,
though... but for several reasons I am not keen to switch to time stamps
anyway.

> > Does that help?  This sounds like a major scalability problem to me.

It is a little bit of a problem, but you can work around it to some degree
using the CPPFLAGS trick. The remaining waiting times are probably unavoidable
if you want the high degree of automation that SCons provides. However, I often
use another simple trick: I capture the output from scons for the module that I
am currently working on, put it in a sh script and execute that script to
compile and link just that one module. This reduces the waits to zero. When I
am done debugging I am happy to wait the 15 seconds for SCons to look for all
the side effects and to take over again.

Let me say again the SCons is truly awesome. In the grand scheme of things my
complaints are minor issues. Like any system of non-trivial complexity, SCons
has a few "features" that one has to get used to and learn how to work around.

> Never mind, I see now that you mean the preprocessor's scanning to
> generate the dependency tree.  Ungh.

No, the preprocessor is fortunately not involved. SCons is doing all the work
by itself. Under Linux with g++ this doesn't make a big difference time-wise,
but under Tru64 Unix "make depend" (using cxx) takes almost as long as
compiling everything. SCons is *much* faster in this case.

Ralf



		
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail 



From rwgk at yahoo.com  Sun Jul  4 09:23:25 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 4 Jul 2004 00:23:25 -0700 (PDT)
Subject: [C++-sig] patch for map_indexing_suite.hpp
Message-ID: <20040704072326.58622.qmail@web20205.mail.yahoo.com>

Hi Joel,

I found a minor bug in map_indexing_suite.hpp:

Index: suite/indexing/map_indexing_suite.hpp
===================================================================
RCS file:
/cvsroot/boost/boost/boost/python/suite/indexing/map_indexing_suite.hpp,v
retrieving revision 1.5
diff -u -r1.5 map_indexing_suite.hpp
--- suite/indexing/map_indexing_suite.hpp       4 May 2004 09:41:01 -00001.5
+++ suite/indexing/map_indexing_suite.hpp       4 Jul 2004 07:09:18 -0000
@@ -73,7 +73,9 @@
         {
             //  Wrap the map's element (value_type)
             std::string elem_name = "map_indexing_suite_";
-            elem_name += cl.ptr()->ob_type->tp_name; // the class name
+            object class_name(cl.attr("__name__"));
+            extract<std::string> class_name_extractor(class_name);
+            elem_name += class_name_extractor();
             elem_name += "_entry";
 
             typedef typename mpl::if_<


cl.ptr()->ob_type->tp_name always returns "Boost.Python.class", but
cl.attr("__name__") does the right thing. I've tested the patch on
all our platforms. The only issue I found is that Visual C++ 6.6
issues the infamous "compiler limit : internal structure overflow"
message, but it does so even without the patch.

I've made a second patch for map_indexing_suite.py to verify that the
first patch works as expected:

Index: map_indexing_suite.py
===================================================================
RCS file: /cvsroot/boost/boost/libs/python/test/map_indexing_suite.py,v
retrieving revision 1.2
diff -u -r1.2 map_indexing_suite.py
--- map_indexing_suite.py       26 Aug 2003 13:11:51 -0000      1.2
+++ map_indexing_suite.py       4 Jul 2004 07:17:52 -0000
@@ -5,6 +5,9 @@
 #####################################################################
 
 >>> from map_indexing_suite_ext import *
+>>> assert "map_indexing_suite_IntMap_entry" in dir()
+>>> assert "map_indexing_suite_TestMap_entry" in dir()
+>>> assert "map_indexing_suite_XMap_entry" in dir()
 >>> x = X('hi')
 >>> x
 hi


OK to check this in?

Thanks,
        Ralf



		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail



From caustin at gmail.com  Sun Jul  4 10:02:15 2004
From: caustin at gmail.com (Chad Austin)
Date: Sun, 4 Jul 2004 03:02:15 -0500
Subject: [C++-sig] Python, Boost.Python, and SCons
In-Reply-To: <20040704064138.28360.qmail@web20207.mail.yahoo.com>
References: <20040704064138.28360.qmail@web20207.mail.yahoo.com>
Message-ID: <2096514e040704010267badb5a@mail.gmail.com>

On Sat, 3 Jul 2004 23:41:38 -0700 (PDT), Ralf W. Grosse-Kunstleve
<rwgk at yahoo.com> wrote:
> --- Chad Austin <caustin at gmail.com> wrote:
> > p.s.  Have you tried always using the --implicit-cache option?  That
> > usually works wonders, and very rarely results in an incorrect build.
> 
> Here are the timings if I configure our build system to compile "everything"
> (maybe 150k lines + Boost) and do a "no-op" build (everything up to date) with
> the full implicit dependency scan enabled, and all files on a local disk:
> 
> % time libtbx.scons .
[snip]
> 57.200u 6.450s 1:03.74 99.8%    0+0k 0+0io 1394pf+0w
> % time libtbx.scons --implicit-cache .
[snip]
> 57.600u 6.480s 1:04.21 99.7%    0+0k 0+0io 1394pf+0w

Did you try running with --implicit-cache again?  The first time you
use it, it caches the dependency information of headers.  The second
time, it uses that information to speed up the build.  In short, you
could describe --implicit-cache as adding a test:  "if signature of
header has not changed, then don't scan it: use the previous headers
found."  That gets rid of the scanner pass (although MD5 is still
run).

> And here the same but with the implicit dependency scan disabled for the Boost
> subdirectory, using the CPPFLAGS trick:
> 
> % time libtbx.scons .
> scons: Reading SConscript files ...
> libtbx.scons: implicit dependency scan disabled for directory
> /net/worm/scratch1/rwgk/dist/boost
> Compiling distributed version of phaser
> scons: done reading SConscript files.
> scons: Building targets ...
> scons: `.' is up to date.
> scons: done building targets.
> 15.540u 1.340s 0:17.41 96.9%    0+0k 0+0io 1402pf+0w
> % time libtbx.scons --implicit-cache .
> scons: Reading SConscript files ...
> libtbx.scons: implicit dependency scan disabled for directory
> /net/worm/scratch1/rwgk/dist/boost
> Compiling distributed version of phaser
> scons: done reading SConscript files.
> scons: Building targets ...
> scons: `.' is up to date.
> scons: done building targets.
> 15.350u 1.330s 0:16.88 98.8%    0+0k 0+0io 1402pf+0w
> 
> Four times faster! Cool?

Nice.  Try running with --implicit-cache a few times in a row...  then
we can compare it with your patch.  Of course, with both, you might
get an even bigger speedup.  :)

> --implicit-cache doesn't seem to do anything for me. Am I using this option
> incorrectly?
> 
[snip]
>
> That sounds like a great idea! Why didn't I think of that? :-) It is not quite
> as global as I had in mind initially; one still has to be careful to define the
> paths in all Environment instances. However, our usage pattern has evolved over
> time is to use env.Copy() anyway to get common settings from a basic
> Environment instance. I.e. your idea appears to be a perfect fit. I'd just have
> to add the SCAN_CPP_IGNORE_PATH to our basic environment.

That sounds good.  I've noticed that nearly every SCons build creates
an initial environment and uses env.Copy() to customize it, so it
should be okay.

> Do you have an idea how much is involved in adding the SCAN_CPP_IGNORE_PATH
> feature? Would it be a local patch in the scanner, or does the general
> framework need to be patched in several places to provide the necessary
> support?

I'm pretty sure you would only have to patch the scanner. 
Fortunately, the scanner code is pretty straightforward.  Take a look
at Scanner/__init__.py.  Should be easy to implement using an
environmental variable.  :)

Cheers,
Chad



From dave at boost-consulting.com  Sun Jul  4 18:55:56 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 04 Jul 2004 12:55:56 -0400
Subject: [C++-sig] Re: newbie: need example (call python from c++)
In-Reply-To: <20040704103141.7212.qmail@web53104.mail.yahoo.com> (Peter
	Piehler's message of "Sun, 4 Jul 2004 12:31:41 +0200 (CEST)")
References: <20040704103141.7212.qmail@web53104.mail.yahoo.com>
Message-ID: <ufz8790f7.fsf@boost-consulting.com>

The following message is a courtesy copy of an article
that has been posted to gmane.comp.lib.boost.user as well.

Peter Piehler <ppiehler at yahoo.de> writes:

> Hello,
>
> I use call<void>(pyFunc,arg1,..) to call a python
> function with standard double, int etc.

Please bring Boost.Python questions to the C++-sig:
http://www.boost.org/more/mailing_lists/cplussig

> What must I do to call a function with a c++ object as
> argument?

A standard double is a c++ object.  I presume you mean an instance of
a C++ class.  Just pass it to call and make sure its class has been
wrapped.

> psydocode:
>
> class MyAnimal
> {
>        /*...*/
>        std::string __strName;
>     public:
>        MyAnimal() : __strName("Tux") {}
>        /*...*/
>        std::string getName()
>            { return __strName;}
>        void setName(const std::string &strName)
>            { __strName = strName; }
> };
>
> int main()
> {
>   /*...*/
>   MyAnimal* pTux = new Animal;
>   /*do something with pTux*/
>
>   /*use a python function with pTux*/
>   call<void>(pyFunc1, ?pTux? );

    You can pass pTux or *pTux; that will cuase *pTux to be copied
    into a Python object.  You can pass ptr(pTux) or ref(*pTux); that
    will pass a Python object that only holds *pTux by reference (no
    lifetime management)

>   /*change attributes pTux in pyFunc2*/
>   dog = call<MyAnimal>(pyFunc2, ?pTux?);
>
>   /*if it possible to call by reference?*/
>   call<void>(pyFunc3, ?pTux?);
>   pTux->getName();// return Cat

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com




From rwgk at yahoo.com  Sun Jul  4 19:24:18 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sun, 4 Jul 2004 10:24:18 -0700 (PDT)
Subject: [C++-sig] Python, Boost.Python, and SCons
In-Reply-To: <2096514e040704010267badb5a@mail.gmail.com>
Message-ID: <20040704172419.11823.qmail@web20209.mail.yahoo.com>

--- Chad Austin <caustin at gmail.com> wrote:
> > % time libtbx.scons .
> [snip]
> > 57.200u 6.450s 1:03.74 99.8%    0+0k 0+0io 1394pf+0w
> > % time libtbx.scons --implicit-cache .
> [snip]
> > 57.600u 6.480s 1:04.21 99.7%    0+0k 0+0io 1394pf+0w
> 
> Did you try running with --implicit-cache again?  The first time you
> use it, it caches the dependency information of headers.  The second
> time, it uses that information to speed up the build.  In short, you
> could describe --implicit-cache as adding a test:  "if signature of
> header has not changed, then don't scan it: use the previous headers
> found."  That gets rid of the scanner pass (although MD5 is still
> run).

It doesn't help here running the no-op build four times in a row:

57.900u 6.360s 1:04.30 99.9%    0+0k 0+0io 1394pf+0w
58.290u 6.760s 1:05.34 99.5%    0+0k 0+0io 1394pf+0w
61.580u 6.570s 1:08.22 99.8%    0+0k 0+0io 1394pf+0w
57.450u 6.760s 1:04.27 99.9%    0+0k 0+0io 1394pf+0w


> Nice.  Try running with --implicit-cache a few times in a row...  then
> we can compare it with your patch.  Of course, with both, you might
> get an even bigger speedup.  :)

Similar observation using the CPPFLAGS trick:

15.340u 1.310s 0:16.82 98.9%    0+0k 0+0io 1402pf+0w
15.220u 1.480s 0:16.81 99.3%    0+0k 0+0io 1402pf+0w
15.280u 1.440s 0:16.78 99.6%    0+0k 0+0io 1402pf+0w
15.160u 1.410s 0:16.65 99.5%    0+0k 0+0io 1402pf+0w

Do I have to run something else before using --implicit-cache?
IIRC I also tried --implicit-deps-unchanged and other options at some point in
the past. Nothing made a significant difference.

> I'm pretty sure you would only have to patch the scanner. 
> Fortunately, the scanner code is pretty straightforward.

I know...

> Take a look
> at Scanner/__init__.py.  Should be easy to implement using an
> environmental variable.  :)

OK, I'll put this on my try-again list. :-)

Ralf



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 



From nicodemus at esss.com.br  Sun Jul  4 19:30:19 2004
From: nicodemus at esss.com.br (Nicodemus)
Date: Sun, 04 Jul 2004 14:30:19 -0300
Subject: [C++-sig] Getter/Setter as Property with Pyste
In-Reply-To: <BPEBKLCAPNMHJOAHJOIHIELKCBAA.achim.domma@syynx.de>
References: <BPEBKLCAPNMHJOAHJOIHIELKCBAA.achim.domma@syynx.de>
Message-ID: <40E83EAB.5010801@esss.com.br>

Hi Achim, sorry about the delay,

Achim Domma wrote:

>Hi,
>
>I try to generate Code with Pyste. The wrapped classes have lots of getter
>and setter functions. The generated code looks like this:
>
>.def("borderColor", (void (Magick::Image::*)(const
>Magick::Color&) )&Magick::Image::borderColor)
>.def("borderColor", (Magick::Color (Magick::Image::*)()
>const)&Magick::Image::borderColor)
>
>Is there a simple way to tell Pyste to generate an add_property call for
>'borderColor' instead of the two functions?
>  
>

Right now there is no direct support for that, sorry! 8(

Regards,
Nicodemus.



From caustin at gmail.com  Tue Jul  6 01:58:27 2004
From: caustin at gmail.com (Chad Austin)
Date: Mon, 5 Jul 2004 18:58:27 -0500
Subject: [C++-sig] Python, Boost.Python, and SCons
In-Reply-To: <20040704172419.11823.qmail@web20209.mail.yahoo.com>
References: <20040704172419.11823.qmail@web20209.mail.yahoo.com>
Message-ID: <2096514e0407051658249e0463@mail.gmail.com>

On Sun, 4 Jul 2004 10:24:18 -0700 (PDT), Ralf W. Grosse-Kunstleve
<rwgk at yahoo.com> wrote:
> --- Chad Austin <caustin at gmail.com> wrote:
> > > % time libtbx.scons .
> > [snip]
> > > 57.200u 6.450s 1:03.74 99.8%    0+0k 0+0io 1394pf+0w
> > > % time libtbx.scons --implicit-cache .
> > [snip]
> > > 57.600u 6.480s 1:04.21 99.7%    0+0k 0+0io 1394pf+0w
> >
> > Did you try running with --implicit-cache again?  The first time you
> > use it, it caches the dependency information of headers.  The second
> > time, it uses that information to speed up the build.  In short, you
> > could describe --implicit-cache as adding a test:  "if signature of
> > header has not changed, then don't scan it: use the previous headers
> > found."  That gets rid of the scanner pass (although MD5 is still
> > run).
> 
> It doesn't help here running the no-op build four times in a row:
> 
> 57.900u 6.360s 1:04.30 99.9%    0+0k 0+0io 1394pf+0w
> 58.290u 6.760s 1:05.34 99.5%    0+0k 0+0io 1394pf+0w
> 61.580u 6.570s 1:08.22 99.8%    0+0k 0+0io 1394pf+0w
> 57.450u 6.760s 1:04.27 99.9%    0+0k 0+0io 1394pf+0w

That's surprising.  I'd guess most of the time is spent doing MD5
scans?  Have you tried using timestamps?

> > Nice.  Try running with --implicit-cache a few times in a row...  then
> > we can compare it with your patch.  Of course, with both, you might
> > get an even bigger speedup.  :)
> 
> Similar observation using the CPPFLAGS trick:
> 
> 15.340u 1.310s 0:16.82 98.9%    0+0k 0+0io 1402pf+0w
> 15.220u 1.480s 0:16.81 99.3%    0+0k 0+0io 1402pf+0w
> 15.280u 1.440s 0:16.78 99.6%    0+0k 0+0io 1402pf+0w
> 15.160u 1.410s 0:16.65 99.5%    0+0k 0+0io 1402pf+0w
> 
> Do I have to run something else before using --implicit-cache?
> IIRC I also tried --implicit-deps-unchanged and other options at some point in
> the past. Nothing made a significant difference.

--implicit-cache should work automagically.  If it's not working,
something else is the bottleneck.

> > Take a look
> > at Scanner/__init__.py.  Should be easy to implement using an
> > environmental variable.  :)
> 
> OK, I'll put this on my try-again list. :-)

Sounds good.  :)

Cheers,
Chad


From joel at boost-consulting.com  Tue Jul  6 03:28:28 2004
From: joel at boost-consulting.com (Joel de Guzman)
Date: Tue, 06 Jul 2004 09:28:28 +0800
Subject: [C++-sig] patch for map_indexing_suite.hpp
In-Reply-To: <20040704072326.58622.qmail@web20205.mail.yahoo.com>
References: <20040704072326.58622.qmail@web20205.mail.yahoo.com>
Message-ID: <40EA003C.7030408@boost-consulting.com>

Ralf W. Grosse-Kunstleve wrote:

> Hi Joel,
> 
> I found a minor bug in map_indexing_suite.hpp:


[...]

> OK to check this in?

Sounds good. Thanks!

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


From jeff.holle at verizon.net  Tue Jul  6 07:29:02 2004
From: jeff.holle at verizon.net (Jeffrey Holle)
Date: Tue, 06 Jul 2004 01:29:02 -0400
Subject: [C++-sig] Re: Accessing C++ values from within Python
In-Reply-To: <cc8243$ifa$1@sea.gmane.org>
References: <cbu8sl$jkr$1@sea.gmane.org> <40E26BF7.6070809@verizon.net>
	<cc8243$ifa$1@sea.gmane.org>
Message-ID: <cccdkh$fb4$1@sea.gmane.org>

Sounds like you have not placed your testScript.py file in a "python 
public" directory.

The easiest way to make the python interpreter look in an additional 
place is to add the directory to your PYTHONPATH environement variable.

I understand that its also possible to do this by using the approbriate 
Python C API calls before calling Py_Initialize(), but do not know the 
details yet.

Don't know what to make of the garbage collection stuff.  Sounds like 
your python interpreter isn't healthy....

xin wrote:
> I finally got around to trying to get this to work, as I am unable to 
> get bjam to operate correctly I tried to implement it in my existing code.
> Unfortunately I get problems with the getPythonFunction() function. When 
> I ran it, the application would abort.
> 
> After playing around a bit I ended up with :
> PyObject *getPythonFunction(const char *moduleName, const char 
> *functionName)
> {
>    PyObject *pModule = PyImport_ImportModule((char *)moduleName);
> }
> And I got the error when I ran it:
> Exception exceptions.ImportError: 'No module named testScript.py' in 
> 'garbage collection' ignored
> Fatal Python error: unexpected exception during garbage collection Aborted
> 
> Any comments/suggestions?
> 
> Jeffrey Holle wrote:
> 
>> I'm sending the source of a simple project that does what I believe 
>> you are trying to do.
>>
>> In Main.cpp, note the use of call, and the use of ref within it.
>> The former does all the "magic" of converting C++ objects to/from python.
>> The later causes the C++ object to be passed by reference, allowing 
>> the python script to alter C++ object attributes.
>>
>>
>> xin wrote:
>>
>>> Hi.
>>> I have a setup such as the following:
>>>
>>> class object {
>>> public:
>>>     void doSomthingElse();
>>>     float x;
>>>     float *y;
>>>     Somthing SomePyScript;
>>> };
>>>
>>> int main()
>>> {
>>>     object *array = new object[10]; // size of array is only an example
>>>     for (int i = 0; i < 10; i++)
>>>     {
>>>         array[i].y = new float[array[i]]
>>>         RunPythonScript(array[i]);
>>>     }
>>>     return 1;
>>> }
>>>
>>> Where:
>>>  - " Somting SomePyScript; " Is some reference to a python script 
>>> that is affiliated with this instance of the class (varies from 
>>> instance to instance)
>>>  - " RunPythonScript(array[i]); " Is some method of running the 
>>> python script that is affiliated with the instance array[i].
>>>
>>> My intention is that the python scripts change values within the 
>>> class 'object'
>>> e.g. The python code sets 'x' to equal 0.9. And then sets each value 
>>> of y to equal a muliple of 9. (y[0] = 0, y[1] = 9, y[2] = 18, ... 
>>> ,y[100] = 900 etc...)
>>>
>>> Is this at all possible? Is it possible without moving all the memory 
>>> from one place, to another area accessable by both python and then 
>>> back again? If so how would I go about doing it?
>>>
>>> I've tried all sorts of methods of attempting this, but have had no 
>>> luck. Any help would be appreciated.
>>>
>>> Thanks.
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> C++-sig mailing list
>> C++-sig at python.org
>> http://mail.python.org/mailman/listinfo/c++-sig



From rwgk at yahoo.com  Tue Jul  6 17:43:47 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 6 Jul 2004 08:43:47 -0700 (PDT)
Subject: [C++-sig] Re: compile errors with embedding example from tutorial
In-Reply-To: <40E6F5FC.16639.1263850@localhost>
Message-ID: <20040706154347.51364.qmail@web20202.mail.yahoo.com>

--- Niall Douglas <s_sourceforge at nedprod.com> wrote:
> I'd really like it if Ralf's SConstruct files for Boost came with 
> Boost. Thoughts?

Hi Niall, it is not just one file. You need the "libtbx" (toolbox for building
libraries) and "boost_adaptbx" (adaptor toolbox) from our CVS tree (both
modules are tiny in comparison). I could make a web site like this one:
http://cci.lbl.gov/cctbx_build/, but only with boost, scons libtbx,
boost_adaptbx, and only sources, no binaries, and a simple examples that
demonstrates how to add custom modules and how to build your own
self-extracting installer. I've been thinking about this for a while but
didn't/don't have enough time to do it. :-(

Ralf



	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 


From hoeppler at diener.iap.physik.uni-tuebingen.de  Tue Jul  6 18:30:15 2004
From: hoeppler at diener.iap.physik.uni-tuebingen.de (Chris Hoeppler)
Date: Tue, 6 Jul 2004 18:30:15 +0200 (CEST)
Subject: [C++-sig] Re: Boost.Python in SUSE 9.0 or SUSE 9.1?
In-Reply-To: <20040629215434.65607.qmail@web20212.mail.yahoo.com>
Message-ID: <Pine.LNX.4.33.0407061809460.28792-100000@diener.iap.physik.uni-tuebingen.de>

On Tue, 29 Jun 2004, Ralf W. Grosse-Kunstleve wrote:

> --- David Abrahams <dave at boost-consulting.com> wrote:
> > Chris Hoeppler <hoeppler at diener.iap.physik.uni-tuebingen.de> writes:
> >
> > > FWIW, the compiler is happy with  "catch(exception_cref &e)", though I do
> > > --------------------------------------------------------^
> > > not know whether it would be okay to make that change...
> >
> > Sure; you can do that in your local copy.
>
> David is telling me:
>
> > > Hi David, I think he was asking if we can make that change in the main
> version
> .
> > > I think we should unless you have objections. I can run tests on all our
> > > platforms to make sure it works everywhere. Please let me know.
>
> > Yes, I have objections, at least if you don't make the patch very
> > precise and conditional.  It will break on many compilers.  The
> > add_reference invocation above it should have already added a
> > reference and many compilers (even most GCCs?) will choke on adding a
> > reference to a type that is already a reference.
>
> I.e. what we need is a very specific set of #ifdef's that will apply your patch
> only under SUSE 9, and only if the compiler with SUSE's patches is used.

Hi Ralf,

thanks for the pointers. Unfortunately I was unable to find a macro which
would allow to decide whether the gcc-version used was patched by SuSE. So
I guess, that for the time being I have to (a) install an 'official' gcc
release or (b) apply my patch locally. BTW, a first try with gcc-3.3.4 and
gcc-3.4.0 seemes to indicate that neither minds the added reference.
Should they?

Chris.



From wirawan0 at softhome.net  Tue Jul  6 19:15:59 2004
From: wirawan0 at softhome.net (Wirawan Purwanto)
Date: Tue, 6 Jul 2004 13:15:59 -0400 (EDT)
Subject: [C++-sig] Re: Problem: boost_python 1.31 (release) causes huge
	memory allocation
Message-ID: <Pine.LNX.4.60.0407061309050.2998@wirawan0.lan>

Hi,

Well, the issue has been resolved. The bug turns out to be on my side 
(i.e. in my own code), in the construction stage of the object. That was a 
very subtle bug, which (believe it or not) wasn't exposed until I tried to 
play with boost::python. Anyway, thanks for the help.

>> To get the right compilation/link command lines, build the example
>> projects using bjam -d+2 or just trial-run the build with bjam -n -a
>> and copy those down.  I can't vouch for your bulid being correct otherwise.
>>
>>> QUESTION: Without the .addproperty() stuff (that's commented in the
>>> snippet above), the code runs fine. But when I added the
>>> .addproperty() line, a calamity happens: when I was about to
>>> instantiate HubbardGP object, the computer froze.


>>> But I can't debug the code easily, as it involves running
>>> python itself in the debugger. How do you debug such a problem?
>>
>> I run Python itself in the debugger.  What's so hard about that?

Resolved. I saw again that there was some info in the FAQ.
I have taken another approach, i.e. by embedding the python interpreter 
plus boost::python interface into my code.


[from Greg Landrum]:

> If you run gdb on python itself, you can try setting the breakpoint
> right away, newer versions of gdb will give you a message like this:
> Make breakpoint pending on future shared library load? (y or [n])
> just reply 'y' and everything should work ok.
>
> If you have an older version of gdb,  wait until after your .so has
> been loaded (after you do an import) and then set the breakpoint.

Which version is the GDB that you mean? I'm currently using either GDB 
5.2, 5.3 or 6.0.


Wirawan


From wirawan0 at softhome.net  Tue Jul  6 19:37:41 2004
From: wirawan0 at softhome.net (Wirawan Purwanto)
Date: Tue, 6 Jul 2004 13:37:41 -0400 (EDT)
Subject: [C++-sig] How to wrap reference-returning method as a property?
Message-ID: <Pine.LNX.4.60.0407061316130.2998@wirawan0.lan>

This is a newbie question again. Suppose I have a C++ program like this:

struct Member
{
   int x; // whatever...
};

struct Master
{
protected:
   Member hand_, foot_, head_;
public:
   Member &hand() { return hand_; }
};

Master foo;

You see that the reference returned by hand() has a lifetime defined by 
the Master object. Now I want to wrap this to python:

BOOST_PYTHON_MODULE(MasterModule)
{
     using namespace boost::python;
     class<Master>("Master")
       .add_property("hand", &Master::hand); // wouldn't work
}

That interface wouldn't work since the reference's lifetime wasn't 
known/specified. Is there anyway to fix this problem? I did not see the 
"recipe" to do it in the tutorial. It only deals with regular function 
(see 
http://www.boost.org/libs/python/doc/tutorial/doc/call_policies.html
).

Alternatively I could use .def instead of .add_property. But I'd like to 
use .add_property if I can.


Wirawan


From mike at nospam.com  Tue Jul  6 19:57:13 2004
From: mike at nospam.com (Mike Rovner)
Date: Tue, 6 Jul 2004 10:57:13 -0700
Subject: [C++-sig] Re: How to wrap reference-returning method as a property?
References: <Pine.LNX.4.60.0407061316130.2998@wirawan0.lan>
Message-ID: <ccep5l$ukn$1@sea.gmane.org>

Wirawan Purwanto wrote:

>        .add_property("hand", &Master::hand); // wouldn't work
>
> That interface wouldn't work since the reference's lifetime wasn't
> known/specified. Is there anyway to fix this problem? I did not see

>From BPL FAQ (http://tinyurl.com/24mnc):

.add_property("hand",
      make_function(&Master::hand,
return_value_policy<manage_new_object>()) )

HTH,
Mike







From murrayc at murrayc.com  Tue Jul  6 22:58:40 2004
From: murrayc at murrayc.com (Murray Cumming)
Date: Tue, 06 Jul 2004 22:58:40 +0200
Subject: [C++-sig] Evaluating multiple statements
Message-ID: <1089147520.3233.27.camel@murrayc_debian>

I am trying to evaluate arbitrary sets of python statements from C++.
Because PyRun_String (with Py_eval_input) can only evaluate single
lines, I have found a way to do it by compiling and evaluating each
statement in sequence.

However, this really doesn't look like the best way to do this, and I
don't think it can handle complex constructs, so I'd welcome advice:
http://www.murrayc.com/misc/test_pyembed.cc

-- 
Murray Cumming
murrayc at murrayc.com
www.murrayc.com
www.openismus.com



From dave at boost-consulting.com  Tue Jul  6 21:03:49 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 06 Jul 2004 15:03:49 -0400
Subject: [C++-sig] Re: Boost.Python in SUSE 9.0 or SUSE 9.1?
References: <20040629215434.65607.qmail@web20212.mail.yahoo.com>
	<Pine.LNX.4.33.0407061809460.28792-100000@diener.iap.physik.uni-tuebingen.de>
Message-ID: <ueknpdkkq.fsf@boost-consulting.com>

Chris Hoeppler <hoeppler at diener.iap.physik.uni-tuebingen.de> writes:

> On Tue, 29 Jun 2004, Ralf W. Grosse-Kunstleve wrote:
>
>> --- David Abrahams <dave at boost-consulting.com> wrote:
>> > Chris Hoeppler <hoeppler at diener.iap.physik.uni-tuebingen.de> writes:
>> >
>> > > FWIW, the compiler is happy with  "catch(exception_cref &e)", though I do
>> > > --------------------------------------------------------^
>> > > not know whether it would be okay to make that change...
>> >
>> > Sure; you can do that in your local copy.
>>
>> David is telling me:
>>
>> > > Hi David, I think he was asking if we can make that change in the main
>> version
>> .
>> > > I think we should unless you have objections. I can run tests on all our
>> > > platforms to make sure it works everywhere. Please let me know.
>>
>> > Yes, I have objections, at least if you don't make the patch very
>> > precise and conditional.  It will break on many compilers.  The
>> > add_reference invocation above it should have already added a
>> > reference and many compilers (even most GCCs?) will choke on adding a
>> > reference to a type that is already a reference.
>>
>> I.e. what we need is a very specific set of #ifdef's that will apply your patch
>> only under SUSE 9, and only if the compiler with SUSE's patches is used.
>
> Hi Ralf,
>
> thanks for the pointers. Unfortunately I was unable to find a macro which
> would allow to decide whether the gcc-version used was patched by SuSE. So
> I guess, that for the time being I have to (a) install an 'official' gcc
> release or (b) apply my patch locally. BTW, a first try with gcc-3.3.4 and
> gcc-3.4.0 seemes to indicate that neither minds the added reference.
> Should they?

Not neccessarily.  There's been a DR which says they are legal.
Some earlier GCCs will barf.  If you can satisfy yourself that you're
not going to cause trouble, I'll be happy to accept the patch.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Tue Jul  6 21:05:28 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 06 Jul 2004 15:05:28 -0400
Subject: [C++-sig] Re: How to wrap reference-returning method as a property?
References: <Pine.LNX.4.60.0407061316130.2998@wirawan0.lan>
	<ccep5l$ukn$1@sea.gmane.org>
Message-ID: <u6591dkhz.fsf@boost-consulting.com>

"Mike Rovner" <mike at nospam.com> writes:

> Wirawan Purwanto wrote:
>
>>        .add_property("hand", &Master::hand); // wouldn't work
>>
>> That interface wouldn't work since the reference's lifetime wasn't
>> known/specified. Is there anyway to fix this problem? I did not see
>
>>From BPL FAQ (http://tinyurl.com/24mnc):
>
> .add_property("hand",
>       make_function(&Master::hand,
> return_value_policy<manage_new_object>()) )

Nooo!

Use return_internal_reference!

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From ingo at fargonauten.de  Tue Jul  6 21:45:06 2004
From: ingo at fargonauten.de (Ingo Luetkebohle)
Date: Tue, 06 Jul 2004 21:45:06 +0200
Subject: [C++-sig] Evaluating multiple statements
In-Reply-To: <1089147520.3233.27.camel@murrayc_debian>
References: <1089147520.3233.27.camel@murrayc_debian>
Message-ID: <1089143106.26312.13.camel@localhost>

Hi Murray,

you're using Py_CompileString already and that method can compile whole
modules with Py_file_input.

Say you have
	def fun():
		return 1	

Where 'fun' could of course be arbitrarily complex.  Then you'd do
something like (all error handling and reference counting omitted):

	PyObject* c = Py_CompileString(text, "null", Py_file_input);
	PyObject* module = PyImport_ExecModule("module name", c);
	PyObject* dict = PyModule_GetDict(module);
	PyObject* f = PyDict_GetItemString(dict, "fun");


And you get yourself a callable for "fun" for use with
PyObject_CallObject.

Hope that helps,

-- 
Ingo

Soll doch jeder bleiben, wie er gerne w?re.



From s_sourceforge at nedprod.com  Tue Jul  6 04:15:29 2004
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 06 Jul 2004 03:15:29 +0100
Subject: [C++-sig] Python, Boost.Python, and SCons
In-Reply-To: <2096514e0407051658249e0463@mail.gmail.com>
References: <20040704172419.11823.qmail@web20209.mail.yahoo.com>
Message-ID: <40EA1951.26746.D683BBB@localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 5 Jul 2004 at 18:58, Chad Austin wrote:

> That's surprising.  I'd guess most of the time is spent doing MD5
> scans?  Have you tried using timestamps?

No, a good proportion is spent by scons organising its environment - 
basically shuffling data around. If you run scons with psyco, you'll 
get a *major* improvement when bound here though last time I checked 
there were still issues with psyco.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBQOoLQ8EcvDLFGKbPEQIgiACfYHI9zjJo+LJdbcDhdZ5MxpombYgAoPz8
S0nNIwe9eJ3Oc3fCd2XFBUt5
=S8yo
-----END PGP SIGNATURE-----


From s_sourceforge at nedprod.com  Tue Jul  6 12:39:48 2004
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 06 Jul 2004 11:39:48 +0100
Subject: [C++-sig] Tiny fix to the FAQ please
Message-ID: <40EA8F84.5180.F35F238@localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In the FAQ "How do I handle void * conversion?" a tiny thing needs 
changing. Instead of declaring void_ as struct void_; you should use:

struct void_ {};

This is due to a bug in GCC whereby corrupted typeinfo can be emitted 
for undefined types. Unfortunately it only happens in my 60Mb shared 
object ie; truly massive linking & relocation requirements and thus I 
can't condense down an example for reporting. However, the simple 
trick above works fine.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBQOqBdcEcvDLFGKbPEQKs2gCeJvFDHCTkzRmBmG/xSXEeRL/F3g8AoK/C
snS/4X5pQVWbRFXfMn23BR6C
=y62G
-----END PGP SIGNATURE-----


From hoeppler at diener.iap.physik.uni-tuebingen.de  Tue Jul  6 22:03:30 2004
From: hoeppler at diener.iap.physik.uni-tuebingen.de (Chris Hoeppler)
Date: Tue, 6 Jul 2004 22:03:30 +0200 (CEST)
Subject: [C++-sig] Re: Boost.Python in SUSE 9.0 or SUSE 9.1?
In-Reply-To: <ueknpdkkq.fsf@boost-consulting.com>
Message-ID: <Pine.LNX.4.33.0407062140440.32563-100000@diener.iap.physik.uni-tuebingen.de>

On Tue, 6 Jul 2004, David Abrahams wrote:

> Chris Hoeppler <hoeppler at diener.iap.physik.uni-tuebingen.de> writes:
>
> > On Tue, 29 Jun 2004, Ralf W. Grosse-Kunstleve wrote:
> >
> >> --- David Abrahams <dave at boost-consulting.com> wrote:
> >> > Chris Hoeppler <hoeppler at diener.iap.physik.uni-tuebingen.de> writes:
> >> >
> >> > > FWIW, the compiler is happy with  "catch(exception_cref &e)", though I do
> >> > > --------------------------------------------------------^
> >> > > not know whether it would be okay to make that change...
> >> >
> >> > Sure; you can do that in your local copy.
> >>
> >> David is telling me:
> >>
> >> > > Hi David, I think he was asking if we can make that change in the main
> >> version
> >> .
> >> > > I think we should unless you have objections. I can run tests on all our
> >> > > platforms to make sure it works everywhere. Please let me know.
> >>
> >> > Yes, I have objections, at least if you don't make the patch very
> >> > precise and conditional.  It will break on many compilers.  The
> >> > add_reference invocation above it should have already added a
> >> > reference and many compilers (even most GCCs?) will choke on adding a
> >> > reference to a type that is already a reference.
> >>
> >> I.e. what we need is a very specific set of #ifdef's that will apply your patch
> >> only under SUSE 9, and only if the compiler with SUSE's patches is used.
> >
> > Hi Ralf,
> >
> > thanks for the pointers. Unfortunately I was unable to find a macro which
> > would allow to decide whether the gcc-version used was patched by SuSE. So
> > I guess, that for the time being I have to (a) install an 'official' gcc
> > release or (b) apply my patch locally. BTW, a first try with gcc-3.3.4 and
> > gcc-3.4.0 seemes to indicate that neither minds the added reference.
> > Should they?
>
> Not neccessarily.  There's been a DR which says they are legal.
> Some earlier GCCs will barf.  If you can satisfy yourself that you're
> not going to cause trouble, I'll be happy to accept the patch.

Unfortunately I cannot as you were right in your first post forwarded by
Ralf: GCC considers forming a reference to the reference type `const
error&' an error. My impression that the change was okay was based on the
fact that just compiling the header was possible with the additional
reference. However, trying to instantiate the template, as happens when
libs/python/test/exception_translator is built, results in errors as
follows:

<snip>
../../../libs/python/test/exception_translator.cpp:21:   instantiated from
here
/usr/local/src/boost_1_31_0/boost/python/detail/translate_exception.hpp:38:
error: forming reference to reference type `const error&'
<snip>

I just checked this for gcc-3.3.4 and gcc-3.4.0 (official), and
gcc-3.3.1 (as shipped by SuSE 8.2) So it will have to be non-SuSE gcc's
for the time being...

Sorry for the noise and thanks for the help,
Chris.



From wirawan0 at softhome.net  Tue Jul  6 23:47:02 2004
From: wirawan0 at softhome.net (Wirawan Purwanto)
Date: Tue, 6 Jul 2004 17:47:02 -0400 (EDT)
Subject: [C++-sig] Does boost::python support complex numbers?
In-Reply-To: <20040706200027.5467D1E4018@bag.python.org>
References: <20040706200027.5467D1E4018@bag.python.org>
Message-ID: <Pine.LNX.4.60.0407061741550.2998@wirawan0.lan>

Does boost::python support complex-number arithmetic? Complex numbers 
seems to be natively supported by python itself. If it doesn't, is there 
an ad hoc way for handling that?

Thanks
Wirawan



From rwgk at yahoo.com  Wed Jul  7 00:45:35 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 6 Jul 2004 15:45:35 -0700 (PDT)
Subject: [C++-sig] Tiny fix to the FAQ please
In-Reply-To: <40EA8F84.5180.F35F238@localhost>
Message-ID: <20040706224535.34511.qmail@web20208.mail.yahoo.com>

--- Niall Douglas <s_sourceforge at nedprod.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> In the FAQ "How do I handle void * conversion?" a tiny thing needs 
> changing. Instead of declaring void_ as struct void_; you should use:
> 
> struct void_ {};

OK, I just checked this change in.
Ralf



		
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail


From dave at boost-consulting.com  Wed Jul  7 00:58:35 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 06 Jul 2004 18:58:35 -0400
Subject: [C++-sig] Re: Does boost::python support complex numbers?
References: <20040706200027.5467D1E4018@bag.python.org>
	<Pine.LNX.4.60.0407061741550.2998@wirawan0.lan>
Message-ID: <uvfh0agkk.fsf@boost-consulting.com>

Wirawan Purwanto <wirawan0 at softhome.net> writes:

> Does boost::python support complex-number arithmetic? 

It supports automatic conversions between Python complex numbers and
std::complex<T> where T is float or double.


-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From rwgk at yahoo.com  Wed Jul  7 01:06:25 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 6 Jul 2004 16:06:25 -0700 (PDT)
Subject: [C++-sig] Re: Boost.Python in SUSE 9.0 or SUSE 9.1?
In-Reply-To: <Pine.LNX.4.33.0407061809460.28792-100000@diener.iap.physik.uni-tuebingen.de>
Message-ID: <20040706230625.21389.qmail@web20223.mail.yahoo.com>

--- Chris Hoeppler <hoeppler at diener.iap.physik.uni-tuebingen.de> wrote:
> thanks for the pointers. Unfortunately I was unable to find a macro which
> would allow to decide whether the gcc-version used was patched by SuSE. So
> I guess, that for the time being I have to (a) install an 'official' gcc
> release or (b) apply my patch locally. BTW, a first try with gcc-3.3.4 and
> gcc-3.4.0 seemes to indicate that neither minds the added reference.
> Should they?

That's beyond me...

David, I still think it is not ideal that Boost.Python doesn't work out-of-the
box under SuSE 9.x. What do you think about this plan:

First we verify that the unpatched gcc's don't choke on the added reference. If
that works out we add the reference under a condition like this (reformulated
using BOOST_WORKAROUND):

#if defined(__linux__) && defined(__GNUC__) && __GNUC__ == 3 && __GNUC_MINOR__
== 3 && (__GNUC_PATCHLEVEL__ == 1 || __GNUC_PATCHLEVEL__ == 3) 

Would that be acceptable? I could test with the gcc versions under question
under RedHat.

Ralf



	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 


From rwgk at yahoo.com  Wed Jul  7 01:10:16 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 6 Jul 2004 16:10:16 -0700 (PDT)
Subject: [C++-sig] Re: Boost.Python in SUSE 9.0 or SUSE 9.1?
In-Reply-To: <Pine.LNX.4.33.0407062140440.32563-100000@diener.iap.physik.uni-tuebingen.de>
Message-ID: <20040706231016.69183.qmail@web20203.mail.yahoo.com>

--- Chris Hoeppler <hoeppler at diener.iap.physik.uni-tuebingen.de> wrote:
> I just checked this for gcc-3.3.4 and gcc-3.4.0 (official), and
> gcc-3.3.1 (as shipped by SuSE 8.2) So it will have to be non-SuSE gcc's
> for the time being...

Oh, sorry, I didn't see this before sending the other message a minute ago.
Please disregard the other message.
Ralf



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 


From rwgk at yahoo.com  Wed Jul  7 02:49:46 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 6 Jul 2004 17:49:46 -0700 (PDT)
Subject: [C++-sig] boost/python/slice.hpp
Message-ID: <20040707004946.82071.qmail@web20205.mail.yahoo.com>

Hi Jonathan,

I think I found a typo in the slice.hpp documentation, near the bottom of the
page:

while (bounds.start != bounds.end) {
                              ^^^
                    should be stop instead

Other general feedback (not urgent by any means):

double partial_sum(std::vector<double> const& Foo, slice index)

I tried

double partial_sum(std::vector<double> const& Foo, slice const& index)

but it did not work, which I found surprising.

I couldn't figure out how to get the size of the final array from a slice
instance without looping over all indices. This would be useful for e.g.
std::vector::reserve().

Ralf



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 


From murrayc at murrayc.com  Wed Jul  7 14:00:10 2004
From: murrayc at murrayc.com (Murray Cumming)
Date: Wed, 07 Jul 2004 14:00:10 +0200
Subject: [C++-sig] Evaluating multiple statements
In-Reply-To: <1089143106.26312.13.camel@localhost>
References: <1089147520.3233.27.camel@murrayc_debian>
	<1089143106.26312.13.camel@localhost>
Message-ID: <1089201610.3322.23.camel@murrayc_debian>

On Tue, 2004-07-06 at 21:45 +0200, Ingo Luetkebohle wrote:
> Hi Murray,
> 
> you're using Py_CompileString already and that method can compile whole
> modules with Py_file_input.
> 
> Say you have
> 	def fun():
> 		return 1	
> 
> Where 'fun' could of course be arbitrarily complex.  Then you'd do
> something like (all error handling and reference counting omitted):
> 
> 	PyObject* c = Py_CompileString(text, "null", Py_file_input);
> 	PyObject* module = PyImport_ExecModule("module name", c);
> 	PyObject* dict = PyModule_GetDict(module);
> 	PyObject* f = PyDict_GetItemString(dict, "fun");
> 
> 
> And you get yourself a callable for "fun" for use with
> PyObject_CallObject.

Yes, that's what I ended up doing. I build a function definition from
the supplied statements, execute it so that it's defined, then evaluatea
call to that function. It seems to work really well.

-- 
Murray Cumming
murrayc at murrayc.com
www.murrayc.com
www.openismus.com



From dave at boost-consulting.com  Wed Jul  7 15:25:33 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 07 Jul 2004 09:25:33 -0400
Subject: [C++-sig] Re: Boost.Python in SUSE 9.0 or SUSE 9.1?
References: <Pine.LNX.4.33.0407062140440.32563-100000@diener.iap.physik.uni-tuebingen.de>
	<20040706231016.69183.qmail@web20203.mail.yahoo.com>
Message-ID: <usmc454qa.fsf@boost-consulting.com>

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

> --- Chris Hoeppler <hoeppler at diener.iap.physik.uni-tuebingen.de> wrote:
>> I just checked this for gcc-3.3.4 and gcc-3.4.0 (official), and
>> gcc-3.3.1 (as shipped by SuSE 8.2) So it will have to be non-SuSE gcc's
>> for the time being...
>
> Oh, sorry, I didn't see this before sending the other message a minute ago.
> Please disregard the other message.
> Ralf

Here's what you do.  You use that nasty preprocessor condition to
switch in this code:

  template <class ExceptionType, class Translate>
  struct translate_exception
  {
      typedef typename remove_reference<
                       ^^^^^^^
          typename add_const<ExceptionType>::type
      >::type exception_non_ref;

      inline bool operator()(
          exception_handler const& handler
        , function0<void> const& f
        , typename call_traits<Translate>::param_type translate) const
      {
          try
          {
              return handler(f);
          }
          catch(exception_non_ref& e)
                ^^^^^^^^^^^^^^^^^^                                 
          {
              translate(e);
              return true;
          }
      }
  };

Then you test it thoroughly.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From hoeppler at diener.iap.physik.uni-tuebingen.de  Wed Jul  7 20:19:14 2004
From: hoeppler at diener.iap.physik.uni-tuebingen.de (Chris Hoeppler)
Date: Wed, 7 Jul 2004 20:19:14 +0200 (CEST)
Subject: [C++-sig] Re: Boost.Python in SUSE 9.0 or SUSE 9.1?
In-Reply-To: <usmc454qa.fsf@boost-consulting.com>
Message-ID: <Pine.LNX.4.33.0407071924030.24733-200000@diener.iap.physik.uni-tuebingen.de>

On Wed, 7 Jul 2004, David Abrahams wrote:

> Here's what you do.  You use that nasty preprocessor condition to
> switch in this code:
>
>   template <class ExceptionType, class Translate>
>   struct translate_exception
>   {
>       typedef typename remove_reference<
>                        ^^^^^^^
>           typename add_const<ExceptionType>::type
>       >::type exception_non_ref;
>
>       inline bool operator()(
>           exception_handler const& handler
>         , function0<void> const& f
>         , typename call_traits<Translate>::param_type translate) const
>       {
>           try
>           {
>               return handler(f);
>           }
>           catch(exception_non_ref& e)
>                 ^^^^^^^^^^^^^^^^^^
>           {
>               translate(e);
>               return true;
>           }
>       }
>   };
>
> Then you test it thoroughly.

Thanks for the help. I applied your workaround using BOOST_WORKAROUND as
suggested by Ralf (see enclosed patch how) and successfully ran all the
test in libs/python/test by invoking bjam with no arguments in that
directory on the following two systems:

* SuSE Linux 9.1 with gcc 3.3.3 as shipped by SuSE

* SuSE Linux 9.0 with gcc 3.3.1 as shipped by SuSE

On both systems I used boost_1_31_0 from the boost web-site.

Could somebody with easy access to the official versions of gcc please
test the enclosed patch, as well?

Are there any other tests I could/should run?

Chris.
-------------- next part --------------
Index: translate_exception.hpp
===================================================================
RCS file: /cvsroot/boost/boost/boost/python/detail/translate_exception.hpp,v
retrieving revision 1.3
diff -d -u -r1.3 translate_exception.hpp
--- translate_exception.hpp	23 Nov 2002 22:18:23 -0000	1.3
+++ translate_exception.hpp	7 Jul 2004 17:14:32 -0000
@@ -22,9 +22,19 @@
 template <class ExceptionType, class Translate>
 struct translate_exception
 {
+# if defined(__linux__) && defined(__GNUC__) \
+    && BOOST_WORKAROUND(__GNUC__, == 3) \
+    && BOOST_WORKAROUND(__GNUC_MINOR__, == 3) \
+    && (BOOST_WORKAROUND(__GNUC_PATCHLEVEL__, == 1) \
+        || BOOST_WORKAROUND(__GNUC_PATCHLEVEL__, == 3))
+    typedef typename remove_reference<
+        typename add_const<ExceptionType>::type
+    >::type exception_non_ref;
+# else
     typedef typename add_reference<
         typename add_const<ExceptionType>::type
     >::type exception_cref;
+# endif
     
     inline bool operator()(
         exception_handler const& handler
@@ -35,7 +45,15 @@
         {
             return handler(f);
         }
+# if defined(__linux__) && defined(__GNUC__) \
+    && BOOST_WORKAROUND(__GNUC__, == 3) \
+    && BOOST_WORKAROUND(__GNUC_MINOR__, == 3) \
+    && (BOOST_WORKAROUND(__GNUC_PATCHLEVEL__, == 1) \
+        || BOOST_WORKAROUND(__GNUC_PATCHLEVEL__, == 3))
+        catch(exception_non_ref& e)
+# else
         catch(exception_cref e)
+# endif
         {
             translate(e);
             return true;

From strawman at astraw.com  Wed Jul  7 23:07:10 2004
From: strawman at astraw.com (Andrew Straw)
Date: Wed, 07 Jul 2004 14:07:10 -0700
Subject: [C++-sig] constructing Python objects in C++
Message-ID: <40EC65FE.6010203@astraw.com>

(Thanks much for providing guidance on previous questions. On with a 
simple? newbie question.)

The tutorial (section "Derived Object types") nicely explains that 
class_<T> lets me make a Python object out of a C++ class. 

However, if I've already defined class_<T> once in my 
BOOST_PYTHON_MODULE block, how can I create a Python object of this 
wrapped class elsewhere in the code without the class_<T> block? 

In other words, right now, I'm forced to replicate the class_<T> 
definition in both the BOOST_PYTHON_MODULE block and also whereever I 
want to create a Python object representing an instance of this class.  
Is there a way to avoid such multiple definitions?

(I feel that maybe I'm missing something pretty fundamental...)

Cheers and TIA,
Andrew


From dave at boost-consulting.com  Wed Jul  7 23:27:52 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 07 Jul 2004 17:27:52 -0400
Subject: [C++-sig] Re: constructing Python objects in C++
References: <40EC65FE.6010203@astraw.com>
Message-ID: <ufz83y0br.fsf@boost-consulting.com>

Andrew Straw <strawman at astraw.com> writes:

> (Thanks much for providing guidance on previous questions. On with a
> simple? newbie question.)
>
> The tutorial (section "Derived Object types") nicely explains that
> class_<T> lets me make a Python object out of a C++ class. 
>
> However, if I've already defined class_<T> once in my
> BOOST_PYTHON_MODULE block, how can I create a Python object of this
> wrapped class elsewhere in the code without the class_<T> block? 

Just store the class_ in an object:

     object my_py_class;

     BOOST_PYTHON_MODULE("Foo")
     {
        my_py_class
           = class_<my_cpp_class>("my_py_class")
                 .def(...
                 ;
     }

     void f()
     {
        object my_py_instance = my_py_class();
     }

> (I feel that maybe I'm missing something pretty fundamental...)

[Replicating the class_<> declaration won't work].

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From rwgk at yahoo.com  Thu Jul  8 06:17:34 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 7 Jul 2004 21:17:34 -0700 (PDT)
Subject: [C++-sig] Re: Boost.Python in SUSE 9.0 or SUSE 9.1?
In-Reply-To: <Pine.LNX.4.33.0407071924030.24733-200000@diener.iap.physik.uni-tuebingen.de>
Message-ID: <20040708041734.79503.qmail@web20212.mail.yahoo.com>

--- Chris Hoeppler <hoeppler at diener.iap.physik.uni-tuebingen.de> wrote:
> Thanks for the help. I applied your workaround using BOOST_WORKAROUND as
> suggested by Ralf (see enclosed patch how) and successfully ran all the
> test in libs/python/test by invoking bjam with no arguments in that
> directory on the following two systems:
> 
> * SuSE Linux 9.1 with gcc 3.3.3 as shipped by SuSE
> 
> * SuSE Linux 9.0 with gcc 3.3.1 as shipped by SuSE
> 
> On both systems I used boost_1_31_0 from the boost web-site.
> 
> Could somebody with easy access to the official versions of gcc please
> test the enclosed patch, as well?
> 
> Are there any other tests I could/should run?

Hi Chris,

Thanks for the patch! I've applied it locally and I've tested with gcc 3.3.1
and gcc 3.3.3 under Red Hat 9.0 without finding any difficulties. I've also
tested on a bunch of other platforms. Could you please do a last verification
to make sure my version works for you? Please get this file:

    http://cci.lbl.gov/~rwgk/tmp/boost_2004_07_07_1512.tar.gz

Unpack and run bjam as before. If you can confirm that it works as expected
under SuSE 9.x I'll check the patch into the main version.

Thanks!
        Ralf



		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail


From hoeppler at diener.iap.physik.uni-tuebingen.de  Thu Jul  8 14:37:01 2004
From: hoeppler at diener.iap.physik.uni-tuebingen.de (Chris Hoeppler)
Date: Thu, 8 Jul 2004 14:37:01 +0200 (CEST)
Subject: [C++-sig] Re: Boost.Python in SUSE 9.0 or SUSE 9.1?
In-Reply-To: <20040708041734.79503.qmail@web20212.mail.yahoo.com>
Message-ID: <Pine.LNX.4.33.0407081339020.20336-200000@diener.iap.physik.uni-tuebingen.de>

On Wed, 7 Jul 2004, Ralf W. Grosse-Kunstleve wrote:

> Hi Chris,
>
> Thanks for the patch! I've applied it locally and I've tested with gcc 3.3.1
> and gcc 3.3.3 under Red Hat 9.0 without finding any difficulties. I've also
> tested on a bunch of other platforms. Could you please do a last verification
> to make sure my version works for you? Please get this file:
>
>     http://cci.lbl.gov/~rwgk/tmp/boost_2004_07_07_1512.tar.gz
>
> Unpack and run bjam as before. If you can confirm that it works as expected
> under SuSE 9.x I'll check the patch into the main version.

Hi Ralf,

Thanks for runnung those tests! I got your tarball, unpacked it, and ran
bjam in libs/python/test on
* SuSE Linux 9.1 with gcc 3.3.3 as shipped by SuSE
  Python 2.3.3 as shipped by SuSE
and
* SuSE Linux 9.0 with gcc 3.3.1 as shipped by SuSE
  Python 2.3.3 from www.python.org
as before.

Results :

...failed updating 2 targets...
...skipped 1 target...
...updated 492 targets...

Failures:

(1) ...failed gcc-Link-action ../../../bin/boost/libs/python/test/select_arg_to_python_test.test/gcc/debug/threading-multi/select_arg_to_python_test...
(2) ...failed gcc-C++-action ../../../bin/boost/libs/python/test/embedding.test/gcc/debug/threading-multi/embedding.o...
(2b)...skipped <@boost!libs!python!test/embedding.test/gcc/debug/threading-multi>embedding for lack of <@boost!libs!python!test/embedding.test/gcc/debug/threading-multi>embedding.o...

I guess these failures are not related to the patch, without which the
results after a bjam clean; bjam invocation are as indicated below.
I am enclosing the detailed error messages for the failures with patch, so
you could have a look at them.

HTH and thanks,

   Chris.


Results for tests without patch:

...failed updating 9 targets...
...skipped 8 targets...
...updated 179 targets...

Failures:
...failed gcc-C++-action ../../../bin/boost/libs/python/test/ben_scott1_ext.so/gcc/debug/shared-linkable-true/ben_scott1.o...
...skipped <@boost!libs!python!test/ben_scott1_ext.so/gcc/debug/shared-linkable-true>ben_scott1_ext.so for lack of <@boost!libs!python!test/ben_scott1_ext.so/gcc/debug/shared-linkable-true>ben_scott1.o...
...failed gcc-C++-action ../../../bin/boost/libs/python/test/slice_ext.so/gcc/debug/shared-linkable-true/slice.o...
...skipped <@boost!libs!python!test/slice_ext.so/gcc/debug/shared-linkable-true>slice_ext.so for lack of <@boost!libs!python!test/slice_ext.so/gcc/debug/shared-linkable-true>slice.o...
...failed gcc-C++-action ../../../bin/boost/libs/python/test/keywords.so/gcc/debug/shared-linkable-true/keywords.o...
...skipped <@boost!libs!python!test/keywords.so/gcc/debug/shared-linkable-true>keywords.so for lack of <@boost!libs!python!test/keywords.so/gcc/debug/shared-linkable-true>keywords.o...
...failed gcc-C++-action ../../../bin/boost/libs/python/test/exception_translator_ext.so/gcc/debug/shared-linkable-true/exception_translator.o...
...skipped <@boost!libs!python!test/exception_translator_ext.so/gcc/debug/shared-linkable-true>exception_translator_ext.so for lack of <@boost!libs!python!test/exception_translator_ext.so/gcc/debug/shared-linkable-true>exception_translator.o...
...failed gcc-C++-action ../../../bin/boost/libs/python/test/properties_ext.so/gcc/debug/shared-linkable-true/properties.o...
...skipped <@boost!libs!python!test/properties_ext.so/gcc/debug/shared-linkable-true>properties_ext.so for lack of <@boost!libs!python!test/properties_ext.so/gcc/debug/shared-linkable-true>properties.o...
...failed gcc-C++-action ../../../bin/boost/libs/python/test/crossmod_exception_a.so/gcc/debug/shared-linkable-true/crossmod_exception_a.o...
...skipped <@boost!libs!python!test/crossmod_exception_a.so/gcc/debug/shared-linkable-true>crossmod_exception_a.so for lack of <@boost!libs!python!test/crossmod_exception_a.so/gcc/debug/shared-linkable-true>crossmod_exception_a.o...
...failed gcc-C++-action ../../../bin/boost/libs/python/test/crossmod_exception_b.so/gcc/debug/shared-linkable-true/crossmod_exception_b.o...
...skipped <@boost!libs!python!test/crossmod_exception_b.so/gcc/debug/shared-linkable-true>crossmod_exception_b.so for lack of <@boost!libs!python!test/crossmod_exception_b.so/gcc/debug/shared-linkable-true>crossmod_exception_b.o...
...failed gcc-Link-action ../../../bin/boost/libs/python/test/select_arg_to_python_test.test/gcc/debug/threading-multi/select_arg_to_python_test...
...failed gcc-C++-action ../../../bin/boost/libs/python/test/embedding.test/gcc/debug/threading-multi/embedding.o...
...skipped <@boost!libs!python!test/embedding.test/gcc/debug/threading-multi>embedding for lack of <@boost!libs!python!test/embedding.test/gcc/debug/threading-multi>embedding.o...

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: suse-9.1-failures.txt
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20040708/ceef43a4/attachment.txt>

From mimler at usf.uni-kassel.de  Thu Jul  8 17:21:03 2004
From: mimler at usf.uni-kassel.de (Matthias Mimler)
Date: Thu, 08 Jul 2004 17:21:03 +0200
Subject: [C++-sig] Problems building boost.python (Spawn: permission denied)
Message-ID: <40ED665F.7060802@usf.uni-kassel.de>

Hi everybody,

I am new to boost.python and currently working throught the tutorial. 
However, when building the tutorial example (Using boost.jam with MS 
VC6.0), the build process is soon terminated with the message:

spawn: permission denied

Here is how I start the build:

set PYTHON_ROOT=c:\Python23
set PYTHON_VERSION=2.3
bjam "-sTOOLS=msvc"

and here is what I get:

...patience...
...found 1977 targets...
...updating 41 targets...
MkDir1 ..\..\..\..\bin
spawn: Permission denied

Can anybody help me?

Thanks,
Matthias



From jbrandmeyer at earthlink.net  Thu Jul  8 18:32:41 2004
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Thu, 08 Jul 2004 12:32:41 -0400
Subject: [C++-sig] boost/python/slice.hpp
In-Reply-To: <20040707004946.82071.qmail@web20205.mail.yahoo.com>
References: <20040707004946.82071.qmail@web20205.mail.yahoo.com>
Message-ID: <1089304360.12502.20.camel@illuvatar>

On Tue, 2004-07-06 at 20:49, Ralf W. Grosse-Kunstleve wrote:
> Other general feedback (not urgent by any means):
> 
> double partial_sum(std::vector<double> const& Foo, slice index)
> 
> I tried
> 
> double partial_sum(std::vector<double> const& Foo, slice const& index)
> 
> but it did not work, which I found surprising.

That's because the start() stop() and step() member functions (and, by
extension, get_indicies()) were not const.  They should be and I will
make that change.

> I couldn't figure out how to get the size of the final array from a slice
> instance without looping over all indices. This would be useful for e.g.
> std::vector::reserve().

Since ret.stop is guaranteed to be a multiple of ret.step away from
ret.start, this statement should get it for you (the signs also work out
in the reverse case):

int size = (ret.stop - ret.start) / ret.step;

HTH,
-Jonathan



From jbrandmeyer at earthlink.net  Thu Jul  8 18:58:54 2004
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Thu, 08 Jul 2004 12:58:54 -0400
Subject: [C++-sig] boost/python/slice.hpp
In-Reply-To: <1089304360.12502.20.camel@illuvatar>
References: <20040707004946.82071.qmail@web20205.mail.yahoo.com>
	<1089304360.12502.20.camel@illuvatar>
Message-ID: <1089305934.12502.23.camel@illuvatar>

On Thu, 2004-07-08 at 12:32, Jonathan Brandmeyer wrote:
> Since ret.stop is guaranteed to be a multiple of ret.step away from
> ret.start, this statement should get it for you (the signs also work out
> in the reverse case):
> 
> int size = (ret.stop - ret.start) / ret.step;

And since it is an inclusive range, make that:
int size = (ret.stop - ret.start) / ret.step + 1;

-Jonathan




From rwgk at yahoo.com  Thu Jul  8 19:06:30 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 8 Jul 2004 10:06:30 -0700 (PDT)
Subject: [C++-sig] boost/python/slice.hpp
In-Reply-To: <1089305934.12502.23.camel@illuvatar>
Message-ID: <20040708170630.51233.qmail@web20210.mail.yahoo.com>

--- Jonathan Brandmeyer <jbrandmeyer at earthlink.net> wrote:
> On Thu, 2004-07-08 at 12:32, Jonathan Brandmeyer wrote:
> > Since ret.stop is guaranteed to be a multiple of ret.step away from
> > ret.start, this statement should get it for you (the signs also work out
> > in the reverse case):
> > 
> > int size = (ret.stop - ret.start) / ret.step;
> 
> And since it is an inclusive range, make that:
> int size = (ret.stop - ret.start) / ret.step + 1;

I think this would make a very useful member function.
Ralf



	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 


From jbrandmeyer at earthlink.net  Thu Jul  8 19:21:53 2004
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Thu, 08 Jul 2004 13:21:53 -0400
Subject: [C++-sig] boost/python/slice.hpp
In-Reply-To: <20040708170630.51233.qmail@web20210.mail.yahoo.com>
References: <20040708170630.51233.qmail@web20210.mail.yahoo.com>
Message-ID: <1089307312.12502.29.camel@illuvatar>

On Thu, 2004-07-08 at 13:06, Ralf W. Grosse-Kunstleve wrote:
> --- Jonathan Brandmeyer <jbrandmeyer at earthlink.net> wrote:
> > On Thu, 2004-07-08 at 12:32, Jonathan Brandmeyer wrote:
> > > Since ret.stop is guaranteed to be a multiple of ret.step away from
> > > ret.start, this statement should get it for you (the signs also work out
> > > in the reverse case):
> > > 
> > > int size = (ret.stop - ret.start) / ret.step;
> > 
> > And since it is an inclusive range, make that:
> > int size = (ret.stop - ret.start) / ret.step + 1;
> 
> I think this would make a very useful member function.
> Ralf

Due to the possibilities from negative and PyNone values in a slice, the
only place that you can reliably compute it is in get_indicies().  It
would be added to the returned struct.

-Jonathan



From dleary at gmail.com  Thu Jul  8 23:31:43 2004
From: dleary at gmail.com (Dusty Leary)
Date: Thu, 8 Jul 2004 17:31:43 -0400
Subject: [C++-sig] Re: implicitly_convertible and char*
In-Reply-To: <81c509c040703112342091c2c@mail.gmail.com>
References: <81c509c040629130556f7312d@mail.gmail.com>
	<20040629205654.59109.qmail@web20212.mail.yahoo.com>
	<uu0wtoonw.fsf@boost-consulting.com>
	<81c509c04070308535c33b72e@mail.gmail.com>
	<uoemxar80.fsf@boost-consulting.com>
	<81c509c040703112342091c2c@mail.gmail.com>
Message-ID: <81c509c04070814314930b7ad@mail.gmail.com>

I guess I'm being a pain, but I still have my same problem.

To recap:

I write saying that implicitly_convertible<X, char*> doesn't work.
Dave responds saying that char* is not a valid C++ string, that char
const * should work.
I amend my example to show that char const * does not work.
Thread gets a little sidetracked with "const char*" vs "char const *"
...Limbo




On Sat, 3 Jul 2004 14:23:07 -0400, Dusty Leary <dleary at gmail.com> wrote:
> yeah, that was an unrelated side note that someone else brought up...
> the issue is that implicity_convertible<X, const char*> is not working
> 
> On Sat, 03 Jul 2004 14:19:27 -0400, David Abrahams
> 
> 
> <dave at boost-consulting.com> wrote:
> > Dusty Leary <dleary at gmail.com> writes:
> >
> > > so, any news on this?
> >
> > What news grould there be?  char const* and const char* are the same
> > thing, so trying it won't make any difference.
> >
> >
> >
> > > On Tue, 29 Jun 2004 20:49:39 -0400, David Abrahams
> > > <dave at boost-consulting.com> wrote:
> > >> "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:
> > >>
> > >> > I don't really feel competent in this matter, but I believe char const* and
> > >> > const char* are two different things. Did you try it with "const char*"?
> > >>
> > >> They are the same thing.
> >
> > --
> > Dave Abrahams
> > Boost Consulting
> > http://www.boost-consulting.com
> >
> > _______________________________________________
> > C++-sig mailing list
> > C++-sig at python.org
> > http://mail.python.org/mailman/listinfo/c++-sig
> >
>


From s_sourceforge at nedprod.com  Fri Jul  9 02:54:06 2004
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 09 Jul 2004 01:54:06 +0100
Subject: [C++-sig] Multiple typeinfos causing failure of exception catches
Message-ID: <40EDFABE.21427.1C90CEAC@localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've been having major problems with getting exceptions to traverse 
shared object boundaries with Boost.Python using GCC and Linux. There 
is a core SO called libTnFOX-0.80.so which is linked against by 
TnFOX.so, the BPL extension and these are linked into TestEmbedPython 
which is an executable.

Now when python has an exception, I have it translate it into a C++ 
exception which it throws. In theory, TnFOX.so should throw a 
FXPythonException instance which in theory gets caught in 
TestEmbedPython. All is good under Win32, but on GCC & Linux you get 
"uncaught exception" and a terminate(). I have examined the dynamic 
symbol table in each binary and a typeinfo for FXPythonException 
appears in TnFOX.so and TestEmbedPython.

I did some searching and found:

http://gcc.gnu.org/ml/gcc/2002-05/msg00995.html

This problem reported by Dave in 2002 is due to a typeinfo for the 
exception type being emitted in each object it is used within. As 
they are marked weak, they get coalesced into a single typeinfo *per* 
*shared* *object* but these happily clash when multiple shared 
objects are loaded.

This then causes typeinfo comparisons to fail not because the mangled 
symbol is different but because the addresses of each are different. 
Dave suggested a typeinfo comparison by string and AFAICS it was 
refused on grounds of speed (despite that comparing hashes is the 
same speed as comparing addresses).

Dave - was this problem ever fixed? If not, I will submit a patch 
implementing typeinfo comparison by string comparison and we'll swing 
round the roundabout once again (maybe two years of experience has 
changed opinions).

BTW, your problem with python having to load extension modules with 
RTDL_LOCAL rather than RTDL_GLOBAL goes away if you use my -
fvisibility=hidden patch as no symbol clashes can happen.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBQO3srsEcvDLFGKbPEQK7agCgsh+QzdJcz3DfHmnl9GatHlfkKY4AoMop
ymYKrY1os+JdgM5h7EG7BE/a
=N651
-----END PGP SIGNATURE-----


From rwgk at yahoo.com  Fri Jul  9 06:24:31 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 8 Jul 2004 21:24:31 -0700 (PDT)
Subject: [C++-sig] Multiple typeinfos causing failure of exception catches
In-Reply-To: <40EDFABE.21427.1C90CEAC@localhost>
Message-ID: <20040709042431.56160.qmail@web20224.mail.yahoo.com>

--- Niall Douglas <s_sourceforge at nedprod.com> wrote:
> BTW, your problem with python having to load extension modules with 
> RTDL_LOCAL rather than RTDL_GLOBAL goes away if you use my -
> fvisibility=hidden patch as no symbol clashes can happen.

Hi Niall,

I don't use embedding, so I am not sure this is relevant, but ever since I
started importing all extension modules with RTLD_GLOBAL under Linux I've not
observed exception handling problems anymore. I.e. I am doing the exact
opposite of what I understand you are suggesting above. Here is my trick,
the "import_ext" function:

   
http://cvs.sourceforge.net/viewcvs.py/cctbx/boost_adaptbx/boost/python.py?view=markup

Does it make sense to you that this approach seems to fix the EH problems? (Or
am I just lucky? Hope not.)

Ralf



		
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail


From rwgk at yahoo.com  Fri Jul  9 07:12:48 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 8 Jul 2004 22:12:48 -0700 (PDT)
Subject: [C++-sig] Re: Boost.Python in SUSE 9.0 or SUSE 9.1?
In-Reply-To: <Pine.LNX.4.33.0407081339020.20336-200000@diener.iap.physik.uni-tuebingen.de>
Message-ID: <20040709051248.83177.qmail@web20228.mail.yahoo.com>

--- Chris Hoeppler <hoeppler at diener.iap.physik.uni-tuebingen.de> wrote:
> Thanks for runnung those tests! I got your tarball, unpacked it, and ran
> bjam in libs/python/test on
> * SuSE Linux 9.1 with gcc 3.3.3 as shipped by SuSE
>   Python 2.3.3 as shipped by SuSE
> and
> * SuSE Linux 9.0 with gcc 3.3.1 as shipped by SuSE
>   Python 2.3.3 from www.python.org
> as before.
> 
> Results :
> 
> ...failed updating 2 targets...
> ...skipped 1 target...
> ...updated 492 targets...

The exact same failures are reported under Red Hat 8.0 with gcc 3.2, a
configuration which is definitely not affected by the patch. I.e. the failures
must be unrelated. Your patch is in CVS now.

If you get a chance could you do me a little favor and try this under SuSE 9.x?

mkdir /var/tmp/junk
cd /var/tmp/junk
wget http://cci.lbl.gov/cctbx_build/results/2004_07_08_1744/cctbx_bundle.selfx
perl cctbx_bundle.selfx

The last command will prompt you for the number of available CPU's and then
start building Boost.Python and a large number of extension modules. I am just
interested to know if it goes through without errors (it does so on at least 13
other platforms).
To remove all traces of the test simply rm -rf /var/tmp/junk.
It will take about 1 CPU hour for everything to compile so you might want to
start the build before you go home. Please disregard my request without comment
if there are any issues.

Thanks,
        Ralf



		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail


From k.dejong at geog.uu.nl  Fri Jul  9 10:24:48 2004
From: k.dejong at geog.uu.nl (Kor de Jong)
Date: Fri, 09 Jul 2004 10:24:48 +0200
Subject: [C++-sig] Free function returning reference
Message-ID: <40EE5650.4050401@geog.uu.nl>

Hi all,

I have some difficulties wrapping free functions which return a
reference (or a pointer) to static variables:

struct Foo {
};

static Foo d_foo;

void setValue(Foo const& value) {
   d_foo = value;
}

Foo const& value() {
   return d_foo;
}

using namespace boost::python;

BOOST_PYTHON_MODULE(foopy) {
   class_<Foo>("Foo")
     ;
   def("setValue", &setValue);
   def("value", &value, return_internal_reference<>());
}

I use the return_internal_reference call policy because I don't
want a copy to be created when value() is called. The first template
argument of return_internal_reference is the owner_arg. According to
the documentation: "If used to wrap a member function, parameter 1 is
the target object (*this)."

But how about wrapping free functions returning references or pointers to
static objects? I would like the Python variables recieving the references
or pointers to be able to use the object but they should not worry about
memory management in this case.

I wonder how the Boost.Python code above should be changed
to get it right. When using the wrapped library from Python a
"python::with_custodian_and_ward_postcall: argument index out of range"
exceptions is thrown when value() is called:

from foopy import *
foo = Foo()
setValue(foo)
value()

(I appologize if I missed something obvious in the manual.)

Best regards,
Kor



From k.dejong at geog.uu.nl  Fri Jul  9 10:42:08 2004
From: k.dejong at geog.uu.nl (Kor de Jong)
Date: Fri, 09 Jul 2004 10:42:08 +0200
Subject: [C++-sig] Free function returning reference
In-Reply-To: <40EE5650.4050401@geog.uu.nl>
References: <40EE5650.4050401@geog.uu.nl>
Message-ID: <40EE5A60.4090001@geog.uu.nl>

Kor de Jong wrote:
> BOOST_PYTHON_MODULE(foopy) {
>   class_<Foo>("Foo")
>     ;
>   def("setValue", &setValue);
>   def("value", &value, return_internal_reference<>());
> }

I guess I should use reference_existing_object:

BOOST_PYTHON_MODULE(foopy)
{
   class_<Foo>("Foo")
     ;
   def("setValue", &setValue);
   def("value", &value, return_value_policy<reference_existing_object>());
}

Please tell me if I am wrong (I still get a Segmentation fault which could be 
related to this).

Kor



From hoeppler at diener.iap.physik.uni-tuebingen.de  Fri Jul  9 14:31:35 2004
From: hoeppler at diener.iap.physik.uni-tuebingen.de (Chris Hoeppler)
Date: Fri, 9 Jul 2004 14:31:35 +0200 (CEST)
Subject: [C++-sig] Re: Boost.Python in SUSE 9.0 or SUSE 9.1?
In-Reply-To: <20040709051248.83177.qmail@web20228.mail.yahoo.com>
Message-ID: <Pine.LNX.4.33.0407091415520.17204-100000@diener.iap.physik.uni-tuebingen.de>

On Thu, 8 Jul 2004, Ralf W. Grosse-Kunstleve wrote:

> The exact same failures are reported under Red Hat 8.0 with gcc 3.2, a
> configuration which is definitely not affected by the patch. I.e. the failures
> must be unrelated. Your patch is in CVS now.

Great. Thanks!

> If you get a chance could you do me a little favor and try this under SuSE 9.x?
>
> mkdir /var/tmp/junk
> cd /var/tmp/junk
> wget http://cci.lbl.gov/cctbx_build/results/2004_07_08_1744/cctbx_bundle.selfx
> perl cctbx_bundle.selfx
>
> The last command will prompt you for the number of available CPU's and then
> start building Boost.Python and a large number of extension modules. I am just
> interested to know if it goes through without errors (it does so on at least 13
> other platforms).

I built your bundle on both SuSE 9.0 and SuSE 9.1. The build ends with
running a selected test followed by instructions on how to use the
installation in a new shell or process. This presumably indicates that no
errrors occured. :-)

Chris.




From dave at boost-consulting.com  Fri Jul  9 14:32:51 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 09 Jul 2004 08:32:51 -0400
Subject: [C++-sig] Re: Problems building boost.python (Spawn: permission
	denied)
References: <40ED665F.7060802@usf.uni-kassel.de>
Message-ID: <uy8ltnyx8.fsf@boost-consulting.com>

Matthias Mimler <mimler at usf.uni-kassel.de> writes:

> Hi everybody,
>
> I am new to boost.python and currently working throught the
> tutorial. However, when building the tutorial example (Using boost.jam
> with MS VC6.0), the build process is soon terminated with the message:
>
> spawn: permission denied
>
> Here is how I start the build:
>
> set PYTHON_ROOT=c:\Python23
> set PYTHON_VERSION=2.3
> bjam "-sTOOLS=msvc"
>
> and here is what I get:
>
> ...patience...
> ...found 1977 targets...
> ...updating 41 targets...
> MkDir1 ..\..\..\..\bin
> spawn: Permission denied
>
> Can anybody help me?

Are you using a regular windows command shell?  If not, please do.  If
you are, please invoke bjam this way:

  bjam -d+2 -d+4 "-sTOOLS=msvc"

and post the output.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Fri Jul  9 14:38:35 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 09 Jul 2004 08:38:35 -0400
Subject: [C++-sig] Re: implicitly_convertible and char*
References: <81c509c040629130556f7312d@mail.gmail.com>
	<20040629205654.59109.qmail@web20212.mail.yahoo.com>
	<uu0wtoonw.fsf@boost-consulting.com>
	<81c509c04070308535c33b72e@mail.gmail.com>
	<uoemxar80.fsf@boost-consulting.com>
	<81c509c040703112342091c2c@mail.gmail.com>
	<81c509c04070814314930b7ad@mail.gmail.com>
Message-ID: <uhdshnyno.fsf@boost-consulting.com>

Dusty Leary <dleary at gmail.com> writes:

> I guess I'm being a pain, but I still have my same problem.
>
> To recap:
>
> I write saying that implicitly_convertible<X, char*> doesn't work.
> Dave responds saying that char* is not a valid C++ string, that char
> const * should work.
> I amend my example to show that char const * does not work.
> Thread gets a little sidetracked with "const char*" vs "char const *"
> ...Limbo

Sorry, I just don't think I have time to look into the problem right
now :(

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Fri Jul  9 14:37:50 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 09 Jul 2004 08:37:50 -0400
Subject: [C++-sig] Re: Boost.Python in SUSE 9.0 or SUSE 9.1?
References: <Pine.LNX.4.33.0407081339020.20336-200000@diener.iap.physik.uni-tuebingen.de>
	<20040709051248.83177.qmail@web20228.mail.yahoo.com>
Message-ID: <un029nyox.fsf@boost-consulting.com>

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

> The exact same failures are reported under Red Hat 8.0 with gcc 3.2, a
> configuration which is definitely not affected by the patch. I.e. the failures
> must be unrelated. Your patch is in CVS now.

I find these failures disturbing.  Anyone have a clue?

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Fri Jul  9 14:39:03 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 09 Jul 2004 08:39:03 -0400
Subject: [C++-sig] Re: Free function returning reference
References: <40EE5650.4050401@geog.uu.nl> <40EE5A60.4090001@geog.uu.nl>
Message-ID: <ubripnymw.fsf@boost-consulting.com>

Kor de Jong <k.dejong at geog.uu.nl> writes:

> I guess I should use reference_existing_object:

That's right.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Fri Jul  9 14:36:56 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 09 Jul 2004 08:36:56 -0400
Subject: [C++-sig] Re: Multiple typeinfos causing failure of exception
	catches
References: <40EDFABE.21427.1C90CEAC@localhost>
Message-ID: <usmc1nyqf.fsf@boost-consulting.com>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> I've been having major problems with getting exceptions to traverse 
> shared object boundaries with Boost.Python using GCC and Linux. There 
> is a core SO called libTnFOX-0.80.so which is linked against by 
> TnFOX.so, the BPL extension and these are linked into TestEmbedPython 
> which is an executable.
>
> Now when python has an exception, I have it translate it into a C++ 
> exception which it throws. In theory, TnFOX.so should throw a 
> FXPythonException instance which in theory gets caught in 
> TestEmbedPython. All is good under Win32, but on GCC & Linux you get 
> "uncaught exception" and a terminate(). I have examined the dynamic 
> symbol table in each binary and a typeinfo for FXPythonException 
> appears in TnFOX.so and TestEmbedPython.
>
> I did some searching and found:
>
> http://gcc.gnu.org/ml/gcc/2002-05/msg00995.html
>
> This problem reported by Dave in 2002 is due to a typeinfo for the 
> exception type being emitted in each object it is used within. As 
> they are marked weak, they get coalesced into a single typeinfo *per* 
> *shared* *object* but these happily clash when multiple shared 
> objects are loaded.
>
> This then causes typeinfo comparisons to fail not because the mangled 
> symbol is different but because the addresses of each are different. 
> Dave suggested a typeinfo comparison by string and AFAICS it was 
> refused on grounds of speed (despite that comparing hashes is the 
> same speed as comparing addresses).
>
> Dave - was this problem ever fixed? 

Not AFAIK.

> If not, I will submit a patch 
> implementing typeinfo comparison by string comparison and we'll swing 
> round the roundabout once again (maybe two years of experience has 
> changed opinions).

There's a better fix that involves dealing differently with the way
the ELF loader resolves weak symbols.  You might ask Jason Merrill
(cc:'d here) about the idea - it was his.

> BTW, your problem with python having to load extension modules with 
> RTDL_LOCAL rather than RTDL_GLOBAL goes away if you use my -
> fvisibility=hidden patch as no symbol clashes can happen.

I don't think so; you can still have symbol clashes if two extension
modules explicitly export the same names.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From rwgk at yahoo.com  Fri Jul  9 17:20:05 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 9 Jul 2004 08:20:05 -0700 (PDT)
Subject: [C++-sig] Re: Boost.Python in SUSE 9.0 or SUSE 9.1?
In-Reply-To: <Pine.LNX.4.33.0407091415520.17204-100000@diener.iap.physik.uni-tuebingen.de>
Message-ID: <20040709152005.78986.qmail@web20221.mail.yahoo.com>

--- Chris Hoeppler <hoeppler at diener.iap.physik.uni-tuebingen.de> wrote:
> I built your bundle on both SuSE 9.0 and SuSE 9.1. The build ends with
> running a selected test followed by instructions on how to use the
> installation in a new shell or process. This presumably indicates that no
> errrors occured. :-)

Yes! Thank you very much for trying this out. Just two days ago one of our
users got stomped by the SuSE gcc problem. I am very glad we have a workaround
now. Thanks for your persistence!
Ralf



		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail


From rwgk at yahoo.com  Fri Jul  9 17:37:01 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 9 Jul 2004 08:37:01 -0700 (PDT)
Subject: [C++-sig] Re: implicitly_convertible and char*
In-Reply-To: <uhdshnyno.fsf@boost-consulting.com>
Message-ID: <20040709153701.98721.qmail@web20223.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> > I write saying that implicitly_convertible<X, char*> doesn't work.
> > Dave responds saying that char* is not a valid C++ string, that char
> > const * should work.
> > I amend my example to show that char const * does not work.
> > Thread gets a little sidetracked with "const char*" vs "char const *"
> > ...Limbo
> 
> Sorry, I just don't think I have time to look into the problem right
> now :(

In that case I'd work around the problem in one of these ways:

- create "thin wrapper" functions. I.e. make standalone function with X const&
or X& as the first parameter, and .def() them as member function. You can find
several examples of thin wrappers in this short piece of code:

 
http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/stl/set_wrapper.h?view=markup

- if that is impractical due to the large number of functions that you might
have to wrap, write your own "custom from python converter" which you could use
to convert any Python object to X. Here is an example:

 
http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/boost_python/slice_ext.cpp?view=markup

  Look for "slice_from_python". It is probably not easy to grasp although it is
not much code, but understanding this approach will give you access to a very
^H^H^H^Hextremely powerful tool.

Ralf



		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail


From s_sourceforge at nedprod.com  Fri Jul  9 20:21:54 2004
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 09 Jul 2004 19:21:54 +0100
Subject: [C++-sig] Multiple typeinfos causing failure of exception catches
In-Reply-To: <20040709042431.56160.qmail@web20224.mail.yahoo.com>
References: <40EDFABE.21427.1C90CEAC@localhost>
Message-ID: <40EEF052.6773.205018AD@localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8 Jul 2004 at 21:24, Ralf W. Grosse-Kunstleve wrote:

> --- Niall Douglas <s_sourceforge at nedprod.com> wrote:
> > BTW, your problem with python having to load extension modules with
> > RTDL_LOCAL rather than RTDL_GLOBAL goes away if you use my -
> > fvisibility=hidden patch as no symbol clashes can happen.
> 
> Hi Niall,
> 
> I don't use embedding, so I am not sure this is relevant, but ever
> since I started importing all extension modules with RTLD_GLOBAL under
> Linux I've not observed exception handling problems anymore. I.e. I am
> doing the exact opposite of what I understand you are suggesting
> above. Here is my trick, the "import_ext" function:

Just to clarify, Dave in his original post said that Python needed to 
use RTLD_LOCAL to prevent symbols in multiple extension modules from 
clashing. This however comes with many downsides, including breaking 
static variables and loads of other bad things. I was suggesting that 
if you use -fvisibility=hidden then no symbols are exported from any 
extension modules at all (apart from the minimum which you will 
ensure are unique) so Python can use RTLD_GLOBAL again which solves 
many other problems.

> http://cvs.sourceforge.net/viewcvs.py/cctbx/boost_adaptbx/boost/python
> .py?view=markup
> 
> Does it make sense to you that this approach seems to fix the EH
> problems? (Or am I just lucky? Hope not.)

I assume 0x100|0x2 means RTLD_GLOBAL. Well, since python extension 
modules have no reason to throw a C++ exception into python you're 
probably fairly safe. The issues begin when ld.so loads a so due to 
dependency requirements of a previous so which then causes the 
merging of symbols to come out with different addresses so typeinfo 
comparisons magically fail.

With a bit of work, the shared library system on Linux can be made to 
play nice with C++. I'm kinda surprised it wasn't done already as I'd 
have thought people would be clamouring for it but if they didn't 
before, now GCC 3.4 is so standards compliant they surely will in the 
future.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBQO7iQsEcvDLFGKbPEQIElwCfcZJ9Q25bwj7kt79P/oxoWo0MBTwAoLZA
VOW8RoeTT1AWhMOgxB909H5A
=BX0l
-----END PGP SIGNATURE-----


From s_sourceforge at nedprod.com  Fri Jul  9 20:27:17 2004
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 09 Jul 2004 19:27:17 +0100
Subject: [C++-sig] Re: Multiple typeinfos causing failure of
	exception	catches
In-Reply-To: <usmc1nyqf.fsf@boost-consulting.com>
Message-ID: <40EEF195.4131.2055052C@localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 9 Jul 2004 at 8:36, David Abrahams wrote:

> There's a better fix that involves dealing differently with the way
> the ELF loader resolves weak symbols.  You might ask Jason Merrill
> (cc:'d here) about the idea - it was his.

I'd imagine he'll get back to me on Monday. Was it to do with getting 
the Linux ld.so to behave more like the Solaris one?

> > BTW, your problem with python having to load extension modules with
> > RTDL_LOCAL rather than RTDL_GLOBAL goes away if you use my -
> > fvisibility=hidden patch as no symbol clashes can happen.
> 
> I don't think so; you can still have symbol clashes if two extension
> modules explicitly export the same names.

True, but then why would they need exporting in a python extension? 
AFAICS most extensions export a table to python of what they provide 
plus a few init and deinit functions which I would have thought are 
looked up via dlsym() and thus unaffected by clashes?

I suppose if an extension was written using BPL and the extension 
could also be dual used as an embedded library then you might have 
issues. But you're still way ahead of how things stand now.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBQO7jhcEcvDLFGKbPEQJJzgCcDgN7UtRFkU+hGKtfaCtrRE3weRIAn2yI
ICCNejU7m1Q/OgEb0zrmL4rV
=/gu4
-----END PGP SIGNATURE-----


From dave at boost-consulting.com  Fri Jul  9 21:22:07 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 09 Jul 2004 15:22:07 -0400
Subject: [C++-sig] Re: Multiple typeinfos causing failure of
	exception	catches
References: <usmc1nyqf.fsf@boost-consulting.com>
	<40EEF195.4131.2055052C@localhost>
Message-ID: <usmc1gf4w.fsf@boost-consulting.com>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> On 9 Jul 2004 at 8:36, David Abrahams wrote:
>
>> There's a better fix that involves dealing differently with the way
>> the ELF loader resolves weak symbols.  You might ask Jason Merrill
>> (cc:'d here) about the idea - it was his.
>
> I'd imagine he'll get back to me on Monday. Was it to do with getting 
> the Linux ld.so to behave more like the Solaris one?

I know the solaris loader came up in the conversation, but I think
Jason had a very specific idea that isn't implemented anywhere yet.

>> > BTW, your problem with python having to load extension modules with
>> > RTDL_LOCAL rather than RTDL_GLOBAL goes away if you use my -
>> > fvisibility=hidden patch as no symbol clashes can happen.
>> 
>> I don't think so; you can still have symbol clashes if two extension
>> modules explicitly export the same names.
>
> True, but then why would they need exporting in a python extension? 

Because they're not self-contained; perhaps they need to interact
with other shared libs.

> AFAICS most extensions export a table to python of what they provide 
> plus a few init and deinit functions which I would have thought are 
> looked up via dlsym() and thus unaffected by clashes?

Right.

> I suppose if an extension was written using BPL and the extension 
> could also be dual used as an embedded library then you might have 
> issues. But you're still way ahead of how things stand now.

Agreed.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From rwgk at yahoo.com  Fri Jul  9 23:25:07 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 9 Jul 2004 14:25:07 -0700 (PDT)
Subject: [C++-sig] Multiple typeinfos causing failure of exception catches
In-Reply-To: <40EEF052.6773.205018AD@localhost>
Message-ID: <20040709212507.7079.qmail@web20226.mail.yahoo.com>

--- Niall Douglas <s_sourceforge at nedprod.com> wrote:
> > http://cvs.sourceforge.net/viewcvs.py/cctbx/boost_adaptbx/boost/python
> > .py?view=markup
> > 
> > Does it make sense to you that this approach seems to fix the EH
> > problems? (Or am I just lucky? Hope not.)
> 
> I assume 0x100|0x2 means RTLD_GLOBAL.

I think it is RTLD_GLOBAL | RTLD_NOW.
Ralf



		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 


From bhall at midwaygames.com  Sat Jul 10 00:01:58 2004
From: bhall at midwaygames.com (Brian Hall)
Date: Fri, 9 Jul 2004 22:01:58 +0000 (UTC)
Subject: [C++-sig] Injecting python derived C++ types at runtime in embedded
	environment
Message-ID: <loom.20040709T235404-930@post.gmane.org>

Hello all,

I have a C++ application where I want to be able to provide the user with 
creating a derived python class at runtime.

I basically have 3 C++ classes that I want to expose to python, and then at 
any time the user will be allowed to create a new custom python class derived 
from one of the 3 exposed classes.  They will also be allowed to modify their 
code and run it again.

Should I expose the types using the BOOST_PYTHON_MODULE macro? Or can I expose 
them after PyInitialize directly into the __main__ namespace?  Is it possible 
to reevaluate the code and have it update the derived class or will I have to 
purge the globals in some fashion?

Any help would be much appreciated.

Brian Hall



From ingo at fargonauten.de  Sat Jul 10 00:17:41 2004
From: ingo at fargonauten.de (Ingo Luetkebohle)
Date: Sat, 10 Jul 2004 00:17:41 +0200
Subject: [C++-sig] Injecting python derived C++ types at runtime in
	embedded environment
In-Reply-To: <loom.20040709T235404-930@post.gmane.org>
References: <loom.20040709T235404-930@post.gmane.org>
Message-ID: <1089411461.8958.17.camel@localhost>

Am Sa, den 10.07.2004 schrieb Brian Hall um 0:01:
> Should I expose the types using the BOOST_PYTHON_MODULE macro? Or can I expose 
> them after PyInitialize directly into the __main__ namespace?  Is it possible 
> to reevaluate the code and have it update the derived class or will I have to 
> purge the globals in some fashion?

Boost.Python helps you a lot with making the C++ types available to
Python at all.  The results is a module that you can import.

After having created the module,  you have to make it available to the
python script.  Just use a normal import statement, that will work as
usual.  If the user provides the python script, you can prepend the
statement the top, before compiling it.  

regards

-- 
Ingo

Soll doch jeder bleiben, wie er gerne w?re.



From s_sourceforge at nedprod.com  Sat Jul 10 14:05:03 2004
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 10 Jul 2004 13:05:03 +0100
Subject: [C++-sig] Re: Multiple typeinfos causing failure
	of	exception	catches
In-Reply-To: <usmc1gf4w.fsf@boost-consulting.com>
Message-ID: <40EFE97F.5930.241D6F4C@localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A little more on this:

[ned at katey2 lib]$ ./TestEmbedPython
TnFOX Python test:
- -=-=-=-=-=-=-=-=-Working with Python 2.3 (#8, Jul 10 2004, 11:28:33)
[GCC 3.4.0]
If you can read this, python prints!
Typeinfo of FXException in DLL is 0x804cba0,0x41f65004 
(N2FX11FXExceptionE)
Typeinfo of FXPythonException in DLL is 0x804a9d8,0x804a9e4 
(N2FX17FXPythonExceptionE)

Throwing a python exception ...
Typeinfo of caught exception in DLL is 0x804a9d8,0x804a9e4 
(N2FX17FXPythonExceptionE)
C++ exception caught: exceptions.IOError,A parameter to a python 
exception at line 2 in <string> (code 0xFFDE)

Typeinfo of pointer to be returned from DLL is 0x804a9d8,0x804a9e4 
(N2FX17FXPythonExceptionE)
Typeinfo of pointer returned from DLL is 0x804a9d8,0x804a9e4 
(N2FX17FXPythonExceptionE)

Typeinfo of FXException in EXE is 0x804cba0,0x41f65004 
(N2FX11FXExceptionE)
Typeinfo of FXPythonException in EXE is 0x804a9d8,0x804a9e4 
(N2FX17FXPythonExceptionE)

Throwing a python exception ...
terminate called after throwing an instance of 
'FX::FXPythonException'
Deleted secure heap

Unhandled Signal 0x6 (Abnormal termination)
    at address 0x5979 - immediate exit!


What I've done here is copy the throw/catch code into the bindings 
shared object. As we can see, the first throw/catch works fine and 
the second dies with terminate(). Both sets of code are identical - 
just in the second the throw is in the bindings DLL and the catch is 
in the EXE.

I have it printing the address of the typeinfo, the typeinfo.name() 
address and then the string. I was surprised to see that in both the 
DLL and EXE all addresses are the same, so therefore typeinfo 
comparison by address should be working. Therefore it would seem that 
this bug is not the same as Dave's original one.

I'll investigate GCC's source code next, maybe get it printing what 
the hell it's up to when it's catching exceptions. I've already 
looked through the assembler output from GCC for each of the source 
files and I'm fairly confident it's not that - also, a mockup of the 
same DLL & EXE configuration works fine so I think it's the linker, 
perhaps because it's linking 120Mb of non-debug object files with 
nearly 160,000 symbols.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBQO/bb8EcvDLFGKbPEQLXpACgqwP/hgNoh0+eXgmDVBYpuVt4sugAniGe
CWzSIkAX1gcgqXTG0jlH4Mun
=wGDg
-----END PGP SIGNATURE-----


From bhall at midwaygames.com  Sat Jul 10 19:47:07 2004
From: bhall at midwaygames.com (Brian Hall)
Date: Sat, 10 Jul 2004 17:47:07 +0000 (UTC)
Subject: [C++-sig] Creating an instance of a python class derived from a C++
	object from C++
Message-ID: <loom.20040710T193542-7@post.gmane.org>

Hello all,

Say I have the following:

class MyCppClass
{
public:
  virtual int SomeFunction(void) = 0;
};

struct MyCppClassWrap : public MyCppClass
{
  MyCppClassWrap(PyObject *self_)
    : self(self_)
  {}
  int SomeFunction(void) { return call_method<int>(self, "some_function"); }

  PyObject *self;
};

int call_SomeFunction(MyCppClass &c) { return c.SomeFunction(); }

BOOST_PYTHON_MODULE(MyPythonModule)
{
  class_<cState>("State", init<std::string>())
    .def("value", &cState::Value)
    .def("set_value", &cState::SetValue)
    .def("initial_value", &cState::InitialValue)
    .def("set_initial_value", &cState::SetInitialValue)
    .def("name", &cState::Name)
    .def("reset", &cState::Reset)
    .def("iterate", &cState::Iterate)
  ;
  def("call_some_function", call_SomeFunction);
};

Now say I want to dynamically create an instance of a python class derived 
from MyCppClass like so:

class MyPythonClass(MyCppClass):
  def SomeFunction(self):
    return 42

But I want to do this from C++, not Python... how would I do this?  Basically 
I want to be able to define new Python derived types of MyCppClass at runtime 
on the fly, and redefine them at will.  Say for instance the user of the 
application typed in the above declaration of MyPythonClass... and then later, 
updated that definition to return 43 instead, I want to be able to redefine 
the code for the class... if I did that, would I have to destroy the old 
instance and create a new one?  Any ideas?



From bhall at midwaygames.com  Sat Jul 10 19:52:23 2004
From: bhall at midwaygames.com (Brian Hall)
Date: Sat, 10 Jul 2004 17:52:23 +0000 (UTC)
Subject: [C++-sig] Re: Creating an instance of a python class derived from a
	C++	object from C++
References: <loom.20040710T193542-7@post.gmane.org>
Message-ID: <loom.20040710T195022-141@post.gmane.org>

> 
> BOOST_PYTHON_MODULE(MyPythonModule)
> {
>   class_<cState>("State", init<std::string>())
>     .def("value", &cState::Value)
>     .def("set_value", &cState::SetValue)
>     .def("initial_value", &cState::InitialValue)
>     .def("set_initial_value", &cState::SetInitialValue)
>     .def("name", &cState::Name)
>     .def("reset", &cState::Reset)
>     .def("iterate", &cState::Iterate)
>   ;
>   def("call_some_function", call_SomeFunction);
> };
> 


Ack!  How about this for the module definition...

BOOST_PYTHON_MODULE(MyPythonModule)
{
  class_<MyCppClass, MyCppClassWrap, boost::noncopyable>("MyCppClass", 
init<void>())
  ;
  def("call_some_function", call_SomeFunction);
};




From ingo at fargonauten.de  Sat Jul 10 20:56:47 2004
From: ingo at fargonauten.de (Ingo Luetkebohle)
Date: Sat, 10 Jul 2004 20:56:47 +0200
Subject: [C++-sig] Creating an instance of a python class derived from	a
	C++ object from C++
In-Reply-To: <loom.20040710T193542-7@post.gmane.org>
References: <loom.20040710T193542-7@post.gmane.org>
Message-ID: <1089485807.8960.24.camel@localhost>

Am Sa, den 10.07.2004 schrieb Brian Hall um 19:47:
> But I want to do this from C++, not Python... how would I do this?  Basically 
> I want to be able to define new Python derived types of MyCppClass at runtime 
> on the fly, and redefine them at will.  Say for instance the user of the 
> application typed in the above declaration of MyPythonClass... and then later, 
> updated that definition to return 43 instead, I want to be able to redefine 
> the code for the class... if I did that, would I have to destroy the old 
> instance and create a new one?  Any ideas?

As far as I know, you have to use the Python/C API directly for that. 
See the posting by Murray Cumming ("evaluating multiple statements") and
my answer from tuesday.  I never tried it, but you should be able to use
that procedure repeatedly with the same module name.  If you try that,
please report back if you had to do anything, I will have to do
something like that in the near future.

To create an object of class "MyPClass", use the method "MyPClass" from
the module dictionary.  After reloading, you will have to recreate your
objects to reflect the new code.  If the state is important, you might
want to pickle them.

regards,

-- 
Ingo

Soll doch jeder bleiben, wie er gerne w?re.



From bhall at gamers-fix.com  Sat Jul 10 21:43:55 2004
From: bhall at gamers-fix.com (Brian Hall)
Date: Sat, 10 Jul 2004 14:43:55 -0500
Subject: [C++-sig] Embedding Python and the Game Institute
Message-ID: <20040710194349.3F1E31E4002@bag.python.org>

Hello All,

I?m currently in the process of extending my current course at the Game
Institute (www.gameinstitute.com) to include scripting engines for games.?
I?m wanting to use Boost.Python to do the job, but I?m running into some
problems and I am under a tight time budget.? I was wondering if any of you
could help point me in the right direction for what I?m trying to accomplish
as this would help get an actual course out there for people to somewhat
learn to use Boost.Python in their own little games they are writing.? Any
help any of you could provide would be much appreciated.

Let me start with a quick overview of what I?m trying to accomplish


I have a state machine demo where the user is able to add new states to
their state machine.? They can attach actions to these states, which are
each executed when the machine is in the state.? The states also have
transitions attached to them which are evaluated to determine if the machine
should transition into the transition?s target state.? Simple stuff.

The tricky bit comes in when the user wants to add a ?scripted action? which
will be python script.? The way I wanted to have it work was I was going to
have the user derive the python action class directly from the C++ action
class.? Same with the transitions.? The catch is they can change these
scripts at any time, as well as add new transitions and actions at any time

so I?m trying to figure out how to update the instances of the python
objects the user would be mucking with


Incidentally I have no problems falling back onto the python C API if I have
to, I don?t expect Boost.Python to do it all for me
 I?m just needing a
little help connecting the dots


Thanks in advance for any help you can provide!

Brian Hall
Instructor
Game Institute





From dave at boost-consulting.com  Sat Jul 10 21:47:03 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 10 Jul 2004 15:47:03 -0400
Subject: [C++-sig] Re: Creating an instance of a python class derived from a
 C++ object from C++
References: <loom.20040710T193542-7@post.gmane.org>
Message-ID: <ubriny79k.fsf@boost-consulting.com>

Brian Hall <bhall at midwaygames.com> writes:

> Hello all,
>
> Say I have the following:
>
> class MyCppClass
> {
> public:
>   virtual int SomeFunction(void) = 0;
> };
>
> struct MyCppClassWrap : public MyCppClass
> {
>   MyCppClassWrap(PyObject *self_)
>     : self(self_)
>   {}
>   int SomeFunction(void) { return call_method<int>(self, "some_function"); }
>
>   PyObject *self;
> };
>
> int call_SomeFunction(MyCppClass &c) { return c.SomeFunction(); }
>
> BOOST_PYTHON_MODULE(MyPythonModule)
> {
>   class_<cState>("State", init<std::string>())
>     .def("value", &cState::Value)
>     .def("set_value", &cState::SetValue)
>     .def("initial_value", &cState::InitialValue)
>     .def("set_initial_value", &cState::SetInitialValue)
>     .def("name", &cState::Name)
>     .def("reset", &cState::Reset)
>     .def("iterate", &cState::Iterate)
>   ;
>   def("call_some_function", call_SomeFunction);
> };
>
> Now say I want to dynamically create an instance of a python class derived 
> from MyCppClass like so:
>
> class MyPythonClass(MyCppClass):
>   def SomeFunction(self):
>     return 42
>
> But I want to do this from C++, not Python... how would I do this?  

Use the metaclass interface:

  >>> class fu(object):pass
  ...
  >>> bases = (fu,)
  >>> attributes = { 'x' : 1, 'quack' : lambda self: 'like a duck' }
  >>> bar = object.__class__('bar', bases, attributes) # a derived class of fu
  >>> help(bar)
  Help on class bar in module __main__:

  class bar(fu)
   |  Method resolution order:
   |      bar
   |      fu
   |      __builtin__.object
   |
   |  Methods defined here:
   |
   |  lambdaself
   |
   |  ----------------------------------------------------------------------
   |  Data and other attributes defined here:
   |
   |  x = 1
   |
   |  ----------------------------------------------------------------------
   |  Data and other attributes inherited from fu:
   |
   |  __dict__ = <dictproxy object>
   |      dictionary for instance variables (if defined)
   |
   |  __weakref__ = <attribute '__weakref__' of 'fu' objects>
   |      list of weak references to the object (if defined)

  >>> bar().quack()
  'like a duck'
  >>> bar.x
  1

So,

    object py_cState; // the Python class object

    BOOST_PYTHON_MODULE(MyPythonModule)
    {
      py_cState = class_<cState>("State", init<std::string>())
      ^^^^^^^^^^^^
        .def("value", &cState::Value)
        .def("set_value", &cState::SetValue)
        .def("initial_value", &cState::InitialValue)
        .def("set_initial_value", &cState::SetInitialValue)
        .def("name", &cState::Name)
        .def("reset", &cState::Reset)
        .def("iterate", &cState::Iterate)
      ;
      def("call_some_function", call_SomeFunction);
    };
    
    char const* quack(object self) { return "like a duck"; }

    // returns a new class
    object make_bar
    {
        object bases = make_tuple(py_cState);
        dict attributes;
        attributes['x'] = 1;
        attributes['quack'] = quack;

        return py_cState.attr("__class__")("bar", bases, attributes);
    };

> Basically 
> I want to be able to define new Python derived types of MyCppClass at runtime 
> on the fly, and redefine them at will.  Say for instance the user of the 
> application typed in the above declaration of MyPythonClass... and then later, 
> updated that definition to return 43 instead, I want to be able to redefine 
> the code for the class... if I did that, would I have to destroy the old 
> instance and create a new one?  Any ideas?

You can always replace the class' methods one-at-a-time.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From bhall at gamers-fix.com  Sat Jul 10 22:03:03 2004
From: bhall at gamers-fix.com (Brian Hall)
Date: Sat, 10 Jul 2004 15:03:03 -0500
Subject: [C++-sig] Re: Creating an instance of a python class derived from
	a C++ object from C++
In-Reply-To: <ubriny79k.fsf@boost-consulting.com>
Message-ID: <20040710200256.909551E4002@bag.python.org>


>
> Now say I want to dynamically create an instance of a python class derived

> from MyCppClass like so:
>
> class MyPythonClass(MyCppClass):
>   def SomeFunction(self):
>     return 42
>
> But I want to do this from C++, not Python... how would I do this?  

Use the metaclass interface:

    // returns a new class
    object make_bar
    {
        object bases = make_tuple(py_cState);
        dict attributes;
        attributes['x'] = 1;
        attributes['quack'] = quack;

        return py_cState.attr("__class__")("bar", bases, attributes);
    };

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

While this is very very cool, I think you misunderstand me... I have the
python script, and I want to instantiate a python object of type
MyPythonClass from C++ not define it from C++.

Thanks again!

Brian





From dave at boost-consulting.com  Sun Jul 11 01:49:17 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 10 Jul 2004 19:49:17 -0400
Subject: [C++-sig] Re: Creating an instance of a python class derived from a
 C++ object from C++
References: <ubriny79k.fsf@boost-consulting.com>
	<20040710200256.909551E4002@bag.python.org>
Message-ID: <uu0wfv2wy.fsf@boost-consulting.com>

"Brian Hall" <bhall at gamers-fix.com> writes:

>>
>> Now say I want to dynamically create an instance of a python class derived
>
>> from MyCppClass like so:
>>
>> class MyPythonClass(MyCppClass):
>>   def SomeFunction(self):
>>     return 42
>>
>> But I want to do this from C++, not Python... how would I do this?  
>
> Use the metaclass interface:
>
>     // returns a new class
>     object make_bar
>     {
>         object bases = make_tuple(py_cState);
>         dict attributes;
>         attributes['x'] = 1;
>         attributes['quack'] = quack;
>
>         return py_cState.attr("__class__")("bar", bases, attributes);
>     };
>
> ----------------
>
> While this is very very cool, I think you misunderstand me... I have the
> python script, and I want to instantiate a python object of type
> MyPythonClass from C++ not define it from C++.

Wrap this:

     object make_one(object some_class)
     {
        return some_class();
     }

in python:

   >>> make_one(MyPythonClass)
   >>> <my_module.MyPythonClass object at 0xwhatever>


-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From bhall at gamers-fix.com  Sun Jul 11 06:26:33 2004
From: bhall at gamers-fix.com (Brian Hall)
Date: Sat, 10 Jul 2004 23:26:33 -0500
Subject: [C++-sig] Type Exception of type Argument Error
Message-ID: <20040711042632.B221C1E4002@bag.python.org>

Hello all,

 

I'm getting really close on my defining derived C++ types in python and
having them instantiated and executed from C++, but I've run into a snag.

 

I have the following module defined:

 

BOOST_PYTHON_MODULE(GI_AISDK)

{

      // Expose the State class to Python

      class_<cState>("State", init<float, std::string>())

            .add_property("value", &cState::Value, &cState::SetValue)

            .add_property("initial_value", &cState::InitialValue,
&cState::SetInitialValue)

            ;

 

      // Expose a base class new scripted actions should derive from

      class_<cPythonScriptedAction>("PythonScriptedAction", init<cState&>())

            .def("state", &cScriptedAction::State,
return_internal_reference<>())

            ;

 

      // Expose a base class new scripted transitions should derive from

      class_<cPythonScriptedTransition>("PythonScriptedTransition",
init<cState&, cState&>())

            .def("source", &cPythonScriptedTransition::Source,
return_internal_reference<>())

            .def("target", &cPythonScriptedTransition::Target,
return_internal_reference<>())

            ;

}

 

The State(), Source(), and Target() methods of the Actions and Transitions
all return a reference to an internally held cState class.

However if I try to call the execute method on the following Action python
script:

 

from GI_AISDK import *

 

class TestAction(PythonScriptedAction):

 

      def __init__(self):

            pass

 

      def execute(self):

            self.state()

 

I get a Type Exception with the annotation Argument Error.  I'm not entirely
sure what could be going on here.  I also tried the
reference_existing_object but to no avail.  If I simply pass in that method,
it executes fine.  In fact I can do whatever I want except call that state()
method.

 

Any ideas?

 

Thanks!

 

Brian Hall

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

From dave at boost-consulting.com  Sun Jul 11 15:10:08 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 11 Jul 2004 09:10:08 -0400
Subject: [C++-sig] Re: Type Exception of type Argument Error
References: <20040711042632.B221C1E4002@bag.python.org>
Message-ID: <uiscuu1u7.fsf@boost-consulting.com>

"Brian Hall" <bhall at gamers-fix.com> writes:

> I get a Type Exception with the annotation Argument Error.  I'm not entirely
> sure what could be going on here.  I also tried the
> reference_existing_object but to no avail.  If I simply pass in that method,
> it executes fine.  In fact I can do whatever I want except call that state()
> method.

It's hard to be of much help unless you show the C++ classes being
wrapped.   The best way to get help here is to post a complete,
reproducible, minimal test case.
 
-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From bhall at gamers-fix.com  Sun Jul 11 19:35:25 2004
From: bhall at gamers-fix.com (Brian Hall)
Date: Sun, 11 Jul 2004 12:35:25 -0500
Subject: [C++-sig] Re: Type Exception of type Argument Error
In-Reply-To: <uiscuu1u7.fsf@boost-consulting.com>
Message-ID: <20040711173524.DDEE01E4002@bag.python.org>


I'm working on a minimal reproducible test case, but for the time being, let
me post the declarations of the classes involved and what I have so far on
the simple reproduction case:

<code>

class cState : public cObject
{
public:
	typedef vector<cTransition*> tTransitionList;
	typedef vector<cAction*> tActionList;

					cState(float initialValue, string
name) : 
	
mValue(initialValue), 
	
mInitialValue(initialValue),
							mName(name) 
						{}
	virtual 			~cState(void);

	float				Value(void) const { return(mValue);
}
	float				InitialValue(void) const 
					{ return(mInitialValue); }

	void				SetValue(float value) { mValue =
value; }
	void				SetInitialValue(float value) 
					{ mInitialValue = value; }

	void				Reset(void) { mValue =
mInitialValue; }

	const string		&Name(void) const { return(mName); }
	void				SetName(const string &name) { mName
= name; }

	void				Iterate(void)
					{
						for
						(
	
tActionList::iterator it = 
	
mActions.begin();
							it !=
mActions.end();
							++it
						)
							(*it)->Execute();
					}
	tTransitionList		&Transitions(void) { return(mTransitions); }
	tActionList			&Actions(void) { return(mActions); }
	
protected:
	float				mValue;
	float				mInitialValue;
	tTransitionList		mTransitions;
	tActionList			mActions;
	string			mName;
};

class cAction : public cObject
{
public:
				cAction(cState &state) : mState(state) {}
	virtual		~cAction(void) {}
	virtual void	Execute(void) = 0;
	virtual string	Label(void) = 0;
	cState		&State(void) const { return(mState); }

protected:
	cState &mState;
};

class cScriptedAction : public cAction
{
public:
			cScriptedAction(cState &state);
	virtual	~cScriptedAction(void);
};

class cPythonScriptedAction : public cScriptedAction
{
public:
					cPythonScriptedAction(cState
&state);
					cPythonScriptedAction(cState &state,

						const string &scriptName, 
						const string &script);
	virtual			~cPythonScriptedAction(void);

	virtual void	Execute(void);
	virtual string	Label(void) { return("Python Scripted Action"); };

	void			SetScript(const string &script) { mScript =
script; }
	const string	&Script(void) const { return(mScript); }

protected:
	string		mScriptName;
	string		mScript;
	handle<>		mInstance;
};

BOOST_PYTHON_MODULE(GI_AISDK)
{
	// Expose the State class to Python
	class_<cState>("State", init<float, std::string>())
		.add_property("value", &cState::Value, &cState::SetValue)
		.add_property("initial_value", &cState::InitialValue,
&cState::SetInitialValue)
		;

	// Expose a base class new scripted actions should derive from
	class_<cPythonScriptedAction>("PythonScriptedAction",
init<cState&>())
		.def("state", &cScriptedAction::State, 
			return_internal_reference<>())
		;
}

</code>

<pythoncode>

from GI_AISDK import *

class TestAction(PythonScriptedAction):

	def __init__(self):
		pass

	def execute(self):
		self.state()

</pythoncode>

Ok so that's all the code... now for the tricky part.... the way I get all
this stuff to work, is I get the script from the user and I use the C API to
compile it and get it in the dictionary:

bool cPythonScriptEngine::CompileScript(const string &scriptName, 
							const string
&script)
{
	// Parse the script
	node *pythonNode = PyParser_SimpleParseString(script.c_str(),
 					Py_file_input);

	// Dump any errors that may have occurred
	if (PyErr_Occurred())
		return(false);

	// if the script parsed properly, 
	// compile the code and inject it into the dictionary
	PyCodeObject* codeObject = PyNode_CompileFlags(pythonNode, 
		const_cast<char *>(scriptName.c_str()), NULL);
	// free our parsed script node
	PyNode_Free(pythonNode);

	if (!codeObject)
		if (PyErr_Occurred())
			return(false);

	// evaluate the code so the new class can find
	// its way into the dictionary
	PyObject *evaluateResult = PyEval_EvalCode(codeObject,
		mMainNamespace.get(), mMainNamespace.get());
	Py_DECREF(codeObject);
	if (!evaluateResult)
		if (PyErr_Occurred())
			return(false);

	Py_DECREF(evaluateResult);

	return(true);
}

If the code successfully compiles, I instantiate a new cPythonScriptedAction
class and hand it the script name, and construct the instance like so:

cPythonScriptedAction::cPythonScriptedAction
(
	cState &state, 
	const string &scriptName, 
	const string &script
) : 
	cScriptedAction(state), 
	mScriptName(scriptName),
	mScript(script)
{
	mInstance = 
		handle<>(cPythonScriptEngine::Instance().MakeInstance(this, 
			scriptName));
}

PyObject *cPythonScriptEngine::MakeInstance(void *, 
			const string &scriptName)
{
	PyTypeObject *objType = NULL;
	PyObject *newInstance = NULL;
	PyObject *args = PyTuple_New(0);

	// Look up the type object first...
	// Look in the main dictionary for the object
	objType = (PyTypeObject *)PyDict_GetItemString(mMainNamespace.get(),

			const_cast<char *>(scriptName.c_str()));
	// if we don't find it, try the built in dictionary
	if (!objType)
		objType = (PyTypeObject *)PyDict_GetItemString(
				mBuiltinsNamespace.get(), 
				const_cast<char *>(scriptName.c_str()));

	// if we still didn't find it bail
	if (!objType)
		return(NULL);

	// now create a new instance of an object of that type
	if (objType->tp_new)
		newInstance = objType->tp_new(objType, args, NULL);
	else
	{
		// error!
		return(NULL);
	}

	// now call the new objects init method if we have one
	if (!newInstance)
		return(NULL);

	if (objType->tp_init)
	{
		if (objType->tp_init(newInstance, args, NULL) < 0)
			return(NULL);	// init failed?
	}

	return(newInstance);
}

Execute for cPythonScriptedAction is implemented as:

void cPythonScriptedAction::Execute(void)
{
	try
	{
		call_method<void>(mInstance.get(), "execute");
	}
	catch(error_already_set)
	{
		MessageBox(NULL,
	
cPythonScriptEngine::Instance().GetPythonException().c_str(), 
		"Python Execution Error", MB_ICONEXCLAMATION);
	}
}

Given all this, basically a C++ main function would look like:

int main(int argc, char** argv)
{
	const char script[] = 
		"from GI_AISDK import *\n"
		"\n"
		"class TestAction(PythonScriptedAction):\n"
		"\n"
		"\tdef __init__(self):\n"
		"\t\tpass\n"
		"\n"
		"\tdef execute(self):\n"
		"\t\tself.state()\n"
		"\n";

	const char scriptName[] = "TestAction";

	// setup python here
	cPythonScriptEngine::Instance().Initialize();

	cPythonScriptEngine::Instance().CompileScript(scriptName, script);

	cState *state = new cState(10.0f, "TestState");
	cAction *action = new cPythonScriptedAction(*cState, 
					scriptName, script);
	state->Actions().push_back(action);

	try
	{
		state->Iterate();		// will die here evaluating
execute
	}
	catch(...)
	{
	}

	// clean up python here
	cPythonScriptEngine::Instance().Finalize();
}

That's it!  I'm hoping to put together an actual test case that just does
this stuff and put it on my website for download...

If you see anything broken here let me know! Thanks!

Brian Hall

-----Original Message-----
From: c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org] On
Behalf Of David Abrahams
Sent: Sunday, July 11, 2004 7:10 AM
To: c++-sig at python.org
Subject: [C++-sig] Re: Type Exception of type Argument Error

It's hard to be of much help unless you show the C++ classes being
wrapped.   The best way to get help here is to post a complete,
reproducible, minimal test case.
 



From bhall at gamers-fix.com  Sun Jul 11 21:24:52 2004
From: bhall at gamers-fix.com (Brian Hall)
Date: Sun, 11 Jul 2004 14:24:52 -0500
Subject: [C++-sig] Re: Type Exception of type Argument Error
In-Reply-To: <20040711173524.DDEE01E4002@bag.python.org>
Message-ID: <20040711192443.55E291E4002@bag.python.org>

Alright, I've modified my code to use the object class to create python
objects, and all is going well now aside from the object being passed into
the constructor being copied rather than used as a reference...

I do the following:

	// look up the object in the dictionary
	object scriptType = pyEngine.GetObject(scriptName);

	cState *state = new cState(10.0f, "TestState");

	try
	{
		cout << "State Value: " << state->Value() << endl;
		object newObject = scriptType(*state);
		call_method<void>(newObject.ptr(), "execute");
		cout << "State Value: " << state->Value() << endl;
	}
	catch(error_already_set)
	{
		if (PyErr_Occurred())
		{
			PyErr_Print();
			PyErr_Clear();
		}
	}

With the script:

from GI_AISDK import *

class TestAction(PythonScriptedAction):
	def execute(self):
		print "Hello from Python"
		print "State Value(py): ", self.state().value
		self.state().value = self.state().value - 5.0
		print "State Value(py): ", self.state().value

However the output I get is:

State Value: 10
Hello from Python
State Value: 10
State Value: 5
State Value: 10

How do can I ensure that any constructor parameters are not copied but are
actually treated as the correct type of constructor parameters?


-----Original Message-----
From: c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org] On
Behalf Of Brian Hall
Sent: Sunday, July 11, 2004 11:35 AM
To: 'Development of Python/C++ integration'
Subject: RE: [C++-sig] Re: Type Exception of type Argument Error


I'm working on a minimal reproducible test case, but for the time being, let
me post the declarations of the classes involved and what I have so far on
the simple reproduction case:

<code>

class cState : public cObject
{
public:
	typedef vector<cTransition*> tTransitionList;
	typedef vector<cAction*> tActionList;

					cState(float initialValue, string
name) : 
	
mValue(initialValue), 
	
mInitialValue(initialValue),
							mName(name) 
						{}
	virtual 			~cState(void);

	float				Value(void) const { return(mValue);
}
	float				InitialValue(void) const 
					{ return(mInitialValue); }

	void				SetValue(float value) { mValue =
value; }
	void				SetInitialValue(float value) 
					{ mInitialValue = value; }

	void				Reset(void) { mValue =
mInitialValue; }

	const string		&Name(void) const { return(mName); }
	void				SetName(const string &name) { mName
= name; }

	void				Iterate(void)
					{
						for
						(
	
tActionList::iterator it = 
	
mActions.begin();
							it !=
mActions.end();
							++it
						)
							(*it)->Execute();
					}
	tTransitionList		&Transitions(void) { return(mTransitions); }
	tActionList			&Actions(void) { return(mActions); }
	
protected:
	float				mValue;
	float				mInitialValue;
	tTransitionList		mTransitions;
	tActionList			mActions;
	string			mName;
};

class cAction : public cObject
{
public:
				cAction(cState &state) : mState(state) {}
	virtual		~cAction(void) {}
	virtual void	Execute(void) = 0;
	virtual string	Label(void) = 0;
	cState		&State(void) const { return(mState); }

protected:
	cState &mState;
};

class cScriptedAction : public cAction
{
public:
			cScriptedAction(cState &state);
	virtual	~cScriptedAction(void);
};

class cPythonScriptedAction : public cScriptedAction
{
public:
					cPythonScriptedAction(cState
&state);
					cPythonScriptedAction(cState &state,

						const string &scriptName, 
						const string &script);
	virtual			~cPythonScriptedAction(void);

	virtual void	Execute(void);
	virtual string	Label(void) { return("Python Scripted Action"); };

	void			SetScript(const string &script) { mScript =
script; }
	const string	&Script(void) const { return(mScript); }

protected:
	string		mScriptName;
	string		mScript;
	handle<>		mInstance;
};

BOOST_PYTHON_MODULE(GI_AISDK)
{
	// Expose the State class to Python
	class_<cState>("State", init<float, std::string>())
		.add_property("value", &cState::Value, &cState::SetValue)
		.add_property("initial_value", &cState::InitialValue,
&cState::SetInitialValue)
		;

	// Expose a base class new scripted actions should derive from
	class_<cPythonScriptedAction>("PythonScriptedAction",
init<cState&>())
		.def("state", &cScriptedAction::State, 
			return_internal_reference<>())
		;
}

</code>

<pythoncode>

from GI_AISDK import *

class TestAction(PythonScriptedAction):

	def __init__(self):
		pass

	def execute(self):
		self.state()

</pythoncode>

Ok so that's all the code... now for the tricky part.... the way I get all
this stuff to work, is I get the script from the user and I use the C API to
compile it and get it in the dictionary:

bool cPythonScriptEngine::CompileScript(const string &scriptName, 
							const string
&script)
{
	// Parse the script
	node *pythonNode = PyParser_SimpleParseString(script.c_str(),
 					Py_file_input);

	// Dump any errors that may have occurred
	if (PyErr_Occurred())
		return(false);

	// if the script parsed properly, 
	// compile the code and inject it into the dictionary
	PyCodeObject* codeObject = PyNode_CompileFlags(pythonNode, 
		const_cast<char *>(scriptName.c_str()), NULL);
	// free our parsed script node
	PyNode_Free(pythonNode);

	if (!codeObject)
		if (PyErr_Occurred())
			return(false);

	// evaluate the code so the new class can find
	// its way into the dictionary
	PyObject *evaluateResult = PyEval_EvalCode(codeObject,
		mMainNamespace.get(), mMainNamespace.get());
	Py_DECREF(codeObject);
	if (!evaluateResult)
		if (PyErr_Occurred())
			return(false);

	Py_DECREF(evaluateResult);

	return(true);
}

If the code successfully compiles, I instantiate a new cPythonScriptedAction
class and hand it the script name, and construct the instance like so:

cPythonScriptedAction::cPythonScriptedAction
(
	cState &state, 
	const string &scriptName, 
	const string &script
) : 
	cScriptedAction(state), 
	mScriptName(scriptName),
	mScript(script)
{
	mInstance = 
		handle<>(cPythonScriptEngine::Instance().MakeInstance(this, 
			scriptName));
}

PyObject *cPythonScriptEngine::MakeInstance(void *, 
			const string &scriptName)
{
	PyTypeObject *objType = NULL;
	PyObject *newInstance = NULL;
	PyObject *args = PyTuple_New(0);

	// Look up the type object first...
	// Look in the main dictionary for the object
	objType = (PyTypeObject *)PyDict_GetItemString(mMainNamespace.get(),

			const_cast<char *>(scriptName.c_str()));
	// if we don't find it, try the built in dictionary
	if (!objType)
		objType = (PyTypeObject *)PyDict_GetItemString(
				mBuiltinsNamespace.get(), 
				const_cast<char *>(scriptName.c_str()));

	// if we still didn't find it bail
	if (!objType)
		return(NULL);

	// now create a new instance of an object of that type
	if (objType->tp_new)
		newInstance = objType->tp_new(objType, args, NULL);
	else
	{
		// error!
		return(NULL);
	}

	// now call the new objects init method if we have one
	if (!newInstance)
		return(NULL);

	if (objType->tp_init)
	{
		if (objType->tp_init(newInstance, args, NULL) < 0)
			return(NULL);	// init failed?
	}

	return(newInstance);
}

Execute for cPythonScriptedAction is implemented as:

void cPythonScriptedAction::Execute(void)
{
	try
	{
		call_method<void>(mInstance.get(), "execute");
	}
	catch(error_already_set)
	{
		MessageBox(NULL,
	
cPythonScriptEngine::Instance().GetPythonException().c_str(), 
		"Python Execution Error", MB_ICONEXCLAMATION);
	}
}

Given all this, basically a C++ main function would look like:

int main(int argc, char** argv)
{
	const char script[] = 
		"from GI_AISDK import *\n"
		"\n"
		"class TestAction(PythonScriptedAction):\n"
		"\n"
		"\tdef __init__(self):\n"
		"\t\tpass\n"
		"\n"
		"\tdef execute(self):\n"
		"\t\tself.state()\n"
		"\n";

	const char scriptName[] = "TestAction";

	// setup python here
	cPythonScriptEngine::Instance().Initialize();

	cPythonScriptEngine::Instance().CompileScript(scriptName, script);

	cState *state = new cState(10.0f, "TestState");
	cAction *action = new cPythonScriptedAction(*cState, 
					scriptName, script);
	state->Actions().push_back(action);

	try
	{
		state->Iterate();		// will die here evaluating
execute
	}
	catch(...)
	{
	}

	// clean up python here
	cPythonScriptEngine::Instance().Finalize();
}

That's it!  I'm hoping to put together an actual test case that just does
this stuff and put it on my website for download...

If you see anything broken here let me know! Thanks!

Brian Hall

-----Original Message-----
From: c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org] On
Behalf Of David Abrahams
Sent: Sunday, July 11, 2004 7:10 AM
To: c++-sig at python.org
Subject: [C++-sig] Re: Type Exception of type Argument Error

It's hard to be of much help unless you show the C++ classes being
wrapped.   The best way to get help here is to post a complete,
reproducible, minimal test case.
 

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



From dave at boost-consulting.com  Sun Jul 11 21:30:22 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 11 Jul 2004 15:30:22 -0400
Subject: [C++-sig] Re: Type Exception of type Argument Error
References: <20040711173524.DDEE01E4002@bag.python.org>
	<20040711192443.55E291E4002@bag.python.org>
Message-ID: <uoemms5o1.fsf@boost-consulting.com>

"Brian Hall" <bhall at gamers-fix.com> writes:

> Alright, I've modified my code to use the object class to create python
> objects, and all is going well now aside from the object being passed into
> the constructor being copied rather than used as a reference...

??  What constructor ??

>
> How do can I ensure that any constructor parameters are not copied but are
> actually treated as the correct type of constructor parameters?

I'm lost.  Can you post a small piece of code that illustrates your
question?

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From bhall at gamers-fix.com  Sun Jul 11 22:36:44 2004
From: bhall at gamers-fix.com (Brian Hall)
Date: Sun, 11 Jul 2004 15:36:44 -0500
Subject: [C++-sig] Re: Type Exception of type Argument Error
In-Reply-To: <uoemms5o1.fsf@boost-consulting.com>
Message-ID: <20040711203640.47F2E1E4002@bag.python.org>

Here is a simple project that shows the problem...

There is cPythonScriptedAction class which is a wrapper for the
cScriptedAction class which is derived from cAction.  cAction holds a
reference to a cState.  All of the constructors of the various cAction
classes take a reference to a cState object upon construction which they
store.

The python script derives a new type from the exposed cScriptedAction,
obtains the cState reference via the State() accessor, and makes
modifications to the value the state contains.

The output expected is:

State Value: 10
Hello from Python!
State Value 10
State Value 5
State Value 5

The output received is:

State Value: 10
Hello from Python!
State Value 10
State Value 5
State Value 10

This shows the state value on the C++ side isn't changing, and therefore the
python derived action class has its own copy of the state rather that using
the reference.

I hope this helps explain what's going on!

Brian

-----Original Message-----
From: c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org] On
Behalf Of David Abrahams
Sent: Sunday, July 11, 2004 1:30 PM
To: c++-sig at python.org
Subject: [C++-sig] Re: Type Exception of type Argument Error

"Brian Hall" <bhall at gamers-fix.com> writes:

> Alright, I've modified my code to use the object class to create python
> objects, and all is going well now aside from the object being passed into
> the constructor being copied rather than used as a reference...

??  What constructor ??

>
> How do can I ensure that any constructor parameters are not copied but are
> actually treated as the correct type of constructor parameters?

I'm lost.  Can you post a small piece of code that illustrates your
question?

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

_______________________________________________
C++-sig mailing list
C++-sig at python.org
http://mail.python.org/mailman/listinfo/c++-sig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PythonSandbox.zip
Type: application/x-zip-compressed
Size: 9391 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20040711/63f31626/attachment.bin>

From dave at boost-consulting.com  Sun Jul 11 23:30:57 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 11 Jul 2004 17:30:57 -0400
Subject: [C++-sig] Re: Type Exception of type Argument Error
References: <uoemms5o1.fsf@boost-consulting.com>
	<20040711203640.47F2E1E4002@bag.python.org>
Message-ID: <ueknis032.fsf@boost-consulting.com>

"Brian Hall" <bhall at gamers-fix.com> writes:

> Here is a simple project that shows the problem...

This is still way too complicated for me to analyze.  Please reduce it to
a single C++ file (no headers) and a single Python file.  Remove all
of the code that's irrelevant to the problem -- there' a great deal
of that here.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From bhall at gamers-fix.com  Mon Jul 12 00:09:43 2004
From: bhall at gamers-fix.com (Brian Hall)
Date: Sun, 11 Jul 2004 17:09:43 -0500
Subject: [C++-sig] Re: Type Exception of type Argument Error
In-Reply-To: <ueknis032.fsf@boost-consulting.com>
Message-ID: <20040711220938.25AEA1E4002@bag.python.org>

I tried to simplify it further, but I didn't want to get too far from the
scope of what I'm doing and wind up having it not even be the same problem
anymore.

The crux of the problem is this:

I have a class A which holds a reference to another class B which it gets in
its constructor.
I have a python class C which inherits from class A.
I run the script containing the declaration of class C and store it in a
Boost.Python 'object'.
I construct a class B C++ object.
I use the Boost.Python 'object' to create an instance of class C and pass
the class B object in for the object's __init__.
I execute a method on the new instance, expecting the B C++ object I made to
be the one getting modified.

Attached is some simplified code... it compiles but the error isn't quite
the same as what I'm getting on my full test case, though it is similar.


I expect to see:
B Value: 10
Hello from Python
B Value(py): 10
B Value(py): 5
Goodbye from Python
B Value: 5

B Value: 10
Hello from Python
B Value(py):  1.46175160111e-038		(my full test case gives 10)
B Value(py):  1.46175160111e-038		(my full test case gives 5)
Goodbye from Python
B Value: 10

Hope this clears things up...

Brian

-----Original Message-----
From: c++-sig-bounces+bhall=gamers-fix.com at python.org
[mailto:c++-sig-bounces+bhall=gamers-fix.com at python.org] On Behalf Of David
Abrahams
Sent: Sunday, July 11, 2004 3:31 PM
To: c++-sig at python.org
Subject: [C++-sig] Re: Type Exception of type Argument Error

"Brian Hall" <bhall at gamers-fix.com> writes:

> Here is a simple project that shows the problem...

This is still way too complicated for me to analyze.  Please reduce it to
a single C++ file (no headers) and a single Python file.  Remove all
of the code that's irrelevant to the problem -- there' a great deal
of that here.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

_______________________________________________
C++-sig mailing list
C++-sig at python.org
http://mail.python.org/mailman/listinfo/c++-sig
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: SimplifiedMore.cpp
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20040711/b6043848/attachment.txt>

From dave at boost-consulting.com  Mon Jul 12 02:15:00 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 11 Jul 2004 20:15:00 -0400
Subject: [C++-sig] Re: Type Exception of type Argument Error
References: <ueknis032.fsf@boost-consulting.com>
	<20040711220938.25AEA1E4002@bag.python.org>
Message-ID: <uu0weqdx7.fsf@boost-consulting.com>

"Brian Hall" <bhall at gamers-fix.com> writes:

> 		// create new instance of object
> 		object newInstance = typeObj(*b);

		object newInstance = typeObj(boost::ref(*b));

or

		object newInstance = typeObj(ptr(b));

Will get you over this particular hurdle.

But you have major ownership issues.  Your B object ought to be
created within a Python object

	pyB = class_<B>("B", init<float>())
		.add_property("value", &B::Value, &B::SetValue)
		;

    ...
    object b = pyB(10);

or held by a shared_ptr:

	boost::shared_ptr<B> b(new B(10));

Your A ought to hold a shared_ptr<B>, and you shouldn't use
return_internal_reference on GetB: that's only for when the return
value is a subobject of an argument to the method (self in this case).

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From bhall at gamers-fix.com  Mon Jul 12 06:39:28 2004
From: bhall at gamers-fix.com (Brian Hall)
Date: Sun, 11 Jul 2004 23:39:28 -0500
Subject: [C++-sig] Re: Type Exception of type Argument Error
In-Reply-To: <uu0weqdx7.fsf@boost-consulting.com>
Message-ID: <20040712043917.7C8F31E4002@bag.python.org>

That fixed it all up!  I've converted all my references and whatnot over to
using shared_ptr (way safer I agree) and I'm in business!  Works great and
much easier than the stuff I was going through! 

Thanks!  I'll keep everyone in the loop on how the rest of it goes!

Brian

-----Original Message-----
From: c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org] On
Behalf Of David Abrahams
Sent: Sunday, July 11, 2004 6:15 PM
To: c++-sig at python.org
Subject: [C++-sig] Re: Type Exception of type Argument Error

"Brian Hall" <bhall at gamers-fix.com> writes:

> 		// create new instance of object
> 		object newInstance = typeObj(*b);

		object newInstance = typeObj(boost::ref(*b));

or

		object newInstance = typeObj(ptr(b));

Will get you over this particular hurdle.

But you have major ownership issues.  Your B object ought to be
created within a Python object

	pyB = class_<B>("B", init<float>())
		.add_property("value", &B::Value, &B::SetValue)
		;

    ...
    object b = pyB(10);

or held by a shared_ptr:

	boost::shared_ptr<B> b(new B(10));

Your A ought to hold a shared_ptr<B>, and you shouldn't use
return_internal_reference on GetB: that's only for when the return
value is a subobject of an argument to the method (self in this case).

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

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



From python at cityofdreams.com  Mon Jul 12 09:35:47 2004
From: python at cityofdreams.com (Peter)
Date: Mon, 12 Jul 2004 03:35:47 -0400
Subject: [C++-sig] TIB/Rv API Wrapper?
Message-ID: <E1BjvLn-00046e-Qu@sinope.affordablehost.com>

Boost.Python developers,

I remember seeing some time ago that someone was attempting to wrap 
the TIB RV API using the Boost.Python library.  Did anything come of 
that?  This would be quite useful and I am considering doing something 
similar if no one has already done this.

Thanks,
Peter



From gaiacrtn at free.fr  Mon Jul 12 09:58:32 2004
From: gaiacrtn at free.fr (Baptiste Lepilleur)
Date: Mon, 12 Jul 2004 09:58:32 +0200
Subject: [C++-sig] Pyste: patch to be more Makefile friendly
Message-ID: <007801c467e6$0706ed50$c782223e@lain>

    I added two command-line options to pyste to make it easier to integrate
in scons build script:
    --gcxml-path: to specify the absolute path of gccxml instead of relying
on the environment variable PATH
    --no-default-include: to tell pyste not to use the include specified in
the environment variable INCLUDE.

    Notes, that I also removed the extra '_' (not included in the patch)
that was added in MultipleCodeUnit.py before the output filename specified
with --out=. This would have made the build script more complicated than
necessary. What was the motivation for that 'feature' ?

    Baptiste.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pyste-environ-patch.txt
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20040712/68e1b2e0/attachment.txt>

From Holger.Joukl at LBBW.de  Mon Jul 12 12:14:20 2004
From: Holger.Joukl at LBBW.de (Holger Joukl)
Date: Mon, 12 Jul 2004 12:14:20 +0200
Subject: [C++-sig] TIB/Rv API Wrapper?
Message-ID: <OF45D8FEDD.9F30F48E-ONC1256ECF.00344885@lbbw.sko.de>


Hi there,
I experimented with boost 1.31.0 and pyste some time ago to wrap the
TIB/Rv-API 7.2.
Unfortunately, I did not have the time to really look into that, but first
tries were promising.
Actually I had the most problems with the bjam build mechanisms ;-).
I could post the .pyste files I used, wrapping just as much to have a basic
Rv listener receiving data.

We are currently using a heavily modified version of boost 1 (1.27, I
think) with an also
heavily modified version of Shigeru Chiba?s OpenC++ parser to automatically
wrap
the Rv API. The OpenC++ parser takes the role of pyste in our scenario.

This is used in python 1.5.2 based production code. As we are migrating to
python 2.3.4
right now, we are thinking about substituting our wrapping solution with a
newer boost
("Boost version 2") and pyste, to reduce complexity on our side. But I
don?t think
we?ll be able to do that until the end of this year/beginning of next year.

G
  Holger

Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene
Empf?nger sind oder falls diese E-Mail irrt?mlich an Sie adressiert wurde,
verst?ndigen Sie bitte den Absender sofort und l?schen Sie die E-Mail
sodann. Das unerlaubte Kopieren sowie die unbefugte ?bermittlung sind nicht
gestattet. Die Sicherheit von ?bermittlungen per E-Mail kann nicht
garantiert werden. Falls Sie eine Best?tigung w?nschen, fordern Sie bitte
den Inhalt der E-Mail als Hardcopy an.

The contents of this  e-mail are confidential. If you are not the named
addressee or if this transmission has been addressed to you in error,
please notify the sender immediately and then delete this e-mail.  Any
unauthorized copying and transmission is forbidden. E-Mail transmission
cannot be guaranteed to be secure. If verification is required, please
request a hard copy version.


From dave at boost-consulting.com  Mon Jul 12 14:55:26 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 12 Jul 2004 08:55:26 -0400
Subject: [C++-sig] Re: TIB/Rv API Wrapper?
References: <OF45D8FEDD.9F30F48E-ONC1256ECF.00344885@lbbw.sko.de>
Message-ID: <usmbxo05d.fsf@boost-consulting.com>

"Holger Joukl" <Holger.Joukl at LBBW.de> writes:

> Actually I had the most problems with the bjam build mechanisms ;-).

What were the problems?
-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From Holger.Joukl at LBBW.de  Mon Jul 12 15:39:37 2004
From: Holger.Joukl at LBBW.de (Holger Joukl)
Date: Mon, 12 Jul 2004 15:39:37 +0200
Subject: [C++-sig] Re: TIB/Rv API Wrapper? 
Message-ID: <OFAE6A862D.70DC4EF5-ONC1256ECF.004A1036@lbbw.sko.de>


>Dave wrote:
>What were the problems?

I remember two threads concerning build problems:
- building boost.python problems: problem had to to with objcopy step, Rene
Rivera submitted a patch
- boost.build: How to set runtime library paths in a Jamfile (wrapping 3rd
party libs): about how to
set a runtime library search path (btw: this is what you set with the
parameter "runtime_library_dirs" in python
distutils terminology)

Best regards
  Holger

Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene
Empf?nger sind oder falls diese E-Mail irrt?mlich an Sie adressiert wurde,
verst?ndigen Sie bitte den Absender sofort und l?schen Sie die E-Mail
sodann. Das unerlaubte Kopieren sowie die unbefugte ?bermittlung sind nicht
gestattet. Die Sicherheit von ?bermittlungen per E-Mail kann nicht
garantiert werden. Falls Sie eine Best?tigung w?nschen, fordern Sie bitte
den Inhalt der E-Mail als Hardcopy an.

The contents of this  e-mail are confidential. If you are not the named
addressee or if this transmission has been addressed to you in error,
please notify the sender immediately and then delete this e-mail.  Any
unauthorized copying and transmission is forbidden. E-Mail transmission
cannot be guaranteed to be secure. If verification is required, please
request a hard copy version.


From dioselin at purdue.edu  Tue Jul 13 01:26:58 2004
From: dioselin at purdue.edu (Dioselin Gonzalez)
Date: Mon, 12 Jul 2004 18:26:58 -0500
Subject: [C++-sig] [newbie] wrapping a class with argc and argv
Message-ID: <40F31E42.7080900@purdue.edu>

Hi everybody! a couple of questions from a newbie learning boost.python

(1) I want to wrap a class which takes arguments from the command line:
class foo {
foo(int *argc, char **argv);
<...>}

I would like to have a class in python like this:
import sys
myfoo = foo(len(sys.argv), sys.argv)

How do I define it?  From what I read, I could use arg_from_python or a 
thin wrapper for this, but I can't find any examples on how they work.  
Would anybody help me with a sample code?

(2) Where can I get sample codes for boost.python? There are a lot of 
documents explaining the "theory", but sometimes they are pretty obscure 
without examples.

Thanks!

Dioselin.-




From s_sourceforge at nedprod.com  Tue Jul 13 04:04:19 2004
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 13 Jul 2004 03:04:19 +0100
Subject: [C++-sig] [newbie] wrapping a class with argc and argv
In-Reply-To: <40F31E42.7080900@purdue.edu>
Message-ID: <40F35133.31024.316A87E3@localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12 Jul 2004 at 18:26, Dioselin Gonzalez wrote:

> I would like to have a class in python like this:
> import sys
> myfoo = foo(len(sys.argv), sys.argv)
> 
> How do I define it?  From what I read, I could use arg_from_python or
> a thin wrapper for this, but I can't find any examples on how they
> work.  Would anybody help me with a sample code?

You'll need to hand wrap the char *[]. Look through the c++-sig 
mailing list archives and there's plenty on that.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBQPNDJMEcvDLFGKbPEQLdzQCgk3SKRshKj0C4vZFfk3CXATonsNgAnjcD
0I5eZbzp6Fgp1GRIfECcr+Le
=CCgs
-----END PGP SIGNATURE-----


From ndbecker2 at verizon.net  Tue Jul 13 20:29:35 2004
From: ndbecker2 at verizon.net (Neal D. Becker)
Date: Tue, 13 Jul 2004 14:29:35 -0400
Subject: [C++-sig] operators and avoiding copying
Message-ID: <cd19mf$6qg$1@sea.gmane.org>

I want to learn how to implement operators (for arithmetic) while avoiding
copying large objects.

Let's say I have this:

template<typename T>
struct MyVec : public std::vector<T>, boost::addable<MyVec<T> > {
  MyVec(){}
  template<typename in_t>
  MyVec (in_t in, in_t inend) : std::vector<T> (in, inend) {}
  MyVec (size_t i) : std::vector<T> (i) {}

  MyVec& operator+=(MyVec const& rhs) {
    for (size_t i = 0; i < size(); i++)
      (*this)[i] += rhs[i];
    return *this;
  }
};

typedef MyVec<double> DMyVec;

The reason for using MyVec rather than directly wrapping std::vector is to
derive from addable.  This code seems to compile OK:

BOOST_PYTHON_MODULE(STL)
{    

  class_<DMyVec>("MVec")
    .def(init<size_t>())
    .def(init<const DMyVec&>())
   .def("size", &DMyVec::size)
    .def("resize", (void (DMyVec::*)(size_t, const
double&) )&DMyVec::resize)
    .def("resize", (void (DMyVec::*)(size_t) )&DMyVec::resize)
    .def(vector_indexing_suite<DMyVec>())
    .def (self + other<DMyVec>())
    .def (self += self)
    ;

Question is, does it make unnecessary copies of the vectors and if so, how
to avoid this?  I'd assume that return value optimization is possible.  Any
way to learn more?  Staring at the code is not easy.



From dave at boost-consulting.com  Tue Jul 13 20:53:17 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 13 Jul 2004 14:53:17 -0400
Subject: [C++-sig] Re: operators and avoiding copying
References: <cd19mf$6qg$1@sea.gmane.org>
Message-ID: <ufz7vagde.fsf@boost-consulting.com>

"Neal D. Becker" <ndbecker2 at verizon.net> writes:

> I want to learn how to implement operators (for arithmetic) while avoiding
> copying large objects.
>
>
> Question is, does it make unnecessary copies of the vectors and if so, how
> to avoid this?  I'd assume that return value optimization is possible.  Any
> way to learn more?  Staring at the code is not easy.

I suggest you try using a debugger to find out.  That's what I'd do if
I were going to answer your question.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From itamar at itamarst.org  Wed Jul 14 18:15:57 2004
From: itamar at itamarst.org (Itamar Shtull-Trauring)
Date: Wed, 14 Jul 2004 12:15:57 -0400
Subject: [C++-sig] Making buffer objects using Boost
Message-ID: <1089821757.29334.30.camel@sheriffpony>

Hi,

I'd like to create a Python type with Boost that acts like a buffer
object (http://www.python.org/doc/current/api/buffer-structs.html). The
reason I'm not just using strings or arrays is that I want to allow
custom deallocation strategies for the char* that is being wrapped  (I'm
working on Twisted C++ integration - network protocols that will be
calling something like Transport::write(Deallocator d, char* buf, size_t
buflen).)

Does Boost have the hooks for this?

-- 
Itamar Shtull-Trauring    http://itamarst.org




From itamar at itamarst.org  Wed Jul 14 19:08:01 2004
From: itamar at itamarst.org (Itamar Shtull-Trauring)
Date: Wed, 14 Jul 2004 13:08:01 -0400
Subject: [C++-sig] Making buffer objects using Boost
Message-ID: <1089824880.29322.38.camel@sheriffpony>

Hi,

I'd like to create a Python type with Boost that acts like a buffer
object (http://www.python.org/doc/current/api/buffer-structs.html). The
reason I'm not just using strings or arrays is that I want to allow
custom deallocation strategies for the char* that is being wrapped  (I'm
working on Twisted C++ integration - network protocols that will be
calling something like Transport::write(Deallocator d, char* buf, size_t
buflen).)

Does Boost have the hooks for this?

-- 
Itamar Shtull-Trauring    http://itamarst.org




From dave at boost-consulting.com  Wed Jul 14 21:15:11 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 14 Jul 2004 15:15:11 -0400
Subject: [C++-sig] Re: Making buffer objects using Boost
References: <1089824880.29322.38.camel@sheriffpony>
Message-ID: <ud62ye6yo.fsf@boost-consulting.com>

Itamar Shtull-Trauring <itamar at itamarst.org> writes:

> Hi,
>
> I'd like to create a Python type with Boost that acts like a buffer
> object (http://www.python.org/doc/current/api/buffer-structs.html). The
> reason I'm not just using strings or arrays is that I want to allow
> custom deallocation strategies for the char* that is being wrapped  (I'm
> working on Twisted C++ integration - network protocols that will be
> calling something like Transport::write(Deallocator d, char* buf, size_t
> buflen).)
>
> Does Boost have the hooks for this?

Not yet, sorry.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From itamar at itamarst.org  Wed Jul 14 21:46:34 2004
From: itamar at itamarst.org (Itamar Shtull-Trauring)
Date: Wed, 14 Jul 2004 15:46:34 -0400
Subject: [C++-sig] Re: Making buffer objects using Boost
In-Reply-To: <ud62ye6yo.fsf@boost-consulting.com>
References: <1089824880.29322.38.camel@sheriffpony>
	<ud62ye6yo.fsf@boost-consulting.com>
Message-ID: <1089834393.29326.45.camel@sheriffpony>

In that case, how would I hook up a manually written extension to the
module boost creates?



From dave at boost-consulting.com  Wed Jul 14 22:05:02 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 14 Jul 2004 16:05:02 -0400
Subject: [C++-sig] Re: Making buffer objects using Boost
References: <1089824880.29322.38.camel@sheriffpony>
	<ud62ye6yo.fsf@boost-consulting.com>
	<1089834393.29326.45.camel@sheriffpony>
Message-ID: <uoemibbip.fsf@boost-consulting.com>

Itamar Shtull-Trauring <itamar at itamarst.org> writes:

> In that case, how would I hook up a manually written extension to the
> module boost creates?

Just put the usual code in your module initialization function.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From ndbecker2 at verizon.net  Thu Jul 15 14:09:33 2004
From: ndbecker2 at verizon.net (Neal D. Becker)
Date: Thu, 15 Jul 2004 08:09:33 -0400
Subject: [C++-sig] __call__?
Message-ID: <cd5s5t$ksb$1@sea.gmane.org>

How does one overload __call__?  It doesn't seem to be included in
<boost/python/operators.hpp> or mentioned in the tutorial.



From dave at boost-consulting.com  Thu Jul 15 14:33:13 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 15 Jul 2004 08:33:13 -0400
Subject: [C++-sig] Re: __call__?
References: <cd5s5t$ksb$1@sea.gmane.org>
Message-ID: <usmbt5u2e.fsf@boost-consulting.com>

"Neal D. Becker" <ndbecker2 at verizon.net> writes:

> How does one overload __call__?  It doesn't seem to be included in
> <boost/python/operators.hpp> or mentioned in the tutorial.

You add your operator() as a method called "__call__" ;-)

  class_<Foo>("Foo")
    .def("__call__", &Foo::operator())
    ...
    ;

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From jbrandmeyer at earthlink.net  Sat Jul 17 20:40:52 2004
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Sat, 17 Jul 2004 14:40:52 -0400
Subject: [C++-sig] difficulty with has_back_reference example
Message-ID: <1090089652.16099.55.camel@illuvatar>

I'm trying to get the has_back_reference example to work.  I started
with the example in the reference manual, which has some errors.  I
removed the const qualifier from the free function Y_self, fixed the
name of the 'x' variable in structs X and Y to 'm_x', and fixed the
semicolon usage in has_back_reference<X>.  However, that still isn't
enough to get it to compile.

I have attached the touched-up example, and the error message (GNU G++
3.4.0 on Linux).  This doesn't compile with G++ 3.3.4, either.

Thanks for your help,
-Jonathan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: back_references.cpp
Type: text/x-c++src
Size: 1228 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20040717/66a33dd0/attachment.cpp>
-------------- next part --------------
/usr/include/boost/mpl/aux_/nested_type_wknd.hpp: In instantiation of `boost::mpl::aux::nested_type_wknd<boost::python::has_back_reference<X> >':
/usr/include/boost/mpl/aux_/preprocessed/gcc/or.hpp:21:   instantiated from `boost::mpl::aux::or_impl< false, boost::python::has_back_reference<X>, boost::mpl::bool_< false>, boost::mpl::bool_< false>, boost::mpl::bool_< false> >'
/usr/include/boost/mpl/aux_/preprocessed/gcc/or.hpp:47:   instantiated from `boost::mpl::or_<boost::mpl::not_<boost::is_same<X, X> >, boost::python::has_back_reference<X>, boost::mpl::bool_< false>, boost::mpl::bool_< false>, boost::mpl::bool_< false> >'
/usr/include/boost/mpl/if.hpp:75:   instantiated from `boost::mpl::algo_::if_<boost::mpl::or_<boost::mpl::not_<boost::is_same<X, X> >, boost::python::has_back_reference<X>, boost::mpl::bool_< false>, boost::mpl::bool_< false>, boost::mpl::bool_< false> >, boost::python::objects::value_holder_back_reference<X, X>, boost::python::objects::value_holder<X> >'
/usr/include/boost/python/object/select_holder.hpp:110:   instantiated from `boost::python::objects::detail::select_value_holder<X, X>'
/usr/include/boost/python/object/select_holder.hpp:190:   instantiated from `boost::python::objects::select_holder<X, boost::python::detail::not_specified>'
/usr/include/boost/python/class.hpp:652:   instantiated from `boost::python::class_<T, X1, X2, X3>::class_(const char*, const char*) [with T = X, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]'
back_references.cpp:47:   instantiated from here
/usr/include/boost/mpl/aux_/nested_type_wknd.hpp:32: error: no type named `type' in `struct boost::python::has_back_reference<X>'
/usr/include/boost/mpl/aux_/preprocessed/gcc/or.hpp: In instantiation of `boost::mpl::aux::or_impl< false, boost::python::has_back_reference<X>, boost::mpl::bool_< false>, boost::mpl::bool_< false>, boost::mpl::bool_< false> >':
/usr/include/boost/mpl/aux_/preprocessed/gcc/or.hpp:47:   instantiated from `boost::mpl::or_<boost::mpl::not_<boost::is_same<X, X> >, boost::python::has_back_reference<X>, boost::mpl::bool_< false>, boost::mpl::bool_< false>, boost::mpl::bool_< false> >'
/usr/include/boost/mpl/if.hpp:75:   instantiated from `boost::mpl::algo_::if_<boost::mpl::or_<boost::mpl::not_<boost::is_same<X, X> >, boost::python::has_back_reference<X>, boost::mpl::bool_< false>, boost::mpl::bool_< false>, boost::mpl::bool_< false> >, boost::python::objects::value_holder_back_reference<X, X>, boost::python::objects::value_holder<X> >'
/usr/include/boost/python/object/select_holder.hpp:110:   instantiated from `boost::python::objects::detail::select_value_holder<X, X>'
/usr/include/boost/python/object/select_holder.hpp:190:   instantiated from `boost::python::objects::select_holder<X, boost::python::detail::not_specified>'
/usr/include/boost/python/class.hpp:652:   instantiated from `boost::python::class_<T, X1, X2, X3>::class_(const char*, const char*) [with T = X, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]'
back_references.cpp:47:   instantiated from here
/usr/include/boost/mpl/aux_/preprocessed/gcc/or.hpp:21: error: `value' is not a member of `boost::mpl::aux::nested_type_wknd<boost::python::has_back_reference<X> >'
/usr/include/boost/mpl/if.hpp: In instantiation of `boost::mpl::algo_::if_<boost::mpl::or_<boost::mpl::not_<boost::is_same<X, X> >, boost::python::has_back_reference<X>, boost::mpl::bool_< false>, boost::mpl::bool_< false>, boost::mpl::bool_< false> >, boost::python::objects::value_holder_back_reference<X, X>, boost::python::objects::value_holder<X> >':
/usr/include/boost/python/object/select_holder.hpp:110:   instantiated from `boost::python::objects::detail::select_value_holder<X, X>'
/usr/include/boost/python/object/select_holder.hpp:190:   instantiated from `boost::python::objects::select_holder<X, boost::python::detail::not_specified>'
/usr/include/boost/python/class.hpp:652:   instantiated from `boost::python::class_<T, X1, X2, X3>::class_(const char*, const char*) [with T = X, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]'
back_references.cpp:47:   instantiated from here
/usr/include/boost/mpl/if.hpp:75: error: `value' is not a member of `boost::mpl::or_<boost::mpl::not_<boost::is_same<X, X> >, boost::python::has_back_reference<X>, boost::mpl::bool_< false>, boost::mpl::bool_< false>, boost::mpl::bool_< false> >'
/usr/include/boost/mpl/if.hpp:78: error: `value' is not a member of `boost::mpl::or_<boost::mpl::not_<boost::is_same<X, X> >, boost::python::has_back_reference<X>, boost::mpl::bool_< false>, boost::mpl::bool_< false>, boost::mpl::bool_< false> >'
/usr/include/boost/python/object/select_holder.hpp: In instantiation of `boost::python::objects::detail::select_value_holder<X, X>':
/usr/include/boost/python/object/select_holder.hpp:190:   instantiated from `boost::python::objects::select_holder<X, boost::python::detail::not_specified>'
/usr/include/boost/python/class.hpp:652:   instantiated from `boost::python::class_<T, X1, X2, X3>::class_(const char*, const char*) [with T = X, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]'
back_references.cpp:47:   instantiated from here
/usr/include/boost/python/object/select_holder.hpp:110: error: no type named `type' in `struct boost::mpl::algo_::if_<boost::mpl::or_<boost::mpl::not_<boost::is_same<X, X> >, boost::python::has_back_reference<X>, boost::mpl::bool_< false>, boost::mpl::bool_< false>, boost::mpl::bool_< false> >, boost::python::objects::value_holder_back_reference<X, X>, boost::python::objects::value_holder<X> >'
/usr/include/boost/python/object/select_holder.hpp:116: error: no type named `type' in `struct boost::mpl::algo_::if_<boost::mpl::or_<boost::mpl::not_<boost::is_same<X, X> >, boost::python::has_back_reference<X>, boost::mpl::bool_< false>, boost::mpl::bool_< false>, boost::mpl::bool_< false> >, boost::python::objects::value_holder_back_reference<X, X>, boost::python::objects::value_holder<X> >'
/usr/include/boost/python/class.hpp: In member function `void boost::python::class_<T, X1, X2, X3>::register_holder() [with T = X, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]':
/usr/include/boost/python/class.hpp:651:   instantiated from `boost::python::class_<T, X1, X2, X3>::class_(const char*, const char*) [with T = X, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]'
back_references.cpp:47:   instantiated from here
/usr/include/boost/python/class.hpp:641: error: no type named `type' in `struct boost::python::objects::select_holder<X, boost::python::detail::not_specified>'
/usr/include/boost/python/class.hpp:642: error: no type named `type' in `struct boost::python::objects::select_holder<X, boost::python::detail::not_specified>'
/usr/include/boost/python/class.hpp:642: error: `value' is not a member of `<declaration error>'
/usr/include/boost/python/object/select_holder.hpp: In static member function `static void boost::python::objects::detail::select_value_holder<T, Held>::assert_default_constructible() [with T = X, Held = X]':
/usr/include/boost/python/class.hpp:652:   instantiated from `boost::python::class_<T, X1, X2, X3>::class_(const char*, const char*) [with T = X, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]'
back_references.cpp:47:   instantiated from here
/usr/include/boost/python/object/select_holder.hpp:103: error: no matching function for call to `check_default_constructible(X*, X*, boost::mpl::or_<boost::mpl::not_<boost::is_same<X, X> >, boost::python::has_back_reference<X>, boost::mpl::bool_< false>, boost::mpl::bool_< false>, boost::mpl::bool_< false> >)'
/usr/include/boost/python/object/select_holder.hpp:54: note: candidates are: void boost::python::objects::detail::check_default_constructible(T*, U*, boost::mpl::true_) [with T = X, U = X]
/usr/include/boost/python/object/select_holder.hpp:64: note:                 void boost::python::objects::detail::check_default_constructible(T*, T*, boost::mpl::false_) [with T = X]
/usr/include/boost/python/class.hpp: In function `void boost::python::detail::register_class_to_python(boost::mpl::true_, SelectHolder, T*) [with T = X, SelectHolder = boost::python::objects::select_holder<X, boost::python::detail::not_specified>]':
/usr/include/boost/python/class.hpp:631:   instantiated from `void boost::python::class_<T, X1, X2, X3>::register_() const [with T = X, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]'
/usr/include/boost/python/class.hpp:640:   instantiated from `void boost::python::class_<T, X1, X2, X3>::register_holder() [with T = X, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]'
/usr/include/boost/python/class.hpp:651:   instantiated from `boost::python::class_<T, X1, X2, X3>::class_(const char*, const char*) [with T = X, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]'
back_references.cpp:47:   instantiated from here
/usr/include/boost/python/class.hpp:104: error: no type named `type' in `struct boost::python::objects::select_holder<X, boost::python::detail::not_specified>'
/usr/include/boost/python/class.hpp:105: error: no type named `type' in `struct boost::python::objects::select_holder<X, boost::python::detail::not_specified>'
/usr/include/boost/python/init.hpp: In function `void boost::python::detail::def_init_aux(ClassT&, const Signature&, NArgs, const CallPoliciesT&, const char*, const boost::python::detail::keyword_range&) [with ClassT = boost::python::class_<X, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>, CallPoliciesT = boost::python::default_call_policies, Signature = boost::mpl::vector1<int>, NArgs = boost::mpl::size<boost::mpl::vector1<int> >]':
/usr/include/boost/python/init.hpp:402:   instantiated from `static void boost::python::detail::define_class_init_helper<0>::apply(ClassT&, const CallPoliciesT&, const Signature&, NArgs, const char*, const boost::python::detail::keyword_range&) [with ClassT = boost::python::class_<X, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>, CallPoliciesT = boost::python::default_call_policies, Signature = boost::mpl::vector1<int>, NArgs = boost::mpl::size<boost::mpl::vector1<int> >]'
/usr/include/boost/python/init.hpp:172:   instantiated from `void boost::python::init_base<DerivedT>::visit(classT&) const [with classT = boost::python::class_<X, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>, 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_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_>]'
/usr/include/boost/python/def_visitor.hpp:32:   instantiated from `static void boost::python::def_visitor_access::visit(const V&, classT&) [with V = boost::python::def_visitor<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_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_> >, classT = boost::python::class_<X, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>]'
/usr/include/boost/python/def_visitor.hpp:68:   instantiated from `void boost::python::def_visitor<DerivedVisitor>::visit(classT&) const [with classT = boost::python::class_<X, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>, DerivedVisitor = 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_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_>]'
/usr/include/boost/python/class.hpp:294:   instantiated from `boost::python::class_<T, X1, X2, X3>& boost::python::class_<T, X1, X2, X3>::def(const boost::python::def_visitor<Derived>&) [with Derived = 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_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_>, T = X, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]'
back_references.cpp:48:   instantiated from here
/usr/include/boost/python/init.hpp:333: error: `get' is not a member of `boost::python::objects::select_holder<X, boost::python::detail::not_specified>'
/usr/include/boost/python/init.hpp: In function `void boost::python::detail::def_init_aux(ClassT&, const Signature&, NArgs, const CallPoliciesT&, const char*, const boost::python::detail::keyword_range&) [with ClassT = boost::python::class_<X, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>, CallPoliciesT = boost::python::default_call_policies, Signature = boost::mpl::vector0<boost::mpl::void_>, NArgs = boost::mpl::size<boost::mpl::vector0<boost::mpl::void_> >]':
/usr/include/boost/python/init.hpp:402:   instantiated from `static void boost::python::detail::define_class_init_helper<0>::apply(ClassT&, const CallPoliciesT&, const Signature&, NArgs, const char*, const boost::python::detail::keyword_range&) [with ClassT = boost::python::class_<X, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>, CallPoliciesT = boost::python::default_call_policies, Signature = boost::mpl::vector0<boost::mpl::void_>, NArgs = boost::mpl::size<boost::mpl::vector0<boost::mpl::void_> >]'
/usr/include/boost/python/init.hpp:172:   instantiated from `void boost::python::init_base<DerivedT>::visit(classT&) const [with classT = boost::python::class_<X, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>, DerivedT = boost::python::init<boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_>]'
/usr/include/boost/python/def_visitor.hpp:32:   instantiated from `static void boost::python::def_visitor_access::visit(const V&, classT&) [with V = boost::python::def_visitor<boost::python::init<boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_> >, classT = boost::python::class_<X, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>]'
/usr/include/boost/python/def_visitor.hpp:68:   instantiated from `void boost::python::def_visitor<DerivedVisitor>::visit(classT&) const [with classT = boost::python::class_<X, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>, DerivedVisitor = boost::python::init<boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_>]'
/usr/include/boost/python/class.hpp:294:   instantiated from `boost::python::class_<T, X1, X2, X3>& boost::python::class_<T, X1, X2, X3>::def(const boost::python::def_visitor<Derived>&) [with Derived = boost::python::init<boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_, boost::mpl::void_>, T = X, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]'
/usr/include/boost/python/class.hpp:653:   instantiated from `boost::python::class_<T, X1, X2, X3>::class_(const char*, const char*) [with T = X, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]'
back_references.cpp:47:   instantiated from here
/usr/include/boost/python/init.hpp:333: error: `get' is not a member of `boost::python::objects::select_holder<X, boost::python::detail::not_specified>'

From dave at boost-consulting.com  Sat Jul 17 21:17:50 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 17 Jul 2004 15:17:50 -0400
Subject: [C++-sig] Re: difficulty with has_back_reference example
References: <1090089652.16099.55.camel@illuvatar>
Message-ID: <uwu12tpcx.fsf@boost-consulting.com>

Jonathan Brandmeyer <jbrandmeyer at earthlink.net> writes:

> I'm trying to get the has_back_reference example to work.  I started
> with the example in the reference manual, which has some errors.  I
> removed the const qualifier from the free function Y_self, fixed the
> name of the 'x' variable in structs X and Y to 'm_x', and fixed the
> semicolon usage in has_back_reference<X>.  However, that still isn't
> enough to get it to compile.
>
> I have attached the touched-up example, and the error message (GNU G++
> 3.4.0 on Linux).  This doesn't compile with G++ 3.3.4, either.

See libs/python/test/back_reference.cpp in your boost distribution,
which does compile.  Would you mind posting a patch to correct the
documentation (or just checking in the fix once you know what it is
if you have checkin privs)?

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Sat Jul 17 21:21:27 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 17 Jul 2004 15:21:27 -0400
Subject: [C++-sig] Re: difficulty with has_back_reference example
References: <1090089652.16099.55.camel@illuvatar>
	<uwu12tpcx.fsf@boost-consulting.com>
Message-ID: <ur7ratp6w.fsf@boost-consulting.com>

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

> Jonathan Brandmeyer <jbrandmeyer at earthlink.net> writes:
>
>> I'm trying to get the has_back_reference example to work.  I started
>> with the example in the reference manual, which has some errors.  I
>> removed the const qualifier from the free function Y_self, fixed the
>> name of the 'x' variable in structs X and Y to 'm_x', and fixed the
>> semicolon usage in has_back_reference<X>.  However, that still isn't
>> enough to get it to compile.
>>
>> I have attached the touched-up example, and the error message (GNU G++
>> 3.4.0 on Linux).  This doesn't compile with G++ 3.3.4, either.
>
> See libs/python/test/back_reference.cpp in your boost distribution,
> which does compile.  Would you mind posting a patch to correct the
> documentation (or just checking in the fix once you know what it is
> if you have checkin privs)?

The problem is that has_back_reference<T> needs to be a metafunction.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From jbrandmeyer at earthlink.net  Sun Jul 18 16:37:51 2004
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Sun, 18 Jul 2004 10:37:51 -0400
Subject: [C++-sig] Re: difficulty with has_back_reference example
In-Reply-To: <ur7ratp6w.fsf@boost-consulting.com>
References: <1090089652.16099.55.camel@illuvatar>
	<uwu12tpcx.fsf@boost-consulting.com>
	<ur7ratp6w.fsf@boost-consulting.com>
Message-ID: <1090161470.3069.7.camel@illuvatar>

On Sat, 2004-07-17 at 15:21, David Abrahams wrote:
> David Abrahams <dave at boost-consulting.com> writes:
> > See libs/python/test/back_reference.cpp in your boost distribution,
> > which does compile.  Would you mind posting a patch to correct the
> > documentation (or just checking in the fix once you know what it is
> > if you have checkin privs)?
> 
> The problem is that has_back_reference<T> needs to be a metafunction.

Thanks for the diagnosis.  Rather than raise the requirement of
has_back_reference<T> from being a traits class to a predicate
metafunction, would you accept the following patch?  It basically
performs a metacast from a predicate traits struct to a metafuction.  I
will be happy to apply the right patches in either case.

Thanks,
Jonathan

===================================================================
RCS file: /cvsroot/boost/boost/boost/python/object/select_holder.hpp,v
retrieving revision 1.19
diff -u -r1.19 select_holder.hpp
--- select_holder.hpp   25 Aug 2003 18:41:02 -0000      1.19
+++ select_holder.hpp   18 Jul 2004 14:30:23 -0000
@@ -94,7 +94,7 @@
    private:
       typedef mpl::or_<
           mpl::not_<is_same<T,Held> >
-        , has_back_reference<T>
+        , mpl::bool_<has_back_reference<T>::value>
       > use_back_ref;

    public:
@@ -123,7 +123,7 @@
       typedef typename python::pointee<Ptr>::type wrapper;
       typedef mpl::or_<
           mpl::not_<is_same<T,wrapper> >
-        , has_back_reference<T>
+        , mpl::bool_<has_back_reference<T>::value>
       > use_back_ref;

    public:




From dave at boost-consulting.com  Sun Jul 18 17:58:21 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 18 Jul 2004 11:58:21 -0400
Subject: [C++-sig] Re: difficulty with has_back_reference example
References: <1090089652.16099.55.camel@illuvatar>
	<uwu12tpcx.fsf@boost-consulting.com>
	<ur7ratp6w.fsf@boost-consulting.com>
	<1090161470.3069.7.camel@illuvatar>
Message-ID: <uk6x1nw82.fsf@boost-consulting.com>

Jonathan Brandmeyer <jbrandmeyer at earthlink.net> writes:

> On Sat, 2004-07-17 at 15:21, David Abrahams wrote:
>> David Abrahams <dave at boost-consulting.com> writes:
>> > See libs/python/test/back_reference.cpp in your boost distribution,
>> > which does compile.  Would you mind posting a patch to correct the
>> > documentation (or just checking in the fix once you know what it is
>> > if you have checkin privs)?
>> 
>> The problem is that has_back_reference<T> needs to be a metafunction.
>
> Thanks for the diagnosis.  Rather than raise the requirement of
> has_back_reference<T> from being a traits class to a predicate
> metafunction, would you accept the following patch?  It basically
> performs a metacast from a predicate traits struct to a metafuction.  I
> will be happy to apply the right patches in either case.

I'm afraid not.  I'm actually in the process or reworking and
cleaning up that whole area of the code.  The metafunction protocol
is the emergent Boost standard; has_back_reference doesn't need to
inherit from mpl::bool_<x>, but it does need to have a nested ::type
with a nested ::value.

Cheers,

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From bhall at gamers-fix.com  Sun Jul 18 18:54:36 2004
From: bhall at gamers-fix.com (Brian Hall)
Date: Sun, 18 Jul 2004 11:54:36 -0500
Subject: [C++-sig] Builtin python functions and the Object Wrapper
Message-ID: <20040718165431.6F12D1E4002@bag.python.org>

Say I want to implement the following python code in C++ using the object
wrapper:

 

def tb_lineno(tb):

 

    c = tb.tb_frame.f_code

    if not hasattr(c, 'co_lnotab'):

        return tb.tb_lineno

 

    tab = c.co_lnotab

    line = c.co_firstlineno

    stopat = tb.tb_lasti

    addr = 0

    for i in range(0, len(tab), 2):

        addr = addr + ord(tab[i])

        if addr > stopat:

            break

        line = line + ord(tab[i+1])

    return line

 

 

How would I gain access to the len() and ord() builtin methods?

 

Thanks!

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

From jbrandmeyer at earthlink.net  Sun Jul 18 19:54:08 2004
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Sun, 18 Jul 2004 13:54:08 -0400
Subject: [C++-sig] Re: difficulty with has_back_reference example
In-Reply-To: <uk6x1nw82.fsf@boost-consulting.com>
References: <1090089652.16099.55.camel@illuvatar>
	<uwu12tpcx.fsf@boost-consulting.com>
	<ur7ratp6w.fsf@boost-consulting.com>
	<1090161470.3069.7.camel@illuvatar>
	<uk6x1nw82.fsf@boost-consulting.com>
Message-ID: <1090173247.3069.21.camel@illuvatar>

On Sun, 2004-07-18 at 11:58, David Abrahams wrote:
> Jonathan Brandmeyer <jbrandmeyer at earthlink.net> writes:
> 
> > On Sat, 2004-07-17 at 15:21, David Abrahams wrote:
> >> David Abrahams <dave at boost-consulting.com> writes:
> >> > See libs/python/test/back_reference.cpp in your boost distribution,
> >> > which does compile.  Would you mind posting a patch to correct the
> >> > documentation (or just checking in the fix once you know what it is
> >> > if you have checkin privs)?
> >> 
> >> The problem is that has_back_reference<T> needs to be a metafunction.
> >
> > Thanks for the diagnosis.  Rather than raise the requirement of
> > has_back_reference<T> from being a traits class to a predicate
> > metafunction, would you accept the following patch?  It basically
> > performs a metacast from a predicate traits struct to a metafuction.  I
> > will be happy to apply the right patches in either case.
> 
> I'm afraid not.  I'm actually in the process or reworking and
> cleaning up that whole area of the code.  The metafunction protocol
> is the emergent Boost standard; has_back_reference doesn't need to
> inherit from mpl::bool_<x>, but it does need to have a nested ::type
> with a nested ::value.

OK.  I've fixed the docs.

Thanks,
-Jonathan



From jmastro at rochester.rr.com  Sun Jul 18 21:50:42 2004
From: jmastro at rochester.rr.com (James Mastro)
Date: Sun, 18 Jul 2004 15:50:42 -0400
Subject: [C++-sig] extracting C++ objects
Message-ID: <6.1.0.6.0.20040718151503.01b69448@pop-server.rochester.rr.com>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20040718/5e4f5a7d/attachment.htm>

From dave at boost-consulting.com  Mon Jul 19 00:23:29 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 18 Jul 2004 18:23:29 -0400
Subject: [C++-sig] Re: Builtin python functions and the Object Wrapper
References: <20040718165431.6F12D1E4002@bag.python.org>
Message-ID: <u7jt1lztq.fsf@boost-consulting.com>

"Brian Hall" <bhall at gamers-fix.com> writes:

> Say I want to implement the following python code in C++ using the object
> wrapper:
>
>  
>
> def tb_lineno(tb):
>
>  
>
>     c = tb.tb_frame.f_code
>
>     if not hasattr(c, 'co_lnotab'):
>
>         return tb.tb_lineno
>
>  
>
>     tab = c.co_lnotab
>
>     line = c.co_firstlineno
>
>     stopat = tb.tb_lasti
>
>     addr = 0
>
>     for i in range(0, len(tab), 2):
>
>         addr = addr + ord(tab[i])
>
>         if addr > stopat:
>
>             break
>
>         line = line + ord(tab[i+1])
>
>     return line
>
>  
>
>  
>
> How would I gain access to the len() and ord() builtin methods?

There's nothing in the library for those, though there should be.
len() is x.attr("__len__")(), but I think you need to go directly to
the Python/C API for "ord" (I'm not sure).

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Mon Jul 19 00:24:24 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 18 Jul 2004 18:24:24 -0400
Subject: [C++-sig] Re: extracting C++ objects
References: <6.1.0.6.0.20040718151503.01b69448@pop-server.rochester.rr.com>
Message-ID: <u1xj9lzs7.fsf@boost-consulting.com>

James Mastro <jmastro at rochester.rr.com> writes:

> Hello again list. I'm back in the boost.python game after a number of
> months off, this time on Win XP.
> I want to be able to create Python instances from C++. These Python
> instances hold wrapped C++ instances that I want to extract. For example,
> I have a class called SomeObject that holds a wrapped C++ class called
> MyPoint which is it's location onscreen. MyPoint is a class holding a
> double for both x and y. Here's the Python code:
>
> import
> JimsModule<x-tab>       </x-tab>#where
> the wrapped MyPoint is

<snip garbage>

Jim, I think you'd better try posting in plaintext.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From jmastro at rochester.rr.com  Mon Jul 19 01:22:17 2004
From: jmastro at rochester.rr.com (James Mastro)
Date: Sun, 18 Jul 2004 19:22:17 -0400
Subject: [C++-sig] Re: extracting C++ objects
In-Reply-To: <u1xj9lzs7.fsf@boost-consulting.com>
References: <6.1.0.6.0.20040718151503.01b69448@pop-server.rochester.rr.com>
	<u1xj9lzs7.fsf@boost-consulting.com>
Message-ID: <6.1.0.6.0.20040718185259.01b593a0@pop-server.rochester.rr.com>

At 06:24 PM 7/18/2004, you wrote:

>Jim, I think you'd better try posting in plaintext.

Oops. You'd think C++ comments showing up in red in Eudora would have been 
a good clue that something was up. This should be OK. Sorry about that.

My problem is I can't extract a C++ object out of a Python object. MyPoint 
is a simple class storing doubles for x and y. SomeObject is an object 
onscreen, location is its location. Here's the Python:

import JimsModule       #where the wrapped MyPoint is

class SomeObject:

     def __init__(self):
         self.num = 942
         self.location = JimsModule.MyPoint( 3.2, -4.7 )

     def getPt(self):
         return self.location

     def getX(self):
         return self.location.x

Here's the C++:

handle<>        (PyImport_ImportModule( "SomeObject" ) );       // 
SomeObject class is in SomeObject.py module
handle<>        module( borrowed( PyImport_AddModule( "SomeObject" ) ) );
handle<>        the_namespace(borrowed( PyModule_GetDict(module.get()) ));
object          the_class( borrowed( 
PyDict_GetItemString(the_namespace.get(), "SomeObject") ));

object  obj = the_class();

handle<> a( PyObject_CallMethod( obj.ptr(), "getX", NULL ) );
double  val = extract<double>( a.get() );                       // returns 3.2
int     num = extract<int>(obj.attr("num"));            // returns 942

So I can extract POD fine. But what about getting my C++ MyPoint object out?

extract<MyPoint&> ck(obj.attr("location"));
if ( ck.check() ) {
     MyPoint&    myPt = extract<MyPoint&>(obj.attr("location"));
}

ck.check() returns false, and ignoring it and attempting the extraction 
anyway throws an exception saying "TypeError: No registered converter was 
able to extract a C++ reference to type class MyPoint from this Python 
object of type MyPoint". Using the getPt method with call_method, etc, gave 
me the same error. Trying to get a MyPoint object, or a MyPoint* out gives 
me similar errors.

How can I pull my C++ object out of the Python object?

-jim



From dave at boost-consulting.com  Mon Jul 19 04:28:08 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 18 Jul 2004 22:28:08 -0400
Subject: [C++-sig] Re: extracting C++ objects
References: <6.1.0.6.0.20040718151503.01b69448@pop-server.rochester.rr.com>
	<u1xj9lzs7.fsf@boost-consulting.com>
	<6.1.0.6.0.20040718185259.01b593a0@pop-server.rochester.rr.com>
Message-ID: <uzn5wk9xj.fsf@boost-consulting.com>

James Mastro <jmastro at rochester.rr.com> writes:

> At 06:24 PM 7/18/2004, you wrote:
>
>>Jim, I think you'd better try posting in plaintext.
>
> Oops. You'd think C++ comments showing up in red in Eudora would have
> been a good clue that something was up. This should be OK. Sorry about
> that.
>
> My problem is I can't extract a C++ object out of a Python
> object. MyPoint is a simple class storing doubles for x and
> y. SomeObject is an object onscreen, location is its location. Here's
> the Python:
>
> import JimsModule       #where the wrapped MyPoint is
>
> class SomeObject:
>
>      def __init__(self):
>          self.num = 942
>          self.location = JimsModule.MyPoint( 3.2, -4.7 )
>
>      def getPt(self):
>          return self.location
>
>      def getX(self):
>          return self.location.x
>
> Here's the C++:
>
> handle<> (PyImport_ImportModule( "SomeObject" ) );  // SomeObject class is in SomeObject.py module
> handle<> module( borrowed( PyImport_AddModule( "SomeObject" ) ) );
> handle<> the_namespace(borrowed( PyModule_GetDict(module.get()) ));
> object the_class( 
>             borrowed( PyDict_GetItemString(the_namespace.get(), "SomeObject") ));

I'm a little surprised that compiles ( and do you really need to do
PyImport_AddModule?), but anyway, you should do:

object module( 
        handle<>( borrowed( PyImport_AddModule( "SomeObject" ) ) ) );

object the_class = module.attr("SomeObject");

> object  obj = the_class();
>
> handle<> a( PyObject_CallMethod( obj.ptr(), "getX", NULL ) );

Bleah.  Should be:

  object a = obj.attr("getX")();

> double  val = extract<double>( a.get() );                       // returns 3.2

surprised this compiles too.

  double val = extract<double>(a);

is better.

> int     num = extract<int>(obj.attr("num"));            // returns 942

Hooray!

> So I can extract POD fine. But what about getting my C++ MyPoint object out?
>
> extract<MyPoint&> ck(obj.attr("location"));
> if ( ck.check() ) {
>      MyPoint&    myPt = extract<MyPoint&>(obj.attr("location"));

Bleah. Should be:

       MyPoint& myPt = ck();
> }
>
> ck.check() returns false, and ignoring it and attempting the
> extraction anyway throws an exception saying "TypeError: No registered
> converter was able to extract a C++ reference to type class MyPoint
> from this Python object of type MyPoint". 

1. Did you wrap MyPoint with class_<MyPoint> and has the extension
   module that does that wrapping been loaded at this point?

2. Does it work if you do it in two steps?

   object pt = obj.attr("location");
   MyPoint& myPt = extract<MyPoint&>(pt);
   
> Using the getPt method with
> call_method, etc, gave me the same error. Trying to get a MyPoint
> object, or a MyPoint* out gives me similar errors.
>
> How can I pull my C++ object out of the Python object?

If all this fails, please post a minimal but complete reproducible
example (as an attachment).

Thanks,
-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From jmastro at rochester.rr.com  Mon Jul 19 05:54:23 2004
From: jmastro at rochester.rr.com (James Mastro)
Date: Sun, 18 Jul 2004 23:54:23 -0400
Subject: [C++-sig] Re: extracting C++ objects
In-Reply-To: <uzn5wk9xj.fsf@boost-consulting.com>
References: <6.1.0.6.0.20040718151503.01b69448@pop-server.rochester.rr.com>
	<u1xj9lzs7.fsf@boost-consulting.com>
	<6.1.0.6.0.20040718185259.01b593a0@pop-server.rochester.rr.com>
	<uzn5wk9xj.fsf@boost-consulting.com>
Message-ID: <6.1.0.6.0.20040718233928.01bebec0@pop-server.rochester.rr.com>

At 10:28 PM 7/18/2004, you wrote:
>1. Did you wrap MyPoint with class_<MyPoint> and has the extension
>    module that does that wrapping been loaded at this point?

This is the code for the C++ class and the wrapping. I took out everything 
but a constructor, but I have the same problems. It's loaded because the 
Python object is using it right before I try to extract the object.

class MyPoint    {
     public:
         MyPoint() {}
};

BOOST_PYTHON_MODULE(JimsModule)
{
     class_<MyPoint>("MyPoint", init<>())
     ;
}


>2. Does it work if you do it in two steps?
>
>    object pt = obj.attr("location");
>    MyPoint& myPt = extract<MyPoint&>(pt);

Nope...same result.

Thanks for your comments in the last email. 100 times simpler and cleaner 
now, and no I didn't need PyImport_AddModule in there. I'll put together a 
example of this problem and post it.

-jim 



From roman.yakovenko at actimize.com  Mon Jul 19 08:53:32 2004
From: roman.yakovenko at actimize.com (Roman Yakovenko)
Date: Mon, 19 Jul 2004 09:53:32 +0300
Subject: [C++-sig] boost.python on linux using bjam
Message-ID: <2D89F6C4A80FA547BF5D5B8FDDD04523060CA3@exchange.adrembi.com>

	Hi. I am trying to compile boost.python on Linux so far without success.
The reason: I can't setup python location. 
The tools I am using are: 
	bjam 3.1.10 with build system 2 ( bjam --v2 ).
	Python 2.3.
	gentoo 2004.1

Detailes:
I have 2 problems:
	1. Where should I write PYTHON_ROOT and PYTHON_VERSION? 
	   I don't want to pass this as parameters to bjam.
	   I read http://tinyurl.com/5fz2o but it doesn't say where to write them.
	2. It seams that Jamfile.v2 works only with python 2.2 
	   and also doesn't use PYTHON_ROOT and PYTHON_VERSION.
	   I can try to fix Jamfile.v2 
	   ( I am sure I will need help with this ).	 
		

Thanks.

Roman


From dave at boost-consulting.com  Mon Jul 19 15:34:54 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 19 Jul 2004 09:34:54 -0400
Subject: [C++-sig] Re: boost.python on linux using bjam
References: <2D89F6C4A80FA547BF5D5B8FDDD04523060CA3@exchange.adrembi.com>
Message-ID: <u658km875.fsf@boost-consulting.com>

"Roman Yakovenko" <roman.yakovenko at actimize.com> writes:

> 	Hi. I am trying to compile boost.python on Linux so far without success.
> The reason: I can't setup python location. 
> The tools I am using are: 
> 	bjam 3.1.10 with build system 2 ( bjam --v2 ).

You're asking the wrong people.  Only Boost.Build v1 is officially
supported for Boost.Python.  

If you want to use v2, post your questions at
http://www.boost.org/more/mailing_lists.htm#jamboost


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



From jmastro at rochester.rr.com  Mon Jul 19 22:29:59 2004
From: jmastro at rochester.rr.com (James Mastro)
Date: Mon, 19 Jul 2004 16:29:59 -0400
Subject: [C++-sig] Re: extracting C++ objects
In-Reply-To: <uzn5wk9xj.fsf@boost-consulting.com>
References: <6.1.0.6.0.20040718151503.01b69448@pop-server.rochester.rr.com>
	<u1xj9lzs7.fsf@boost-consulting.com>
	<6.1.0.6.0.20040718185259.01b593a0@pop-server.rochester.rr.com>
	<uzn5wk9xj.fsf@boost-consulting.com>
Message-ID: <6.1.0.6.0.20040719162348.01bcee88@pop-server.rochester.rr.com>

At 10:28 PM 7/18/2004, David Abrahams wrote:
>If all this fails, please post a minimal but complete reproducible
>example (as an attachment).

I'm trying to post my example attachment here but it keeps bouncing back to 
me. Mind if I send it to you off-list?

One thing I've noticed after playing around in the Python interpreter is 
that the extension module works perfictly there. I can pass in the wrapped 
class, pass one back from the Python object, etc. all without a problem. 
Some more testing on the C++ side revealed I also can't pass the C++ object 
in to the Python object, and still can't extract it.

-jim 



From dave at boost-consulting.com  Tue Jul 20 00:24:32 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 19 Jul 2004 18:24:32 -0400
Subject: [C++-sig] Re: extracting C++ objects
References: <6.1.0.6.0.20040718151503.01b69448@pop-server.rochester.rr.com>
	<u1xj9lzs7.fsf@boost-consulting.com>
	<6.1.0.6.0.20040718185259.01b593a0@pop-server.rochester.rr.com>
	<uzn5wk9xj.fsf@boost-consulting.com>
	<6.1.0.6.0.20040719162348.01bcee88@pop-server.rochester.rr.com>
Message-ID: <uoembfxen.fsf@boost-consulting.com>

James Mastro <jmastro at rochester.rr.com> writes:

> At 10:28 PM 7/18/2004, David Abrahams wrote:
>>If all this fails, please post a minimal but complete reproducible
>>example (as an attachment).
>
> I'm trying to post my example attachment here but it keeps bouncing
> back to me. Mind if I send it to you off-list?

Not at all, please do (compressed!)

> One thing I've noticed after playing around in the Python interpreter
> is that the extension module works perfictly there. I can pass in the
> wrapped class, pass one back from the Python object, etc. all without
> a problem. Some more testing on the C++ side revealed I also can't
> pass the C++ object in to the Python object, and still can't extract
> it.

I'll see it when I get it.  I'm expecting one C++ source file and one
Python source file.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Tue Jul 20 19:16:26 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 20 Jul 2004 13:16:26 -0400
Subject: [C++-sig] Re: Extracting C++ object from Python problem
In-Reply-To: <6.1.0.6.0.20040720103104.01b4ebb8@pop-server.rochester.rr.com>
	(James Mastro's message of "Tue, 20 Jul 2004 13:00:11 -0400")
References: <6.1.0.6.0.20040720011521.01b3f078@pop-server.rochester.rr.com>
	<uhds3yol1.fsf@boost-consulting.com>
	<6.1.0.6.0.20040720103104.01b4ebb8@pop-server.rochester.rr.com>
Message-ID: <uacxutx91.fsf@boost-consulting.com>

James Mastro <jmastro at rochester.rr.com> writes:

> At 06:12 AM 7/20/2004, David Abrahams wrote:
>>Just for future reference, when I asked for a minimal but complete
>>reproducible example, what I was looking for was a single
>>compilable-and-linkable C++ file,
>
> Sorry. I didn't know you could define the module right there in the
> app source like you did. After I did that, and added
> initPointModule(), it worked fine for me, too. I wondered how you
> expected me to get it in one C++ source and one Python script..now I
> know.
>
> I still couldn't get it working with an extension module I built
> seperately. But having it working at all was encouraging. I decided to
> start over from scratch for the fifth time, this time making doubly
> sure I did everything the tutorial said on embedding
> correctly. Eventually I ended up getting it working! I think my
> problem was either I had libs in the wrong place or the wrong ones or
> something. Actually, I know that's the case because I didn't change a
> thing in the code. After that I went back and made the same changes to
> the problematic project's linker options and fixing lib locations and
> that's working too. So I think I've got it, though it's obvious I need
> to do a good bit of Boost.Python learning still.
>
> As always, thanks for everything and especially for your patience.

Sure thing.  Please carry on these discussion on the c++-sig, though,
so that everyone else can benefit, too.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From igor at pcigeomatics.com  Wed Jul 21 00:05:39 2004
From: igor at pcigeomatics.com (Igor Lapshin)
Date: Tue, 20 Jul 2004 18:05:39 -0400
Subject: [C++-sig] will custom lvalue converters be supported?
Message-ID: <BF0BED91AA17F448A3A927857E11FC64CAE232@thor.pcigeomatics.com>

 

Hi, 

I am wondering if custom lvalue converters are planned to be supported
in near future. The FAQ say that they are not supported, but I found
some declarations in Python.Boost source code, which look as relevant to
lvalue conversions, e.g. void* get_lvalue_from_python(). 

I have almost exactly the situation as it is described in FAQ (but with
my custom classes): 

C++:

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

Python: 

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

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

 

Thanks,

Igor Lapshin



 

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

From dave at boost-consulting.com  Wed Jul 21 00:24:13 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 20 Jul 2004 18:24:13 -0400
Subject: [C++-sig] Re: will custom lvalue converters be supported?
References: <BF0BED91AA17F448A3A927857E11FC64CAE232@thor.pcigeomatics.com>
Message-ID: <uu0w2jp0y.fsf@boost-consulting.com>

"Igor Lapshin" <igor at pcigeomatics.com> writes:

>  
>
> Hi, 
>
> I am wondering if custom lvalue converters are planned to be supported
> in near future. 

There are no such plans.

> The FAQ say that they are not supported, but I found some
> declarations in Python.Boost source code, which look as relevant to
> lvalue conversions, e.g. void* get_lvalue_from_python().

There's nothing in Boost.Python that would allow the example to work.

> I have almost exactly the situation as it is described in FAQ (but
> with my custom classes):

What does the parenthetical remark mean?  Maybe that small difference
means you don't need what's being discussed there.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From rwgk at yahoo.com  Wed Jul 21 01:03:24 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 20 Jul 2004 16:03:24 -0700 (PDT)
Subject: [C++-sig] Re: will custom lvalue converters be supported?
In-Reply-To: <uu0w2jp0y.fsf@boost-consulting.com>
Message-ID: <20040720230324.29026.qmail@web20227.mail.yahoo.com>

--- David Abrahams <dave at boost-consulting.com> wrote:
> "Igor Lapshin" <igor at pcigeomatics.com> writes:
> > I am wondering if custom lvalue converters are planned to be supported
> > in near future. 
> 
> There are no such plans.
> 
> > The FAQ say that they are not supported, but I found some
> > declarations in Python.Boost source code, which look as relevant to
> > lvalue conversions, e.g. void* get_lvalue_from_python().
> 
> There's nothing in Boost.Python that would allow the example to work.
> 
> > I have almost exactly the situation as it is described in FAQ (but
> > with my custom classes):
> 
> What does the parenthetical remark mean?  Maybe that small difference
> means you don't need what's being discussed there.

... and if you really need the behavior outlined in the FAQ you could write a
thin wrapper with boost::python::list in the signature. This is a problem only
if you have a large number of functions with a "write back" requirement.

Ralf



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 


From igor at pcigeomatics.com  Wed Jul 21 17:14:54 2004
From: igor at pcigeomatics.com (Igor Lapshin)
Date: Wed, 21 Jul 2004 11:14:54 -0400
Subject: [C++-sig] Re: will custom lvalue converters be supported?
Message-ID: <BF0BED91AA17F448A3A927857E11FC64CAE24E@thor.pcigeomatics.com>


Hi Ralf and Dave, 

Thanks for the fast response.

That's exactly the case:  there are already hundreds of functions
written with that "write-back" requirement long before we decided to use
Python and it seems to me that writing thin wrappers for all of them is
quite problematic. Moreover, the new functions are still being
written...

The classes, which are used as parameters for those functions, derived
from stl::vector, but have additional member-functions, which I cannot
remove without affecting hundreds of already written functions. Those
additional members are used only internally and not from Python, thus
tuple or sequence functionality is sufficient. I can add new
member-functions, or derive new classes from existing. The current
classes normally don't hold more than 10-100 values and, by convention,
are sent to the functions by references (thus, the function can change
them). As I understand, I have now two options: 

 - don't allow returning values in arguments at all, but that would make
many existing functions unusable;

 - don't do automatic conversions and request that all classes be
instantiated explicitly (what looks ugly to me):

  C++:
      Class CustomVectorInt : public std::vector<int>
	{ ... } // expands vector<int> operations

	int fn(CustomVectorInt &cv1, CustomVectorInt &cv2,.. cvN)
	{
 	  cv1+=cv2; // cv1 is expected to be returned to the caller
	  return 0; // no error
	}

  Python:
	cv1=CustomVectorInt()
	cv1[:]= [1,2,3]
	fn(cv1, cv2, cv3, cv4...) # many functions have >10 parameters
	returnedpythonlist=cv1.to_list() # I'll add conversion function

Am I right?

Is there any way to write a generic thin wrapper supporting "write back"
for various functions with different signatures but with very limited
set of types (we have some 5 types)?

Thanks,
Igor


$-> > > I am wondering if custom lvalue converters are planned to be
$-> supported
$-> > > in near future.
$-> >
$-> > There are no such plans.
$-> >
$-> > > The FAQ say that they are not supported, but I found some
$-> > > declarations in Python.Boost source code, which look as relevant
to
$-> > > lvalue conversions, e.g. void* get_lvalue_from_python().
$-> >
$-> > There's nothing in Boost.Python that would allow the example to
work.
$-> >
$-> > > I have almost exactly the situation as it is described in FAQ
(but
$-> > > with my custom classes):
$-> >
$-> > What does the parenthetical remark mean?  Maybe that small
difference
$-> > means you don't need what's being discussed there.
$-> 
$-> ... and if you really need the behavior outlined in the FAQ you
could
$-> write a
$-> thin wrapper with boost::python::list in the signature. This is a
$-> problem only
$-> if you have a large number of functions with a "write back"
requirement.
$-> 
$-> Ralf
$-> 
$-> 
$-> 
$-> 
$-> __________________________________
$-> Do you Yahoo!?
$-> New and Improved Yahoo! Mail - 100MB free storage!
$-> http://promotions.yahoo.com/new_mail
$-> _______________________________________________
$-> C++-sig mailing list
$-> C++-sig at python.org
$-> http://mail.python.org/mailman/listinfo/c++-sig



From rwgk at yahoo.com  Wed Jul 21 20:32:02 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 21 Jul 2004 11:32:02 -0700 (PDT)
Subject: [C++-sig] Re: will custom lvalue converters be supported?
In-Reply-To: <BF0BED91AA17F448A3A927857E11FC64CAE24E@thor.pcigeomatics.com>
Message-ID: <20040721183202.19605.qmail@web20226.mail.yahoo.com>

--- Igor Lapshin <igor at pcigeomatics.com> wrote:
> That's exactly the case:  there are already hundreds of functions
> written with that "write-back" requirement long before we decided to use
> Python and it seems to me that writing thin wrappers for all of them is
> quite problematic. Moreover, the new functions are still being
> written...

In that case I'd wrap your list-like classes like this:

http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/stl/vector_wrapper.h?view=markup

This makes your std::vector derived classes look and work almost exactly like a
native Python list. You can even write foo([1,2,3]) directly to call
foo(std::vector<int> const&). Only if you want the write-back you have to be a
bit more conscious:

    array = stl.vector.int([1,2,3])
    foo(array)
    print list(array)

This works because

    - std::vector<int> is wrapped with boost::python::class_<>
    - there is a custom rvalue converter from any Python sequence
      (list, tuple, any iterable) to std::vector<int>
    - the copy constructor for std::vector<int> is wrapped explicitly

About my implementation:

    - I am trying to keep it simple to keep compile times down.
    - All required header files are open source and quite small.
      The most important header file is container_conversions.h
      which has no other dependencies. You can easily copy and
      paste code from slice.h and utils.h.
    - You will not be interested in ref_from_array.h. Simply remove
      the include and the three corresponding lines near the bottom.
    - If you are not interested in pickling you can reduce compile
      times some more by removing .enable_pickling() and the getinitargs
      implementation.
    - For use examples, see:

http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/stl/vector_ext.cpp?view=markup

You may want to wrap the required std::vector instantiations in the way
outlined above, and your derived classes with class_<your_derived,
bases<std::vector<int> > >.

It may be better to use Jonathan's newer boost::python::slice instead of my
older code for handling slices. As a start you could simply remove the
functions involving my slice objects. Maybe Jonathan can suggest replacement
code?

Ralf



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 


From igor at pcigeomatics.com  Wed Jul 21 22:53:54 2004
From: igor at pcigeomatics.com (Igor Lapshin)
Date: Wed, 21 Jul 2004 16:53:54 -0400
Subject: [C++-sig] Re: will custom lvalue converters be supported?
Message-ID: <BF0BED91AA17F448A3A927857E11FC64CAE288@thor.pcigeomatics.com>

Thanks a lot, Ralf, 

I'll try to use the classes you suggested. I have already seen the
container_conversions.h and used that to write my own custom converters.
I was not able to fully understand how construct() works since it uses
several types for which I haven't found any description (e.g.
rvalue_from_python_stage1_data and rvalue_from_python_storage<>). Is
there documentation for them and for converter::registry and or I should
just follow the examples which do all that magic?

Igor



From rwgk at yahoo.com  Wed Jul 21 23:07:36 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 21 Jul 2004 14:07:36 -0700 (PDT)
Subject: [C++-sig] Re: will custom lvalue converters be supported?
In-Reply-To: <BF0BED91AA17F448A3A927857E11FC64CAE288@thor.pcigeomatics.com>
Message-ID: <20040721210736.50538.qmail@web20226.mail.yahoo.com>

--- Igor Lapshin <igor at pcigeomatics.com> wrote:
> I'll try to use the classes you suggested. I have already seen the
> container_conversions.h and used that to write my own custom converters.
> I was not able to fully understand how construct() works since it uses
> several types for which I haven't found any description (e.g.
> rvalue_from_python_stage1_data and rvalue_from_python_storage<>). Is
> there documentation for them and for converter::registry and or I should
> just follow the examples which do all that magic?

That's what I did. :-) I only have a very sketchy idea myself of how it works
under the hood.
Each time I write a new custom converter I immediately run valgrind/memcheck to
make sure I did everything right. More often than not I had to go back and fix
my initial implementation. Here is the link to the life saver:
http://valgrind.kde.org/
Ralf



	
		
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/


From jbrandmeyer at earthlink.net  Thu Jul 22 00:05:34 2004
From: jbrandmeyer at earthlink.net (Jonathan Brandmeyer)
Date: Wed, 21 Jul 2004 18:05:34 -0400
Subject: [C++-sig] Re: will custom lvalue converters be supported?
In-Reply-To: <BF0BED91AA17F448A3A927857E11FC64CAE24E@thor.pcigeomatics.com>
References: <BF0BED91AA17F448A3A927857E11FC64CAE24E@thor.pcigeomatics.com>
Message-ID: <1090447534.15801.263.camel@localhost>

On Wed, 2004-07-21 at 11:14, Igor Lapshin wrote:
> Hi Ralf and Dave, 
> 
> Thanks for the fast response.
> 
> That's exactly the case:  there are already hundreds of functions
> written with that "write-back" requirement long before we decided to use
> Python and it seems to me that writing thin wrappers for all of them is
> quite problematic. Moreover, the new functions are still being
> written...
> 
> The classes, which are used as parameters for those functions, derived
> from stl::vector, but have additional member-functions, which I cannot
> remove without affecting hundreds of already written functions. Those
> additional members are used only internally and not from Python, thus
> tuple or sequence functionality is sufficient. 

[snip]
> 
> Is there any way to write a generic thin wrapper supporting "write back"
> for various functions with different signatures but with very limited
> set of types (we have some 5 types)?

Sure.  Here is something.  Hopefully, it can be generalized/specialized
as needed for your requirements, and isn't too non-portable (er, it
works with gcc 3.3.4 and 3.4.1 ...).  It takes advantage of the idea
that the function pointers passed to class_<T>::def() can be free
functions that take a T pointer or reference as their first argument.

If you have no choice but to go the route of wrapping the type to be
list-like, I would recommend the vector_indexing_suite<>.  (as a side
note, it supports basic slicing, but not extended slicing of the wrapped
type).

-Jonathan

---------------- A somewhat generic thin wrapper ---------------------
#include <vector>
#include <boost/python.hpp>

using namespace boost::python;

template <typename T, void (T:: *T_fn)(std::vector<double>&)>
void
call_from_python_with_list( T* This, boost::python::list py_arg1)
{
  int arg1_size = extract<int>(py_arg1.attr("__len__")());
  std::vector<double> cpp_arg1(arg1_size);

  // Initialize cpp_arg1 from py_arg1
  for (int i = 0; i < arg1_size; ++i)
    cpp_arg1[i] = extract<double>(py_arg1[i]);
	
  // Call the C++ mem fun that takes an lvalue.
  (This->*T_fn)( cpp_arg1);

  // overwrite py_arg1 with data from cpp_arg1
  py_arg1.attr("__delslice__")(0, arg1_size);
  for (std::vector<double>::iterator i = cpp_arg1.begin(); 
      i < cpp_arg1.end(); ++i)
    py_arg1.append( object(*i));

  return;
}

struct call_me
{
  void f( std::vector<double>& arg)
  {
    // do something to modify the vector.
    arg.push_back(2);
  }
};

BOOST_PYTHON_MODULE(call_from_python_with_list)
{
  class_<call_me>("call_me")
    .def( "f", &call_from_python_with_list< call_me, &call_me::f>)
    ;
}




From dawson at physics.uq.edu.au  Thu Jul 22 06:42:20 2004
From: dawson at physics.uq.edu.au (Christopher Dawson)
Date: Thu, 22 Jul 2004 14:42:20 +1000
Subject: [C++-sig] Exposing copy constructors with Boost::Python
Message-ID: <20040722144220.B6098@lamb.physics.uq.edu.au>

Apologies if this is a common problem with a common solution, but I haven't been able to find it anywhere.

I have a simple class which stupidly has a c-style array as a member:

class Test {
public:
	int *a;

	Test(int N) {
		a = new int[N];
	}

	Test(const Test& T) {
		a = new int[T.N];
	}

	Test& operator=(const Test& T) {
		if (N != T.N) {
			delete[] a;
			a = new int[N];
			for (int i=0;i<N;i++)
				a[i] = T.a[i];
		}
	}
	~Test() {
		if (a) 
			delete[] a;
	}
};

I have wrapped this with Boost::Python (1_31_0), and understood that the copy and assignment constructors would be wrapped automatically.A

However copying the object from Python just copies the pointer, not the array. I can explicitly expose the copy constructor with

	.def(init<const Test&>())

so  it's possible to do 
	
	a = Test(4)
	b = Test(a),

but I'd like to be able to to

	b = a

Have I missed something about exposing copy constructors?

Ta,

Chris 


	









From claireguilbaud at yahoo.fr  Thu Jul 22 13:16:24 2004
From: claireguilbaud at yahoo.fr (=?iso-8859-1?q?Claire=20Guilbaud?=)
Date: Thu, 22 Jul 2004 13:16:24 +0200 (CEST)
Subject: [C++-sig] SWIG comments
Message-ID: <20040722111624.72866.qmail@web52802.mail.yahoo.com>

Hi, I use SWIG to create a module from several C++ classes. In my C++ classes, I have a lot of comments to generate doxygen documentation.
I would like to have the same comments for the module (with help(mymodule)) but in doc strings for pydoc. I don't want to have doc strings for pydoc in my C++ part.
 
Does anybody know a solution ?
 
Thanks very much
 
Margebulle


		
---------------------------------
Cr?ez gratuitement votre Yahoo! Mail avec 100 Mo de stockage !
Cr?ez votre Yahoo! Mail

Yahoo! Messenger : dialoguez instantan?ment avec vos amis - c'est  gratuit !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20040722/d58aee27/attachment.htm>

From dave at boost-consulting.com  Thu Jul 22 14:48:11 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 22 Jul 2004 08:48:11 -0400
Subject: [C++-sig] Re: Exposing copy constructors with Boost::Python
References: <20040722144220.B6098@lamb.physics.uq.edu.au>
Message-ID: <un01s8ayc.fsf@boost-consulting.com>

Christopher Dawson <dawson at physics.uq.edu.au> writes:

> Apologies if this is a common problem with a common solution, but I
> haven't been able to find it anywhere.
>
> I have a simple class which stupidly has a c-style array as a member:

Your class has a pointer as a member, not an array.

> class Test {
> public:
> 	int *a;
>
> 	Test(int N) {
> 		a = new int[N];
> 	}
>
> 	Test(const Test& T) {
> 		a = new int[T.N];
                     ^^
?? There is no N member of Test??

Your copy ctor doesn't copy the contents of the array.  Intentional?

> 	}
>
> 	Test& operator=(const Test& T) {
> 		if (N != T.N) {
> 			delete[] a;
> 			a = new int[N];
> 			for (int i=0;i<N;i++)
> 				a[i] = T.a[i];
> 		}
> 	}
> 	~Test() {
> 		if (a) 
> 			delete[] a;
> 	}
> };
>
> I have wrapped this with Boost::Python (1_31_0), and understood that
> the copy and assignment constructors would be wrapped automatically.A
>
> However copying the object from Python

What do you mean by "copying the object from Python"?

> just copies the pointer, not
> the array. I can explicitly expose the copy constructor with
>
> 	.def(init<const Test&>())
>
> so  it's possible to do 
> 	
> 	a = Test(4)
> 	b = Test(a),
>
> but I'd like to be able to to
>
> 	b = a

When you do that in Python, it *always* just rebinds the reference
that B was referring to so b and a are "pointing at" the same object.
Nothing ever gets copied.  There's no way to change that; it's just
the way Python works.

> Have I missed something about exposing copy constructors?

Forget about Python for a moment; it looks to me like you've missed
something about writing copy ctors in C++.

Don't you want this C++ to work

      Test x[2];
      x.a[0] = 1;
      x.a[1] = 2;
      Test y = x;
      assert(y.a[0] == x.a[0]);
      assert(y.a[1] == x.a[1]);

??
-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From mario-p at iname.com  Thu Jul 22 20:27:55 2004
From: mario-p at iname.com (Mario Palomo)
Date: Thu, 22 Jul 2004 20:27:55 +0200
Subject: [C++-sig] Boost::Python for C code -> Segmentation fault
Message-ID: <cdp0vd$g2v$1@sea.gmane.org>

I'd like to use Boost::Python to wrap C code in python, but my first test 
doesn't work:


FILE: hello.cpp
=================== BEGIN =======================
/*---------------- C code -------------------- */
#ifdef __cplusplus
extern "C" {
#endif

#include <stdio.h>

typedef struct user {
   char *name;
   int number;
}user;

void greet(user *u)
{
    printf("Hello %s, your number is %d.\n"
           , u->name, u->number);
}

#ifdef __cplusplus
}
#endif
/*-------------------------------------------- */

#include <boost/python/module.hpp>
#include <boost/python/def.hpp>
#include <boost/python/class.hpp>
using namespace boost::python;

BOOST_PYTHON_MODULE(hello)
{
   class_<user>("user")
     .def_readwrite("name",   &user::name)
     .def_readwrite("number", &user::number)
   ;

   def("greet", greet);
}
==================== END ========================


I'm using Linux (Debian Sid) Boost::Python packages.
When I compile, I get:

$ g++ -c hello.cpp -Wall -I/usr/include/python2.3
$ ld -shared -o hello.so hello.o -lboost_python

All right, now I have 'hello.so', but when I try to use
the new module, I get a "Segmentation fault":

$ python
Python 2.3.4 (#2, Jul  5 2004, 09:15:05)
[GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> import hello
 >>> u = hello.user()
 >>> u.number=10
Segmentation fault
$

What's wrong?

Thanks in advance




From flatfeetpete at gmail.com  Thu Jul 22 20:37:40 2004
From: flatfeetpete at gmail.com (Peter Bradshaw)
Date: Thu, 22 Jul 2004 11:37:40 -0700
Subject: [C++-sig] Threads and boost wrapped classes.
Message-ID: <991db9fe040722113739de7f16@mail.gmail.com>

Hello all.

My Aim:
An app where embedded python scripts control a number of C++ analysis
functions that are run over a bunch of mp3's. The idea is that each
thread would do a PyRunSimpleString or similar to run a python
function that controls and organises the analysis of an mp3. The
dispatch/organisation of mp3 selection could be handled in a thread
safe manner in C++.

Q:
I'm aware that there's probably some Python/C API stuff I have to
learn/implement, but I'm curious if boost::python will play nicely in
this situation. That is, if different objects of the same wrapped
class being accessed from diffferent threads will I have issues?

Thanks for your time.

Pete.


From thor.arne.johansen at ibas.no  Thu Jul 22 20:56:03 2004
From: thor.arne.johansen at ibas.no (thor.arne.johansen at ibas.no)
Date: Thu, 22 Jul 2004 20:56:03 +0200
Subject: [C++-sig] Boost::Python for C code -> Segmentation fault
Message-ID: <OFCF9414FF.4F9D433C-ONC1256ED9.0067D366@no>



>typedef struct user {
>   char *name;
>   int number;
>}user;
>
>void greet(user *u)
>{
>    printf("Hello %s, your number is %d.\n"
>           , u->name, u->number);
>}


You never allocate (or initilialize) the memory for user, so your printf
runs wild in memory.

--
Thor Arne Johansen
Dept. Manager R&D
Ibas AS



From mario-p at iname.com  Thu Jul 22 22:16:56 2004
From: mario-p at iname.com (Mario Palomo)
Date: Thu, 22 Jul 2004 22:16:56 +0200
Subject: [C++-sig] Re: Boost::Python for C code -> Segmentation fault
In-Reply-To: <OFCF9414FF.4F9D433C-ONC1256ED9.0067D366@no>
References: <OFCF9414FF.4F9D433C-ONC1256ED9.0067D366@no>
Message-ID: <cdp7bp$3pu$1@sea.gmane.org>

thor.arne.johansen at ibas.no wrote:
> 
>>typedef struct user {
>>  char *name;
>>  int number;
>>}user;
>>
>>void greet(user *u)
>>{
>>   printf("Hello %s, your number is %d.\n"
>>          , u->name, u->number);
>>}
> 
> 
> 
> You never allocate (or initilialize) the memory for user, so your printf
> runs wild in memory.
> 
> --
> Thor Arne Johansen
> Dept. Manager R&D
> Ibas AS

But I get the "Segmentation fault" and I don't use the 'greet' function (the 
printf never get executed):

$ python
Python 2.3.4 (#2, Jul  5 2004, 09:15:05)
[GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> import hello
 >>> u = hello.user()
 >>> u.number=10
Segmentation fault
$

I think Python allocate the memory for user, in the 'u' variable.


As a note, this same example works under SWIG, when I use this files:
==================> FILE: hello.c <==============
/*---------------- C code -------------------- */
#ifdef __cplusplus
extern "C" {
#endif

#include <stdio.h>

   typedef struct user {
       char *name;
         int number;
   }user;

   void greet(user *u)
   {
        printf("Hello %s, your number is %d.\n"
                      , u->name, u->number);
   }

#ifdef __cplusplus
}
#endif
/*-------------------------------------------- */


==================> FILE: hello.i <==============
%module hello
%{

typedef struct user {
   char *name;
   int number;
}user;

%}

typedef struct user {
   char *name;
   int number;
}user;

void greet(user *u);
=================================================

Using Linux (Debian Sid) 'swig' packages, when I compile, I get:
$ swig -python hello.i
$ gcc -c hello.c -Wall
$ gcc -c hello_wrap.c -Wall -I/usr/include/python2.3
$ ld -shared -o _hello.so hello.o hello_wrap.o

I get '_hello.so' and 'hello.py', that work fine:

Python 2.3.4 (#2, Jul  5 2004, 09:15:05)
[GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> import hello
 >>> u = hello.user()
 >>> u.number=10
 >>> u.name="Mario"
 >>> hello.greet(u)
Hello Mario, your number is 10.
 >>>


Why this doesn't work on Boost::Python?

Thanks for your response.

Mario



From igor at pcigeomatics.com  Thu Jul 22 23:10:03 2004
From: igor at pcigeomatics.com (Igor Lapshin)
Date: Thu, 22 Jul 2004 17:10:03 -0400
Subject: [C++-sig] Re: will custom lvalue converters be supported?
Message-ID: <BF0BED91AA17F448A3A927857E11FC64CAE2F2@thor.pcigeomatics.com>


Hi Jonathan, 

It's an interesting idea to wrap the function into such template. I need
to think how I can overcome the problem that the types of the function
parameters of my functions may be in different sequences and thus I may
need too many templates. Meanwhile I'll probably use
vector_indexing_suite<> or scitbx/stl/vector_wrapper.h. 

Thanks,
Igor

$-> 
$-> template <typename T, void (T:: *T_fn)(std::vector<double>&)>
$-> void
$-> call_from_python_with_list( T* This, boost::python::list py_arg1)
$-> {
$->   int arg1_size = extract<int>(py_arg1.attr("__len__")());
$->   std::vector<double> cpp_arg1(arg1_size);
$-> 
$->   // Initialize cpp_arg1 from py_arg1
$->   for (int i = 0; i < arg1_size; ++i)
$->     cpp_arg1[i] = extract<double>(py_arg1[i]);
$-> 
$->   // Call the C++ mem fun that takes an lvalue.
$->   (This->*T_fn)( cpp_arg1);
$-> 
$->   // overwrite py_arg1 with data from cpp_arg1
$->   py_arg1.attr("__delslice__")(0, arg1_size);
$->   for (std::vector<double>::iterator i = cpp_arg1.begin();
$->       i < cpp_arg1.end(); ++i)
$->     py_arg1.append( object(*i));
$-> 
$->   return;
$-> }
$-> 
$-> struct call_me
$-> {
$->   void f( std::vector<double>& arg)
$->   {
$->     // do something to modify the vector.
$->     arg.push_back(2);
$->   }
$-> };
$-> 
$-> BOOST_PYTHON_MODULE(call_from_python_with_list)
$-> {
$->   class_<call_me>("call_me")
$->     .def( "f", &call_from_python_with_list< call_me, &call_me::f>)
$->     ;
$-> }
$-> 
$-> 
$-> _______________________________________________
$-> C++-sig mailing list
$-> C++-sig at python.org
$-> http://mail.python.org/mailman/listinfo/c++-sig



From rwgk at yahoo.com  Thu Jul 22 23:13:40 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 22 Jul 2004 14:13:40 -0700 (PDT)
Subject: [C++-sig] Re: Boost::Python for C code -> Segmentation fault
In-Reply-To: <cdp7bp$3pu$1@sea.gmane.org>
Message-ID: <20040722211340.55661.qmail@web20223.mail.yahoo.com>

I am somewhat surprised that your code compiles. While you are right that
Boost.Python manages the memory for the user instance, it certainly doesn't
manage your char* name. I cannot explain how exactly the segmentation fault
comes about, but you certainly have to do something about the raw char*. As a
start I'd remove the extern "C" declaration and replace char* name by
std::string name. Does that make it work as expected?
Ralf

--- Mario Palomo <mario-p at iname.com> wrote:
> thor.arne.johansen at ibas.no wrote:
> > 
> >>typedef struct user {
> >>  char *name;
> >>  int number;
> >>}user;
> >>
> >>void greet(user *u)
> >>{
> >>   printf("Hello %s, your number is %d.\n"
> >>          , u->name, u->number);
> >>}
> > 
> > 
> > 
> > You never allocate (or initilialize) the memory for user, so your printf
> > runs wild in memory.
> > 
> > --
> > Thor Arne Johansen
> > Dept. Manager R&D
> > Ibas AS
> 
> But I get the "Segmentation fault" and I don't use the 'greet' function (the 
> printf never get executed):
> 
> $ python
> Python 2.3.4 (#2, Jul  5 2004, 09:15:05)
> [GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> import hello
>  >>> u = hello.user()
>  >>> u.number=10
> Segmentation fault
> $
> 
> I think Python allocate the memory for user, in the 'u' variable.
> 
> 
> As a note, this same example works under SWIG, when I use this files:
> ==================> FILE: hello.c <==============
> /*---------------- C code -------------------- */
> #ifdef __cplusplus
> extern "C" {
> #endif
> 
> #include <stdio.h>
> 
>    typedef struct user {
>        char *name;
>          int number;
>    }user;
> 
>    void greet(user *u)
>    {
>         printf("Hello %s, your number is %d.\n"
>                       , u->name, u->number);
>    }
> 
> #ifdef __cplusplus
> }
> #endif
> /*-------------------------------------------- */
> 
> 
> ==================> FILE: hello.i <==============
> %module hello
> %{
> 
> typedef struct user {
>    char *name;
>    int number;
> }user;
> 
> %}
> 
> typedef struct user {
>    char *name;
>    int number;
> }user;
> 
> void greet(user *u);
> =================================================
> 
> Using Linux (Debian Sid) 'swig' packages, when I compile, I get:
> $ swig -python hello.i
> $ gcc -c hello.c -Wall
> $ gcc -c hello_wrap.c -Wall -I/usr/include/python2.3
> $ ld -shared -o _hello.so hello.o hello_wrap.o
> 
> I get '_hello.so' and 'hello.py', that work fine:
> 
> Python 2.3.4 (#2, Jul  5 2004, 09:15:05)
> [GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> import hello
>  >>> u = hello.user()
>  >>> u.number=10
>  >>> u.name="Mario"
>  >>> hello.greet(u)
> Hello Mario, your number is 10.
>  >>>
> 
> 
> Why this doesn't work on Boost::Python?
> 
> Thanks for your response.
> 
> Mario
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 



		
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail 


From s_sourceforge at nedprod.com  Thu Jul 22 23:11:45 2004
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Thu, 22 Jul 2004 22:11:45 +0100
Subject: [C++-sig] Re: Boost::Python for C code -> Segmentation fault
In-Reply-To: <cdp7bp$3pu$1@sea.gmane.org>
References: <OFCF9414FF.4F9D433C-ONC1256ED9.0067D366@no>
Message-ID: <41003BA1.15661.983170E@localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 22 Jul 2004 at 22:16, Mario Palomo wrote:

> Why this doesn't work on Boost::Python?

Does it work without the extern "C"?

Also, you want direct member variable access to use make_setter and 
make_getter rather than def_readwrite(). Search the list archive for 
more.

Also, it would be far more useful to us if you ran python inside gdb 
and gave a backtrace (bt) of where the segfault is happening.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBQQAtkcEcvDLFGKbPEQKZfwCggSM4SH08NuQkD0i/an2Ko3jwpkwAoNA5
DhdULXQVOLkEpVYhpt/z8/vd
=/HKi
-----END PGP SIGNATURE-----


From dave at boost-consulting.com  Fri Jul 23 00:01:51 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Thu, 22 Jul 2004 18:01:51 -0400
Subject: [C++-sig] Re: Boost::Python for C code -> Segmentation fault
References: <OFCF9414FF.4F9D433C-ONC1256ED9.0067D366@no>
	<41003BA1.15661.983170E@localhost>
Message-ID: <uu0vz3dm8.fsf@boost-consulting.com>

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

> On 22 Jul 2004 at 22:16, Mario Palomo wrote:
>
>> Why this doesn't work on Boost::Python?
>
> Does it work without the extern "C"?

Extern "C" function pointers and C++ function pointers are different
types, and BPL isn't set up to handle extern "C" at all.  On a
conforming implementation, any attempt to wrap extern "C" functions
without first building C++ thin wrappers will fail.  That said, if
things are compiling your compiler probably ignores that part of the
type and there's some other problem.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dawson at physics.uq.edu.au  Fri Jul 23 05:05:46 2004
From: dawson at physics.uq.edu.au (Christopher Dawson)
Date: Fri, 23 Jul 2004 13:05:46 +1000
Subject: [C++-sig] Re: Exposing copy constructors with Boost::Python
In-Reply-To: <un01s8ayc.fsf@boost-consulting.com>
References: <20040722144220.B6098@lamb.physics.uq.edu.au>
	<un01s8ayc.fsf@boost-consulting.com>
Message-ID: <4100808A.9090904@physics.uq.edu.au>

David Abrahams wrote:

>Your copy ctor doesn't copy the contents of the array.  Intentional?
>
>  
>
Bah. I should have just pasted the code. The copy ctor does copy the 
contents of the array.

>What do you mean by "copying the object from Python"?
>
>  
>
I thought I meant b = a, and even though I was aware this just makes b a 
reference to a, didn't appreciate it.

I now mean a deep copy  b = copy.deepcopy(a). So this means either 
providing some method by which the object can be pickled, or exposing a  
__deepcopy__ function. Or something.

Thanks, that helped a lot.

Chris


From mario-p at iname.com  Fri Jul 23 11:25:33 2004
From: mario-p at iname.com (Mario Palomo)
Date: Fri, 23 Jul 2004 11:25:33 +0200
Subject: [C++-sig] Re: Boost::Python for C code -> Segmentation fault
In-Reply-To: <uu0vz3dm8.fsf@boost-consulting.com>
References: <OFCF9414FF.4F9D433C-ONC1256ED9.0067D366@no>	<41003BA1.15661.983170E@localhost>
	<uu0vz3dm8.fsf@boost-consulting.com>
Message-ID: <cdqlid$asb$1@sea.gmane.org>

It doesn't work. I get the same segfault with the extern "C" and without the 
extern "C".

I'll try make_setter and make_getter rather than def_readwrite(). Then I'll try 
to run python inside gdb and get a backtrace (bt) of where the segfault is 
happening... Can someone reproduce my segfault?


David Abrahams escribi?:
> "Niall Douglas" <s_sourceforge at nedprod.com> writes:
> 
> 
>>On 22 Jul 2004 at 22:16, Mario Palomo wrote:
>>
>>
>>>Why this doesn't work on Boost::Python?
>>
>>Does it work without the extern "C"?
> 
> 
> Extern "C" function pointers and C++ function pointers are different
> types, and BPL isn't set up to handle extern "C" at all.  On a
> conforming implementation, any attempt to wrap extern "C" functions
> without first building C++ thin wrappers will fail.  That said, if
> things are compiling your compiler probably ignores that part of the
> type and there's some other problem.
> 



From sseefeld at art.ca  Fri Jul 23 19:04:02 2004
From: sseefeld at art.ca (Stefan Seefeld)
Date: Fri, 23 Jul 2004 13:04:02 -0400
Subject: [C++-sig] make_constructor issues
Message-ID: <20DCDD8F0FCED411AC4D001083CF504501AA96E6@MTL-EXCHANGE>

hi there,

the wrapper 'python.hpp' header doesn't include
the 'make_constructor.hpp' file. Shouldn't it ?

Then I try to make

Foo make_foo()
{
  Foo foo;
  foo.init();
  return foo;
}

a constructor (i.e. binding it to '__init__' via
'make_constructor'), but I get an error message about
'element_type' not being a member of Foo. The
examples I'v found all use pointes, so I changed
the 'make_foo' function to return a pointer.
That works, but is not what I want to do.
What's the problem ?

Thanks,
		Stefan


From bhall at gamers-fix.com  Fri Jul 23 20:50:47 2004
From: bhall at gamers-fix.com (Brian Hall)
Date: Fri, 23 Jul 2004 13:50:47 -0500
Subject: [C++-sig] Shared Pointers and Boost.Python
Message-ID: <20040723185047.455801E4002@bag.python.org>

What is the proper way to pass shared pointers to constructors of exposed
objects?
What about returning them?

For instance, lets say I have the following classes:

Class A:
{
// some stuff
};

Class B:
{
	B(shared_ptr<A> a) : myA(a) {}
	shared_ptr<A> getA() { return myA; }

	shared_ptr<A> myA;
}

And exposed as so:

BOOST_PYTHON_MODULE(GI_AISDK)
{
	// Expose the State class to Python
	class_<A>("A");
	class_<B>("B", init<shared_ptr<A> >())
		.def("getA", &B::getA);
}

With some python script like so:

class C(B):
	def do_some_stuff(self):
		pass

Now say I want to create an instance of class C from within C++:

shared_ptr<A> a(new A);

object myClassCType(maindictionary["C"]);

object newClassCObject = myClassCType(a);

shared_ptr<A> theA = extract<shared_ptr<A>
>(newClassCObject.attr("getA")());

Is this right?

Thanks!  

Brian Hall





From rwgk at yahoo.com  Fri Jul 23 21:04:26 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 23 Jul 2004 12:04:26 -0700 (PDT)
Subject: [C++-sig] Shared Pointers and Boost.Python
In-Reply-To: <20040723185047.455801E4002@bag.python.org>
Message-ID: <20040723190426.97434.qmail@web20225.mail.yahoo.com>

--- Brian Hall <bhall at gamers-fix.com> wrote:
> BOOST_PYTHON_MODULE(GI_AISDK)
> {
> 	// Expose the State class to Python
> 	class_<A>("A");
> 	class_<B>("B", init<shared_ptr<A> >())
> 		.def("getA", &B::getA);
> }

Try:
        class_<A, shared_ptr<A> >("A");
        class_<B, shared_ptr<B> >("B", init<shared_ptr<A> >())

This should answer the first part of your question. I am not sure about the
second part.
Ralf



	
		
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/


From rwgk at yahoo.com  Fri Jul 23 21:38:26 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 23 Jul 2004 12:38:26 -0700 (PDT)
Subject: [C++-sig] make_constructor issues
In-Reply-To: <20DCDD8F0FCED411AC4D001083CF504501AA96E6@MTL-EXCHANGE>
Message-ID: <20040723193826.6985.qmail@web20221.mail.yahoo.com>

--- Stefan Seefeld <sseefeld at art.ca> wrote:
> hi there,
> 
> the wrapper 'python.hpp' header doesn't include
> the 'make_constructor.hpp' file. Shouldn't it ?
> 
> Then I try to make
> 
> Foo make_foo()
> {
>   Foo foo;
>   foo.init();
>   return foo;
> }
> 
> a constructor (i.e. binding it to '__init__' via
> 'make_constructor'), but I get an error message about
> 'element_type' not being a member of Foo. The
> examples I'v found all use pointes, so I changed
> the 'make_foo' function to return a pointer.
> That works, but is not what I want to do.

Why not? It is just a technical detail that you have to adjust to. I.e. you
could to this (untested):

 shared_ptr<Foo> make_foo()
 {
   Foo foo;
   foo.init();
   return shared_ptr<Foo>(new Foo(foo));
 }

But this requires that Foo is copy-constructable and you incur a
runtime-penalty for executing the copy constructor. I'd generally prefer this:

 shared_ptr<Foo> make_foo()
 {
   shared_ptr<Foo> foo_ptr(new Foo);
   Foo& foo = *foo_ptr;
   foo.init();
   return foo_ptr;
 }

Is this approach impractical in your environment? If so, what are the reasons?

Ralf



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 


From sseefeld at art.ca  Fri Jul 23 22:05:14 2004
From: sseefeld at art.ca (Stefan Seefeld)
Date: Fri, 23 Jul 2004 16:05:14 -0400
Subject: [C++-sig] make_constructor issues
Message-ID: <20DCDD8F0FCED411AC4D001083CF504501AA96E7@MTL-EXCHANGE>

well, the reason I'm asking because I found it counter-intuitive.
Having defined a wrapper via

class_<Foo> foo("Foo");

I'd expect to pass values around, not Foo pointers. If it is
a limitation of make_constructor, it should be documented.

It's not an issue, though, in this particular case. I'm
wrapping legacy code, and the Foo in question is a small
structure, which however, isn't properly initialized in its
default constructor, so instead of using that I'd like to
make a factory that does the initialization...

Thanks,
		Stefan


From flatfeetpete at gmail.com  Fri Jul 23 22:11:21 2004
From: flatfeetpete at gmail.com (Peter Bradshaw)
Date: Fri, 23 Jul 2004 13:11:21 -0700
Subject: [C++-sig] boost and threads
Message-ID: <991db9fe04072313113c3c15aa@mail.gmail.com>

Hello all. Apologies if this is a dupe. It's the second time I've sent
it, but it didn't seem to get thru first time.

My Aim:
An app where embedded python scripts control a number of C++ analysis
functions that are run over a bunch of mp3's. The idea is that each
thread would do a PyRunSimpleString or similar to run a python
function that controls and organises the analysis of an mp3. The
dispatch/organisation of mp3 selection could be handled in a thread
safe manner in C++.

Q:
I'm aware that there's probably some Python/C API stuff I have to
learn/implement, but I'm curious if boost::python will play nicely in
this situation. That is, if different objects of the same wrapped
class being accessed from diffferent threads will I have issues?

Thanks for your time.

Pete.


From rwgk at yahoo.com  Fri Jul 23 22:46:20 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 23 Jul 2004 13:46:20 -0700 (PDT)
Subject: [C++-sig] make_constructor issues
In-Reply-To: <20DCDD8F0FCED411AC4D001083CF504501AA96E7@MTL-EXCHANGE>
Message-ID: <20040723204620.30584.qmail@web20223.mail.yahoo.com>

--- Stefan Seefeld <sseefeld at art.ca> wrote:
> well, the reason I'm asking because I found it counter-intuitive.
> Having defined a wrapper via
> 
> class_<Foo> foo("Foo");
>
> I'd expect to pass values around, not Foo pointers. If it is
> a limitation of make_constructor, it should be documented.

AFAICT the behavior of class_<Foo> foo("Foo") isn't affected in any way by the
use of make_constructor. David, is this correct?

Speculating: David chose to implement make_constructor the way you see it to
avoid the requirement that the wrapped type must be copy-constructable. I guess
he could have provided another make_constructor overload that copies the new
instance but for some reason that wasn't considered worthwhile or even counter
productive. With the implementation as is people are forced to think about the
extra copy, and more likely than not are lead to write code which avoids it.

> It's not an issue, though, in this particular case.

Glad this is the case.

> I'm
> wrapping legacy code, and the Foo in question is a small
> structure, which however, isn't properly initialized in its
> default constructor, so instead of using that I'd like to
> make a factory that does the initialization...

To me it seems the best implementation of the factory should return
auto_ptr<Foo> or shared_ptr<Foo> in order to avoid a copy.

Ralf



		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail


From sseefeld at art.ca  Fri Jul 23 22:50:25 2004
From: sseefeld at art.ca (Stefan Seefeld)
Date: Fri, 23 Jul 2004 16:50:25 -0400
Subject: [C++-sig] make_constructor issues
Message-ID: <20DCDD8F0FCED411AC4D001083CF504501AA96E8@MTL-EXCHANGE>



> To me it seems the best implementation of the factory should return
> auto_ptr<Foo> or shared_ptr<Foo> in order to avoid a copy.

But copy-construct it must anyways, simply because I chose to export
the type as class_<Foo>, not class_<Foo, shared_ptr<Foo> > !?!

Stefan
 


From rwgk at yahoo.com  Sat Jul 24 01:20:13 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 23 Jul 2004 16:20:13 -0700 (PDT)
Subject: [C++-sig] make_constructor issues
In-Reply-To: <20DCDD8F0FCED411AC4D001083CF504501AA96E8@MTL-EXCHANGE>
Message-ID: <20040723232013.39050.qmail@web20225.mail.yahoo.com>

--- Stefan Seefeld <sseefeld at art.ca> wrote:
> > To me it seems the best implementation of the factory should return
> > auto_ptr<Foo> or shared_ptr<Foo> in order to avoid a copy.
> 
> But copy-construct it must anyways, simply because I chose to export
> the type as class_<Foo>, not class_<Foo, shared_ptr<Foo> > !?!

Probably, but the point is that the current make_constructor implementation
covers the general case. Is it really worth the complication of implementing
another make_constructor overload? As shown in one of my previous messages you
can very easily modify your original factory function to fit into the current
system.
Ralf



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 


From seefeld at sympatico.ca  Sat Jul 24 01:23:19 2004
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Fri, 23 Jul 2004 19:23:19 -0400
Subject: [C++-sig] make_constructor issues
In-Reply-To: <20040723232013.39050.qmail@web20225.mail.yahoo.com>
References: <20040723232013.39050.qmail@web20225.mail.yahoo.com>
Message-ID: <41019DE7.1000308@sympatico.ca>

Ralf W. Grosse-Kunstleve wrote:
> --- Stefan Seefeld <sseefeld at art.ca> wrote:
> 
>>>To me it seems the best implementation of the factory should return
>>>auto_ptr<Foo> or shared_ptr<Foo> in order to avoid a copy.
>>
>>But copy-construct it must anyways, simply because I chose to export
>>the type as class_<Foo>, not class_<Foo, shared_ptr<Foo> > !?!
> 
> 
> Probably, but the point is that the current make_constructor implementation
> covers the general case. Is it really worth the complication of implementing
> another make_constructor overload? As shown in one of my previous messages you
> can very easily modify your original factory function to fit into the current
> system.

yes, it's not a problem. As I said, I was just surprised to see it not working,
since most (all ?) other functions easily deal with derived types. I have no
idea how much complication a generalization involves. I can certainly live with
the status quo (but I'd suggest documenting the constraint somewhere).

Regards,
		Stefan



From s_sourceforge at nedprod.com  Sat Jul 24 02:43:58 2004
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 24 Jul 2004 01:43:58 +0100
Subject: [C++-sig] boost and threads
In-Reply-To: <991db9fe04072313113c3c15aa@mail.gmail.com>
Message-ID: <4101BEDE.30703.F6BBCE9@localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23 Jul 2004 at 13:11, Peter Bradshaw wrote:

> An app where embedded python scripts control a number of C++ analysis
> functions that are run over a bunch of mp3's. The idea is that each
> thread would do a PyRunSimpleString or similar to run a python
> function that controls and organises the analysis of an mp3. The
> dispatch/organisation of mp3 selection could be handled in a thread
> safe manner in C++.
> 
> Q:
> I'm aware that there's probably some Python/C API stuff I have to
> learn/implement, but I'm curious if boost::python will play nicely in
> this situation. That is, if different objects of the same wrapped
> class being accessed from diffferent threads will I have issues?

So long as you are holding the python GIL when you call boost.python, 
everything should be fine. Of course, all time spent inside python 
and any code of yours python calls will be single threaded due to the 
mutex.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBQQGwzsEcvDLFGKbPEQJLGQCg5BfuPPyNTUh8wyN+Fh/NNFk7+3IAoPNC
GxL4p3GtE+JPsTHFeLymsvnX
=ns8g
-----END PGP SIGNATURE-----


From dave at boost-consulting.com  Sat Jul 24 16:30:54 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 24 Jul 2004 10:30:54 -0400
Subject: [C++-sig] Re: make_constructor issues
References: <20DCDD8F0FCED411AC4D001083CF504501AA96E7@MTL-EXCHANGE>
Message-ID: <un01pxysh.fsf@boost-consulting.com>

Stefan Seefeld <sseefeld at art.ca> writes:

> well, the reason I'm asking because I found it counter-intuitive.
> Having defined a wrapper via
>
> class_<Foo> foo("Foo");
>
> I'd expect to pass values around, not Foo pointers. If it is
> a limitation of make_constructor, it should be documented.

Yes, apparently make_constructor isn't documented at all :(
There's documentation for something else called make_constructor that
doesn't even exist :(.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Sat Jul 24 16:39:50 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 24 Jul 2004 10:39:50 -0400
Subject: [C++-sig] Re: Shared Pointers and Boost.Python
References: <20040723185047.455801E4002@bag.python.org>
	<20040723190426.97434.qmail@web20225.mail.yahoo.com>
Message-ID: <uzn5pwjt5.fsf@boost-consulting.com>

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

> --- Brian Hall <bhall at gamers-fix.com> wrote:
>> BOOST_PYTHON_MODULE(GI_AISDK)
>> {
>> 	// Expose the State class to Python
>> 	class_<A>("A");
>> 	class_<B>("B", init<shared_ptr<A> >())
>> 		.def("getA", &B::getA);
>> }
>
> Try:
>         class_<A, shared_ptr<A> >("A");
>         class_<B, shared_ptr<B> >("B", init<shared_ptr<A> >())
>
> This should answer the first part of your question. I am not sure about the
> second part.

Actually, everything he did was fine.  Wrapping classes with
shared_ptr is almost completely pointless now, since any Python object
holding an X object can be converted to a shared_ptr<X>.  The
shared_ptr has a custom deleter that manages the owning Python object's
lifetime.

You might want to use register_ptr_to_python<shared_ptr<X> >() for
some shared pointers if you ever create them from C++ code, but in
this case it never happens so they can all be automatically converted
back into Python objects by (we just extract the owning Python object
from the deleter).

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Sat Jul 24 16:34:29 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 24 Jul 2004 10:34:29 -0400
Subject: [C++-sig] Re: make_constructor issues
References: <20040723232013.39050.qmail@web20225.mail.yahoo.com>
	<41019DE7.1000308@sympatico.ca>
Message-ID: <u658dxymi.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> Ralf W. Grosse-Kunstleve wrote:
>> --- Stefan Seefeld <sseefeld at art.ca> wrote:
>> 
>>>>To me it seems the best implementation of the factory should return
>>>>auto_ptr<Foo> or shared_ptr<Foo> in order to avoid a copy.
>>>
>>>But copy-construct it must anyways, simply because I chose to export
>>>the type as class_<Foo>, not class_<Foo, shared_ptr<Foo> > !?!
>> Probably, but the point is that the current make_constructor
>> implementation
>> covers the general case. Is it really worth the complication of implementing
>> another make_constructor overload? As shown in one of my previous messages you
>> can very easily modify your original factory function to fit into the current
>> system.
>
> yes, it's not a problem. As I said, I was just surprised to see it not working,
> since most (all ?) other functions easily deal with derived types. I have no
> idea how much complication a generalization involves. 

What do derived types have to do with anything?

> I can certainly live with the status quo (but I'd suggest
> documenting the constraint somewhere).

If someone would like to write the doc file make_constructor.html and
remove the completely erroneous docs for make_constructor from
make_function.html, I'd be most grateful.  Otherwise, I'll try to get
to it, but I'm officially on vacation.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Sat Jul 24 16:32:28 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 24 Jul 2004 10:32:28 -0400
Subject: [C++-sig] Re: make_constructor issues
References: <20DCDD8F0FCED411AC4D001083CF504501AA96E8@MTL-EXCHANGE>
Message-ID: <ubri5xypv.fsf@boost-consulting.com>

Stefan Seefeld <sseefeld at art.ca> writes:

>> To me it seems the best implementation of the factory should return
>> auto_ptr<Foo> or shared_ptr<Foo> in order to avoid a copy.
>
> But copy-construct it must anyways, simply because I chose to export
> the type as class_<Foo>, not class_<Foo, shared_ptr<Foo> > !?!

No; there's no copy construction.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Sat Jul 24 16:32:02 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sat, 24 Jul 2004 10:32:02 -0400
Subject: [C++-sig] Re: make_constructor issues
References: <20DCDD8F0FCED411AC4D001083CF504501AA96E7@MTL-EXCHANGE>
	<20040723204620.30584.qmail@web20223.mail.yahoo.com>
Message-ID: <uhdrxxyql.fsf@boost-consulting.com>

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

> --- Stefan Seefeld <sseefeld at art.ca> wrote:
>> well, the reason I'm asking because I found it counter-intuitive.
>> Having defined a wrapper via
>> 
>> class_<Foo> foo("Foo");
>>
>> I'd expect to pass values around, not Foo pointers. If it is
>> a limitation of make_constructor, it should be documented.
>
> AFAICT the behavior of class_<Foo> foo("Foo") isn't affected in any way by the
> use of make_constructor. David, is this correct?

Correct.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From ingo at fargonauten.de  Sun Jul 25 14:16:37 2004
From: ingo at fargonauten.de (=?iso-8859-1?q?Ingo_L=FCtkebohle?=)
Date: Sun, 25 Jul 2004 14:16:37 +0200
Subject: [C++-sig] Re: Shared Pointers and Boost.Python
References: <20040723185047.455801E4002@bag.python.org>
	<20040723190426.97434.qmail@web20225.mail.yahoo.com>
	<uzn5pwjt5.fsf@boost-consulting.com>
Message-ID: <pan.2004.07.25.12.16.36.860705@fargonauten.de>

Am Sat, 24 Jul 2004 10:39:50 -0400 schrieb David Abrahams:
> You might want to use register_ptr_to_python<shared_ptr<X> >() for
> some shared pointers if you ever create them from C++ code,

Whats the difference between calling that method and specifying a
shared_ptr in the class_ call?  I noticed the two are mutually exclusive
(getting a failed assertion at runtime otherwise).

I'm commonly using factory methods where the smart ptr is instantiated on
the C++ side.  Mostly using std::auto_ptr.  I once had problems using
a boost::shared_ptr instead (hung on when calling 'del' from python). 
Could that be a related problem?

-- 
Ingo

Soll doch jeder bleiben, wie er gern w?re.





From bhall at gamers-fix.com  Sun Jul 25 17:32:04 2004
From: bhall at gamers-fix.com (Brian Hall)
Date: Sun, 25 Jul 2004 10:32:04 -0500
Subject: [C++-sig] Re: Shared Pointers and Boost.Python
In-Reply-To: <uzn5pwjt5.fsf@boost-consulting.com>
Message-ID: <20040725153158.4CDBF1E4002@bag.python.org>


Actually, everything he did was fine.  Wrapping classes with
shared_ptr is almost completely pointless now, since any Python object
holding an X object can be converted to a shared_ptr<X>.  The
shared_ptr has a custom deleter that manages the owning Python object's
lifetime.

You might want to use register_ptr_to_python<shared_ptr<X> >() for
some shared pointers if you ever create them from C++ code, but in
this case it never happens so they can all be automatically converted
back into Python objects by (we just extract the owning Python object
from the deleter).

-----

Actually before I tried putting the shared_ptr<> declaration in the class_
exposure, the application would crash in some code having to do with the
custom deleter.  It also was saying something about being unable to make a
to_python coverter.

Brian




From dave at boost-consulting.com  Mon Jul 26 02:48:54 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 25 Jul 2004 17:48:54 -0700
Subject: [C++-sig] Re: Shared Pointers and Boost.Python
References: <uzn5pwjt5.fsf@boost-consulting.com>
	<20040725153158.4CDBF1E4002@bag.python.org>
Message-ID: <u658bh9u1.fsf@boost-consulting.com>

"Brian Hall" <bhall at gamers-fix.com> writes:

> Actually, everything he did was fine.  Wrapping classes with
> shared_ptr is almost completely pointless now, since any Python object
> holding an X object can be converted to a shared_ptr<X>.  The
> shared_ptr has a custom deleter that manages the owning Python object's
> lifetime.
>
> You might want to use register_ptr_to_python<shared_ptr<X> >() for
> some shared pointers if you ever create them from C++ code, but in
> this case it never happens so they can all be automatically converted
> back into Python objects by (we just extract the owning Python object
> from the deleter).
>
> -----
>
> Actually before I tried putting the shared_ptr<> declaration in the class_
> exposure, the application would crash in some code having to do with the
> custom deleter.  

Details, please!  Was this for the precise test case you posted
(without the shared_ptr in the class_) or was it for some other code?

> It also was saying something about being unable to make a to_python
> coverter.

I'm pretty sure the message was that it was unable to *find* one (a
runtime message, right?)  That's why you use register_ptr_to_python.
That would only happen when calling a wrapped function returning a
shared_ptr that wasn't created from Python.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Mon Jul 26 02:56:50 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 25 Jul 2004 17:56:50 -0700
Subject: [C++-sig] Re: Shared Pointers and Boost.Python
References: <20040723185047.455801E4002@bag.python.org>
	<20040723190426.97434.qmail@web20225.mail.yahoo.com>
	<uzn5pwjt5.fsf@boost-consulting.com>
	<pan.2004.07.25.12.16.36.860705@fargonauten.de>
Message-ID: <uzn5nfuwd.fsf@boost-consulting.com>

Ingo L?tkebohle <ingo at fargonauten.de> writes:

> Am Sat, 24 Jul 2004 10:39:50 -0400 schrieb David Abrahams:
>> You might want to use register_ptr_to_python<shared_ptr<X> >() for
>> some shared pointers if you ever create them from C++ code,
>
> Whats the difference between calling that method

It's a regular function template, not a method.

> and specifying a shared_ptr in the class_ call?  I noticed the two
> are mutually exclusive (getting a failed assertion at runtime
> otherwise).

The _warning_ (it should be a warning, not an assertion -- if it's an
assertion something is very wrong) is because both of them register a
converter from shared_ptr<X> to the Python class corresponding to X,
and Boost.Python warns whenever duplicate to-python converters are
registered.

Specifying a shared_ptr in the class_<...> argument list like

           class_<X,shared_ptr<X>, ...>

additionally means that when you create an instance of the Python
class corresponding to X, it holds the X instance via shared_ptr<X>.
The only upshot is that you can pass these Python X instances to a
wrapped C++ function that takes a shared_ptr<X> by non-const reference
(rather than by value), since there really is a persistent shared_ptr
that can be modified.  The shared_ptr<T> created when you call a
wrapped C++ function taking a shared_ptr<T> by value is normally
created on-the-fly for each function call.

> I'm commonly using factory methods where the smart ptr is instantiated on
> the C++ side.  Mostly using std::auto_ptr.  I once had problems using
> a boost::shared_ptr instead (hung on when calling 'del' from python). 
> Could that be a related problem?

Related?  I guess.  You haven't given much detail so it could be
almost anything I suppose.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From seefeld at sympatico.ca  Mon Jul 26 03:10:30 2004
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Sun, 25 Jul 2004 21:10:30 -0400
Subject: [C++-sig] Re: make_constructor issues
In-Reply-To: <ubri5xypv.fsf@boost-consulting.com>
References: <20DCDD8F0FCED411AC4D001083CF504501AA96E8@MTL-EXCHANGE>
	<ubri5xypv.fsf@boost-consulting.com>
Message-ID: <41045A06.8060600@sympatico.ca>

David Abrahams wrote:

>>But copy-construct it must anyways, simply because I chose to export
>>the type as class_<Foo>, not class_<Foo, shared_ptr<Foo> > !?!
> 
> 
> No; there's no copy construction.

My understanding of 'class_<Foo>' is that a python type is generated
with an embedded 'Foo' in it. If I have a function returning a Foo (value,
pointer, reference, whatever), which can act as a constructor for a
python object holding a Foo, how can I construct my python instance without
either copy construction or assignment ?

Thanks for any clarifications,
		Stefan




From bhall at gamers-fix.com  Mon Jul 26 04:29:09 2004
From: bhall at gamers-fix.com (Brian Hall)
Date: Sun, 25 Jul 2004 21:29:09 -0500
Subject: [C++-sig] Re: Shared Pointers and Boost.Python
In-Reply-To: <u658bh9u1.fsf@boost-consulting.com>
Message-ID: <20040726022900.0A3931E4002@bag.python.org>

Yes it was for nearly the case I posted (somewhat stripped for brevity).
But it was a runtime unhandled exception that was being thrown so I'm sure
if I would have don't the register_ptr_to_python thing it would have worked
out.

-----Original Message-----
From: c++-sig-bounces at python.org [mailto:c++-sig-bounces at python.org] On
Behalf Of David Abrahams
Sent: Sunday, July 25, 2004 6:49 PM
To: c++-sig at python.org
Subject: [C++-sig] Re: Shared Pointers and Boost.Python

"Brian Hall" <bhall at gamers-fix.com> writes:

> Actually, everything he did was fine.  Wrapping classes with
> shared_ptr is almost completely pointless now, since any Python object
> holding an X object can be converted to a shared_ptr<X>.  The
> shared_ptr has a custom deleter that manages the owning Python object's
> lifetime.
>
> You might want to use register_ptr_to_python<shared_ptr<X> >() for
> some shared pointers if you ever create them from C++ code, but in
> this case it never happens so they can all be automatically converted
> back into Python objects by (we just extract the owning Python object
> from the deleter).
>
> -----
>
> Actually before I tried putting the shared_ptr<> declaration in the class_
> exposure, the application would crash in some code having to do with the
> custom deleter.  

Details, please!  Was this for the precise test case you posted
(without the shared_ptr in the class_) or was it for some other code?

> It also was saying something about being unable to make a to_python
> coverter.

I'm pretty sure the message was that it was unable to *find* one (a
runtime message, right?)  That's why you use register_ptr_to_python.
That would only happen when calling a wrapped function returning a
shared_ptr that wasn't created from Python.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

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





From bhall at gamers-fix.com  Mon Jul 26 04:30:57 2004
From: bhall at gamers-fix.com (Brian Hall)
Date: Sun, 25 Jul 2004 21:30:57 -0500
Subject: [C++-sig] Building Boost.Python via the MSVC project on VC6
Message-ID: <20040726023047.DC0AB1E4002@bag.python.org>

I'm having some troubles building Boost.Python via the supplied MSVC project
using VC6.  Below are the errors:

../../../../boost/graph/detail/adjacency_list.hpp(1055) : error C2244:
'bidirectional_graph_helper_with_property<Config>::remove_edge' : unable to
resolve function overload
../../../../boost/graph/detail/adjacency_list.hpp(1057) : error C2954:
template definitions cannot nest
../../../../boost/mem_fn.hpp(315) : error C2039: 'dm' : is not a member of
'_mfi'
../../../../boost/mem_fn.hpp(315) : error C2143: syntax error : missing ';'
before '<'
../../../../boost/mem_fn.hpp(315) : error C2501: 'dm' : missing
storage-class or type specifiers
../../../../boost/mem_fn.hpp(315) : error C2059: syntax error : ';'
../../../../boost/mem_fn.hpp(315) : error C2059: syntax error : '<'
../../../../boost/mem_fn.hpp(315) : error C2653: 'T' : is not a class or
namespace name
../../../../boost/mem_fn.hpp(315) : error C2645: no qualified name for
pointer to member (found ':: *')
../../../../boost/mem_fn.hpp(320) : error C2143: syntax error : missing ';'
before '}'
../../../../boost/mem_fn.hpp(320) : fatal error C1506: unrecoverable block
scoping error

Is there something I'm missing to get this building on VC6?

Thanks!

Brian Hall




From gaiacrtn at free.fr  Mon Jul 26 09:15:28 2004
From: gaiacrtn at free.fr (Baptiste Lepilleur)
Date: Mon, 26 Jul 2004 09:15:28 +0200
Subject: [C++-sig] Pyste: patch to fix overloaded method with policy
	generation bug
Message-ID: <005001c472e0$54bcda00$167c223e@lain>

    Pyste generates wrong code in the case of methods with overload and a
specific return value policy. The code compile but when called from python
lead to a 'can not resolve ++ call' failure (it only works if all the
arguments are specified).

For example:
class NonVirtualReturnValuePolicy
{
public:
 ValueHolder *set( const std::string &name_, int size_ = 10, int width_ =
12 )
};


The following code is generated:
.def("set",
     &NonVirtualReturnValuePolicy::set,
     return_internal_reference< 1 >(),
     py::NonVirtualReturnValuePolicy_set_overloads_1_3())


instead of:
.def("set",
     &NonVirtualReturnValuePolicy::set,
     py::NonVirtualReturnValuePolicy_set_overloads_1_3()[
  return_internal_reference< 1 >() ] )

=> the policy should be specified in square bracket.

    The attached patch fix this.

    Baptiste Lepilleur
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pyste-overload-policy.patch
Type: application/octet-stream
Size: 1368 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20040726/bd9abca0/attachment.obj>

From ingo at fargonauten.de  Mon Jul 26 10:20:28 2004
From: ingo at fargonauten.de (=?iso-8859-1?q?Ingo_L=FCtkebohle?=)
Date: Mon, 26 Jul 2004 10:20:28 +0200
Subject: [C++-sig] Re: Shared Pointers and Boost.Python
References: <20040723185047.455801E4002@bag.python.org>
	<20040723190426.97434.qmail@web20225.mail.yahoo.com>
	<uzn5pwjt5.fsf@boost-consulting.com>
	<pan.2004.07.25.12.16.36.860705@fargonauten.de>
	<uzn5nfuwd.fsf@boost-consulting.com>
Message-ID: <pan.2004.07.26.08.20.27.900925@fargonauten.de>

Am Sun, 25 Jul 2004 17:56:50 -0700 schrieb David Abrahams:
> The _warning_ (it should be a warning, not an assertion -- if it's an
> assertion something is very wrong)

It *is* an assertion.  See example at the end for this.  I'm using Boost
1.30.2

> Related?  I guess.  You haven't given much detail so it could be
> almost anything I suppose.

Hard to explain and I had trouble narrowing it down.  At the moment I'm
assuming its some threading-related problem in our code.  Thats why I
didn't report it earlier.  Your comment about creating shared_ptrs from
C++ just sparked my interest but from your explanation of the effects, I'm
back to the my-fault assumption again ;-)

Anyways, here's the example for the assertion problem.  It bombs on import.

---- begin
#include <boost/python/class.hpp>
#include <boost/python/implicit.hpp>
#include <boost/python/module.hpp>
#include <boost/python/def.hpp>
#include <boost/python/register_ptr_to_python.hpp>

using namespace std;
using namespace boost::python;
 
namespace {
        struct me;
        typedef boost::shared_ptr<me> me_ptr;
         
        struct me {
                static me_ptr create() { return me_ptr(new me()); }
        };
 
        void print(const me_ptr me)
        {
                cerr << me.get() << endl;
        }
}
 
BOOST_PYTHON_MODULE(me)
{
        register_ptr_to_python<me_ptr>();
 
        class_<me, me_ptr>("ME", no_init)
                .def("debug", &print);
         
        def("create", &me::create);
}
---- end


-- 
Ingo

Soll doch jeder bleiben, wie er gern w?re.




From dave at boost-consulting.com  Mon Jul 26 16:52:45 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 26 Jul 2004 07:52:45 -0700
Subject: [C++-sig] Re: Shared Pointers and Boost.Python
References: <20040723185047.455801E4002@bag.python.org>
	<20040723190426.97434.qmail@web20225.mail.yahoo.com>
	<uzn5pwjt5.fsf@boost-consulting.com>
	<pan.2004.07.25.12.16.36.860705@fargonauten.de>
	<uzn5nfuwd.fsf@boost-consulting.com>
	<pan.2004.07.26.08.20.27.900925@fargonauten.de>
Message-ID: <upt6ies76.fsf@boost-consulting.com>

Ingo L?tkebohle <ingo at fargonauten.de> writes:

> Am Sun, 25 Jul 2004 17:56:50 -0700 schrieb David Abrahams:
>> The _warning_ (it should be a warning, not an assertion -- if it's an
>> assertion something is very wrong)
>
> It *is* an assertion.  See example at the end for this.  I'm using Boost
> 1.30.2

Oh, well it's a warning in 1.31.0.

>> Related?  I guess.  You haven't given much detail so it could be
>> almost anything I suppose.
>
> Hard to explain and I had trouble narrowing it down.  At the moment I'm
> assuming its some threading-related problem in our code.  Thats why I
> didn't report it earlier.  Your comment about creating shared_ptrs from
> C++ just sparked my interest but from your explanation of the effects, I'm
> back to the my-fault assumption again ;-)

Oh, OK.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Mon Jul 26 16:55:11 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 26 Jul 2004 07:55:11 -0700
Subject: [C++-sig] Re: make_constructor issues
References: <20DCDD8F0FCED411AC4D001083CF504501AA96E8@MTL-EXCHANGE>
	<ubri5xypv.fsf@boost-consulting.com> <41045A06.8060600@sympatico.ca>
Message-ID: <uk6wqes34.fsf@boost-consulting.com>

Stefan Seefeld <seefeld at sympatico.ca> writes:

> David Abrahams wrote:
>
>>>But copy-construct it must anyways, simply because I chose to export
>>>the type as class_<Foo>, not class_<Foo, shared_ptr<Foo> > !?!
>> No; there's no copy construction.
>
> My understanding of 'class_<Foo>' is that a python type is generated
> with an embedded 'Foo' in it. 

That's just the  _default_ structure of a Python Foo object generated
by ordinary __init__ functions.  The ones generated by
make_constructor __init__ functions hold the [smart] pointer.

> If I have a function returning a Foo (value, pointer, reference,
> whatever), which can act as a constructor for a python object
> holding a Foo, how can I construct my python instance without either
> copy construction or assignment ?

> Thanks for any clarifications,
> 		Stefan

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Mon Jul 26 16:56:14 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 26 Jul 2004 07:56:14 -0700
Subject: [C++-sig] Re: Building Boost.Python via the MSVC project on VC6
References: <20040726023047.DC0AB1E4002@bag.python.org>
Message-ID: <uekmyes1d.fsf@boost-consulting.com>

"Brian Hall" <bhall at gamers-fix.com> writes:

> I'm having some troubles building Boost.Python via the supplied MSVC project
> using VC6.  Below are the errors:
>
> ../../../../boost/graph/detail/adjacency_list.hpp(1055) : error C2244:
> 'bidirectional_graph_helper_with_property<Config>::remove_edge' : unable to
> resolve function overload
> ../../../../boost/graph/detail/adjacency_list.hpp(1057) : error C2954:
> template definitions cannot nest
> ../../../../boost/mem_fn.hpp(315) : error C2039: 'dm' : is not a member of
> '_mfi'
> ../../../../boost/mem_fn.hpp(315) : error C2143: syntax error : missing ';'
> before '<'
> ../../../../boost/mem_fn.hpp(315) : error C2501: 'dm' : missing
> storage-class or type specifiers
> ../../../../boost/mem_fn.hpp(315) : error C2059: syntax error : ';'
> ../../../../boost/mem_fn.hpp(315) : error C2059: syntax error : '<'
> ../../../../boost/mem_fn.hpp(315) : error C2653: 'T' : is not a class or
> namespace name
> ../../../../boost/mem_fn.hpp(315) : error C2645: no qualified name for
> pointer to member (found ':: *')
> ../../../../boost/mem_fn.hpp(320) : error C2143: syntax error : missing ';'
> before '}'
> ../../../../boost/mem_fn.hpp(320) : fatal error C1506: unrecoverable block
> scoping error
>
> Is there something I'm missing to get this building on VC6?

1.31.0 shipped with an MSVC6 regression.  You can use the current CVS
state instead.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From sseefeld at art.ca  Mon Jul 26 17:07:10 2004
From: sseefeld at art.ca (Stefan Seefeld)
Date: Mon, 26 Jul 2004 11:07:10 -0400
Subject: [C++-sig] Re: make_constructor issues
Message-ID: <20DCDD8F0FCED411AC4D001083CF504501AA96EA@MTL-EXCHANGE>


> > My understanding of 'class_<Foo>' is that a python type is generated
> > with an embedded 'Foo' in it. 
> 
> That's just the  _default_ structure of a Python Foo object generated
> by ordinary __init__ functions.  The ones generated by
> make_constructor __init__ functions hold the [smart] pointer.

so are you saying that the actual shape of the python object depends
on how I generate it ? (am I just too much used to statically typed
languages to see the light here ?)

By the way, I just run into the 'Internals Documentation'
(http://www.boost.org/libs/python/doc/internals.html) which looks like
it has the potential to clarify a lot of these questions. Unfortunately
it seems to be very sparse as of now.

Regards,
		Stefan
 


From dave at boost-consulting.com  Mon Jul 26 17:43:37 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 26 Jul 2004 08:43:37 -0700
Subject: [C++-sig] New-style polymorphism
Message-ID: <usmbedb9y.fsf@boost-consulting.com>


I just checked in changes that improve the way we can wrap classes
with virtual functions in Boost.Python.  This is essentially what's
described in
http://www.boost.org/libs/python/todo.html#base-class-for-virtual-function-callback-wrappers


The differences are most apparent if you compare
libs/python/test/polymorphism.cpp and
libs/python/test/polymorphism2.cpp.

  * you no longer need an initial "self" argument to yourconstructor.
    Instead you derive your class X from wrapper<X> (I'm looking for
    better names for that base class)

  * You no longer need to define a special "default" member function
    for the default behavior, and you only have to pass one member
    function pointer to "def()"

  * You no longer need to use call_method; you instead ask the
    wrapper<X> base class for the method override, and then call that
    instead.  If there's no override, you call the default directly.
    On some broken compilers you may need to use
    call<result_type>(...) args for some of the calls (always on
    vc6/7, for reference return types only on some other compielrs).
    Most other reasonably conforming compilers will convert the result
    of calling the override directly into the function's return type.

  * It should be much faster in the case where you have a default
    implementation that isn't overridden in Python, because you'll
    usually not have to enter the Python interpreter.

  * Many problems with dangling references have been eliminated,
    because you don't have to take a round-trip through Python.  You
    can wrap virtual functions that return char const* !

I hope to get this documented before the release, but in case I
don't, the old method still works; I'd like people to get some
experience with this new feature though, so I can see if it's working
out as it should.  It would be great if Pyste could be switched to
generate the appropriate code.

Thanks,
-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Mon Jul 26 18:41:29 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 26 Jul 2004 09:41:29 -0700
Subject: [C++-sig] Re: Building Boost.Python via the MSVC project on VC6
References: <20040726023047.DC0AB1E4002@bag.python.org>
	<uekmyes1d.fsf@boost-consulting.com>
Message-ID: <uacxmd8li.fsf@boost-consulting.com>

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

> "Brian Hall" <bhall at gamers-fix.com> writes:
>
>> I'm having some troubles building Boost.Python via the supplied MSVC project
>> using VC6.  Below are the errors:
>>
>> ../../../../boost/graph/detail/adjacency_list.hpp(1055) : error C2244:
>> 'bidirectional_graph_helper_with_property<Config>::remove_edge' : unable to
>> resolve function overload
>> ../../../../boost/graph/detail/adjacency_list.hpp(1057) : error C2954:
>> template definitions cannot nest
>> ../../../../boost/mem_fn.hpp(315) : error C2039: 'dm' : is not a member of
>> '_mfi'
>> ../../../../boost/mem_fn.hpp(315) : error C2143: syntax error : missing ';'
>> before '<'
>> ../../../../boost/mem_fn.hpp(315) : error C2501: 'dm' : missing
>> storage-class or type specifiers
>> ../../../../boost/mem_fn.hpp(315) : error C2059: syntax error : ';'
>> ../../../../boost/mem_fn.hpp(315) : error C2059: syntax error : '<'
>> ../../../../boost/mem_fn.hpp(315) : error C2653: 'T' : is not a class or
>> namespace name
>> ../../../../boost/mem_fn.hpp(315) : error C2645: no qualified name for
>> pointer to member (found ':: *')
>> ../../../../boost/mem_fn.hpp(320) : error C2143: syntax error : missing ';'
>> before '}'
>> ../../../../boost/mem_fn.hpp(320) : fatal error C1506: unrecoverable block
>> scoping error
>>
>> Is there something I'm missing to get this building on VC6?
>
> 1.31.0 shipped with an MSVC6 regression.  You can use the current CVS
> state instead.

Except that now there's a source file you need to add: libs/python/src/wrapper.cpp
-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Mon Jul 26 18:44:25 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 26 Jul 2004 09:44:25 -0700
Subject: [C++-sig] Re: New-style polymorphism
References: <usmbedb9y.fsf@boost-consulting.com>
Message-ID: <u7jsqd8gm.fsf@boost-consulting.com>

I forgot one thing:

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

> I just checked in changes that improve the way we can wrap classes
> with virtual functions in Boost.Python.  This is essentially what's
> described in
> http://www.boost.org/libs/python/todo.html#base-class-for-virtual-function-callback-wrappers
>
>
> The differences are most apparent if you compare
> libs/python/test/polymorphism.cpp and
> libs/python/test/polymorphism2.cpp.
>
>   * you no longer need an initial "self" argument to yourconstructor.
>     Instead you derive your class X from wrapper<X> (I'm looking for
>     better names for that base class)
>
>   * You no longer need to define a special "default" member function
>     for the default behavior, and you only have to pass one member
>     function pointer to "def()"
>
>   * You no longer need to use call_method; you instead ask the
>     wrapper<X> base class for the method override, and then call that
>     instead.  If there's no override, you call the default directly.
>     On some broken compilers you may need to use
>     call<result_type>(...) args for some of the calls (always on
>     vc6/7, for reference return types only on some other compielrs).
>     Most other reasonably conforming compilers will convert the result
>     of calling the override directly into the function's return type.
>
>   * It should be much faster in the case where you have a default
>     implementation that isn't overridden in Python, because you'll
>     usually not have to enter the Python interpreter.
>
>   * Many problems with dangling references have been eliminated,
>     because you don't have to take a round-trip through Python.  You
>     can wrap virtual functions that return char const* !

    * A C++ pointer or reference to a polymorphic T created from
      Python (one that is actually also a wrapper<T>) can be
      converted back to Python without creating a new Python object.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From bhall at gamers-fix.com  Mon Jul 26 20:29:27 2004
From: bhall at gamers-fix.com (bhall at gamers-fix.com)
Date: 26 Jul 2004 18:29:27 -0000
Subject: [C++-sig] (no subject)
Message-ID: <20040726182927.85212.qmail@rs152.securehostserver.com>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20040726/cb24dbf6/attachment.txt>

From dalwan01 at student.umu.se  Tue Jul 27 02:22:02 2004
From: dalwan01 at student.umu.se (Daniel Wallin)
Date: Tue, 27 Jul 2004 02:22:02 +0200
Subject: [C++-sig] Re: New-style polymorphism
In-Reply-To: <usmbedb9y.fsf@boost-consulting.com>
References: <usmbedb9y.fsf@boost-consulting.com>
Message-ID: <ce4778$mep$1@sea.gmane.org>

David Abrahams wrote:
> I hope to get this documented before the release, but in case I
> don't, the old method still works; I'd like people to get some
> experience with this new feature though, so I can see if it's working
> out as it should.

Here's a problem: Trying to call a base class member function statically
from python will call the virtual function, resulting in infinite
recursion.

-- 
Daniel Wallin
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: failed.py
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20040727/3f14cae2/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: failed.cpp
Type: text/x-csrc
Size: 494 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20040727/3f14cae2/attachment.c>

From dave at boost-consulting.com  Tue Jul 27 14:58:19 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Tue, 27 Jul 2004 05:58:19 -0700
Subject: [C++-sig] Re: New-style polymorphism
References: <usmbedb9y.fsf@boost-consulting.com> <ce4778$mep$1@sea.gmane.org>
Message-ID: <u4qnta9p0.fsf@boost-consulting.com>

Daniel Wallin <dalwan01 at student.umu.se> writes:

> David Abrahams wrote:
>> I hope to get this documented before the release, but in case I
>> don't, the old method still works; I'd like people to get some
>> experience with this new feature though, so I can see if it's working
>> out as it should.
>
> Here's a problem: Trying to call a base class member function statically
> from python will call the virtual function, resulting in infinite
> recursion.

#*&!!!@@

How could I miss that one?  And how did it ever work, even with the
existing mechanism?

I'll look into this, but I'm not optimistic it can be fixed :(.

> -- 
> Daniel Wallin
> from failed import *
>
> class B(A):
>     def f(self):
>         A.f(self)
>
> B().f()
>
>
> #include <boost/python/module.hpp>
> #include <boost/python/wrapper.hpp>
> #include <boost/python/class.hpp>
>
> using namespace boost::python;
>
> struct A
> {
>     virtual ~A() {}
>     virtual void f() {}
> };
>
> struct AWrap : A, wrapper<A> 
> {
>     void f()
>     {
>         if (override f = get_override("f"))
>         {
>             f();
>         }
>         else
>         {
>             A::f();
>         }
>     }
> };
>
> BOOST_PYTHON_MODULE(failed)
> {
>     class_<AWrap, boost::noncopyable>("A")
>         .def("f", &A::f);
> }
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From chrish at debian.org  Tue Jul 27 20:57:32 2004
From: chrish at debian.org (Christian Hudon)
Date: Tue, 27 Jul 2004 14:57:32 -0400
Subject: [C++-sig] Pyste: Thinko in CppParser.py + bug when bool(tail) ==
	True
Message-ID: <4106A59C.8090907@debian.org>

Hi,

the following patch fixes a small thinko in Pyste's CppParser.py

--- src/Pyste/CppParser.py      18 Jul 2004 15:50:10 -0000      1.11
+++ src/Pyste/CppParser.py      27 Jul 2004 16:40:17 -0000
@@ -153,7 +153,7 @@
          '''
          if tail is None:
              tail = ''
-        tail.strip()
+        tail = tail.strip()
          declarations = self.GetCache(header, interface, tail)
          if declarations is None:
              declarations = self.ParseWithGCCXML(header, tail)

The reason I found out about this is because of another bug. I'm not 
sure how best to fix it (actually, I'm not sure I understand the reason 
for the whole tail thing), so I'll just describe the bug here and let 
better minds than mine think about how best to solve it.

The problem is triggered when bool(tail) (after stripping) evaluates to 
True. Then the contents of the input C++ file is copied over to a 
temporary file (in /tmp), with the contents of tail appendede to it, and 
gccxml then works on that file. The problem is, this breaks things if 
the file does #include "someotherstuff.h". Before invoking gccxml, the 
name of the directory containing the C++ file being processed is 
prepended to the list of include directories. When bool(tail) == False 
this isn't necessary, because gccxml is working on the actual C++ file, 
not a copy in another directory. When bool(tail) == True this doesn't 
work because it adds -I /tmp, which is useless because the include files 
that were in the same directory as the C++ file being parsed weren't 
copied over to /tmp.

I can see two possible fixes. Not sure which one is better. Tell me if 
I'm missing something...

1. Prepend the directory of the original C++ file to the include path, 
not that of the copy being made in /tmp. (Unless I'm mistaken, there 
shouldn't be any need to modify the include path when we're not copying 
the file to /tmp.)

2. When bool(tail) == True, instead of copying the contents of the C++ 
file to a temporary file, create a new .h file in /tmp that contains 
#include "/full/path/to/original/cpp_file" followed then by the contents 
of tail. That way you shouldn't need to add directories to the include path.

Hope this is useful...

   Christian

PS Thanks for a great tool.


From ndbecker2 at verizon.net  Tue Jul 27 22:21:43 2004
From: ndbecker2 at verizon.net (Neal D. Becker)
Date: Tue, 27 Jul 2004 16:21:43 -0400
Subject: [C++-sig] wrapping boost::optional
Message-ID: <ce6dgn$g06$1@sea.gmane.org>

I'm trying to wrap boost::optional<T>.  I have an adequate solution here:

#include <boost/optional.hpp>
#include <boost/python/module.hpp>
#include <boost/python/def.hpp>
#include <boost/python/class.hpp>
#include <boost/python/init.hpp>
#include <boost/python/operators.hpp>

using namespace boost::python;

template<typename T>
inline void set (boost::optional<T>& o, T x) {
  o = x;
}
  
template<typename T>
inline T get (boost::optional<T>& o) {
  return o.get();
}

#define OPTIONAL(T)\
  class_<boost::optional<T> >("opt_"#T) \
    .def ("set", &set<T>) \
    .def ("get", &get<T>) \
    .def (!(self)) \
    ;

BOOST_PYTHON_MODULE(optional_wrap)
{
  OPTIONAL(int)
  
  OPTIONAL(double)
}

What would be better, though, is that if the option is not initialized, it
should return None in response to get.  That would be more pythonic, no? 
Problem is, I don't know how to do that.  Any hints?



From sashang at ihug.co.nz  Wed Jul 28 05:39:06 2004
From: sashang at ihug.co.nz (sashan)
Date: Wed, 28 Jul 2004 15:39:06 +1200
Subject: [C++-sig] Re: Boost::Python for C code -> Segmentation fault
In-Reply-To: <cdqlid$asb$1@sea.gmane.org>
References: <OFCF9414FF.4F9D433C-ONC1256ED9.0067D366@no>	<41003BA1.15661.983170E@localhost>	<uu0vz3dm8.fsf@boost-consulting.com>
	<cdqlid$asb$1@sea.gmane.org>
Message-ID: <ce77a0$sig$1@sea.gmane.org>

Mario Palomo wrote:
> It doesn't work. I get the same segfault with the extern "C" and without 
> the extern "C".
> 
> I'll try make_setter and make_getter rather than def_readwrite(). Then 
> I'll try to run python inside gdb and get a backtrace (bt) of where the 
> segfault is happening... Can someone reproduce my segfault?
> 

For what its worth I can repro it.

/***************************************************************/
#include <stdio.h>

typedef struct user {
   char *name;
   int number;
}user;

#include <boost/python/module.hpp>
#include <boost/python/def.hpp>
#include <boost/python/class.hpp>
using namespace boost::python;

BOOST_PYTHON_MODULE(segfault)
{
   class_<user>("user")
     .def_readwrite("name",   &user::name)
     .def_readwrite("number", &user::number)
   ;
}
/***************************************************************/
To build:
g++ -g -c segfault.cpp -Wall -I/usr/include/python2.3
ld -shared -o segfault.so segfault.o -lboost_python

Running:
from segfault import *
u = user()
u.number = 1
Segmentation fault

I'm using the boost package that comes with Gentoo's portage system. 
I've never had any luck building python extensions with it. The only way 
i've been able to build extensions is by downloading the tarball, and 
setting up the boost stuff from there and using bjam to build the extension.
-- 
sashan



From rwgk at yahoo.com  Wed Jul 28 07:48:35 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 27 Jul 2004 22:48:35 -0700 (PDT)
Subject: [C++-sig] Re: Boost::Python for C code -> Segmentation fault
In-Reply-To: <ce77a0$sig$1@sea.gmane.org>
Message-ID: <20040728054835.18629.qmail@web20227.mail.yahoo.com>

--- sashan <sashang at ihug.co.nz> wrote:
> Mario Palomo wrote:
> > It doesn't work. I get the same segfault with the extern "C" and without 
> > the extern "C".
> > 
> > I'll try make_setter and make_getter rather than def_readwrite(). Then 
> > I'll try to run python inside gdb and get a backtrace (bt) of where the 
> > segfault is happening... Can someone reproduce my segfault?
> > 
> 
> For what its worth I can repro it.

There is no segfault under Red Hat 8 when using these commands:

g++ -fPIC -O0 -I/net/worm/scratch1/rwgk/dist/boost -I/usr/include/python2.2 -c
-o segfault.os segfault.cpp
g++ -shared -o segfault.so segfault.os -Llibtbx -lboost_python -lm

from segfault import *
u = user()
u.number = 1
print u.number
u.name = "abc"
print u.name

1
Traceback (most recent call last):
  File "zi", line 6, in ?
    print u.name
TypeError: No to_python (by-value) converter found for C++ type: char*

The TypeError is expected. I don't know why the assignment to u.name doesn't
throw an expection. Ideally the def_readwrite("name", ...) shouldn't even
compile.

Advice:
  - first try to build some simple examples that are known to work.
  - don't wrap assignments to raw pointers if there is nothing
    to manage the lifetime of the pointee. Boost.Python doesn't do
    this for you.

Ralf



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 


From roman_yakovenko at yahoo.com  Wed Jul 28 08:06:33 2004
From: roman_yakovenko at yahoo.com (Roman Yakovenko)
Date: Tue, 27 Jul 2004 23:06:33 -0700 (PDT)
Subject: [C++-sig] New-style polymorphism
Message-ID: <20040728060633.21728.qmail@web50705.mail.yahoo.com>

> From: David Abrahams
[mailto:dave at boost-consulting.com]

> The differences are most apparent if you compare
> libs/python/test/polymorphism.cpp and
> libs/python/test/polymorphism2.cpp.
> 
>   * you no longer need an initial "self" argument to
yourconstructor.
>     Instead you derive your class X from wrapper<X>
(I'm looking for
>     better names for that base class)

call_dispatch, dispatch

> I hope to get this documented before the release,
but in case I
> don't, the old method still works; I'd like people
to get some
> experience with this new feature though, so I can
see if it's working
> out as it should.  It would be great if Pyste could
be switched to
> generate the appropriate code.

I already have pyste patch, I need to test it more. I
will submit in a few days.
 




		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail


From sashang at ihug.co.nz  Wed Jul 28 08:31:42 2004
From: sashang at ihug.co.nz (sashan)
Date: Wed, 28 Jul 2004 18:31:42 +1200
Subject: [C++-sig] Re: Boost::Python for C code -> Segmentation fault
In-Reply-To: <20040728054835.18629.qmail@web20227.mail.yahoo.com>
References: <ce77a0$sig$1@sea.gmane.org>
	<20040728054835.18629.qmail@web20227.mail.yahoo.com>
Message-ID: <ce7hdk$car$1@sea.gmane.org>

> 
> There is no segfault under Red Hat 8 when using these commands:
> 
> g++ -fPIC -O0 -I/net/worm/scratch1/rwgk/dist/boost -I/usr/include/python2.2 -c
> -o segfault.os segfault.cpp
> g++ -shared -o segfault.so segfault.os -Llibtbx -lboost_python -lm
>

Thanks for that. The following works for me:

g++ -g -I/usr/include/python2.3 -c -osegfault.o segfault.cpp
g++ -shared -osegfault.so segfault.o -lboost_python

whereas if I used ld to do the linking:

ld -shared -osegfault.so segfault.o -lboost_python

a segfault occurs. I don't know why.
-- 
sashan



From rwgk at yahoo.com  Wed Jul 28 10:39:43 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 28 Jul 2004 01:39:43 -0700 (PDT)
Subject: [C++-sig] Re: Boost::Python for C code -> Segmentation fault
In-Reply-To: <ce7hdk$car$1@sea.gmane.org>
Message-ID: <20040728083943.24479.qmail@web20224.mail.yahoo.com>

--- sashan <sashang at ihug.co.nz> wrote:

> > 
> > There is no segfault under Red Hat 8 when using these commands:
> > 
> > g++ -fPIC -O0 -I/net/worm/scratch1/rwgk/dist/boost -I/usr/include/python2.2
> -c
> > -o segfault.os segfault.cpp
> > g++ -shared -o segfault.so segfault.os -Llibtbx -lboost_python -lm
> >
> 
> Thanks for that. The following works for me:
> 
> g++ -g -I/usr/include/python2.3 -c -osegfault.o segfault.cpp
> g++ -shared -osegfault.so segfault.o -lboost_python
> 
> whereas if I used ld to do the linking:
> 
> ld -shared -osegfault.so segfault.o -lboost_python
> 
> a segfault occurs. I don't know why.

Probably because the g++ front-end implicitly adds different runtime libraries.
Ralf



		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 


From roman_yakovenko at yahoo.com  Wed Jul 28 11:11:30 2004
From: roman_yakovenko at yahoo.com (Roman Yakovenko)
Date: Wed, 28 Jul 2004 02:11:30 -0700 (PDT)
Subject: [C++-sig] pyste patch for  new-style polymorphism
Message-ID: <20040728091130.13570.qmail@web50702.mail.yahoo.com>

Hi. I wrote pyste patch for new-style polymorphism.
I testes it. It seems to work fine, without breaking
anything else. 
Patch description: patch consist from 2 files. The
first 
one is pyste_future.py. It purpose is similar to
"import ??? from future". It defines call_dispatch
boolean constant. The second one is edited
ClassExporter.py. Also 
I send difference file. 

Roman.


		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ClassExporter.py
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20040728/1fa2f399/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pyste_future.py
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20040728/1fa2f399/attachment-0001.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ClassExporter.diff
Type: application/octet-stream
Size: 4000 bytes
Desc: ClassExporter.diff
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20040728/1fa2f399/attachment.obj>

From mario-p at iname.com  Wed Jul 28 13:18:16 2004
From: mario-p at iname.com (Mario Palomo)
Date: Wed, 28 Jul 2004 13:18:16 +0200
Subject: [C++-sig] Re: Boost::Python for C code -> Segmentation fault
In-Reply-To: <20040728083943.24479.qmail@web20224.mail.yahoo.com>
References: <ce7hdk$car$1@sea.gmane.org>
	<20040728083943.24479.qmail@web20224.mail.yahoo.com>
Message-ID: <ce821p$g87$1@sea.gmane.org>

Thanks a lot!!

Using Linux (Debian Sid) Boost::Python packages and using g++ to link works for 
me too.

I've changed the original file to use 'int name' instead of 'char *name':

FILE: hello.cpp
=================== BEGIN =======================
#include <stdio.h>

//typedef
struct user {
   int name;
   int number;
};//user;

void greet(user *u)
{
   printf("Hello %d, your number is %d.\n", u->name, u->number);
}

/*-------------------------------------------- */

#include <boost/python/module.hpp>
#include <boost/python/def.hpp>
#include <boost/python/class.hpp>
using namespace boost::python;

BOOST_PYTHON_MODULE(hello)
{
   class_<user>("user")
     .def_readwrite("name",   &user::name)
     .def_readwrite("number", &user::number)
   ;

   def("greet", greet);
}
==================== END ========================


$ g++ -c hello.cpp -Wall -I/usr/include/python2.3
$ g++ -shared -o hello.so hello.o -lboost_python

$ python
Python 2.3.4 (#2, Jul  5 2004, 09:15:05)
[GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> import hello
 >>> u = hello.user()
 >>> u.number=10
 >>> u.name=20
 >>> hello.greet(u)
Hello 20, your number is 10.
 >>>
$

Using 'ldd' I get the segfault (even if I use 'int name').
Then, should I use always g++ for linking C++ code?
I've been using 'ldd' for years... :-)


Ralf W. Grosse-Kunstleve wrote:
> --- sashan <sashang at ihug.co.nz> wrote:
> 
> 
>>>There is no segfault under Red Hat 8 when using these commands:
>>>
>>>g++ -fPIC -O0 -I/net/worm/scratch1/rwgk/dist/boost -I/usr/include/python2.2
>>
>>-c
>>
>>>-o segfault.os segfault.cpp
>>>g++ -shared -o segfault.so segfault.os -Llibtbx -lboost_python -lm
>>>
>>
>>Thanks for that. The following works for me:
>>
>>g++ -g -I/usr/include/python2.3 -c -osegfault.o segfault.cpp
>>g++ -shared -osegfault.so segfault.o -lboost_python
>>
>>whereas if I used ld to do the linking:
>>
>>ld -shared -osegfault.so segfault.o -lboost_python
>>
>>a segfault occurs. I don't know why.
> 
> 
> Probably because the g++ front-end implicitly adds different runtime libraries.
> Ralf
> 
> 
> 
> 		
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail Address AutoComplete - You start. We finish.
> http://promotions.yahoo.com/new_mail 



From rwgk at yahoo.com  Wed Jul 28 17:22:08 2004
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Wed, 28 Jul 2004 08:22:08 -0700 (PDT)
Subject: [C++-sig] Re: Boost::Python for C code -> Segmentation fault
In-Reply-To: <ce821p$g87$1@sea.gmane.org>
Message-ID: <20040728152208.16496.qmail@web20221.mail.yahoo.com>

--- Mario Palomo <mario-p at iname.com> wrote:
> Using 'ldd' I get the segfault (even if I use 'int name').
> Then, should I use always g++ for linking C++ code?

Unless you are mixing with other languages that is probably the best idea. You
can probably add the correct runtime libraries to your ldd link line, but
finding out what the libraries are may be difficult and highly platform
specific.

Ralf



		
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail


From dave at boost-consulting.com  Wed Jul 28 17:48:16 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 28 Jul 2004 08:48:16 -0700
Subject: [C++-sig] Re: pyste patch for  new-style polymorphism
References: <20040728091130.13570.qmail@web50702.mail.yahoo.com>
Message-ID: <uacxkp1z3.fsf@boost-consulting.com>

Roman Yakovenko <roman_yakovenko at yahoo.com> writes:

> Hi. I wrote pyste patch for new-style polymorphism.
> I testes it. It seems to work fine, without breaking
> anything else. 
> Patch description: patch consist from 2 files. The
> first 
> one is pyste_future.py. It purpose is similar to
> "import ??? from future". It defines call_dispatch
> boolean constant. The second one is edited
> ClassExporter.py. Also 
> I send difference file. 

FYI, 

1. you need to keep the old approach for handling default virtual
   function implementations in there, *in addition* to using the new
   approach.

2. When calling an override, you still need to use ptr(x) and ref(x)
   as appropriate to pass pointers and references.

Cheers,
-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Wed Jul 28 17:45:45 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 28 Jul 2004 08:45:45 -0700
Subject: [C++-sig] Re: wrapping boost::optional
References: <ce6dgn$g06$1@sea.gmane.org>
Message-ID: <ufz7cp23a.fsf@boost-consulting.com>

"Neal D. Becker" <ndbecker2 at verizon.net> writes:

> What would be better, though, is that if the option is not initialized, it
> should return None in response to get.  That would be more pythonic, no? 
> Problem is, I don't know how to do that.  Any hints?

template<typename T>
inline object get (boost::optional<T>& o) {
  return o ? object() : object(o.get());
}

You'll have some issues with policies and ownership if you ever want
to wrap optional<T*> or optional<T&>, but this should be enough to get
you started.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From dave at boost-consulting.com  Wed Jul 28 17:40:05 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Wed, 28 Jul 2004 08:40:05 -0700
Subject: [C++-sig] Re: New-style polymorphism
References: <usmbedb9y.fsf@boost-consulting.com> <ce4778$mep$1@sea.gmane.org>
	<u4qnta9p0.fsf@boost-consulting.com>
Message-ID: <uoem0p2cq.fsf@boost-consulting.com>

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

> Daniel Wallin <dalwan01 at student.umu.se> writes:
>
>> David Abrahams wrote:
>>> I hope to get this documented before the release, but in case I
>>> don't, the old method still works; I'd like people to get some
>>> experience with this new feature though, so I can see if it's working
>>> out as it should.
>>
>> Here's a problem: Trying to call a base class member function statically
>> from python will call the virtual function, resulting in infinite
>> recursion.
>
> #*&!!!@@
>
> How could I miss that one?  And how did it ever work, even with the
> existing mechanism?
>
> I'll look into this, but I'm not optimistic it can be fixed :(.

Actually, the solution is to keep using the same way of exposing the
default method implementation: write a default_f member function that
calls the default implementation and expose it during wrapping.  That
removes one of the advantages, leaving us with this list:

  * you no longer need an initial "self" argument to yourconstructor.
    Instead you derive your class X from wrapper<X> (I'm looking for
    better names for that base class)

  * You no longer need to use call_method; you instead ask the
    wrapper<X> base class for the method override, and then call that
    instead.  If there's no override, you call the default directly.
    On some broken compilers you may need to use
    call<result_type>(...) args for some of the calls (always on
    vc6/7, for reference return types only on some other compielrs).
    Most other reasonably conforming compilers will convert the result
    of calling the override directly into the function's return type.

  * It should be much faster in the case where you have a default
    implementation that isn't overridden in Python, because you'll
    usually not have to enter the Python interpreter.

  * Many problems with dangling references have been eliminated,
    because you don't have to take a round-trip through Python.  You
    can wrap virtual functions that return char const* !

  * A C++ pointer or reference to a polymorphic T created from
    Python (one that is actually also a wrapper<T>) can be
    converted back to Python without creating a new Python object.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From ndbecker2 at verizon.net  Wed Jul 28 18:50:05 2004
From: ndbecker2 at verizon.net (Neal D. Becker)
Date: Wed, 28 Jul 2004 12:50:05 -0400
Subject: [C++-sig] Re: wrapping boost::optional
References: <ce6dgn$g06$1@sea.gmane.org> <ufz7cp23a.fsf@boost-consulting.com>
Message-ID: <ce8lfu$50u$1@sea.gmane.org>

David Abrahams wrote:

> "Neal D. Becker" <ndbecker2 at verizon.net> writes:
> 
>> What would be better, though, is that if the option is not initialized,
>> it
>> should return None in response to get.  That would be more pythonic, no?
>> Problem is, I don't know how to do that.  Any hints?
> 
> template<typename T>
> inline object get (boost::optional<T>& o) {
>   return o ? object() : object(o.get());
> }
> 
> You'll have some issues with policies and ownership if you ever want
> to wrap optional<T*> or optional<T&>, but this should be enough to get
> you started.
> 

Thanks.  Doesn't seem to work though:
>>> o=optional_wrap.opt_int()
>>> o
<optional_wrap.opt_int object at 0x550737d4>
>>> o.get()
1426232544

Here is the complete code:
#include <boost/python/module.hpp>
#include <boost/python/def.hpp>
#include <boost/python/class.hpp>
#include <boost/python/init.hpp>
#include <boost/python/operators.hpp>

using namespace boost::python;

template<typename T>
inline void set (boost::optional<T>& o, T x) {
  o = x;
}
  

template<typename T>
inline object get (boost::optional<T>& o) {
  return o ? object() : object(o.get());
}

#define OPTIONAL(T)\
  class_<boost::optional<T> >("opt_"#T) \
    .def ("set", &set<T>) \
    .def ("get", &get<T>) \
    .def (!(self)) \
    ;

BOOST_PYTHON_MODULE(optional_wrap)
{

  OPTIONAL(int)
  
  OPTIONAL(double)
}




From mike at nospam.com  Wed Jul 28 20:19:13 2004
From: mike at nospam.com (Mike Rovner)
Date: Wed, 28 Jul 2004 11:19:13 -0700
Subject: [C++-sig] Re: wrapping boost::optional
References: <ce6dgn$g06$1@sea.gmane.org> <ufz7cp23a.fsf@boost-consulting.com>
Message-ID: <ce8qmt$j83$1@sea.gmane.org>

David Abrahams wrote:
> "Neal D. Becker" <ndbecker2 at verizon.net> writes:

> template<typename T>
> inline object get (boost::optional<T>& o) {
>   return o ? object() : object(o.get());

return o ? object(o.get()) : object();      // !?

Mike





From ndbecker2 at verizon.net  Thu Jul 29 16:48:42 2004
From: ndbecker2 at verizon.net (Neal D. Becker)
Date: Thu, 29 Jul 2004 10:48:42 -0400
Subject: [C++-sig] Interface slices between python and c++
Message-ID: <ceb2oa$2b7$1@sea.gmane.org>

I now have some experience using boost::python with vector_indexing_suite to
expose std::vector objects to python.  Using this, it is easy to expose c++
algorithms written for stl-style iterators.

Consider an algorithm F1:

template<typename it_t>
void F1 (it_t start, it_t end);

We can do:

template<typename cont>
void wrap_f1 (cont c) {
  F1 (c.begin(), c.end());
}

and then expose wrap_f1<vector<double> >, for example.

But now, suppose we want to apply algorithm F1 to a *slice* of a vector?

I noticed that in boost.cvs, there is "slice.hpp".  AFAICT,
vector_indexing_suite is not using it, though.

OK, so my question is, what is a "good" approach to this?  I would add, I
think this must be a very common issue.



From ndbecker2 at verizon.net  Thu Jul 29 22:27:03 2004
From: ndbecker2 at verizon.net (Neal D. Becker)
Date: Thu, 29 Jul 2004 16:27:03 -0400
Subject: [C++-sig] Re: Interface slices between python and c++
References: <ceb2oa$2b7$1@sea.gmane.org>
Message-ID: <cebmio$oi2$1@sea.gmane.org>

I think I may have answered my own question.  We can make a vector, and also
a vector_slice object.  Some sample code is below.  One thing I still need
to figure out, is I know I need to increment refcnt of vector when creating
vector_slice, but I don't yet know how to do it.

A vector_slice object has usual c++ iterator protocol, so I can pass it to a
generic c++ algorithm without having to write a new wrapper.  (The same
wrapper that works for vector also works for vector_slice.)


Comments?

example:

python
Python 2.3.3 (#1, May  7 2004, 10:31:40) 
[GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from vector import *
>>> v=IVec(10)
>>> for i in xrange(0,10):
...   v[i]=i
... 
>>> IVecSliceTimesIntInplace (IVec_slice (v, slice (0,4)), 2)
>>> [e for e in v]
[0, 2, 4, 6, 4, 5, 6, 7, 8, 9]
>>> 

vector.cc:
#include <boost/python/class.hpp>
#include <boost/python/init.hpp>
#include <boost/python/module.hpp>
#include <boost/python/def.hpp>
#include <boost/python/operators.hpp>
#include <boost/python/suite/indexing/vector_indexing_suite.hpp>
#include <boost/python/slice.hpp>
#include <string>
#include <vector>
#include <complex>
#include <iostream>
#include <numeric>
#include <iterator>
#include <boost/type_traits.hpp>
#include "mismatch.H"

typedef std::complex<double> Complex;
typedef std::complex<int> ComplexI;

using namespace boost::python;

template<typename in1_cont_t, typename in2_cont_t, typename out_cont_t>
inline void add_vector_wrapper (in1_cont_t in1, in2_cont_t in2, out_cont_t
out) {
  typedef typename boost::remove_reference<in1_cont_t>::type::const_iterator
it1_t;
  typedef typename boost::remove_reference<in2_cont_t>::type::const_iterator
it2_t;
  typedef typename boost::remove_reference<out_cont_t>::type::iterator
it3_t;

  if (in1.size() != in2.size() || in1.size() != out.size())
    throw size_mismatch();
  
  it1_t it1 = in1.begin();
  it2_t it2 = in2.begin();
  it3_t it3 = out.begin();
  for ( ; it1 != in1.end(); it1++, it2++, it3++)
    *it3 = *it1 + *it2;
}

template<typename in1_cont_t, typename scale_t, typename out_cont_t>
inline void times_vector_scalar_wrapper (in1_cont_t in1, scale_t scale,
out_cont_t out) {
  typedef typename boost::remove_reference<in1_cont_t>::type::const_iterator
it1_t;
  typedef typename boost::remove_reference<out_cont_t>::type::iterator
it2_t;

  if (in1.size() != out.size())
    throw size_mismatch();
  
  it1_t it1 = in1.begin();
  it2_t it2 = out.begin();
  for ( ; it1 != in1.end(); it1++, it2++)
    *it2 = *it1 * scale;
}

template<typename in1_cont_t, typename scale_t>
inline void times_vector_scalar_inplace_wrapper (in1_cont_t in1, scale_t
scale) {
  typedef typename boost::remove_reference<in1_cont_t>::type::iterator
it1_t;

  it1_t it1 = in1.begin();
  for ( ; it1 != in1.end(); it1++)
    *it1 *= scale;
}

template<typename T>
struct vector_slice {
  typedef typename std::vector<T>::iterator iterator;
  typedef typename std::vector<T>::const_iterator const_iterator;

  std::vector<T>& v;
  boost::python::slice s;
  vector_slice (std::vector<T>& _v, boost::python::slice _s) :
    v (_v),
    s (_s)
  {}

  iterator begin() { return v.begin() + extract<long>(s.start()); }
  iterator end() { return v.begin() + extract<long>(s.stop()); }
  const_iterator begin() const { return v.begin() +
extract<long>(s.start()); }
  const_iterator end() const { return v.begin() + extract<long>(s.stop()); }

  size_t size() const { return (s.step() == object()) ?
      extract<long>(s.stop()) - extract<long>(s.start()) :
      (extract<long>(s.stop()) -
extract<long>(s.start()))/extract<long>(s.step());
  }
};


BOOST_PYTHON_MODULE(vector)
{    

  class_<std::vector<double> >("DVec")
    .def(init<size_t>())
    .def(init<const std::vector<double>&>())
    .def("size", &std::vector<double>::size)
    .def("resize", (void (std::vector<double>::*)(size_t, const
double&) )&std::vector<double>::resize)
    .def("resize", (void (std::vector<double>::*
(size_t) )&std::vector<double>::resize)
    .def(vector_indexing_suite<std::vector<double> >())
    ;

  class_<std::vector<Complex> >("CVec")
    .def(init<size_t>())
    .def(init<const std::vector<Complex>&>())
    .def("size", &std::vector<Complex>::size)
    .def("resize", (void (std::vector<Complex>::*)(size_t, const
Complex&) )&std::vector<Complex>::resize)
    .def("resize", (void (std::vector<Complex>::*
(size_t) )&std::vector<Complex>::resize)
    .def(vector_indexing_suite<std::vector<Complex>, true >())
    ;
    
  class_<ComplexI >("CInt")
    .def(init<int,int>())
    .def ("real", &ComplexI::real)
    .def ("imag", &ComplexI::imag)
    ;

  class_<std::vector<ComplexI > >("CIntVec")
    .def(init<size_t>())
    .def(init<const std::vector<ComplexI>&>())
    .def("size", &std::vector<ComplexI>::size)
    .def("resize", (void (std::vector<ComplexI>::*)(size_t, const
ComplexI&) )&std::vector<ComplexI>::resize)
    .def("resize", (void (std::vector<ComplexI>::*
(size_t) )&std::vector<ComplexI>::resize)
    .def(vector_indexing_suite<std::vector<ComplexI >, true >())
      ;

  class_<std::vector<int> >("IVec")
    .def(init<size_t>())
    .def(init<const std::vector<int>&>())
    .def("size", &std::vector<int>::size)
    .def("resize", (void (std::vector<int>::*)(size_t, const
int&) )&std::vector<int>::resize)
    .def("resize", (void (std::vector<int>::*
(size_t) )&std::vector<int>::resize)
    .def(vector_indexing_suite<std::vector<int> >()) 
    ;

  class_<vector_slice<int> > ("IVec_slice", init<std::vector<int>&,
boost::python::slice>())
    ;
  def ("AddCVec", &add_vector_wrapper<std::vector<Complex>const&,
std::vector<Complex>const&, std::vector<Complex>&>);
  def ("CVecTimesdouble",
&times_vector_scalar_wrapper<std::vector<Complex>const&, double,
std::vector<Complex>&>);
  def ("CVecTimesComplex",
&times_vector_scalar_wrapper<std::vector<Complex>const&, Complex,
std::vector<Complex>&>);

  def ("IVecSliceTimesInt",
&times_vector_scalar_wrapper<vector_slice<int>const&, int,
std::vector<int>&>);
  def ("IVecSliceTimesIntInplace",
&times_vector_scalar_inplace_wrapper<vector_slice<int>&, int>);
}



From dave at boost-consulting.com  Fri Jul 30 14:47:40 2004
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 30 Jul 2004 05:47:40 -0700
Subject: [C++-sig] Re: wrapping boost::optional
References: <ce6dgn$g06$1@sea.gmane.org> <ufz7cp23a.fsf@boost-consulting.com>
	<ce8qmt$j83$1@sea.gmane.org>
Message-ID: <ur7qtpspf.fsf@boost-consulting.com>

"Mike Rovner" <mike at nospam.com> writes:

> David Abrahams wrote:
>> "Neal D. Becker" <ndbecker2 at verizon.net> writes:
>
>> template<typename T>
>> inline object get (boost::optional<T>& o) {
>>   return o ? object() : object(o.get());
>
> return o ? object(o.get()) : object();      // !?

Uh, right.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



From eli at water.ca.gov  Wed Jul 28 22:02:35 2004
From: eli at water.ca.gov (Ateljevich, Eli)
Date: Wed, 28 Jul 2004 13:02:35 -0700
Subject: [C++-sig] Boost wrapper converting Boost::multi_array to PyArray
Message-ID: <3EE436BDAFE0044A8D6997B74EC3FAB10182A5@sacex2.ad.water.ca.gov>

Hi. 

I am attempting to create a wrapper for a C++ method that returns a
Boost::multi_array. I was hoping to convert this result to a PyArray
without copying the underlying data.

 

I have isolated my problem below, using a class with one method which
creates a trivial multi_array, the converter code and the wrapper. I
have included a very simple test.py file and its output.

 

As the results show:

1. The results are correct for most elements of the array, but the first
element of the array is getting overwritten.

2. Both the multi_array and the PyArray seem to have the correct value
for the first element right before returning from the
to_python_converter. So it seems like it must be happening either during
or after the return.

 

Can anyone shed any light on why this is happening? 

 

I am using a recent Enthought build of Python23 with mingw 3.2.3
compiler on a Windows XP machine.

 

Thanks so much, 

Eli

 

///////////////////////File test.py

 

import timeseries

creator=timeseries.multi_array_creator()

array=creator.getArray()

print "\nIn Python array looks like: %s" % array

 

///////////////////////  Output

 

>>> execfile("test.py")

in C++:

a[0][0] = 0 a[0][1] = 1 a[0][2] = 2 a[1][0] = 10 a[1][1] = 11 a[1][2] =
12  ...

On entry to convert(), a[0][0] = 0

After PyArray creation a[0][0] = 0

Before return, PyArrayObject first slot = 0

 

In Python array looks like: array([[9623160, 1, 2], [10, 11, 12], [20,
21, 22]], 'i')

 

////////////////////////   File multi_array_creator.hpp

#include <iostream>

#include "boost/multi_array.hpp"

 

using namespace std;

 

class multi_array_creator{

    public:

    typedef boost::multi_array<int, 2> ArrayType;

    multi_array_creator(){ import_array() }

    ArrayType getArray(){ 

            ArrayType* a=new ArrayType(boost::extents[3][3]);

            for (int i=0;i<3;i++){

                for (int j=0;j<3;j++)

                        (*a)[i][j] = 10*i+j;

            }

            cout << "in C++:" << endl;

            for (int i=0;i<2;i++)

                for (int j=0;j<3;j++)

                        cout << "a[" << i << "][" << j << "] = " <<
(*a)[i][j] << " ";

            cout << " ... " << endl;

            return *a; 

    }

};

 

/////////////////////////  File multi_array_export.cpp

 

#include <boost/python.hpp>

#include <Numeric/arrayobject.h>

#include <Python.h>

#include <iostream>

#include "multi_array_creator.hpp"

 

using namespace std;

using namespace boost;

using namespace boost::python;

 

struct MArrayToPYArray

{

    static PyObject* convert(multi_array<int, 2> const& a)

    {

            cout << "On entry to convert(), a[0][0] = " << a[0][0] <<
endl;

        PyObject* po =  PyArray_FromDimsAndData(2, (int*) a.shape(),
PyArray_INT, (char*) (a.origin()));

            cout << "After PyArray creation a[0][0] = " << a[0][0] <<
endl;

        PyArrayObject* pao=(PyArrayObject*)po;

            cout <<"Before return, PyArrayObject first slot = " <<
*(int*)(pao->data)<< endl; 

            return po;

    }

};

 

void export_MultiArrayCreator(){

    import_array();

    class_<multi_array_creator>("multi_array_creator")

        .def("getArray", &multi_array_creator::getArray);

    to_python_converter<multi_array<int, 2>, MArrayToPYArray>();

 

}

 

void export_MultiArrayCreator();

 

BOOST_PYTHON_MODULE(timeseries){

    export_MultiArrayCreator();

}

 

 

 

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

From eli at water.ca.gov  Wed Jul 28 19:43:07 2004
From: eli at water.ca.gov (Ateljevich, Eli)
Date: Wed, 28 Jul 2004 10:43:07 -0700
Subject: [C++-sig] Boost wrapper converting Boost::multi_array to PyArray
Message-ID: <3EE436BDAFE0044A8D6997B74EC3FAB10EF84C@sacex2.ad.water.ca.gov>

Hi. 

I am attempting to create a wrapper for a C++ method that returns a
Boost::multi_array. I was hoping to convert this result to a PyArray
without copying the underlying data.

 

I have isolated my problem below, using a class with one method which
creates a trivial multi_array, the converter code and the wrapper. I
have included a very simple test.py file and its output.

 

As the results show:

1. The results are correct for most elements of the array, but the first
element of the array is getting overwritten.

2. Both the multi_array and the PyArray seem to have the correct value
for the first element right before returning from the
to_python_converter. So it seems like it must be happening either during
or after the return.

 

Can anyone shed any light on why this is happening? 

 

I am using a recent Enthought build of Python23 with mingw 3.2.3
compiler on a Windows XP machine.

 

Thanks so much, 

Eli

 

///////////////////////File test.py

 

import timeseries

creator=timeseries.multi_array_creator()

array=creator.getArray()

print "\nIn Python array looks like: %s" % array

 

///////////////////////  Output

 

>>> execfile("test.py")

in C++:

a[0][0] = 0 a[0][1] = 1 a[0][2] = 2 a[1][0] = 10 a[1][1] = 11 a[1][2] =
12  ...

On entry to convert(), a[0][0] = 0

After PyArray creation a[0][0] = 0

Before return, PyArrayObject first slot = 0

 

In Python array looks like: array([[9623160, 1, 2], [10, 11, 12], [20,
21, 22]], 'i')

 

////////////////////////   File multi_array_creator.hpp

#include <iostream>

#include "boost/multi_array.hpp"

 

using namespace std;

 

class multi_array_creator{

    public:

    typedef boost::multi_array<int, 2> ArrayType;

    multi_array_creator(){ import_array() }

    ArrayType getArray(){ 

            ArrayType* a=new ArrayType(boost::extents[3][3]);

            for (int i=0;i<3;i++){

                for (int j=0;j<3;j++)

                        (*a)[i][j] = 10*i+j;

            }

            cout << "in C++:" << endl;

            for (int i=0;i<2;i++)

                for (int j=0;j<3;j++)

                        cout << "a[" << i << "][" << j << "] = " <<
(*a)[i][j] << " ";

            cout << " ... " << endl;

            return *a; 

    }

};

 

/////////////////////////  File multi_array_export.cpp

 

#include <boost/python.hpp>

#include <Numeric/arrayobject.h>

#include <Python.h>

#include <iostream>

#include "multi_array_creator.hpp"

 

using namespace std;

using namespace boost;

using namespace boost::python;

 

struct MArrayToPYArray

{

    static PyObject* convert(multi_array<int, 2> const& a)

    {

            cout << "On entry to convert(), a[0][0] = " << a[0][0] <<
endl;

        PyObject* po =  PyArray_FromDimsAndData(2, (int*) a.shape(),
PyArray_INT, (char*) (a.origin()));

            cout << "After PyArray creation a[0][0] = " << a[0][0] <<
endl;

        PyArrayObject* pao=(PyArrayObject*)po;

            cout <<"Before return, PyArrayObject first slot = " <<
*(int*)(pao->data)<< endl; 

            return po;

    }

};

 

void export_MultiArrayCreator(){

    import_array();

    class_<multi_array_creator>("multi_array_creator")

        .def("getArray", &multi_array_creator::getArray);

    to_python_converter<multi_array<int, 2>, MArrayToPYArray>();

 

}

 

void export_MultiArrayCreator();

 

BOOST_PYTHON_MODULE(timeseries){

    export_MultiArrayCreator();

}

 

 

 

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

From belvis at imageworks.com  Sat Jul 31 01:45:06 2004
From: belvis at imageworks.com (Robert Bell)
Date: Fri, 30 Jul 2004 16:45:06 -0700
Subject: [C++-sig] Boost.python + PyQt?
Message-ID: <410ADD82.5010504@imageworks.com>

Hi All-

I have some Qt widgets that I need exported to Python for use with PyQt. 
I've been looking into sip, but I'm also curious if boost.python is up 
to the task. Has anyone tried this?

Bob


From jesuso20 at hotmail.com  Sat Jul 31 13:31:33 2004
From: jesuso20 at hotmail.com (=?iso-8859-1?B?SmVz+nMgR3VtYmF1IFBvcnRhbOhz?=)
Date: Sat, 31 Jul 2004 11:31:33 +0000
Subject: [C++-sig] Passing pointer to classes from C++ to Python
Message-ID: <BAY15-F4Y0xyqVQBLPx00091939@hotmail.com>

I am using the PyObject_CallObject function to call a method on a python 
script and passing a pointer to a class object as a parameter. I pass the 
address of that object as:

PyInt_FromLong((long)&object);

as a parameter.

The problem is interpreting that address as a reference to a object from 
Python. (I am using SWIG so that python can know the class structure of the 
object).

_________________________________________________________________
Descarga gratis la Barra de Herramientas de MSN 
http://www.msn.es/usuario/busqueda/barra?XAPID=2031&DI=1055&SU=http%3A//www.hotmail.com&HL=LINKTAG1OPENINGTEXT_MSNBH