From kubol at kormoran.net  Fri Jul  2 15:42:26 2010
From: kubol at kormoran.net (Jakub Zytka)
Date: Fri, 02 Jul 2010 15:42:26 +0200
Subject: [C++-sig] problem with boost::python and pickling
Message-ID: <4C2DECC2.3030400@kormoran.net>

I've run into some problem i do not understand. Consider following example, 
which is a slightly modified pickle2.cpp from boost's libs/python/test/:

#include <boost/python/module.hpp>
#include <boost/python/def.hpp>
#include <boost/python/class.hpp>
#include <boost/python/tuple.hpp>
#include <boost/python/extract.hpp>

namespace boost_python_test {

struct dummy // my addition
{
};
   // A friendly class.
   class world
   {
     public:
       world(const std::string& country) : secret_number(0) {
         this->country = country;
       }
       world(dummy) {}; // my addition
       std::string greet() const { return "Hello from " + country + "!"; }
       std::string get_country() const { return country; }
       void set_secret_number(int number) { secret_number = number; }
       int get_secret_number() const { return secret_number; }
     private:
       std::string country;
       int secret_number;
   };

   struct world_pickle_suite : boost::python::pickle_suite
   {
     static
     boost::python::tuple
     getinitargs(const world& w)
     {
         using namespace boost::python;
         return make_tuple(dummy()); // change to use dummy instead of string
     }

     static
     boost::python::tuple
     getstate(const world& w)
     {
         using namespace boost::python;
         return make_tuple(w.get_secret_number());
     }

     static
     void
     setstate(world& w, boost::python::tuple state)
     {
         using namespace boost::python;

         	boost::python::object lenRes = state.attr("__len__")(); // old boost
	int const stateLen = boost::python::extract<int>(lenRes);
         if (stateLen != 1)
         {
           PyErr_SetObject(PyExc_ValueError,
                           ("expected 1-item tuple in call to __setstate__; got %s"
                            % state).ptr()
               );
           throw_error_already_set();
         }
         long number = extract<long>(state[0]);
         if (number != 42)
             w.set_secret_number(number);
     }
   };

}

BOOST_PYTHON_MODULE(pickle2_ext)
{
boost::python::class_< boost_python_test::dummy>( "dummy", boost::python::no_init );

     boost::python::class_<boost_python_test::world>(
         "world", boost::python::init<boost_python_test::dummy>())
         .def( boost::python::init< std::string const & >())
         .def("greet", &boost_python_test::world::greet)
         .def("get_secret_number", &boost_python_test::world::get_secret_number)
         .def("set_secret_number", &boost_python_test::world::set_secret_number)
         .def_pickle(boost_python_test::world_pickle_suite())
         ;
}

Code is compiled with gcc41, boost 1.33.1; compile options that might be relevant:
-pthread -fno-strict-aliasing -O0 -fno-inline -g0 -m64 -fPIC

then i use follwing test:
import pickle2_ext
import pickle

a = pickle2_ext.world("asd")
a.set_secret_number(54)
print a.get_secret_number()
pickle.dump(a, open('a.p', 'w'), pickle.HIGHEST_PROTOCOL)
r = pickle.load(open('a.p'))
print r.get_secret_number()

This test yields (python 2.4):
54
Traceback (most recent call last):
   File "test.py", line 7, in ?
     r = pickle.load(open('a.p'))
   File "/usr/lib64/python2.4/pickle.py", line 1390, in load
     return Unpickler(file).load()
   File "/usr/lib64/python2.4/pickle.py", line 872, in load
     dispatch[key](self)
   File "/usr/lib64/python2.4/pickle.py", line 1153, in load_reduce
     value = func(*args)
Boost.Python.ArgumentError: Python argument types in
     world.__init__(world, dummy)
did not match C++ signature:
     __init__(_object*, std::string)
     __init__(_object*, boost_python_test::dummy)

The original example, with std::string as a constructor parameter, works fine.
What do i miss?

regards,
Jakub ?ytka

From kubol at kormoran.net  Fri Jul  2 16:41:33 2010
From: kubol at kormoran.net (Jakub Zytka)
Date: Fri, 02 Jul 2010 16:41:33 +0200
Subject: [C++-sig] problem with boost::python and pickling
In-Reply-To: <4C2DECC2.3030400@kormoran.net>
References: <4C2DECC2.3030400@kormoran.net>
Message-ID: <4C2DFA9D.5080903@kormoran.net>

On 07/02/10 15:42, Jakub Zytka wrote:

Ok, on newer boost (1.43) error message pointed the actual problem:
even for such simple dummy class some pickling support must be provided, eg.

struct dummy_pickle_suite : boost::python::pickle_suite
{
static
     boost::python::tuple
     getinitargs(const dummy& w)
     {
         return boost::python::tuple();
     }

     static
     boost::python::tuple
     getstate(const dummy& w)
     {
         using namespace boost::python;
         return boost::python::tuple();
     }

     static
     void
     setstate(dummy&, boost::python::tuple)
     {
     }
};

I was mislead by this ArgumentError...

regards,
Jakub ?ytka

> I've run into some problem i do not understand. Consider following example,
> which is a slightly modified pickle2.cpp from boost's libs/python/test/:
>
> #include <boost/python/module.hpp>
> #include <boost/python/def.hpp>
> #include <boost/python/class.hpp>
> #include <boost/python/tuple.hpp>
> #include <boost/python/extract.hpp>
>
> namespace boost_python_test {
>
> struct dummy // my addition
> {
> };
> // A friendly class.
> class world
> {
> public:
> world(const std::string& country) : secret_number(0) {
> this->country = country;
> }
> world(dummy) {}; // my addition
> std::string greet() const { return "Hello from " + country + "!"; }
> std::string get_country() const { return country; }
> void set_secret_number(int number) { secret_number = number; }
> int get_secret_number() const { return secret_number; }
> private:
> std::string country;
> int secret_number;
> };
>
> struct world_pickle_suite : boost::python::pickle_suite
> {
> static
> boost::python::tuple
> getinitargs(const world& w)
> {
> using namespace boost::python;
> return make_tuple(dummy()); // change to use dummy instead of string
> }
>
> static
> boost::python::tuple
> getstate(const world& w)
> {
> using namespace boost::python;
> return make_tuple(w.get_secret_number());
> }
>
> static
> void
> setstate(world& w, boost::python::tuple state)
> {
> using namespace boost::python;
>
> boost::python::object lenRes = state.attr("__len__")(); // old boost
> int const stateLen = boost::python::extract<int>(lenRes);
> if (stateLen != 1)
> {
> PyErr_SetObject(PyExc_ValueError,
> ("expected 1-item tuple in call to __setstate__; got %s"
> % state).ptr()
> );
> throw_error_already_set();
> }
> long number = extract<long>(state[0]);
> if (number != 42)
> w.set_secret_number(number);
> }
> };
>
> }
>
> BOOST_PYTHON_MODULE(pickle2_ext)
> {
> boost::python::class_< boost_python_test::dummy>( "dummy",
> boost::python::no_init );
>
> boost::python::class_<boost_python_test::world>(
> "world", boost::python::init<boost_python_test::dummy>())
> .def( boost::python::init< std::string const & >())
> .def("greet", &boost_python_test::world::greet)
> .def("get_secret_number", &boost_python_test::world::get_secret_number)
> .def("set_secret_number", &boost_python_test::world::set_secret_number)
> .def_pickle(boost_python_test::world_pickle_suite())
> ;
> }
>
> Code is compiled with gcc41, boost 1.33.1; compile options that might be relevant:
> -pthread -fno-strict-aliasing -O0 -fno-inline -g0 -m64 -fPIC
>
> then i use follwing test:
> import pickle2_ext
> import pickle
>
> a = pickle2_ext.world("asd")
> a.set_secret_number(54)
> print a.get_secret_number()
> pickle.dump(a, open('a.p', 'w'), pickle.HIGHEST_PROTOCOL)
> r = pickle.load(open('a.p'))
> print r.get_secret_number()
>
> This test yields (python 2.4):
> 54
> Traceback (most recent call last):
> File "test.py", line 7, in ?
> r = pickle.load(open('a.p'))
> File "/usr/lib64/python2.4/pickle.py", line 1390, in load
> return Unpickler(file).load()
> File "/usr/lib64/python2.4/pickle.py", line 872, in load
> dispatch[key](self)
> File "/usr/lib64/python2.4/pickle.py", line 1153, in load_reduce
> value = func(*args)
> Boost.Python.ArgumentError: Python argument types in
> world.__init__(world, dummy)
> did not match C++ signature:
> __init__(_object*, std::string)
> __init__(_object*, boost_python_test::dummy)
>
> The original example, with std::string as a constructor parameter, works fine.
> What do i miss?
>
> regards,
> Jakub ?ytka
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig


From arn at bestmx.ru  Sat Jul  3 00:29:29 2010
From: arn at bestmx.ru (Anton Yabchinskiy)
Date: Sat, 3 Jul 2010 02:29:29 +0400
Subject: [C++-sig] X-language polymorphism and multithreading
Message-ID: <20100702222928.GA16001@mithlonde.erebor71.org>

Hi there.

I'm unsuccessfully trying to do a weird thing: to call an overridden
method in Python's class from a C++ thread. It doesn't work neither
with SWIG nor with Boost.Python. And I don't really sure it is
possible. Can someone comment on this? Below is the forwarded message
from the SWIG mailing list.

----- Forwarded message from Nitro <nitro at dr-code.org> -----

Am 01.07.2010, 22:35 Uhr, schrieb Anton Yabchinskiy <arn at bestmx.ru>:

> Greetings, SWIG users.
>
> Is it any way one could pass some data from the spawned thread in C++
> code to the Python class' method? My interface file looks like this:
>
> %module(directors="1") xyzzy
>
> %include <std_vector.i>
>
> %{
> #include "xyzzy.hpp"
> %}
>
> %template(Data_Buffer) std::vector<char>;
>
> namespace xyzzy {
>
>     typedef std::vector<char> Data_Buffer;
>
>     // Data listener interface
>     %feature("director") Data_Listener;
>     class Data_Listener
>     {
>     public:
>         virtual
>         ~Data_Listener();
>
>         virtual void
>         on_data(const Data_Buffer& data);
>     };
>
>     // Has an internal thread running
>     class Data_Provider
>     {
>     public:
>         // Add the listener to the list of known listeners. Call
>         // listener's ?on_data? method from internal thread when a
>         // block of data becomes available.
>         int
>         start(Data_Listener& listener);
>
>         // Removes the listener from the internal list of active
>         // listeners.
>         void
>         stop(int ticket);
>     };
>
> }// namespace xyzzy
>
> Interface file is then get processed and compiled into extension:
> $ swig -c++ -python -o _xyzzy.cpp xyzzy.i
> $ g++ -Wall -W -O1 -g `python2.5-dbg-config --includes` *.cpp -shared -o  
> _xyzzy.so -lPocoFoundation
>
> Then I'm trying to run a test application:
>
> #!/usr/bin/python2.5-dbg
>
> import time
> import xyzzy
>
> class Listener(xyzzy.Data_Listener):
>     def __init__(self):
>         xyzzy.Data_Listener.__init__(self)
>
>     def on_data(self, data):
>         print "data =", data
>
> provider = xyzzy.Data_Provider()
> listener = Listener()
> n = provider.start(listener)
> time.sleep(10)
> provider.stop(n)
>
> And before ?on_data? method get called it aborts with the following:
>
> Fatal Python error: PyThreadState_Get: no current thread
> [1]    14018 abort      ./test.py
>
> It seems to work (but SIGSEGVs on exit), if sleep is replaced with
> simple infinite loop:
>
> while True:
>     pass
>
> Is it something I missing? Is it something could be tweaked in the
> generated interfacing code? Or is it not possible to do such a thing?
>
> Thanks in advance for any suggestions and comments.

I think this question is better asked on the Python list. It might be  
something like time.sleep() not releasing the GIL and then sleeping. Or  
you might have to call things like PyThreadState_New(). The guys on the  
python list should be able to give you some answers.

-Matthias

----- End forwarded message -----

Also here is my Boost.Python file:

#include <boost/python.hpp>
#include <boost/python/suite/indexing/vector_indexing_suite.hpp>

#include "../xyzzy.hpp"

using namespace boost::python;
using namespace xyzzy;

class Data_Listener_Wrapper : public Data_Listener, public wrapper<Data_Listener>
{
public:
    void
    on_data(const Data_Buffer& data)
    {
        if (override on_data = get_override("on_data")) {
            on_data(data);
        }
        default_on_data(data);
    }

    void
    default_on_data(const Data_Buffer& data)
    {
        Data_Listener::on_data(data);
    }
};

BOOST_PYTHON_MODULE(xyzzy) {

    class_<Data_Buffer>("Data_Buffer")
        .def(vector_indexing_suite<Data_Buffer>());

    class_<Data_Listener_Wrapper, boost::noncopyable>("Data_Listener")
        .def("on_data", &Data_Listener::on_data, &Data_Listener_Wrapper::default_on_data);

    class_<Data_Provider, boost::noncopyable>("Data_Provider")
        .def("start", &Data_Provider::start)
        .def("stop", &Data_Provider::stop);

}

From charlessolar at gmail.com  Sat Jul  3 01:27:39 2010
From: charlessolar at gmail.com (Charles Solar)
Date: Fri, 2 Jul 2010 18:27:39 -0500
Subject: [C++-sig] X-language polymorphism and multithreading
In-Reply-To: <20100702222928.GA16001@mithlonde.erebor71.org>
References: <20100702222928.GA16001@mithlonde.erebor71.org>
Message-ID: <AANLkTinuhT9B4FAF9lYIrTE-ykDg9fhazzXr_pWIHrJW@mail.gmail.com>

Threads and python do not mix very well.  You need to handle locking and
unlocking the gil at the boundaries of python and c++.
There are several posts here about this problem, just search for thread or
'no current thread' in the archives.
A month ago I posted a modified boost python that will handle the gil
correctly for you if you want to give that a shot, or there is also TnFox
which also handles threads correctly.

Basically the short answer to your question is that you most certainly can,
but you need to understand how the gil works and when and where you need to
have it in order to do it correctly.

On Fri, Jul 2, 2010 at 5:29 PM, Anton Yabchinskiy <arn at bestmx.ru> wrote:

> Hi there.
>
> I'm unsuccessfully trying to do a weird thing: to call an overridden
> method in Python's class from a C++ thread. It doesn't work neither
> with SWIG nor with Boost.Python. And I don't really sure it is
> possible. Can someone comment on this? Below is the forwarded message
> from the SWIG mailing list.
>
> ----- Forwarded message from Nitro <nitro at dr-code.org> -----
>
> Am 01.07.2010, 22:35 Uhr, schrieb Anton Yabchinskiy <arn at bestmx.ru>:
>
> > Greetings, SWIG users.
> >
> > Is it any way one could pass some data from the spawned thread in C++
> > code to the Python class' method? My interface file looks like this:
> >
> > %module(directors="1") xyzzy
> >
> > %include <std_vector.i>
> >
> > %{
> > #include "xyzzy.hpp"
> > %}
> >
> > %template(Data_Buffer) std::vector<char>;
> >
> > namespace xyzzy {
> >
> >     typedef std::vector<char> Data_Buffer;
> >
> >     // Data listener interface
> >     %feature("director") Data_Listener;
> >     class Data_Listener
> >     {
> >     public:
> >         virtual
> >         ~Data_Listener();
> >
> >         virtual void
> >         on_data(const Data_Buffer& data);
> >     };
> >
> >     // Has an internal thread running
> >     class Data_Provider
> >     {
> >     public:
> >         // Add the listener to the list of known listeners. Call
> >         // listener's ?on_data? method from internal thread when a
> >         // block of data becomes available.
> >         int
> >         start(Data_Listener& listener);
> >
> >         // Removes the listener from the internal list of active
> >         // listeners.
> >         void
> >         stop(int ticket);
> >     };
> >
> > }// namespace xyzzy
> >
> > Interface file is then get processed and compiled into extension:
> > $ swig -c++ -python -o _xyzzy.cpp xyzzy.i
> > $ g++ -Wall -W -O1 -g `python2.5-dbg-config --includes` *.cpp -shared -o
> > _xyzzy.so -lPocoFoundation
> >
> > Then I'm trying to run a test application:
> >
> > #!/usr/bin/python2.5-dbg
> >
> > import time
> > import xyzzy
> >
> > class Listener(xyzzy.Data_Listener):
> >     def __init__(self):
> >         xyzzy.Data_Listener.__init__(self)
> >
> >     def on_data(self, data):
> >         print "data =", data
> >
> > provider = xyzzy.Data_Provider()
> > listener = Listener()
> > n = provider.start(listener)
> > time.sleep(10)
> > provider.stop(n)
> >
> > And before ?on_data? method get called it aborts with the following:
> >
> > Fatal Python error: PyThreadState_Get: no current thread
> > [1]    14018 abort      ./test.py
> >
> > It seems to work (but SIGSEGVs on exit), if sleep is replaced with
> > simple infinite loop:
> >
> > while True:
> >     pass
> >
> > Is it something I missing? Is it something could be tweaked in the
> > generated interfacing code? Or is it not possible to do such a thing?
> >
> > Thanks in advance for any suggestions and comments.
>
> I think this question is better asked on the Python list. It might be
> something like time.sleep() not releasing the GIL and then sleeping. Or
> you might have to call things like PyThreadState_New(). The guys on the
> python list should be able to give you some answers.
>
> -Matthias
>
> ----- End forwarded message -----
>
> Also here is my Boost.Python file:
>
> #include <boost/python.hpp>
> #include <boost/python/suite/indexing/vector_indexing_suite.hpp>
>
> #include "../xyzzy.hpp"
>
> using namespace boost::python;
> using namespace xyzzy;
>
> class Data_Listener_Wrapper : public Data_Listener, public
> wrapper<Data_Listener>
> {
> public:
>    void
>    on_data(const Data_Buffer& data)
>    {
>        if (override on_data = get_override("on_data")) {
>            on_data(data);
>        }
>        default_on_data(data);
>    }
>
>    void
>    default_on_data(const Data_Buffer& data)
>    {
>        Data_Listener::on_data(data);
>    }
> };
>
> BOOST_PYTHON_MODULE(xyzzy) {
>
>    class_<Data_Buffer>("Data_Buffer")
>        .def(vector_indexing_suite<Data_Buffer>());
>
>    class_<Data_Listener_Wrapper, boost::noncopyable>("Data_Listener")
>        .def("on_data", &Data_Listener::on_data,
> &Data_Listener_Wrapper::default_on_data);
>
>    class_<Data_Provider, boost::noncopyable>("Data_Provider")
>        .def("start", &Data_Provider::start)
>        .def("stop", &Data_Provider::stop);
>
> }
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20100702/804bf7ae/attachment-0001.html>

