Mailman 3 February 2004 - Cplusplus-sig

RE: [C++-sig] Re: Wrapper for exception translation
by Gottfried.Ganssauge＠HAUFE.DE Dec. 13, 2004

Dec. 13, 2004

> > ... > >> > >> > Currently, in order to wrap user defined exceptions you need to > >> > > >> > - allocate a python exception using PyErr_NewException > >> > >> Well, no. I don't see any call to PyErr_NewException in > >> libs/python/test/exception_translator.cpp > > > > Right, you don't need to if you are content with RuntimeError > > exceptions. > > or any other pre-packaged exception type provided by Python. > > > My objective was another one: I wanted to create module exceptions > > that are derived from the python "Exception" class. > >> > >> > This function needs to be parametrized using a specific naming > >> > convention > >> > >> It's not clear to me what you're referring to. Are you > sure you mean > >> "naming convention"? > > Yes. > > From the documentation to PyErr_NewException: > > > > ... The __module__ attribute of the new class is set to > the first part > > (up to the last dot) of the name argument, and the > class name is set to > > the last part (after the last dot). > > ...yeah, that's a naming convention, but I don't see how that affects > the parameterization of any function. It is enforced by PyErr_NewException, so you must follow this convention. On the hand I don't think that any user of boost.python is aware of that convention, so I wanted to codify it within my facility. ... > > What I wanted to achieve was the following: > > Create an instance of a translated_exception_handler<> t > which will be > > registered with the library by calling > > register_exception_translator<>(). > > Sorry to be difficult, but I'm going to contradict you. You didn't > want any of that. What you wanted was to create a new Python > exception type in the module which would correspond to a particular > C++ exception type and would be raised at the boundary with Python > whenever a wrapped function threw the C++ exception. Right? Right. I actually described the way to do it within the current library design. > > > Normally t would be destructed by the end of exception_<>() thereby > > leaving a registration to a non-existing translator - very bad > > karma. > > I don't understand any of this. All you have to pass to > register_exception_translator is a function pointer, and functions > live forever. So where's the lifetime issue? A pointer to a function which has access to python exception instance e. As I didn't want to create separate entities I chose to supply a functor instead which has e as a member variable. > > > Because I didn't like to have an additional container for all > > translated_exception_handler<> instances, I chose to store t within > > e's class dictionary. At that moment it seemed to be the easiest > > way to create a wrapper class using class_<> instead of making a > > true python class by hand (and it even works!). You are right, it > > is way too complex, I will change it to the mechanism I used in > > opaque_pointer_converter. > > I don't know what that is, but before you consider doing something > which is again too complex, please consider: > > template <class E> > struct translate_exception > { > static char const* msg; This would need to be defined somewhere. > static object python_exception_type; ... and this would need to be defined somewhere as well. > > static void handler(E const&) > { > PyErr_SetString(python_exception_type.ptr(), msg.c_str()); > }; > > translate_exception(char const* python_exception_name, > char const* msg_) > { > // need fancier name manipulation here > python_exception_type > = object( > handle<>(PyErr_NewException(name))); > msg = msg_; > register_exception_translator<E>(handler); > } > }; > > > Simple. Yes. ... > > I'll make a redesign ... At times you don't see the forrest, just trees ... I think this time I have a simple facility which is also easy to use (no macros). It could be even simpler with a completely different design but frankly - I have no clue how to implement that: We would need a way to somehow derive (in the python sense) a class_<> from PyExc_Exception (the type of the python Exception class) or any other python class (PyErr_NewException() has a base parameter, which could be used for that). At the same time an exception_translator should be registered for that class_<> which uses PyErr_SetObject() to raise a copy of the exception caught. This would allow us to have true Python exceptions in a pythonic sense directly wrapped around the corresponding C++ exception. > > Thnx for your feedback. > > Cool! Looking forward to it. > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com Cheers, Gottfried

3 7

Boost Python and Intel C++ 7.1 windows
by Xavier WARIN(Compte LOCAL) - I23 Aug. 16, 2004

Aug. 16, 2004

