Mailman 3 September 2009 - Cplusplus-sig

Trouble optimizing Boost.python integration
by Dan Sanduleac Sept. 8, 2009

Sept. 8, 2009

Hi, I'm trying to compare different python-C wrapping techniques to see which would be faster and also more suited to game development. I'm using Stackless Python 2.6.2 and boost 1.39.0. I implemented a simple Vec3 (3D vector) class in C++ and wrapped it with boost:python. All it does is multiplications and additions, so it implements just two operators. The thing is, it proves to be kind of slow compared to Cython/Pyrex code that does the same. I think it should run faster than Cython code. (Note: Cython is not an abbreviation for C/Python API) I compiled the python library from boost, in release mode, and then linked the vec3 module, provided below, to the compiled boost_python library. (I used -O2 when compiling the vec3 module) The testing goes like this: each "tick", 10000 objects update their position, according to their velocity and timedelta since last "tick", and I'm measuring the average time a tick takes to complete. On my machine doing this with Cython takes ~0.026 sec/tick, while doing it with boost.python takes like 0.052 sec/tick (The overhead introduced by python's iterating through the list of objects each tick is about 0.01 sec) During one tick, for each object, python runs this: "self.position += self.velocity * time_delta", where position and velocity are instances of Vec3. I was hoping for results better than with Cython, by using Boost. Am I doing something wrong? Source code: vec3.cpp ========== #include <boost/python.hpp> using namespace boost::python; class Vec3 { float x, y, z; public: Vec3(float x, float y, float z); Vec3 &operator*=(float scalar); Vec3 operator*(float scalar) const; Vec3 &operator+=(const Vec3 &who); // that `const Vec3` is REALLY needed, unless you want error monsoon to come down }; // === boost:python wrapper === // publish just += and * to python BOOST_PYTHON_MODULE(vec3) { class_<Vec3>("Vec3", init<float, float, float>()) .def(self += self) .def(self * float()) ; } // === implementation === Vec3::Vec3(float x, float y, float z) { this->x = x; this->y = y; this->z = z; } Vec3 & Vec3::operator*=(float scalar) { this->x *= scalar; this->y *= scalar; thiz->z *= scalar;a } Vec3 Vec3::operator*(float scalar) const { return Vec3(*this) *= scalar; } Vec3 & Vec3::operator+=(const Vec3 &who) { this->x += who.x; this->y += who.y; this->z += who.z; return *this; }

4 4

Re: [C++-sig] Your confirmation is required to join the Cplusplus-sig mailing list
by Amruta Chaudhari Sept. 7, 2009

Sept. 7, 2009

cplusplus-sig-confirm+36e1dc99c23a2f349b7576eb72ee1e88429813a6(a)python.org On Mon, Sep 7, 2009 at 2:40 PM, < cplusplus-sig-confirm+36e1dc99c23a2f349b7576eb72ee1e88429813a6(a)python.org<cplusplus-sig-confirm%2B36e1dc99c23a2f349b7576eb72ee1e88429813a6(a)python.org> > wrote: > Mailing list subscription confirmation notice for mailing list > Cplusplus-sig > > We have received a request from 125.18.59.225 for subscription of your > email address, "amruta.rs(a)gmail.com", to the cplusplus-sig(a)python.org > mailing list. To confirm that you want to be added to this mailing > list, simply reply to this message, keeping the Subject: header > intact. Or visit this web page: > > > http://mail.python.org/mailman/confirm/cplusplus-sig/36e1dc99c23a2f349b7576… > > > Or include the following line -- and only the following line -- in a > message to cplusplus-sig-request(a)python.org: > > confirm 36e1dc99c23a2f349b7576eb72ee1e88429813a6 > > Note that simply sending a `reply' to this message should work from > most mail readers, since that usually leaves the Subject: line in the > right form (additional "Re:" text in the Subject: is okay). > > If you do not wish to be subscribed to this list, please simply > disregard this message. If you think you are being maliciously > subscribed to the list, or have any other questions, send them to > cplusplus-sig-owner(a)python.org. >

