From petr_aleksandrov at mail.ru  Sun Jun  2 00:50:40 2013
From: petr_aleksandrov at mail.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGA0L7QsiDQn9C10YLRgA==?=)
Date: Sun, 02 Jun 2013 02:50:40 +0400
Subject: [C++-sig] Handling a custom C++ exception from Python
Message-ID: <51AA7AC0.5010200@mail.ru>

I want to catch a custom C++ exception in Python. I have described my 
custom exception class as usual:

class_<CMyException>(...);

and created a translator:

void translate(CMyException const &e) {
     object o(e);
     PyErr_SetObject(PyExc_Exception, o.ptr());
}

This exception can be caught from Python:
try:
   do_something()
except Exception as exc:
   #exc.args[0] - the custom exception object
   print exc.args[0]

Is it safe to do in such a way? Is the Python object, created in the 
function "translate", destroyed? Need I add "Py_INCREF" to this function?

From beamesleach at gmail.com  Sun Jun  2 11:14:39 2013
From: beamesleach at gmail.com (Alex Leach)
Date: Sun, 02 Jun 2013 10:14:39 +0100
Subject: [C++-sig] Handling a custom C++ exception from Python
In-Reply-To: <51AA7AC0.5010200@mail.ru>
References: <51AA7AC0.5010200@mail.ru>
Message-ID: <op.wx1nypdb8s54ea@ns1.alexleach.org.uk>

On Sat, 01 Jun 2013 23:50:40 +0100, ??????????? ????  
<petr_aleksandrov at mail.ru> wrote:

> I want to catch a custom C++ exception in Python. I have described my  
> custom exception class as usual:
>
> class_<CMyException>(...);
>
> and created a translator:
>
> void translate(CMyException const &e) {
>      object o(e);
>      PyErr_SetObject(PyExc_Exception, o.ptr());
> }
>
> This exception can be caught from Python:
> try:
>    do_something()
> except Exception as exc:
>    #exc.args[0] - the custom exception object
>    print exc.args[0]
>
> Is it safe to do in such a way? Is the Python object, created in the  
> function "translate", destroyed? Need I add "Py_INCREF" to this function?