From arn at bestmx.ru  Sat Jul  3 03:03:53 2010
From: arn at bestmx.ru (Anton Yabchinskiy)
Date: Sat, 3 Jul 2010 05:03:53 +0400
Subject: [C++-sig] X-language polymorphism and multithreading
In-Reply-To: <AANLkTinuhT9B4FAF9lYIrTE-ykDg9fhazzXr_pWIHrJW@mail.gmail.com>
References: <20100702222928.GA16001@mithlonde.erebor71.org>
	<AANLkTinuhT9B4FAF9lYIrTE-ykDg9fhazzXr_pWIHrJW@mail.gmail.com>
Message-ID: <20100703010353.GA16508@mithlonde.erebor71.org>

On 2010-07-02 18:27:39-0500, Charles Solar wrote:
> Threads and python do not mix very well.  You need to handle locking and
> unlocking the gil at the boundaries of python and c++.
> There are several posts here about this problem, just search for thread or
> 'no current thread' in the archives.
> A month ago I posted a modified boost python that will handle the gil
> correctly for you if you want to give that a shot, or there is also TnFox
> which also handles threads correctly.
> 
> Basically the short answer to your question is that you most certainly can,
> but you need to understand how the gil works and when and where you need to
> have it in order to do it correctly.

So, I need PyGILState_Ensure/PyGILState_Release around the
overridden method call, and PyEval_InitThreads in the module
initialization. Am I right? Is the following code OK?

#include <boost/python.hpp>
#include <boost/python/suite/indexing/vector_indexing_suite.hpp>

#include "../xyzzy.hpp"

using namespace boost::python;
using namespace xyzzy;

namespace {

class GIL_State_Guard
{
public:
    GIL_State_Guard() :
        state_(PyGILState_Ensure())
    {
    }

    ~GIL_State_Guard()
    {
        PyGILState_Release(state_);
    }

private:
    PyGILState_STATE state_;
};

class Data_Listener_Wrapper : public Data_Listener, public wrapper<Data_Listener>
{
public:
    void
    on_data(const Data_Buffer& data)
    {
        if (override on_data = get_override("on_data")) {
            GIL_State_Guard guard;

            on_data(data);
        }
        default_on_data(data);
    }

    void
    default_on_data(const Data_Buffer& data)
    {
        Data_Listener::on_data(data);
    }
};

}// namespace

BOOST_PYTHON_MODULE(xyzzy) {

    PyEval_InitThreads();

    class_<Data_Buffer>("Data_Buffer")
        .def(vector_indexing_suite<Data_Buffer>());

    class_<Data_Listener_Wrapper, boost::noncopyable>("Data_Listener")
        .def("on_data", &Data_Listener::on_data, &Data_Listener_Wrapper::default_on_data);

    class_<Data_Provider, boost::noncopyable>("Data_Provider")
        .def("start", &Data_Provider::start)
        .def("stop", &Data_Provider::stop);

}

From hans_meine at gmx.net  Tue Jul  6 16:11:28 2010
From: hans_meine at gmx.net (Hans Meine)
Date: Tue, 6 Jul 2010 16:11:28 +0200
Subject: [C++-sig] X-language polymorphism and multithreading
Message-ID: <201007061611.29318.hans_meine@gmx.net>

On Saturday 03 July 2010 03:03:53 Anton Yabchinskiy wrote:
> So, I need PyGILState_Ensure/PyGILState_Release around the
> overridden method call, and PyEval_InitThreads in the module
> initialization. Am I right? Is the following code OK?

The code looks OK to me at least, but what's your problem?  (You just wrote 
"does not work"!)  Is there still a problem with the code below?

If so, I can see potential problems just due to ownership handling, for 
example you pass &data to the callbacks, but who's the owner of that data?  Is 
it possible that another thread releases the memory while the callback is 
running?

Oh, I see another likely problematic thing:
>     void
>     on_data(const Data_Buffer& data)
>     {
>         if (override on_data = get_override("on_data")) {
>             GIL_State_Guard guard;
> 
>             on_data(data);
>         }
>         default_on_data(data);
>     }

You're calling get_override - although I never used it, I believe it performs 
some PyObject_GetAttr or similar to check for an overridden method.  Remember: 
As soon as you're dealing with any python objects, you need the GIL!  (A 
common problem is that people don't see _GetItem oder _GetAttr as "running 
python code", although that's pushing your luck!)

HTH,
  Hans

From David.Aldrich at EU.NEC.COM  Tue Jul  6 16:32:07 2010
From: David.Aldrich at EU.NEC.COM (David Aldrich)
Date: Tue, 6 Jul 2010 15:32:07 +0100
Subject: [C++-sig] Cannot build Boost.Python
Message-ID: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3124@EUEXCLU01.EU.NEC.COM>

Hi

I am new to Boost.Python and am trying to build its library using Visual C++ 2008 on Windows XP.

I have downloaded and unzipped boost_1_43_0.zip and I have installed boost-jam-3.1.18-1-ntx86.zip.

Next, I executed:

C:\boost_1_43_0\libs\python\example\quickstart>\boost-jam-3.1.18-1-ntx86\bjam toolset=msvc --verbose-test test

The output I get is:

==================================================================
[snip]
msvc.link bin\test_embed.test\msvc-10.0\debug\threading-multi\test_embed.exe
LINK : warning LNK4001: no object files specified; libraries used
LINK : error LNK2001: unresolved external symbol _mainCRTStartup
bin\test_embed.test\msvc-10.0\debug\threading-multi\test_embed.exe : fatal error LNK1120: 1 unresolved externals

        call "C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 >nul
link /NOLOGO /INCREMENTAL:NO /DEBUG /MACHINE:X86 /subsystem:console /out:"bin\test_embed.test\msvc-10.0\debug\threading-multi\test_em
t_embed.test\msvc-10.0\debug\threading-multi\test_embed.exe.rsp"
        if %ERRORLEVEL% NEQ 0 EXIT %ERRORLEVEL%

...failed msvc.link bin\test_embed.test\msvc-10.0\debug\threading-multi\test_embed.exe bin\test_embed.test\msvc-10.0\debug\threading-
...removing bin\test_embed.test\msvc-10.0\debug\threading-multi\test_embed.pdb
...skipped <pbin\test_embed.test\msvc-10.0\debug\threading-multi>test_embed.run for lack of <pbin\test_embed.test\msvc-10.0\debug\thr
...failed updating 2 targets...
...skipped 2 targets...
==================================================================

I am surprised at the mention of Visual Studio 10.0 because I only have Visual Studio 2008 and Visual C++ 2008 Express installed.

Please will anyone suggest what is wrong?

Would it be better for me to use the pre-built binaries provided by Boost Consulting?

Best regards

David

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

From arn at bestmx.ru  Tue Jul  6 21:30:25 2010
From: arn at bestmx.ru (Anton Yabchinskiy)
Date: Tue, 6 Jul 2010 23:30:25 +0400
Subject: [C++-sig] X-language polymorphism and multithreading
In-Reply-To: <20100703010353.GA16508@mithlonde.erebor71.org>
References: <20100702222928.GA16001@mithlonde.erebor71.org>
	<AANLkTinuhT9B4FAF9lYIrTE-ykDg9fhazzXr_pWIHrJW@mail.gmail.com>
	<20100703010353.GA16508@mithlonde.erebor71.org>
Message-ID: <20100706193025.GA1299@mithlonde.erebor71.org>

On 2010-07-03 05:03:53+0400, Anton Yabchinskiy wrote:
> So, I need PyGILState_Ensure/PyGILState_Release around the
> overridden method call, and PyEval_InitThreads in the module
> initialization. Am I right? Is the following code OK?

With the GIL stuff code runs nicely now. It used to hang in the
callback, but that was my fault: I forgot to export one of the types
properly. I've just asked to be sure that I'm getting it
right. Charles, Hans, thanks for the valuable information.

From hans_meine at gmx.net  Wed Jul  7 09:44:17 2010
From: hans_meine at gmx.net (Hans Meine)
Date: Wed, 7 Jul 2010 09:44:17 +0200
Subject: [C++-sig] X-language polymorphism and multithreading
In-Reply-To: <20100706193025.GA1299@mithlonde.erebor71.org>
References: <20100702222928.GA16001@mithlonde.erebor71.org>
	<20100703010353.GA16508@mithlonde.erebor71.org>
	<20100706193025.GA1299@mithlonde.erebor71.org>
Message-ID: <201007070944.18965.hans_meine@gmx.net>

On Tuesday 06 July 2010 21:30:25 Anton Yabchinskiy wrote:
> On 2010-07-03 05:03:53+0400, Anton Yabchinskiy wrote:
> > So, I need PyGILState_Ensure/PyGILState_Release around the
> > overridden method call, and PyEval_InitThreads in the module
> > initialization. Am I right? Is the following code OK?
> 
> With the GIL stuff code runs nicely now. It used to hang in the
> callback, but that was my fault: I forgot to export one of the types
> properly. I've just asked to be sure that I'm getting it
> right. Charles, Hans, thanks for the valuable information.

Remember that you probably need the GIL earlier than in the code you posted, 
namely for the get_override().  "runs nicely" can mean "most of the time" with 
threading, you know... ;-)

HTH,
  Hans

From David.Aldrich at EU.NEC.COM  Wed Jul  7 15:03:46 2010
From: David.Aldrich at EU.NEC.COM (David Aldrich)
Date: Wed, 7 Jul 2010 14:03:46 +0100
Subject: [C++-sig] Newbie question about Boost.Python
Message-ID: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3B37ED@EUEXCLU01.EU.NEC.COM>

Hi

I am trying to use Boost.Python on Windows XP using Visual C++ 2008 Express and Python 2.7.

I have built Boost using bjam. The generated libraries include:

libboost_python-vc90-mt-gd-1_43.lib

I am now trying to run the example in the boost.python 'EmbeddingPython wiki page, which begins:

#include <boost/python.hpp>
using namespace boost::python;
int main( int argc, char ** argv ) {
  try {
    Py_Initialize();
[snip]

When I build it I get error:

LINK : fatal error LNK1104: cannot open file 'boost_python-vc90-mt-gd-1_43.lib'

Please can anyone suggest why the linker wants a library file beginning 'boost_python' when bjam has generated library files beginning 'libboost_python' ?

Best regards

David

From pj at nexplore.ch  Thu Jul  8 08:43:22 2010
From: pj at nexplore.ch (Philip Jonientz - NEXPLORE AG)
Date: Thu, 8 Jul 2010 06:43:22 +0000
Subject: [C++-sig] Newbie question about Boost.Python
In-Reply-To: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3B37ED@EUEXCLU01.EU.NEC.COM>
References: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3B37ED@EUEXCLU01.EU.NEC.COM>
Message-ID: <6EE3FC70E2CECE45834E05359BCE7349027F93@BRUTUS.nexplore.ch>

Hi

I had a similar problem some time ago, I just don't exactly remember, how I solved it...
For me, this lib-file is located in: \bin.v2\libs\python\build\msvc-10.0\debug\threading-multi
If I remember correctly, I simply moved some folders and files around, until it fit.

-----Urspr?ngliche Nachricht-----
Von: cplusplus-sig-bounces+pj=nexplore.ch at python.org [mailto:cplusplus-sig-bounces+pj=nexplore.ch at python.org] Im Auftrag von David Aldrich
Gesendet: Mittwoch, 7. Juli 2010 15:04
An: cplusplus-sig at python.org
Betreff: [C++-sig] Newbie question about Boost.Python

Hi

I am trying to use Boost.Python on Windows XP using Visual C++ 2008 Express and Python 2.7.

I have built Boost using bjam. The generated libraries include:

libboost_python-vc90-mt-gd-1_43.lib

I am now trying to run the example in the boost.python 'EmbeddingPython wiki page, which begins:

#include <boost/python.hpp>
using namespace boost::python;
int main( int argc, char ** argv ) {
  try {
    Py_Initialize();
[snip]

When I build it I get error:

LINK : fatal error LNK1104: cannot open file 'boost_python-vc90-mt-gd-1_43.lib'

Please can anyone suggest why the linker wants a library file beginning 'boost_python' when bjam has generated library files beginning 'libboost_python' ?

Best regards

David
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig at python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

From David.Aldrich at EU.NEC.COM  Thu Jul  8 12:24:25 2010
From: David.Aldrich at EU.NEC.COM (David Aldrich)
Date: Thu, 8 Jul 2010 11:24:25 +0100
Subject: [C++-sig] Newbie question about Boost.Python
In-Reply-To: <6EE3FC70E2CECE45834E05359BCE7349027F93@BRUTUS.nexplore.ch>
References: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3B37ED@EUEXCLU01.EU.NEC.COM>,
	<6EE3FC70E2CECE45834E05359BCE7349027F93@BRUTUS.nexplore.ch>
Message-ID: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3B37F1@EUEXCLU01.EU.NEC.COM>

Hi

I got an answer for this problem from Steven Watanabe on the boost-users list. He wrote:

=========================
The linker is looking for the import library for a DLL.
You can build this with
bjam --with-python link=shared
or you can compile your project with
-DBOOST_PYTHON_STATIC_LIB
(Boost.Python uses different auto-link conventions from the
rest of Boost)
==========================

That fixes my problem.

Best regards

David

________________________________________
From: cplusplus-sig-bounces+david.aldrich=eu.nec.com at python.org [cplusplus-sig-bounces+david.aldrich=eu.nec.com at python.org] On Behalf Of Philip Jonientz - NEXPLORE AG [pj at nexplore.ch]
Sent: 08 July 2010 07:43
To: Development of Python/C++ integration
Subject: Re: [C++-sig] Newbie question about Boost.Python

Hi

I had a similar problem some time ago, I just don't exactly remember, how I solved it...
For me, this lib-file is located in: \bin.v2\libs\python\build\msvc-10.0\debug\threading-multi
If I remember correctly, I simply moved some folders and files around, until it fit.

-----Urspr?ngliche Nachricht-----
Von: cplusplus-sig-bounces+pj=nexplore.ch at python.org [mailto:cplusplus-sig-bounces+pj=nexplore.ch at python.org] Im Auftrag von David Aldrich
Gesendet: Mittwoch, 7. Juli 2010 15:04
An: cplusplus-sig at python.org
Betreff: [C++-sig] Newbie question about Boost.Python

Hi

I am trying to use Boost.Python on Windows XP using Visual C++ 2008 Express and Python 2.7.

I have built Boost using bjam. The generated libraries include:

libboost_python-vc90-mt-gd-1_43.lib

I am now trying to run the example in the boost.python 'EmbeddingPython wiki page, which begins:

#include <boost/python.hpp>
using namespace boost::python;
int main( int argc, char ** argv ) {
  try {
    Py_Initialize();
[snip]

When I build it I get error:

LINK : fatal error LNK1104: cannot open file 'boost_python-vc90-mt-gd-1_43.lib'

Please can anyone suggest why the linker wants a library file beginning 'boost_python' when bjam has generated library files beginning 'libboost_python' ?

Best regards

David
_______________________________________________
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


 Click https://www.mailcontrol.com/sr/4UrU4bFfymzTndxI!oX7UoEGNNKKZK+e8S19yqcE31+woBqi0QOlYHAZsmfuHmZeEGynLBNIB!Z1EP!VjHY16w==  to report this email as spam.

From elemel at elemel.se  Fri Jul  9 10:05:25 2010
From: elemel at elemel.se (Mikael Lind)
Date: Fri, 9 Jul 2010 10:05:25 +0200
Subject: [C++-sig] Best practices for wrapping classes where instance
	lifecycle is managed by someone else?
Message-ID: <AANLkTimhqfAjIv5fVnFMHq2O6UuT-WVFfaAapkrhW33s@mail.gmail.com>

I'm using Boost.Python to wrap Box2D, a 2D physics engine written in
C++. The user of Box2D starts by constructing an instance of class
b2World. The b2World class has member functions for creating and
destroying bodies and joints (for constraining the movement of the
bodies). The b2Body class has member functions for creating and
destroying fixtures (for attaching collisions shapes to the body). The
created instances are returned as raw pointers.

Is there a safe and efficient way of associating a Python wrapper
instance with a wrapped C++ instance, where the Python instance
doesn't manage the lifecycle of the C++ instance? I was thinking of
adding a member variable to the C++ class that tracks the Python
wrapper instance if any has been created, and do something intelligent
on destruction of the C++ instance, i.e. marking the Python instance
as invalid. I would like to throw an exception if the user attempts to
access the destructed C++ instance through the invalid Python
instance.

Is the above a good approach? If it is, has anyone got any best
practices or recommendations for the implementation?

-- 
Mikael Lind
http://elemel.se/

From renatox at gmail.com  Fri Jul  9 14:28:45 2010
From: renatox at gmail.com (Renato Araujo)
Date: Fri, 9 Jul 2010 09:28:45 -0300
Subject: [C++-sig] Best practices for wrapping classes where instance
	lifecycle is managed by someone else?
In-Reply-To: <AANLkTimhqfAjIv5fVnFMHq2O6UuT-WVFfaAapkrhW33s@mail.gmail.com>
References: <AANLkTimhqfAjIv5fVnFMHq2O6UuT-WVFfaAapkrhW33s@mail.gmail.com>
Message-ID: <AANLkTimBtDuPs89DjtkGmxdcYgrDtAwv6ds89109wwWX@mail.gmail.com>

Hi
Mikael Lind

Check: http://www.boost.org/doc/libs/1_43_0/libs/python/doc/v2/with_custodian_and_ward.html#with_custodian_and_ward-spec,
if this not work to your problem this can help you to implement a new
policy.

BR
Renato Araujo Oliveira Filho




On Fri, Jul 9, 2010 at 5:05 AM, Mikael Lind <elemel at elemel.se> wrote:
> I'm using Boost.Python to wrap Box2D, a 2D physics engine written in
> C++. The user of Box2D starts by constructing an instance of class
> b2World. The b2World class has member functions for creating and
> destroying bodies and joints (for constraining the movement of the
> bodies). The b2Body class has member functions for creating and
> destroying fixtures (for attaching collisions shapes to the body). The
> created instances are returned as raw pointers.
>
> Is there a safe and efficient way of associating a Python wrapper
> instance with a wrapped C++ instance, where the Python instance
> doesn't manage the lifecycle of the C++ instance? I was thinking of
> adding a member variable to the C++ class that tracks the Python
> wrapper instance if any has been created, and do something intelligent
> on destruction of the C++ instance, i.e. marking the Python instance
> as invalid. I would like to throw an exception if the user attempts to
> access the destructed C++ instance through the invalid Python
> instance.
>
> Is the above a good approach? If it is, has anyone got any best
> practices or recommendations for the implementation?
>
> --
> Mikael Lind
> http://elemel.se/
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
>

From pentix at gmail.com  Mon Jul 12 09:13:05 2010
From: pentix at gmail.com (Pentix)
Date: Mon, 12 Jul 2010 00:13:05 -0700 (PDT)
Subject: [C++-sig] Problem with map_indexing_suite
Message-ID: <29135982.post@talk.nabble.com>


Hi, Damien!

I've got exactly the same problem... Have you got any achievements?



Damien Dupuis wrote:
> 
> error: no match for call to ?(const
> boost::python::detail::specify_a_return_value_policy_to_wrap_functions_returning<X*>)
> (X*)?
> 

-- 
View this message in context: http://old.nabble.com/Problem-with-map_indexing_suite-tp28925347p29135982.html
Sent from the Python - c++-sig mailing list archive at Nabble.com.


From j.reid at mail.cryst.bbk.ac.uk  Mon Jul 12 09:50:03 2010
From: j.reid at mail.cryst.bbk.ac.uk (John Reid)
Date: Mon, 12 Jul 2010 08:50:03 +0100
Subject: [C++-sig] Problem with map_indexing_suite
In-Reply-To: <29135982.post@talk.nabble.com>
References: <29135982.post@talk.nabble.com>
Message-ID: <i1ehfb$r3s$1@dough.gmane.org>

Pentix wrote:
> Hi, Damien!
> 
> I've got exactly the same problem... Have you got any achievements?
> 
Have a look at:
http://www.boost.org/doc/libs/1_43_0/libs/python/doc/tutorial/doc/html/python/functions.html#python.call_policies


> 
> 
> Damien Dupuis wrote:
>> error: no match for call to ?(const
>> boost::python::detail::specify_a_return_value_policy_to_wrap_functions_returning<X*>)
>> (X*)?
>>
> 


From j.reid at mail.cryst.bbk.ac.uk  Mon Jul 12 09:52:10 2010
From: j.reid at mail.cryst.bbk.ac.uk (John Reid)
Date: Mon, 12 Jul 2010 08:52:10 +0100
Subject: [C++-sig] Problem with map_indexing_suite
In-Reply-To: <B43CD2F4-2A40-4530-B7FB-BF818FB56089@lip6.fr>
References: <B43CD2F4-2A40-4530-B7FB-BF818FB56089@lip6.fr>
Message-ID: <i1ehja$r3s$2@dough.gmane.org>



Damien Dupuis wrote:
> I'm trying to wrap a whole C++ that contains a lot of access to std::vector and std::map.
> 
> I managed to wrap vectors but i've got problems with maps.
> 
> The following simple example fails to compile with the error:
> error: no match for call to ?(const boost::python::detail::specify_a_return_value_policy_to_wrap_functions_returning<X*>) (X*)?
> 
> ====================================================
> #include <boost/python.hpp>
> #include <boost/python/suite/indexing/vector_indexing_suite.hpp>
> #include <boost/python/suite/indexing/map_indexing_suite.hpp>
> using namespace boost::python;
> 
> class X {
>     public:
>     X(std::string s): _s(s) {}
>     std::string const repr() { return _s; }
> 
>     private:
>     std::string _s;
> };
> 
> class Y {
>     public:
>     Y(): _vec(), _map() {};
>     void addToVec(X* x)                { _vec.push_back(x); }
>     void addToMap(int i, X* x)         { _map[i] = x;       }
>     const std::vector<X*>& getXVec()   { return _vec;       }
>     const std::map<int, X*>& getXMap() { return _map; }
> 
>     private:
>     std::vector<X*>   _vec;
>     std::map<int, X*> _map;
> };
> 
> BOOST_PYTHON_MODULE(pyTEST) {
>     class_<X, X*>("X", init<std::string>())
>         .def("__repr__", &X::repr)
>     ;
> 
>     class_<std::vector<X*> >("XVec")
>         .def(vector_indexing_suite<std::vector<X*>, true>())
>     ;
> 
>     class_<std::map<int, X*> >("XMap")
>         .def(map_indexing_suite<std::map<int, X*>, true>())
>     ;
> 
>     class_<Y>("Y", init<>())
>         .def("addToVec", &Y::addToVec)
>         .def("addToMap", &Y::addToMap)
>         .def("getXVec" , &Y::getXVec , return_internal_reference<>())
>         .def("getXMap" , &Y::getXMap , return_internal_reference<>())
>     ;
> }
> ====================================================
> 
> 
> I tried to use boost::shared_ptr<X> instead of X* in this small example and it works, but I would like not to have to correct all my existing C++ code to use boost::shared_ptr.
> And since it works well with std::vector<X*>, I think it should work with maps.
> 
> Some google search make me think I should add a return_value_policy to the __getitem__ method of std::map<int, X*> class, but when I try I get the error
> error: address of overloaded function with no contextual type information
> I'm clearly doing something wrong here.

That sounds like the right idea. Are you taking the address of an 
overloaded function? In which case the compiler might not know which 
overload to use.



From damien.dupuis at lip6.fr  Mon Jul 12 15:04:24 2010
From: damien.dupuis at lip6.fr (Damien Dupuis)
Date: Mon, 12 Jul 2010 15:04:24 +0200
Subject: [C++-sig] Problem with map_indexing_suite
In-Reply-To: <29135982.post@talk.nabble.com>
References: <29135982.post@talk.nabble.com>
Message-ID: <0BDF9E55-4B47-460B-8841-6A13FCD1A3E3@lip6.fr>

Since I didn't find any solution when using map_indexing_suite, I wrote a simple wrapping that works in my case :

==============
#include <map>
#include <boost/python.hpp>

namespace myProject {
template<class Key, class Val>
struct map_item {
    typedef std::map<Key,Val> Map;

    static Val get(Map & self, const Key idx) {
      if (self.find(idx) == self.end()) {
          PyErr_SetString(PyExc_KeyError,"Map key not found");
          throw_error_already_set();
      }
      return self[idx];
    }

    static void set(Map& self, const Key idx, const Val val) { self[idx]=val; }
    static void del(Map& self, const Key n)                  { self.erase(n); }
    static bool in (Map const& self, const Key n)            { return self.find(n) != self.end(); }

    static list keys(Map const& self) {
        list t;
        for(typename Map::const_iterator it = self.begin() ; it!=self.end() ; ++it)
            t.append(it->first);
        return t;
    }

    static list values(Map const& self) {
        list t;
        for(typename Map::const_iterator it=self.begin(); it!=self.end(); ++it)
            t.append(it->second);
        return t;
    }

    static list items(Map const& self) {
        list t;
        for(typename Map::const_iterator it=self.begin(); it!=self.end(); ++it)
            t.append( make_tuple(it->first, it->second) );
        return t;
    }
};

#define STL_MAP_WRAPPING_PTR(KEY_TYPE, VALUE_TYPE, PYTHON_TYPE_NAME)               \
    class_<std::pair<const KEY_TYPE, VALUE_TYPE> >((std::string(PYTHON_TYPE_NAME)+std::string("DATA")).c_str()) \
        .def_readonly ("key"  , &std::pair<const KEY_TYPE, VALUE_TYPE>::first ) \
        .def_readwrite("value", &std::pair<const KEY_TYPE, VALUE_TYPE>::second) \
    ;                                                                          \
    class_<std::map<KEY_TYPE, VALUE_TYPE> >(PYTHON_TYPE_NAME)                  \
        .def("__len__"     , &std::map<KEY_TYPE, VALUE_TYPE>::size)            \
        .def("__iter__"    , boost::python::iterator<std::map<KEY_TYPE, VALUE_TYPE>, return_internal_reference<> >()) \
        .def("__getitem__" , &map_item<KEY_TYPE, VALUE_TYPE>().get, return_internal_reference<>()) \
        .def("__setitem__" , &map_item<KEY_TYPE, VALUE_TYPE>().set   )         \
        .def("__delitem__" , &map_item<KEY_TYPE, VALUE_TYPE>().del   )         \
        .def("__contains__", &map_item<KEY_TYPE, VALUE_TYPE>().in    )         \
        .def("clear"       , &std::map<KEY_TYPE, VALUE_TYPE>::clear  )         \
        .def("has_key"     , &map_item<KEY_TYPE, VALUE_TYPE>().in    )         \
        .def("keys"        , &map_item<KEY_TYPE, VALUE_TYPE>().keys  )         \
        .def("values"      , &map_item<KEY_TYPE, VALUE_TYPE>().values)         \
        .def("items"       , &map_item<KEY_TYPE, VALUE_TYPE>().items )         \
    ;

#define STL_MAP_WRAPPING(KEY_TYPE, VALUE_TYPE, PYTHON_TYPE_NAME)               \
    class_<std::pair<const KEY_TYPE, VALUE_TYPE> >((std::string(PYTHON_TYPE_NAME)+std::string("DATA")).c_str()) \
        .def_readonly ("key"  , &std::pair<const KEY_TYPE, VALUE_TYPE>::first ) \
        .def_readwrite("value", &std::pair<const KEY_TYPE, VALUE_TYPE>::second) \
    ;                                                                          \
    class_<std::map<KEY_TYPE, VALUE_TYPE> >(PYTHON_TYPE_NAME)                  \
        .def("__len__"     , &std::map<KEY_TYPE, VALUE_TYPE>::size)            \
        .def("__iter__"    , boost::python::iterator<std::map<KEY_TYPE, VALUE_TYPE>, return_internal_reference<> >()) \
        .def("__getitem__" , &map_item<KEY_TYPE, VALUE_TYPE>().get   )         \
        .def("__setitem__" , &map_item<KEY_TYPE, VALUE_TYPE>().set   )         \
        .def("__delitem__" , &map_item<KEY_TYPE, VALUE_TYPE>().del   )         \
        .def("__contains__", &map_item<KEY_TYPE, VALUE_TYPE>().in    )         \
        .def("clear"       , &std::map<KEY_TYPE, VALUE_TYPE>::clear  )         \
        .def("has_key"     , &map_item<KEY_TYPE, VALUE_TYPE>().in    )         \
        .def("keys"        , &map_item<KEY_TYPE, VALUE_TYPE>().keys  )         \
        .def("values"      , &map_item<KEY_TYPE, VALUE_TYPE>().values)         \
        .def("items"       , &map_item<KEY_TYPE, VALUE_TYPE>().items )         \
    ;

} // namespace
=================



Simply use STL_MAP_WRAPPING_PTR(KeyClass, ClassA*, "ClassAMap") to bind a map<KeyClass, ClassA*>
or STL_MAP_WRAPPING(KeyClass, ClassB, "ClassBMap") to bind a map<KeyClass, ClassB>

This code works in my case, fell free to correct or complete any error / missing.

-------------------------------
Damien Dupuis

Le 12 juil. 2010 ? 09:13, Pentix a ?crit :

> 
> Hi, Damien!
> 
> I've got exactly the same problem... Have you got any achievements?
> 
> 
> 
> Damien Dupuis wrote:
>> 
>> error: no match for call to ?(const
>> boost::python::detail::specify_a_return_value_policy_to_wrap_functions_returning<X*>)
>> (X*)?
>> 
> 
> -- 
> View this message in context: http://old.nabble.com/Problem-with-map_indexing_suite-tp28925347p29135982.html
> Sent from the Python - c++-sig mailing list archive at Nabble.com.
> 
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
> 








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20100712/6a5994a7/attachment.html>

From eudoxos at arcig.cz  Tue Jul 13 17:47:55 2010
From: eudoxos at arcig.cz (=?UTF-8?Q?V=C3=A1clav_=C5=A0milauer?=)
Date: Tue, 13 Jul 2010 17:47:55 +0200
Subject: [C++-sig] a working example of container_proxy?
Message-ID: <1279036075.13745.34.camel@flux>

Hi,

I would like to wrap several std::vector containers using a proxy so
that changing an element like obj[3]=3 will propagate back to c++. I
found container_proxy in the indexing_suite v2 at
http://www.language-binding.net/pyplusplus/documentation/indexing_suite_v2.html.html?highlight=container_proxy#container_proxy

I spend a long time to find a working example of that (very nice and
handy) template on the web without success; and I admit I am lost in
reading its source, unable to figure it out myself.

Is there an example that shows a very simple case of wrapping e.g.
std::vector<int> using the proxy_container? I imagine it will be only a
few lines. Or can I get an example here?

Many thanks,

V?clav


From marco.selinger at yahoo.de  Thu Jul 15 13:35:55 2010
From: marco.selinger at yahoo.de (Marco Selinger)
Date: Thu, 15 Jul 2010 11:35:55 +0000 (GMT)
Subject: [C++-sig] reuse C++ classes that have been wrapped with SWIG
Message-ID: <65706.17933.qm@web24902.mail.ird.yahoo.com>

Dear all,
is it possible to reuse C++ classes in Boost.Python that have been wrapped with 
SWIG?

There is a complete SWIG wrapper for the OpenCV (http://opencv.willowgarage.com) 
project.

I am developing a small image processing application that uses some of the 
OpenCV classes. This application will be wrapped using Boost.Python.
How do I declare those classes in Boost.Python that have already been wrapped 
with SWIG?

For example, there is a method in my application that returns an instance of 
CvArr. The wrapper must recognize that the returned CvArr is the same as the 
CvArr wrapped by SWIG, so that all CvArr methods can be called on this instance.

Thank you
Marco


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

From rwgk at yahoo.com  Thu Jul 15 19:48:13 2010
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 15 Jul 2010 10:48:13 -0700 (PDT)
Subject: [C++-sig] reuse C++ classes that have been wrapped with SWIG
In-Reply-To: <65706.17933.qm@web24902.mail.ird.yahoo.com>
References: <65706.17933.qm@web24902.mail.ird.yahoo.com>
Message-ID: <230639.25094.qm@web111411.mail.gq1.yahoo.com>

Yes, should be possible, although I haven't tried it in a long time, but here 
are 

some old files that may still work:

http://cctbx.svn.sourceforge.net/viewvc/cctbx/trunk/boost_adaptbx/

swig_arg.hpp
swig_args_ext.cpp
tests/tst_swig_args.py
SConscript

In the SConscript look for "swig".

From pentix at gmail.com  Fri Jul 16 05:23:23 2010
From: pentix at gmail.com (Pentix)
Date: Thu, 15 Jul 2010 20:23:23 -0700 (PDT)
Subject: [C++-sig]  Project architecture and Py++
Message-ID: <29179641.post@talk.nabble.com>


Hi,

I?d like to use Python in the following way:

1) create a library (pyd) with some interfaces of the main program taken
outside; generate then its code with py++
2) create a set of scripts, that use this library
3) execute these scripts with boost::python from the main program

Unwillingness to carry out any manual corrections of the generated code is
an important part of the solution. The code is being generated
authomatically, and only the script and the imported header are to be
corrected in case of any problem. It is motivated by the fact, that
the program is developing dynamically and it is better to see and solve
immedeately the emerging discrepancies.

Thus, the main task of implementation phase been solved already, but there
arose the following problem: there appeared a desire to transfer
into python our objects (from those being exposed). But all wrappers are
being generated into the library from the point 1, and are in the
cpp files. 

I?m ready to make the dependance of the main module on the library. But how
to get the wrappers, if it is undesirable to correct the generated code
manually?

Thanks,
Alex
-- 
View this message in context: http://old.nabble.com/Project-architecture-and-Py%2B%2B-tp29179641p29179641.html
Sent from the Python - c++-sig mailing list archive at Nabble.com.


From benoit-l at moving-picture.com  Fri Jul 16 10:30:09 2010
From: benoit-l at moving-picture.com (Benoit Leveau)
Date: Fri, 16 Jul 2010 09:30:09 +0100
Subject: [C++-sig] Project architecture and Py++
In-Reply-To: <29179641.post@talk.nabble.com>
References: <29179641.post@talk.nabble.com>
Message-ID: <4C401891.8080004@moving-picture.com>

Pentix wrote:
> Hi,
> 
> I?d like to use Python in the following way:
> 
> 1) create a library (pyd) with some interfaces of the main program taken
> outside; generate then its code with py++
> 2) create a set of scripts, that use this library
> 3) execute these scripts with boost::python from the main program
> 
> Unwillingness to carry out any manual corrections of the generated code is
> an important part of the solution. The code is being generated
> authomatically, and only the script and the imported header are to be
> corrected in case of any problem. It is motivated by the fact, that
> the program is developing dynamically and it is better to see and solve
> immedeately the emerging discrepancies.
> 
> Thus, the main task of implementation phase been solved already, but there
> arose the following problem: there appeared a desire to transfer
> into python our objects (from those being exposed). But all wrappers are
> being generated into the library from the point 1, and are in the
> cpp files. 
> 
> I?m ready to make the dependance of the main module on the library. But how
> to get the wrappers, if it is undesirable to correct the generated code
> manually?

Hi,

Manually fixing the generated code is indeed a bad idea.

You should take a look at the code injection feature of py++.

What you can do is having your "binding generator" detecting some
custom files and then injecting the code in the wrappers.
- you define a "custom code" folder,
- whenever your generator detects a "MyClass_injection.cpp" file,
then it will inject the code of this file into the wrapper of 'MyClass',
>>> cls.add_wrapper_code( custom_code )

This is the basic approach, you may need to inject declaration code, registration code, some code at the
module level and not the class level, handle templates, etc. but once you get the basic system in place,
you can add more features as the need arise.

This way, you don't have to change your original headers nor the generated code directly.

Hope that helps,
Benoit

From benoit-l at moving-picture.com  Fri Jul 16 10:57:18 2010
From: benoit-l at moving-picture.com (Benoit Leveau)
Date: Fri, 16 Jul 2010 09:57:18 +0100
Subject: [C++-sig] Project architecture and Py++
In-Reply-To: <4C401891.8080004@moving-picture.com>
References: <29179641.post@talk.nabble.com>
	<4C401891.8080004@moving-picture.com>
Message-ID: <4C401EEE.1080201@moving-picture.com>

Benoit Leveau wrote:
> Pentix wrote:
>> Hi,
>>
>> I?d like to use Python in the following way:
>>
>> 1) create a library (pyd) with some interfaces of the main program taken
>> outside; generate then its code with py++
>> 2) create a set of scripts, that use this library
>> 3) execute these scripts with boost::python from the main program
>>
>> Unwillingness to carry out any manual corrections of the generated 
>> code is
>> an important part of the solution. The code is being generated
>> authomatically, and only the script and the imported header are to be
>> corrected in case of any problem. It is motivated by the fact, that
>> the program is developing dynamically and it is better to see and solve
>> immedeately the emerging discrepancies.
>>
>> Thus, the main task of implementation phase been solved already, but 
>> there
>> arose the following problem: there appeared a desire to transfer
>> into python our objects (from those being exposed). But all wrappers are
>> being generated into the library from the point 1, and are in the
>> cpp files.
>> I?m ready to make the dependance of the main module on the library. 
>> But how
>> to get the wrappers, if it is undesirable to correct the generated code
>> manually?
> 
> Hi,
> 
> Manually fixing the generated code is indeed a bad idea.
> 
> You should take a look at the code injection feature of py++.
> 
> What you can do is having your "binding generator" detecting some
> custom files and then injecting the code in the wrappers.
> - you define a "custom code" folder,
> - whenever your generator detects a "MyClass_injection.cpp" file,
> then it will inject the code of this file into the wrapper of 'MyClass',
>>>> cls.add_wrapper_code( custom_code )
> 
> This is the basic approach, you may need to inject declaration code, 
> registration code, some code at the
> module level and not the class level, handle templates, etc. but once 
> you get the basic system in place,
> you can add more features as the need arise.
> 
> This way, you don't have to change your original headers nor the 
> generated code directly.
> 
> Hope that helps,
> Benoit