Hi, While compiling with Intel C++ 7.1 Boost Python , i get this kind of error on class.cpp and a lot of other Boost Python files : C:\boost-1.30.2\boost/type_traits/is_integral.hpp(39): error: class "boost::is_integral<unsigned short>" has already been defined BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,wchar_t,true) I think that there must be a define that i missed somewhere ! I don't find it Any idea ? Thank you Xavier Warin

2 2

Re: [C++-sig] Re: init function not found [was Re: Problem with
by Aashish Chaudhary April 6, 2004

April 6, 2004

Thanks raul that was a silly mistake :( ... I should have noticed that .. > I didn't know that VC7.0 support had been dropped - at least, not > deliberately! Well that link that you sent in the some mail (on feb 03) (the status of the compilers) showed that there were couple of problems with the VC7.0 but nothing reported for 7.1.. I got the CVS version compiled on Linux .. :) > This looks very confusing to me, because the error message doesn't > seem to match up to what you "did" in Python. Maybe the problem is > very simple though. If you create a shared object called > register_ptr.so you can import it with "from register_ptr import > ....". Python then looks for a Python module or shared object that > matches that name, and in the case of a shared object loads it and > looks for a function called something like initregister_ptr. The > BOOST_PYTHON_MODULE(register_ptr) macro gives you this function, > correctly named. > > > ____________ Problem solved !! Thanks! regards, Aashish ___________________________________ > C++-sig mailing list > C++-sig(a)python.org > http://mail.python.org/mailman/listinfo/c++-sig > __________________________________________________________________________ Aashish Chaudhary Research Assistant Iowa State University E-Mail: aashish(a)iastate.edu Ames, Iowa Telephone: +1 515-441-1178

5 7

wrapping interfaces and supplied implementations
by Brian Peters April 5, 2004

April 5, 2004

Hello All, I'd like first to thank the Boost.Python team and commend them on their creation. Dave Abrahams et.al. have implemented code the likes of which I could not even have conceived, let alone writen. Boost MPL is not something I could ever have thought up. My hope is simply that someone some day finds my work as useful and impressive as I find theirs. I am trying to wrap a library that implements a generic programming approach to computational geometry and topology. To achieve this it defines a number of interfaces it requires to do its job. For developers who do not wish to code the details of these interfaces it also supplies concrete implementations. Having observed Dave Abrahams' penchant for a working test case I have developed a sandbox representing a portion of the library. It has three classes that are abstract base classes: IFacade, IManager, and IProduct. All their pure virtual methods are defined using raw pointers to abstract base classes. The idea is that an application asks the facade for a manager [ IManager* IFacade::manager() ] and then uses the manager to create products [ IProduct* IManager::create(inti i) ]. The products have state that may be changed by the client or other operations of the facade. The manager can also store and retrieve products. A simple user can use the concrete Manager and Product classes supplied through these interfaces, but a more advanced user could derive their own product and manager from the abc's and pass that into the facade [ void IFacade::setManager(IManager* manager) ]. The old addage applies: "The simple should be easy, but the complex should be possible." i.e use the supplied system if you want, but you can always over ride it with something more complex. So now I want to be able to do the same thing in Python. I want to wrap everything so that a simple user can: * see the abstract base classes in python; i.e. the interfaces, their doc strings, etc. * use the supplied implementation of manager and product * derive their own products and manager if they want/need to in python Well, I got it all working! Not only working, but doing cool python stuff too. Being new to python I have found it interesting that arbitrary attributes and methods can be added to any object regardless of its class. I think of a wrapped Product passed out to python from the supplied Manager class as a python envelope containing the C++ Product. I can scribble on that envelope. Spill coffee on it. Crumple it up a bit. I can store it in the manager and throw it away. When I later retrieve from the manager, not only is it the same C++ Product (i.e same address), but it is the same PyObject (i.e. same address, or "id" as they call it in the interpreter), AND it even has the same note scribbled on it and the coffee stain! Its like decorating C++ classes dynamically at run time. I thought the article about C++/Python integration was cool when I read it a few months ago, but now I really see it. The line between Python and C++ is very fluid. ( http://www.cuj.com/documents/s=8188/cuj0307abrahams ) The code is attached below. For reference I am using the following (admittedly somewhat dated) environment: * Python 2.2.2 * Boost 1.30.0 * Windows NT4 with MSVC6 * RH linux 2.4.2-2 with g++ 1.96 I am offering this example to anyone that finds it useful. It is more complex than the examples I found in the documentation and code, yet still simple enough to examine in detail. I am hoping that those in the know will tell me if I have done anything terribly wrong. I will gladly explain why I have done things the way I have and/or share the verbose version of this sandbox that contains a lot more testing functions and cout's. This message is already too long to do so here. thanks, bfp ====================== > Brian Peters > topology<at>eircom<dot>net =============================================================================== ============ abcdf_ext.cpp ==================================================== #include <boost/python.hpp> #include <iostream> #include <sstream> using namespace boost::python; // --- component code ----------------------------------------------- // published interfaces struct IProduct { virtual ~IProduct() {} virtual int value() const = 0; virtual void set(int i) = 0; virtual int other(IProduct* product) const = 0; }; struct IManager { virtual ~IManager() {} virtual IProduct* create(int i) = 0; virtual IProduct* modify(IProduct* product) = 0; virtual int store(IProduct* product) = 0; virtual IProduct* retrieve(int index) = 0; }; struct IFacade { static IFacade* instance(); virtual ~IFacade() {} virtual IManager* manager() = 0; virtual void setManager(IManager* manager) = 0; virtual void update(int i) = 0; virtual std::string notice() const = 0; }; // supplied implementation of interfaces. // only exposed through pointers to the above interfaces. #define MANAGER_CAPACITY 10 struct Product : IProduct { Product(int i): _i(i) {} virtual ~Product() {} virtual int value() const { return _i; } virtual void set(int i) { _i = i; } virtual int other(IProduct* product) const { int v = -10; // TODO Should I throw if NULL == product??? if (product) v = product->value(); return _i*1000 + v; } int _i; }; struct Manager : IManager { Manager(): mCount(0) { memset(mProducts, 0, sizeof(mProducts)); } virtual ~Manager() {} virtual IProduct* create(int i) { return new Product(i); } virtual IProduct* modify(IProduct* product) { product->set(2 * product->value()); return product; } virtual int store(IProduct* product) { int index = -1; if (MANAGER_CAPACITY > mCount) { index = mCount; mProducts[mCount++] = product; } return index; } virtual IProduct* retrieve(int index) { IProduct* product = NULL; if (MANAGER_CAPACITY > index) product = mProducts[index]; return product; } int mCount; IProduct* mProducts[MANAGER_CAPACITY]; }; struct Facade : IFacade { Facade(): mManager(new Manager) {} virtual ~Facade() {} virtual IManager* manager() { return mManager; } virtual void setManager(IManager* manager) { // TODO Deleting the old manager will cause trouble if it has // already been sent out to python. How do I want to handle this? //if (mManager) // delete mManager; mManager = manager; } virtual void update(int delta) { // TODO get a product iterator from IManager here. IProduct* product; for (int i=0; i < MANAGER_CAPACITY; i++) { if (NULL != (product = mManager->retrieve(i))) product->set(product->value() + delta); } } virtual std::string notice() const { return "IFacade::notice() message: hello world!"; } IManager* mManager; }; // the singleton IFacade* theFacade = NULL; IFacade* IFacade::instance() { if (NULL == theFacade) theFacade = new Facade(); return theFacade; } // --- B.P.L. wrapper code ------------------------------------------- // rudimentary exception class struct error { error(std::string message): _msg(message) {} std::string const _msg; }; // ProductProxy provides abc methods to pass IProduct* to python. struct ProductProxy : IProduct { ProductProxy(IProduct* product) : mProduct(product) {} virtual ~ProductProxy() {} virtual int value() const { if (!mProduct) throw error("Bad proxy"); return mProduct->value(); } virtual void set(int i) { if (!mProduct) throw error("Bad proxy"); mProduct->set(i); } virtual int other(IProduct* product) const { if (!mProduct) throw error("Bad proxy"); return mProduct->other(product); } // this virtual function is overridden in ProductBase virtual int otherWrap(object& product) const { if (!mProduct) throw error("Bad proxy"); ProductProxy* proxy = arg_from_python<ProductProxy*>(product.ptr())(product.ptr()); return mProduct->other(proxy); } IProduct* mProduct; }; // ProductBase is the heldtype for ProductProxy to let python derive from IProduct. struct ProductBase : ProductProxy { ProductBase(PyObject* pyobject): ProductProxy(NULL), mSelf(pyobject) {} virtual ~ProductBase() {} virtual int value() const { return call_method<int>(mSelf, "value"); } int default_value() const { std::ostringstream msg; msg << mSelf->ob_type->tp_name << " missing implementation of function 'value'"; throw error(msg.str()); } virtual void set(int i) { call_method<void>(mSelf, "set", i); } void default_set(int i) { std::ostringstream msg; msg << mSelf->ob_type->tp_name << " missing implementation of function 'set'"; throw error(msg.str()); } virtual int other(IProduct* product) const { ProductProxy proxy(product); return call_method<int>(mSelf, "other", ptr(&proxy)); } // this virtual function is overridden from ProductProxy virtual int otherWrap(object& product) const { return call_method<int>(mSelf, "other", product); } int default_other(object& product) const { std::ostringstream msg; msg << mSelf->ob_type->tp_name << " missing implementation of function 'other'"; throw error(msg.str()); } PyObject* mSelf; }; // ManagerProxy provides abc methods to pass IManager* to python. struct ManagerProxy : IManager { ManagerProxy(IManager* manager): mManager(manager), mCount(0) {} ManagerProxy(ManagerProxy& manager) : mManager(manager.mManager), mCount(manager.mCount) { for (int i=--mCount; 0 <= i; --i) mProducts[i] = manager.mProducts[i]; } virtual ~ManagerProxy() {} virtual IProduct* create(int i) { if (!mManager) throw error("Bad proxy"); return mManager->create(i); } // this virtual function is overridden in ManagerBase virtual object createWrap(int i) { if (NULL == mManager) throw error("Bad proxy"); return object(ptr(new ProductProxy(mManager->create(i)))); } virtual IProduct* modify(IProduct* product) { if (NULL == mManager) throw error("Bad proxy"); return mManager->modify(product); } // this virtual function is overridden in ManagerBase virtual object modifyWrap(object& product) { if (NULL == mManager) throw error("Bad proxy"); ProductProxy* proxy = arg_from_python<ProductProxy*>(product.ptr())(product.ptr()); mManager->modify(proxy); return product; // IManager::modify returns its argument, but if another function might not, do this: //IProduct* value = mManager->anotherFunction(proxy); //return value == proxy ? product : object(ptr(new ProductProxy(value))); } virtual int store(IProduct* product) { return mManager->store(product); } virtual int storeWrap(object& product) { ProductProxy* proxy = arg_from_python<ProductProxy*>(product.ptr())(product.ptr()); // make sure side effects will happen mManager->store(proxy->mProduct); int index = -1; if (MANAGER_CAPACITY > mCount) { index = mCount; mProducts[mCount++] = product; } return index; } virtual IProduct* retrieve(int index) { return mManager->retrieve(index); } virtual object retrieveWrap(int index) { // make sure side effects will happen mManager->retrieve(index); if (MANAGER_CAPACITY > index) return mProducts[index]; else return object(); // python's None } IManager* mManager; // just mirror the Manager approach to storage for sandbox int mCount; object mProducts[MANAGER_CAPACITY]; }; // ManagerBase is the heldtype for ManagerProxy to let python derive from IManager. struct ManagerBase : ManagerProxy { ManagerBase(PyObject* pyobject): ManagerProxy(NULL), mSelf(pyobject) {} virtual ~ManagerBase() {} virtual IProduct* create(int i) { object product = call_method<object>(mSelf, "create", i); return arg_from_python<ProductProxy*>(product.ptr())(product.ptr()); } // this virtual function is overridden from ManagerProxy virtual object createWrap(int i) { return call_method<object>(mSelf, "create", i); } object default_create(int i) { std::ostringstream msg; msg << mSelf->ob_type->tp_name << " missing implementation of function 'create'"; throw error(msg.str()); } virtual IProduct* modify(IProduct* product) { ProductProxy proxy(product); return call_method<IProduct*>(mSelf, "modify", ptr(&proxy)); } // this virtual function is overridden from ManagerProxy virtual object modifyWrap(object& product) { return call_method<object>(mSelf, "modify", product); } object default_modify(object& product) { std::ostringstream msg; msg << mSelf->ob_type->tp_name << " missing implementation of function 'modify'"; throw error(msg.str()); } virtual int store(IProduct* product) { ProductProxy proxy(product); return call_method<int>(mSelf, "store", ptr(&proxy)); } virtual int storeWrap(object& product) { return call_method<int>(mSelf, "store", product); } int default_store(object& product) { std::ostringstream msg; msg << mSelf->ob_type->tp_name << " missing implementation of function 'store'"; throw error(msg.str()); } virtual IProduct* retrieve(int index) { object product = call_method<object>(mSelf, "retrieve", index); return arg_from_python<ProductProxy*>(product.ptr())(product.ptr()); } virtual object retrieveWrap(int index) { return call_method<object>(mSelf, "retrieve", index); } object default_retrieve(int index) { std::ostringstream msg; msg << mSelf->ob_type->tp_name << " missing implementation of function 'retrieve'"; throw error(msg.str()); } PyObject* mSelf; }; // after IFacade, but no need to inherit struct FacadeProxy { ~FacadeProxy() {} static FacadeProxy* instance() { return new FacadeProxy(); } object managerWrap() { if (mManager == object()) mManager = object(ptr(new ManagerProxy(IFacade::instance()->manager()))); return mManager; } void setManagerWrap(object manager) { ManagerProxy* proxy = arg_from_python<ManagerProxy*>(manager.ptr())(manager.ptr()); if (NULL != proxy) { mManager = manager; IFacade::instance()->setManager(proxy); } else { std::ostringstream msg; msg << "Object type: " << manager.ptr()->ob_type->tp_name << " not derived from IManager"; throw error(msg.str()); } } void update(int delta) { IFacade::instance()->update(delta); } std::string notice() const { return IFacade::instance()->notice(); } object mManager; }; // exception handling void translate(error const& e) { PyErr_SetString(PyExc_AttributeError, e._msg.c_str()); } // utility functions PyObject* _last; void dumpLast() { std::cout << "dumpLast" << std::endl; std::cout << " last: " << (void*)_last << " [" << (typeid(*_last)).name() << "]" << std::endl; std::cout << " last->ob_refcnt: " << _last->ob_refcnt << std::endl; std::cout << " last->ob_type->tp_name: " << _last->ob_type->tp_name << std::endl; } void dumpPyObject(PyObject* pyobject) { _last = pyobject; // steal for dumpLast std::cout << "dumpPyObject" << std::endl; std::cout << " pyobject: " << (void*)pyobject << " [" << (typeid(*pyobject)).name() << "]" << std::endl; std::cout << " pyobject->ob_refcnt: " << pyobject->ob_refcnt << std::endl; std::cout << " pyobject->ob_type->tp_name: " << pyobject->ob_type->tp_name << std::endl; } void dumpProduct(ProductProxy* proxy) { std::cout << "dumpProduct" << std::endl; std::cout << " proxy: " << (void*)proxy << " [" << (typeid(*proxy)).name() << "]" << std::endl; ProductBase* base = dynamic_cast<ProductBase*>(proxy); if (base) { std::cout << " proxy->mSelf: " << (void*)base->mSelf << " [" << (typeid(*base->mSelf)).name() << "]" << std::endl; std::cout << " proxy->mSelf->ob_refcnt: " << base->mSelf->ob_refcnt << std::endl; std::cout << " proxy->mSelf->ob_type->tp_name: " << base->mSelf->ob_type->tp_name << std::endl; } else { std::cout << " proxy->mProduct: " << (void*)proxy->mProduct << " [" << (typeid(*proxy->mProduct)).name() << "]" << std::endl; } } int useValue_PyObject_ptr(PyObject* product) { return call_method<int>(product, "value"); } int useValue_object_ref(object& product) { return call_method<int>(product.ptr(), "value"); } int useValue_ProductProxy_ptr(ProductProxy* product) { return NULL != product ? product->value() : -1; } ProductProxy* passBack_ProductProxy_ptr(ProductProxy* product) { return product; } object passBack_object(object& product) { ProductProxy* proxy = arg_from_python<ProductProxy*>(product.ptr())(product.ptr()); if (NULL == proxy) return object(); else return product; } BOOST_PYTHON_MODULE(abcdf_ext) { register_exception_translator<error>(&translate); class_<ProductProxy, ProductBase, boost::noncopyable>("IProduct") .def("value", &ProductProxy::value, &ProductBase::default_value, "Returns an int value") .def("set", &ProductProxy::set, &ProductBase::default_set, "Sets an int value") .def("other", &ProductProxy::otherWrap, &ProductBase::default_other, "Returns an int value using another IProduct") ; class_<ManagerProxy, ManagerBase, boost::noncopyable>("IManager") .def("create", &ManagerProxy::createWrap, &ManagerBase::default_create) .def("modify", &ManagerProxy::modifyWrap, &ManagerBase::default_modify) .def("store", &ManagerProxy::storeWrap, &ManagerBase::default_store) .def("retrieve", &ManagerProxy::retrieveWrap, &ManagerBase::default_retrieve) ; class_<FacadeProxy>("IFacade", no_init) .def("instance", &FacadeProxy::instance, return_value_policy<manage_new_object>()) // How do I do a singleton? .staticmethod("instance") .def("manager", &FacadeProxy::managerWrap) .def("setManager", &FacadeProxy::setManagerWrap) // ,with_custodian_and_ward<1, 2>()) // I don't think I need this as returning an object keeps track of reference counts. .def("update", &FacadeProxy::update) .def("notice", &FacadeProxy::notice) ; def("dumpLast", &dumpLast); def("dumpPyObject", &dumpPyObject); def("dumpProduct", &dumpProduct); def("useValue_PyObject_ptr", &useValue_PyObject_ptr); def("useValue_object_ref", &useValue_object_ref); def("useValue_ProductProxy_ptr", &useValue_ProductProxy_ptr); def("ProductProxy_ptr_manage_new_object", &passBack_ProductProxy_ptr, return_value_policy<manage_new_object>()); def("ProductProxy_ptr_reference_existing_object", &passBack_ProductProxy_ptr, return_value_policy<reference_existing_object>()); def("Product_as_object", &passBack_object); // no return_value_policy needed } #include "../../../boost_1_30_0/libs/python/test/module_tail.cpp" ============ abcdf_ext.cpp ==================================================== # test abcdf_ext: Abstract Base Class with DeFaults from abcdf_ext import * class Derived(IProduct): def __init__(self, i): IProduct.__init__(self) self.i = i def value(self): return self.i def set(self, i): self.i = i def other(self, product): return self.i*1000 + product.value() def callValue(product): return product.value() def callOther(product, other): return product.other(other) def callSet(product, i): product.set(i) class DManager(IManager): def __init__(self): IManager.__init__(self) self._products = [] def create(self, i): return Derived(i) def modify(self, product): product.set(product.value()*3) return product def store(self, product): index = len(self._products) self._products.append(product) return index def retrieve(self, index): try: return self._products[index] except: return None E=IFacade.instance() M=E.manager() D=DManager() m = M.create(2) n = M.create(3) m._m = "m" n._n = "n" i1 = M.store(m) i2 = M.store(n) i3 = M.store(M.create(4)) M.retrieve(i1)._m d = D.create(4) E.setManager(D) Dr=E.manager() e=Dr.create(5) f=Dr.create(6) e._e = "e" f._f = "f" Dr.store(e) Dr.store(f) =============================================================================== ===============================================================================

2 1

Conversion of C++ return type.
by Hanz Meizer March 22, 2004

March 22, 2004

Hello, I've realized that one of the C++-classes of my project will be very hard to wrap. Basically, it's a generic container type that holds a pointer to some object (similar to auto_ptr<>). The class is called 'Any' because it can contain a pointer to anything (nice eh? :( ). What I want to do is avoid this class entirely from python, that means, I want to have the wrapped object returned directly without the Any class wrapper. Functions that take an Any as rgument should be callable as well, of course. My question: Is it possible to shado this Any class entirely, and if yes, has this been done or where can I get some hints as to how this could work? I've searched some and my guess is to_python_converter, but I currently don't see the way how to achive my goal. Regards, H.

2 4

Creating an array in C++
by CÔTÉ Marc-Alexis March 1, 2004

March 1, 2004

Hello, I am relatively new to the world of python, so please bear with me if you find this question rather basic. I am writting some python code that interfaces with an image processing library that I wrote in C++. Up until now, I have exchanged image data (between the c++ library and python) through bitmaps stored in files. I find this rather clumsy and I am trying to use boost.python and the numeric::array type to help me transfer images from the library in a more elegant manner. My first problem is in creating the numeric::array in the c++ code. Let's say that I want a 3 dimensional array of unsigned bytes, would this be a correct way to do it? unsigned char data[300]; boost::python::numeric::array anArray(&data[0], "UByte", boost::python::make_tuple(10,10,3)); This doesn't give an error when I compile it. However, it fails to run as I expect it: >>>TypeError: No to_python (by-value) converter found for C++ type: unsigned char What am I missing? Would you even use an array to return the data, or is there a better way? Thanks, Marc-Alexis Cote ************************************************************************************* Ce courrier électronique s'adresse uniquement à la personne désignée ci-dessus, il est confidentiel et ne doit pas être remis à une autre personne, ni reproduit et son contenu ne peut être autrement divulgué. Si ce courrier électronique vous est transmis par erreur, veuillez nous en avertir immédiatement à l'adresse securite(a)ino.ca. Nous vous remercions de votre collaboration. This email is directed in confidence solely to the person named above, and may not otherwise be distributed, copied or disclosed. If you have received this email by error, please notify us immediately by email to address security(a)ino.ca. Thank you for your cooperation. ***********************************************************************************

5 12

CFP: International Conference on Computational Intelligence for Modelling, Control and Automation
by cimca Feb. 29, 2004

Feb. 29, 2004

CALL FOR PAPERS International Conference on Computational Intelligence for Modelling, Control and Automation 12-14 July 2004 Gold Coast, Australia http://www.ise.canberra.edu.au/conferences/cimca04/index.htm Jointly with International Conference on Intelligent Agents, Web Technologies and Internet Commerce 12-14 July 2004 Gold Coast, Australia http://www.ise.canberra.edu.au/conferences/iawtic04/index.htm The international conference on computational intelligence for modelling, control and automation will be held in Gold Coast, Australia on 12-14 July 2004. The conference provides a medium for the exchange of ideas between theoreticians and practitioners to address the important issues in computational intelligence, modelling, control and automation. The conference will consist of both plenary sessions and contributory sessions, focusing on theory, implementation and applications of computational intelligence techniques to modelling, control and automation. For contributory sessions, papers (4 pages or more) are being solicited. Several well-known keynote speakers will address the conference. Topics of the conference include, but are not limited to, the following areas: Modern and Advanced Control Strategies: Neural Networks Control, Fuzzy Logic Control, Genetic Algorithms & Evolutionary Control, Model-Predictive Control, Adaptive and Optimal Control, Intelligent Control Systems, Robotics and Automation, Fault Diagnosis, Intelligent agents, Industrial Automations Hybrid Systems: Fuzzy Evolutionary Systems, Fuzzy Expert Systems, Fuzzy Neural Systems, Neural Genetic Systems, Neural-Fuzzy-Genetic Systems, Hybrid Systems for Optimisation Data Analysis, Prediction and Model Identification: Signal Processing, Prediction & Time Series Analysis, System Identification, Data Fusion and Mining, Knowledge Discovery, Intelligent Information Systems, Image Processing, Image Understanding, Parallel Computing applications in Identification & Control, Pattern Recognition, Clustering, Classification Decision Making and Information Retrieval: Case-Based Reasoning, Decision Analysis, Intelligent Databases & Information Retrieval, Dynamic Systems Modelling, Decision Support Systems, Multi-criteria Decision Making, Qualitative and Approximate-Reasoning Paper Submission Papers will be selected based on their originality, significance, correctness, and clarity of presentation. Papers (4 pages or more) should be submitted to the following e-mail or the following address: CIMCA'2004 Secretariat School of Computing University of Canberra Canberra, 2601, ACT, Australia E-mail: cimca(a)ise.canberra.edu.au E-mail submission is preferred. Papers should present original work, which has not been published or being reviewed for other conferences. Important Dates · 14 March 2004 Submission of papers · 30 April 2004 Notification of acceptance · 21 May 2004 Deadline for camera-ready copies of accepted papers · 12-14 July 2004 Conference sessions Special Sessions and Tutorials Special sessions and tutorials will be organised at the conference. The conference is calling for special sessions and tutorial proposals. All proposals should be sent to the conference chair on or before 27th February 2004. CIMCA'04 will also include a special poster session devoted to recent work and work-in-progress. Abstracts are solicited for this session. Abstracts (3 pages limit) may be submitted up to 30 days before the conference date. Invited Sessions Keynote speakers from academia and industry will be addressing the main issues of the conference. Visits and social events Sightseeing visits will be arranged for the delegates and guests. A separate program will be arranged for companions during the conference. Further Information For further information either contact cimca(a)ise.canberra.edu.au or see the conference homepage at: http://www.ise.canberra.edu.au/conferences/cimca04/index.htm

1 0

Code failing to compile in boost-1.31.0
by Bruno da Silva de Oliveira Feb. 27, 2004

Feb. 27, 2004

Hi all, This code used to compile using boost from CVS (from 05.Aug.2003, IIRC): #include <boost/python.hpp> #include <exception> #include <vector> struct A { std::vector<double> v; double foo() const throw(std::out_of_range) { return v.at(0); } }; using namespace boost::python; BOOST_PYTHON_MODULE(testit) { class_<A>("A") .def("foo", &A::foo) ; } Removing the throw declaration from A::foo: double foo() const { Makes the code compile. Is this a bug, or am I doing something wrong? Thanks, Nicodemus.

2 1

exposing a class with a member class object
by Francois Ostiguy Feb. 27, 2004

Feb. 27, 2004

Hi - Using boost.python, I am trying to expose an object member from a class. As a simple example, consider : class A { A( double x, double y): s.h(0.0), s.v(0.0) {} struct S { double h, double v } s; }; I would like the C++ type A to be mapped into a corresponding Python type that once instantiated can be used with the obvious syntax a = A() a.s.h = 1.0 a.s.v = 2.0 a2 = A() a2.s.h = 3.0 a2.s.v = 4.0 As usual, I am grateful for any help or hints. -Francois ---------------------------------------------------------------------------- Dr. Jean-Francois OSTIGUY voice: (630) 840-2231 Beam Physics Dept MS220 FAX: (630) 840-6039 Fermi National Accelerator Laboratory email: ostiguy(a)fnal.gov Batavia IL 60510-0500 WWW:www-ap.fnal.gov/~ostiguy

2 1

Must be CopyConstructible for stringification?
by Andreas Kloeckner Feb. 27, 2004

Feb. 27, 2004

Hi all, I've discovered that in order to have a __str__ method, i.e. to be able to use .def( self_ns::str(self)) on a class_, it has to be CopyConstructible, or rather, is copy constructed when passed to boost::lexical_cast. This strikes me as slightly odd, since a reference would have done just as well, and not everything that can be sensibly stringified is also copyconstructible (or cheaply so, thinking matrices and lists). In short: Wouldn't it make sense to pass lexical_cast a reference instead of a copy? Andreas

2 1