From bogus@does.not.exist.com Tue Oct 14 00:29:20 2008 From: bogus@does.not.exist.com () Date: Mon, 13 Oct 2008 22:29:20 -0000 Subject: No subject Message-ID: "Each compiler is free to choose appropriate sizes for its own hardware, subject only to the restriction that shorts and ints are at least 16 bits, longs are at least 32 bits, and short is no longer than int, which is no longer than long." Everyone may be seated now... Cheers, Dave From bogus@does.not.exist.com Tue Oct 14 00:29:20 2008 From: bogus@does.not.exist.com () Date: Mon, 13 Oct 2008 22:29:20 -0000 Subject: No subject Message-ID: There are some issues. First, you will note EVERY method is defined, add, radd, etc -- even for C++ types you want to define, that aren't numbers of sequences, etc. This really IS a problem, because CPython checks some things by seeing if the subtable pointer is NULL. So a pragmatic solution might, indeed, requires several abstract bases rather than one -- a base for numbers, another for sequences, etc. [But the number is still finite and fixed for all C++ extensions]. The trick in all this is that _constructors_ are not methods. They're ordinary functions that fill out the Python PyObject struct C_Cpp_PyObject: we construct a client C++ object and store the pointer to it in that struct. BTW: here is another solution, abstract in principle, but technically concrete: class Cpp_PyObject { virtual int len() const { throw "Unimplemented Error"; } .. }; -- John Skaller, mailto:skaller at maxtal.com.au 10/1 Toxteth Rd Glebe NSW 2037 Australia homepage: http://www.maxtal.com.au/~skaller voice: 61-2-9660-0850 From bogus@does.not.exist.com Tue Oct 14 00:29:20 2008 From: bogus@does.not.exist.com () Date: Mon, 13 Oct 2008 22:29:20 -0000 Subject: No subject Message-ID: when Python executes the above code, it creates an internal index and successively calls sequence_item(int), incrementing the index as it goes. It would be like an iterator implemented in terms of an index and an accessor function. This is different from COM's approach: internal use of an iterator object supporting Next()-like functions. Is it possible to expose the iteration capability without implementing sequence_item(int)? Your quote above suggests that it's possible, but I can't see how. -- Steven E. Harris Primus Knowledge Solutions, Inc. http://www.primus.com From bogus@does.not.exist.com Tue Oct 14 00:29:20 2008 From: bogus@does.not.exist.com () Date: Mon, 13 Oct 2008 22:29:20 -0000 Subject: No subject Message-ID: eventually when extending Python is that there's no way to make a true Python class in an extension module...Py_cpp solves this problem by taking advantage of Python's metaclass feature to provide objects which look, walk, and hiss almost exactly like regular Python classes." If you need a "class" on which just one or two methods are C functions, let me know after you've read the documentation. That's a use I hadn't thought of for this technology but which is possible without writing new code. I just didn't put a recipe in the documentation. -Dave From lolita86 at libero.it Tue Oct 14 00:29:20 2008 From: lolita86 at libero.it (lolita) Date: Fri, 24 May 2002 00.24.50 +0200 Subject: [C++-sig] Eros e soldi:guadagna con internet 0,08 euro a clic Message-ID: sono lolita, voglio presentarti il mio nuovo sito affiliazione gratuita con guadagni immediati: erotismo, chat,loghi e sonerie etc, etc, l'unico sito che paga cos? tanto 0,08 euro a clic ............................guarda bene la pg di affiliazione............................e buon divertimento. visita il sito: http://members.xoom.it/marym1976 http://members.xoom.it/marym1976 http://members.xoom.it/marym1976 From bogus@does.not.exist.com Tue Oct 14 00:29:20 2008 From: bogus@does.not.exist.com () Date: Mon, 13 Oct 2008 22:29:20 -0000 Subject: No subject Message-ID: module m("pyImageTools").def("foo", &foo); I get: P:\graphics\private\Students\hupp\ITImage\ImageTools\ITWrapper\ITWrapper.cpp(19) : error C2143: syntax error : missing ';' before '.' Last, and probably least, I get a bunch of warnings when compiling. I assume that is normal, but I'll put them at the end of the message just in case it's useful. The test case I'm trying to build is also at the end of the message. Thanks, -Adam #include using namespace boost::python; BOOST_PYTHON_MODULE_INIT(pyImageTools) { module m("pyImageTools"); } And the results... p:\graphics\Tools\boost\boost/python/object/function.hpp(37) : warning C4251: 'm_fn' : class 'boost::function2' needs to h ave dll-interface to be used by clients of struct 'boost::python::objects::function' p:\graphics\Tools\boost\boost/python/type_id.hpp(99) : warning C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning) p:\graphics\Tools\boost\boost/python/type_id.hpp(108) : warning C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning) p:\graphics\Tools\boost\boost/python/instance_holder.hpp(16) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface struct 'boost::python::instance_holder' p:\graphics\Tools\boost\boost/utility.hpp(50) : see declaration of 'noncopyable' p:\graphics\Tools\boost\boost/python/object/class.hpp(27) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface struct 'boost::python::objects::class_base' p:\graphics\Tools\boost\boost/utility.hpp(50) : see declaration of 'noncopyable' p:\graphics\Tools\boost\boost/python/object/class.hpp(43) : warning C4251: 'm_object' : class 'boost::python::reference' needs to have dll-interface to be used by clients of struct 'boost::python::objects::class_base' p:\graphics\Tools\boost\boost/python/converter/callback_to_python_base.hpp(26) : warning C4275: non dll-interface struct 'boost::python::converter::detail::callback_to_python_holder' used as base for dll-interface struct 'boost::python::converter::d etail::callback_to_python_base' p:\graphics\Tools\boost\boost/python/converter/callback_to_python_base.hpp(17) : see declaration of 'callback_to_python_holder' p:\graphics\Tools\boost\boost/python/objects.hpp(32) : warning C4251: 'm_p' : class 'boost::python::reference' needs to have dll-interface to be used by clients of class 'boost::python::object' p:\graphics\Tools\boost\boost/python/objects.hpp(270) : warning C4251: 'm_dict' : class 'boost::python::reference' needs to have dll-interface to be used by clients of struct 'boost::python::dictionary_proxy' p:\graphics\Tools\boost\boost/python/objects.hpp(271) : warning C4251: 'm_key' : class 'boost::python::reference' needs to have dll-interface to be used by clients of struct 'boost::python::dictionary_proxy' p:\graphics\Tools\boost\boost/python/objects.hpp(336) : warning C4251: 'm_list' : class 'boost::python::list' needs to have dll-interface to be used by clients of struct 'boost::python::list_proxy' p:\graphics\Tools\boost\boost/python/objects.hpp(146) : see declaration of 'list' p:\graphics\Tools\boost\boost/python/objects.hpp(351) : warning C4251: 'm_list' : class 'boost::python::reference' needs to have dll-interface to be used by clients of struct 'boost::python::list_slice_proxy' p:\graphics\Tools\boost\boost/python/detail/module_base.hpp(33) : warning C4251: 'm_module' : class 'boost::python::reference' needs to have dll-interface to be used by clients of class 'boost::python::detail::module_base' Linking... Creating library Release/pyImageTools.lib and object Release/pyImageTools.exp ITWrapper.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall boost::python::detail::module_base::~module_base(void)" (__imp_??1module_base at detail@python at boost@@QAE at XZ) ITWrapper.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall boost::python::detail::module_base::module_base(char const *)" (__imp_??0module_base at detail@python at boost@@QAE at PBD@Z) ../../DLLs/pyImageTools.dll : fatal error LNK1120: 2 unresolved externals Error executing link.exe. From bogus@does.not.exist.com Tue Oct 14 00:29:20 2008 From: bogus@does.not.exist.com () Date: Mon, 13 Oct 2008 22:29:20 -0000 Subject: No subject Message-ID: #include #include #include #include using namespace boost::python; class A { public: A() : x(0) {} #if 0 virtual double get() = 0; virtual double get1(double x) = 0; #else double get() { return x; } double get1(double x) { return x; } #endif private: double x; }; class AA : public A { public: AA() : A() {} double get() { return 0; } double get1(double x) { return x; } double get2(double x, double y) { return y+x; } }; BOOST_PYTHON_MODULE_INIT(AA) { module m("AA"); m.add( #if 0 class_("A") #else class_("A") #endif .def("get", &A::get) .def("get1", &A::get1) ); m.add( class_ >("AA") .def_init(args<>()) .def("get2", &AA::get2) ); } Min Xu From bogus@does.not.exist.com Tue Oct 14 00:29:20 2008 From: bogus@does.not.exist.com () Date: Mon, 13 Oct 2008 22:29:20 -0000 Subject: No subject Message-ID: cvs update -P -d -D2002/6/13 boost/preprocessor This will get an earlier version of the preprocessor library that works with VC6. You'll just need to remember to do: cvs update -A boost/preprocessor to get the latest stuff once Vesa has put in the fixes. -Dave From bogus@does.not.exist.com Tue Oct 14 00:29:20 2008 From: bogus@does.not.exist.com () Date: Mon, 13 Oct 2008 22:29:20 -0000 Subject: No subject Message-ID: PyObject* PySequence_Fast (PyObject *o, const char *m) Return value: New reference. Returns the sequence o as a tuple, unless it is already a tuple or list, in which case o is returned. Use PySequence_Fast_GET_ITEM() to access the members of the result. Returns NULL on failure. If the object is not a sequence, raises TypeError with m as the message text. This implies to me that it will work for any sequence, and a quick test just convinced me that PySequence_Fast() works with o = xrange(n), even if traversed twice. See: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/cctbx/misc/Attic/container_from_list_or_tuple.py?rev=1.1.2.2&only_with_tag=boost_python_v2_transition&content-type=text/vnd.viewcvs-markup Ralf __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From bogus@does.not.exist.com Tue Oct 14 00:29:20 2008 From: bogus@does.not.exist.com () Date: Mon, 13 Oct 2008 22:29:20 -0000 Subject: No subject Message-ID: (____) methods, which are handled already by class object. Where arguments can be any Python type, I provided a template member function to cover that (e.g. list.index()) and a version in the dll/so which accepts object. Where arguments must be a specific type (e.g. pop(x)), I provided an overload taking the specific type and another accepting object, which will allow it to be used in expressions involving object. As we get these other types implemented we can carve them out of objects2.[cpp/hpp]. I hope someone will take up this challenge, and that this description will be helpful. Enjoy, Dave +---------------------------------------------------------------+ David Abrahams C++ Booster (http://www.boost.org) O__ == Pythonista (http://www.python.org) c/ /'_ == resume: http://users.rcn.com/abrahams/resume.html (*) \(*) == email: david.abrahams at rcn.com +---------------------------------------------------------------+ From bogus@does.not.exist.com Tue Oct 14 00:29:20 2008 From: bogus@does.not.exist.com () Date: Mon, 13 Oct 2008 22:29:20 -0000 Subject: No subject Message-ID: libstlport_gcc_[stldebug].so has a dependency on pthreads, right? So you can't expect to link to it without pthreads support, right? The only mystery to me is why the other boost libs would link OK. Is it possible that the error is mis-reported, and it's really expressing a dependency of Python on pthreads? If that's the case, the fix would be to python.jam. -Dave ----- Original Message ----- From: I guess the tools file is probably the wrong place to hack this in? Is there something better I should be doing? best, Greg _______________________________________________ C++-sig mailing list C++-sig at python.org http://mail.python.org/mailman/listinfo/c++-sig From bogus@does.not.exist.com Tue Oct 14 00:29:20 2008 From: bogus@does.not.exist.com () Date: Mon, 13 Oct 2008 22:29:20 -0000 Subject: No subject Message-ID: Python C++ y = x.foo y = x.attr("foo"); ... x and y x and y ^^^ Should this be &&, or is there something in C++ that I don't know about? Ralf --- David Abrahams wrote: > The much belated June 2002 progress report is now available in CVS, or at: > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/ > python/doc/v2/Jun2002.html __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com From bogus@does.not.exist.com Tue Oct 14 00:29:20 2008 From: bogus@does.not.exist.com () Date: Mon, 13 Oct 2008 22:29:20 -0000 Subject: No subject Message-ID: object none; ... if (getinitargs.ptr() != none.ptr()) Is your None above the same is my none here? Ralf __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com From bogus@does.not.exist.com Tue Oct 14 00:29:20 2008 From: bogus@does.not.exist.com () Date: Mon, 13 Oct 2008 22:29:20 -0000 Subject: No subject Message-ID: creates a submodule of whatever the current outer module is (whatever was passed to BOOST_PYTHON_MODULE_INIT). The benefits of being able to drop *just* the outer module name seem questionable to me; I think people will be confused by the lack of uniformity. I think I'd rather see a simple and straightforward approach where the full module qualification is supplied. I guess the question is, "how much work is it to make a submodule of an extension module that may be located anywhere in the package hierarchy?" OK, now I think I see why Dave wants to support '.'-prefixed module names. Because this usage creates a temporary which is destroyed immediately, I also take it that there's a "current inner module" into which new def()s and class_<> instances stick their Python results. At this point, python::module might as well be a function. One thing I dislike about that is that (if my assumptions are correct) some obvious usages give an unexpected result: void initialize_inner() { module(".inner"); def("g", g); } BOOST_PYTHON_MODULE_INIT(outer) { def("f", f); initialize_inner(); def("h", h); // creates outer.inner.h! } So we could return to the current syntax for inner modules: void initialize_inner() { module("outer.inner") .def("g", g) ; } BOOST_PYTHON_MODULE_INIT(outer) { def("f", f); initialize_inner(); def("h", h); // ok } I'm beginning to settle on the following conclusions: . module is a class derived from object. That makes constructs like: m.attr("x") = 1 possible. . It takes a single string in its constructor. . The name in the string is an absolute path if it does not begin with a '.' . Otherwise, the name in the string supplies a path relative to whatever is being constructed with BOOST_PYTHON_MODULE_INIT. . I am not convinced of the utility of auto-creating missing intermediate modules in: module("w.x.y.z") I'd be just as happy with a runtime error if it simplifies the code even a little. In fact, I take it back: not giving a runtime error could mask errors. I want to require that parent modules be constructed already. . What about auto-creating child modules? Clearly we want to be able to say: module(".x") and have it create the x submodule. However I think I would be very unhappy if module("sys") did anything other than retrieving (loading, if neccessary) the built-in "sys" module. Conclusion: when the constructor arg begins with '.', we auto-construct leaf modules. Otherwise, we don't. That leaves out the ability to build new modules with an absolute package path using module(...). Oh, well, no great loss. . BOOST_PYTHON_MODULE_INIT(...) creates a "module context", inside which def() and class_<> normally place their definitions. *If* we want to get around the class<> ordering problems for inner modules, we ought to provide a "module_scope" class which changes the target module of def() and class_<>... Why not just use module() itself, so that the last module created will always be the target? module("sys").attr("argv") is one good argument against it. . All of the stuff "above the line" can be done very cleanly; there are almost no questions about how it should work. We can afford to let the stuff "below the line" percolate a little bit before adding it. After we've had a round of comments on this message, we can discuss inner classes. Thanks for listening, Dave From bogus@does.not.exist.com Tue Oct 14 00:29:20 2008 From: bogus@does.not.exist.com () Date: Mon, 13 Oct 2008 22:29:20 -0000 Subject: No subject Message-ID: Python 2.2. > Furthermore: > > >>> range(3.3, 10.3) > [3, 4, 5, 6, 7, 8, 9] > > But: > > >>> range('1', '5') > Traceback (most recent call last): > File "", line 1, in ? > TypeError: an integer is required > > Now I note that strings don't have __int__, so I guess the int type handles > int('42') itself using special knowledge about strings. That's correct. int() knows how to convert strings: >>> print int.__doc__ int(x[, base]) -> integer Convert a string or number to an integer, if possible. A floating point argument will be truncated towards zero (this does not include a string representation of a floating point number!) When converting a string, use the optional base. It is an error to supply a base when converting a non-string. > I suppose that's to > keep strings from seeming to be numbers, since the nb_int slot fills in the > number_methods. > > And: > > >>> class zero(object): > ... def __int__(self): return 0 > ... > >>> range(zero(), 5) > [0, 1, 2, 3, 4] > > So, is there any general practice, (even if it's not universal)? Do Python > functions usually tend to coerce their arguments into the types they're > expecting? I'm guessing the answer is no... From bogus@does.not.exist.com Tue Oct 14 00:29:20 2008 From: bogus@does.not.exist.com () Date: Mon, 13 Oct 2008 22:29:20 -0000 Subject: No subject Message-ID: walk up the 'Number type tower', at least as far as function arguments are involved (operators are a different mess). The number tower is: int -> long -> float -> complex So, putting ints where floats are expected is always ok. This is part of what I think is 'intended design'. The reverse not true, though. Most python stuff don't react well to putting floats where ints are expected. I think it's also ok to accept a longint where ints are expected if you can convert it without loss. That's what sequence indexing (in Python 2.1) and range() do. Speaking of which, I think range() is an explicit exception because of it's semantics. It tries to convert all numbers it gets to int. I mentioned operators being a different mess mostly because of the division operator, but this is changing in the direction of always allowing you to go up the number tower. So, to sumarize: * you can go up the number tower. * longs can be used where ints are expected if int(yourlong) doesn't raise an exception * you can break the above rules if it makes sense and you really want to :-) Cheers, Leo -- Ideas don't stay in some minds very long because they don't like solitary confinement. From bogus@does.not.exist.com Tue Oct 14 00:29:20 2008 From: bogus@does.not.exist.com () Date: Mon, 13 Oct 2008 22:29:20 -0000 Subject: No subject Message-ID: > or > will it be available in the future? In Boost.Python? Eventually, I'm sure. Not for 1.29.0 > What's currently the best way to return > a std::vector, where T is some class already wrapped by boost.python? You could always wrap std::vector... or you could use Ralf's stuff. Or you could make a thin wrapper that builds a Python list and returns that using the facilities of boost/python/list.hpp. no-one-best-way-ly y'rs, Dave ----------------------------------------------------------- David Abrahams * Boost Consulting dave at boost-consulting.com * http://www.boost-consulting.com From bogus@does.not.exist.com Tue Oct 14 00:29:20 2008 From: bogus@does.not.exist.com () Date: Mon, 13 Oct 2008 22:29:20 -0000 Subject: No subject Message-ID: wrapper like Blob createBlob(const std::string data) { return Blob(data.str(),data.size()); } Can I pass this funktion to boost.python in a way, that I could be used as ctor? Something like this: class_("Blob",init<>()) .def( ??? , createBlob ); and then from Python: data = "a string with data to be passed to the blob" blob = Blob(data) regards, Achim From bogus@does.not.exist.com Tue Oct 14 00:29:20 2008 From: bogus@does.not.exist.com () Date: Mon, 13 Oct 2008 22:29:20 -0000 Subject: No subject Message-ID: > Most-importantly, when references and (smart) pointers to > polymorphic classes are converted to python, we will attempt to > downcast to "self_base", and if successful, we'll return the > contained self pointer instead of a new object This suggests that agent is derived from self_base, not multiply-inherited in agent_callback. The agent might have been created from the c++ side - so the self_pointer might be null. How do we deal with this case? From bogus@does.not.exist.com Tue Oct 14 00:29:20 2008 From: bogus@does.not.exist.com () Date: Mon, 13 Oct 2008 22:29:20 -0000 Subject: No subject Message-ID: snip... One way is just to find out what the real type of the pointee is on your own, by examining the header file. An HWND is a pointer to an HWND__ struct defined as follows: struct HWND__ { int unused; }; typedef struct HWND__* HWND I have attached three files noddy.cpp cn.cpp, and cnl.cpp-- cnl contains my conversion for noddy objects just using longs cn does the same thing using HWND. The following python session shows how it works for longs: C:\developer\com-hacking\boost hacking\convert noddy long>python Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import noddy,cnl >>> n=noddy.noddy() >>> m=cnl.magic() >>> m.magicnum 1957 >>> m.magicnum=n >>> m.magicnum 453311 >>> cnl (convert noddy long) contains a struct called magic with a single data member--magicnum. The struct initializes magicnum to 1957. Noddy's all have an int value attribute 453311. I assign a noddy to m.magicnum (setattr) and my converter correctly retrieves values and assigns it to the magicnum data member. The problem is indeed occurring when I try to do the same thing using pointers (my attempt is in cn.cpp). I just want to pass an int from python to my converter--have the converter cast the int to an HWND (pointer). How does knowing the real type help me in this situation? Thanks --Mark --Boundary_(ID_xRd++t/Mn4vDAnuEgMc4Ug) Content-type: application/octet-stream; name=cnl.cpp Content-transfer-encoding: 7bit Content-disposition: attachment; filename=cnl.cpp #include using namespace std; using namespace boost::python; //declarations extern "C" _declspec(dllimport) PyTypeObject noddy_NoddyType; typedef struct { PyObject_HEAD long magicNum; } noddy_NoddyObject; //magic struct typedef struct _magic { _magic() : magicnum(1957) {} long magicnum; } magic; //noddy object converter struct convertNoddy { static long& execute(PyObject& o) { static long magic = call_method(&o, "getMagicNum"); return magic; } }; BOOST_PYTHON_MODULE(cnl) { class_("magic") .def_readwrite("magicnum", &magic::magicnum); lvalue_from_pytype(); } --Boundary_(ID_xRd++t/Mn4vDAnuEgMc4Ug) Content-type: application/octet-stream; name=noddy.cpp Content-transfer-encoding: 7bit Content-disposition: attachment; filename=noddy.cpp #include extern "C" _declspec(dllexport) PyTypeObject noddy_NoddyType; typedef struct { PyObject_HEAD long magicNum; } noddy_NoddyObject; static PyObject* noddy_new_noddy(PyObject* self, PyObject* args) { noddy_NoddyObject* noddy; if (!PyArg_ParseTuple(args,":new_noddy")) return NULL; noddy = PyObject_New(noddy_NoddyObject, &noddy_NoddyType); noddy->magicNum = 453311; return (PyObject*)noddy; } #define MAGICNUM(v) (((noddy_NoddyObject *)(v))->magicNum) static PyObject* getMagicNum(PyObject* self, PyObject* args) { return Py_BuildValue("i", MAGICNUM(self)); } static void noddy_noddy_dealloc(PyObject* self) { PyObject_Del(self); } static PyMethodDef noddy_methods[] = { {"noddy", noddy_new_noddy, METH_VARARGS, "Create a new Noddy object."}, {"getMagicNum", getMagicNum, METH_VARARGS, "get magic number."}, // {"setMagicNum", setMagicNum, METH_VARARGS, // "set magic number."}, {NULL, NULL, 0, NULL} }; static PyObject* noddyGetAttr(PyObject* self, char* attrname) { return Py_FindMethod(noddy_methods, self, attrname); } extern "C" _declspec(dllexport)PyTypeObject noddy_NoddyType = { PyObject_HEAD_INIT(NULL) 0, "Noddy", sizeof(noddy_NoddyObject), 0, noddy_noddy_dealloc, /*tp_dealloc*/ 0, /*tp_print*/ noddyGetAttr, /*tp_getattr*/ 0, /*tp_setattr*/ 0, /*tp_compare*/ 0, /*tp_repr*/ 0, /*tp_as_number*/ 0, /*tp_as_sequence*/ 0, /*tp_as_mapping*/ 0, /*tp_hash */ }; DL_EXPORT(void) initnoddy(void) { noddy_NoddyType.ob_type = &PyType_Type; Py_InitModule("noddy", noddy_methods); } --Boundary_(ID_xRd++t/Mn4vDAnuEgMc4Ug) Content-type: application/octet-stream; name=cn.cpp Content-transfer-encoding: 7bit Content-disposition: attachment; filename=cn.cpp #include #include using namespace boost::python; //declarations extern "C" _declspec(dllimport) PyTypeObject noddy_NoddyType; typedef struct { PyObject_HEAD long magicNum; } noddy_NoddyObject; //magic structure typedef struct _magic { _magic(){ long deflong = 1957; magicnum= reinterpret_cast(deflong); } HWND magicnum; } magic; //converters struct HWND_PyInt { static PyObject* convert(const HWND& h) { static PyObject* pyh = PyInt_FromLong((long) h); return pyh; } }; struct convertNoddy { static HWND& execute(PyObject& o) { long magic = call_method(&o, "getMagicNum"); static HWND hmagic = reinterpret_cast(magic); return hmagic; } }; BOOST_PYTHON_MODULE(cn) { lvalue_from_pytype(); to_python_converter(); class_("magic") .def_readwrite("magicnum", &magic::magicnum); } --Boundary_(ID_xRd++t/Mn4vDAnuEgMc4Ug)-- From bogus@does.not.exist.com Tue Oct 14 00:29:20 2008 From: bogus@does.not.exist.com () Date: Mon, 13 Oct 2008 22:29:20 -0000 Subject: No subject Message-ID:
...   return 0
...
>>> C.f
<unbound method C.f>
>>> C.f = staticmethod(C.f)
>>> C.f
<unbound method C.f>
>>> C.f()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: unbound method f() must be called with C instance as first argument (
got nothing instead)

What am I missing?

Regards From bogus@does.not.exist.com Tue Oct 14 00:29:20 2008 From: bogus@does.not.exist.com () Date: Mon, 13 Oct 2008 22:29:20 -0000 Subject: No subject Message-ID:
...   return 0
...
>>> C.f
<unbound method C.f>
>>> C.f = staticmethod(C.f)
>>> C.f
<unbound method C.f>
>>> C.f()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: unbound method f() must be called with C instance as first argument (
got nothing instead)

What am I missing?