I've just realized this is C++-sig mailing list, you may want to post to
pygccxml-development at lists.sourceforge.net
if the conversation is more about py++.

Benoit

From charlessolar at gmail.com  Fri Jul 16 20:38:48 2010
From: charlessolar at gmail.com (Charles Solar)
Date: Fri, 16 Jul 2010 13:38:48 -0500
Subject: [C++-sig] [patch] Make boost python accessible by multiple threads
Message-ID: <AANLkTinMlKfDqK171ktAYCjQZdAo8HKgN4lUbOm429vs@mail.gmail.com>

I mentioned it before but I have this patch for boost python that adds
code to lock and unlock the gil at all the boundaries I have found
between python and boost python.  This makes it so multiple threads
can call into python without the user having to lock and unlock the
gil themselves.  I am pretty sure this is a very much desired feature
but I guess the developers are waiting for a head start, so here is
the patch file that can be applied to the boost trunk or any of the
1.4x versions of boost python.  I would very much like to see the
patch correctly worked into boost python so I no longer have to
maintain it myself.
I have been using this in my application for a few months now and I am
fairly confident in its completeness when NOT embedding python
interpreters.  There may be more entry points I have missed because I
do not embed python in my app, therefore I would say this patch is
only non-embedded systems.

Charles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: boost_python.patch
Type: application/octet-stream
Size: 10015 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20100716/0701705d/attachment.obj>

From talljimbo at gmail.com  Fri Jul 16 21:33:43 2010
From: talljimbo at gmail.com (Jim Bosch)
Date: Fri, 16 Jul 2010 12:33:43 -0700
Subject: [C++-sig] [patch] Make boost python accessible by multiple
	threads
In-Reply-To: <AANLkTinMlKfDqK171ktAYCjQZdAo8HKgN4lUbOm429vs@mail.gmail.com>
References: <AANLkTinMlKfDqK171ktAYCjQZdAo8HKgN4lUbOm429vs@mail.gmail.com>
Message-ID: <4C40B417.5010904@gmail.com>

On 07/16/2010 11:38 AM, Charles Solar wrote:
> I mentioned it before but I have this patch for boost python that adds
> code to lock and unlock the gil at all the boundaries I have found
> between python and boost python.  This makes it so multiple threads
> can call into python without the user having to lock and unlock the
> gil themselves.  I am pretty sure this is a very much desired feature
> but I guess the developers are waiting for a head start, so here is
> the patch file that can be applied to the boost trunk or any of the
> 1.4x versions of boost python.  I would very much like to see the
> patch correctly worked into boost python so I no longer have to
> maintain it myself.
> I have been using this in my application for a few months now and I am
> fairly confident in its completeness when NOT embedding python
> interpreters.  There may be more entry points I have missed because I
> do not embed python in my app, therefore I would say this patch is
> only non-embedded systems.
>

I think there have already been (at least two?) other submitted patches 
to add multithreading support to Boost.Python.  I believe one of them 
has been languishing in the Boost ticket system for quite a long time, 
and I've gathered that some people have put together their own forks of 
Boost.Python that have threading support.

But I don't know much more than this, and I'm also curious to hear the 
story told by someone who has more information...why hasn't 
multithreading support been added?  Does it just add too much overhead 
for those who don't need it?

(bump)

Jim Bosch

From marco.selinger at yahoo.de  Sat Jul 17 09:05:21 2010
From: marco.selinger at yahoo.de (Marco Selinger)
Date: Sat, 17 Jul 2010 07:05:21 +0000 (GMT)
Subject: [C++-sig] reuse C++ classes that have been wrapped with SWIG
In-Reply-To: <230639.25094.qm@web111411.mail.gq1.yahoo.com>
References: <65706.17933.qm@web24902.mail.ird.yahoo.com>
	<230639.25094.qm@web111411.mail.gq1.yahoo.com>
Message-ID: <258048.77082.qm@web24903.mail.ird.yahoo.com>

Dear Ralf,
thank you for the links. Unfortunately I don't get the point. Where is the swig 
interface defined? Where is the boost.python module defined?
What is the key idea how the two python wrappers are linked together?

If you or somebody else could briefly outline these steps in english text (not 
only program code), I'd highly appreciate it.

Thanks
Marco




________________________________
Von: Ralf W. Grosse-Kunstleve <rwgk at yahoo.com>
An: Development of Python/C++ integration <cplusplus-sig at python.org>
Gesendet: Donnerstag, den 15. Juli 2010, 19:48:13 Uhr
Betreff: Re: [C++-sig] reuse C++ classes that have been wrapped with SWIG

Yes, should be possible, although I haven't tried it in a long time, but here 
are 

some old files that may still work:

http://cctbx.svn.sourceforge.net/viewvc/cctbx/trunk/boost_adaptbx/

swig_arg.hpp
swig_args_ext.cpp
tests/tst_swig_args.py
SConscript

In the SConscript look for "swig".
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig at python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20100717/e76f443c/attachment-0001.html>

From j.reid at mail.cryst.bbk.ac.uk  Sat Jul 17 11:17:12 2010
From: j.reid at mail.cryst.bbk.ac.uk (John Reid)
Date: Sat, 17 Jul 2010 10:17:12 +0100
Subject: [C++-sig] Pickle python subclass of C++ interface
Message-ID: <i1rseo$4va$1@dough.gmane.org>

Hi,

I'm using boost.python. I want to pickle some python subclasses of a C++ 
base. The C++ base does not have any state, it is just an interface. Is 
there an easy way to ask the python pickling machinery to ignore the C++ 
base? I'm not sure if I should use the boost.python pickling support or 
go directly down the route described at
http://docs.python.org/library/pickle.html#pickling-and-unpickling-extension-types

Thanks,
John.


From s_sourceforge at nedprod.com  Sat Jul 17 16:18:29 2010
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 17 Jul 2010 15:18:29 +0100
Subject: [C++-sig] [patch] Make boost python accessible by multiple
	threads
In-Reply-To: <AANLkTinMlKfDqK171ktAYCjQZdAo8HKgN4lUbOm429vs@mail.gmail.com>
References: <AANLkTinMlKfDqK171ktAYCjQZdAo8HKgN4lUbOm429vs@mail.gmail.com>
Message-ID: <4C41BBB5.28776.8E19E72@s_sourceforge.nedprod.com>

On 16 Jul 2010 at 13:38, Charles Solar wrote:

> I mentioned it before but I have this patch for boost python that adds
> code to lock and unlock the gil at all the boundaries I have found
> between python and boost python.  This makes it so multiple threads
> can call into python without the user having to lock and unlock the
> gil themselves.  I am pretty sure this is a very much desired feature
> but I guess the developers are waiting for a head start, so here is
> the patch file that can be applied to the boost trunk or any of the
> 1.4x versions of boost python.  I would very much like to see the
> patch correctly worked into boost python so I no longer have to
> maintain it myself.

Thanks for posting this patch. I promised someone on here some months 
ago I'd do a proper version of this patch based on static upcalls 
thinking that the then upcoming MSVC10 had support for variadic 
templates. Unfortunately, it doesn't and hence I have found it all 
too easy to make excuses to leave it till later until when it does.

> I have been using this in my application for a few months now and I am
> fairly confident in its completeness when NOT embedding python
> interpreters.  There may be more entry points I have missed because I
> do not embed python in my app, therefore I would say this patch is
> only non-embedded systems.

I see that you based your patch on my original patch. My original 
patch DID support embedding, but there was a lot of TnFOX-specific 
stuff in there to achieve it. If I remember rightly, it was a bit of 
a hornet's nest :)

Cheers,
Niall
-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 
472909.




From s_sourceforge at nedprod.com  Sat Jul 17 16:18:29 2010
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 17 Jul 2010 15:18:29 +0100
Subject: [C++-sig] [patch] Make boost python accessible by multiple
	threads
In-Reply-To: <4C40B417.5010904@gmail.com>
References: <AANLkTinMlKfDqK171ktAYCjQZdAo8HKgN4lUbOm429vs@mail.gmail.com>,
	<4C40B417.5010904@gmail.com>
Message-ID: <4C41BBB5.541.8E19DE6@s_sourceforge.nedprod.com>

On 16 Jul 2010 at 12:33, Jim Bosch wrote:

> But I don't know much more than this, and I'm also curious to hear the 
> story told by someone who has more information...why hasn't 
> multithreading support been added?  Does it just add too much overhead 
> for those who don't need it?

Atomic exchange instructions are a very precious commodity on modern 
systems and become ever more precious over time. Wherever possible 
atomic exchange instructions ought to be avoided for the benefit of 
the whole system.

Besides, one of the big problems with a "naive" threading support 
implementation such as the one just posted is that there are loads of 
occasions (e.g. when checking for an overload of a virtual function) 
when you unlock, do less than 100 cycles of work which doesn't need 
the unlock and relock. That's crazy, and it hammers performance 
across your entire system.

What was discussed on here many months ago was a simple "hanging 
lock" system which avoids the problem above. It will however also 
require source code changes to code using Boost.Python, but wrapper 
generators like Py++ would take most of the pain.

The problem, as always, is funding the time of those to implement a 
proper solution which would pass muster under peer review. The na?ve 
implementation is not suitable for mainline, and I agree it should be 
kept out until it's done properly. Annoyingly you could probably get 
a full and proper implementation for just ~US$7-8k as it's a feature 
most Boost developers would feel very favourably toward.

HTH,
Niall

-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 
472909.




From rwgk at yahoo.com  Sat Jul 17 18:32:07 2010
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sat, 17 Jul 2010 09:32:07 -0700 (PDT)
Subject: [C++-sig] Pickle python subclass of C++ interface
In-Reply-To: <i1rseo$4va$1@dough.gmane.org>
References: <i1rseo$4va$1@dough.gmane.org>
Message-ID: <865918.50804.qm@web111401.mail.gq1.yahoo.com>

I think all you need to do is add
  .enable_pickling()
to your Boost.Python wrapper and
  def __getinitargs__(self):
    return (x,y,z)
to your subclass.
You could also use __getstate__, __setstate__, but I'd try to work with
just __getinitargs__ first.

See also:

http://www.boost.org/doc/libs/1_43_0/libs/python/doc/v2/pickle.html


----- Original Message ----

From: John Reid <j.reid at mail.cryst.bbk.ac.uk>
To: cplusplus-sig at python.org
Sent: Sat, July 17, 2010 2:17:12 AM
Subject: [C++-sig] Pickle python subclass of C++ interface

Hi,

I'm using boost.python. I want to pickle some python subclasses of a C++ base. 
The C++ base does not have any state, it is just an interface. Is there an easy 
way to ask the python pickling machinery to ignore the C++ base? I'm not sure if 
I should use the boost.python pickling support or go directly down the route 
described at
http://docs.python.org/library/pickle.html#pickling-and-unpickling-extension-types


Thanks,
John.

_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig at python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig


From j.reid at mail.cryst.bbk.ac.uk  Sat Jul 17 19:17:48 2010
From: j.reid at mail.cryst.bbk.ac.uk (John Reid)
Date: Sat, 17 Jul 2010 18:17:48 +0100
Subject: [C++-sig] Pickle python subclass of C++ interface
In-Reply-To: <865918.50804.qm@web111401.mail.gq1.yahoo.com>
References: <i1rseo$4va$1@dough.gmane.org>
	<865918.50804.qm@web111401.mail.gq1.yahoo.com>
Message-ID: <i1sojs$ti8$1@dough.gmane.org>

Ralf W. Grosse-Kunstleve wrote:
> I think all you need to do is add
>   .enable_pickling()
> to your Boost.Python wrapper and
>   def __getinitargs__(self):
>     return (x,y,z)
> to your subclass.
> You could also use __getstate__, __setstate__, but I'd try to work with
> just __getinitargs__ first.
> 
> See also:
> 
> http://www.boost.org/doc/libs/1_43_0/libs/python/doc/v2/pickle.html

Ok I'll give that a whirl. I was hoping to avoid doing __getinitargs__() 
for each subclass as I have quite a few of them. If I didn't have a C++ 
base class then the pickling would just work as is. There's no way I can 
get back to that sort of situation with the C++ base class is there?

Thanks,
John.




> 
> 
> ----- Original Message ----
> 
> From: John Reid <j.reid at mail.cryst.bbk.ac.uk>
> To: cplusplus-sig at python.org
> Sent: Sat, July 17, 2010 2:17:12 AM
> Subject: [C++-sig] Pickle python subclass of C++ interface
> 
> Hi,
> 
> I'm using boost.python. I want to pickle some python subclasses of a C++ base. 
> The C++ base does not have any state, it is just an interface. Is there an easy 
> way to ask the python pickling machinery to ignore the C++ base? I'm not sure if 
> I should use the boost.python pickling support or go directly down the route 
> described at
> http://docs.python.org/library/pickle.html#pickling-and-unpickling-extension-types
> 
> 
> Thanks,
> John.
> 
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig


From rwgk at yahoo.com  Sat Jul 17 23:38:43 2010
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Sat, 17 Jul 2010 14:38:43 -0700 (PDT)
Subject: [C++-sig] Pickle python subclass of C++ interface
In-Reply-To: <i1sojs$ti8$1@dough.gmane.org>
References: <i1rseo$4va$1@dough.gmane.org>
	<865918.50804.qm@web111401.mail.gq1.yahoo.com>
	<i1sojs$ti8$1@dough.gmane.org>
Message-ID: <955324.54239.qm@web111416.mail.gq1.yahoo.com>

> Ok I'll give that a whirl. I was hoping to avoid doing __getinitargs__()
> for each subclass as I have quite a few of them. If I didn't have a C++
> base class then the pickling would just work as is. There's no way I
> can get back to that sort of situation with the C++ base class is there?

I don't know, but there may be. One (totally untested) idea would be to
give the base class __getstate__ and __setstate__ methods that inspect the
instance to re/store the state. Maybe you just need to return and restore
self.__dict__?
I guess you could mix-in the __getstate__, __setstate__ methods.

Ralf

From j.reid at mail.cryst.bbk.ac.uk  Sun Jul 18 11:16:29 2010
From: j.reid at mail.cryst.bbk.ac.uk (John Reid)
Date: Sun, 18 Jul 2010 10:16:29 +0100
Subject: [C++-sig] Pickle python subclass of C++ interface
In-Reply-To: <955324.54239.qm@web111416.mail.gq1.yahoo.com>
References: <i1rseo$4va$1@dough.gmane.org>	<865918.50804.qm@web111401.mail.gq1.yahoo.com>	<i1sojs$ti8$1@dough.gmane.org>
	<955324.54239.qm@web111416.mail.gq1.yahoo.com>
Message-ID: <i1ugpd$skv$1@dough.gmane.org>



Ralf W. Grosse-Kunstleve wrote:
>> Ok I'll give that a whirl. I was hoping to avoid doing __getinitargs__()
>> for each subclass as I have quite a few of them. If I didn't have a C++
>> base class then the pickling would just work as is. There's no way I
>> can get back to that sort of situation with the C++ base class is there?
> 
> I don't know, but there may be. One (totally untested) idea would be to
> give the base class __getstate__ and __setstate__ methods that inspect the
> instance to re/store the state. Maybe you just need to return and restore
> self.__dict__?
> I guess you could mix-in the __getstate__, __setstate__ methods.
> 
> Ralf


I'm not sure what you mean by mix-in, but my first attempt involved 
defining pickle suite getstate() and setstate() methods. I did not 
define a getinitargs() method. Unfortunately when the derived object was 
unpickled, __init__ was called with no arguments. As far as I can see 
there's no way to use the boost.python pickle suite that does not 
involve a call to __init__() on the unpickled object.

I'll try having a go using the python pickling protocol's __reduce__() 
method.

John.


From j.reid at mail.cryst.bbk.ac.uk  Sun Jul 18 17:09:40 2010
From: j.reid at mail.cryst.bbk.ac.uk (John Reid)
Date: Sun, 18 Jul 2010 16:09:40 +0100
Subject: [C++-sig] Pickle python subclass of C++ interface
In-Reply-To: <i1ugpd$skv$1@dough.gmane.org>
References: <i1rseo$4va$1@dough.gmane.org>	<865918.50804.qm@web111401.mail.gq1.yahoo.com>	<i1sojs$ti8$1@dough.gmane.org>	<955324.54239.qm@web111416.mail.gq1.yahoo.com>
	<i1ugpd$skv$1@dough.gmane.org>
Message-ID: <i1v5fk$k01$1@dough.gmane.org>

John Reid wrote:
> 
> 
> Ralf W. Grosse-Kunstleve wrote:
>>> Ok I'll give that a whirl. I was hoping to avoid doing __getinitargs__()
>>> for each subclass as I have quite a few of them. If I didn't have a C++
>>> base class then the pickling would just work as is. There's no way I
>>> can get back to that sort of situation with the C++ base class is there?
>>
>> I don't know, but there may be. One (totally untested) idea would be to
>> give the base class __getstate__ and __setstate__ methods that inspect 
>> the
>> instance to re/store the state. Maybe you just need to return and restore
>> self.__dict__?
>> I guess you could mix-in the __getstate__, __setstate__ methods.
>>
>> Ralf
> 
> 
> I'm not sure what you mean by mix-in, but my first attempt involved 
> defining pickle suite getstate() and setstate() methods. I did not 
> define a getinitargs() method. Unfortunately when the derived object was 
> unpickled, __init__ was called with no arguments. As far as I can see 
> there's no way to use the boost.python pickle suite that does not 
> involve a call to __init__() on the unpickled object.
> 
> I'll try having a go using the python pickling protocol's __reduce__() 
> method.

Ok this seems to work by injecting a __reduce__() method into the C++ 
base class. Here ext is the extension module and A is the C++ base class:


import ext, cPickle, logging, copy_reg

def __newobj__(cls, *args):
     return cls.__new__(cls, *args)