1 0

get_overload raising cannot convert from 'boost::python::detail::method_result' to 'MMOT::Geometry &'
by Freyr Magnússon Sept. 7, 2009

Sept. 7, 2009

I trying to create an interface wrapper for a class and I get an error: cannot convert from 'boost::python::detail::method_result' to 'MMOT::Geometry &' The code is like this: struct SelectQueryWrap : SelectQuery, wrapper<SelectQuery> { bool queryNodeBefore(QueryContext* context, OctreeNode *node, const AABBox& region) { return this->get_override("queryNodeBefore")(context, node, region); } // removed working members // >>>>>>>>>>>>>>>>>>>>> this failes <<<<<<<<<<<<<<<<<<< Geometry& getGeometry() { return this->get_override("getGeometry")(); } }; Geometry is another wrapped interface which is working fine and is defined like so: struct GeometryWrap : Geometry, wrapper<Geometry> { int intersectNode(const MMOT::AABBox &box) { return this->get_override("intersectNode")(box); } float volume() const { return this->get_override("volume")(); } void prepare() { if (override prepare = this->get_override("prepare")) prepare(); else Geometry::prepare(); } void default_prepare() { this->Geometry::prepare(); } }; I'm a bit lost here. Can't I return a reference to the object or is my wrapping getting too convoluted (well something is wrong anyway)? Any help appreciated. Freyr

2 2

Embending : Expose and Extract a dictionary object To/From C++
by Constant Dupuis Sept. 3, 2009

Sept. 3, 2009

Hi, I would like to expose a dictionary object instanciated in C++ to a Python code, which manipulate the dictoinary. And after extract the resulting modified dictionary back in C++. I try this : try { Py_Initialize(); std::cout << "Hello, World!\n"; dict d; d["Headline"] = "Titre"; object main_module = import("__main__"); object main_namespace = main_module.attr("__dict__"); main_namespace["iptc"] = ptr(&d); object ignored = exec("print('Headline')\n" "print(iptc['Headline'])\n", main_namespace); } catch( error_already_set ) { PyErr_Print(); } And here is hte output : Hello, World! Headline Traceback (most recent call last): File "<string>", line 2, in <module> TypeError: 'NoneType' object is unsubscriptable What did I missed ? Thanks en regards, Constant

3 7

Problem with combined Boost.Python, shared_ptr and enable_shared_from_this
by Catalin Iacob Sept. 3, 2009

Sept. 3, 2009

Hello everybody, We're using Boost.Python to embed an interpreter for our application. We're having trouble with some code that I reduced to the following: -------------------------------------------------------------------- #include <boost/enable_shared_from_this.hpp> #include <boost/shared_ptr.hpp> #include <boost/python.hpp> #include <iostream> using namespace boost; using namespace boost::python; template <typename T> bool are_equal_using_less(const T& x, const T& y) { return (!(x < y)) && (!(y < x)); } template <class T> void hold_python(shared_ptr<T>& x) { x = extract<shared_ptr<T> >(object(x)); } class A : public enable_shared_from_this<A> { public: shared_ptr<A> get_shared_from_this() { return shared_from_this(); } }; int main() { Py_Initialize(); class_<A, shared_ptr<A> >("A") .def("get_shared_from_this", &A::get_shared_from_this) ; shared_ptr<A> a(new A); shared_ptr<A> first_shared_from_this = a->get_shared_from_this(); if (are_equal_using_less(first_shared_from_this, a)) std::cout << "first_shared_from_this is equal to a - OK" << std::endl; else std::cout << "first_shared_from_this is NOT equal to a - BUG" << std::endl; hold_python(a); if (are_equal_using_less(first_shared_from_this, a)) std::cout << "first_shared_from_this is still equal to a" << std::endl; else std::cout << "now first_shared_from_this is not equal to a since a was changed by hold_python - OK I think" << std::endl; shared_ptr<A> second_shared_from_this = a->get_shared_from_this(); if (are_equal_using_less(second_shared_from_this, a)) std::cout << "second_shared_from_this - OK" << std::endl; else std::cout << "we just called shared_from_this on a but we get back a shared_ptr object that is not equal to a - isn't this a BUG?" << std::endl; return 0; } -------------------------------------------------------------------- In both 1.39.0 and 1.40.0 the result is: first_shared_from_this is equal to a - OK now first_shared_from_this is not equal to a since a was changed by hold_python - OK I think we just called shared_from_this on a but we get back a shared_ptr object that is not equal to a - isn't this a BUG? While in 1.34.0 we get: first_shared_from_this is equal to a - OK now first_shared_from_this is not equal to a since a was changed by hold_python - OK I think second_shared_from_this - OK It probably doesn't matter but this is on Windows, with Visual Studio 2005 and Python 2.4. The hold_python function in the code above comes from combining ideas in 2 older threads on this list. At http://mail.python.org/pipermail/cplusplus-sig/2006-January/009671.html my colleague asks how to get a reference to the same Python object rather than having Boost.Python always create a new wrapper (if you read the discussion above notice that it is unfortunately split in 2 threads). One of the answers references a message by David Abrahams here http://mail.python.org/pipermail/cplusplus-sig/2005-April/008537.html. So my colleague chose to call hold_python after the allocation of the object, just like shared_ptr a(new A); hold_python(a) in the example above. This worked for us until upgrading from 1.34 to 1.39. It could very well be that the problem is on our side not in Boost but given that Boost.Python is quite esoteric any help from somebody who has more insight into it is very valuable. Thank you, Catalin

1 0

python extended object to native c++ pointer
by Mark Chandler Sept. 2, 2009

Sept. 2, 2009

Im toying around with the idea to use python as an embedded scripting language for a project im working on and have got most things working. However i cant seem to be able to convert a python extended object back into a native c++ pointer. So this is my class: class CGEGameModeBase { public: virtual void FunctionCall()=0; virtual const char* StringReturn()=0; }; class CGEPYGameMode : public CGEGameModeBase, public boost::python::wrapper<CGEPYGameMode> { public: virtual void FunctionCall() { if (override f = this->get_override("FunctionCall")) f(); } virtual const char* StringReturn() { if (override f = this->get_override("StringReturn")) return f(); return "FAILED TO CALL"; } }; Boost wrapping: BOOST_PYTHON_MODULE(GEGameMode) { class_<CGEGameModeBase, boost::noncopyable>("CGEGameModeBase", no_init); class_<CGEPYGameMode, bases<CGEGameModeBase> >("CGEPYGameMode", no_init) .def("FunctionCall", &CGEPYGameMode::FunctionCall) .def("StringReturn", &CGEPYGameMode::StringReturn); } and the python code: import GEGameMode def Ident(): return "Alpha" def NewGamePlay(): return "NewAlpha" def NewAlpha(): import GEGameMode import GEUtil class Alpha(GEGameMode.CGEPYGameMode): def __init__(self): print "Made new Alpha!" def FunctionCall(self): GEUtil.Msg("This is function test Alpha!") def StringReturn(self): return "This is return test Alpha!" return Alpha() Now i can call the first to functions fine by doing this: const char* ident = extract< const char* >( GetLocalDict()["Ident"]() ); const char* newgameplay = extract< const char* >( GetLocalDict()["NewGamePlay"]() ); printf("Loading Script: %s\n", ident); CGEPYGameMode* m_pGameMode = extract< CGEPYGameMode* >( GetLocalDict()[newgameplay]() ); However when i try and convert the Alpha class back to its base class (last line above) i get an boost error: TypeError: No registered converter was able to extract a C++ pointer to type class CGEPYGameMode from this Python object of type Alpha I have done alot of searching on the net but cant work out how to convert the Alpha object into its base class pointer. I could leave it as an object but rather have it as a pointer so some non python aware code can use it. Any ideas? Better Formatted version: http://stackoverflow.com/questions/1355187/python-object-to-native-c-pointer

2 5

[GSoC] Boost.Python py3k support project final report
by Haoyu Bai Sept. 1, 2009

Sept. 1, 2009

Hi, As GSoC is officially finished, this is the final report of the Boost.Python py3k(Python 3) support project. The goal of this project is to provide seamless support for Python 2 and 3 in Boost.Python. So extension modules using Boost.Python can be easily migrated to Python 3. The SVN branch is located at: https://svn.boost.org/svn/boost/sandbox-branches/bhy/py3k/ Status ===== Currently, all the BPL test cases passed when running under Python 3, and there are almost no change for most of the test cases. To support the Python 3 unicode string, some of the default converts between PyString and C/C++ strings are changed to convert between PyUnicode and C/C++ strings. Support for py3k in Boost.Build is done. Also, a piece of document is written in the "News" part of BPL document. API Changes ========== There are some minor API changes: 1) Introduced object.contains where x.contains(y) is equivalent to Python code y in x. Now dict.has_key is just a wrapper of object.contains. 2) When building against Python 3, str.decode will be removed. 3) When building against Python 3, the original signature of list.sort, which is: void sort(object_cref cmpfunc); will change to: void sort(args_proxy const &args, kwds_proxy const &kwds); This is because in Python 3 list.sort requires all its arguments be keyword argument. So you should call it like this: x.sort(*tuple(), **dict(make_tuple(make_tuple("reverse", true)))); // This is equivalent to the Python call x.sort(reverse=true) 4) When building Boost.Python against Python older than 2.6, the following macros will be defined in Boost.Python header: # define Py_TYPE(o) (((PyObject*)(o))->ob_type) # define Py_REFCNT(o) (((PyObject*)(o))->ob_refcnt) # define Py_SIZE(o) (((PyVarObject*)(o))->ob_size) These are macros defined in Python >=2.6 header. We defined for Python < 2.6 so when you are using Boost.Python, these macros will be always available. Please refer to PEP 3123 (http://www.python.org/dev/peps/pep-3123/) for details about these macro. Building and Testing =============== To build Boost.Python with Python 3, first write your user-config.jam contains these line: using python : 2.6 ; using python : 3.2 ; where the "2.6" and "3.2" should be replaced by the actual version of Python 2 and Python 3 on your system, respectively. Then call "bjam", it will build out a "libboost_python.so" and a "libboost_python3.so". The latter one is the Boost.Python library built against Python 3. To run test cases against Python 3, what you need to do is to switch into the libs/python/test, then run: bjam python=3.2 It will automatically call the "2to3" tool to convert the Python source code in test case to Python 3 syntax. So we only need to maintain the test cases in Python 2. Further Works =========== I'm going to merge the py3k branch back to trunk. After the merge, more tests can be done to check is there any regression, also some people may want to start to use it to make your projects run on Python 3. Then I can get some bug report and feedback, thus more improvement is expected. Thanks! -- Haoyu BAI School of Computing, National University of Singapore.

2 1

ANN: PyBindGen 0.12 released
by Gustavo Carneiro Sept. 1, 2009

Sept. 1, 2009

PyBindGen is a Python module that is geared to generating C/C++ code that binds a C/C++ library for Python. It does so without extensive use of either C++ templates or C pre-processor macros. It has modular handling of C/C++ types, and can be easily extended with Python plugins. The generated code is almost as clean as what a human programmer would write. It can be downloaded from: http://code.google.com/p/pybindgen/ Bug reports should be filed here: https://bugs.launchpad.net/pybindgen === pybindgen 0.12 === - Now we can catch C++ exceptions and translate them into Python - New API to add container iteration powers to wrapped C++ classes - Unary minus operator support (J. Michael Owen) - CppMethod: is_pure_virtual=True should imply is_virtual=True - More polish for numeric operators with non-class right operand - Virtual methods regressions fixed - gccxmlparser: don't try to wrap private/protected operators - MSVC compilation fix - unsigned long type handlers (J. Michael Owen) - tp_len/__len__ works now with overloaded methods (J. Michael Owen) - Add foreign_cpp_namespace option to Function wrappers - Misc. cleanup and bug fixes -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert

1 0