Regards _______________________________________________ C++-sig mailing list C++-sig at python.org http://mail.python.org/mailman/listinfo/c++-sig __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From bogus@does.not.exist.com Tue Oct 14 00:29:20 2008 From: bogus@does.not.exist.com () Date: Mon, 13 Oct 2008 22:29:20 -0000 Subject: No subject Message-ID: union, which is forbidden. Does anyone knows if I'm overlooking something? If Boost.Python doesn't indeed support unions, then Pyste will not support them too. But the stack trace is a bug: it should just ignore the union. I will work on it later today, and when it's ready I will let you know. Thanks for your interest and willingness to report bugs, Patrick! Nicodemus. From bogus@does.not.exist.com Tue Oct 14 00:29:20 2008 From: bogus@does.not.exist.com () Date: Mon, 13 Oct 2008 22:29:20 -0000 Subject: No subject Message-ID: which version of g++/gcc compiler I am getting to compile sources. There is newer g++ installed in our computer center: pengra0(828) which g++-3.2.1 /usr/local/bin/g++-3.2.1 pengra0(829) ../../../tools/build/jam_src/bin.linuxx86/bjam -sTOOLS=gcc -sBUILD=debug -sJAMBASE= -sBOOST_ROOT= -sBOOST_BUILD_PATH= -sGXX=g++-3.2.1 -sGCC=gcc-3.2.1 The output to my terminal does not give me info that g++-3.2.1 is used as follow: gcc-C++-action ../../../libs/test/build/bin/libunit_test_framework.a/gcc/debug/runtime-link-dynamic/unit_test_result.o So, could you please tell me how to find out whether g++-3.2.1 was used or just g++ (which uses version 2.9.6)? Also, please tell me if the command line above is the correct way to use g++-3.2.1 compiler? g++-3.2.1 compiler is symbolically linked to /usr/local/tools/gnu/gcc/3.2.1_redhat_7a_ia32/bin/g++, so I can simply do: 1) setenv GCC_ROOT_DIRECTORY /usr/local/tools/gnu/gcc/3.2.1_redhat_7a_ia32 2) ../../../tools/build/jam_src/bin.linuxx86/bjam -sTOOLS=gcc -sBUILD=debug -sJAMBASE= -sBOOST_ROOT= -sBOOST_BUILD_PATH= without using -sGXX=g++-3.2.1 ? Thank you very much in advance Chuzo From bogus@does.not.exist.com Tue Oct 14 00:29:20 2008 From: bogus@does.not.exist.com () Date: Mon, 13 Oct 2008 22:29:20 -0000 Subject: No subject Message-ID: > In fact, the sizeof stuff isn't needed; I was just trying to avoid > some compilation overhead, but that was a shot in the dark. You can > change both of those > convert_function_must_take_value_or_const_reference overloads to > inline void, give them bodies, and remove the > BOOST_STATIC_ASSERT(sizeof( ... ) == sizeof(int)) wrapper around the > call. I will try this out if you want, but I'd like you to consider that the suggested change could cause problems on other platforms, while Romain's fix is minimally intrusive and does not change the code seen by compilers other than gcc 3.3. Your choice: adventurous or conservative? Ralf __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From bogus@does.not.exist.com Tue Oct 14 00:29:20 2008 From: bogus@does.not.exist.com () Date: Mon, 13 Oct 2008 22:29:20 -0000 Subject: No subject Message-ID: property. Is there a way to wrap a module property (assume I have create get_verbose/set_verbose)? -- Sincerely yours, Zhang Le From lists_ravi at lavabit.com Wed Oct 1 00:17:40 2008 From: lists_ravi at lavabit.com (Ravi) Date: Tue, 30 Sep 2008 18:17:40 -0400 Subject: [C++-sig] Retrieving lvalues using custom converters Message-ID: <200809301817.41450.lists_ravi@lavabit.com> Hello, Is there a way to retrieve lvalues from function arguments? For example, consider the following code: void do_something( const array_t &a ) { ... } BOOST_PYTHON_MODULE( mmm ) { // my_converter is a custom from_python converter for array_t boost::python::converter::registry::push_back( my_converter::convertible, my_converter::construct, boost::python::type_id() ); boost::python::def( "do_something", &do_something ); } This registers a converter which works for calls from python to do_something. Everything works as expected. However, if the const is removed in the definition of do_something: void do_something( array_t &a ) { ... } then, boost.python complains that no converter is found. Now, if the argument "a" above to do_something needs to be modified, an ugly const_cast is required. Alternatively, one could do something like the following: void do_something( boost::python::object &obj ) { array_t a = boost::python::extract( obj ); ... } The above works reasonably well in the absence of function overloading. In essence, the dispatch is now handled manually instead of using boost.python. But this approach breaks down in the presence of function overloading because we then start needing another intermediate function to dispatch: int do_something( array1_t & ) { ... } float do_something( array2_t & ) { ... } return_type do_something_dispatcher( object &o ) { /*dispatch by type in o*/ } However, this new dispatcher still has a problem with different return types which I don't know how to solve (short of converting the return type to a boost::python::object). The problems above can be avoided if boost.python would allow extraction of lvalues for objects with custom from_python converters. Is this already possible and have I just missed it in the documentation? Or is extraction of lvalues possible using custom call_policies? Regards, Ravi From rwgk at yahoo.com Wed Oct 1 01:50:36 2008 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Tue, 30 Sep 2008 16:50:36 -0700 (PDT) Subject: [C++-sig] Retrieving lvalues using custom converters Message-ID: <938226.20754.qm@web31407.mail.mud.yahoo.com> > void do_something( array_t &a ) { ... } > > then, boost.python complains that no converter is found. Now, if the argument > "a" above to do_something needs to be modified, an ugly const_cast is > required. Alternatively, one could do something like the following: > > > void do_something( boost::python::object &obj ) > { > array_t a = boost::python::extract( obj ); > ... > } If the above works, this should work, too: void do_something( array_t a ) { ... } > The above works reasonably well in the absence of function overloading. In > essence, the dispatch is now handled manually instead of using boost.python. > But this approach breaks down in the presence of function overloading because > we then start needing another intermediate function to dispatch: > > int do_something( array1_t & ) { ... } > float do_something( array2_t & ) { ... } > return_type do_something_dispatcher( object &o ) { /*dispatch by type in o*/ } extract<> is a two stage process. Your code above is a shortcut for array_t a = boost::python::extract( obj )(); The intermediate object has a .check() method to determine if the conversion can succeed. You can use this two test for array1_t and array2_t. http://www.boost.org/doc/libs/1_36_0/libs/python/doc/v2/extract.html > However, this new dispatcher still has a problem with different return types > which I don't know how to solve (short of converting the return type to a > boost::python::object). Yes, make your dispatcher return a boost::python::object. > The problems above can be avoided if boost.python would allow extraction of > lvalues for objects with custom from_python converters. Is this already > possible No. > and have I just missed it in the documentation? No. > Or is extraction of lvalues possible using custom call_policies? No. FWIW: In my own code, I have an array ref<> type, which give you the .begin() and .size(), but not any of the functions that change the size of the array. I have custom converters from the main (reference-counted) array type to ref<>, which I can pass via ref<> const& and I can still modify the array elements. Ralf From thomas.rab at gmail.com Wed Oct 1 11:39:32 2008 From: thomas.rab at gmail.com (Thomas Rab) Date: Wed, 1 Oct 2008 09:39:32 +0000 (UTC) Subject: [C++-sig] exposing built-in type pointer Message-ID: I'm new boost python. After a few nights of trying to figure out this problem and trying to search for a solution, I finally decided to start a post. Anyway, I'm wrapping an existing API, so I unfortunately can't change the actual code, but here's my problem. There's a class: class foo { public: X x; }; bar is actually a typedef for: const unsigned int* bar; Basically I need x to create another object: class bar { public: bar(X x); }; I've tried this: class_("foo") .def_readonly("x",&foo::x) Which obviously doesn't work because python's integer type is immutable. Basically what I want to do in python is this: foo = foo() bar = bar(foo.x) This is the perfect outcome though, I'll just be happy if I'm able to access x, so I can pass it to bar. If I've not left enough information let me know, so I can explain/add more. Sorry for the horrible class/variable names. From thomas.rab at gmail.com Wed Oct 1 12:04:36 2008 From: thomas.rab at gmail.com (Thomas Rab) Date: Wed, 1 Oct 2008 10:04:36 +0000 (UTC) Subject: [C++-sig] exposing built-in type pointer References: Message-ID: Thomas Rab gmail.com> writes: > class foo > { > public: > X x; > }; > > bar is actually a typedef for: const unsigned int* bar; > Basically I need x to create another object: made a slight typo. I meant X is a typedef for: const unsigned int* From martin.walser at gmx.de Wed Oct 1 15:00:23 2008 From: martin.walser at gmx.de (Martin Walser) Date: Wed, 1 Oct 2008 15:00:23 +0200 Subject: [C++-sig] boost::python::dict problem Message-ID: Hello! :) Hmm... something odd's happening here when I'm trying to use a dict in my boost python C++ Extension: C++ Extension Code: dict testdict; ... testdict[1,17]="huhu"; string test = extract(testdict[1,17]); //access to dict: works! mLog->log(test); //writes test string to log... output: "huhu": works! But if I want to access the testdict class member in Python like here: Python Code: print self.myCExtension.testdict I get this output: {17: 'huhu'} While it should be {(1,17): 'huhu'} Doing this with a bigger dict results in a output were most entries are missing. When I output them in C++ all are there. Accessing with self.myCExtension.testdict[1,17] in python doesn't work either of course: KeyError: (1, 17) Hum... ravening beast... this boost::python. Martin From rwgk at yahoo.com Wed Oct 1 17:34:19 2008 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Wed, 1 Oct 2008 08:34:19 -0700 (PDT) Subject: [C++-sig] boost::python::dict problem Message-ID: <800224.37153.qm@web31401.mail.mud.yahoo.com> I have no explanation (other than that it looks like a bug/hole), but I'd expect testdict[boost::python::make_tuple(1, 17)] to work as you expect. ----- Original Message ---- From: Martin Walser To: c++-sig at python.org Sent: Wednesday, October 1, 2008 6:00:23 AM Subject: [C++-sig] boost::python::dict problem Hello! :) Hmm... something odd's happening here when I'm trying to use a dict in my boost python C++ Extension: C++ Extension Code: dict testdict; ... testdict[1,17]="huhu"; string test = extract(testdict[1,17]); //access to dict: works! mLog->log(test); //writes test string to log... output: "huhu": works! But if I want to access the testdict class member in Python like here: Python Code: print self.myCExtension.testdict I get this output: {17: 'huhu'} While it should be {(1,17): 'huhu'} Doing this with a bigger dict results in a output were most entries are missing. When I output them in C++ all are there. Accessing with self.myCExtension.testdict[1,17] in python doesn't work either of course: KeyError: (1, 17) Hum... ravening beast... this boost::python. Martin _______________________________________________ C++-sig mailing list C++-sig at python.org http://mail.python.org/mailman/listinfo/c++-sig From martin.walser at gmx.de Wed Oct 1 18:58:27 2008 From: martin.walser at gmx.de (Martin Walser) Date: Wed, 1 Oct 2008 18:58:27 +0200 Subject: [C++-sig] boost::python::dict problem In-Reply-To: References: Message-ID: Ralf W. Grosse-Kunstleve wrote: > I have no explanation (other than that it looks like a bug/hole), but I'd > expect > testdict[boost::python::make_tuple(1, 17)] to work as you expect. Indeed. This seems to help. :D C++: testdict[make_tuple(1,17)]="huhu"; testdict[(2,32)]="hooray"; string test = extract(testdict[make_tuple(1,17)]); //works mLog->log(test); //works Python: print self.myCExtension.testdict print self.myCExtension.testdict[(1,17)] results in: Python Output: {32: 'hooray', (1, 17): 'huhu'} huhu Perfect! Access in C++ has to be done with make_tuple(x,y) as well, though (Line 3 of C++) or it'll raise an error. Thx Ralf! From lists_ravi at lavabit.com Wed Oct 1 21:10:18 2008 From: lists_ravi at lavabit.com (Ravi) Date: Wed, 1 Oct 2008 15:10:18 -0400 Subject: [C++-sig] boost::python::dict problem In-Reply-To: References: Message-ID: <200810011510.18929.lists_ravi@lavabit.com> On Wednesday 01 October 2008 09:00:23 Martin Walser wrote: > ????????testdict[1,17]="huhu"; > ????????string test = extract(testdict[1,17]);??????????//access to > dict: works! > ????????mLog->log(test); //writes test string to log... output: "huhu": > works! This is a bug in your code. test[1,17] is actually test[17] since C++ rules for evaluating the expression "1,17" results in the value 17. I would not expect C++ to follow python rules and make it into a tuple. Even "(1,17)" would still evaluate in C++ to 17. You need, as Ralf pointed out, make_tuple or something else that returns a python tuple rather than an expression that returns a single int. Regards, Ravi From lists_ravi at lavabit.com Wed Oct 1 23:22:18 2008 From: lists_ravi at lavabit.com (Ravi) Date: Wed, 1 Oct 2008 17:22:18 -0400 Subject: [C++-sig] Retrieving lvalues using custom converters (numpy 1-D converters attached) In-Reply-To: <938226.20754.qm@web31407.mail.mud.yahoo.com> References: <938226.20754.qm@web31407.mail.mud.yahoo.com> Message-ID: <200810011722.19697.lists_ravi@lavabit.com> On Tuesday 30 September 2008 19:50:36 Ralf W. Grosse-Kunstleve wrote: > > void do_something( boost::python::object &obj ) > > { > > array_t a = boost::python::extract( obj ); > > ... > > } > > If the above works, this should work, too: > > void do_something( array_t a ) { ... } That is very insightful and works very well for my application; more below. [snip] > FWIW: > In my own code, I have an array ref<> type, which give you the .begin() > and .size(), but not any of the functions that change the size of the > array. I have custom converters from the main (reference-counted) array > type to ref<>, which I can pass via > ref<> const& > and I can still modify the array elements. Attached is some code then that could be useful to you. The following creates a storage array that references a numpy array. Copies of this storage class still point to the same underlying numpy array (whose reference count is increased). The way to use this is as part of a ublas array: typedef ublas::vector > array_t; This class handles non-contiguous arrays; resizing is also allowed, subject to the caveat that iterators are invalidated by resizing. The main limitation is that only vectors are supported, i.e., no matrices. Matrix support would be very simple to add but I haven't needed that for my application. As a usage note, you would need to register the converters using the non-templated registration functions provided in your extension module. Note that all basic types supported by numpy are supported here as well; no object arrays though! Comments welcome. Regards, Ravi -------------- next part -------------- A non-text attachment was scrubbed... Name: numpy.h Type: text/x-chdr Size: 15845 bytes Desc: not available URL: From lists_ravi at lavabit.com Wed Oct 1 23:33:15 2008 From: lists_ravi at lavabit.com (Ravi) Date: Wed, 1 Oct 2008 17:33:15 -0400 Subject: [C++-sig] Return value policies for objects with custom to-python converters In-Reply-To: <200809291417.26620.lists_ravi@lavabit.com> References: <200809291417.26620.lists_ravi@lavabit.com> Message-ID: <200810011733.16011.lists_ravi@lavabit.com> On Monday 29 September 2008 14:17:25 Ravi wrote: > ? The return value policies from boost.python do not seem to handle objects > with custom converters; they seem to handle only those types exposed via > boost.python. Attached is some code that handles reference_existing_object > for objects with custom converters. Searching the web, I found that Roman Yakovenko has a similar converter in his Py++ code repository, but for some reason, his version is called return_ref_value rather than reference_existing_object_[some_suffix] and that his version does not handle references (only pointers). If Roman could not plug in his converter into the already-existing boost.python framework, I probably should not bother trying to do so. > 2. So far, I have used only reference_existing_object. Do the other return > value policies need similar special handling for objects with custom > to-python converters? How do I figure out which ones do and which ones > don't? The other return value policies seem to be fine though I would like some assurance (from someone knowledgeable about boost.python internals) that only reference_existing_object needs to be rewritten to handle custom to-python converters. Regards, Ravi From NurEinDummy at gmx.de Thu Oct 2 01:07:58 2008 From: NurEinDummy at gmx.de (Littil Dummy) Date: Thu, 2 Oct 2008 01:07:58 +0200 Subject: [C++-sig] boost::python::dict problem In-Reply-To: <200810011510.18929.lists_ravi@lavabit.com> References: <200810011510.18929.lists_ravi@lavabit.com> Message-ID: <005801c9241a$8ba9f210$a2fdd630$@de> Hm. I don't get why "1,17" evaluates to 17 in c++. And if it does... this still doesn't explain why the dict contained 255*255 = 65000 =len(testdict) entries in C++ but only 255 entries when querying the length of it from within python. Removed duplicates? Martin -----Urspr?ngliche Nachricht----- Von: c++-sig-bounces+nureindummy=gmx.de at python.org [mailto:c++-sig-bounces+nureindummy=gmx.de at python.org] Im Auftrag von Ravi Gesendet: Mittwoch, 1. Oktober 2008 21:10 An: Development of Python/C++ integration Betreff: Re: [C++-sig] boost::python::dict problem On Wednesday 01 October 2008 09:00:23 Martin Walser wrote: > ????????testdict[1,17]="huhu"; > ????????string test = extract(testdict[1,17]);??????????//access to > dict: works! > ????????mLog->log(test); //writes test string to log... output: "huhu": > works! This is a bug in your code. test[1,17] is actually test[17] since C++ rules for evaluating the expression "1,17" results in the value 17. I would not expect C++ to follow python rules and make it into a tuple. Even "(1,17)" would still evaluate in C++ to 17. You need, as Ralf pointed out, make_tuple or something else that returns a python tuple rather than an expression that returns a single int. Regards, Ravi _______________________________________________ C++-sig mailing list C++-sig at python.org http://mail.python.org/mailman/listinfo/c++-sig From roman.yakovenko at gmail.com Thu Oct 2 10:38:02 2008 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Thu, 2 Oct 2008 11:38:02 +0300 Subject: [C++-sig] Return value policies for objects with custom to-python converters In-Reply-To: <200810011733.16011.lists_ravi@lavabit.com> References: <200809291417.26620.lists_ravi@lavabit.com> <200810011733.16011.lists_ravi@lavabit.com> Message-ID: <7465b6170810020138w5a6ecf19t8a8e66136ca1e3b2@mail.gmail.com> On Thu, Oct 2, 2008 at 12:33 AM, Ravi wrote: > On Monday 29 September 2008 14:17:25 Ravi wrote: >> The return value policies from boost.python do not seem to handle objects >> with custom converters; they seem to handle only those types exposed via >> boost.python. Attached is some code that handles reference_existing_object >> for objects with custom converters. > > Searching the web, I found that Roman Yakovenko has a similar converter in his > Py++ code repository, but for some reason, his version is called > return_ref_value rather than reference_existing_object_[some_suffix] and that > his version does not handle references (only pointers). If Roman could not > plug in his converter into the already-existing boost.python framework, I > probably should not bother trying to do so. Too many assumptions :-). Really. * I am not that good in Boost.Python internals. * I didn't need such functionality. >> 2. So far, I have used only reference_existing_object. Do the other return >> value policies need similar special handling for objects with custom >> to-python converters? How do I figure out which ones do and which ones >> don't? > > The other return value policies seem to be fine though I would like some > assurance (from someone knowledgeable about boost.python internals) that only > reference_existing_object needs to be rewritten to handle custom to-python > converters. You didn't presented small test case that reproduce the problem. I suggest you to take a look on the following FAQ: http://www.boost.org/doc/libs/1_36_0/libs/python/doc/v2/faq.html#topythonconversionfailed HTH. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ From roman.yakovenko at gmail.com Thu Oct 2 10:40:02 2008 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Thu, 2 Oct 2008 11:40:02 +0300 Subject: [C++-sig] How to use an opaque pointer ? In-Reply-To: <19655049.post@talk.nabble.com> References: <19655049.post@talk.nabble.com> Message-ID: <7465b6170810020140s4f5c428amdd32d133e31637ed@mail.gmail.com> On Wed, Sep 24, 2008 at 9:26 PM, William Mari? wrote: > > Hi, > > I would like to pass a CObject from C++ to Python without exposing the class > i've seen the opaque pointer feature but i can't make it work. > > Here is what i would like to do : > > CObject* pObj = ..... ; > bp::object callable = .... ; > callable( (bpCObject*)pObj ); > > I tried to do like in the documentation : > > typedef struct CObject_ *bpCObject; > BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(CObject_) > > but i always have this error at runtime : > > TypeError: No to_python (by-value) converter found for C++ type: struct > bpCObject * > > and i don't understand, could someone tell me why i have that and what do i > have to do to fix the problem ? You should register BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(CObject_) in every module. May I suggest you to try Py++? It handles such functionality pretty well. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ From roman.yakovenko at gmail.com Thu Oct 2 11:51:00 2008 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Thu, 2 Oct 2008 12:51:00 +0300 Subject: [C++-sig] exposing built-in type pointer In-Reply-To: References: Message-ID: <7465b6170810020251l444f5ec7q70b0c0d89e7ec639@mail.gmail.com> On Wed, Oct 1, 2008 at 1:04 PM, Thomas Rab wrote: > Thomas Rab gmail.com> writes: > >> class foo >> { >> public: >> X x; >> }; >> >> bar is actually a typedef for: const unsigned int* bar; >> Basically I need x to create another object: > > made a slight typo. I meant X is a typedef for: const unsigned int* There are few ways to go: 1. Create thin wrapper around X, which holds x, and use it for arguments and return type 2. Expose "x" address and use ctypes module 3. Create "more" Pythonic interface for the functionality. Boost.Python doesn't allow you to pass by pointer\non-const reference "Python" immutable types. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ From thomas.rab at gmail.com Thu Oct 2 12:52:33 2008 From: thomas.rab at gmail.com (Thomas Rab) Date: Thu, 2 Oct 2008 10:52:33 +0000 (UTC) Subject: [C++-sig] exposing built-in type pointer References: <7465b6170810020251l444f5ec7q70b0c0d89e7ec639@mail.gmail.com> Message-ID: Roman Yakovenko gmail.com> writes: > There are few ways to go: > 1. Create thin wrapper around X, which holds x, and use it for > arguments and return type > 2. Expose "x" address and use ctypes module > 3. Create "more" Pythonic interface for the functionality. I was thinking about option 1, how exactly would I accomplish this? From meine at informatik.uni-hamburg.de Thu Oct 2 13:34:08 2008 From: meine at informatik.uni-hamburg.de (Hans Meine) Date: Thu, 2 Oct 2008 13:34:08 +0200 Subject: [C++-sig] Importing and internal modules In-Reply-To: <9e264e780809291220i15f0557aq581af0ca58e9e0f4@mail.gmail.com> References: <9e264e780809291220i15f0557aq581af0ca58e9e0f4@mail.gmail.com> Message-ID: <200810021334.09423.meine@informatik.uni-hamburg.de> Am Montag, 29. September 2008 21:20:06 schrieb Peter LaDow: > The scriptable part is a module. It exposes a set of functions, so > I'd really like to just import that module, and not execute it. [...] Maybe you misunderstand the difference between import and execfile. importing is just some kind of namespaced execution; it is still execution. Also, you can pass execfile dictionaries for the local and global namespaces which make it possible to customize both what's predefined in the script, as well as which namespace the functions defined in it end up in. -- Ciao, / / /--/ / / ANS From ndbecker2 at gmail.com Thu Oct 2 13:41:04 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 02 Oct 2008 07:41:04 -0400 Subject: [C++-sig] Retrieving lvalues using custom converters (numpy 1-D converters attached) References: <938226.20754.qm@web31407.mail.mud.yahoo.com> <200810011722.19697.lists_ravi@lavabit.com> Message-ID: This is very interesting! But how do I use it? What I tried: your numpy.h (but comment out) #ifndef IN_FILE_IMPORTING_ARRAY #define NO_IMPORT_ARRAY #endif #define PY_ARRAY_UNIQUE_SYMBOL Wicket_Numpy My code: ,----[ /home/nbecker/numpy.new/num.cc ] | #include "numpy.h" | #include | #include | #include | | namespace ublas=boost::numeric::ublas; | using namespace boost::python; | | double do_sum (ublas::vector const& u) { | return std::accumulate (u.begin(), u.end(), 0.0); | } | | BOOST_PYTHON_MODULE (num) { | import_array(); | numpy::register_ublas_from_python_converters(); | numpy::register_default_ublas_to_python(); | def ("do_sum", &do_sum); | } `---- ,----[ /home/nbecker/numpy.new/test_num.py ] | from num import * | from numpy import * | | u = array (xrange(10), dtype=float64) | v = do_sum (u) `---- Seems the converters didn't work: ArgumentError: Python argument types in num.do_sum(numpy.ndarray) did not match C++ signature: do_sum(boost::numeric::ublas::vector > >) From ndbecker2 at gmail.com Thu Oct 2 14:35:05 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 02 Oct 2008 08:35:05 -0400 Subject: [C++-sig] Retrieving lvalues using custom converters (numpy 1-D converters attached) References: <938226.20754.qm@web31407.mail.mud.yahoo.com> <200810011722.19697.lists_ravi@lavabit.com> Message-ID: OK, got it! But, I needed to add simple_const_iter for const_iterator. Then, this works: ,----[ /home/nbecker/numpy.new/num.cc ] | #include "numpy.h" | #include | #include | #include | | namespace ublas=boost::numeric::ublas; | using namespace boost::python; | | double do_sum (ublas::vector > const& u) { | return std::accumulate (u.begin(), u.end(), 0.0); | } | | | BOOST_PYTHON_MODULE (num) { | import_array(); | numpy::register_ublas_from_python_converters(); | numpy::register_default_ublas_to_python(); | def ("do_sum", &do_sum); | } `---- From lists_ravi at lavabit.com Thu Oct 2 15:18:23 2008 From: lists_ravi at lavabit.com (Ravi) Date: Thu, 2 Oct 2008 09:18:23 -0400 Subject: [C++-sig] boost::python::dict problem In-Reply-To: <005801c9241a$8ba9f210$a2fdd630$@de> References: <200810011510.18929.lists_ravi@lavabit.com> <005801c9241a$8ba9f210$a2fdd630$@de> Message-ID: <200810020918.25068.lists_ravi@lavabit.com> On Wednesday 01 October 2008 19:07:58 Littil Dummy wrote: > I don't get why "1,17" evaluates to 17 in c++. Try the following (untested): #include int main( int char *[] ) { std::cout << 17 << " " << (1,17) << " " << (2,4,18) << std::endl; } > And if it does... this still doesn't explain why the dict contained 255*255 > = 65000 =len(testdict) entries in C++ but only 255 entries when querying > the length of it from within python. Removed duplicates? Yes. Regards, Ravi From lists_ravi at lavabit.com Thu Oct 2 15:34:29 2008 From: lists_ravi at lavabit.com (Ravi) Date: Thu, 2 Oct 2008 09:34:29 -0400 Subject: [C++-sig] Retrieving lvalues using custom converters (numpy 1-D converters attached) In-Reply-To: References: <938226.20754.qm@web31407.mail.mud.yahoo.com> <200810011722.19697.lists_ravi@lavabit.com> Message-ID: <200810020934.29475.lists_ravi@lavabit.com> On Thursday 02 October 2008 07:41:04 Neal Becker wrote: > This is very interesting! ?But how do I use it? > > What I tried: > your numpy.h (but comment out) > ?#ifndef IN_FILE_IMPORTING_ARRAY > ?#define NO_IMPORT_ARRAY > ?#endif > ?#define PY_ARRAY_UNIQUE_SYMBOL Wicket_Numpy Unless you removed the above for simplicity in you trivial module, you should generally have something like the above if you plan to include numpy.h from multiple source files for a single extension module; please see the numpy book for details. > My code: > ,----[ /home/nbecker/numpy.new/num.cc ] > > | #include "numpy.h" > | #include > | #include > | #include > | > | namespace ublas=boost::numeric::ublas; > | using namespace boost::python; > | > | double do_sum (ublas::vector const& u) { > | ? return std::accumulate (u.begin(), u.end(), 0.0); > | } Replace the above with: double do_sum( numpy::array_from_py::type u ) { ... } The reason is that arrays coming *from* numpy are converted to this type which is actually ublas::vector< double, numpy_storage_array >. The allocator (numpy_storage_array) is what converts storage in a PyArrayObject to something that ublas can use. I expect that the argument type above will be used only for functions dealing with values from python. I have attached an example of using numpy.h. Note that, in dump_vec(), a "regular" ublas vector is subtracted from the numpy vector with the results visible in python. Also, FYI, since you pass by const reference, you cannot modify the contents of 'u', but if you pass by value, you can. Passing by value costs you the two pointers instead of one but nothing more since the underlying storage is reference counted. > | > | BOOST_PYTHON_MODULE (num) { > | ? import_array(); > | ? numpy::register_ublas_from_python_converters(); > | ? numpy::register_default_ublas_to_python(); > | ? def ("do_sum", &do_sum); > | } > > `---- > ,----[ /home/nbecker/numpy.new/test_num.py ] > > | from num import * > | from numpy import * > | > | u = array (xrange(10), dtype=float64) > | v = do_sum (u) > > `---- Regards, Ravi -------------- next part -------------- A non-text attachment was scrubbed... Name: decco.cc Type: text/x-c++src Size: 1821 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: decco_example.py Type: text/x-python Size: 331 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: reference_existing_object_1.hpp Type: text/x-c++hdr Size: 1104 bytes Desc: not available URL: From ravi.rajagopal at amd.com Thu Oct 2 15:40:44 2008 From: ravi.rajagopal at amd.com (Ravikiran Rajagopal) Date: Thu, 2 Oct 2008 09:40:44 -0400 Subject: [C++-sig] Retrieving lvalues using custom converters (numpy 1-D converters attached) In-Reply-To: References: <938226.20754.qm@web31407.mail.mud.yahoo.com> Message-ID: <200810020940.44158.ravi.rajagopal@amd.com> On Thursday 02 October 2008 08:35:05 Neal Becker wrote: > OK, got it! ?But, I needed to add simple_const_iter for const_iterator. Could you elaborate? There is a const_iterator defined for the storage array already. If I have made some mistake, I would really like to fix it in my copy as well. Regards, Ravi From lists_ravi at lavabit.com Thu Oct 2 15:42:04 2008 From: lists_ravi at lavabit.com (Ravi) Date: Thu, 2 Oct 2008 09:42:04 -0400 Subject: [C++-sig] Retrieving lvalues using custom converters (numpy 1-D converters attached) In-Reply-To: References: <938226.20754.qm@web31407.mail.mud.yahoo.com> Message-ID: <200810020942.04959.lists_ravi@lavabit.com> On Thursday 02 October 2008 08:35:05 Neal Becker wrote: > OK, got it! ?But, I needed to add simple_const_iter for const_iterator. Could you elaborate? There is a const_iterator defined for the storage array already. If I have made some mistake, I would really like to fix it in my copy as well. Regards, Ravi From lists_ravi at lavabit.com Thu Oct 2 16:09:17 2008 From: lists_ravi at lavabit.com (Ravi) Date: Thu, 2 Oct 2008 10:09:17 -0400 Subject: [C++-sig] Return value policies for objects with custom to-python converters In-Reply-To: <7465b6170810020138w5a6ecf19t8a8e66136ca1e3b2@mail.gmail.com> References: <200809291417.26620.lists_ravi@lavabit.com> <200810011733.16011.lists_ravi@lavabit.com> <7465b6170810020138w5a6ecf19t8a8e66136ca1e3b2@mail.gmail.com> Message-ID: <200810021009.17645.lists_ravi@lavabit.com> On Thursday 02 October 2008 04:38:02 Roman Yakovenko wrote: > On Thu, Oct 2, 2008 at 12:33 AM, Ravi wrote: > > On Monday 29 September 2008 14:17:25 Ravi wrote: > >> ? The return value policies from boost.python do not seem to handle > >> objects with custom converters; they seem to handle only those types > >> exposed via boost.python. Attached is some code that handles > >> reference_existing_object for objects with custom converters. > > > > Searching the web, I found that Roman Yakovenko has a similar converter > > in his Py++ code repository, but for some reason, his version is called > > return_ref_value rather than reference_existing_object_[some_suffix] and > > that his version does not handle references (only pointers). If Roman > > could not plug in his converter into the already-existing boost.python > > framework, I probably should not bother trying to do so. > > Too many assumptions :-). Really. > * I am not that good in Boost.Python internals. > * I didn't need such functionality. Well, I'm pretty sure I understand boost.python internals less than you do :-) > >> 2. So far, I have used only reference_existing_object. Do the other > >> return value policies need similar special handling for objects with > >> custom to-python converters? How do I figure out which ones do and which > >> ones don't? > > > > The other return value policies seem to be fine though I would like some > > assurance (from someone knowledgeable about boost.python internals) that > > only reference_existing_object needs to be rewritten to handle custom > > to-python converters. > > You didn't presented small test case that reproduce the problem. Attached; hope you don't mind me using your code in my example. You will also need tuples.hpp from here: http://www.language- binding.net/pyplusplus/troubleshooting_guide/automatic_conversion/tuples.hpp.html Python code: import tuples x = tuples.get2() # works x = tuples.get1() # fails with conversion error > I suggest you to take a look on the following FAQ: > http://www.boost.org/doc/libs/1_36_0/libs/python/doc/v2/faq.html#topythonco >nversionfailed As far I can tell, add_property cannot be used to declare stand-alone functions though I am happy to be corrected. Regards, Ravi -------------- next part -------------- A non-text attachment was scrubbed... Name: tuples_tester.cpp Type: text/x-c++src Size: 628 bytes Desc: not available URL: From ndbecker2 at gmail.com Thu Oct 2 21:22:32 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 02 Oct 2008 15:22:32 -0400 Subject: [C++-sig] Retrieving lvalues using custom converters (numpy 1-D converters attached) References: <938226.20754.qm@web31407.mail.mud.yahoo.com> <200810011722.19697.lists_ravi@lavabit.com> Message-ID: Do I understand correctly, that when returning a ublas::vector to python, lifetime management is not provided? That is, nothing will ever destruct the ublas::vector, resulting in a memory leak? From lists_ravi at lavabit.com Thu Oct 2 21:54:46 2008 From: lists_ravi at lavabit.com (Ravi) Date: Thu, 2 Oct 2008 15:54:46 -0400 Subject: [C++-sig] Retrieving lvalues using custom converters (numpy 1-D converters attached) In-Reply-To: References: <938226.20754.qm@web31407.mail.mud.yahoo.com> <200810011722.19697.lists_ravi@lavabit.com> Message-ID: <200810021554.47340.lists_ravi@lavabit.com> On Thursday 02 October 2008 15:22:32 Neal Becker wrote: > Do I understand correctly, that when returning a ublas::vector to python, > lifetime management is not provided? ?That is, nothing will ever destruct > the ublas::vector, resulting in a memory leak? Yes. However, you can use any of the standard return value policies from boost.python to manage the lifetime of an array returned to python; if you use copy_const_reference and return the array by value from your function, any decent optimizing compiler would optimize away the copy. There are 4 main use cases: 1. A python array is passed into your function (and perhaps you modify it); no lifetime management is needed here. 2. A C++ array is exposed as a member of some other class; the lifetime of the python member is tied to the lifetime of the C++ object and the usual caveats apply. 3. A C++ array is returned from a function by reference; in this case, the usual return value policies can be used to manage the Python object lifetime. 4. A C++ array is returned from a function by value; this case is the same as the preceding one. Note that there is no use case in which a python array is passed back out of a C++ function. The rationale is that python arrays can be created only in python in which case you already have a reference in python. If you create a python array in C++, you are on your own. In that case, it is not terribly hard to use the provided converter to get a numpy ublas array; you could simply write the trivial to_python converter using the provided get_array() function. Regards, Ravi From lists_ravi at lavabit.com Thu Oct 2 22:51:10 2008 From: lists_ravi at lavabit.com (Ravi) Date: Thu, 2 Oct 2008 16:51:10 -0400 Subject: [C++-sig] Retrieving lvalues using custom converters (numpy 1-D converters attached) In-Reply-To: References: <938226.20754.qm@web31407.mail.mud.yahoo.com> Message-ID: <200810021651.12130.lists_ravi@lavabit.com> On Thursday 02 October 2008 08:35:05 Neal Becker wrote: > But, I needed to add simple_const_iter for const_iterator. Figured it out, stupid oversight on my part (forgot some add_const in the right places); replace the definition of simple_iter like so: template < class Value > class simple_iter : public boost::iterator_facade< simple_iter, Value, boost::random_access_traversal_tag, typename boost::add_reference::type, npy_intp > { private: struct enabler {}; typedef typename boost::mpl::if_::type, const numpy_storage_array, numpy_storage_array >::type array_type; public: explicit simple_iter( array_type *a, npy_intp indx = 0 ) : array( a ), index( indx ) {} template simple_iter( simple_iter const &other, typename boost::enable_if< boost::is_convertible< OtherValue*, Value* >, enabler >::type = enabler() ) : array( other.array ), index( other.index ) {} private: friend class boost::iterator_core_access; template friend class simple_iter; void increment() { ++index; } void decrement() { --index; } template bool equal( simple_iter const &other ) const { return index == other.index; } Value &dereference() const { return ( *array )[index]; } void advance( npy_intp n ) { index += n; } template npy_intp distance_to( simple_iter const &other ) const { return other.index - index; } private: array_type *array; npy_intp index; }; From ndbecker2 at gmail.com Fri Oct 3 02:03:58 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 02 Oct 2008 20:03:58 -0400 Subject: [C++-sig] Retrieving lvalues using custom converters (numpy 1-D converters attached) References: <938226.20754.qm@web31407.mail.mud.yahoo.com> <200810011722.19697.lists_ravi@lavabit.com> <200810021554.47340.lists_ravi@lavabit.com> Message-ID: Sorry, I'm still confused. Suppose I have this: ublas::vector create (int size, double init) { return ublas::vector (size, init); } With default return value policy, this fails. We used: register_vector_to_python_converters< false, contiguous_vector_to_py, default_ublas_array_traits>(); Which does _not_ copy the data and uses PyArray_SimpleNewFromData. The data is immediately destroyed and the array returned to python is garbage. It would be nice if the function could return a shared_ptr, which python would manage. This doesn't seem to work: boost::shared_ptr > create (int size, double init) { boost::shared_ptr > u (new ublas::vector (size, init)); return u; } TypeError: No to_python (by-value) converter found for C++ type: boost::shared_ptr > > > What do you suggest? From ralvek at yahoo.it Fri Oct 3 11:10:32 2008 From: ralvek at yahoo.it (k k) Date: Fri, 3 Oct 2008 09:10:32 +0000 (GMT) Subject: [C++-sig] Choosing the best way to wrap Message-ID: <661889.1599.qm@web27806.mail.ukl.yahoo.com> Hi to all, I'm pretty new to Boost.python , i've done some very basic test with it, i've built the hello world example module and another useless extension module that wrap a little c++ class. In reality i want to wrap this c++ library http://www.cs.umd.edu/~mount/ANN/ and i'd like to ask you which is the best way to do this and if you suggest me something about this. Do you think is this possible to wrap? Do you think i have to use only Boost.python or also Py++ ? Thanks Scopri il blog di Yahoo! Mail: Trucchi, novit? e la tua opinione. http://www.ymailblogit.com/blog -------------- next part -------------- An HTML attachment was scrubbed... URL: From renatox at gmail.com Fri Oct 3 15:29:30 2008 From: renatox at gmail.com (Renato Araujo) Date: Fri, 3 Oct 2008 10:29:30 -0300 Subject: [C++-sig] void* cast to a specific type based on string name Message-ID: <95291a80810030629y27ac1b9ex50f69eaac42fe483@mail.gmail.com> Hi all, This question is about a problem I have in my implementation during the use of : boost::python::object(), my code is like this (this is a simple example how I receive the args from the C++ library): void call_Pyfunction(char **types /* contains the types names*/, void **args /* contains the pointers to values */ ) { /* type contains values like that: type ={"int", "double", "char*", "MyObject", ...} /* args contains values like that: args = {10, 5.5, "my string", ...} /* here I need convert the args to PyObjects */ /* I'm using boost::python::object() but I need cast the value to specific type based on types names */ // the main question here is how to convert char* to a c++ type // I can use a switch to native types but i would like to know if there is a best way to solve this } -- Renato Araujo Oliveira Filho From lists_ravi at lavabit.com Fri Oct 3 17:05:00 2008 From: lists_ravi at lavabit.com (Ravi) Date: Fri, 3 Oct 2008 11:05:00 -0400 Subject: [C++-sig] Retrieving lvalues using custom converters (numpy 1-D converters attached) In-Reply-To: References: <938226.20754.qm@web31407.mail.mud.yahoo.com> <200810021554.47340.lists_ravi@lavabit.com> Message-ID: <200810031105.02448.lists_ravi@lavabit.com> On Thursday 02 October 2008 20:03:58 Neal Becker wrote: > ublas::vector create (int size, double init) { > ? ?return ublas::vector (size, init); > } > > With default return value policy, this fails. ? ?We used: > ? register_vector_to_python_converters< false, contiguous_vector_to_py, > ? ? default_ublas_array_traits>(); > > Which does _not_ copy the data and uses PyArray_SimpleNewFromData. ?The > data is immediately destroyed and the array returned to python is garbage. You are right; I was wrong in my previous reply. I need the help of a boost.python expert to tell me what to do in this case. For the default return value policy, we end up in registry_to_python_value::operator(), but the last line of that function is never called. Why this is, I have been unable to figure out. > It would be nice if the function could return a shared_ptr, which python > would manage. ?This doesn't seem to work: > > boost::shared_ptr > create (int size, double init) { > ? boost::shared_ptr > u (new ublas::vector > (size, init)); return u; > } This, too, remains a puzzle to me. Do shared_ptr conversions not work for objects with custom to_python converters? Regards, Ravi From roman.yakovenko at gmail.com Fri Oct 3 20:22:22 2008 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Fri, 3 Oct 2008 21:22:22 +0300 Subject: [C++-sig] Return value policies for objects with custom to-python converters In-Reply-To: <200810021009.17645.lists_ravi@lavabit.com> References: <200809291417.26620.lists_ravi@lavabit.com> <200810011733.16011.lists_ravi@lavabit.com> <7465b6170810020138w5a6ecf19t8a8e66136ca1e3b2@mail.gmail.com> <200810021009.17645.lists_ravi@lavabit.com> Message-ID: <7465b6170810031122u7bc9aa52sbdb5eaa02db4b398@mail.gmail.com> 2008/10/2 Ravi : > Attached; hope you don't mind me using your code in my example. No, I am glad you find it useful. > Python code: > import tuples > x = tuples.get2() # works > x = tuples.get1() # fails with conversion error > I could be wrong, but it seems to be Boost.Python bug. I would submit bug report. I thought about possible work around for you. Basically you can wrap functionality that registers custom converters and add that type to some global list. You can use boost::python::type_info class for the type description. Then you can create new call policy, that will query that list and will execute library "reference_existing_object" or yours. This solution is applicable if you have few types with custom conversion and many functions. HTH -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ From roman.yakovenko at gmail.com Fri Oct 3 20:32:30 2008 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Fri, 3 Oct 2008 21:32:30 +0300 Subject: [C++-sig] void* cast to a specific type based on string name In-Reply-To: <95291a80810030629y27ac1b9ex50f69eaac42fe483@mail.gmail.com> References: <95291a80810030629y27ac1b9ex50f69eaac42fe483@mail.gmail.com> Message-ID: <7465b6170810031132n441176b7p983c4205d123457c@mail.gmail.com> On Fri, Oct 3, 2008 at 4:29 PM, Renato Araujo wrote: > Hi all, > > This question is about a problem I have in my implementation during > the use of : boost::python::object(), > my code is like this (this is a simple example how I receive the args > from the C++ library): > > > void call_Pyfunction(char **types /* contains the types names*/, void > **args /* contains the pointers to values */ ) > { > /* type contains values like that: type ={"int", "double", > "char*", "MyObject", ...} > /* args contains values like that: args = {10, 5.5, "my string", ...} > /* here I need convert the args to PyObjects */ > > /* I'm using boost::python::object() but I need cast the value > to specific type based on types names */ > // the main question here is how to convert char* to a c++ type > > // I can use a switch to native types but i would like to know > if there is a best way to solve this > } Why don't you pass boost::python::object directly? Later you can use http://www.boost.org/doc/libs/1_36_0/libs/python/doc/v2/extract.html#extract-spec class and check what type the object contains? -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ From roman.yakovenko at gmail.com Fri Oct 3 20:41:28 2008 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Fri, 3 Oct 2008 21:41:28 +0300 Subject: [C++-sig] Choosing the best way to wrap In-Reply-To: <661889.1599.qm@web27806.mail.ukl.yahoo.com> References: <661889.1599.qm@web27806.mail.ukl.yahoo.com> Message-ID: <7465b6170810031141r5defc725j84842b7bbee0e6df@mail.gmail.com> 2008/10/3 k k : > Do you think i have to use only Boost.python or also Py++ ? You can definitely go without Py++, but it could help, If the code is more-or-less "simple", Py++ will generate the wrapper without to much work from you. Otherwise Py++ will generate warnings for functionality it cannot expose. The warning will help you to estimate the effort needed to create the initial wrapper. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ From renatox at gmail.com Fri Oct 3 21:06:15 2008 From: renatox at gmail.com (Renato Araujo) Date: Fri, 3 Oct 2008 16:06:15 -0300 Subject: [C++-sig] void* cast to a specific type based on string name In-Reply-To: <7465b6170810031132n441176b7p983c4205d123457c@mail.gmail.com> References: <95291a80810030629y27ac1b9ex50f69eaac42fe483@mail.gmail.com> <7465b6170810031132n441176b7p983c4205d123457c@mail.gmail.com> Message-ID: <95291a80810031206o3daeb1b6y8cd3e8405e3ea822@mail.gmail.com> Hi thanks for your help, but I already tried this: This is the code: void call_Pyfunction(int argc, char **types, void **args, PyObject *callbak) { PyObject *pyargs = PyTuple_New(argc); for (int i=0; i < argc; i++) { PyObject *o = boost::python::object(args[i]).ptr(); PyTuple_SetItem(pyargs, i, boost::python::incref(o)); } PyObject_Call(callback, pyargs, NULL); } I got this error during the object creation: terminate called after throwing an instance of 'boost::python::error_already_set' BR Renato Araujo On Fri, Oct 3, 2008 at 3:32 PM, Roman Yakovenko wrote: > On Fri, Oct 3, 2008 at 4:29 PM, Renato Araujo wrote: >> Hi all, >> >> This question is about a problem I have in my implementation during >> the use of : boost::python::object(), >> my code is like this (this is a simple example how I receive the args >> from the C++ library): >> >> >> void call_Pyfunction(char **types /* contains the types names*/, void >> **args /* contains the pointers to values */ ) >> { >> /* type contains values like that: type ={"int", "double", >> "char*", "MyObject", ...} >> /* args contains values like that: args = {10, 5.5, "my string", ...} >> /* here I need convert the args to PyObjects */ >> >> /* I'm using boost::python::object() but I need cast the value >> to specific type based on types names */ >> // the main question here is how to convert char* to a c++ type >> >> // I can use a switch to native types but i would like to know >> if there is a best way to solve this >> } > > Why don't you pass boost::python::object directly? > Later you can use > http://www.boost.org/doc/libs/1_36_0/libs/python/doc/v2/extract.html#extract-spec > class and check what type the object contains? > > -- > Roman Yakovenko > C++ Python language binding > http://www.language-binding.net/ > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > -- Renato Araujo Oliveira Filho From roman.yakovenko at gmail.com Fri Oct 3 21:18:54 2008 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Fri, 3 Oct 2008 22:18:54 +0300 Subject: [C++-sig] void* cast to a specific type based on string name In-Reply-To: <95291a80810031206o3daeb1b6y8cd3e8405e3ea822@mail.gmail.com> References: <95291a80810030629y27ac1b9ex50f69eaac42fe483@mail.gmail.com> <7465b6170810031132n441176b7p983c4205d123457c@mail.gmail.com> <95291a80810031206o3daeb1b6y8cd3e8405e3ea822@mail.gmail.com> Message-ID: <7465b6170810031218n39aa8ef1x5cd7fb016a770781@mail.gmail.com> On Fri, Oct 3, 2008 at 10:06 PM, Renato Araujo wrote: > Hi thanks for your help, but I already tried this: > > This is the code: > > void call_Pyfunction(int argc, char **types, void **args, PyObject *callbak) > { > PyObject *pyargs = PyTuple_New(argc); > for (int i=0; i < argc; i++) > { > PyObject *o = boost::python::object(args[i]).ptr(); > PyTuple_SetItem(pyargs, i, boost::python::incref(o)); > } > PyObject_Call(callback, pyargs, NULL); > } > > I got this error during the object creation: > > terminate called after throwing an instance of > 'boost::python::error_already_set' I would find out what cause the error. It seems that you are trying to implement functionality that already exists in trunk. Search this mailing list, there are few posts that discuss how to call any python function. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ From lists_ravi at lavabit.com Fri Oct 3 23:00:03 2008 From: lists_ravi at lavabit.com (Ravi) Date: Fri, 3 Oct 2008 17:00:03 -0400 Subject: [C++-sig] Return value policies for objects with custom to-python converters In-Reply-To: <7465b6170810031122u7bc9aa52sbdb5eaa02db4b398@mail.gmail.com> References: <200809291417.26620.lists_ravi@lavabit.com> <200810021009.17645.lists_ravi@lavabit.com> <7465b6170810031122u7bc9aa52sbdb5eaa02db4b398@mail.gmail.com> Message-ID: <200810031700.03408.lists_ravi@lavabit.com> On Friday 03 October 2008 14:22:22 Roman Yakovenko wrote: > > Python code: > > import tuples > > x = tuples.get2() # works > > x = tuples.get1() # fails with conversion error > > I could be wrong, but it seems to be Boost.Python bug. I would submit > bug report. Ok, but this is a symptom of a more general problem: boost.python does not allow one to plug in custom converters to work easily with its return value policies. For example, I just figured out a hack to make return_by_value(!) work for my custom converter (see my next mail replying to Neal Becker on the mailing list). > I thought about possible work around for you. > > Basically you can wrap functionality that registers custom converters > and add that type to some global list. You can use > boost::python::type_info class for the type description. > Then you can create new call policy, that will query that list and > will execute library "reference_existing_object" or yours. That is a good idea, but I would like to see it fixed in boost.python; I tried my hand at fixing it today but I was totally lost in the internals of boost.python. Regards, Ravi From lists_ravi at lavabit.com Fri Oct 3 23:08:28 2008 From: lists_ravi at lavabit.com (Ravi) Date: Fri, 3 Oct 2008 17:08:28 -0400 Subject: [C++-sig] Retrieving lvalues using custom converters (numpy 1-D converters attached) In-Reply-To: References: <938226.20754.qm@web31407.mail.mud.yahoo.com> <200810021554.47340.lists_ravi@lavabit.com> Message-ID: <200810031708.29008.lists_ravi@lavabit.com> On Thursday 02 October 2008 20:03:58 Neal Becker wrote: > Sorry, I'm still confused. ?Suppose I have this: > > ublas::vector create (int size, double init) { > ? ?return ublas::vector (size, init); > } > > With default return value policy, this fails. ? ?We used: > ? register_vector_to_python_converters< false, contiguous_vector_to_py, > ? ? default_ublas_array_traits>(); > > Which does _not_ copy the data and uses PyArray_SimpleNewFromData. ?The > data is immediately destroyed and the array returned to python is garbage. Ok, here is an extremely hackish solution for the return_by_value return value policy. This solution is not guaranteed to work if call policies chaining is used. At the end of numpy.h, please append the following code: ------- start here -------- namespace boost { namespace python { namespace detail { template struct registry_to_python_value< boost::numeric::ublas::vector const &> { typedef typename boost::numeric::ublas::vector vector_t; typedef typename value_arg< vector_t const&>::type argument_type; PyObject* operator()(argument_type in) const { // Do we need the extra incref in contiguous_vector_to_py or should we go directly // to the implementation in pyarray_from_vector_impl to avoid the incref? return numpy::contiguous_vector_to_py::convert( in ); } #ifndef BOOST_PYTHON_NO_PY_SIGNATURES PyTypeObject const* get_pytype() const { return converter::registered::converters.to_python_target_type(); } #endif BOOST_STATIC_CONSTANT(bool, uses_registry = false); }; }}} // namespace boost::python::detail ------- ends here --------- You will also need to include boost/python/to_python_value.hpp. If you can think of a better solution, I would be grateful. I am aware that a copy is made here, but I could not think of a solution that avoids copies. If Dave Abrahams is reading this: Am I hijacking the conversion mechanism at the right point or is there a better point, such as make_instance? I could not get make_instance to work with custom converters. Regards, Ravi From renatox at gmail.com Fri Oct 3 23:38:11 2008 From: renatox at gmail.com (Renato Araujo) Date: Fri, 3 Oct 2008 18:38:11 -0300 Subject: [C++-sig] void* cast to a specific type based on string name In-Reply-To: <7465b6170810031218n39aa8ef1x5cd7fb016a770781@mail.gmail.com> References: <95291a80810030629y27ac1b9ex50f69eaac42fe483@mail.gmail.com> <7465b6170810031132n441176b7p983c4205d123457c@mail.gmail.com> <95291a80810031206o3daeb1b6y8cd3e8405e3ea822@mail.gmail.com> <7465b6170810031218n39aa8ef1x5cd7fb016a770781@mail.gmail.com> Message-ID: <95291a80810031438l436a019dg3a9b6cce198a7d05@mail.gmail.com> Hi thanks again, I found some e-mails about this, but my problem continue: now I reimplemented the function to some like that: void call_Pyfunction(int argc, char **types, void **args, PyObject *callbak) { boost::python::list pyArgs; for (int i=0; i <= count; i++) { pyArgs.append(args[i]); } callback(pyArgs); } but the error still happen: If i put the correct cast before "args[i]" this works fine; .......... for (int i=0; i <= count; i++) { pyArgs.append(*(int *)args[i]); } .......... Thanks Renato On Fri, Oct 3, 2008 at 4:18 PM, Roman Yakovenko wrote: > On Fri, Oct 3, 2008 at 10:06 PM, Renato Araujo wrote: >> Hi thanks for your help, but I already tried this: >> >> This is the code: >> >> void call_Pyfunction(int argc, char **types, void **args, PyObject *callbak) >> { >> PyObject *pyargs = PyTuple_New(argc); >> for (int i=0; i < argc; i++) >> { >> PyObject *o = boost::python::object(args[i]).ptr(); >> PyTuple_SetItem(pyargs, i, boost::python::incref(o)); >> } >> PyObject_Call(callback, pyargs, NULL); >> } >> >> I got this error during the object creation: >> >> terminate called after throwing an instance of >> 'boost::python::error_already_set' > > I would find out what cause the error. > > It seems that you are trying to implement functionality that already > exists in trunk. > Search this mailing list, there are few posts that discuss how to call > any python function. > > > -- > Roman Yakovenko > C++ Python language binding > http://www.language-binding.net/ > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > -- Renato Araujo Oliveira Filho From ndbecker2 at gmail.com Sat Oct 4 01:49:29 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 03 Oct 2008 19:49:29 -0400 Subject: [C++-sig] Retrieving lvalues using custom converters (numpy 1-D converters attached) References: <938226.20754.qm@web31407.mail.mud.yahoo.com> <200810021554.47340.lists_ravi@lavabit.com> <200810031105.02448.lists_ravi@lavabit.com> Message-ID: Ravi wrote: > On Thursday 02 October 2008 20:03:58 Neal Becker wrote: >> ublas::vector create (int size, double init) { >> return ublas::vector (size, init); >> } >> >> With default return value policy, this fails. We used: >> register_vector_to_python_converters< false, contiguous_vector_to_py, >> default_ublas_array_traits>(); >> >> Which does _not_ copy the data and uses PyArray_SimpleNewFromData. The >> data is immediately destroyed and the array returned to python is >> garbage. > > You are right; I was wrong in my previous reply. I need the help of a > boost.python expert to tell me what to do in this case. For the default > return value policy, we end up in registry_to_python_value::operator(), > but the last line of that function is never called. Why this is, I have > been unable to figure out. > >> It would be nice if the function could return a shared_ptr, which python >> would manage. This doesn't seem to work: >> >> boost::shared_ptr > create (int size, double init) >> { boost::shared_ptr > u (new ublas::vector >> (size, init)); return u; >> } > > This, too, remains a puzzle to me. Do shared_ptr conversions not work for > objects with custom to_python converters? > I realize now, this isn't a problem of boost::python. The problem is the design of numpy. numpy can adopt external storage, but has no way to really manage it. It _could_ use the C 'free' function on it, and although that _might_ work, it can't do the 'right' thing, which is call your choice of deallocation function (like boost::shared_ptr could, for example). From lists_ravi at lavabit.com Sat Oct 4 17:03:36 2008 From: lists_ravi at lavabit.com (Ravi) Date: Sat, 4 Oct 2008 11:03:36 -0400 Subject: [C++-sig] Retrieving lvalues using custom converters (numpy 1-D converters attached) In-Reply-To: References: <938226.20754.qm@web31407.mail.mud.yahoo.com> <200810031105.02448.lists_ravi@lavabit.com> Message-ID: <200810041103.36316.lists_ravi@lavabit.com> On Friday 03 October 2008 19:49:29 Neal Becker wrote: > > This, too, remains a puzzle to me. Do shared_ptr conversions not work for > > objects with custom to_python converters? > > I realize now, this isn't a problem of boost::python. ?The problem is the > design of numpy. ?numpy can adopt external storage, but has no way to > really manage it. ?It _could_ use the C 'free' function on it, and although > that _might_ work, it can't do the 'right' thing, which is call your choice > of deallocation function (like boost::shared_ptr could, for example). Never say never. Attached is code, along with tests that handles both return- by-value and returning by shared pointer; returning existing reference was already handled by the code posted earlier. Unfortunately, you need to make an extra function call in the module initialization code to ensure that the new python type for handling smart pointer deletion is initialized. See the example. As a bonus, this version handles to_python conversion of ublas matrices as well. Note: Numpy has a bug which prevents return_by_value from working for row_major matrices. Regards, Ravi -------------- next part -------------- A non-text attachment was scrubbed... Name: decco.cc Type: text/x-c++src Size: 3664 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: numpy.hpp Type: text/x-c++hdr Size: 9278 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: numpyregister.hpp Type: text/x-c++hdr Size: 16428 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: decco_example.py Type: text/x-python Size: 889 bytes Desc: not available URL: From roman.yakovenko at gmail.com Sat Oct 4 20:06:44 2008 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Sat, 4 Oct 2008 21:06:44 +0300 Subject: [C++-sig] void* cast to a specific type based on string name In-Reply-To: <95291a80810031438l436a019dg3a9b6cce198a7d05@mail.gmail.com> References: <95291a80810030629y27ac1b9ex50f69eaac42fe483@mail.gmail.com> <7465b6170810031132n441176b7p983c4205d123457c@mail.gmail.com> <95291a80810031206o3daeb1b6y8cd3e8405e3ea822@mail.gmail.com> <7465b6170810031218n39aa8ef1x5cd7fb016a770781@mail.gmail.com> <95291a80810031438l436a019dg3a9b6cce198a7d05@mail.gmail.com> Message-ID: <7465b6170810041106j2adb0686j78263172cafedad5@mail.gmail.com> On Sat, Oct 4, 2008 at 12:38 AM, Renato Araujo wrote: > Hi thanks again, I found some e-mails about this, but my problem continue: > > now I reimplemented the function to some like that: > > void call_Pyfunction(int argc, char **types, void **args, PyObject *callbak) > { > boost::python::list pyArgs; > for (int i=0; i <= count; i++) > { > pyArgs.append(args[i]); > } > callback(pyArgs); > } > > but the error still happen: > If i put the correct cast before "args[i]" this works fine; > > .......... > for (int i=0; i <= count; i++) > { > pyArgs.append(*(int *)args[i]); > } I don't understand you. Why do you expect that boost::python::object will guess the actual type from void*? -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ From renatox at gmail.com Mon Oct 6 15:42:30 2008 From: renatox at gmail.com (Renato Araujo) Date: Mon, 6 Oct 2008 10:42:30 -0300 Subject: [C++-sig] void* cast to a specific type based on string name In-Reply-To: <7465b6170810041106j2adb0686j78263172cafedad5@mail.gmail.com> References: <95291a80810030629y27ac1b9ex50f69eaac42fe483@mail.gmail.com> <7465b6170810031132n441176b7p983c4205d123457c@mail.gmail.com> <95291a80810031206o3daeb1b6y8cd3e8405e3ea822@mail.gmail.com> <7465b6170810031218n39aa8ef1x5cd7fb016a770781@mail.gmail.com> <95291a80810031438l436a019dg3a9b6cce198a7d05@mail.gmail.com> <7465b6170810041106j2adb0686j78263172cafedad5@mail.gmail.com> Message-ID: <95291a80810060642y2c3f4b43u748654ff2e58b14e@mail.gmail.com> Hi, for this case I would like to know if is possible create a python object based on string name like that: void call_Pyfunction(int argc, char **types, void **args, boost::python::object *callbak) { boost::python::list pyArgs; for (int i=0; i <= count; i++) { //in types I have the typenames: {"int", "string", "MyObject", ....} boost::python::object o(types[i], args[i]); pyArgs.append(o); } callback(pyArgs); } On Sat, Oct 4, 2008 at 3:06 PM, Roman Yakovenko wrote: > On Sat, Oct 4, 2008 at 12:38 AM, Renato Araujo wrote: >> Hi thanks again, I found some e-mails about this, but my problem continue: >> >> now I reimplemented the function to some like that: >> >> void call_Pyfunction(int argc, char **types, void **args, PyObject *callbak) >> { >> boost::python::list pyArgs; >> for (int i=0; i <= count; i++) >> { >> pyArgs.append(args[i]); >> } >> callback(pyArgs); >> } >> >> but the error still happen: >> If i put the correct cast before "args[i]" this works fine; >> >> .......... >> for (int i=0; i <= count; i++) >> { >> pyArgs.append(*(int *)args[i]); >> } > > I don't understand you. Why do you expect that boost::python::object > will guess the actual type from void*? > > > -- > Roman Yakovenko > C++ Python language binding > http://www.language-binding.net/ > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > -- Renato Araujo Oliveira Filho From Ralf.Hildebrandt at charite.de Mon Oct 6 22:09:22 2008 From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt) Date: Mon, 6 Oct 2008 22:09:22 +0200 Subject: [C++-sig] Test Message-ID: <20081006200922.GQ9633@charite.de> Test due to the bounce problems with c++-sig at python.org Please discard! From NurEinDummy at gmx.de Mon Oct 6 22:26:36 2008 From: NurEinDummy at gmx.de (Littil Dummy) Date: Mon, 6 Oct 2008 22:26:36 +0200 Subject: [C++-sig] Test In-Reply-To: <20081006200922.GQ9633@charite.de> References: <20081006200922.GQ9633@charite.de> Message-ID: <001e01c927f1$d4a933b0$7dfb9b10$@de> succeeded. -----Urspr?ngliche Nachricht----- Von: c++-sig-bounces+nureindummy=gmx.de at python.org [mailto:c++-sig-bounces+nureindummy=gmx.de at python.org] Im Auftrag von Ralf Hildebrandt Gesendet: Montag, 6. Oktober 2008 22:09 An: c++-sig at python.org Betreff: [C++-sig] Test Test due to the bounce problems with c++-sig at python.org Please discard! _______________________________________________ C++-sig mailing list C++-sig at python.org http://mail.python.org/mailman/listinfo/c++-sig From jonas at MIT.EDU Tue Oct 7 05:28:37 2008 From: jonas at MIT.EDU (Eric Jonas) Date: Mon, 06 Oct 2008 23:28:37 -0400 Subject: [C++-sig] passing containers of shared pointers as arguments and getting automatic conversion Message-ID: <1223350118.8059.27.camel@convolution> Hello! I've found several examples of code on the internet where people are trying to convert from a native python container type to a std::container. Using those as a template, I'm trying to convert from a python tuple of objects wrapped by boost::python to a std::vector of boost::shared_ptrs. Example c++: http://pastebin.com/m3b198a9c Example python showing the code running: http://pastebin.com/m400f17e1 Example output: http://pastebin.com/m1b0eb94e [all pasted at the end of the mail] [Please note these only work if you've hacked your boost/shared_ptr.hpp to make everything public] Unfortunately, I'm running into a problem with extract> creating a -new- shared pointer pointing to the raw pointer -within- the existing shared pointer -- so no reference-comanaging occurs. I've hacked my shared_ptr.hpp to let me examine the refcounted struct inside the shared pointer. What I see when I run things is as follows: [jonas at hamiltonian core]$ python broken_test.py Foo 0 is at 88276256 with reference counter 8276288 Foo 1 is at 88276352 with reference counter 8276384 Foo 2 is at 88276320 with reference counter 8276416 Extraction of object pointing to 88276256 but with reference counter 0x7f54c0 Extraction of object pointing to 88276352 but with reference counter 0x7f3f80 Extraction of object pointing to 88276320 but with reference counter 0x7e4a00 Note what this is saying: While internal to my FooHolder, the shared pointers point to location X and reference-counting struct Y, within the converter they're being turned into new shared pointers, still managing the raw pointer X but with a different reference-counting-struct Z. This is most perplexing, and I worry it might be the result of interaction with the fact that in my example code, I'm explicitly using the shared pointer to manage the reference count: class_("Foo"); In any case, I'm quite stumped, and have a -ton- of places in my main codebase where stl containers are passed around containing shared_ptrs. I asked around on IRC but everyone seemed stumped too. Any help would be greatly appreciated. Thanks! ...Eric Jonas broken.cc: #include #include #include #include #include #include #include #include using namespace boost::python; using namespace std; template struct vector_from_tuple_of_shared { vector_from_tuple_of_shared() { converter::registry::push_back(&convertible, &construct, boost::python::type_id >()); } static void* convertible(PyObject* obj_ptr) { handle<> x(borrowed(obj_ptr)); boost::python::tuple o(x); for (int i = 0; i < boost::python::len(o); i++) { extract obj(o[i]); if (!obj.check() ) { return 0; } } return obj_ptr; } static void construct(PyObject* obj_ptr, converter::rvalue_from_python_stage1_data* data) { handle<> x(borrowed(obj_ptr)); std::vector value; boost::python::tuple o(x); for (int i = 0; i < boost::python::len(o); i++) { extract obj(o[i]); T1 s1 = obj; std::cout << "Extraction of object pointing to " << ios::hex << (int64_t) s1.get() << " but with reference counter " << s1.pn.pi_ << std::endl; value.push_back(obj); } void* storage = ( (converter::rvalue_from_python_storage >*) data)->storage.bytes; new (storage) std::vector(value); data->convertible = storage; } }; class Foo { }; typedef boost::shared_ptr pFoo_t; class FooHolder { public: std::vector foos_; pFoo_t createFoo() { pFoo_t f(new Foo()); foos_.push_back(f); return f; } void printFooStatus() { for(int i = 0; i < foos_.size(); i++) { std::cout << "Foo " << i << " is at " << ios::hex << (int64_t)foos_[i].get() << " with reference counter " << (int64_t)foos_[i].pn.pi_ << std::endl; } } }; void doStuff(std::vector stuff) { } BOOST_PYTHON_MODULE(broken) { class_("Foo"); class_("FooHolder") .def("createFoo", &FooHolder::createFoo) .def("printFooStatus", &FooHolder::printFooStatus) ; def("doStuff", &doStuff); vector_from_tuple_of_shared(); } Broken.py: import broken fh = broken.FooHolder() f1 = fh.createFoo() f2 = fh.createFoo() f3 = fh.createFoo() fh.printFooStatus() broken.doStuff((f1, f2, f3)) Output: [again, requires modified shared_ptr.hpp] jonas at hamiltonian core]$ make broken.so g++ -O2 -g -pg -I/usr/local/include -fPIC -I../threadpool/threadpool/include -pthread -fPIC -I/usr/include/`/usr/bin/python -c "import sys; (a, b, c, t, n) = sys.version_info; print 'python%d.%d' % (a, b),"` -c broken.cc g++ broken.o -L/usr/local/lib -lgsl -lgslcblas -lm -lboost_unit_test_framework -lboost_program_options -g -pg -lboost_thread -lboost_signals -o broken.so -shared -I/usr/include/`/usr/bin/python -c "import sys; (a, b, c, t, n) = sys.version_info; print 'python%d.%d' % (a, b),"` \ -L/usr/lib -lpython2.4 -lboost_python [jonas at hamiltonian core]$ python broken_test.py Foo 0 is at 88276256 with reference counter 8276288 Foo 1 is at 88276352 with reference counter 8276384 Foo 2 is at 88276320 with reference counter 8276416 Extraction of object pointing to 88276256 but with reference counter 0x7f54c0 Extraction of object pointing to 88276352 but with reference counter 0x7f3f80 Extraction of object pointing to 88276320 but with reference counter 0x7e4a00 From meine at informatik.uni-hamburg.de Tue Oct 7 12:05:26 2008 From: meine at informatik.uni-hamburg.de (Hans Meine) Date: Tue, 7 Oct 2008 12:05:26 +0200 Subject: [C++-sig] Choosing the best way to wrap In-Reply-To: <661889.1599.qm@web27806.mail.ukl.yahoo.com> References: <661889.1599.qm@web27806.mail.ukl.yahoo.com> Message-ID: <200810071205.28145.meine@informatik.uni-hamburg.de> Am Freitag, 03. Oktober 2008 11:10:32 schrieb k k: > I'm pretty new to Boost.python , i've done some very basic test with it, > i've built the hello world example module and another useless extension > module that wrap a little c++ class. In reality i want to wrap this c++ > library http://www.cs.umd.edu/~mount/ANN/ and i'd like to ask you which is > the best way to do this and if you suggest me something about this. Do you > think is this possible to wrap? You do know about scikits.ann, do you? http://scipy.org/scipy/scikits/wiki/AnnWrapper -- Ciao, / / /--/ / / ANS From rcdailey at gmail.com Thu Oct 9 18:24:50 2008 From: rcdailey at gmail.com (Robert) Date: Thu, 09 Oct 2008 11:24:50 -0500 Subject: [C++-sig] Inconsistency with Boost.Python code Message-ID: Hi, Suppose the following C++ Boost.Python code below. Note that I am embedding the python interpreter to execute python scripts from C++: using namespace boost::python; object imported( import( "sys" ) ); dict sysdict( imported.attr( "__dict__" ) ); list syspath( sysdict["path"] ); syspath.append( "C:\testing" ); When I do the following python code in a script that I load after calling the code above, the output shows that "C:\testing" is not present in the list of paths: import sys print sys.path However, when I do the Boost.Python code below, it works perfectly fine: import( "sys" ).attr( "path" ).attr( "append" )( "C:\testing" ); Both should do the same thing, however one works and one does not. Somewhere a copy seems to be getting created, when according to my research they should be reference counted. Can anyone explain the reasoning for this? From seefeld at sympatico.ca Thu Oct 9 19:06:50 2008 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Thu, 09 Oct 2008 13:06:50 -0400 Subject: [C++-sig] Inconsistency with Boost.Python code In-Reply-To: References: Message-ID: <48EE3A2A.3040303@sympatico.ca> Hi Robert, I believe the reason for this behavior is that an implicit cast from object to dict and list will cause a copy, so you don't actually insert the path into the original (global) path object, but a local copy, which obviously isn't seen by the rest of the application. Robert wrote: > Hi, > > Suppose the following C++ Boost.Python code below. Note that I am > embedding the python interpreter to execute python scripts from C++: > > using namespace boost::python; > object imported( import( "sys" ) ); > dict sysdict( imported.attr( "__dict__" ) ); The call to 'attr()' returns an object, and you assign it to a dict. This causes a copy. Try this instead: object dict_object = imported.attr("__dict__"); dict sysdict = extract(dict_object); > > list syspath( sysdict["path"] ); And likewise here: object list_object = sysdict["path"]; list syspath = extract(list_object); > > syspath.append( "C:\testing" ); However, as you have discovered, there are ways to fold these lines to make it more compact. I only spelled the individual steps out to illustrate what's going on underneath. HTH, Stefan -- ...ich hab' noch einen Koffer in Berlin... From rcdailey at gmail.com Thu Oct 9 19:47:50 2008 From: rcdailey at gmail.com (Robert) Date: Thu, 09 Oct 2008 12:47:50 -0500 Subject: [C++-sig] Inconsistency with Boost.Python code In-Reply-To: <48EE3A2A.3040303@sympatico.ca> References: <48EE3A2A.3040303@sympatico.ca> Message-ID: Stefan Seefeld wrote: > Hi Robert, > > I believe the reason for this behavior is that an implicit cast from > object to dict and list will cause a copy, so you don't actually insert > the path into the original (global) path object, but a local copy, which > obviously isn't seen by the rest of the application. > > Robert wrote: >> Hi, >> >> Suppose the following C++ Boost.Python code below. Note that I am >> embedding the python interpreter to execute python scripts from C++: >> >> using namespace boost::python; >> object imported( import( "sys" ) ); >> dict sysdict( imported.attr( "__dict__" ) ); > > The call to 'attr()' returns an object, and you assign it to a dict. > This causes a copy. Try this instead: > > object dict_object = imported.attr("__dict__"); > dict sysdict = extract(dict_object); > >> >> list syspath( sysdict["path"] ); > > And likewise here: > > object list_object = sysdict["path"]; > list syspath = extract(list_object); > >> >> syspath.append( "C:\testing" ); > > However, as you have discovered, there are ways to fold these lines to > make it more compact. I only spelled the individual steps out to > illustrate what's going on underneath. > > HTH, > Stefan > Thanks for your response. Will this code below work? boost::python::dict GetNamespace( char const* mod ) { using namespace boost::python; dict moduleNamespace( extract( import( mod ).attr( "__dict__" ) ) ); return moduleNamespace; } My main concern is the returned value of "import()" going out of scope and being destroyed since there are no outstanding references to it, causing the dict object returned to reference an invalid object. Would this be a possibility? After running the code above I find that it does not work, and I get the following output from python: TypeError: No to_python (by-value) converter found for C++ type: struct boost::python::extract Not sure what this means! Thanks again for all the help! From rcdailey at gmail.com Thu Oct 9 20:02:49 2008 From: rcdailey at gmail.com (Robert) Date: Thu, 09 Oct 2008 13:02:49 -0500 Subject: [C++-sig] [boost.python] __dict__ question Message-ID: Hi, Is it really necessary to obtain __dict__ in order to add variables to some object's scope? For example, suppose I want to define a global variable in a module, how would I do this? I know the first step I must take is to import the module: boost::python::import( "my_module" ) What then? A pseudo-code example of what I would expect is something like: using namespace boost::python; import( "my_module" ).attr( "my_global" ) = object( 5.0f ); What's the real way to do this? The only valid code I can come up with is: using namespace boost::python; object my_global( 5.0f ); dict my_module_namespace = extract( import( "my_module" ).attr( "__dict__" ) ); my_module_namespace.append( my_global ); Is there no way to clean this up? I'm not even sure if this functions (I haven't compiled it), but it should work I think. From seefeld at sympatico.ca Thu Oct 9 20:11:52 2008 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Thu, 09 Oct 2008 14:11:52 -0400 Subject: [C++-sig] Inconsistency with Boost.Python code In-Reply-To: References: <48EE3A2A.3040303@sympatico.ca> Message-ID: <48EE4968.8010300@sympatico.ca> Robert wrote: > > Will this code below work? > > boost::python::dict GetNamespace( char const* mod ) > { > using namespace boost::python; > dict moduleNamespace( extract( import( mod ).attr( > "__dict__" ) ) ); > return moduleNamespace; > } > > > My main concern is the returned value of "import()" going out of scope > and being destroyed since there are no outstanding references to it, > causing the dict object returned to reference an invalid object. Would > this be a possibility? No. moduleNamespace holds a (counted) reference to the module object, so it won't be destroyed (unloaded) while someone still holds references to objects within it. > > After running the code above I find that it does not work, and I get > the following output from python: > > TypeError: No to_python (by-value) converter found for C++ type: > struct boost::python::extract That's probably caused by the above code being a little too compact. extract is actually a distinct type, which provides a conversion operator for 'dict'. (This two-phase conversion is useful as you may not yet know whether the conversion would succeed, so the extract<> type gives you an opportunity to check that, before actually invoking it.) In most circumstances this conversion operator is invoked implicitly by the compiler, but sometimes it isn't. A slight change in the syntax should do the trick, such as dict moduleNamespace = extract( import( mod ).attr( "__dict__" ) ); // caution: untested ! or applying the call operator on the temporary extract<> object: dict moduleNamespace(extract(import(mod).attr("__dict__")(); // caution: untested ! HTH, Stefan -- ...ich hab' noch einen Koffer in Berlin... From rcdailey at gmail.com Thu Oct 9 20:05:04 2008 From: rcdailey at gmail.com (Robert) Date: Thu, 09 Oct 2008 13:05:04 -0500 Subject: [C++-sig] [boost.python] object: Assignment vs Construction Message-ID: Hi, I've noticed in various situations that assignment and construction of boost::python::object types do not do the same thing. For example, these two lines of code below are different at runtime: dict ns = extract( import( "sys" ).attr( "__dict__" ) ); -- -- dict ns( extract( import( "sys" ).attr( "__dict__" ) ) ); The latter of the two will cause an exception at runtime. Why are these different and what is each meant to do? From rcdailey at gmail.com Thu Oct 9 20:15:35 2008 From: rcdailey at gmail.com (Robert) Date: Thu, 09 Oct 2008 13:15:35 -0500 Subject: [C++-sig] Inconsistency with Boost.Python code In-Reply-To: <48EE4968.8010300@sympatico.ca> References: <48EE3A2A.3040303@sympatico.ca> <48EE4968.8010300@sympatico.ca> Message-ID: Stefan Seefeld wrote: > Robert wrote: >> >> Will this code below work? >> >> boost::python::dict GetNamespace( char const* mod ) >> { >> using namespace boost::python; >> dict moduleNamespace( extract( import( mod ).attr( >> "__dict__" ) ) ); >> return moduleNamespace; >> } >> >> >> My main concern is the returned value of "import()" going out of scope >> and being destroyed since there are no outstanding references to it, >> causing the dict object returned to reference an invalid object. Would >> this be a possibility? > > No. moduleNamespace holds a (counted) reference to the module object, so > it won't be destroyed (unloaded) while someone still holds references to > objects within it. > >> >> After running the code above I find that it does not work, and I get >> the following output from python: >> >> TypeError: No to_python (by-value) converter found for C++ type: >> struct boost::python::extract > > That's probably caused by the above code being a little too compact. > extract is actually a distinct type, which provides a conversion > operator for 'dict'. (This two-phase conversion is useful as you may > not yet know whether the conversion would succeed, so the extract<> type > gives you an opportunity to check that, before actually invoking it.) > > In most circumstances this conversion operator is invoked implicitly by > the compiler, but sometimes it isn't. > A slight change in the syntax should do the trick, such as > > dict moduleNamespace = extract( import( mod ).attr( "__dict__" ) > ); // caution: untested ! > > or applying the call operator on the temporary extract<> object: > > dict moduleNamespace(extract(import(mod).attr("__dict__")(); // > caution: untested ! > > > HTH, > Stefan > > Do copies occur only between object to dict? or does it also copy from dict to dict? or list to list? I'm still not 100% sure if the copy or reference counting is deterministic. Thanks so far for all the help, you've been extremely helpful. From seefeld at sympatico.ca Thu Oct 9 20:33:21 2008 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Thu, 09 Oct 2008 14:33:21 -0400 Subject: [C++-sig] Inconsistency with Boost.Python code In-Reply-To: References: <48EE3A2A.3040303@sympatico.ca> <48EE4968.8010300@sympatico.ca> Message-ID: <48EE4E71.10901@sympatico.ca> Robert wrote: > > Do copies occur only between object to dict? or does it also copy from > dict to dict? or list to list? I'm still not 100% sure if the copy or > reference counting is deterministic. See http://www.boost.org/doc/libs/1_36_0/libs/python/doc/tutorial/doc/html/python/object.html#python.derived_object_types (look for 'pitfall') Note that what you did in C++ (dict d(...)) corresponds to this in Python: d = dict(...) which also creates a copy. Boost.python is simply being consistent with Python here. (Yes, this keeps confusing me, too...) HTH, Stefan -- ...ich hab' noch einen Koffer in Berlin... From dave at boostpro.com Fri Oct 10 20:24:07 2008 From: dave at boostpro.com (David Abrahams) Date: Fri, 10 Oct 2008 14:24:07 -0400 Subject: [C++-sig] [boost.python] __dict__ question In-Reply-To: (Robert's message of "Thu, 09 Oct 2008 13:02:49 -0500") References: Message-ID: <87d4i8cnqw.fsf@mcbain.luannocracy.com> on Thu Oct 09 2008, Robert wrote: > Hi, > > Is it really necessary to obtain __dict__ in order to add variables to > some object's scope? No. > For example, suppose I want to define a global > variable in a module, how would I do this? I know the first step I > must take is to import the module: > > boost::python::import( "my_module" ) > > What then? A pseudo-code example of what I would expect is something like: > > using namespace boost::python; > import( "my_module" ).attr( "my_global" ) = object( 5.0f ); Looks OK to me. In fact, import( "my_module" ).attr( "my_global" ) = 5.0f; should work. -- Dave Abrahams BoostPro Computing http://www.boostpro.com From dave at boostpro.com Fri Oct 10 20:25:51 2008 From: dave at boostpro.com (David Abrahams) Date: Fri, 10 Oct 2008 14:25:51 -0400 Subject: [C++-sig] [boost.python] object: Assignment vs Construction In-Reply-To: (Robert's message of "Thu, 09 Oct 2008 13:05:04 -0500") References: Message-ID: <878wswcno0.fsf@mcbain.luannocracy.com> on Thu Oct 09 2008, Robert wrote: > Hi, > > I've noticed in various situations that assignment and construction of > boost::python::object types do not do the same thing. For example, these two lines of > code below are different at runtime: > > dict ns = extract( import( "sys" ).attr( "__dict__" ) ); > > -- -- > > dict ns( extract( import( "sys" ).attr( "__dict__" ) ) ); > > > The latter of the two will cause an exception at runtime. Which exception? > Why are these different and what is each meant to do? I think they should be the same. -- Dave Abrahams BoostPro Computing http://www.boostpro.com From dave at boostpro.com Fri Oct 10 20:41:17 2008 From: dave at boostpro.com (David Abrahams) Date: Fri, 10 Oct 2008 14:41:17 -0400 Subject: [C++-sig] downcasting problems In-Reply-To: <95291a80809291146j2885674eo618a959da5b3704b@mail.gmail.com> (Renato Araujo's message of "Mon, 29 Sep 2008 15:46:50 -0300") References: <95291a80809280830y40a01a47l45f6b204212a70f1@mail.gmail.com> <95291a80809291146j2885674eo618a959da5b3704b@mail.gmail.com> Message-ID: <87r66ob8du.fsf@mcbain.luannocracy.com> on Mon Sep 29 2008, "Renato Araujo" wrote: > Hi all, > > After some test I got this working but with some extra code. I created > 2 wrapper classes to Shape and Circle like that: > > =========== > wrapper code: > =========== > class ShapeWrapper : public Shape, public wrapper > { > .... > }; > > class CircleWrapper : public Cirlce, public wrapper > { > ..... > }; > > and used this classes in boost code. And all works fine. > But is this the best way to do this?? That is the best way to wrap polymorphic classes if you want to be able to override their C++ virtual functions in Python. > I always need create theses > wrapper class?? I don't understand your question, sorry. -- Dave Abrahams BoostPro Computing http://www.boostpro.com From dave at boostpro.com Sun Oct 12 21:08:14 2008 From: dave at boostpro.com (David Abrahams) Date: Sun, 12 Oct 2008 15:08:14 -0400 Subject: [C++-sig] void* cast to a specific type based on string name In-Reply-To: <95291a80810060642y2c3f4b43u748654ff2e58b14e@mail.gmail.com> (Renato Araujo's message of "Mon, 6 Oct 2008 10:42:30 -0300") References: <95291a80810030629y27ac1b9ex50f69eaac42fe483@mail.gmail.com> <7465b6170810031132n441176b7p983c4205d123457c@mail.gmail.com> <95291a80810031206o3daeb1b6y8cd3e8405e3ea822@mail.gmail.com> <7465b6170810031218n39aa8ef1x5cd7fb016a770781@mail.gmail.com> <95291a80810031438l436a019dg3a9b6cce198a7d05@mail.gmail.com> <7465b6170810041106j2adb0686j78263172cafedad5@mail.gmail.com> <95291a80810060642y2c3f4b43u748654ff2e58b14e@mail.gmail.com> Message-ID: <877i8dpr6p.fsf@mcbain.luannocracy.com> on Mon Oct 06 2008, "Renato Araujo" wrote: > Hi, > > for this case I would like to know if is possible create a python > object based on string name like that: > > > void call_Pyfunction(int argc, char **types, void **args, > boost::python::object *callbak) > { > boost::python::list pyArgs; > for (int i=0; i <= count; i++) > { > //in types I have the typenames: {"int", "string", "MyObject", ....} > boost::python::object o(types[i], args[i]); > pyArgs.append(o); > } > callback(pyArgs); > } Sure, just build a map from type names to conversion functions: std::map m; template python::object void_ptr_to_python(void* p) { return python::object(*(T*)p); } m["int"] = &void_ptr_to_python; m["string"] = &void_ptr_to_python; m["MyObject"] = &void_ptr_to_python; Then, m[types[i]](args[i]) will do the trick. -- Dave Abrahams BoostPro Computing http://www.boostpro.com From hans_meine at gmx.net Mon Oct 13 10:03:45 2008 From: hans_meine at gmx.net (Hans Meine) Date: Mon, 13 Oct 2008 10:03:45 +0200 Subject: [C++-sig] downcasting problems In-Reply-To: <95291a80809280830y40a01a47l45f6b204212a70f1@mail.gmail.com> References: <95291a80809280830y40a01a47l45f6b204212a70f1@mail.gmail.com> Message-ID: <200810131003.52270.hans_meine@gmx.net> On Sonntag 28 September 2008, Renato Araujo wrote: > ======================================= > the python test is this, and this always output "FAIL": > ======================================= > > if __name__ == '__main__': > shape = Shape() > circle = Circle(shape) > p = circle.parent() > if (p == shape): > print "OK" > else: > print "FAIL" Maybe it's your test which is wrong - you're testing for *identity* (since no equality comparison operators are defined) of the *python* objects. If you want to achieve that, using wrappers is one method, using shared_ptrs is another one AFAICS (but then you wrote "without changing the c++ code"). But anyhow, the p and shape may not satisfy ==, but they'll still "be the same [c++] object". -- Ciao, / / .o. /--/ ..o / / ANS ooo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From tfautre at telenet.be Mon Oct 13 18:43:23 2008 From: tfautre at telenet.be (Tanguy =?utf-8?Q?Fautr=C3=A9?=) Date: Mon, 13 Oct 2008 16:43:23 +0000 Subject: [C++-sig] Object destructor not always called in embedded interpreter Message-ID: Hi, I've been trying to sort this issue for some time now, but without any success. Long story short: some objects are never destroyed after executing a script using the embedded Python interpreter and Boost.Python. For example, when executing the following script in the embedded interpreter: def f() : o2 = NamedObject('object2') o1 = NamedObject('object1') f() It will print: Creating NamedObject 'object1' Creating NamedObject 'object2' Destroying NamedObject 'object2' This shows that o1 is never destroyed. Note that if I call Py_Finalize() afterwards, o1 is correctly destroyed (although, from what I understand this function should not be called when using Boost.Python). This leads me to believe that something, somewhere, is holding a reference to that object. I've attached the sources of this example. You'll see that before I execute the python script, I create a new namespace object so that several scripts could be sequentially run without polluting each other's namespace (this seems to work). I would also expect that any python object defined in this namespace would be destroyed when the namespace object goes out of scoped in C++ (obviously this doesn't work, hence this email). Regards, Tanguy -------------- next part -------------- A non-text attachment was scrubbed... Name: main.cpp Type: application/octet-stream Size: 715 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: main.py Type: application/octet-stream Size: 110 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: named_object.cpp Type: application/octet-stream Size: 712 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: named_object.hpp Type: application/octet-stream Size: 357 bytes Desc: not available URL: From merlin66b at gmail.com Mon Oct 13 22:38:12 2008 From: merlin66b at gmail.com (Thomas Berg) Date: Mon, 13 Oct 2008 22:38:12 +0200 Subject: [C++-sig] Object destructor not always called in embedded interpreter In-Reply-To: References: Message-ID: 2008/10/13 Tanguy Fautr? : > Hi, > > I've been trying to sort this issue for some time now, but without any success. Long story short: some objects are never destroyed after executing a script using the embedded Python interpreter and Boost.Python. > > For example, when executing the following script in the embedded interpreter: > > def f() : > o2 = NamedObject('object2') > > o1 = NamedObject('object1') > f() > > > It will print: > > Creating NamedObject 'object1' > Creating NamedObject 'object2' > Destroying NamedObject 'object2' > > > This shows that o1 is never destroyed. Note that if I call Py_Finalize() afterwards, o1 is correctly destroyed (although, from what I understand this function should not be called when using Boost.Python). This leads me to believe that something, somewhere, is holding a reference to that object. > > I've attached the sources of this example. You'll see that before I execute the python script, I create a new namespace object so that several scripts could be sequentially run without polluting each other's namespace (this seems to work). I would also expect that any python object defined in this namespace would be destroyed when the namespace object goes out of scoped in C++ (obviously this doesn't work, hence this email). > > > Regards, > > Tanguy > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > > Hi Tanguy, I'm no python expert, but I think it works as follows: When you import __main__, it is added to the internal list of modules in python. It's __dict__ is therefore also referenced. So even though you no longer reference it, the __dict__ will still be referenced by the interpreter itself, and it's refcount doesn't reach 0 until you finalize the interpreter... So, what can you do? I also wanted to be able to clear the interpreter and re-run scripts in clean namespaces, without re-initializing the interpreter. This can be achieved by calling clear() on the namespace (it's a dictionary). However, that also clears the members "__builtins__", "__doc__" and "__name__", which are needed (at least __builtins__) if you want to execute code again. I solved this too, simply by re-initializing those variables again after clearing the dictionary. I also discovered that a similar initialization enables you to create other modules than the "__main__" module (using PyImport_AddModule instead of import) and execute scripts in those too, which can be useful. I don't know whether this is the "correct" way of doing things though... See below for an example. Regards, Thomas #include using namespace boost::python; Py_Initialize(); try { const char* code; object main_module = import("__main__"); dict module_dict = extract(main_module.attr("__dict__")); code = "a = 3"; exec(code, module_dict, module_dict); // Should succeed code = "b = a"; exec(code, module_dict, module_dict); // Should succeed module_dict.clear(); // deletes all variables module_dict["__builtins__"] = import("__builtin__"); module_dict["__name__"] = "__main__"; module_dict["__doc__"] = object(); code = "c = b"; exec(code, module_dict, module_dict); // Should fail, b not in namespace } catch (error_already_set&) { //Should end up here because of the last exec, complaining about 'b' PyErr_Print(); } From Ralf.Hildebrandt at charite.de Tue Oct 14 00:43:18 2008 From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt) Date: Tue, 14 Oct 2008 00:43:18 +0200 Subject: [C++-sig] Administrativa: List renamed from c++-sig@python.org to cplusplus-sig@python.org Message-ID: <20081013224318.GO15774@charite.de> Hi! This list has been renamed from c++-sig at python.org -> cplusplus-sig at python.org Why? + is the address delimiter mailman uses in it's automatic bounce detection. Having a "+" in the mailing list's name breaks all this. We had quite a number of undeliverable mails (both in and outgoing) because of this. Sorry for the inconvenience. -- Ralf Hildebrandt (i.A. des GB IT) Ralf.Hildebrandt at charite.de Charite - Universit?tsmedizin Berlin Tel. +49 (0)30-450 570-155 Gemeinsame Einrichtung von FU- und HU-Berlin Fax. +49 (0)30-450 570-962 Gesch?ftsbereich IT Standort CBF I'm looking for a job! From tfautre at telenet.be Tue Oct 14 15:48:55 2008 From: tfautre at telenet.be (Tanguy =?utf-8?Q?Fautr=C3=A9?=) Date: Tue, 14 Oct 2008 13:48:55 +0000 Subject: [C++-sig] Object destructor not always called in embedded interpreter Message-ID: > Hi Tanguy, > > I'm no python expert, but I think it works as follows: > When you import __main__, it is added to the internal list of modules > in python. It's __dict__ is therefore also referenced. So even though > you no longer reference it, the __dict__ will still be referenced by > the interpreter itself, and it's refcount doesn't reach 0 until you > finalize the interpreter... > > So, what can you do? I also wanted to be able to clear the interpreter > and re-run scripts in clean namespaces, without re-initializing the > interpreter. > > This can be achieved by calling clear() on the namespace (it's a dictionary). > > However, that also clears the members "__builtins__", "__doc__" and > "__name__", which are needed (at least __builtins__) if you want to > execute code again. I solved this too, simply by re-initializing those > variables again after clearing the dictionary. > > I also discovered that a similar initialization enables you to create > other modules than the "__main__" module (using PyImport_AddModule > instead of import) and execute scripts in those too, which can be > useful. I don't know whether this is the "correct" way of doing things > though... > > See below for an example. > > Regards, > Thomas > > [...] Hi Thomas, Thanks for the advise, it seems to work. It's also good to know how to create other modules. Although, I'm still surprised by this. Because I'm copying the __dict__ of __main__ instead of referencing it (I've even tried directly calling dict.copy()). So I'm surprised by the fact that the interpreter would hold a reference to my copy. I've also tested the following code, and it seems to do the same as yours (as far as I can tell) and can be called several time. Notice how the clear() at the end seems to only affect the copy and not the __main__.__dict__. object main_module = import("__main__"); object main_namespace = main_module.attr("__dict__"); dict new_namespace(main_namespace); object ignored = exec_file("main.py", new_namespace, new_namespace); new_namespace.clear(); Thanks for your help! Cheers, Tanguy PS: I apologize if there is any problem with my posts (e.g. formatting), I'm forced to use my ISP webmail for the moment. From merlin66b at gmail.com Tue Oct 14 20:26:10 2008 From: merlin66b at gmail.com (Thomas Berg) Date: Tue, 14 Oct 2008 20:26:10 +0200 Subject: [C++-sig] Object destructor not always called in embedded interpreter In-Reply-To: References: Message-ID: On Tue, Oct 14, 2008 at 3:48 PM, Tanguy Fautr? wrote: >> Hi Tanguy, >> >> I'm no python expert, but I think it works as follows: >> When you import __main__, it is added to the internal list of modules >> in python. It's __dict__ is therefore also referenced. So even though >> you no longer reference it, the __dict__ will still be referenced by >> the interpreter itself, and it's refcount doesn't reach 0 until you >> finalize the interpreter... >> >> So, what can you do? I also wanted to be able to clear the interpreter >> and re-run scripts in clean namespaces, without re-initializing the >> interpreter. >> >> This can be achieved by calling clear() on the namespace (it's a dictionary). >> >> However, that also clears the members "__builtins__", "__doc__" and >> "__name__", which are needed (at least __builtins__) if you want to >> execute code again. I solved this too, simply by re-initializing those >> variables again after clearing the dictionary. >> >> I also discovered that a similar initialization enables you to create >> other modules than the "__main__" module (using PyImport_AddModule >> instead of import) and execute scripts in those too, which can be >> useful. I don't know whether this is the "correct" way of doing things >> though... >> >> See below for an example. >> >> Regards, >> Thomas >> >> [...] > > > Hi Thomas, > > Thanks for the advise, it seems to work. It's also good to know how to create other modules. > > Although, I'm still surprised by this. Because I'm copying the __dict__ of __main__ instead of referencing it (I've even tried directly calling dict.copy()). So I'm surprised by the fact that the interpreter would hold a reference to my copy. > > I've also tested the following code, and it seems to do the same as yours (as far as I can tell) and can be called several time. Notice how the clear() at the end seems to only affect the copy and not the __main__.__dict__. > > > object main_module = import("__main__"); > object main_namespace = main_module.attr("__dict__"); > dict new_namespace(main_namespace); > > object ignored = exec_file("main.py", new_namespace, new_namespace); > > new_namespace.clear(); > > > Thanks for your help! > Cheers, > > Tanguy > > > PS: I apologize if there is any problem with my posts (e.g. formatting), I'm forced to use my ISP webmail for the moment. > > > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig at python.org > http://mail.python.org/mailman/listinfo/cplusplus-sig > Hi Tanguy, The behaviour surprises me too. In my early attempts at embedding, I tried making copies of the __main__ module's dictionary too. I don't remember why, but after a lot of experiments I ended up just using the original dictonary, and clearing it after use. I didn't even notice your dictionary copying when I wrote the previous post... If someone knows, I would like to get an explanation to this behaviour. There seems to be something "magical" going on. One thing I tried was to make a deep copy of the __main__ module's dictionary. If I remember correctly, that wasn't even possible. Maybe it has some special properties? Maybe we should try dumping all it's attributes? If it was just an ordinary dictionary, deep-copying it should have been possible. Cheers, Thomas From merlin66b at gmail.com Tue Oct 14 20:45:01 2008 From: merlin66b at gmail.com (Thomas Berg) Date: Tue, 14 Oct 2008 20:45:01 +0200 Subject: [C++-sig] Object destructor not always called in embedded interpreter In-Reply-To: References: Message-ID: On Tue, Oct 14, 2008 at 8:26 PM, Thomas Berg wrote: > On Tue, Oct 14, 2008 at 3:48 PM, Tanguy Fautr? wrote: >>> Hi Tanguy, >>> >>> I'm no python expert, but I think it works as follows: >>> When you import __main__, it is added to the internal list of modules >>> in python. It's __dict__ is therefore also referenced. So even though >>> you no longer reference it, the __dict__ will still be referenced by >>> the interpreter itself, and it's refcount doesn't reach 0 until you >>> finalize the interpreter... >>> >>> So, what can you do? I also wanted to be able to clear the interpreter >>> and re-run scripts in clean namespaces, without re-initializing the >>> interpreter. >>> >>> This can be achieved by calling clear() on the namespace (it's a dictionary). >>> >>> However, that also clears the members "__builtins__", "__doc__" and >>> "__name__", which are needed (at least __builtins__) if you want to >>> execute code again. I solved this too, simply by re-initializing those >>> variables again after clearing the dictionary. >>> >>> I also discovered that a similar initialization enables you to create >>> other modules than the "__main__" module (using PyImport_AddModule >>> instead of import) and execute scripts in those too, which can be >>> useful. I don't know whether this is the "correct" way of doing things >>> though... >>> >>> See below for an example. >>> >>> Regards, >>> Thomas >>> >>> [...] >> >> >> Hi Thomas, >> >> Thanks for the advise, it seems to work. It's also good to know how to create other modules. >> >> Although, I'm still surprised by this. Because I'm copying the __dict__ of __main__ instead of referencing it (I've even tried directly calling dict.copy()). So I'm surprised by the fact that the interpreter would hold a reference to my copy. >> >> I've also tested the following code, and it seems to do the same as yours (as far as I can tell) and can be called several time. Notice how the clear() at the end seems to only affect the copy and not the __main__.__dict__. >> >> >> object main_module = import("__main__"); >> object main_namespace = main_module.attr("__dict__"); >> dict new_namespace(main_namespace); >> >> object ignored = exec_file("main.py", new_namespace, new_namespace); >> >> new_namespace.clear(); >> >> >> Thanks for your help! >> Cheers, >> >> Tanguy >> >> >> PS: I apologize if there is any problem with my posts (e.g. formatting), I'm forced to use my ISP webmail for the moment. >> >> >> _______________________________________________ >> Cplusplus-sig mailing list >> Cplusplus-sig at python.org >> http://mail.python.org/mailman/listinfo/cplusplus-sig >> > > > Hi Tanguy, > > The behaviour surprises me too. > > In my early attempts at embedding, I tried making copies of the > __main__ module's dictionary too. I don't remember why, but after a > lot of experiments I ended up just using the original dictonary, and > clearing it after use. I didn't even notice your dictionary copying > when I wrote the previous post... > > If someone knows, I would like to get an explanation to this > behaviour. There seems to be something "magical" going on. One thing I > tried was to make a deep copy of the __main__ module's dictionary. If > I remember correctly, that wasn't even possible. Maybe it has some > special properties? Maybe we should try dumping all it's attributes? > If it was just an ordinary dictionary, deep-copying it should have > been possible. > > Cheers, > Thomas > After one more experiment, I think it is just the __main__ module dict (and using shallow copies of it) that is the problem. If you modify your example to create a custom module + dictionary instead, it works as expected: // ... NamedObject::exportToPython(); { handle<> module_handle( PyImport_AddModule( "__test__") ); object module = object(module_handle); dict module_dict = extract(module.attr("__dict__")); module_dict["__builtins__"] = import("__builtin__"); module_dict["__name__"] = "__test__"; module_dict["__doc__"] = object(); exec_file("main.py", module_dict, module_dict); } // The module_dict goes out of scope, and everything gets deleted By the way, I think you can't call PyImport_AddModule many times with the same name (it will crash python), so if you want to reuse it you have to just clear it and keep a reference to it. Cheers, Thomas From mark at image-engine.com Thu Oct 16 01:56:45 2008 From: mark at image-engine.com (Mark Williams) Date: Wed, 15 Oct 2008 16:56:45 -0700 Subject: [C++-sig] boost.python / bjam Message-ID: <48F6833D.3030302@image-engine.com> Hi, is it possible to build boost.python such that the python version gets embedded in the .so name along with the compiler name, version, multithread flags, etc? For example, "libboost_python25-gcc41-mt-1_35.so" instead of "libboost_python-gcc41-mt-1_35.so" Alternatively, is it possible to build it without the embedded SONAME so that it can be renamed afterwards? Thanks in advance, Mark From furkankuru at gmail.com Fri Oct 17 12:43:30 2008 From: furkankuru at gmail.com (Furkan Kuru) Date: Fri, 17 Oct 2008 13:43:30 +0300 Subject: [C++-sig] [c++-sig] python std::string assignment Message-ID: <3a4a8f930810170343q7ea8fafdma6a4aef3688075f0@mail.gmail.com> Hello, I have exported a struct containing a std::string field and used it one of my py files. I used same py and pyd file in another operating system (vista). It just stuck without giving any errors. I figured out that the std::string field gets a limited space (as it should do) but does not increase it when initialized or assigned with longer sequence of characters. Is it a "quick and good" solution to write a wrapper for std::string and set its reserved space a high number ( reserve(128); ) or export overloaded = operator to python side? thanks in advance. -- Furkan Kuru -------------- next part -------------- An HTML attachment was scrubbed... URL: From seefeld at sympatico.ca Fri Oct 17 12:54:28 2008 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Fri, 17 Oct 2008 06:54:28 -0400 Subject: [C++-sig] [c++-sig] python std::string assignment In-Reply-To: <3a4a8f930810170343q7ea8fafdma6a4aef3688075f0@mail.gmail.com> References: <3a4a8f930810170343q7ea8fafdma6a4aef3688075f0@mail.gmail.com> Message-ID: <48F86EE4.10308@sympatico.ca> Furkan Kuru wrote: > Hello, > > I have exported a struct containing a std::string field and used it > one of my py files. > I used same py and pyd file in another operating system (vista). > It just stuck without giving any errors. > I figured out that the std::string field gets a limited space (as it > should do) > but does not increase it when initialized or assigned with longer > sequence of characters. > > Is it a "quick and good" solution to write a wrapper for std::string > and set its reserved space a high number ( reserve(128); ) > > or > > export overloaded = operator to python side? Sorry, but it isn't clear at all what problem you are seeing. Can you provide a concise description of what behavior you expect, and what you actually get (together with a minimal but complete code snippet) ? In that case someone on this list may be able to help you. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin... From furkankuru at gmail.com Fri Oct 17 13:10:23 2008 From: furkankuru at gmail.com (Furkan Kuru) Date: Fri, 17 Oct 2008 14:10:23 +0300 Subject: [C++-sig] [c++-sig] python std::string assignment In-Reply-To: <48F86EE4.10308@sympatico.ca> References: <3a4a8f930810170343q7ea8fafdma6a4aef3688075f0@mail.gmail.com> <48F86EE4.10308@sympatico.ca> Message-ID: <3a4a8f930810170410o31cc1f8ajdca246f56c85f2b0@mail.gmail.com> Ok, class DataPack { public: std::string name; }; BOOST_PYTHON_MODULE( Data) { class_("DataPack ") .def_readwrite("name", &DataPack ::name); } in my py file: d = Data.DataPack() d.name = "123456789101234567891012345678910" It works fine in xp but breaks application down in a vista installed computer memory corrupt if I set shorter string: d.name = "123" it is fine for vista too. = operator does not work as it does in c++ side, I think. On Fri, Oct 17, 2008 at 1:54 PM, Stefan Seefeld wrote: > Furkan Kuru wrote: > >> Hello, >> >> I have exported a struct containing a std::string field and used it one of >> my py files. >> I used same py and pyd file in another operating system (vista). >> It just stuck without giving any errors. >> I figured out that the std::string field gets a limited space (as it >> should do) >> but does not increase it when initialized or assigned with longer sequence >> of characters. >> >> Is it a "quick and good" solution to write a wrapper for std::string and >> set its reserved space a high number ( reserve(128); ) >> or >> >> export overloaded = operator to python side? >> > > Sorry, but it isn't clear at all what problem you are seeing. Can you > provide a concise description of what behavior you expect, and what you > actually get (together with a minimal but complete code snippet) ? In that > case someone on this list may be able to help you. > > Thanks, > Stefan > > > -- > > ...ich hab' noch einen Koffer in Berlin... > > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig at python.org > http://mail.python.org/mailman/listinfo/cplusplus-sig > -- Furkan Kuru -------------- next part -------------- An HTML attachment was scrubbed... URL: From furkankuru at gmail.com Fri Oct 17 14:51:48 2008 From: furkankuru at gmail.com (Furkan Kuru) Date: Fri, 17 Oct 2008 15:51:48 +0300 Subject: [C++-sig] [c++-sig] python std::string assignment In-Reply-To: <3a4a8f930810170410o31cc1f8ajdca246f56c85f2b0@mail.gmail.com> References: <3a4a8f930810170343q7ea8fafdma6a4aef3688075f0@mail.gmail.com> <48F86EE4.10308@sympatico.ca> <3a4a8f930810170410o31cc1f8ajdca246f56c85f2b0@mail.gmail.com> Message-ID: <3a4a8f930810170551u6009e750u3b0aa1e6b95f9e88@mail.gmail.com> By the way I tried "resize"ing and "reserve"ing of strings by name.resize(1024); or name.reserve(1024); but it did not fix the problem. It seems that it allows up to 15 chars + null character total 16chars. I think strings set longer than 15 chars corrupts the stack. Any help is appreciated. On Fri, Oct 17, 2008 at 2:10 PM, Furkan Kuru wrote: > Ok, > > class DataPack { > > public: > std::string name; > }; > > BOOST_PYTHON_MODULE( Data) > { > class_("DataPack ") > .def_readwrite("name", &DataPack ::name); > } > > > in my py file: > > d = Data.DataPack() > d.name = "123456789101234567891012345678910" > > It works fine in xp but breaks application down in a vista installed > computer memory corrupt > if I set shorter string: d.name = "123" it is fine for vista too. > = operator does not work as it does in c++ side, I think. > > > > On Fri, Oct 17, 2008 at 1:54 PM, Stefan Seefeld wrote: > >> Furkan Kuru wrote: >> >>> Hello, >>> >>> I have exported a struct containing a std::string field and used it one >>> of my py files. >>> I used same py and pyd file in another operating system (vista). >>> It just stuck without giving any errors. >>> I figured out that the std::string field gets a limited space (as it >>> should do) >>> but does not increase it when initialized or assigned with longer >>> sequence of characters. >>> >>> Is it a "quick and good" solution to write a wrapper for std::string and >>> set its reserved space a high number ( reserve(128); ) >>> or >>> >>> export overloaded = operator to python side? >>> >> >> Sorry, but it isn't clear at all what problem you are seeing. Can you >> provide a concise description of what behavior you expect, and what you >> actually get (together with a minimal but complete code snippet) ? In that >> case someone on this list may be able to help you. >> >> Thanks, >> Stefan >> >> >> -- >> >> ...ich hab' noch einen Koffer in Berlin... >> >> _______________________________________________ >> Cplusplus-sig mailing list >> Cplusplus-sig at python.org >> http://mail.python.org/mailman/listinfo/cplusplus-sig >> > > > > -- > Furkan Kuru > -- Furkan Kuru -------------- next part -------------- An HTML attachment was scrubbed... URL: From seefeld at sympatico.ca Fri Oct 17 15:13:08 2008 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Fri, 17 Oct 2008 09:13:08 -0400 Subject: [C++-sig] [c++-sig] python std::string assignment In-Reply-To: <3a4a8f930810170551u6009e750u3b0aa1e6b95f9e88@mail.gmail.com> References: <3a4a8f930810170343q7ea8fafdma6a4aef3688075f0@mail.gmail.com> <48F86EE4.10308@sympatico.ca> <3a4a8f930810170410o31cc1f8ajdca246f56c85f2b0@mail.gmail.com> <3a4a8f930810170551u6009e750u3b0aa1e6b95f9e88@mail.gmail.com> Message-ID: <48F88F64.8070709@sympatico.ca> Furkan Kuru wrote: > By the way > > I tried > "resize"ing and "reserve"ing of strings > by > > name.resize(1024); > or > name.reserve(1024); > > but it did not fix the problem. > > It seems that it allows up to 15 chars + null character total 16chars. > I think strings set longer than 15 chars corrupts the stack. I remember having seen similar behavior in a former life of mine, when I had to work with various MS platforms. I'm pretty sure this is entirely unrelated to your use of boost, but rather caused by your compilation settings such as mixing different Windows runtime libraries for the different components of your application. I can't be more specific, since a) I have long since parted from developing on Windows and b) you don't give any details about your build system. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin... From furkankuru at gmail.com Fri Oct 17 15:37:41 2008 From: furkankuru at gmail.com (Furkan Kuru) Date: Fri, 17 Oct 2008 16:37:41 +0300 Subject: [C++-sig] [c++-sig] python std::string assignment In-Reply-To: <48F88F64.8070709@sympatico.ca> References: <3a4a8f930810170343q7ea8fafdma6a4aef3688075f0@mail.gmail.com> <48F86EE4.10308@sympatico.ca> <3a4a8f930810170410o31cc1f8ajdca246f56c85f2b0@mail.gmail.com> <3a4a8f930810170551u6009e750u3b0aa1e6b95f9e88@mail.gmail.com> <48F88F64.8070709@sympatico.ca> Message-ID: <3a4a8f930810170637v43f72db3n4782fa5f585d2f37@mail.gmail.com> b) I am using Visual Studio 2005 and Windows Xp as development environment. I do not know too much about configuration details. If you can specify any related configuration parameter I can write the setting value. Thanks for your help. Regards, On Fri, Oct 17, 2008 at 4:13 PM, Stefan Seefeld wrote: > Furkan Kuru wrote: > >> By the way >> >> I tried >> "resize"ing and "reserve"ing of strings >> by >> >> name.resize(1024); >> or >> name.reserve(1024); >> >> but it did not fix the problem. >> >> It seems that it allows up to 15 chars + null character total 16chars. >> I think strings set longer than 15 chars corrupts the stack. >> > > I remember having seen similar behavior in a former life of mine, when I > had to work with various MS platforms. I'm pretty sure this is entirely > unrelated to your use of boost, but rather caused by your compilation > settings such as mixing different Windows runtime libraries for the > different components of your application. I can't be more specific, since a) > I have long since parted from developing on Windows and b) you don't give > any details about your build system. > > Regards, > > Stefan > > > -- > > ...ich hab' noch einen Koffer in Berlin... > > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig at python.org > http://mail.python.org/mailman/listinfo/cplusplus-sig > -- Furkan Kuru -------------- next part -------------- An HTML attachment was scrubbed... URL: From seefeld at sympatico.ca Fri Oct 17 15:43:55 2008 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Fri, 17 Oct 2008 09:43:55 -0400 Subject: [C++-sig] [c++-sig] python std::string assignment In-Reply-To: <3a4a8f930810170637v43f72db3n4782fa5f585d2f37@mail.gmail.com> References: <3a4a8f930810170343q7ea8fafdma6a4aef3688075f0@mail.gmail.com> <48F86EE4.10308@sympatico.ca> <3a4a8f930810170410o31cc1f8ajdca246f56c85f2b0@mail.gmail.com> <3a4a8f930810170551u6009e750u3b0aa1e6b95f9e88@mail.gmail.com> <48F88F64.8070709@sympatico.ca> <3a4a8f930810170637v43f72db3n4782fa5f585d2f37@mail.gmail.com> Message-ID: <48F8969B.6010105@sympatico.ca> Furkan Kuru wrote: > b) > I am using Visual Studio 2005 and Windows Xp as development environment. > > I do not know too much about configuration details. You should. Did you compile boost yourself or did you obtain a binary package from somewhere else ? As I said, you have to make sure boost (notably boost.python) is compiled with the same runtime settings (I believe that are the /M, /MD, /MT etc. flags) as your application. What I think may be causing the crashes you are observing is that the initial strings get allocated from a memory pool of one runtime library, and then (attempted to be) deleted in another (during resize), causing the crash. But that's just a guess. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin... From furkankuru at gmail.com Fri Oct 17 16:07:26 2008 From: furkankuru at gmail.com (Furkan Kuru) Date: Fri, 17 Oct 2008 17:07:26 +0300 Subject: [C++-sig] [c++-sig] python std::string assignment In-Reply-To: <48F8969B.6010105@sympatico.ca> References: <3a4a8f930810170343q7ea8fafdma6a4aef3688075f0@mail.gmail.com> <48F86EE4.10308@sympatico.ca> <3a4a8f930810170410o31cc1f8ajdca246f56c85f2b0@mail.gmail.com> <3a4a8f930810170551u6009e750u3b0aa1e6b95f9e88@mail.gmail.com> <48F88F64.8070709@sympatico.ca> <3a4a8f930810170637v43f72db3n4782fa5f585d2f37@mail.gmail.com> <48F8969B.6010105@sympatico.ca> Message-ID: <3a4a8f930810170707r700f9043n4cf6cddf5672da56@mail.gmail.com> Definitely, but On Fri, Oct 17, 2008 at 4:43 PM, Stefan Seefeld wrote: > Furkan Kuru wrote: > >> b) >> I am using Visual Studio 2005 and Windows Xp as development environment. >> >> I do not know too much about configuration details. >> > > You should. Did you compile boost yourself or did you obtain a binary > package from somewhere else ? As I said, you have to make sure boost > (notably boost.python) is compiled with the same runtime settings (I believe > that are the /M, /MD, /MT etc. flags) as your application. > Definitely, I will look into the details of build configuration. I complied boost myself and the runtime settings are all same: /MD I have a main application (exe) a pyd and boost_python-vc80-mt-1_36.dll > > What I think may be causing the crashes you are observing is that the > initial strings get allocated from a memory pool of one runtime library, and > then (attempted to be) deleted in another (during resize), causing the > crash. But that's just a guess. > > I tried setting strings to 30 chars in the constructors to force the size allocation in another way but no change same problem. name= "1234567890123456789012345678901234567890"; I do not know if it fails while deleting but it booms just during assignment. I dont think it reaches delete time. Do different configured PCs have different memory allocation routines? Because a friend of mine tested the application on a different computer running same os (vista) without anyproblems. Regards, -- Furkan Kuru -------------- next part -------------- An HTML attachment was scrubbed... URL: From seefeld at sympatico.ca Fri Oct 17 16:11:25 2008 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Fri, 17 Oct 2008 10:11:25 -0400 Subject: [C++-sig] [c++-sig] python std::string assignment In-Reply-To: <3a4a8f930810170707r700f9043n4cf6cddf5672da56@mail.gmail.com> References: <3a4a8f930810170343q7ea8fafdma6a4aef3688075f0@mail.gmail.com> <48F86EE4.10308@sympatico.ca> <3a4a8f930810170410o31cc1f8ajdca246f56c85f2b0@mail.gmail.com> <3a4a8f930810170551u6009e750u3b0aa1e6b95f9e88@mail.gmail.com> <48F88F64.8070709@sympatico.ca> <3a4a8f930810170637v43f72db3n4782fa5f585d2f37@mail.gmail.com> <48F8969B.6010105@sympatico.ca> <3a4a8f930810170707r700f9043n4cf6cddf5672da56@mail.gmail.com> Message-ID: <48F89D0D.8040407@sympatico.ca> Furkan Kuru wrote: > > > Do different configured PCs have different memory allocation routines? > Because a friend of mine tested the application on a different > computer running same os (vista) without anyproblems. I have no idea what you mean by 'differently configured PCs', but I'd suggest you take that question to a Windows-specific forum. Here this is entirely off-topic. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin... From adrien.saladin at gmail.com Fri Oct 17 16:28:42 2008 From: adrien.saladin at gmail.com (Adrien Saladin) Date: Fri, 17 Oct 2008 16:28:42 +0200 Subject: [C++-sig] [pybindgen] custom selections with pybindgen and pygccxml Message-ID: Hi, I would like to give pybindgen a try on a C++ library. I'm currently using Py++ (which is great) to automatically generate the correct interface. Before seriously playing with pybindgen, I need to know if it is possible to do a fine selection of which classes and methods has to be exposed to python. For some reasons I need to expose to python only a part of a C++ library, but for this part I would like to do it in an automated fashion (ie: use pygccxml) Is it possible to do a kind of "exclude all classes and methods" command to the ModuleParser object (or another pybindgen/pygccxml object) and then only include a few classes one by one together with pygccxml ? Is it possible to remove a single method from a class by name or argument types ? Are pre_scan_hook or post_scan_hook suitable for this ? Another question: on the features page (http://code.google.com/p/pybindgen/wiki/Features) it is said that multiple inheritance is not yet supported. What does this exactly mean ? It is not possible to expose a class C which publicly inherits from A and B ? Thanks, Adrien From dave at boostpro.com Fri Oct 17 16:31:34 2008 From: dave at boostpro.com (David Abrahams) Date: Fri, 17 Oct 2008 10:31:34 -0400 Subject: [C++-sig] [c++-sig] python std::string assignment In-Reply-To: <48F88F64.8070709@sympatico.ca> (Stefan Seefeld's message of "Fri, 17 Oct 2008 09:13:08 -0400") References: <3a4a8f930810170343q7ea8fafdma6a4aef3688075f0@mail.gmail.com> <48F86EE4.10308@sympatico.ca> <3a4a8f930810170410o31cc1f8ajdca246f56c85f2b0@mail.gmail.com> <3a4a8f930810170551u6009e750u3b0aa1e6b95f9e88@mail.gmail.com> <48F88F64.8070709@sympatico.ca> Message-ID: <87skqvjnsp.fsf@mcbain.luannocracy.com> on Fri Oct 17 2008, Stefan Seefeld wrote: > Furkan Kuru wrote: >> By the way >> >> I tried >> "resize"ing and "reserve"ing of strings >> by >> >> name.resize(1024); >> or >> name.reserve(1024); >> >> but it did not fix the problem. >> >> It seems that it allows up to 15 chars + null character total 16chars. >> I think strings set longer than 15 chars corrupts the stack. > > I remember having seen similar behavior in a former life of mine, when > I had to work with various MS platforms. I'm pretty sure this is > entirely unrelated to your use of boost, but rather caused by your > compilation settings such as mixing different Windows runtime > libraries for the different components of your application. Yes, that seems very likely; this looks a bit like the small string optimization gone awry. Perhaps you have mixed the MS runtime lib headers with a different version of the binary library. -- Dave Abrahams BoostPro Computing http://www.boostpro.com From furkankuru at gmail.com Fri Oct 17 16:49:58 2008 From: furkankuru at gmail.com (Furkan Kuru) Date: Fri, 17 Oct 2008 17:49:58 +0300 Subject: [C++-sig] [c++-sig] python std::string assignment In-Reply-To: <3a4a8f930810170746v43ba4a4bv85e45335dc56d8ee@mail.gmail.com> References: <3a4a8f930810170343q7ea8fafdma6a4aef3688075f0@mail.gmail.com> <48F86EE4.10308@sympatico.ca> <3a4a8f930810170410o31cc1f8ajdca246f56c85f2b0@mail.gmail.com> <3a4a8f930810170551u6009e750u3b0aa1e6b95f9e88@mail.gmail.com> <48F88F64.8070709@sympatico.ca> <87skqvjnsp.fsf@mcbain.luannocracy.com> <3a4a8f930810170746v43ba4a4bv85e45335dc56d8ee@mail.gmail.com> Message-ID: <3a4a8f930810170749v32639a4bu7cb3c42924683c4c@mail.gmail.com> Apart from assinging a string passing a "longer" string to a function does not work either. example: void createNavi(std::string naviname,std::string url,RelativePosition pos,int sizeX,int sizeY); class_("PyNaviManager") .def("createNavi", &NaviManagerWrapper::createNavi) ; in python fail line: pyNaviManager.createNavi("activation","local://activation.html",Center,800,400) I think the second parameter "local://activation.html" can not be converted to std::string. Regards, On Fri, Oct 17, 2008 at 5:46 PM, Furkan Kuru wrote: > > Yes, that seems very likely; this looks a bit like the small string >> optimization gone awry. Perhaps you have mixed the MS runtime lib >> headers with a different version of the binary library. >> >> > > Is there any way to remove this string optimization. Or How can I trace and > find these mixed headers to fix the problem? > > > -- > Furkan Kuru > -- Furkan Kuru -------------- next part -------------- An HTML attachment was scrubbed... URL: From furkankuru at gmail.com Fri Oct 17 16:46:04 2008 From: furkankuru at gmail.com (Furkan Kuru) Date: Fri, 17 Oct 2008 17:46:04 +0300 Subject: [C++-sig] [c++-sig] python std::string assignment In-Reply-To: <87skqvjnsp.fsf@mcbain.luannocracy.com> References: <3a4a8f930810170343q7ea8fafdma6a4aef3688075f0@mail.gmail.com> <48F86EE4.10308@sympatico.ca> <3a4a8f930810170410o31cc1f8ajdca246f56c85f2b0@mail.gmail.com> <3a4a8f930810170551u6009e750u3b0aa1e6b95f9e88@mail.gmail.com> <48F88F64.8070709@sympatico.ca> <87skqvjnsp.fsf@mcbain.luannocracy.com> Message-ID: <3a4a8f930810170746v43ba4a4bv85e45335dc56d8ee@mail.gmail.com> > Yes, that seems very likely; this looks a bit like the small string > optimization gone awry. Perhaps you have mixed the MS runtime lib > headers with a different version of the binary library. > > Is there any way to remove this string optimization. Or How can I trace and find these mixed headers to fix the problem? -- Furkan Kuru -------------- next part -------------- An HTML attachment was scrubbed... URL: From seefeld at sympatico.ca Fri Oct 17 16:53:51 2008 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Fri, 17 Oct 2008 10:53:51 -0400 Subject: [C++-sig] [c++-sig] python std::string assignment In-Reply-To: <3a4a8f930810170749v32639a4bu7cb3c42924683c4c@mail.gmail.com> References: <3a4a8f930810170343q7ea8fafdma6a4aef3688075f0@mail.gmail.com> <48F86EE4.10308@sympatico.ca> <3a4a8f930810170410o31cc1f8ajdca246f56c85f2b0@mail.gmail.com> <3a4a8f930810170551u6009e750u3b0aa1e6b95f9e88@mail.gmail.com> <48F88F64.8070709@sympatico.ca> <87skqvjnsp.fsf@mcbain.luannocracy.com> <3a4a8f930810170746v43ba4a4bv85e45335dc56d8ee@mail.gmail.com> <3a4a8f930810170749v32639a4bu7cb3c42924683c4c@mail.gmail.com> Message-ID: <48F8A6FF.9090108@sympatico.ca> Furkan Kuru wrote: > Apart from assinging a string > passing a "longer" string to a function does not work either. > "does not work" isn't an acceptable failure description. Please be specific. > I think the second parameter "local://activation.html" can not be > converted to std::string. What makes you think that ? I reiterate: post a minimal complete test case, stating what behavior you expect, and what you actually get. (Also, I'd suggest you pass std::string argumnts by const-reference, instead of by-value. You are forcing temporaries for no reason.) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin... From furkankuru at gmail.com Fri Oct 17 17:13:41 2008 From: furkankuru at gmail.com (Furkan Kuru) Date: Fri, 17 Oct 2008 18:13:41 +0300 Subject: [C++-sig] [c++-sig] python std::string assignment In-Reply-To: <48F8A6FF.9090108@sympatico.ca> References: <3a4a8f930810170343q7ea8fafdma6a4aef3688075f0@mail.gmail.com> <48F86EE4.10308@sympatico.ca> <3a4a8f930810170410o31cc1f8ajdca246f56c85f2b0@mail.gmail.com> <3a4a8f930810170551u6009e750u3b0aa1e6b95f9e88@mail.gmail.com> <48F88F64.8070709@sympatico.ca> <87skqvjnsp.fsf@mcbain.luannocracy.com> <3a4a8f930810170746v43ba4a4bv85e45335dc56d8ee@mail.gmail.com> <3a4a8f930810170749v32639a4bu7cb3c42924683c4c@mail.gmail.com> <48F8A6FF.9090108@sympatico.ca> Message-ID: <3a4a8f930810170813g13b2256of58c4e93f27b4bd9@mail.gmail.com> On Fri, Oct 17, 2008 at 5:53 PM, Stefan Seefeld wrote: > Furkan Kuru wrote: > >> Apart from assinging a string >> passing a "longer" string to a function does not work either. >> >> > "does not work" isn't an acceptable failure description. Please be > specific. > As in the case of given example: something like segmentation fault occurs. > > I think the second parameter "local://activation.html" can not be >> converted to std::string. >> > What makes you think that ? I reiterate: post a minimal complete test case, > stating what behavior you expect, and what you actually get. > When I use shorter string it works. Ok I will create a very simple test case and post. > > (Also, I'd suggest you pass std::string argumnts by const-reference, > instead of by-value. You are forcing temporaries for no reason.) > ok I have changed it: void createNavi(const std::string& naviname,const std::string& url,RelativePosition pos,int sizeX,int sizeY) > > Thanks I thank you. -- Furkan Kuru -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthew.Scouten at tradingtechnologies.com Fri Oct 17 17:34:20 2008 From: Matthew.Scouten at tradingtechnologies.com (Matthew Scouten (TT)) Date: Fri, 17 Oct 2008 10:34:20 -0500 Subject: [C++-sig] [c++-sig] python std::string assignment In-Reply-To: <87skqvjnsp.fsf@mcbain.luannocracy.com> References: <3a4a8f930810170343q7ea8fafdma6a4aef3688075f0@mail.gmail.com><48F86EE4.10308@sympatico.ca><3a4a8f930810170410o31cc1f8ajdca246f56c85f2b0@mail.gmail.com><3a4a8f930810170551u6009e750u3b0aa1e6b95f9e88@mail.gmail.com><48F88F64.8070709@sympatico.ca> <87skqvjnsp.fsf@mcbain.luannocracy.com> Message-ID: <32490DFF7774554A85D65D23A9F0F93809411A94@chiex01> I saw a problem vary similar to this when I was accidently mixing debug and non-debug libraries in the same pyd. It seems that the debug version of MS's std::string has an some kind of extra debug flag in it. If you mix them you get corruption and other weird behavior. -----Original Message----- From: cplusplus-sig-bounces+matthew.scouten=tradingtechnologies.com at python.org [mailto:cplusplus-sig-bounces+matthew.scouten=tradingtechnologies.com at py thon.org] On Behalf Of David Abrahams Sent: Friday, October 17, 2008 9:32 AM To: Development of Python/C++ integration Subject: Re: [C++-sig] [c++-sig] python std::string assignment on Fri Oct 17 2008, Stefan Seefeld wrote: > Furkan Kuru wrote: >> By the way >> >> I tried >> "resize"ing and "reserve"ing of strings >> by >> >> name.resize(1024); >> or >> name.reserve(1024); >> >> but it did not fix the problem. >> >> It seems that it allows up to 15 chars + null character total 16chars. >> I think strings set longer than 15 chars corrupts the stack. > > I remember having seen similar behavior in a former life of mine, when > I had to work with various MS platforms. I'm pretty sure this is > entirely unrelated to your use of boost, but rather caused by your > compilation settings such as mixing different Windows runtime > libraries for the different components of your application. Yes, that seems very likely; this looks a bit like the small string optimization gone awry. Perhaps you have mixed the MS runtime lib headers with a different version of the binary library. -- Dave Abrahams BoostPro Computing http://www.boostpro.com _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig at python.org http://mail.python.org/mailman/listinfo/cplusplus-sig From gjcarneiro at gmail.com Fri Oct 17 18:37:24 2008 From: gjcarneiro at gmail.com (Gustavo Carneiro) Date: Fri, 17 Oct 2008 17:37:24 +0100 Subject: [C++-sig] [pybindgen] custom selections with pybindgen and pygccxml In-Reply-To: References: Message-ID: 2008/10/17 Adrien Saladin > Hi, > > I would like to give pybindgen a try on a C++ library. I'm currently > using Py++ (which is great) to automatically generate the correct > interface. > Before seriously playing with pybindgen, I need to know if it is > possible to do a fine selection of which classes and methods has to be > exposed to python. > For some reasons I need to expose to python only a part of a C++ > library, but for this part I would like to do it in an automated > fashion (ie: use pygccxml) > > Is it possible to do a kind of "exclude all classes and methods" > command to the ModuleParser object (or another pybindgen/pygccxml > object) and then only include a few classes one by one together with > pygccxml ? Is it possible to remove a single method from a class by > name or argument types ? > Are pre_scan_hook or post_scan_hook suitable for this ? The pre_scan_hook can be used to exclude classes or methods: from pygccxml.declarations.class_declaration import class_t def pre_scan_hook(module_parser, pygccxml_definition, global_annotations, parameter_annotations): if isinstance(pygccxml_definition, class_t): if pygccxml_definition.name not in ["Class1", "Class2"]: global_annotations['ignore'] = None > Another question: on the features page > (http://code.google.com/p/pybindgen/wiki/Features) it is said that > multiple inheritance is not yet supported. What does this exactly mean > ? It is not possible to expose a class C which publicly inherits from > A and B ? Correct. That is not possible. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at boostpro.com Fri Oct 17 19:17:05 2008 From: dave at boostpro.com (David Abrahams) Date: Fri, 17 Oct 2008 13:17:05 -0400 Subject: [C++-sig] [c++-sig] python std::string assignment In-Reply-To: <3a4a8f930810170746v43ba4a4bv85e45335dc56d8ee@mail.gmail.com> (Furkan Kuru's message of "Fri, 17 Oct 2008 17:46:04 +0300") References: <3a4a8f930810170343q7ea8fafdma6a4aef3688075f0@mail.gmail.com> <48F86EE4.10308@sympatico.ca> <3a4a8f930810170410o31cc1f8ajdca246f56c85f2b0@mail.gmail.com> <3a4a8f930810170551u6009e750u3b0aa1e6b95f9e88@mail.gmail.com> <48F88F64.8070709@sympatico.ca> <87skqvjnsp.fsf@mcbain.luannocracy.com> <3a4a8f930810170746v43ba4a4bv85e45335dc56d8ee@mail.gmail.com> Message-ID: <87y70ni1ke.fsf@mcbain.luannocracy.com> on Fri Oct 17 2008, "Furkan Kuru" wrote: > Yes, that seems very likely; this looks a bit like the small string > optimization gone awry. Perhaps you have mixed the MS runtime lib > headers with a different version of the binary library. > > Is there any way to remove this string optimization. Or How can I trace and find > these mixed headers to fix the problem? I don't know. There are many people in the world much better-qualified to help you with this problem than I am. I suggest take your question to a MSVC-specific group. As Stefan said, it's unlikely that it has anything to do with boost or python. -- Dave Abrahams BoostPro Computing http://www.boostpro.com From roman.yakovenko at gmail.com Mon Oct 20 21:55:53 2008 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Mon, 20 Oct 2008 21:55:53 +0200 Subject: [C++-sig] [ANN] Py++ - 1.0 Message-ID: <7465b6170810201255p45f2eb02m455d4ca1431c0276@mail.gmail.com> Hello! I'm pleased to announce the 1.0 release of Py++. What is Py++? ========= Py++ is an object-oriented framework for creating a code generator for Boost.Python library. Where is Py++? ============== Site: http://language-binding.net/pyplusplus/pyplusplus.html Download: http://language-binding.net/pyplusplus/download.html What's new? =========== Features -------- * Algorightm, which defines what virtual functions should be redefined was improved. * Exposing "C" code became easier - Py++ is able to generate ``ctypes`` friendly code. * Support for ``boost::python::make_constructor`` functionality was added. * Support for unions and unnamed classes was added. Bug fixes --------- * Indexing Suite V2 - few bugs were fixed. Contributors: * Julian Scheid * Oliver Schweitzer For a more complete list, with links to documentation, please see the news: http://language-binding.net/pyplusplus/history/history.html -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ From beau at open-source-staffing.com Tue Oct 21 05:02:22 2008 From: beau at open-source-staffing.com (Beau Gould) Date: Mon, 20 Oct 2008 23:02:22 -0400 Subject: [C++-sig] [JOB] Systems Engineer, San Francisco, CA | Relo OK In-Reply-To: <7465b6170810201255p45f2eb02m455d4ca1431c0276@mail.gmail.com> Message-ID: <1E586A6F76AC4F94823AF72686E4336D@EMACHINE> Job Title: Software Engineer--Systems Location: San Francisco - Relocation assistance provided Duration: Full Time/Permanent Salary: 90-130k DOE Our client is home to a new type of search that makes it easy to find subjective information. Starting in early 2008 the company raised seed financing from a number of premier angel investors and carefully grew a high-caliber engineering team. Today, the company includes founders from more than a half-dozen successful startups, four AI Ph.D.s, and engineers from Silicon Valley's major technology companies. The engineers are careful implementers who are curious about how things work. They lean on large levers to get more done, faster, and enjoy applying new tools to the new opportunities afforded by today's web. They endeavor to solve real-world problems for real people (including the rest of the company), and aren't afraid to think big. As a systems engineer, you bring strong technical chops and a desire to think big and build our systems to match. General requirements: * B.S. in CS or Computer engineering from a leading institution (M.S. preferred) * 2+ years direct technical experience in Systems Engineering for web-based products with experience in distributed systems, network programming, database implementation, web search infrastructure, or storage systems in Java, C++, or Python * Affinity for rapid prototyping * Flexibility when faced with complex challenges To be considered, please submit your resume along with your salary requirements to bg @ capitalmarketsp.com Beau Gould Executive Advisor Capital Markets Placement 718-598-1411 bg @ capitalmarketsp.com From dmahler at gmail.com Wed Oct 22 00:40:08 2008 From: dmahler at gmail.com (Daniel Mahler) Date: Wed, 22 Oct 2008 00:40:08 +0200 Subject: [C++-sig] [JOB] Systems Engineer, San Francisco, CA | Relo OK In-Reply-To: <1E586A6F76AC4F94823AF72686E4336D@EMACHINE> References: <7465b6170810201255p45f2eb02m455d4ca1431c0276@mail.gmail.com> <1E586A6F76AC4F94823AF72686E4336D@EMACHINE> Message-ID: Hello Bea, I would be interested in finding out more about this position. You can view my resume at http://www.linkedin.com/in/dmahler regards Daniel Mahler On Tue, Oct 21, 2008 at 5:02 AM, Beau Gould wrote: > Job Title: Software Engineer--Systems > Location: San Francisco - Relocation assistance provided > Duration: Full Time/Permanent > Salary: 90-130k DOE > > Our client is home to a new type of search that makes it easy to find > subjective information. Starting in early 2008 the company raised seed > financing from a number of premier angel investors and carefully grew a > high-caliber engineering team. Today, the company includes founders from > more than a half-dozen successful startups, four AI Ph.D.s, and > engineers from Silicon Valley's major technology companies. > > The engineers are careful implementers who are curious about how things > work. They lean on large levers to get more done, faster, and enjoy > applying new tools to the new opportunities afforded by today's web. > They endeavor to solve real-world problems for real people (including > the rest of the company), and aren't afraid to think big. As a systems > engineer, you bring strong technical chops and a desire to think big and > build our systems to match. > > General requirements: > * B.S. in CS or Computer engineering from a leading institution (M.S. > preferred) > * 2+ years direct technical experience in Systems Engineering for > web-based products with experience in distributed systems, network > programming, database implementation, web search infrastructure, or > storage systems in Java, C++, or Python > * Affinity for rapid prototyping > * Flexibility when faced with complex challenges > > To be considered, please submit your resume along with your salary > requirements to bg @ capitalmarketsp.com > > Beau Gould > Executive Advisor > Capital Markets Placement > 718-598-1411 > bg @ capitalmarketsp.com > > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig at python.org > http://mail.python.org/mailman/listinfo/cplusplus-sig > From dmahler at gmail.com Wed Oct 22 00:53:06 2008 From: dmahler at gmail.com (Daniel Mahler) Date: Wed, 22 Oct 2008 00:53:06 +0200 Subject: [C++-sig] [JOB] Systems Engineer, San Francisco, CA | Relo OK In-Reply-To: References: <7465b6170810201255p45f2eb02m455d4ca1431c0276@mail.gmail.com> <1E586A6F76AC4F94823AF72686E4336D@EMACHINE> Message-ID: hmm, that was not meant to go to the whole world ... On Wed, Oct 22, 2008 at 12:40 AM, Daniel Mahler wrote: > Hello Bea, > > I would be interested in finding out more about this position. > You can view my resume at http://www.linkedin.com/in/dmahler > > regards > Daniel Mahler > > On Tue, Oct 21, 2008 at 5:02 AM, Beau Gould > wrote: >> Job Title: Software Engineer--Systems >> Location: San Francisco - Relocation assistance provided >> Duration: Full Time/Permanent >> Salary: 90-130k DOE >> >> Our client is home to a new type of search that makes it easy to find >> subjective information. Starting in early 2008 the company raised seed >> financing from a number of premier angel investors and carefully grew a >> high-caliber engineering team. Today, the company includes founders from >> more than a half-dozen successful startups, four AI Ph.D.s, and >> engineers from Silicon Valley's major technology companies. >> >> The engineers are careful implementers who are curious about how things >> work. They lean on large levers to get more done, faster, and enjoy >> applying new tools to the new opportunities afforded by today's web. >> They endeavor to solve real-world problems for real people (including >> the rest of the company), and aren't afraid to think big. As a systems >> engineer, you bring strong technical chops and a desire to think big and >> build our systems to match. >> >> General requirements: >> * B.S. in CS or Computer engineering from a leading institution (M.S. >> preferred) >> * 2+ years direct technical experience in Systems Engineering for >> web-based products with experience in distributed systems, network >> programming, database implementation, web search infrastructure, or >> storage systems in Java, C++, or Python >> * Affinity for rapid prototyping >> * Flexibility when faced with complex challenges >> >> To be considered, please submit your resume along with your salary >> requirements to bg @ capitalmarketsp.com >> >> Beau Gould >> Executive Advisor >> Capital Markets Placement >> 718-598-1411 >> bg @ capitalmarketsp.com >> >> _______________________________________________ >> Cplusplus-sig mailing list >> Cplusplus-sig at python.org >> http://mail.python.org/mailman/listinfo/cplusplus-sig >> > From monty at inaugust.com Wed Oct 22 01:06:40 2008 From: monty at inaugust.com (Monty Taylor) Date: Tue, 21 Oct 2008 16:06:40 -0700 Subject: [C++-sig] [JOB] Systems Engineer, San Francisco, CA | Relo OK In-Reply-To: References: <7465b6170810201255p45f2eb02m455d4ca1431c0276@mail.gmail.com> <1E586A6F76AC4F94823AF72686E4336D@EMACHINE> Message-ID: <48FE6080.1090304@inaugust.com> Daniel Mahler wrote: > hmm, that was not meant to go to the whole world ... BWHAHAHA! Now we know your secret plans!!! > On Wed, Oct 22, 2008 at 12:40 AM, Daniel Mahler wrote: >> Hello Bea, >> >> I would be interested in finding out more about this position. >> You can view my resume at http://www.linkedin.com/in/dmahler >> >> regards >> Daniel Mahler >> >> On Tue, Oct 21, 2008 at 5:02 AM, Beau Gould >> wrote: >>> Job Title: Software Engineer--Systems >>> Location: San Francisco - Relocation assistance provided >>> Duration: Full Time/Permanent >>> Salary: 90-130k DOE >>> >>> Our client is home to a new type of search that makes it easy to find >>> subjective information. Starting in early 2008 the company raised seed >>> financing from a number of premier angel investors and carefully grew a >>> high-caliber engineering team. Today, the company includes founders from >>> more than a half-dozen successful startups, four AI Ph.D.s, and >>> engineers from Silicon Valley's major technology companies. >>> >>> The engineers are careful implementers who are curious about how things >>> work. They lean on large levers to get more done, faster, and enjoy >>> applying new tools to the new opportunities afforded by today's web. >>> They endeavor to solve real-world problems for real people (including >>> the rest of the company), and aren't afraid to think big. As a systems >>> engineer, you bring strong technical chops and a desire to think big and >>> build our systems to match. >>> >>> General requirements: >>> * B.S. in CS or Computer engineering from a leading institution (M.S. >>> preferred) >>> * 2+ years direct technical experience in Systems Engineering for >>> web-based products with experience in distributed systems, network >>> programming, database implementation, web search infrastructure, or >>> storage systems in Java, C++, or Python >>> * Affinity for rapid prototyping >>> * Flexibility when faced with complex challenges >>> >>> To be considered, please submit your resume along with your salary >>> requirements to bg @ capitalmarketsp.com >>> >>> Beau Gould >>> Executive Advisor >>> Capital Markets Placement >>> 718-598-1411 >>> bg @ capitalmarketsp.com >>> >>> _______________________________________________ >>> Cplusplus-sig mailing list >>> Cplusplus-sig at python.org >>> http://mail.python.org/mailman/listinfo/cplusplus-sig >>> > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig at python.org > http://mail.python.org/mailman/listinfo/cplusplus-sig > From pixcelrunner at yahoo.com Wed Oct 22 22:14:06 2008 From: pixcelrunner at yahoo.com (pixcelrunner) Date: Wed, 22 Oct 2008 20:14:06 +0000 Subject: [C++-sig] Gambir Sarawak ??? Message-ID: <20081022122103.C662E1E4013@bag.python.org> Hi..... Wanna Know About Gambir Sarawak??? More Information please visit here: mygambirsarawak.blogspot.com or www.pixcelrunner.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 4579 bytes Desc: not available URL: From paniq at paniq.org Thu Oct 23 15:44:05 2008 From: paniq at paniq.org (Leonard Ritter) Date: Thu, 23 Oct 2008 15:44:05 +0200 Subject: [C++-sig] returning vector arrays and multiple values Message-ID: <32c88000810230644j3541ca0axeb5c81f6de4935e4@mail.gmail.com> i have a function which i wish to wrap, which returns a float buffer and an integer: std::vector get_recording_buffer(/* out */ size_t &write_ptr); alternatively, the function could also just return a pointer to a float array: const float *get_recording_buffer(/* out */ size_t &size, /* out */ size_t &write_ptr); the signature doesn't matter as much as the intention here. using boost.python, how can i export the method so its appropriate python counterpart would be something like: def get_recording_buffer(): return (, ) i skimmed through the tutorial, the faq and the wiki, but found nothing related to these two issues. thank you in advance :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From seefeld at sympatico.ca Thu Oct 23 16:03:03 2008 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Thu, 23 Oct 2008 10:03:03 -0400 Subject: [C++-sig] returning vector arrays and multiple values In-Reply-To: <32c88000810230644j3541ca0axeb5c81f6de4935e4@mail.gmail.com> References: <32c88000810230644j3541ca0axeb5c81f6de4935e4@mail.gmail.com> Message-ID: <49008417.1090206@sympatico.ca> Leonard Ritter wrote: > i have a function which i wish to wrap, which returns a float buffer > and an integer: > > std::vector get_recording_buffer(/* out */ size_t &write_ptr); > > alternatively, the function could also just return a pointer to a > float array: > > const float *get_recording_buffer(/* out */ size_t &size, /* out */ > size_t &write_ptr); > > the signature doesn't matter as much as the intention here. > > using boost.python, how can i export the method so its appropriate > python counterpart would be something like: > > def get_recording_buffer(): > return (, ) object get_recording_buffer_wrapper() { size_t write_ptr; std::vector buffer = get_recording_buffer(write_ptr); list l; for (std::vector::iterator i = buffer.begin(); i != buffer.end(); ++i) l.append(*i); return make_tuple(l, write_ptr); } HTH, Stefan -- ...ich hab' noch einen Koffer in Berlin... From craig.bosma at gmail.com Thu Oct 23 18:14:34 2008 From: craig.bosma at gmail.com (Craig Bosma) Date: Thu, 23 Oct 2008 11:14:34 -0500 Subject: [C++-sig] Help wrapping an unconventional setter Message-ID: <73b237cd0810230914l33ea3e84ua57b652bbfafb6bb@mail.gmail.com> Hi, I'm pretty new to Boost.Python, and am trying to wrap a simple class similar to: class Foo { public: float value() const { return value_; } float& value() { return value_; } private: float value_; }; I have no problem wrapping value() as a read-only property, like so: class_("Foo") .add_property("value", (float (Foo::*)(void) const)&Foo::value) ; But I'm having a difficult time determining how to wrap the unconventional 'setter' method for read-write property access; as you can see it returns a non-const reference to be set rather than taking the new value as an argument. Any suggestions? Thanks, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From seefeld at sympatico.ca Thu Oct 23 18:36:08 2008 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Thu, 23 Oct 2008 12:36:08 -0400 Subject: [C++-sig] Help wrapping an unconventional setter In-Reply-To: <73b237cd0810230914l33ea3e84ua57b652bbfafb6bb@mail.gmail.com> References: <73b237cd0810230914l33ea3e84ua57b652bbfafb6bb@mail.gmail.com> Message-ID: <4900A7F8.2080605@sympatico.ca> Craig Bosma wrote: > Hi, > > I'm pretty new to Boost.Python, and am trying to wrap a simple class > similar to: > > class Foo { > public: > float value() const { return value_; } > float& value() { return value_; } > private: > float value_; > }; > > I have no problem wrapping value() as a read-only property, like so: > > class_("Foo") > .add_property("value", (float (Foo::*)(void) const)&Foo::value) > ; > > But I'm having a difficult time determining how to wrap the > unconventional 'setter' method for read-write property access; as you > can see it returns a non-const reference to be set rather than taking > the new value as an argument. Any suggestions? Use a thin wrapper function, such as: void Foo_setter(Foo &foo, float v) { foo.value() = v;} ... float (Foo::*getter)() const = &Foo::value; // to disambiguate class_ foo("Foo"); foo.add_property("value", getter, Foo_setter); HTH, Stefan ... class_("Foo") .add_property("value", Foo::value, setter); should > > Thanks, > > Craig > ------------------------------------------------------------------------ > > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig at python.org > http://mail.python.org/mailman/listinfo/cplusplus-sig -- ...ich hab' noch einen Koffer in Berlin... From paniq at paniq.org Thu Oct 23 22:53:35 2008 From: paniq at paniq.org (Leonard Ritter) Date: Thu, 23 Oct 2008 22:53:35 +0200 Subject: [C++-sig] returning vector arrays and multiple values In-Reply-To: <49008417.1090206@sympatico.ca> References: <32c88000810230644j3541ca0axeb5c81f6de4935e4@mail.gmail.com> <49008417.1090206@sympatico.ca> Message-ID: <32c88000810231353r35ba710fga7b40aa9d9dce3a0@mail.gmail.com> thanks for your help, the solution i used was this one: #include #include using namespace boost::python; tuple py_audio_get_recording_buffer() { int write_ptr = 0; std::vector buffer = audio_get_recording_buffer(write_ptr); return make_tuple(buffer, write_ptr); } BOOST_PYTHON_MODULE(nucleus) { class_< std::vector >("vector_float") .def(vector_indexing_suite< std::vector >()); def("get_recording_buffer", py_audio_get_recording_buffer); } On Thu, Oct 23, 2008 at 4:03 PM, Stefan Seefeld wrote: > object get_recording_buffer_wrapper() > { > size_t write_ptr; > std::vector buffer = get_recording_buffer(write_ptr); > list l; > for (std::vector::iterator i = buffer.begin(); i != buffer.end(); ++i) > l.append(*i); > return make_tuple(l, write_ptr); > } > > > HTH, > Stefan > > -- > > ...ich hab' noch einen Koffer in Berlin... > > _______________________________________________ > 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: From rcdailey at gmail.com Fri Oct 24 19:59:57 2008 From: rcdailey at gmail.com (Robert Dailey) Date: Fri, 24 Oct 2008 12:59:57 -0500 Subject: [C++-sig] How to create embedded packages? Message-ID: <496954360810241059q72efa761lc3777bf878c246c2@mail.gmail.com> Hi, I am currently embedding the python interpreter. I'm doing this because I want my application to be able to execute python scripts. I'm also using Boost.Python to create modules to extend the functionality of python scripts executed through my application. Note that no PYD files are generated when I compile this Boost.Python code. Remember that I am embedding any modules I create. I have a package system that I want to be able to create. It follows the following example hierarchy: my_package/ module1/ module2/ module3/ However, the Boost.Python documentation only explains one specific way of doing this, and that involves actually having PYD files for module1, module2, and module3. Since this is all done from C++, I need to be able to create this package without depending on the filesystem. Is this possible? Thanks in advance for any assistance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey at gmail.com Fri Oct 24 20:01:15 2008 From: rcdailey at gmail.com (Robert Dailey) Date: Fri, 24 Oct 2008 13:01:15 -0500 Subject: [C++-sig] Calling import() multiple times for the same module Message-ID: <496954360810241101qf337373t89d622990b1927d9@mail.gmail.com> Hi, What happens if I do the following? using namespace boost::python; import( "__main__" ).attr( "new_global" ) = 40.0f; import( "__main__" ).attr( "another_global" ) = 100.0f: My main concern here is performance. I'm wondering if each call to import() results in a disk query for the script in question and loads it from there. I'm also wondering if the second import() above will simply read from a memory cache or something. Help would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From seefeld at sympatico.ca Fri Oct 24 20:07:30 2008 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Fri, 24 Oct 2008 14:07:30 -0400 Subject: [C++-sig] Calling import() multiple times for the same module In-Reply-To: <496954360810241101qf337373t89d622990b1927d9@mail.gmail.com> References: <496954360810241101qf337373t89d622990b1927d9@mail.gmail.com> Message-ID: <49020EE2.70601@sympatico.ca> Robert Dailey wrote: > Hi, > > What happens if I do the following? > > using namespace boost::python; > > import( "__main__" ).attr( "new_global" ) = 40.0f; > import( "__main__" ).attr( "another_global" ) = 100.0f: > > > My main concern here is performance. I'm wondering if each call to > import() results in a disk query for the script in question and loads it > from there. I'm also wondering if the second import() above will simply > read from a memory cache or something. As the above code is only a wrapper around the Python runtime, you are really asking about how Python handles repeated 'import' calls. I'm pretty sure importing a module while it is already imported will do (almost) nothing. However, I'm not sure whether a module is actually unloaded as soon as the last reference goes away (such as after the first line above is completed), so I can't give a definite answer. I'm sure you'll get better answers when asking on a Python forum directly. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin... From seefeld at sympatico.ca Fri Oct 24 20:10:17 2008 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Fri, 24 Oct 2008 14:10:17 -0400 Subject: [C++-sig] How to create embedded packages? In-Reply-To: <496954360810241059q72efa761lc3777bf878c246c2@mail.gmail.com> References: <496954360810241059q72efa761lc3777bf878c246c2@mail.gmail.com> Message-ID: <49020F89.80102@sympatico.ca> Robert Dailey wrote: > > my_package/ > module1/ > module2/ > module3/ > > However, the Boost.Python documentation only explains one specific way > of doing this, and that involves actually having PYD files for module1, > module2, and module3. Since this is all done from C++, I need to be able > to create this package without depending on the filesystem. Is this > possible? I don't think so. While you certainly can embed multiple modules into the same executable, you can't embed a hierarchical structure like the one you seem to want, as Python has strict expectations as to what qualifies as a 'package'. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin... From rcdailey at gmail.com Fri Oct 24 21:29:44 2008 From: rcdailey at gmail.com (Robert Dailey) Date: Fri, 24 Oct 2008 14:29:44 -0500 Subject: [C++-sig] Private construction for python objects? Message-ID: <496954360810241229n4aca6203y1a2b8cd428317447@mail.gmail.com> Hi, I have a C++ class that I'm exposing to Python via the Boost.Python library. This specific class is only created from C++. In other words, it doesn't serve the user very much good to construct an instance of this class from Python. A typical use case for obtaining an instance of this class from python is as follows: import myCustomModule fooInstance = myCustomModule.GetFooInstance() However, I want to prevent the user from being able to do this: import myCustomModule fooInstance = myCustomModule.Foo() Let's assume the class in question with private construction is Foo. The latter code snippet would be an example of the user directly constructing an instance of Foo(). Is there a way to prevent this through the BOOST_PYTHON_MODULE() definition? I'm not even really sure if this can be done natively through Python. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From seefeld at sympatico.ca Fri Oct 24 21:34:13 2008 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Fri, 24 Oct 2008 15:34:13 -0400 Subject: [C++-sig] Private construction for python objects? In-Reply-To: <496954360810241229n4aca6203y1a2b8cd428317447@mail.gmail.com> References: <496954360810241229n4aca6203y1a2b8cd428317447@mail.gmail.com> Message-ID: <49022335.4010901@sympatico.ca> Robert Dailey wrote: > Hi, > > I have a C++ class that I'm exposing to Python via the Boost.Python > library. This specific class is only created from C++. In other words, > it doesn't serve the user very much good to construct an instance of > this class from Python. A typical use case for obtaining an instance > of this class from python is as follows: > > import myCustomModule > fooInstance = myCustomModule.GetFooInstance() > > However, I want to prevent the user from being able to do this: > > import myCustomModule > fooInstance = myCustomModule.Foo() > > Let's assume the class in question with private construction is Foo. > The latter code snippet would be an example of the user directly > constructing an instance of Foo(). Is there a way to prevent this > through the BOOST_PYTHON_MODULE() definition? I'm not even really sure > if this can be done natively through Python. Thanks. You can specify a 'noinit<>' argument to the class_<> constructor, indicating you don't want this to expose any constructor. Then, you may use make_constructor to provide your own custom construction (factory) function instead. Please look for details in the online tutorial and reference manual, as well as the examples / tests that are part of the sources. HTH, Stefan -- ...ich hab' noch einen Koffer in Berlin... From furkankuru at gmail.com Sun Oct 26 10:27:57 2008 From: furkankuru at gmail.com (Furkan Kuru) Date: Sun, 26 Oct 2008 11:27:57 +0200 Subject: [C++-sig] [c++-sig] python std::string assignment In-Reply-To: <87y70ni1ke.fsf@mcbain.luannocracy.com> References: <3a4a8f930810170343q7ea8fafdma6a4aef3688075f0@mail.gmail.com> <48F86EE4.10308@sympatico.ca> <3a4a8f930810170410o31cc1f8ajdca246f56c85f2b0@mail.gmail.com> <3a4a8f930810170551u6009e750u3b0aa1e6b95f9e88@mail.gmail.com> <48F88F64.8070709@sympatico.ca> <87skqvjnsp.fsf@mcbain.luannocracy.com> <3a4a8f930810170746v43ba4a4bv85e45335dc56d8ee@mail.gmail.com> <87y70ni1ke.fsf@mcbain.luannocracy.com> Message-ID: <3a4a8f930810260227x596319ecqc95c141e185063da@mail.gmail.com> Sorry for long delay, The problem was: I export a class with a std::string field and assinging its string field longer than 15chars crashed my application on one client computer using vista as os. I wrote small test case and used previous project configurations to build and it worked (The codes are below the message) Then I changed my code as small as the test code but still it was not working (what I mean by not working is that application crashed at same code line): The only difference with my pyd and test pyd was that test pyd was near the main executable but my pyd was under a directory (module) I put test pyd file in a directory and an __init__.py file and trying to import it and It also crashed just on the long (>15chars) string assignment line. Putting all the pyd s and dlls from the module directory to the main applications directory, and arranging python import statements accordingly solved my problem in a dirty way. Now the main folder contains too many dlls which is annoying. I still do not know if it is boost-related or just python related. Is space allocation done automatically during std::string assignment? When I put pyd file and an __init__.py to a folder and import it from its parent folder it crashes the application. Does the way of memory allocation change if it is in a different folder or next to the main file? Thanks for your help, Here is the test part: a main application embed python a boost python dll module loaded by python script a script called by main application for TestPython.pyd file: #include #include #include class DataPack { public: std::string name; void getString(const std::string& str) { std::cout << "String Parameter: " << str << std::endl; } }; using namespace boost::python; BOOST_PYTHON_MODULE( TestPython ) { class_("DataPack") .def_readwrite("name", &DataPack::name) .def("getString",&DataPack::getString); } TestApplication: #include int main(int argc, char **argv) { Py_Initialize(); try { boost::python::import("Test"); } catch(boost::python::error_already_set const &) { PyErr_Print(); } Py_Finalize(); return 0; } Test.py file: from TestPython import DataPack print "Instance" d = DataPack() print "Instance string field assignment SHORT" d.name = "abc" print "Instance string field assignment LONG" d.name = "123456789012345678901234567890" print "Instance function call with short string" d.getString("abc") print "Instance function call with long string" d.getString("123456789012345678901234567890") On Fri, Oct 17, 2008 at 7:17 PM, David Abrahams wrote: > > on Fri Oct 17 2008, "Furkan Kuru" wrote: > > > Yes, that seems very likely; this looks a bit like the small string > > optimization gone awry. Perhaps you have mixed the MS runtime lib > > headers with a different version of the binary library. > > > > Is there any way to remove this string optimization. Or How can I trace > and find > > these mixed headers to fix the problem? > > I don't know. There are many people in the world much better-qualified > to help you with this problem than I am. I suggest take your question > to a MSVC-specific group. As Stefan said, it's unlikely that it has > anything to do with boost or python. > > -- > Dave Abrahams > BoostPro Computing > http://www.boostpro.com > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig at python.org > http://mail.python.org/mailman/listinfo/cplusplus-sig > -- Furkan Kuru -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey at gmail.com Mon Oct 27 14:31:02 2008 From: rcdailey at gmail.com (Robert Dailey) Date: Mon, 27 Oct 2008 08:31:02 -0500 Subject: [C++-sig] Calling import() multiple times for the same module In-Reply-To: <49020EE2.70601@sympatico.ca> References: <496954360810241101qf337373t89d622990b1927d9@mail.gmail.com> <49020EE2.70601@sympatico.ca> Message-ID: <496954360810270631t4bdbe923h5599ccd6a133e736@mail.gmail.com> On Fri, Oct 24, 2008 at 1:07 PM, Stefan Seefeld wrote: > Robert Dailey wrote: > >> Hi, >> >> What happens if I do the following? >> >> using namespace boost::python; >> >> import( "__main__" ).attr( "new_global" ) = 40.0f; >> import( "__main__" ).attr( "another_global" ) = 100.0f: >> >> >> My main concern here is performance. I'm wondering if each call to >> import() results in a disk query for the script in question and loads it >> from there. I'm also wondering if the second import() above will simply >> read from a memory cache or something. >> > > As the above code is only a wrapper around the Python runtime, you are > really asking about how Python handles repeated 'import' calls. I'm pretty > sure importing a module while it is already imported will do (almost) > nothing. However, I'm not sure whether a module is actually unloaded as soon > as the last reference goes away (such as after the first line above is > completed), so I can't give a definite answer. > > I'm sure you'll get better answers when asking on a Python forum directly. I posted about this on the Python mailing list but I'm receiving no responses :( -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans_meine at gmx.net Mon Oct 27 15:55:26 2008 From: hans_meine at gmx.net (Hans Meine) Date: Mon, 27 Oct 2008 15:55:26 +0100 Subject: [C++-sig] Calling import() multiple times for the same module In-Reply-To: <496954360810241101qf337373t89d622990b1927d9@mail.gmail.com> References: <496954360810241101qf337373t89d622990b1927d9@mail.gmail.com> Message-ID: <200810271555.42687.hans_meine@gmx.net> On Freitag 24 Oktober 2008, Robert Dailey wrote: > What happens if I do the following? > > using namespace boost::python; > > import( "__main__" ).attr( "new_global" ) = 40.0f; > import( "__main__" ).attr( "another_global" ) = 100.0f: > > > My main concern here is performance. I'm wondering if each call to > import() results in a disk query for the script in question and loads it > from there. As Stefan said, bp::import is only a wrapper around the standard python import, which (as you can easily check) does not load a module twice. However, IIRC I read on some performance tuning page that an import-statement within a frequently called function still does take some time. Again, this can be easily checked (disclaimer: I did not set my cpufreq scheduler from conservative to performance, so the numbers have to be considered bogus): In [2]: %timeit import numpy 100000 loops, best of 3: 4.49 ?s per loop In [3]: %timeit None # for comparison 1000000 loops, best of 3: 216 ns per loop In your above code, it should be trivial to assign the module to a variable (of type bp::object) though. -- Ciao, / / .o. /--/ ..o / / ANS ooo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From dave at boostpro.com Mon Oct 27 22:43:36 2008 From: dave at boostpro.com (David Abrahams) Date: Mon, 27 Oct 2008 17:43:36 -0400 Subject: [C++-sig] Calling import() multiple times for the same module In-Reply-To: <496954360810270631t4bdbe923h5599ccd6a133e736@mail.gmail.com> (Robert Dailey's message of "Mon, 27 Oct 2008 08:31:02 -0500") References: <496954360810241101qf337373t89d622990b1927d9@mail.gmail.com> <49020EE2.70601@sympatico.ca> <496954360810270631t4bdbe923h5599ccd6a133e736@mail.gmail.com> Message-ID: <87fxmhemt3.fsf@mcbain.luannocracy.com> on Mon Oct 27 2008, "Robert Dailey" wrote: > On Fri, Oct 24, 2008 at 1:07 PM, Stefan Seefeld wrote: > > Robert Dailey wrote: > > Hi, > > What happens if I do the following? > > using namespace boost::python; > > import( "__main__" ).attr( "new_global" ) = 40.0f; > import( "__main__" ).attr( "another_global" ) = 100.0f: > > My main concern here is performance. I'm wondering if each call to > import() results in a disk query for the script in question and loads it > from there. I'm also wondering if the second import() above will simply > read from a memory cache or something. > > As the above code is only a wrapper around the Python runtime, you are really > asking about how Python handles repeated 'import' calls. I'm pretty sure > importing a module while it is already imported will do (almost) nothing. > However, I'm not sure whether a module is actually unloaded as soon as the last > reference goes away (such as after the first line above is completed), so I > can't give a definite answer. > > I'm sure you'll get better answers when asking on a Python forum directly. > > I posted about this on the Python mailing list but I'm receiving no responses :( Python keeps a dictionary in sys.modules that maps module names to module objects. Import looks there first and doesn't hit the filesystem if it finds anything. -- Dave Abrahams BoostPro Computing http://www.boostpro.com From dan.eloff at gmail.com Wed Oct 29 21:06:49 2008 From: dan.eloff at gmail.com (Dan Eloff) Date: Wed, 29 Oct 2008 15:06:49 -0500 Subject: [C++-sig] boost::python constructing object from PyObject * Message-ID: <4817b6fc0810291306p293fa740q7001a0ec2f0bd7c0@mail.gmail.com> When creating an object from a PyObject *, how do you distinguish between a PyObject pointer that is a new reference (must not be increfed, but must be decrefed) versus a PyObject * that is a borrowed reference? (should be increfed and decrefed) A very simple question for which there is no documented answer, conflicting answers in the archives of this mailing list, and hours of googling has turned up conflicting information. The best I could find was object(borrowed(ptr)) for new references and object(handle<>(ptr)) for borrowed pointers. I'm not sure if that is accurate, but if so that deserves a nomination for a terrible interface award. Please someone put me out of my misery. What's the interface for this? -Dan From hans_meine at gmx.net Wed Oct 29 21:37:55 2008 From: hans_meine at gmx.net (Hans Meine) Date: Wed, 29 Oct 2008 21:37:55 +0100 Subject: [C++-sig] boost::python constructing object from PyObject * In-Reply-To: <4817b6fc0810291306p293fa740q7001a0ec2f0bd7c0@mail.gmail.com> References: <4817b6fc0810291306p293fa740q7001a0ec2f0bd7c0@mail.gmail.com> Message-ID: <200810292137.58614.hans_meine@gmx.net> On Mittwoch 29 Oktober 2008, Dan Eloff wrote: > When creating an object from a PyObject *, how do you distinguish > between a PyObject pointer that is a new reference (must not be > increfed, but must be decrefed) versus a PyObject * that is a borrowed > reference? (should be increfed and decrefed) > > A very simple question for which there is no documented answer, > conflicting answers in the archives of this mailing list, and hours of > googling has turned up conflicting information. > > The best I could find was object(borrowed(ptr)) for new references and > object(handle<>(ptr)) for borrowed pointers. I'm not sure if that is > accurate, but if so that deserves a nomination for a terrible > interface award. > > Please someone put me out of my misery. What's the interface for this? IIRC I have complained about this in the past, too. I think it was actually discussed in the BPL tutorial (and only there AFAIK), but was eventually deleted (probably because it was not the best place for that kind of information). Actually, I have the same question as you, and the same impression that the above two ways are the "correct" ways. Err, no - you did swap the two, right? Looking back at my code, I think I used boost::python::detail::new_reference. And for turning a Foo* pointer to an object of an exported class Foo, I used something as ugly as: bp::detail::new_reference(typename manage_new_object::apply::type()(p) AFAICS, I repeated my questions a total of three times (in the "How about class_<...>.enable_copy() ?" thead), but nobody answered so far. -- Ciao, / / .o. /--/ ..o / / ANS ooo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From amohr at pixar.com Wed Oct 29 21:29:20 2008 From: amohr at pixar.com (Alex Mohr) Date: Wed, 29 Oct 2008 13:29:20 -0700 Subject: [C++-sig] boost::python constructing object from PyObject * In-Reply-To: <4817b6fc0810291306p293fa740q7001a0ec2f0bd7c0@mail.gmail.com> References: <4817b6fc0810291306p293fa740q7001a0ec2f0bd7c0@mail.gmail.com> Message-ID: <4908C7A0.4030608@pixar.com> > The best I could find was object(borrowed(ptr)) for new references and > object(handle<>(ptr)) for borrowed pointers. I'm not sure if that is > accurate, but if so that deserves a nomination for a terrible > interface award. The documentation isn't great, but the name 'borrowed' is a hint. Using borrowed instructs boost.python that the PyObject * is a borrowed reference. So you can use: object(handle<>(borrowed(ptr))) for when ptr is a borrowed reference and object(handle<>(ptr)) for when ptr is a new reference. Alex From dan.eloff at gmail.com Wed Oct 29 21:53:47 2008 From: dan.eloff at gmail.com (Dan Eloff) Date: Wed, 29 Oct 2008 15:53:47 -0500 Subject: [C++-sig] boost::python constructing object from PyObject * In-Reply-To: <4908C7A0.4030608@pixar.com> References: <4817b6fc0810291306p293fa740q7001a0ec2f0bd7c0@mail.gmail.com> <4908C7A0.4030608@pixar.com> Message-ID: <4817b6fc0810291353o5fb6313ct74c14bb68910c721@mail.gmail.com> On Wed, Oct 29, 2008 at 3:29 PM, Alex Mohr wrote: > The documentation isn't great, but the name 'borrowed' is a hint. Using > borrowed instructs boost.python that the PyObject * is a borrowed reference. > So you can use: > > object(handle<>(borrowed(ptr))) > > for when ptr is a borrowed reference and > > object(handle<>(ptr)) > > for when ptr is a new reference. > That makes a lot more sense. What confused me is this from Dave Abrahams in a message from Oct 07, I guess he got them mixed up. If the is not pre-incremented for you, then boost::python::handle<> h((PyObject*)callbackID)); return boost::python::object o(h); would be correct. Otherwise, you need boost::python::handle<> h(boost::python::borrowed((PyObject*)callbackID))); return boost::python::object o(h); btw, I notice that object(borrowed(ptr)) compiles and runs without error. Is handle<>(...) superfluous when using borrowed? -Dan From dave at boostpro.com Wed Oct 29 21:55:48 2008 From: dave at boostpro.com (David Abrahams) Date: Wed, 29 Oct 2008 16:55:48 -0400 Subject: [C++-sig] boost::python constructing object from PyObject * In-Reply-To: <200810292137.58614.hans_meine@gmx.net> (Hans Meine's message of "Wed, 29 Oct 2008 21:37:55 +0100") References: <4817b6fc0810291306p293fa740q7001a0ec2f0bd7c0@mail.gmail.com> <200810292137.58614.hans_meine@gmx.net> Message-ID: <8763nbnmsr.fsf@mcbain.luannocracy.com> on Wed Oct 29 2008, Hans Meine wrote: > On Mittwoch 29 Oktober 2008, Dan Eloff wrote: >> When creating an object from a PyObject *, how do you distinguish >> between a PyObject pointer that is a new reference (must not be >> increfed, but must be decrefed) versus a PyObject * that is a borrowed >> reference? (should be increfed and decrefed) >> >> A very simple question for which there is no documented answer, >> conflicting answers in the archives of this mailing list, and hours of >> googling has turned up conflicting information. >> >> The best I could find was object(borrowed(ptr)) for new references and >> object(handle<>(ptr)) for borrowed pointers. I'm not sure if that is >> accurate, but if so that deserves a nomination for a terrible >> interface award. >> >> Please someone put me out of my misery. What's the interface for this? > > IIRC I have complained about this in the past, too. I think it was actually > discussed in the BPL tutorial (and only there AFAIK), but was eventually > deleted (probably because it was not the best place for that kind of > information). > > Actually, I have the same question as you, and the same impression that the > above two ways are the "correct" ways. Err, no - you did swap the two, > right? Guidelines: - handle, essentially a smart pointer. Use when necessary. * a handle<> can be NULL, and maintains a reference count on the object it points to * handle<> y(null_ok(x)) allows y to become NULL * handle<> y(x), where x is not the result of null_ok, never results in a NULL y. An exception will be thrown if x is NULL * handle<> y(borrowed(x)) presumes that *x is borrowed and thus increments its reference count. * handle<> y(x), where x is not the result of borrowed, presumes that someone has already incremented the reference count on *x for us. * you can combine borrowed and null_ok in any order, so handle<> y(borrowed(null_ok(x))) and handle<> y(null_ok(borrowed(x))) are equivalent. - object, a higher-level notion. Use wherever possible. * an object can't be constructed from a raw PyObject* because there's no information in that type about whether the refcount has been incremented for this additional reference * an object can only be constructed from a handle<>. Other interfaces are not for public consumption and thus not documented. Use at your own peril. * an instance of object always "points to" something (maybe None). If the constructor argument (handle) is NULL, an exception will be thrown. > Looking back at my code, I think I used boost::python::detail::new_reference. > > And for turning a Foo* pointer to an object of an exported class Foo, I used > something as ugly as: > bp::detail::new_reference(typename manage_new_object::apply::type()(p) > > AFAICS, I repeated my questions a total of three times (in the "How about > class_<...>.enable_copy() ?" thead), but nobody answered so far. The above should be a complete guide. Any questions? -- Dave Abrahams BoostPro Computing http://www.boostpro.com From hans_meine at gmx.net Wed Oct 29 22:07:16 2008 From: hans_meine at gmx.net (Hans Meine) Date: Wed, 29 Oct 2008 22:07:16 +0100 Subject: [C++-sig] boost::python constructing object from PyObject * In-Reply-To: <8763nbnmsr.fsf@mcbain.luannocracy.com> References: <4817b6fc0810291306p293fa740q7001a0ec2f0bd7c0@mail.gmail.com> <200810292137.58614.hans_meine@gmx.net> <8763nbnmsr.fsf@mcbain.luannocracy.com> Message-ID: <200810292207.19400.hans_meine@gmx.net> On Mittwoch 29 Oktober 2008, David Abrahams wrote: > The above should be a complete guide. Any questions? Great, thanks a lot for the write-up. I think my second question is still left, at least from your post and the docs at http://www.boost.org/doc/libs/1_36_0/libs/python/doc/v2/handle.html I have the impression that a handle<> can only be created from PyObject-style pointers. So, let's say I have exported a class Foo, and I write a wrapper for a factory function that creates a new Foo, and wants to convert it to python in order to manually add some attributes (cf. my deep_copy implementation). Is there a better way than the following for creating result from new_foo? Foo *new_foo = new Foo(...); bp::object result = bp::detail::new_reference( typename manage_new_object::apply::type()(new_foo); result.attr("bar") = 42; return result; -- Ciao, / / .o. /--/ ..o / / ANS ooo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From dan.eloff at gmail.com Wed Oct 29 22:18:17 2008 From: dan.eloff at gmail.com (Dan Eloff) Date: Wed, 29 Oct 2008 16:18:17 -0500 Subject: [C++-sig] boost::python constructing object from PyObject * In-Reply-To: <8763nbnmsr.fsf@mcbain.luannocracy.com> References: <4817b6fc0810291306p293fa740q7001a0ec2f0bd7c0@mail.gmail.com> <200810292137.58614.hans_meine@gmx.net> <8763nbnmsr.fsf@mcbain.luannocracy.com> Message-ID: <4817b6fc0810291418w2d1d239y322f20bf0470f881@mail.gmail.com> On Wed, Oct 29, 2008 at 3:55 PM, David Abrahams wrote: > The above should be a complete guide. Any questions? Just two. 1) Should it be object(handle<>(borrowed(ptr))) or object(borrowed(ptr)) ? Both seem to compile. 2) Can I repost that to a boost::python wiki, givng you credit of course. Hopefully it will prevent others from having as many issues with this. Thanks for taking the time to explain handle in depth. I fixed my code accordingly and all ref-counting issues went away. -Dan From dave at boostpro.com Wed Oct 29 23:11:04 2008 From: dave at boostpro.com (David Abrahams) Date: Wed, 29 Oct 2008 18:11:04 -0400 Subject: [C++-sig] boost::python constructing object from PyObject * In-Reply-To: <4817b6fc0810291418w2d1d239y322f20bf0470f881@mail.gmail.com> (Dan Eloff's message of "Wed, 29 Oct 2008 16:18:17 -0500") References: <4817b6fc0810291306p293fa740q7001a0ec2f0bd7c0@mail.gmail.com> <200810292137.58614.hans_meine@gmx.net> <8763nbnmsr.fsf@mcbain.luannocracy.com> <4817b6fc0810291418w2d1d239y322f20bf0470f881@mail.gmail.com> Message-ID: <87wsfrm4qv.fsf@mcbain.luannocracy.com> on Wed Oct 29 2008, "Dan Eloff" wrote: > On Wed, Oct 29, 2008 at 3:55 PM, David Abrahams wrote: >> The above should be a complete guide. Any questions? > > Just two. > > 1) Should it be object(handle<>(borrowed(ptr))) or > object(borrowed(ptr)) ? Both seem to compile. * an object can only be constructed from a handle<>. Other interfaces are not for public consumption and thus not documented. Use at your own peril. I.e., it should be the first. Actually, you should follow a logical extension of Peter Dimov's guideline (http://www.boost.org/doc/libs/1_36_0/libs/smart_ptr/shared_ptr.htm#BestPractices) and give the handle<> object a name rather than making it a temporary. > 2) Can I repost that to a boost::python wiki, givng you credit of > course. Hopefully it will prevent others from having as many issues > with this. Sure thing. > Thanks for taking the time to explain handle in depth. I fixed my code > accordingly and all ref-counting issues went away. Glad to help. -- Dave Abrahams BoostPro Computing http://www.boostpro.com From dave at boostpro.com Wed Oct 29 23:17:24 2008 From: dave at boostpro.com (David Abrahams) Date: Wed, 29 Oct 2008 18:17:24 -0400 Subject: [C++-sig] boost::python constructing object from PyObject * In-Reply-To: <200810292207.19400.hans_meine@gmx.net> (Hans Meine's message of "Wed, 29 Oct 2008 22:07:16 +0100") References: <4817b6fc0810291306p293fa740q7001a0ec2f0bd7c0@mail.gmail.com> <200810292137.58614.hans_meine@gmx.net> <8763nbnmsr.fsf@mcbain.luannocracy.com> <200810292207.19400.hans_meine@gmx.net> Message-ID: <87skqfm4gb.fsf@mcbain.luannocracy.com> on Wed Oct 29 2008, Hans Meine wrote: > On Mittwoch 29 Oktober 2008, David Abrahams wrote: >> The above should be a complete guide. Any questions? > > Great, thanks a lot for the write-up. I think my second question is still > left, at least from your post and the docs at > http://www.boost.org/doc/libs/1_36_0/libs/python/doc/v2/handle.html > I have the impression that a handle<> can only be created from PyObject-style > pointers. Only from a pointer whose target's initial members are layout-compatible with PyObject, to be precise. > So, let's say I have exported a class Foo, and I write a wrapper > for a factory function that creates a new Foo, and wants to convert it to > python in order to manually add some attributes (cf. my deep_copy > implementation). Is there a better way than the following for creating > result from new_foo? > > Foo *new_foo = new Foo(...); > bp::object result = > bp::detail::new_reference( > typename manage_new_object::apply::type()(new_foo); > result.attr("bar") = 42; > return result; Either of these works: boost::shared_ptr px(new Foo(...)); object result(px); result.attr("bar") = 42; return result; or: class_ py_foo(...); py_foo.def(...) .def(...) ; ... object result = py_foo( ... ); result.attr("bar") = 42; return result; -- Dave Abrahams BoostPro Computing http://www.boostpro.com From christophe.grimault at novagrid.com Thu Oct 30 10:38:07 2008 From: christophe.grimault at novagrid.com (christophe grimault) Date: Thu, 30 Oct 2008 10:38:07 +0100 Subject: [C++-sig] Problem accessing bp::list attributes in C++ In-Reply-To: <4817b6fc0810291306p293fa740q7001a0ec2f0bd7c0@mail.gmail.com> References: <4817b6fc0810291306p293fa740q7001a0ec2f0bd7c0@mail.gmail.com> Message-ID: <1225359487.3013.7.camel@pandora.novagrid.com> Hi, I wrote a function to speedup a part of my Python code that manipulates python list objects. I do stg like: void Foo(numeric::array& X, numeric::array& Y, bool flag, list max_points, list min_points, list left_max_points, list right_max_points){ ... ... int Lmax = boost::python::extract(max_points.attr("__len__")()); ... ... } It compiles, but it crashes with segmentation fault, at the line where I try get the length of max_points, which is a list. I don't understand why ! any help ? Thanks in advance Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at boostpro.com Thu Oct 30 14:13:51 2008 From: dave at boostpro.com (David Abrahams) Date: Thu, 30 Oct 2008 09:13:51 -0400 Subject: [C++-sig] Problem accessing bp::list attributes in C++ In-Reply-To: <1225359487.3013.7.camel@pandora.novagrid.com> References: <4817b6fc0810291306p293fa740q7001a0ec2f0bd7c0@mail.gmail.com> <1225359487.3013.7.camel@pandora.novagrid.com> Message-ID: <637F6258-8CAC-4249-9A41-C638AD398C31@boostpro.com> Looks like you have a bug somewhere else. Trying to reduce this to a minimal reproducible case will doubtless help you find it. Sent from my iPhone On Oct 30, 2008, at 5:38 AM, christophe grimault wrote: > Hi, > > I wrote a function to speedup a part of my Python code that > manipulates > python list objects. I do stg like: > > void Foo(numeric::array& X, numeric::array& Y, bool flag, list > max_points, list min_points, > list left_max_points, list right_max_points){ > ... > ... > int Lmax = boost::python::extract(max_points.attr("__len__") > ()); > ... > ... > } > > It compiles, but it crashes with segmentation fault, at the line > where I try get the length of max_points, > which is a list. > > I don't understand why ! > > any help ? > > Thanks in advance > > Chris > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig at python.org > http://mail.python.org/mailman/listinfo/cplusplus-sig From alanbaljeu at yahoo.com Fri Oct 31 05:54:39 2008 From: alanbaljeu at yahoo.com (Alan Baljeu) Date: Thu, 30 Oct 2008 21:54:39 -0700 (PDT) Subject: [C++-sig] new to python; old to C++ Message-ID: <816419.78434.qm@web58302.mail.re3.yahoo.com> Hi all. Question: which python-calling-C++ tool should I try? Background: I need to use Visual Studio 2005 native C++. I know some tools use gcc. That's fine provided it's for something besides compiling my application. I'm looking at Python as a way to accelerate development of a C++ application. This application uses classes enough, but is largely not object oriented. My thought is I would identify a bunch of C++ functions to wrap, wrap them, and then use Python to pull together new functionality. The key to success is to make the C++ aspect of this wrapping as easy as possible. I don't mean "less work" as much as I mean "obvious work that I'm liable to do right because it's simple". If this means restrictions on what interfaces I can expose, I can live with that. Simple means reducing the toolset I need to understand, keeping the input simple, and keeping the output simple. Above all, "Not crashing" is a priority for me. Alan Baljeu __________________________________________________________________ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now at http://ca.toolbar.yahoo.com. From alanbaljeu at yahoo.com Fri Oct 31 23:04:47 2008 From: alanbaljeu at yahoo.com (Alan Baljeu) Date: Fri, 31 Oct 2008 15:04:47 -0700 (PDT) Subject: [C++-sig] new to python; old to C++ Message-ID: <179747.31109.qm@web58302.mail.re3.yahoo.com> Wow, quiet group. I guess I'll try pybindgen first. Alan Baljeu ----- Original Message ---- From: Alan Baljeu To: cplusplus-sig at python.org Sent: Friday, October 31, 2008 12:54:39 AM Subject: [C++-sig] new to python; old to C++ Hi all. Question: which python-calling-C++ tool should I try? Background: I need to use Visual Studio 2005 native C++. I know some tools use gcc. That's fine provided it's for something besides compiling my application. I'm looking at Python as a way to accelerate development of a C++ application. This application uses classes enough, but is largely not object oriented. My thought is I would identify a bunch of C++ functions to wrap, wrap them, and then use Python to pull together new functionality. The key to success is to make the C++ aspect of this wrapping as easy as possible. I don't mean "less work" as much as I mean "obvious work that I'm liable to do right because it's simple". If this means restrictions on what interfaces I can expose, I can live with that. Simple means reducing the toolset I need to understand, keeping the input simple, and keeping the output simple. Above all, "Not crashing" is a priority for me. Alan Baljeu __________________________________________________________________ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now at http://ca.toolbar.yahoo.com. _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig at python.org http://mail.python.org/mailman/listinfo/cplusplus-sig __________________________________________________________________ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now at http://ca.toolbar.yahoo.com. From renatox at gmail.com Fri Oct 31 23:15:27 2008 From: renatox at gmail.com (Renato Araujo) Date: Fri, 31 Oct 2008 19:15:27 -0300 Subject: [C++-sig] new to python; old to C++ In-Reply-To: <179747.31109.qm@web58302.mail.re3.yahoo.com> References: <179747.31109.qm@web58302.mail.re3.yahoo.com> Message-ID: <95291a80810311515v6b37d37ej28ef613293ff4034@mail.gmail.com> Hi Allan I think you can try Py++, to generate yours bindings then use the code to create a toolset to mke your work more easy an fast. BR Renato On Fri, Oct 31, 2008 at 7:04 PM, Alan Baljeu wrote: > Wow, quiet group. I guess I'll try pybindgen first. > > Alan Baljeu > > > ----- Original Message ---- > From: Alan Baljeu > To: cplusplus-sig at python.org > Sent: Friday, October 31, 2008 12:54:39 AM > Subject: [C++-sig] new to python; old to C++ > > Hi all. > > Question: which python-calling-C++ tool should I try? > > Background: > I need to use Visual Studio 2005 native C++. I know some tools use > gcc. That's fine provided it's for something besides compiling my > application. > > I'm looking at Python as a way to accelerate development of a C++ application. This application uses classes enough, but is largely not object oriented. My thought is I would identify a bunch of C++ functions to wrap, wrap them, and then use Python to pull together new functionality. The key to success is to make the C++ aspect of this wrapping as easy as possible. I don't mean "less work" as much as I mean "obvious work that I'm liable to do right because it's simple". If this means restrictions on what interfaces I can expose, I can live with that. > > Simple means reducing the toolset I need to understand, keeping the input simple, and keeping the output simple. > > Above all, "Not crashing" is a priority for me. > > Alan Baljeu > > > __________________________________________________________________ > Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now at > http://ca.toolbar.yahoo.com. > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig at python.org > http://mail.python.org/mailman/listinfo/cplusplus-sig > > > > __________________________________________________________________ > Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now at > http://ca.toolbar.yahoo.com. > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig at python.org > http://mail.python.org/mailman/listinfo/cplusplus-sig > -- Renato Araujo Oliveira Filho From seefeld at sympatico.ca Fri Oct 31 23:22:40 2008 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Fri, 31 Oct 2008 18:22:40 -0400 Subject: [C++-sig] new to python; old to C++ In-Reply-To: <179747.31109.qm@web58302.mail.re3.yahoo.com> References: <179747.31109.qm@web58302.mail.re3.yahoo.com> Message-ID: <490B8530.5040702@sympatico.ca> Alan Baljeu wrote: > Question: which python-calling-C++ tool should I try? > > Wow, quiet group. I guess I'll try pybindgen first. > That may be because the question is not quite clear. First of all, you should realize that, despite the generic name of this list, this is mostly about boost.python. Second, it isn't clear what you mean by 'tool', i.e., a language binding library ? A code generator ? As you are on a mostly-boost.python list, I guess the suggestion to use boost.python doesn't come as a surprise. That's the most important part. As far as code-generation is concerned, I have never bothered to use a tool. I write my binding code manually. Your milage may vary... HTH, Stefan -- ...ich hab' noch einen Koffer in Berlin...