def __reduce__(self):
     return (
         __newobj__,
         (self.__class__,),
         self.__dict__
     )
ext.A.__reduce__ = __reduce__

class Derived(ext.A):
     def __init__(self, init_arg):
         self.data = init_arg

derived = Derived(1)
pickled_repr = cPickle.dumps(derived)
unpickled = cPickle.loads(pickled_repr)
assert unpickled.data == derived.data



John.


From hans_meine at gmx.net  Mon Jul 19 10:55:49 2010
From: hans_meine at gmx.net (Hans Meine)
Date: Mon, 19 Jul 2010 10:55:49 +0200
Subject: [C++-sig] reuse C++ classes that have been wrapped with SWIG
In-Reply-To: <65706.17933.qm@web24902.mail.ird.yahoo.com>
References: <65706.17933.qm@web24902.mail.ird.yahoo.com>
Message-ID: <201007191055.50115.hans_meine@gmx.net>

On Thursday 15 July 2010 13:35:55 Marco Selinger wrote:
> There is a complete SWIG wrapper for the OpenCV
> (http://opencv.willowgarage.com) project.
> 
> I am developing a small image processing application that uses some of the
> OpenCV classes. This application will be wrapped using Boost.Python.
> How do I declare those classes in Boost.Python that have already been
> wrapped with SWIG?

For all these questions (involving SIP/SWIG/BPL/...), remember that they're 
all based on the common Python/C API.  Thus, each of these wrapping libraries 
have means to convert from/to python, i.e. wrapping a C++ object pointer into 
a (PyObject *) and vice versa.  One just needs to know how this is done with 
each of the above, and depending on the lifetime management.

Additionally, you should *not* "declare those classes in Boost.Python" again, 
i.e. using class_<...>.  (That would lead to incompatible wrappers.)  Instead, 
you *may* define a manual converter to make your life easier, i.e. let 
boost::python wrap your functions and automatically call SWIGs wrap/unwrap 
functions for the corresponding OpenCV classes.  (The alternative is to 
declare your functions with (PyObject *) pointers and manually call these SWIG 
functions, which is probably easier if you have just one or two functions to 
wrap.)

HTH from an overview point,
  Hans

From Matthew.Scouten at tradingtechnologies.com  Mon Jul 19 16:40:20 2010
From: Matthew.Scouten at tradingtechnologies.com (Matthew Scouten (TT))
Date: Mon, 19 Jul 2010 09:40:20 -0500
Subject: [C++-sig] [patch] Make boost python accessible by
	multiplethreads
In-Reply-To: <4C41BBB5.541.8E19DE6@s_sourceforge.nedprod.com>
References: <AANLkTinMlKfDqK171ktAYCjQZdAo8HKgN4lUbOm429vs@mail.gmail.com>,
	<4C40B417.5010904@gmail.com>
	<4C41BBB5.541.8E19DE6@s_sourceforge.nedprod.com>
Message-ID: <32490DFF7774554A85D65D23A9F0F9380D793A71@chiex01>

I agree that automatic GIL Management should not go main line unless it is done right. 

I would like some facilities for manual GIL management though.

I have a RAII object for taking the GIL around a virtual function, and another for freeing the GIL around a call in. Something like that would be nice to put in the library. I can donate mine if asked...  

-----Original Message-----
From: cplusplus-sig-bounces+matthew.scouten=tradingtechnologies.com at python.org [mailto:cplusplus-sig-bounces+matthew.scouten=tradingtechnologies.com at python.org] On Behalf Of Niall Douglas
Sent: Saturday, July 17, 2010 9:18 AM
To: Development of Python/C++ integration
Subject: Re: [C++-sig] [patch] Make boost python accessible by multiplethreads

On 16 Jul 2010 at 12:33, Jim Bosch wrote:

> But I don't know much more than this, and I'm also curious to hear the 
> story told by someone who has more information...why hasn't 
> multithreading support been added?  Does it just add too much overhead 
> for those who don't need it?

Atomic exchange instructions are a very precious commodity on modern 
systems and become ever more precious over time. Wherever possible 
atomic exchange instructions ought to be avoided for the benefit of 
the whole system.

Besides, one of the big problems with a "naive" threading support 
implementation such as the one just posted is that there are loads of 
occasions (e.g. when checking for an overload of a virtual function) 
when you unlock, do less than 100 cycles of work which doesn't need 
the unlock and relock. That's crazy, and it hammers performance 
across your entire system.

What was discussed on here many months ago was a simple "hanging 
lock" system which avoids the problem above. It will however also 
require source code changes to code using Boost.Python, but wrapper 
generators like Py++ would take most of the pain.

The problem, as always, is funding the time of those to implement a 
proper solution which would pass muster under peer review. The na?ve 
implementation is not suitable for mainline, and I agree it should be 
kept out until it's done properly. Annoyingly you could probably get 
a full and proper implementation for just ~US$7-8k as it's a feature 
most Boost developers would feel very favourably toward.

HTH,
Niall

-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 
472909.



_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig at python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

From j.reid at mail.cryst.bbk.ac.uk  Mon Jul 19 22:38:54 2010
From: j.reid at mail.cryst.bbk.ac.uk (John Reid)
Date: Mon, 19 Jul 2010 21:38:54 +0100
Subject: [C++-sig] Pickle python subclass of C++ interface
In-Reply-To: <i1v5fk$k01$1@dough.gmane.org>
References: <i1rseo$4va$1@dough.gmane.org>	<865918.50804.qm@web111401.mail.gq1.yahoo.com>	<i1sojs$ti8$1@dough.gmane.org>	<955324.54239.qm@web111416.mail.gq1.yahoo.com>	<i1ugpd$skv$1@dough.gmane.org>
	<i1v5fk$k01$1@dough.gmane.org>
Message-ID: <i22d4u$84h$1@dough.gmane.org>

John Reid wrote:
> John Reid wrote:
>>
>>
>> Ralf W. Grosse-Kunstleve wrote:
>>>> Ok I'll give that a whirl. I was hoping to avoid doing 
>>>> __getinitargs__()
>>>> for each subclass as I have quite a few of them. If I didn't have a C++
>>>> base class then the pickling would just work as is. There's no way I
>>>> can get back to that sort of situation with the C++ base class is 
>>>> there?
>>>
>>> I don't know, but there may be. One (totally untested) idea would be to
>>> give the base class __getstate__ and __setstate__ methods that 
>>> inspect the
>>> instance to re/store the state. Maybe you just need to return and 
>>> restore
>>> self.__dict__?
>>> I guess you could mix-in the __getstate__, __setstate__ methods.
>>>
>>> Ralf
>>
>>
>> I'm not sure what you mean by mix-in, but my first attempt involved 
>> defining pickle suite getstate() and setstate() methods. I did not 
>> define a getinitargs() method. Unfortunately when the derived object 
>> was unpickled, __init__ was called with no arguments. As far as I can 
>> see there's no way to use the boost.python pickle suite that does not 
>> involve a call to __init__() on the unpickled object.
>>
>> I'll try having a go using the python pickling protocol's __reduce__() 
>> method.
> 
> Ok this seems to work by injecting a __reduce__() method into the C++ 
> base class. Here ext is the extension module and A is the C++ base class:
> 
> 
> import ext, cPickle, logging, copy_reg
> 
> def __newobj__(cls, *args):
>     return cls.__new__(cls, *args)
> 
> def __reduce__(self):
>     return (
>         __newobj__,
>         (self.__class__,),
>         self.__dict__
>     )
> ext.A.__reduce__ = __reduce__
> 
> class Derived(ext.A):
>     def __init__(self, init_arg):
>         self.data = init_arg
> 
> derived = Derived(1)
> pickled_repr = cPickle.dumps(derived)
> unpickled = cPickle.loads(pickled_repr)
> assert unpickled.data == derived.data
> 
OK it seems I was a bit optimistic. When I pass an unpickled object back 
to C++, I get this error:

Boost.Python.ArgumentError: Python argument types in
     ext.method_that_takes_A(Derived)
did not match C++ signature:
     method_that_takes_A(A)

Does anyone have any ideas why my solution doesn't work when I try to 
pass an unpickled object back to C++? I guess I need to learn a bit more 
about how __new__() works.



> 
> 
> John.


From j.reid at mail.cryst.bbk.ac.uk  Mon Jul 19 23:05:29 2010
From: j.reid at mail.cryst.bbk.ac.uk (John Reid)
Date: Mon, 19 Jul 2010 22:05:29 +0100
Subject: [C++-sig] Pickle python subclass of C++ interface
In-Reply-To: <i22d4u$84h$1@dough.gmane.org>
References: <i1rseo$4va$1@dough.gmane.org>	<865918.50804.qm@web111401.mail.gq1.yahoo.com>	<i1sojs$ti8$1@dough.gmane.org>	<955324.54239.qm@web111416.mail.gq1.yahoo.com>	<i1ugpd$skv$1@dough.gmane.org>	<i1v5fk$k01$1@dough.gmane.org>
	<i22d4u$84h$1@dough.gmane.org>
Message-ID: <i22emp$e7o$1@dough.gmane.org>



John Reid wrote:
> John Reid wrote:
>> John Reid wrote:
>>>
>>>
>>> Ralf W. Grosse-Kunstleve wrote:
>>>>> Ok I'll give that a whirl. I was hoping to avoid doing 
>>>>> __getinitargs__()
>>>>> for each subclass as I have quite a few of them. If I didn't have a 
>>>>> C++
>>>>> base class then the pickling would just work as is. There's no way I
>>>>> can get back to that sort of situation with the C++ base class is 
>>>>> there?
>>>>
>>>> I don't know, but there may be. One (totally untested) idea would be to
>>>> give the base class __getstate__ and __setstate__ methods that 
>>>> inspect the
>>>> instance to re/store the state. Maybe you just need to return and 
>>>> restore
>>>> self.__dict__?
>>>> I guess you could mix-in the __getstate__, __setstate__ methods.
>>>>
>>>> Ralf
>>>
>>>
>>> I'm not sure what you mean by mix-in, but my first attempt involved 
>>> defining pickle suite getstate() and setstate() methods. I did not 
>>> define a getinitargs() method. Unfortunately when the derived object 
>>> was unpickled, __init__ was called with no arguments. As far as I can 
>>> see there's no way to use the boost.python pickle suite that does not 
>>> involve a call to __init__() on the unpickled object.
>>>
>>> I'll try having a go using the python pickling protocol's 
>>> __reduce__() method.
>>
>> Ok this seems to work by injecting a __reduce__() method into the C++ 
>> base class. Here ext is the extension module and A is the C++ base class:
>>
>>
>> import ext, cPickle, logging, copy_reg
>>
>> def __newobj__(cls, *args):
>>     return cls.__new__(cls, *args)
>>
>> def __reduce__(self):
>>     return (
>>         __newobj__,
>>         (self.__class__,),
>>         self.__dict__
>>     )
>> ext.A.__reduce__ = __reduce__
>>
>> class Derived(ext.A):
>>     def __init__(self, init_arg):
>>         self.data = init_arg
>>
>> derived = Derived(1)
>> pickled_repr = cPickle.dumps(derived)
>> unpickled = cPickle.loads(pickled_repr)
>> assert unpickled.data == derived.data
>>
> OK it seems I was a bit optimistic. When I pass an unpickled object back 
> to C++, I get this error:
> 
> Boost.Python.ArgumentError: Python argument types in
>     ext.method_that_takes_A(Derived)
> did not match C++ signature:
>     method_that_takes_A(A)
> 
> Does anyone have any ideas why my solution doesn't work when I try to 
> pass an unpickled object back to C++? I guess I need to learn a bit more 
> about how __new__() works.
> 
> 
Changing

def __newobj__(cls, *args):
      return cls.__new__(cls, *args)

to

def __newobj__(cls, *args):
     obj = cls.__new__(cls, *args)
     ext.A.__init__(obj)
     return obj

seems to have done the trick.


From filipemscampos at yahoo.com.br  Tue Jul 20 03:59:47 2010
From: filipemscampos at yahoo.com.br (Filipe M. S. de Campos)
Date: Mon, 19 Jul 2010 22:59:47 -0300
Subject: [C++-sig] [Boost.Python] Problems to make a wrapper of a OpenCV
	program
Message-ID: <AANLkTinGqSiPflKwu7Ija8wh9ufg8iWGk5tHp5BBA8RC@mail.gmail.com>

Hello!

I've been searching during the last few days a way to solve the problem I'm
having, but I can't find the apropriate answer. I hope somebody can help me.

I have written a program in C++ that uses the opencv library. It is
compiling and working fine.
(I use this to compile the code: gcc -o foo foo.c
-I/usr/local/include/opencv -L/usr/local/lib -lcxcore -lcv -lml -lhighgui
-lcvaux)

Last week, I started to write a wrapper to use this program with another one
written in python. To do that, I am using Boost.Python. I followed the Boost
tutorial and it is working fine with the examples that came with it.
The problem happens when I try to use bjam with my first program that uses
opencv.
At first, it complained about the includes... To solve that, I modified the
requirements section of the Jamroot to:

# Set up the project-wide requirements that everything uses the
# boost_python library from the project whose global ID is
# /boost/python.
project
  : requirements <library>/boost/python//boost_python
                 <include>/usr/local/include/opencv ;

This solved the first problem, but now, when using the bjam command, I
receive that message:

darwin.link.dll bin/darwin-4.2.1/debug/abreJanela_ext.so
Undefined symbols:
  "_cvSetZero", referenced from:
      abreJanela()     in abreJanela.o
  "_cvNamedWindow", referenced from:
      abreJanela()     in abreJanela.o
  "_cvCreateImage", referenced from:
      abreJanela()     in abreJanela.o
  "_cvShowImage", referenced from:
      abreJanela()     in abreJanela.o
ld: symbol(s) not found


What is the correct way to configure bjam or Jamroot (or another thing) to
have my wrapper compiled sucessfully?



Regards

(I'm on a macosx 10.6.4, opencv 2.1, bjam 3.1.18 and boost 1_43_0)
-----
Filipe Morgado Sim?es de Campos


www.amodindin.com.br
www.bitabit.eng.br
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20100719/e92c1c72/attachment.html>

From marco.selinger at yahoo.de  Tue Jul 20 09:31:48 2010
From: marco.selinger at yahoo.de (Marco Selinger)
Date: Tue, 20 Jul 2010 00:31:48 -0700 (PDT)
Subject: [C++-sig] reuse C++ classes that have been wrapped with SWIG
In-Reply-To: <201007191055.50115.hans_meine@gmx.net>
References: <65706.17933.qm@web24902.mail.ird.yahoo.com>
	<201007191055.50115.hans_meine@gmx.net>
Message-ID: <386036.66077.qm@web24917.mail.ird.yahoo.com>

Dear Hans,
your explanations are very helpful.

Now it is obvious that I should not redeclare the opencv classes in boost.python 
after they have been wrapped with swig. But still I did not think about it in 
the right way.

You write:
>Instead, you *may* define a manual converter to make your life easier, i.e. let 

>boost::python wrap your functions and automatically call SWIGs wrap/unwrap 
>functions for the corresponding OpenCV classes.
Do you have some example, how this can be achieved? Do I need to do some text 
processing or parsing of the swig output to find out which (un)wrap functions to 
call? I have never worked on the internals of swig, so that I wouldn't know 
where to find those (un)wrappers.

Thanks
Marco


________________________________
Von: Hans Meine <hans_meine at gmx.net>
An: Development of Python/C++ integration <cplusplus-sig at python.org>
Gesendet: Montag, den 19. Juli 2010, 10:55:49 Uhr
Betreff: Re: [C++-sig] reuse C++ classes that have been wrapped with SWIG

On Thursday 15 July 2010 13:35:55 Marco Selinger wrote:
> There is a complete SWIG wrapper for the OpenCV
> (http://opencv.willowgarage.com) project.
> 
> I am developing a small image processing application that uses some of the
> OpenCV classes. This application will be wrapped using Boost.Python.
> How do I declare those classes in Boost.Python that have already been
> wrapped with SWIG?

For all these questions (involving SIP/SWIG/BPL/...), remember that they're 
all based on the common Python/C API.  Thus, each of these wrapping libraries 
have means to convert from/to python, i.e. wrapping a C++ object pointer into 
a (PyObject *) and vice versa.  One just needs to know how this is done with 
each of the above, and depending on the lifetime management.

Additionally, you should *not* "declare those classes in Boost.Python" again, 
i.e. using class_<...>.  (That would lead to incompatible wrappers.)  Instead, 
you *may* define a manual converter to make your life easier, i.e. let 
boost::python wrap your functions and automatically call SWIGs wrap/unwrap 
functions for the corresponding OpenCV classes.  (The alternative is to 
declare your functions with (PyObject *) pointers and manually call these SWIG 
functions, which is probably easier if you have just one or two functions to 
wrap.)

HTH from an overview point,
  Hans
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig at python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig





From hans_meine at gmx.net  Tue Jul 20 09:37:16 2010
From: hans_meine at gmx.net (Hans Meine)
Date: Tue, 20 Jul 2010 09:37:16 +0200
Subject: [C++-sig] Pickle python subclass of C++ interface
In-Reply-To: <i1ugpd$skv$1@dough.gmane.org>
References: <i1rseo$4va$1@dough.gmane.org>
	<955324.54239.qm@web111416.mail.gq1.yahoo.com>
	<i1ugpd$skv$1@dough.gmane.org>
Message-ID: <201007200937.31088.hans_meine@gmx.net>

On Sunday 18 July 2010 11:16:29 John Reid wrote:
> I'm not sure what you mean by mix-in, but my first attempt involved
> defining pickle suite getstate() and setstate() methods. I did not
> define a getinitargs() method. Unfortunately when the derived object was
> unpickled, __init__ was called with no arguments. As far as I can see
> there's no way to use the boost.python pickle suite that does not
> involve a call to __init__() on the unpickled object.

How should it work?  A proper object of a BPL extension type needs a wrapped 
C++ object "behind it".  Thus, if you unpickle such an object, the 
corresponding C++ object needs to be created.

There's the difference between pure python and BPL classes: with pure Python, 
you (or the pickle module) may just assign __class__, restore all attributes 
and be done.  For C++ objects OTOH, pickle cannot list or restore the 
attributes, or make sure that the object is in any defined state.  So you 
*need* to call a constructor, which may need arguments, hence the 
getinitargs().

In the __reduce__ hack within your last mail, you explicitly call __init__ 
with a single self arg, relying on a default constructible class, and relying 
on the fact that the C++ object will be in the same state as before.  (That's 
probably fine, since you originally wrote that you're dealing with interfaces 
w/o state, but I wanted to point it out again for the unwary readers.)

Have a nice day,
  Hans

From hans_meine at gmx.net  Tue Jul 20 09:46:18 2010
From: hans_meine at gmx.net (Hans Meine)
Date: Tue, 20 Jul 2010 09:46:18 +0200
Subject: [C++-sig] reuse C++ classes that have been wrapped with SWIG
In-Reply-To: <386036.66077.qm@web24917.mail.ird.yahoo.com>
References: <65706.17933.qm@web24902.mail.ird.yahoo.com>
	<201007191055.50115.hans_meine@gmx.net>
	<386036.66077.qm@web24917.mail.ird.yahoo.com>
Message-ID: <201007200946.19315.hans_meine@gmx.net>

Hi Marco!

On Tuesday 20 July 2010 09:31:48 Marco Selinger wrote:
> Do you have some example, how this can be achieved? Do I need to do some
> text processing or parsing of the swig output to find out which (un)wrap
> functions to call? I have never worked on the internals of swig, so that I
> wouldn't know where to find those (un)wrappers.

Sorry, I don't have the time to search myself, but this has been discussed on 
the list before.  You may use keywords like "swig boost::python register 
converter" or "lvalue converter".

For example, this was my first hit and looks perfect for one direction (from 
python) at least:

http://wiki.python.org/moin/boost.python/HowTo#SWIGexposedC.2B-.2B-
objectfromPython

I have done the same with SIP only, but I have no experience with SWIG.

HTH,
  Hans

From David.Aldrich at EU.NEC.COM  Tue Jul 20 13:26:18 2010
From: David.Aldrich at EU.NEC.COM (David Aldrich)
Date: Tue, 20 Jul 2010 12:26:18 +0100
Subject: [C++-sig] Wanted: Examples of boost.python embedded usage
Message-ID: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A382D@EUEXCLU01.EU.NEC.COM>

Hi

I am new to boost.python ( and to Python ) and need to demonstrate embedding Python code in a C++ application.

I would like to pass data to a Python function from C++ and retrieve the result.

Please can anyone suggest a tutorial that would show me how to do this please?

Best regards

David

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

From j.reid at mail.cryst.bbk.ac.uk  Tue Jul 20 13:43:40 2010
From: j.reid at mail.cryst.bbk.ac.uk (John Reid)
Date: Tue, 20 Jul 2010 12:43:40 +0100
Subject: [C++-sig] Pickle python subclass of C++ interface
In-Reply-To: <201007200937.31088.hans_meine@gmx.net>
References: <i1rseo$4va$1@dough.gmane.org>	<955324.54239.qm@web111416.mail.gq1.yahoo.com>	<i1ugpd$skv$1@dough.gmane.org>
	<201007200937.31088.hans_meine@gmx.net>
Message-ID: <i2425d$rlq$1@dough.gmane.org>

Hans Meine wrote:
> On Sunday 18 July 2010 11:16:29 John Reid wrote:
>> I'm not sure what you mean by mix-in, but my first attempt involved
>> defining pickle suite getstate() and setstate() methods. I did not
>> define a getinitargs() method. Unfortunately when the derived object was
>> unpickled, __init__ was called with no arguments. As far as I can see
>> there's no way to use the boost.python pickle suite that does not
>> involve a call to __init__() on the unpickled object.
> 
> How should it work?  A proper object of a BPL extension type needs a wrapped 
> C++ object "behind it".  Thus, if you unpickle such an object, the 
> corresponding C++ object needs to be created.
> 
> There's the difference between pure python and BPL classes: with pure Python, 
> you (or the pickle module) may just assign __class__, restore all attributes 
> and be done.  For C++ objects OTOH, pickle cannot list or restore the 
> attributes, or make sure that the object is in any defined state.  So you 
> *need* to call a constructor, which may need arguments, hence the 
> getinitargs().
> 
> In the __reduce__ hack within your last mail, you explicitly call __init__ 
> with a single self arg, relying on a default constructible class, and relying 
> on the fact that the C++ object will be in the same state as before.  (That's 
> probably fine, since you originally wrote that you're dealing with interfaces 
> w/o state, but I wanted to point it out again for the unwary readers.)
> 

Thanks for the clarification, that all makes sense.

I was hoping that I could make all the sub-classes picklable without 
recoding a getinitargs() for each one. I think I've managed that by 
using __reduce__(). I don't think I can do that using the boost.python 
pickle suite.

I can see why you call my method a 'hack' but I think it is fine for my 
purposes.

Thanks,
John.


From pj at nexplore.ch  Tue Jul 20 13:40:33 2010
From: pj at nexplore.ch (Philip Jonientz - NEXPLORE AG)
Date: Tue, 20 Jul 2010 11:40:33 +0000
Subject: [C++-sig] Wanted: Examples of boost.python embedded usage
In-Reply-To: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A382D@EUEXCLU01.EU.NEC.COM>
References: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A382D@EUEXCLU01.EU.NEC.COM>
Message-ID: <6EE3FC70E2CECE45834E05359BCE7349039CB0@BRUTUS.nexplore.ch>

Hi there

http://ironalbatross.net/wiki/index.php5/CPP_BOOST_STACKLESS_PYTHON
This one is actually with stackless python, but he's using the same boost.python you would use with standart cpython.
If you skip the whole setting up part for linux there are some samples on how to create function wrappers and so on...
This tutorial really helped me(Even if this is stackless python I think it might help you too).

Greetings

Phil

Von: cplusplus-sig-bounces+pj=nexplore.ch at python.org [mailto:cplusplus-sig-bounces+pj=nexplore.ch at python.org] Im Auftrag von David Aldrich
Gesendet: Dienstag, 20. Juli 2010 13:26
An: cplusplus-sig at python.org
Betreff: [C++-sig] Wanted: Examples of boost.python embedded usage

Hi

I am new to boost.python ( and to Python ) and need to demonstrate embedding Python code in a C++ application.

I would like to pass data to a Python function from C++ and retrieve the result.

Please can anyone suggest a tutorial that would show me how to do this please?

Best regards

David

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

From David.Aldrich at EU.NEC.COM  Tue Jul 20 14:48:35 2010
From: David.Aldrich at EU.NEC.COM (David Aldrich)
Date: Tue, 20 Jul 2010 13:48:35 +0100
Subject: [C++-sig] Wanted: Examples of boost.python embedded usage
In-Reply-To: <6EE3FC70E2CECE45834E05359BCE7349039CB0@BRUTUS.nexplore.ch>
References: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A382D@EUEXCLU01.EU.NEC.COM>
	<6EE3FC70E2CECE45834E05359BCE7349039CB0@BRUTUS.nexplore.ch>
Message-ID: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3841@EUEXCLU01.EU.NEC.COM>

Hi Phil,

Thanks, I will take a look.

Best regards

David


From: cplusplus-sig-bounces+david.aldrich=eu.nec.com at python.org [mailto:cplusplus-sig-bounces+david.aldrich=eu.nec.com at python.org] On Behalf Of Philip Jonientz - NEXPLORE AG
Sent: 20 July 2010 12:41
To: Development of Python/C++ integration
Subject: Re: [C++-sig] Wanted: Examples of boost.python embedded usage

Hi there

http://ironalbatross.net/wiki/index.php5/CPP_BOOST_STACKLESS_PYTHON
This one is actually with stackless python, but he's using the same boost.python you would use with standart cpython.
If you skip the whole setting up part for linux there are some samples on how to create function wrappers and so on...
This tutorial really helped me(Even if this is stackless python I think it might help you too).

Greetings

Phil

Von: cplusplus-sig-bounces+pj=nexplore.ch at python.org [mailto:cplusplus-sig-bounces+pj=nexplore.ch at python.org] Im Auftrag von David Aldrich
Gesendet: Dienstag, 20. Juli 2010 13:26
An: cplusplus-sig at python.org
Betreff: [C++-sig] Wanted: Examples of boost.python embedded usage

Hi

I am new to boost.python ( and to Python ) and need to demonstrate embedding Python code in a C++ application.

I would like to pass data to a Python function from C++ and retrieve the result.

Please can anyone suggest a tutorial that would show me how to do this please?

Best regards

David



Click here<https://www.mailcontrol.com/sr/RpbHqa6Adt!TndxI!oX7UvLs8dGn3uonMbI37h43g+exlmqk+Q7X0J7KzLJ+gHHxkcffdYN8DZlaXEW7R1X!lw==> to report this email as spam.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20100720/ffd48b55/attachment-0001.html>

From s_sourceforge at nedprod.com  Wed Jul 21 15:02:28 2010
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Wed, 21 Jul 2010 14:02:28 +0100
Subject: [C++-sig] [patch] Make boost python accessible by
	multiplethreads
In-Reply-To: <32490DFF7774554A85D65D23A9F0F9380D793A71@chiex01>
References: <AANLkTinMlKfDqK171ktAYCjQZdAo8HKgN4lUbOm429vs@mail.gmail.com>,
	<4C41BBB5.541.8E19DE6@s_sourceforge.nedprod.com>,
	<32490DFF7774554A85D65D23A9F0F9380D793A71@chiex01>
Message-ID: <4C46EFE4.4866.1D359181@s_sourceforge.nedprod.com>

On 19 Jul 2010 at 9:40, Matthew Scouten (TT) wrote:

> I agree that automatic GIL Management should not go main line unless it
> is done right. 
> 
> I would like some facilities for manual GIL management though.
> 
> I have a RAII object for taking the GIL around a virtual function, and
> another for freeing the GIL around a call in. Something like that would
> be nice to put in the library. I can donate mine if asked...  

Sorry for the delay in replying. Stuff came up.

I would have no objections so long as any such code would be marked 
as deprecated and that it will be removed in the future.

To explain why, proper threading support with hanging locks would be 
incompatible with a na?ve RAII GIL management object. Also, if I 
remember correctly there is additional work required to get multiple 
embedded interpreters to correctly work simultaneously, and again a 
simple RAII style GIL management isn't quite enough. In particular, 
if I remember correctly, the context for the current interpreter for 
this thread must be managed separately from the GIL for a particular 
interpreter, especially if the two interpreters are calling into one 
another via intervening C++ code but still accessing data in both 
simultaneously.

HTH,
Niall

-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 
472909.




From mk.subscribe at gmail.com  Thu Jul 22 03:02:44 2010
From: mk.subscribe at gmail.com (Kiramin (Subscriptions))
Date: Wed, 21 Jul 2010 18:02:44 -0700
Subject: [C++-sig] Need help with simple boost embedded python program
Message-ID: <AANLkTinAPsQJaU2zIR04gQhnW-P03p5l0kj-F4REPcvO@mail.gmail.com>

I can't seem to get this to work:
This little program just embeds python, creates a module using boost, and
attempts to add it to the list of built-in modules.

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

char const* greet()
{
   return "hello, world";
}

BOOST_PYTHON_MODULE(hello)
{
    def("greet", greet);
}

int main()
{
PyImport_AppendInittab("hello", inithello);
Py_Initialize();
return 0;
}
//-------------------------------------------------------

But when I attempt to build using bjam, I get:

-------------------------------------------------------
...found 1629 targets...
...updating 3 targets...
compile-c-c++ bin\msvc-10.0\debug\threading-multi\BoostPy3DEngine.obj
BoostPy3DEngine.cpp
BoostPy3DEngine.cpp(17) : error C2065: 'inithello' : undeclared identifier

    call "C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"
x86 >nul
cl /Zm800 -nologo
@"bin\msvc-10.0\debug\threading-multi\BoostPy3DEngine.obj.rsp"

...failed compile-c-c++
bin\msvc-10.0\debug\threading-multi\BoostPy3DEngine.obj...
...skipped <pbin\msvc-10.0\debug\threading-multi>BoostPy3DEngine.exe for
lack of
 <pbin\msvc-10.0\debug\threading-multi>BoostPy3DEngine.obj...
...skipped <pbin\msvc-10.0\debug\threading-multi>BoostPy3DEngine.pdb for
lack of
 <pbin\msvc-10.0\debug\threading-multi>BoostPy3DEngine.obj...
...failed updating 1 target...
...skipped 2 targets...
-------------------------------------------------------

My understanding is that the BOOST_PYTHON_MODULE macro is supposed to create
the inithello function when it builds the hello module... but the compiler
doesn't seem to be able to find it.

The above code compiles without complaint if I leave out the line:
PyImport_AppendInittab("hello", inithello);

I am using bjam with the --toolset=msvc switch (its the only way I know how
to build with boost).  And I have MSVC version 10.0.30319.1 installed, and
this is a Windows XP machine.

Anyone know what might be causing the above error?

Thanks for any help you can give!

-Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20100721/b4a09d2c/attachment.html>

From merlin66b at gmail.com  Thu Jul 22 15:06:24 2010
From: merlin66b at gmail.com (Thomas Berg)
Date: Thu, 22 Jul 2010 15:06:24 +0200
Subject: [C++-sig] Need help with simple boost embedded python program
In-Reply-To: <AANLkTinAPsQJaU2zIR04gQhnW-P03p5l0kj-F4REPcvO@mail.gmail.com>
References: <AANLkTinAPsQJaU2zIR04gQhnW-P03p5l0kj-F4REPcvO@mail.gmail.com>
Message-ID: <AANLkTilUbgSpTMZV1N5q0GWPMW2ED0B0ajICqApfxF9L@mail.gmail.com>

On Thu, Jul 22, 2010 at 3:02 AM, Kiramin (Subscriptions)
<mk.subscribe at gmail.com> wrote:
> I can't seem to get this to work:
> This little program just embeds python, creates a module using boost, and
> attempts to add it to the list of built-in modules.
> //-------------------------------------------------------
> #include <boost/python.hpp>
> using namespace boost::python;
> char const* greet()
> {
> ?? return "hello, world";
> }
> BOOST_PYTHON_MODULE(hello)
> {
> ?? ?def("greet", greet);
> }
> int main()
> {
> PyImport_AppendInittab("hello", inithello);
> Py_Initialize();
> return 0;
> }
> //-------------------------------------------------------
> But when I attempt to build using bjam, I get:
> -------------------------------------------------------
> ...found 1629 targets...
> ...updating 3 targets...
> compile-c-c++ bin\msvc-10.0\debug\threading-multi\BoostPy3DEngine.obj
> BoostPy3DEngine.cpp
> BoostPy3DEngine.cpp(17) : error C2065: 'inithello' : undeclared identifier
> ?? ?call "C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"
[...]
> Anyone know what might be causing the above error?
> Thanks for any help you can give!
> -Mike

FWIW, your code builds just fine here, with Visual Studio 8.0 and
boost 1.43. Maybe it's a Visual Studio 10.0 specific problem? Also, I
do not use bjam. Your code looks fine at least.

Thomas

From David.Aldrich at EU.NEC.COM  Thu Jul 22 15:50:53 2010
From: David.Aldrich at EU.NEC.COM (David Aldrich)
Date: Thu, 22 Jul 2010 14:50:53 +0100
Subject: [C++-sig] Need help with simple boost embedded python program
In-Reply-To: <AANLkTinAPsQJaU2zIR04gQhnW-P03p5l0kj-F4REPcvO@mail.gmail.com>
References: <AANLkTinAPsQJaU2zIR04gQhnW-P03p5l0kj-F4REPcvO@mail.gmail.com>
Message-ID: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A39C3@EUEXCLU01.EU.NEC.COM>

I'm new to boost.python so am just a beginner. But I built boost.python with bjam and then built my C++ application with MSVC 2008 (not bjam). Worked fine.

David

From: cplusplus-sig-bounces+david.aldrich=eu.nec.com at python.org [mailto:cplusplus-sig-bounces+david.aldrich=eu.nec.com at python.org] On Behalf Of Kiramin (Subscriptions)
Sent: 22 July 2010 02:03
To: cplusplus-sig at python.org
Subject: [C++-sig] Need help with simple boost embedded python program

I can't seem to get this to work:
This little program just embeds python, creates a module using boost, and attempts to add it to the list of built-in modules.

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

char const* greet()
{
   return "hello, world";
}

BOOST_PYTHON_MODULE(hello)
{
    def("greet", greet);
}

int main()
{
          PyImport_AppendInittab("hello", inithello);
          Py_Initialize();
          return 0;
}
//-------------------------------------------------------

But when I attempt to build using bjam, I get:

-------------------------------------------------------
...found 1629 targets...
...updating 3 targets...
compile-c-c++ bin\msvc-10.0\debug\threading-multi\BoostPy3DEngine.obj
BoostPy3DEngine.cpp
BoostPy3DEngine.cpp(17) : error C2065: 'inithello' : undeclared identifier

    call "C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 >nul
cl /Zm800 -nologo @"bin\msvc-10.0\debug\threading-multi\BoostPy3DEngine.obj.rsp"

...failed compile-c-c++ bin\msvc-10.0\debug\threading-multi\BoostPy3DEngine.obj...
...skipped <pbin\msvc-10.0\debug\threading-multi>BoostPy3DEngine.exe for lack of
 <pbin\msvc-10.0\debug\threading-multi>BoostPy3DEngine.obj...
...skipped <pbin\msvc-10.0\debug\threading-multi>BoostPy3DEngine.pdb for lack of
 <pbin\msvc-10.0\debug\threading-multi>BoostPy3DEngine.obj...
...failed updating 1 target...
...skipped 2 targets...
-------------------------------------------------------

My understanding is that the BOOST_PYTHON_MODULE macro is supposed to create the inithello function when it builds the hello module... but the compiler doesn't seem to be able to find it.

The above code compiles without complaint if I leave out the line:
PyImport_AppendInittab("hello", inithello);

I am using bjam with the --toolset=msvc switch (its the only way I know how to build with boost).  And I have MSVC version 10.0.30319.1 installed, and this is a Windows XP machine.

Anyone know what might be causing the above error?

Thanks for any help you can give!

-Mike


Click here<https://www.mailcontrol.com/sr/PLJy!+rMVeHTndxI!oX7UqMEQvnfkQd8IoSZeSiUao33IuUnm05pATKrPOVDpyxkMZUh17DZ8VVhUYCj!eKynw==> to report this email as spam.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20100722/7abb86c8/attachment.html>

From David.Aldrich at EU.NEC.COM  Thu Jul 22 15:57:04 2010
From: David.Aldrich at EU.NEC.COM (David Aldrich)
Date: Thu, 22 Jul 2010 14:57:04 +0100
Subject: [C++-sig] Help needed with simple boost.python exception handler
Message-ID: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A39C5@EUEXCLU01.EU.NEC.COM>

Hi

I want to add a simple exception handler to my boost.python application. I want it to print a simple message to the console, indicating the nature of the error.

I have seen:

try {
    ...
} catch ( error_already_set ) {
    PyErr_Print();
}

But is there a better solution using a boost.python method instead of  PyErr_Print() ?

Or, can I do something like the following?

catch ( const error_already_set& e ) {
    cout << e.what();
}

Best regards

David


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

From talljimbo at gmail.com  Fri Jul 23 09:08:01 2010
From: talljimbo at gmail.com (Jim Bosch)
Date: Fri, 23 Jul 2010 00:08:01 -0700
Subject: [C++-sig] dynamic linking in Linux
Message-ID: <4C493FD1.3040703@gmail.com>

I've just run into the "wontfix" problem detailed here:

https://svn.boost.org/trac/boost/ticket/3210

Essentially, shared information held in one module (such as RTTI stuff 
needed for dynamic cast) isn't available to another module, leading to 
segfaults.

I got the impression from reading the ticket comments and the linked 
email threads that the best solution is to do something like this, where 
module "B" depends on module "A":

liba.so ---- C++ objects for A and Boost.Python wrappers.

a.so ------- module, linked against liba.so, just invokes wrapper 
generator functions defined in liba.so within a BOOST_PYTHON_MODULE block.

libb.so ---- C++ objects for B and Boost.Python wrappers; linked against 
liba.so

b.so ------- module, linked against libb.so and liba.so, just invokes 
wrapper generator functions defined in libb.so within a 
BOOST_PYTHON_MODULE block


However, that's not working, and the only solution I've found is to put 
my modules in packages with something like the following in __init__.py:

import ctypes
ctypes.PyDLL("%s/_a" % tuple(__path__), ctypes.RTLD_GLOBAL)
from . import _a

Another similar option, using sys.setdlopenflags, seems to be less 
favored because the dl module needed to get the flags has been 
deprecated in Python itself.

Is this just the current state of things?  Are there any efforts 
underway to improve matters?  Or was I on track in the first case, and I 
was just doing it wrong?

Thanks!

Jim Bosch

From s_sourceforge at nedprod.com  Fri Jul 23 15:35:28 2010
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 23 Jul 2010 14:35:28 +0100
Subject: [C++-sig] dynamic linking in Linux
In-Reply-To: <4C493FD1.3040703@gmail.com>
References: <4C493FD1.3040703@gmail.com>
Message-ID: <4C499AA0.30923.27A080AD@s_sourceforge.nedprod.com>

On 23 Jul 2010 at 0:08, Jim Bosch wrote:

> I've just run into the "wontfix" problem detailed here:
> 
> https://svn.boost.org/trac/boost/ticket/3210
> 
> Essentially, shared information held in one module (such as RTTI stuff 
> needed for dynamic cast) isn't available to another module, leading to 
> segfaults.
> [snip]
> Another similar option, using sys.setdlopenflags, seems to be less 
> favored because the dl module needed to get the flags has been 
> deprecated in Python itself.
> 
> Is this just the current state of things?  Are there any efforts 
> underway to improve matters?  Or was I on track in the first case, and I 
> was just doing it wrong?

I am sorry to hear that this is STILL a problem so many years later 
(it was a change I submitted to GCC back in 2005 which created this 
problem). My advice then as it is now is to change the default 
dlopenflags to RTLD_GLOBAL across the Python language - it is the 
only sane choice. I would even go so far as to say that RTLD_LOCAL 
needs deprecating in GNU libc.

If you search Google for "dlopenflags python" you will see tales of 
woe and misoperation going back eight years now. My view is that 
Guido should simply impose RTLD_GLOBAL on Python and if people's 
extension modules break then they should be excluded from the core 
build until they are fixed.

Laziness is bad enough anywhere in the world, but laziness which 
wastes productivity for hundreds, perhaps thousands of busy and time 
valuable people is inexcusable. This problem has been allowed to 
fester for far too long, and it particularly annoys me because it is 
very easy to fix.

Sorry for your particular woes, and I do apologise for my part in 
causing them.

Niall

-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 
472909.




From seefeld at sympatico.ca  Fri Jul 23 15:49:10 2010
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Fri, 23 Jul 2010 09:49:10 -0400
Subject: [C++-sig] dynamic linking in Linux
In-Reply-To: <4C499AA0.30923.27A080AD@s_sourceforge.nedprod.com>
References: <4C493FD1.3040703@gmail.com>
	<4C499AA0.30923.27A080AD@s_sourceforge.nedprod.com>
Message-ID: <4C499DD6.8070300@sympatico.ca>

  On 07/23/2010 09:35 AM, Niall Douglas wrote:
> I would even go so far as to say that RTLD_LOCAL
> needs deprecating in GNU libc.

That would open the door for all sorts of ABI issues (symbol collisions 
resulting in the wrong objects being looked up, etc.).
I don't think making symbols visible globally will solve anything.

     Stefan

-- 

       ...ich hab' noch einen Koffer in Berlin...


From s_sourceforge at nedprod.com  Fri Jul 23 20:37:50 2010
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 23 Jul 2010 19:37:50 +0100
Subject: [C++-sig] dynamic linking in Linux
In-Reply-To: <4C499DD6.8070300@sympatico.ca>
References: <4C493FD1.3040703@gmail.com>,
	<4C499AA0.30923.27A080AD@s_sourceforge.nedprod.com>,
	<4C499DD6.8070300@sympatico.ca>
Message-ID: <4C49E17E.16539.28B55256@s_sourceforge.nedprod.com>

On 23 Jul 2010 at 9:49, Stefan Seefeld wrote:

>   On 07/23/2010 09:35 AM, Niall Douglas wrote:
> > I would even go so far as to say that RTLD_LOCAL
> > needs deprecating in GNU libc.
> 
> That would open the door for all sorts of ABI issues (symbol collisions 
> resulting in the wrong objects being looked up, etc.).
> I don't think making symbols visible globally will solve anything.

No, all that's happening with RTLD_LOCAL is that symbol collisions 
are being HIDDEN from view when a properly maintained ABI ought to 
explicitly hide all symbols not absolutely necessary from an external 
use perspective. Failure to correctly do this is programmer laziness 
as I said.

It took Microsoft well over a decade of MSVCRT instance conflicts 
before someone forced the default to be the DLL rather than static 
link in MSVC7.1 - countless millions of dollars of wasted 
productivity happened in the intervening time while people made 
statements like the one you just made. I am not criticising you 
personally Stefen, this response is extremely common in the 
Unix/POSIX community. Unfortunately it's just plain wrong.

As I said back in 2005, and many, many times since, programmers need 
to be forced to get off their lazy arses and fix the plain out broken 
and lazy ABI management endemic in the GCC-based ecosystem. The tools 
(-fvisibility and __attribute__(visibility())) have been there since 
GCC 4.0. Unless major projects such as Python simply force the issue 
nothing is going to happen.

I for one was extremely disappointed to see Python 3.x baulk yet 
again on the default for dlopenflags. But I'm tired of ranting about 
it. Maybe we might have more success in getting GCC to make the 
default -fvisibility=hidden, then we might get some traction at last.

Niall

-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 
472909.




From talljimbo at gmail.com  Fri Jul 23 22:56:59 2010
From: talljimbo at gmail.com (Jim Bosch)
Date: Fri, 23 Jul 2010 13:56:59 -0700
Subject: [C++-sig] dynamic linking in Linux
In-Reply-To: <4C493FD1.3040703@gmail.com>
References: <4C493FD1.3040703@gmail.com>
Message-ID: <4C4A021B.7040407@gmail.com>

On 07/23/2010 12:08 AM, Jim Bosch wrote:
> I've just run into the "wontfix" problem detailed here:
>
> https://svn.boost.org/trac/boost/ticket/3210
>
> Essentially, shared information held in one module (such as RTTI stuff
> needed for dynamic cast) isn't available to another module, leading to
> segfaults.

<snip>

An update: apparently, I'm not experiencing the garden-variety version 
of this problem.  Using setdlopenflags *doesn't* actually fix it (and 
neither does the similar ctypes method); it was just intermittent, and 
happened to work twice after I added the ctypes trick.  And it appears 
to only happens when pickling a Python builtin (dict, in my case) that 
contains a wrapped C++ object.  It doesn't matter whether I use pickle 
or cPickle.

Given that many people (including myself) have pickled Boost.Python 
objects inside dicts many times before without issue, it might be tricky 
to make a contained example that reproduces it this problem.  And I'm 
less motivated now because I can just skip pickling the object in this 
case and move on with my life...

But if anyone has any new ideas on where to look, it does seem like 
mysterious behavior that would be nice to track down.

Jim

From lutz.maibaum at gmail.com  Sat Jul 24 00:09:53 2010
From: lutz.maibaum at gmail.com (Lutz Maibaum)
Date: Fri, 23 Jul 2010 15:09:53 -0700
Subject: [C++-sig] How to derive from an abstract base class
Message-ID: <BA5B5E0B-75CD-4F0F-831B-5418E16E156F@gmail.com>

Dear all,

I am totally new to Boost.Python, and I am going through the tutorial to get up to speed. I apologize if this is a very obvious question.

Imagine I have a base class in C++ that I want to derive from both in C++ and in Python. The following code works wonderfully well:

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

class Base {
public:
  virtual int f() {return -1;}
};
class Derived : public Base {
public:
  int f() {return 1;}
};
class BaseWrap : public Base, public wrapper<Base> {
public:
  int f() {
    if (override f = this->get_override("f"))
      return f();
    return Base::f();
  }
  int default_f() {return this->Base::f();}
};

int func(Base& b) {
  return b.f();
}

BOOST_PYTHON_MODULE(foo) {
  class_<Base> ("Base");
  class_<Derived, bases<Base> > ("Derived")
    .def("f", &Derived::f);
  class_<BaseWrap, boost::noncopyable>("Base")
    .def("f", &Base::f, &BaseWrap::default_f);
  def("func", func, "Calls the method f of its argument");
}


With this code, I can do the following:

>>> import foo
>>> d1=foo.Derived()
>>> class D(foo.Base):
...     def f(self): return 2
... 
>>> d2=D()
>>> foo.func(d1)
1
>>> foo.func(d2)
2


So far so good. Now I would like to make Base::f a pure virtual function, and I can't get it to work.

1. Attempt: 

class Base {
public:
  virtual int f() = 0;
};
class Derived : public Base {
public:
  int f() {return 1;}
};
class BaseWrap : public Base, public wrapper<Base> {
public:
  int f() {return this->get_override("f")();}
};

int func(Base& b) {
  return b.f();
}

BOOST_PYTHON_MODULE(foo) {
  class_<Derived, bases<Base> > ("Derived")
    .def("f", &Derived::f);
  class_<BaseWrap, boost::noncopyable>("Base")
    .def("f", pure_virtual(&Base::f));
  def("func", func, "Calls the method f of its argument");
}

This compiles, but when I try to import the resulting module I get he following error message:

RuntimeError: extension class wrapper for base class Base has not been created yet

This makes sense, because the Python side doesn't now about the abstract  C++ class Base yet. Therefore?

2. Attempt:

I change the wrapping code to the following:

BOOST_PYTHON_MODULE(foo) {
  class_<Derived> ("Derived")
    .def("f", &Derived::f);
  class_<BaseWrap, boost::noncopyable>("Base")
    .def("f", pure_virtual(&Base::f));
  def("func", func, "Calls the method f of its argument");
}

Again this compiles, but I cannot call the c++ function func with the C++ class Derived anymore:

>>> import foo
>>> d1=foo.Derived()
>>> foo.func(d1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
Boost.Python.ArgumentError: Python argument types in
    foo.func(Derived)
did not match C++ signature:
    func(Base {lvalue})

Apparently the Python side doesn't know anymore that the C++ class Derived is derived from Base.

The core of the problem seems to be that I cannot expose the abstract base class Base directly to Python, but only the wrapper class BaseWrap. But then C++ classes derived from Base and Python classes derived from BaseWrap do not have a common ancestor in the class hierarchy.

If anyone could point me in the right direction, it would much appreciated.

Best,

  Lutz




From talljimbo at gmail.com  Sat Jul 24 00:55:39 2010
From: talljimbo at gmail.com (Jim Bosch)
Date: Fri, 23 Jul 2010 15:55:39 -0700
Subject: [C++-sig] How to derive from an abstract base class
In-Reply-To: <BA5B5E0B-75CD-4F0F-831B-5418E16E156F@gmail.com>
References: <BA5B5E0B-75CD-4F0F-831B-5418E16E156F@gmail.com>
Message-ID: <4C4A1DEB.4050403@gmail.com>

On 07/23/2010 03:09 PM, Lutz Maibaum wrote:
> Dear all,
>
> I am totally new to Boost.Python, and I am going through the tutorial to get up to speed. I apologize if this is a very obvious question.
>
<snip>
>
> class Base {
> public:
>    virtual int f() = 0;
> };
> class Derived : public Base {
> public:
>    int f() {return 1;}
> };
> class BaseWrap : public Base, public wrapper<Base>  {
> public:
>    int f() {return this->get_override("f")();}
> };
>
> int func(Base&  b) {
>    return b.f();
> }
>
> BOOST_PYTHON_MODULE(foo) {
>    class_<Derived, bases<Base>  >  ("Derived")
>      .def("f",&Derived::f);
>    class_<BaseWrap, boost::noncopyable>("Base")
>      .def("f", pure_virtual(&Base::f));
>    def("func", func, "Calls the method f of its argument");
> }
>

Try this:

BOOST_PYTHON_MODULE(foo) {
     class_<BaseWrap, boost::noncopyable>("Base")
       .def("f", pure_virtual(&Base::f));
     class_<Derived, bases<Base>  >  ("Derived")
       .def("f",&Derived::f);
     def("func", func, "Calls the method f of its argument");
}

(just swap the order of the class_ statements)


Jim Bosch




From lutz.maibaum at gmail.com  Sat Jul 24 01:19:24 2010
From: lutz.maibaum at gmail.com (Lutz Maibaum)
Date: Fri, 23 Jul 2010 16:19:24 -0700
Subject: [C++-sig] How to derive from an abstract base class
In-Reply-To: <4C4A1DEB.4050403@gmail.com>
References: <BA5B5E0B-75CD-4F0F-831B-5418E16E156F@gmail.com>
	<4C4A1DEB.4050403@gmail.com>
Message-ID: <89F79B6C-16AC-432B-9912-992B94807908@gmail.com>

On Jul 23, 2010, at 3:55 PM, Jim Bosch wrote:
> Try this:
> 
> BOOST_PYTHON_MODULE(foo) {
>    class_<BaseWrap, boost::noncopyable>("Base")
>      .def("f", pure_virtual(&Base::f));
>    class_<Derived, bases<Base>  >  ("Derived")
>      .def("f",&Derived::f);
>    def("func", func, "Calls the method f of its argument");
> }
> 
> (just swap the order of the class_ statements)

Fantastic! That works like charm.

Thank you very much,

  Lutz


From filipemscampos at yahoo.com.br  Sat Jul 24 02:37:23 2010
From: filipemscampos at yahoo.com.br (Filipe M. S. de Campos)
Date: Fri, 23 Jul 2010 21:37:23 -0300
Subject: [C++-sig] Help with Jamroot file
Message-ID: <AANLkTikkVCkg6QLwE_WybmT8qv5poSzJcxfwxg2YoAeY@mail.gmail.com>

Hello!

I'm writing a wrapper of a c++ program that uses
OpenCV<http://opencv.willowgarage.com/wiki/>library. I think I have to
add some information to the Jamroot file to make
bjam import opencv headers and compile the wrapper successfully.
But I couldn't find the right command and location in Jamroot file that I
need to add it. Could somebody help me?

Regards

Filipe Morgado Sim?es de Campos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20100723/033029ed/attachment.html>

From s_sourceforge at nedprod.com  Sat Jul 24 15:27:28 2010
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 24 Jul 2010 14:27:28 +0100
Subject: [C++-sig] dynamic linking in Linux
In-Reply-To: <4C4A021B.7040407@gmail.com>
References: <4C493FD1.3040703@gmail.com>, <4C4A021B.7040407@gmail.com>
Message-ID: <4C4AEA40.20108.2CBF89EB@s_sourceforge.nedprod.com>

On 23 Jul 2010 at 13:56, Jim Bosch wrote:

> Given that many people (including myself) have pickled Boost.Python 
> objects inside dicts many times before without issue, it might be tricky 
> to make a contained example that reproduces it this problem.  And I'm 
> less motivated now because I can just skip pickling the object in this 
> case and move on with my life...
> 
> But if anyone has any new ideas on where to look, it does seem like 
> mysterious behavior that would be nice to track down.

What can happen is that some python loadable modules have implemented 
explicit symbol hiding while others have not - or worse, some parts 
of a python loadable module have a properly shown ABI while other 
parts don't. This can cause symbols to get overridden in a way you 
wouldn't think.

For example, Boost.Python does hide unneccessary parts of its ABI 
because it reuses its MSVC DLL symbol export machinery to do so (I 
contributed the patch myself). If however another library used BPL to 
wrap itself but did NOT use said symbol export machinery then one 
could end up in an inconsistent state depending on basically which 
way the wind is blowing on the day.

Because of these complexities, some - actually many - still feel that 
everything should be made public like it used to be then "it works". 
And indeed this is correct. However, it also takes the runtime 
dynamic linker - which is an O(N^2) beasty - much longer to load your 
executable which for OpenOffice and KDE meant a 60 sec load time back 
in the day. And there is much to be said for the notion that a 
reusable shared object should be responsible enough not to pollute 
the process namespace willy nilly, plus of course there are security 
issues with the more information you expose about the inner layout of 
your binaries.

Basically the ELF shared object format is broken and needs fixing so 
it looks much more like PE's DLL format. But fixing this is years 
away, if ever, so for now we make do ...

HTH,
Niall

-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 
472909.




From rosen.diankov at gmail.com  Mon Jul 26 21:57:09 2010
From: rosen.diankov at gmail.com (Rosen Diankov)
Date: Mon, 26 Jul 2010 15:57:09 -0400
Subject: [C++-sig] docstrings not being interpreted with the correct encoding
Message-ID: <AANLkTim8-axKBhktprn+zCH80me-HxLK0k2-XpD_mDwB@mail.gmail.com>

Hi all,

I'm using epydoc to document the Boost.Python-built shared object.
Everything has been going great except for one minor issue of epydoc
(and probably other documentation tools) not being able to extract the
correct docstring encoding (utf-8 in my case). Let A be a class and
foo be its member function. Then epydoc uses the
"A.foo.im_func.__module__" attribute to get the global module, for
which it extracts the encoding the module has set.

The problem is that A.foo.im_func is a Boost.Python.function object
and does not have any '__module__' attribute. Because epydoc cannot
find the __module__ attribute, it cannot get the correct encoding of
the docstrings, and non-latin characters are turned into garbage. This
is testing with boost python 1.40

thank you,
rosen,

From rwgk at yahoo.com  Mon Jul 26 23:16:51 2010
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Mon, 26 Jul 2010 14:16:51 -0700 (PDT)
Subject: [C++-sig] docstrings not being interpreted with the correct
	encoding
In-Reply-To: <AANLkTim8-axKBhktprn+zCH80me-HxLK0k2-XpD_mDwB@mail.gmail.com>
References: <AANLkTim8-axKBhktprn+zCH80me-HxLK0k2-XpD_mDwB@mail.gmail.com>
Message-ID: <185234.19364.qm@web111405.mail.gq1.yahoo.com>

I'd could review and check in patches for epydoc compatibility (based
on the boost trunk).
Ralf




----- Original Message ----
From: Rosen Diankov <rosen.diankov at gmail.com>
To: cplusplus-sig at python.org
Sent: Mon, July 26, 2010 12:57:09 PM
Subject: [C++-sig] docstrings not being interpreted with the correct encoding

Hi all,

I'm using epydoc to document the Boost.Python-built shared object.
Everything has been going great except for one minor issue of epydoc
(and probably other documentation tools) not being able to extract the
correct docstring encoding (utf-8 in my case). Let A be a class and
foo be its member function. Then epydoc uses the
"A.foo.im_func.__module__" attribute to get the global module, for
which it extracts the encoding the module has set.

The problem is that A.foo.im_func is a Boost.Python.function object
and does not have any '__module__' attribute. Because epydoc cannot
find the __module__ attribute, it cannot get the correct encoding of
the docstrings, and non-latin characters are turned into garbage. This
is testing with boost python 1.40

thank you,
rosen,
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig at python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig


From David.Aldrich at EU.NEC.COM  Thu Jul 29 12:26:35 2010
From: David.Aldrich at EU.NEC.COM (David Aldrich)
Date: Thu, 29 Jul 2010 11:26:35 +0100
Subject: [C++-sig] Can boost_python dll be delay loaded?
Message-ID: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3CFD@EUEXCLU01.EU.NEC.COM>

Hi

I am working on a Windows application that uses boost_python, linked with shared libraries.

I need to store the boost_python dll in a folder other than one in the usual search path (exe folder, System32, search path).  I propose to do this by 'delay loading' the boost_python dll and calling SetDllDirectory() from the application.

So far I haven't got this to work. I have read that some DLLs can't be loaded in this way. Does anyone have experience of delay loading boost_python?

Best regards

David

From s_sourceforge at nedprod.com  Thu Jul 29 12:52:52 2010
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Thu, 29 Jul 2010 11:52:52 +0100
Subject: [C++-sig] Can boost_python dll be delay loaded?
In-Reply-To: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3CFD@EUEXCLU01.EU.NEC.COM>
References: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3CFD@EUEXCLU01.EU.NEC.COM>
Message-ID: <4C515D84.298.45F1E666@s_sourceforge.nedprod.com>

Wouldn't using an embedded manifest to specify a non-default DLL 
location be much easier?

Niall

On 29 Jul 2010 at 11:26, David Aldrich wrote:

> Hi
> 
> I am working on a Windows application that uses boost_python, linked with shared libraries.
> 
> I need to store the boost_python dll in a folder other than one in the usual search path (exe folder, System32, search path).  I propose to do this by 'delay loading' the boost_python dll and calling SetDllDirectory() from the application.
> 
> So far I haven't got this to work. I have read that some DLLs can't be loaded in this way. Does anyone have experience of delay loading boost_python?
> 
> Best regards
> 
> David
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig


-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 
472909.




From David.Aldrich at EU.NEC.COM  Thu Jul 29 13:09:42 2010
From: David.Aldrich at EU.NEC.COM (David Aldrich)
Date: Thu, 29 Jul 2010 12:09:42 +0100
Subject: [C++-sig] Can boost_python dll be delay loaded?
In-Reply-To: <4C515D84.298.45F1E666@s_sourceforge.nedprod.com>
References: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3CFD@EUEXCLU01.EU.NEC.COM>
	<4C515D84.298.45F1E666@s_sourceforge.nedprod.com>
Message-ID: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3D0C@EUEXCLU01.EU.NEC.COM>

Hi Niall

> Wouldn't using an embedded manifest to specify a non-default DLL location be much easier?

Thanks. I am not familiar with how that works. Please can you give me any tips on how to do this?

Best regards

David

From s_sourceforge at nedprod.com  Thu Jul 29 13:35:51 2010
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Thu, 29 Jul 2010 12:35:51 +0100
Subject: [C++-sig] Can boost_python dll be delay loaded?
In-Reply-To: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3D0C@EUEXCLU01.EU.NEC.COM>
References: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3CFD@EUEXCLU01.EU.NEC.COM>,
	<4C515D84.298.45F1E666@s_sourceforge.nedprod.com>,
	<0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3D0C@EUEXCLU01.EU.NEC.COM>
Message-ID: <4C516797.23776.4619412B@s_sourceforge.nedprod.com>

On 29 Jul 2010 at 12:09, David Aldrich wrote:

> > Wouldn't using an embedded manifest to specify a non-default DLL location be much easier?
> 
> Thanks. I am not familiar with how that works. Please can you give me any tips on how to do this?

Searching MSDN or Google would give you all the information you need -
 basically you edit an XML file with the appropriate info. I do 
remember seeing somewhere though that DLL-via-manifest support has 
become deprecated in Windows 7 and onwards due to it causing more 
problems than it solves, and off the top of my head I don't know what 
they're intending to replace it with. That said, there is no reason 
why it would ever cease to function as too much of Microsoft's own 
stuff is heavily dependent on it.

HTH,
Niall

-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 
472909.




From David.Aldrich at EU.NEC.COM  Fri Jul 30 09:22:47 2010
From: David.Aldrich at EU.NEC.COM (David Aldrich)
Date: Fri, 30 Jul 2010 08:22:47 +0100
Subject: [C++-sig] Can boost_python dll be delay loaded?
In-Reply-To: <4C516797.23776.4619412B@s_sourceforge.nedprod.com>
References: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3CFD@EUEXCLU01.EU.NEC.COM>,
	<4C515D84.298.45F1E666@s_sourceforge.nedprod.com>,
	<0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3D0C@EUEXCLU01.EU.NEC.COM>
	<4C516797.23776.4619412B@s_sourceforge.nedprod.com>
Message-ID: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3D56@EUEXCLU01.EU.NEC.COM>

Hi Niall

> > > Wouldn't using an embedded manifest to specify a non-default DLL
> location be much easier?

Thanks for your reply. I have now succeeded in creating a manifest file for an assembly that includes the boost_python dll's. But I don't understand how to specify a non-default location for the assembly using that manifest. I believe this is done using 'probing' in Windows 7 but I think that is unsupported in XP.

So maybe I shall have to use delayed loading after all. Which brings me back to my original question, has anyone succeeded in delay loading boost_python under Visual C++?

Best regards

David

From s_sourceforge at nedprod.com  Fri Jul 30 11:28:25 2010
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 30 Jul 2010 10:28:25 +0100
Subject: [C++-sig] Can boost_python dll be delay loaded?
In-Reply-To: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3D56@EUEXCLU01.EU.NEC.COM>
References: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3CFD@EUEXCLU01.EU.NEC.COM>,
	<4C516797.23776.4619412B@s_sourceforge.nedprod.com>,
	<0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3D56@EUEXCLU01.EU.NEC.COM>
Message-ID: <4C529B39.18504.4B09463@s_sourceforge.nedprod.com>

On 30 Jul 2010 at 8:22, David Aldrich wrote:

> Thanks for your reply. I have now succeeded in creating a manifest file
> for an assembly that includes the boost_python dll's. But I don't
> understand how to specify a non-default location for the assembly using
> that manifest. I believe this is done using 'probing' in Windows 7 but I
> think that is unsupported in XP. 

I thought that the application installer registered the DLL manifests 
at their locations? It's like registering COM or .NET objects, in 
fact I think it's the same mechanism nowadays.

> So maybe I shall have to use delayed loading after all. Which brings me
> back to my original question, has anyone succeeded in delay loading
> boost_python under Visual C++? 

Well, the method you outlined ought to be prevented by the system and 
certainly by any competent anti-virus. It would be ripe for 
exploitation.

As for why it doesn't work when others do, I would guess it's due to 
how the BPL machinery sets itself up on process init. During static 
init the BPL library sets up all sorts of runtime information which 
is later used by BPL clients, and during all of this it is extremely 
important that everything be kept in precisely the right order.

Put another way I would be extremely doubtful that you can delay load 
the BPL library. Your best bet it would seem now is to have PATH 
modified on app install, but that is a very lazy way out and is 
indeed banned in lots of corporate environments. Another alternative 
is that you could hive off all BPL using code into a separate DLL and 
have that delay loaded instead. That ought to work, though you really 
got to wonder at the cost/benefit ratio.

HTH,
Niall

-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 
472909.




From David.Aldrich at EU.NEC.COM  Fri Jul 30 11:56:35 2010
From: David.Aldrich at EU.NEC.COM (David Aldrich)
Date: Fri, 30 Jul 2010 10:56:35 +0100
Subject: [C++-sig] Can boost_python dll be delay loaded?
In-Reply-To: <4C529B39.18504.4B09463@s_sourceforge.nedprod.com>
References: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3CFD@EUEXCLU01.EU.NEC.COM>,
	<4C516797.23776.4619412B@s_sourceforge.nedprod.com>,
	<0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3D56@EUEXCLU01.EU.NEC.COM>
	<4C529B39.18504.4B09463@s_sourceforge.nedprod.com>
Message-ID: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3D81@EUEXCLU01.EU.NEC.COM>

Hi Niall

> I thought that the application installer registered the DLL manifests
> at their locations? It's like registering COM or .NET objects, in
> fact I think it's the same mechanism nowadays.

Well, I don't plan to use an application installer. Most of our users build and run the application from within a svn working copy.

> As for why it doesn't work when others do, I would guess it's due to
> how the BPL machinery sets itself up on process init. During static
> init the BPL library sets up all sorts of runtime information which
> is later used by BPL clients, and during all of this it is extremely
> important that everything be kept in precisely the right order.

I don't understand the intricacies of Boost's initialisation, nor do I even know when it happens. I naively thought that nothing would happen until I explicitly call a boost_python API method. Does the fact that I have included <boost/python.hpp> mean that some boost initialisation will occur before main() is reached?

> Your best bet it would seem now is to have PATH
> modified on app install, but that is a very lazy way out and is
> indeed banned in lots of corporate environments. 

Sadly, I think that is the only solution. Thanks again for your help.

Best regards

David

From s_sourceforge at nedprod.com  Fri Jul 30 17:47:47 2010
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 30 Jul 2010 16:47:47 +0100
Subject: [C++-sig] Can boost_python dll be delay loaded?
In-Reply-To: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3D81@EUEXCLU01.EU.NEC.COM>
References: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3CFD@EUEXCLU01.EU.NEC.COM>,
	<4C529B39.18504.4B09463@s_sourceforge.nedprod.com>,
	<0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3D81@EUEXCLU01.EU.NEC.COM>
Message-ID: <4C52F423.1481.60BE6F0@s_sourceforge.nedprod.com>

On 30 Jul 2010 at 10:56, David Aldrich wrote:

> > I thought that the application installer registered the DLL manifests
> > at their locations? It's like registering COM or .NET objects, in
> > fact I think it's the same mechanism nowadays.
> 
> Well, I don't plan to use an application installer. Most of our users
> build and run the application from within a svn working copy. 

It's usually easy enough to rig up a COM object registration into a 
build system. Surely it would similar for manifest stuff.

> > As for why it doesn't work when others do, I would guess it's due to
> > how the BPL machinery sets itself up on process init. During static
> > init the BPL library sets up all sorts of runtime information which
> > is later used by BPL clients, and during all of this it is extremely
> > important that everything be kept in precisely the right order.
> 
> I don't understand the intricacies of Boost's initialisation, nor do I
> even know when it happens. I naively thought that nothing would happen
> until I explicitly call a boost_python API method. Does the fact that I
> have included <boost/python.hpp> mean that some boost initialisation
> will occur before main() is reached? 

Rather it is when the BPL DLL is loaded into the process that it 
performs its static init which sets up the internal environment ready 
for your client code to call BPL APIs. The BPL DLL, like any complex 
metaprogrammed C++ DLL nowadays, will expect to be initialised before 
main() gets called and would be unlikely to work if main() gets 
called first.

> > Your best bet it would seem now is to have PATH
> > modified on app install, but that is a very lazy way out and is
> > indeed banned in lots of corporate environments. 
> 
> Sadly, I think that is the only solution. Thanks again for your help.

The only other I can think of is putting a symbolic link to the BPL 
DLL in the same directory as the executable. Symbolic links are Vista 
or later only sadly, though you could install Microsoft's Unix 
subsystem on XP and get symbolic links that way :)

HTH,
Niall

-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 
472909.




From David.Aldrich at EU.NEC.COM  Fri Jul 30 18:01:24 2010
From: David.Aldrich at EU.NEC.COM (David Aldrich)
Date: Fri, 30 Jul 2010 17:01:24 +0100
Subject: [C++-sig] Can boost_python dll be delay loaded?
In-Reply-To: <4C52F423.1481.60BE6F0@s_sourceforge.nedprod.com>
References: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3CFD@EUEXCLU01.EU.NEC.COM>,
	<4C529B39.18504.4B09463@s_sourceforge.nedprod.com>,
	<0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3D81@EUEXCLU01.EU.NEC.COM>
	<4C52F423.1481.60BE6F0@s_sourceforge.nedprod.com>
Message-ID: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3F8B44@EUEXCLU01.EU.NEC.COM>

Hi Niall

Thanks again for your answers and help.

Best regards

David

> -----Original Message-----
> From: cplusplus-sig-bounces+david.aldrich=eu.nec.com at python.org
> [mailto:cplusplus-sig-bounces+david.aldrich=eu.nec.com at python.org] On
> Behalf Of Niall Douglas
> Sent: 30 July 2010 16:48
> To: Development of Python/C++ integration
> Subject: Re: [C++-sig] Can boost_python dll be delay loaded?
> 
> On 30 Jul 2010 at 10:56, David Aldrich wrote:
> 
> > > I thought that the application installer registered the DLL manifests
> > > at their locations? It's like registering COM or .NET objects, in
> > > fact I think it's the same mechanism nowadays.
> >
> > Well, I don't plan to use an application installer. Most of our users
> > build and run the application from within a svn working copy.
> 
> It's usually easy enough to rig up a COM object registration into a
> build system. Surely it would similar for manifest stuff.
> 
> > > As for why it doesn't work when others do, I would guess it's due to
> > > how the BPL machinery sets itself up on process init. During static
> > > init the BPL library sets up all sorts of runtime information which
> > > is later used by BPL clients, and during all of this it is extremely
> > > important that everything be kept in precisely the right order.
> >
> > I don't understand the intricacies of Boost's initialisation, nor do I
> > even know when it happens. I naively thought that nothing would happen
> > until I explicitly call a boost_python API method. Does the fact that I
> > have included <boost/python.hpp> mean that some boost initialisation
> > will occur before main() is reached?
> 
> Rather it is when the BPL DLL is loaded into the process that it
> performs its static init which sets up the internal environment ready
> for your client code to call BPL APIs. The BPL DLL, like any complex
> metaprogrammed C++ DLL nowadays, will expect to be initialised before
> main() gets called and would be unlikely to work if main() gets
> called first.
> 
> > > Your best bet it would seem now is to have PATH
> > > modified on app install, but that is a very lazy way out and is
> > > indeed banned in lots of corporate environments.
> >
> > Sadly, I think that is the only solution. Thanks again for your help.
> 
> The only other I can think of is putting a symbolic link to the BPL
> DLL in the same directory as the executable. Symbolic links are Vista
> or later only sadly, though you could install Microsoft's Unix
> subsystem on XP and get symbolic links that way :)
> 
> HTH,
> Niall
> 
> --
> Technology & Consulting Services - ned Productions Limited.
> http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no:
> 472909.
> 
> 
> 
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
> 
> 
>  Click
> https://www.mailcontrol.com/sr/QPy1GWmUWovTndxI!oX7Uqfv98hA5qioKLUaEvLrmgO
> mhsjStaar8uC2P7BlaqMtj6B2UVGAGYT63Umxp4EWgA==  to report this email as
> spam.