Looks fine to me.
You'd probably get a segfault if it was missing an incref. The `object  
o(e)` line should increment the reference count for you, as you didn't  
wrap `e` in `boost::ref` or similar in the conversion to object.

A couple of pointers, though:-

   1. Boost Python has a dedicated exception handling API[1] that doesn't  
require you to wrap the exception in a class_<> template. The class_  
template is a bit heavy duty for registering exceptions, I think. Instead,  
I register exceptions like this:-

#include <boost/python/exception_translator.hpp>

void TranslateMyException(const MyException& err)
{
     PyErr_SetString(PyExc_Exception, err.ptr());
}

void RegisterMyExceptionTranslator(void)
{
     boost::python::register_exception_translator<
         MyException&>( TranslateMyException );
}


   2. If you're concerned about reference counting, it'd probably be worth  
you building a debug version of Python.[2] In the interpreter, this prints  
the global reference count at the end of each code block. The two ways it  
could go wrong:- too few calls to incref and you'll get a free error, so  
your program will segfault. Too many incref's and garbage collection of  
your objects won't happen until the program exits. A debug build of Python  
really helps here, as you'll see that the global reference count go down  
when you delete an instance of your object. With exceptions, I've found  
that Py_DECREF is called a little late though, which is a bit confusing at  
first. So when looking at the reference counting behaviour in relation to  
C++ exceptions, be sure to compare the behaviour against that of normal  
Python exceptions.


HTH,
Alex


[1]:  
http://www.boost.org/doc/libs/1_53_0/libs/python/doc/v2/exception_translator.html
[2]: http://docs.python.org/devguide/setup.html#compiling-for-debugging

From beamesleach at gmail.com  Sun Jun  2 22:37:10 2013
From: beamesleach at gmail.com (Alex Leach)
Date: Sun, 02 Jun 2013 21:37:10 +0100
Subject: [C++-sig] Handling a custom C++ exception from Python
In-Reply-To: <51ABA563.40006@mail.ru>
References: <51AA7AC0.5010200@mail.ru>
	<op.wx1nypdb8s54ea@ns1.alexleach.org.uk> <51ABA563.40006@mail.ru>
Message-ID: <op.wx2jj8sx8s54ea@ns1.alexleach.org.uk>

On Sun, 02 Jun 2013 21:04:51 +0100, ??????????? ????  
<petr_aleksandrov at mail.ru> wrote:

> 02.06.2013 13:14, Alex Leach ?????:
>>   1. Boost Python has a dedicated exception handling API[1] that  
>> doesn't require you to wrap the exception in a class_<> template. The  
>> class_ template is a bit heavy duty for registering exceptions, I  
>> think. Instead, I register exceptions like this:-
>>
>> #include <boost/python/exception_translator.hpp>
>>
>> void TranslateMyException(const MyException& err)
>> {
>>     PyErr_SetString(PyExc_Exception, err.ptr());
>> }
>>
>> void RegisterMyExceptionTranslator(void)
>> {
>>     boost::python::register_exception_translator<
>>         MyException&>( TranslateMyException );
>> }
> I want to pass some info (it is numbers) from C++ to Python with the  
> exception. This info is stored in C++ exception object fields. Using  
> class_ I allow accessing these fields from Python.

Well, that is one way to do it. Above, in TranslateMyException, you can do  
whatever you like with the C++ exception, though. I've been doing it that  
way,usually just creating a human-readable message from the C++ exception,  
then using the above mechanisms to set the exception for Python. To give  
your exception extra Python attributes, you might consider using the raw  
Python C API function, PyErr_NewException[1]. Your call, though.

Cheers,
Alex

[1]: http://docs.python.org/2/c-api/exceptions.html#PyErr_NewException

From sebastian.herbord at googlemail.com  Mon Jun  3 19:48:58 2013
From: sebastian.herbord at googlemail.com (Sebastian Herbord)
Date: Mon, 3 Jun 2013 19:48:58 +0200
Subject: [C++-sig] Heap error with pyqt code embedded using boost python
Message-ID: <CAD2nPaWAhFcNzzizjNWWb9eXJd4NRVftg1kQjzxmZYrJLD4-cg@mail.gmail.com>

Hi,

hope this is an adequate mailing list for this quesion, appologies in
advance if not.

I'm trying to embed python into a C++/Qt application using boost
python. This works pretty well except the whole program crashes when a
pyqt slot is invoked that takes a QString as its parameter.
This is a minimal example:

#include <QCoreApplication>
#include <boost/python.hpp>

using namespace boost::python;

bool handled_exec_file(str filename, object globals) {
  return handle_exception(boost::bind(exec_file, filename, globals, object()));
}

int main() {
  QCoreApplication a(argc, argv);
  Py_Initialize();

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

  if (handled_exec_file("test.py", main_namespace)) {
    if (PyErr_Occurred()) {
      PyErr_Print();
    } else {
      qCritical("unknown error in python code");
    }
  }
  return a.exec();
}

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

from PyQt4 import QtGui

def editBoxChanged(text):
    pass

app = QtGui.QApplication([])
widget = QtGui.QWidget()

editBox = QtGui.QLineEdit(widget)
editBox.textEdited.connect(editBoxChanged)  # mark

widget.show()
app.exec_()


This crashes the second I enter something in the line-edit (exception
code c0000005). If I run this in a debugger I get
"Invalid address specified to RtlFreeHeap( 00BD0000, 00CF8798 )
(1684.1f88): WOW64 breakpoint - code 4000001f (first chance)"
instead every time I input a character.

The crash doesn't happen if the marked python line is removed.

Does anyone have an idea what might be causing this or how to further
debug the issue?

I'd appreciate any help.
Sebastian

From j.reid at mail.cryst.bbk.ac.uk  Tue Jun  4 19:12:13 2013
From: j.reid at mail.cryst.bbk.ac.uk (John Reid)
Date: Tue, 04 Jun 2013 18:12:13 +0100
Subject: [C++-sig] Inner class name
Message-ID: <kol757$ba8$1@ger.gmane.org>

Inner classes seem to be given the wrong name or perhaps this is by
design. Could someone enlighten me? If I do:

namespace py = boost::python;
py::class_< T > outer( "Outer" );
py::scope( outer );
py::class_< U > inner( "Inner" );

then in python:

import module as M
print M.Outer.Inner

gives "M.Inner" which doesn't exist. I'm not sure it is important, it
just seems curious.

John.


From talljimbo at gmail.com  Tue Jun  4 19:45:34 2013
From: talljimbo at gmail.com (Jim Bosch)
Date: Tue, 04 Jun 2013 13:45:34 -0400
Subject: [C++-sig] Inner class name
In-Reply-To: <kol757$ba8$1@ger.gmane.org>
References: <kol757$ba8$1@ger.gmane.org>
Message-ID: <51AE27BE.6000207@gmail.com>

On 06/04/2013 01:12 PM, John Reid wrote:
> Inner classes seem to be given the wrong name or perhaps this is by
> design. Could someone enlighten me? If I do:
>
> namespace py = boost::python;
> py::class_< T > outer( "Outer" );
> py::scope( outer );
> py::class_< U > inner( "Inner" );
>
> then in python:
>
> import module as M
> print M.Outer.Inner
>
> gives "M.Inner" which doesn't exist. I'm not sure it is important, it
> just seems curious.
>

I agree that it's curious, but Python has never really handled inner 
classes terribly well; Boost.Python's behavior in this respect is the 
same as pure Python:

class Outer(object):
     class Inner(object):
         pass

print Outer.Inner

gives "__main__.Inner"



Jim



From adam.preble at gmail.com  Thu Jun  6 07:11:41 2013
From: adam.preble at gmail.com (Adam Preble)
Date: Thu, 6 Jun 2013 00:11:41 -0500
Subject: [C++-sig] Handling multiple GIL accesses
Message-ID: <CAE-m0_=E-JHQB2behWP0LVCg-pDsV0FabtX_aC=wP5K0J3=gVQ@mail.gmail.com>

Here's the double lock I'm afraid of:

1. Embedding program invokes some Python code with its embedded interpreter
2. The embedded interpreter, through running that code, ends up executing
some code actually in the embedded program's environment.
3. This code back in the embedded program has another thread (here we go)
that calls to some interfaces, of which one is written in Python.
4. The wrapper needs to acquire the GIL since it's going back into Python,
and it's going into it from another thread entirely.

At #4 right there I thought it was tricky when trying to do this.  I guess
the important thing to do is to make sure to store a unique state from each
call to PyGILState_Ensure and to keep those in order when using
PyGILState_Release.  I think when I originally did this, I had a global
pointer, which was bad news.

I wanted to make sure I understand how to handle a particularly disruptive
situation when embedding Python in another language.  I've been following
this with embedding Python in C++, and I also looked at this with embedding
CPython in C# using Python.NET.  The Python.NET library looks like it's
surviving without double locking.  Looking at its implementation, I wanted
to review for posterity's sake how this is supposed to work.  I know when I
was first trying to do this in C++, I didn't really pull it off, and I
wanted the next poor fool that's Googling for this to have a good shot at
it.

So do I have it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20130606/4a924680/attachment.html>

From s_sourceforge at nedprod.com  Mon Jun 10 01:14:05 2013
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sun, 09 Jun 2013 19:14:05 -0400
Subject: [C++-sig] Handling multiple GIL accesses
In-Reply-To: <CAE-m0_=E-JHQB2behWP0LVCg-pDsV0FabtX_aC=wP5K0J3=gVQ@mail.gmail.com>
References: <CAE-m0_=E-JHQB2behWP0LVCg-pDsV0FabtX_aC=wP5K0J3=gVQ@mail.gmail.com>
Message-ID: <51B50C3D.4463.2FF75892@s_sourceforge.nedprod.com>

In terms of specific steps to avoid problems, it's been too long ago 
since I wrote those GIL management patches for TnFOX for me to be 
able to comment usefully. Getting the sequences correct took a lot of 
trial and error at the time. All I can say is if you're seeing weird 
hangs under load, the TnFOX patches may be useful, or they may be so 
bitrotted by now that they're not. A race detector might be useful, 
clang's threadsanitizer is one of the better implementations.

Still, good luck with your work.

Niall


On 6 Jun 2013 at 0:11, Adam Preble wrote:

> Here's the double lock I'm afraid of:
> 
> 1. Embedding program invokes some Python code with its embedded interpreter
> 2. The embedded interpreter, through running that code, ends up executing
> some code actually in the embedded program's environment.
> 3. This code back in the embedded program has another thread (here we go)
> that calls to some interfaces, of which one is written in Python.
> 4. The wrapper needs to acquire the GIL since it's going back into Python,
> and it's going into it from another thread entirely.
> 
> At #4 right there I thought it was tricky when trying to do this.  I guess
> the important thing to do is to make sure to store a unique state from each
> call to PyGILState_Ensure and to keep those in order when using
> PyGILState_Release.  I think when I originally did this, I had a global
> pointer, which was bad news.
> 
> I wanted to make sure I understand how to handle a particularly disruptive
> situation when embedding Python in another language.  I've been following
> this with embedding Python in C++, and I also looked at this with embedding
> CPython in C# using Python.NET.  The Python.NET library looks like it's
> surviving without double locking.  Looking at its implementation, I wanted
> to review for posterity's sake how this is supposed to work.  I know when I
> was first trying to do this in C++, I didn't really pull it off, and I
> wanted the next poor fool that's Googling for this to have a good shot at
> it.
> 
> So do I have it?
> 


-- 
Any opinions or advice expressed here do NOT reflect those
of my employer BlackBerry Inc.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/



-------------- next part --------------
A non-text attachment was scrubbed...
Name: SMime.p7s
Type: application/x-pkcs7-signature
Size: 6061 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20130609/e81c7285/attachment.bin>

From Trevor.Haba at logmein.com  Wed Jun 12 11:05:21 2013
From: Trevor.Haba at logmein.com (Trevor Haba)
Date: Wed, 12 Jun 2013 09:05:21 +0000
Subject: [C++-sig] Alternate locations for BOOST_PYTHON_MODULE
Message-ID: <94CA6FFD705CB34D82F3890C00638173B5B3FB@BPGTS-MBX01.3amlabs.net>

Hello,

I am attempting to make a large pre-existing code base accessible to python, so that I can run quick scripts to automate the behavior of certain classes for testing purposes. We are using C++ and python 3.3 with the boost.python library. I have a script to automatically generate the BOOST_PYTHON_MODULE( ... ) wrapper definitions for the C++ source code. But, because this is a pre-existing code base with other people already working on it, I would prefer to not have to modify the source code files of all of the classes by inserting the python wrappers at the bottom. All the examples I've seen show the BOOST_PYTHON_MODULE at the bottom of the C++ source file. Is it possible to put the BOOST_PYTHON_MODULE in a separate file, and #include the class it is wrapping? If so, how would I do this? And how would I configure the Jamroot file to compile these properly?

Also, I'm targeting windows systems and using Visual Studio 2010, if that matters

Thanks very much,
Trevor

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20130612/5716fec3/attachment.html>

From brandsmeier at gmx.de  Wed Jun 12 11:27:09 2013
From: brandsmeier at gmx.de (Holger Brandsmeier)
Date: Wed, 12 Jun 2013 11:27:09 +0200
Subject: [C++-sig] Alternate locations for BOOST_PYTHON_MODULE
In-Reply-To: <94CA6FFD705CB34D82F3890C00638173B5B3FB@BPGTS-MBX01.3amlabs.net>
References: <94CA6FFD705CB34D82F3890C00638173B5B3FB@BPGTS-MBX01.3amlabs.net>
Message-ID: <CAFP7zVuwCkxZF484MrFY_59gKQdLfqxgYBzMvvwH9qeRa7mkXw@mail.gmail.com>

Trevor,

that is certainly possible, all my python exports look like this:

#include "pfemPy.inl"

BOOST_PYTHON_MODULE(pfemPy)
{
  PfemInst::call();
} // boost module

Then e.g. in "pfemPy.inl" I wrap and export the C++ classes. The file
"pfemPy.inl" in turn includes the header of the required source which
are "untoched".

I can not help you about the Jamroot, as I am not using bjam.

-Holger

On Wed, Jun 12, 2013 at 11:05 AM, Trevor Haba <Trevor.Haba at logmein.com> wrote:
> Hello,
>
>
>
> I am attempting to make a large pre-existing code base accessible to python,
> so that I can run quick scripts to automate the behavior of certain classes
> for testing purposes. We are using C++ and python 3.3 with the boost.python
> library. I have a script to automatically generate the BOOST_PYTHON_MODULE(
> ? ) wrapper definitions for the C++ source code. But, because this is a
> pre-existing code base with other people already working on it, I would
> prefer to not have to modify the source code files of all of the classes by
> inserting the python wrappers at the bottom. All the examples I?ve seen show
> the BOOST_PYTHON_MODULE at the bottom of the C++ source file. Is it possible
> to put the BOOST_PYTHON_MODULE in a separate file, and #include the class it
> is wrapping? If so, how would I do this? And how would I configure the
> Jamroot file to compile these properly?
>
>
>
> Also, I?m targeting windows systems and using Visual Studio 2010, if that
> matters
>
>
>
> Thanks very much,
>
> Trevor
>
>
>
>
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig

From Trevor.Haba at logmein.com  Wed Jun 12 12:10:38 2013
From: Trevor.Haba at logmein.com (Trevor Haba)
Date: Wed, 12 Jun 2013 10:10:38 +0000
Subject: [C++-sig] Alternate locations for BOOST_PYTHON_MODULE
In-Reply-To: <CAFP7zVuwCkxZF484MrFY_59gKQdLfqxgYBzMvvwH9qeRa7mkXw@mail.gmail.com>
References: <94CA6FFD705CB34D82F3890C00638173B5B3FB@BPGTS-MBX01.3amlabs.net>
	<CAFP7zVuwCkxZF484MrFY_59gKQdLfqxgYBzMvvwH9qeRa7mkXw@mail.gmail.com>
Message-ID: <94CA6FFD705CB34D82F3890C00638173B5B431@BPGTS-MBX01.3amlabs.net>

Holger,

Thanks for the reply. I'm a little bit confused about the .inl file. Sorry if these are obvious questions, I'm still somewhat new at this.

So this "pfemPy.inl" is what actually contains the python bindings? So the commands like class_<foo>("foo").def(...) are in the .inl file? Are these wrapped in their own BOOST_PYTHON_MODULE(...) {} block, or are they in some other format? Then PfemInst::call(), what does that do? I'm a little bit confused, if you are still writing the wrapper calls, why not just put them in the BOOST_PYTHON_MODULE you have here? Why keep them in a seperate file, #include them and then use the ::call() function?

Also, I am not tied to usnig bjam, that is just what the boost.python tutorial recommended. How are you compiling your python extension modules? Can you point me to some information about it?

Thanks for your help,
Trevor

-----Original Message-----
From: Cplusplus-sig [mailto:cplusplus-sig-bounces+trevor.haba=logmein.com at python.org] On Behalf Of Holger Brandsmeier
Sent: Wednesday, June 12, 2013 11:27 AM
To: Development of Python/C++ integration
Subject: Re: [C++-sig] Alternate locations for BOOST_PYTHON_MODULE

Trevor,

that is certainly possible, all my python exports look like this:

#include "pfemPy.inl"

BOOST_PYTHON_MODULE(pfemPy)
{
  PfemInst::call();
} // boost module

Then e.g. in "pfemPy.inl" I wrap and export the C++ classes. The file "pfemPy.inl" in turn includes the header of the required source which are "untoched".

I can not help you about the Jamroot, as I am not using bjam.

-Holger

On Wed, Jun 12, 2013 at 11:05 AM, Trevor Haba <Trevor.Haba at logmein.com> wrote:
> Hello,
>
>
>
> I am attempting to make a large pre-existing code base accessible to 
> python, so that I can run quick scripts to automate the behavior of 
> certain classes for testing purposes. We are using C++ and python 3.3 
> with the boost.python library. I have a script to automatically 
> generate the BOOST_PYTHON_MODULE( ? ) wrapper definitions for the C++ 
> source code. But, because this is a pre-existing code base with other 
> people already working on it, I would prefer to not have to modify the 
> source code files of all of the classes by inserting the python 
> wrappers at the bottom. All the examples I?ve seen show the 
> BOOST_PYTHON_MODULE at the bottom of the C++ source file. Is it 
> possible to put the BOOST_PYTHON_MODULE in a separate file, and 
> #include the class it is wrapping? If so, how would I do this? And how would I configure the Jamroot file to compile these properly?
>
>
>
> Also, I?m targeting windows systems and using Visual Studio 2010, if 
> that matters
>
>
>
> Thanks very much,
>
> Trevor
>
>
>
>
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig at python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

From brandsmeier at gmx.de  Wed Jun 12 12:34:24 2013
From: brandsmeier at gmx.de (Holger Brandsmeier)
Date: Wed, 12 Jun 2013 12:34:24 +0200
Subject: [C++-sig] Alternate locations for BOOST_PYTHON_MODULE
In-Reply-To: <94CA6FFD705CB34D82F3890C00638173B5B431@BPGTS-MBX01.3amlabs.net>
References: <94CA6FFD705CB34D82F3890C00638173B5B3FB@BPGTS-MBX01.3amlabs.net>
	<CAFP7zVuwCkxZF484MrFY_59gKQdLfqxgYBzMvvwH9qeRa7mkXw@mail.gmail.com>
	<94CA6FFD705CB34D82F3890C00638173B5B431@BPGTS-MBX01.3amlabs.net>
Message-ID: <CAFP7zVu1wZEXveHXcrxkx4+WRbUuguH9vFXeU8t79HrPp28eVg@mail.gmail.com>

Trevor,

ok, so I misunderstood your question. If what you want to do is this:

---- myclass.h
class MyClass {
[...]
};

---- pythonFile.cpp
#include "myclass.h"
[...]

BOOST_PYTHON_MODULE(...) {
[...]
}

That is certainly possible, I think almost everyone (including me)
does it like this.

> Also, I am not tied to usnig bjam, that is just what the boost.python tutorial recommended. How are you compiling your python extension modules? Can you point me to some information about it?

I recommend you to use bjam, I simply can not help you about it.

-Holger


On Wed, Jun 12, 2013 at 12:10 PM, Trevor Haba <Trevor.Haba at logmein.com> wrote:
> Holger,
>
> Thanks for the reply. I'm a little bit confused about the .inl file. Sorry if these are obvious questions, I'm still somewhat new at this.
>
> So this "pfemPy.inl" is what actually contains the python bindings? So the commands like class_<foo>("foo").def(...) are in the .inl file? Are these wrapped in their own BOOST_PYTHON_MODULE(...) {} block, or are they in some other format? Then PfemInst::call(), what does that do? I'm a little bit confused, if you are still writing the wrapper calls, why not just put them in the BOOST_PYTHON_MODULE you have here? Why keep them in a seperate file, #include them and then use the ::call() function?
>
> Also, I am not tied to usnig bjam, that is just what the boost.python tutorial recommended. How are you compiling your python extension modules? Can you point me to some information about it?
>
> Thanks for your help,
> Trevor
>
> -----Original Message-----
> From: Cplusplus-sig [mailto:cplusplus-sig-bounces+trevor.haba=logmein.com at python.org] On Behalf Of Holger Brandsmeier
> Sent: Wednesday, June 12, 2013 11:27 AM
> To: Development of Python/C++ integration
> Subject: Re: [C++-sig] Alternate locations for BOOST_PYTHON_MODULE
>
> Trevor,
>
> that is certainly possible, all my python exports look like this:
>
> #include "pfemPy.inl"
>
> BOOST_PYTHON_MODULE(pfemPy)
> {
>   PfemInst::call();
> } // boost module
>
> Then e.g. in "pfemPy.inl" I wrap and export the C++ classes. The file "pfemPy.inl" in turn includes the header of the required source which are "untoched".
>
> I can not help you about the Jamroot, as I am not using bjam.
>
> -Holger
>
> On Wed, Jun 12, 2013 at 11:05 AM, Trevor Haba <Trevor.Haba at logmein.com> wrote:
>> Hello,
>>
>>
>>
>> I am attempting to make a large pre-existing code base accessible to
>> python, so that I can run quick scripts to automate the behavior of
>> certain classes for testing purposes. We are using C++ and python 3.3
>> with the boost.python library. I have a script to automatically
>> generate the BOOST_PYTHON_MODULE( ? ) wrapper definitions for the C++
>> source code. But, because this is a pre-existing code base with other
>> people already working on it, I would prefer to not have to modify the
>> source code files of all of the classes by inserting the python
>> wrappers at the bottom. All the examples I?ve seen show the
>> BOOST_PYTHON_MODULE at the bottom of the C++ source file. Is it
>> possible to put the BOOST_PYTHON_MODULE in a separate file, and
>> #include the class it is wrapping? If so, how would I do this? And how would I configure the Jamroot file to compile these properly?
>>
>>
>>
>> Also, I?m targeting windows systems and using Visual Studio 2010, if
>> that matters
>>
>>
>>
>> Thanks very much,
>>
>> Trevor
>>
>>
>>
>>
>> _______________________________________________
>> Cplusplus-sig mailing list
>> Cplusplus-sig at python.org
>> http://mail.python.org/mailman/listinfo/cplusplus-sig
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig

From beamesleach at gmail.com  Wed Jun 12 12:53:43 2013
From: beamesleach at gmail.com (Alex Leach)
Date: Wed, 12 Jun 2013 11:53:43 +0100
Subject: [C++-sig] Alternate locations for BOOST_PYTHON_MODULE
In-Reply-To: <CAFP7zVu1wZEXveHXcrxkx4+WRbUuguH9vFXeU8t79HrPp28eVg@mail.gmail.com>
References: <94CA6FFD705CB34D82F3890C00638173B5B3FB@BPGTS-MBX01.3amlabs.net>
	<CAFP7zVuwCkxZF484MrFY_59gKQdLfqxgYBzMvvwH9qeRa7mkXw@mail.gmail.com>
	<94CA6FFD705CB34D82F3890C00638173B5B431@BPGTS-MBX01.3amlabs.net>
	<CAFP7zVu1wZEXveHXcrxkx4+WRbUuguH9vFXeU8t79HrPp28eVg@mail.gmail.com>
Message-ID: <op.wyka7trt8s54ea@ns1.alexleach.org.uk>

On Wed, 12 Jun 2013 11:34:24 +0100, Holger Brandsmeier  
<brandsmeier at gmx.de> wrote:

> Trevor,
>
> ok, so I misunderstood your question. If what you want to do is this:
>
> ---- myclass.h
> class MyClass {
> [...]
> };
>
> ---- pythonFile.cpp
> #include "myclass.h"
> [...]
>
> BOOST_PYTHON_MODULE(...) {
> [...]
> }
>
> That is certainly possible, I think almost everyone (including me)
> does it like this.

Yea, this is kind of how I do it, but I don't include the class headers  
into the file containing BOOST_PYTHON_MODULE; I just forward declare a  
load of RegisterFooClass functions, and then call them within the  
BOOST_PYTHON_MODULE. Doing it this way I find, makes the file containing  
the BOOST_PYTHON_MODULE a lot smaller and it compiles a lot faster. All it  
needs to include is <boost/python/module.hpp>.


>
>> Also, I am not tied to usnig bjam, that is just what the boost.python  
>> tutorial recommended. How are you compiling your python extension  
>> modules? Can you point me to some information about it?
>
> I recommend you to use bjam, I simply can not help you about it.
>

Yea, I don't use bjam either... I'm using Python's distutils, which is not  
all that recommendable. I'd probably recommend using Makefile's. I'm sure  
you can find some relevant tutorials online...

Cheers,
Alex

From octalberfest at gmail.com  Thu Jun 13 00:23:53 2013
From: octalberfest at gmail.com (octalber fest)
Date: Wed, 12 Jun 2013 23:23:53 +0100
Subject: [C++-sig] How can I have a global C/C++ variable that is shared
 between Python C/C++ extensions?
Message-ID: <CACaUboWBDuovB6WUdxK==k8OG6LDfZCjgtQx=vh=m2JrF4f7FA@mail.gmail.com>

Dear list,

Apologies if this question is slightly off-topic, but I thought I might get
answers here rather than the other Python mailing lists. I have a rather
specific issue with creating a Python C++ extension that I'm really stuck
on it. These are the details...

--

I have written a Python package almost completely in C++. The reason for
doing so is because I want to manually wrap an existing C++ library, but
that is irrelevant here.

This Python package consists of a number of different extension modules,
all of which I compile with distutils in a 'setup.py' script. These
extension modules can be interrelated, in which case I link them by passing
the shared library to the Extension constructor. To be clear, suppose I
have two Python C++ modules, A and B, where B uses functions defined in A.
These normally compile into A.so and B.so. Since B uses functions defined
in A, I compile the A module as usual then I pass ':A.so' as a library to
the libraries keyword in the Extension constructor for the B module. (The
':' lets g++ deal with the fact that the library does not start with the
usual 'lib' prefix.) This works fine for linking functions and classes.

My problem is as follows: I have defined some extern global C++ variables
in A. While doing what I have described allows B to access functions in A,
it actually seems to create a COPY of any global data defined in A. This is
a real problem for me.

It seems to me that the issue is essentially similar to having global
variables across shared libraries. The solutions to this that I have found
online do not seem to solve the problem.

Any help would be so very appreciated!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20130612/ea18bd7c/attachment.html>

From beamesleach at gmail.com  Thu Jun 13 16:47:57 2013
From: beamesleach at gmail.com (Alex Leach)
Date: Thu, 13 Jun 2013 15:47:57 +0100
Subject: [C++-sig] How can I have a global C/C++ variable that is shared
 between Python C/C++ extensions?
In-Reply-To: <CACaUboWBDuovB6WUdxK==k8OG6LDfZCjgtQx=vh=m2JrF4f7FA@mail.gmail.com>
References: <CACaUboWBDuovB6WUdxK==k8OG6LDfZCjgtQx=vh=m2JrF4f7FA@mail.gmail.com>
Message-ID: <op.wymgp7m78s54ea@ns1.alexleach.org.uk>

I had a similar problem when testing my extensions on OSX. I guess you're  
not on OSX, but if you test out on it, I'm sure you'd find even more  
linking problems.. Problem is that the bundle format - the default Python  
extension format, on OSX - doesn't allow compile-time linking, only  
run-time dynamic loading. Python's distutils is quite tricky when it comes  
to making shared libraries on OSX, or dylibs, but I found them necessary,  
when sharing symbols between extensions.

YMMV, but I what I did was to create an extension (a file with only  
`BOOST_PYTHON_MODULE(foo)`, to be dlopen'd by Python's import machinery)  
and separate, shared libraries, to be linked in at compile time.

The folder structure I end up with, looks a little like this:-

pkg/__init__.py
pkg/A.py
pkg/B.py
pkg/_A.so
pkg/_B.so
pkg/lib/libA.dylib
pkg/lib/libB.dylib

Then, you don't to link across extensions, only to libraries, which should  
work as normal. I did have to add OS-specific runtime_library_flags, which  
distutils was having problems generating itself. I haven't tested on  
Windows, but, these are some of the exact options I use, when making  
distutils Extension instances.

For an Extension (e.g. _A.so):

# OS-dependent flags for dynamic symbol resolution:
libraries = ["A"]
library_dirs = [ <path to build directory>, ... ]

if sys.platform.startswith('linux'):
     runtime_library_dirs += ["${ORIGIN}/lib"]
elif sys.platform == 'darwin':
     extra_link_args = ['-Wl,-rpath, at loader_path/',
         '-install_name', '_A.so',
         '-compatibility_version', __version__,
         '-current_version', __fullversion__ ]
elif sys.platform == 'win32':
     runtime_library_dirs += ['lib-dynload']

And then for a library (e.g. libA.dylib):-

# OS-dependent flags for dynamic symbol resolution:
libraries = ["B"]
library_dirs = [ <path to build directory> , ...]
if platform == "linux2":
     extra_link_args = ["-Wl,-soname,libA.so"]
elif sys.platform == 'darwin':
     extra_link_args = [
         '-install_name', '@rpath/lib/libA.dylib',
         '-Wl,-rpath, at loader_path/..',
         '-compatibility_version', __version__,
         '-current_version', __fullversion__]


HTH,
Alex


On Wed, 12 Jun 2013 23:23:53 +0100, octalber fest <octalberfest at gmail.com>  
wrote:

>
> Dear list,
>
> Apologies if this question is slightly off-topic, but I thought I might  
> get answers here rather than the other >Python mailing lists. I have a  
> rather specific issue with creating a Python C++ extension that I'm  
> really stuck on >it. These are the details...
>
> --
>
> I have written a Python package almost completely in C++. The reason for  
> doing so is because I want to manually >wrap an existing C++ library,  
> but that is irrelevant here.
>
> This Python package consists of a number of different extension modules,  
> all of which I compile with distutils in a >'setup.py' script. These  
> extension modules can be interrelated, in which case I link them by  
> passing the shared >library to the Extension constructor. To be clear,  
> suppose I have two Python C++ modules, A and B, where B uses >functions  
> defined in A. These normally compile into A.so and B.so. Since B uses  
> functions defined in A, I compile >the A module as usual then I pass  
> ':A.so' as a library to the libraries keyword in the Extension  
> constructor for >the B module. (The ':' lets g++ deal with the fact that  
> the library does not start with the usual 'lib' prefix.) >This works  
> fine for linking functions and classes.
>
> My problem is as follows: I have defined some extern global C++  
> variables in A. While doing what I have described >allows B to access  
> functions in A, it actually seems to create a COPY of any global data  
> defined in A. This is a >real problem for me.
>
> It seems to me that the issue is essentially similar to having global  
> variables across shared libraries. The >solutions to this that I have  
> found online do not seem to solve the problem.
>
> Any help would be so very appreciated!



-- 
Using Opera's mail client: http://www.opera.com/mail/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20130613/bbde476a/attachment.html>

From ndbecker2 at gmail.com  Fri Jun 14 13:57:48 2013
From: ndbecker2 at gmail.com (Neal Becker)
Date: Fri, 14 Jun 2013 07:57:48 -0400
Subject: [C++-sig] return boost::shared_ptr<some internal>
Message-ID: <kpf0fn$b5$1@ger.gmane.org>

I have a class that has a member

something like this:

class A {
  boost::shared_ptr<B> b;

};

boost::shared_ptr<B> get_b (A const& ...) {
  return A.b;
}

where class B is already exposed to python in a different module.


I tried to provide access to the internal member A.b:

class_<A> ...
  .add_property ("b", &A::get_b)


It seems that attempting to provide access to this internal member fails, with
a message about no conversion from c++ type blah blah.

The c++ type represented by this internal state is already exposed in a 
different python module, which has also been imported into python.

>From what I can gather from ancient messages on the web, this usage just isn't
going to work.

Any thoughts?


From beamesleach at gmail.com  Fri Jun 14 14:32:51 2013
From: beamesleach at gmail.com (Alex Leach)
Date: Fri, 14 Jun 2013 13:32:51 +0100
Subject: [C++-sig] return boost::shared_ptr<some internal>
In-Reply-To: <kpf0fn$b5$1@ger.gmane.org>
References: <kpf0fn$b5$1@ger.gmane.org>
Message-ID: <op.wyn441w88s54ea@ns1.alexleach.org.uk>

On Fri, 14 Jun 2013 12:57:48 +0100, Neal Becker <ndbecker2 at gmail.com>  
wrote:

> I have a class that has a member
>
> something like this:
>
> class A {
>   boost::shared_ptr<B> b;
>
> };
>
> boost::shared_ptr<B> get_b (A const& ...) {
>   return A.b;
> }
>
> where class B is already exposed to python in a different module.


I think this depends on (at least) a few things:-

   1. libboost_python shouldn't be linked statically into each extension.  
If it is, then the to_python converter registry will be duplicated in each  
extension, so one extension module wouldn't be able to locate to python  
converters (e.g. class_'s) registered in other extensions.

   2. Class B will need to be exposed with a shared_ptr as its instance  
holder / object manager(?).. e.g.

class_<B, shared_ptr<B> >
    ...

   3. Like you've said, you'll also need to import B into Python, but as  
there's no inheritance involved between A and B (no 'bases<>' declared), I  
don't think the import order is completely relevant here, so long as both  
modules have inserted their to_python converters into a single registry.

HTH,
Alex