From rwgk at yahoo.com  Fri Jul 30 20:38:28 2010
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 30 Jul 2010 11:38:28 -0700 (PDT)
Subject: [C++-sig] Can boost_python dll be delay loaded?
In-Reply-To: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3D81@EUEXCLU01.EU.NEC.COM>
References: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3CFD@EUEXCLU01.EU.NEC.COM>,
	<4C516797.23776.4619412B@s_sourceforge.nedprod.com>,
	<0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3D56@EUEXCLU01.EU.NEC.COM>
	<4C529B39.18504.4B09463@s_sourceforge.nedprod.com>
	<0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3D81@EUEXCLU01.EU.NEC.COM>
Message-ID: <74017.56709.qm@web111404.mail.gq1.yahoo.com>

> Your best bet it would seem now is to have PATH

> modified on app install, but that is a very lazy way out and is
> indeed banned in lots of corporate environments. 

I solved this problem via a small launcher executable. It is just like
a small .bat file which sets PATH and PYTHONPATH before launching the
actual application. Only cmd.exe makes a mess passing through command-line
arguments with spaces, therefore I resorted to this:

http://cctbx.svn.sourceforge.net/viewvc/cctbx/trunk/libtbx/windows_dispatcher.c?revision=11155&view=markup


This is compiled once (windows_dispatcher.exe, in the same svn).
A Python script makes copies and replaces the placeholders for the
path names with the actual path names.

Ralf

From s_sourceforge at nedprod.com  Fri Jul 30 21:37:55 2010
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 30 Jul 2010 20:37:55 +0100
Subject: [C++-sig] Can boost_python dll be delay loaded?
In-Reply-To: <74017.56709.qm@web111404.mail.gq1.yahoo.com>
References: <0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3CFD@EUEXCLU01.EU.NEC.COM>,
	<0CCCA5445D7FCB4298BBF0739D4FDD520254EA3A3D81@EUEXCLU01.EU.NEC.COM>,
	<74017.56709.qm@web111404.mail.gq1.yahoo.com>
Message-ID: <4C532A13.2128.6DE9709@s_sourceforge.nedprod.com>

On 30 Jul 2010 at 11:38, Ralf W. Grosse-Kunstleve wrote:

> > Your best bet it would seem now is to have PATH
> > modified on app install, but that is a very lazy way out and is
> > indeed banned in lots of corporate environments. 
> 
> I solved this problem via a small launcher executable. It is just like
> a small .bat file which sets PATH and PYTHONPATH before launching the
> actual application. Only cmd.exe makes a mess passing through command-line
> arguments with spaces, therefore I resorted to this:

Also, now you make me think about it, Microsoft Detours can inject an 
arbitrary DLL at any given location into a process.

HTH,
Niall

-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 
472909.