Mailman 3 October 2003 - 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

class_<>::add_property() on CVS-HEAD
by Jonathan Brandmeyer Jan. 3, 2004

Jan. 3, 2004

The following example demonstrates a method of using add_property that works with Boost.Python 1.30 but not CVS-HEAD (from sourceforge CVS). The example posted is somewhat useless as-is, but demonstrates something that I started using for properties with non-trivial accessors. Is there a replacement for this functionality? Thanks, Jonathan Brandmeyer -------------------------------------------------------------- #include <boost/python.hpp> namespace test { // Hmm. return_internal_reference<>() wants to wrap a real class. class ret_type { public: double i; }; class crash_me { private: ret_type i; public: ret_type& get_i() { return i; } }; } BOOST_PYTHON_MODULE( crash_test) { using namespace boost::python; class_< test::ret_type>( "ret_type") .def_readwrite( "i", &test::ret_type::i) ; class_< test::crash_me> crash_me_wrapper( "crash_me"); crash_me_wrapper .def( "get_i", &test::crash_me::get_i , return_internal_reference<>()) ; // The following works under Boost 1.30, but not CVS-HEAD // (sourceforge repository). crash_me_wrapper.add_property( "i", crash_me_wrapper.attr("get_i")); } -------------------------------------------------------- Testing with G++ 3.3.2 (Debian) results in the following error using CVS-HEAD: /home/jonathan/src/boost-CVS-HEAD/boost/boost/python/class.hpp: In member function `boost::python::api::object boost::python::class_<T, X1, X2, X3>::make_fn(const F&) [with F = boost::python::api::proxy<boost::python::api::attribute_policies>, T = test::crash_me, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]': /home/jonathan/src/boost-CVS-HEAD/boost/boost/python/class.hpp:365: instantiated from `boost::python::class_<T, X1, X2, X3>& boost::python::class_<T, X1, X2, X3>::add_property(const char*, Get) [with Get = boost::python::api::proxy<boost::python::api::attribute_policies>, T = test::crash_me, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]' crashme.cpp:38: instantiated from here /home/jonathan/src/boost-CVS-HEAD/boost/boost/python/class.hpp:429: error: no matching function for call to `get_signature(const boost::python::api::proxy<boost::python::api::attribute_policies>&, test::crash_me*)'

2 3

Sharing Singleton instances across boost.python extension modules
by Joel Gerard Jan. 2, 2004

Jan. 2, 2004

Hi all, How do I share singleton instances across extension modules in Windows? For instance, if I have an instance of a memory manager in one DLL, how do I use the same memory manager in the other? I realise this is a big question, but any links, references etc would be appreciated. Is it even possible? Joel ===== __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

2 1

IntWrapper.hpp in indexing_suite
by Niall Douglas Dec. 31, 2003

Dec. 31, 2003

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Firstly, let me confirm I have this right: IntWrapper is converted into an int by bpl using the operator boost::shared_ptr<IntWrapper>() const yes? Or is it the implicitly_convertible? If it is the latter, why do we need the shared_ptr<> operator? Anyway I came up with the below by basically following the testlinear.cpp example but unfortunately it complains "TypeError: No to_python (by-value) converter found for C++ type: class boost::python::indexing::iterator_pair<class CArrayMember<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > > *>". The code I used was: >>> from TestCArrays import * >>> a=MyList() >>> b=a.getData() I don't get why it's failing to find the conversion with mine whereas it works with the test :( Any help much appreciated. Cheers, Niall - --- cut --- #include <boost/python.hpp> #include <boost/python/suite/indexing/container_suite.hpp> #include <boost/python/suite/indexing/iterator_pair.hpp> #include <boost/python/suite/indexing/container_proxy.hpp> #include <string> class MyList { std::string *array; public: MyList(); std::string *getData() { return array; } }; MyList::MyList() { static std::string data[]={ std::string("Niall"), std::string("is"), std::string("a"), std::string("teapot") }; arrayÚta; } template<class T> class CArrayMember : public T { public: CArrayMember() : T() { } CArrayMember(const CArrayMember &o) : T(o) { } explicit CArrayMember(const T &o) : T(o) { } operator boost::shared_ptr<CArrayMember>() const { return boost::shared_ptr<CArrayMember>(new CArrayMember(*this)); } }; typedef boost::python::indexing::iterator_pair<CArrayMember<std::string> *> MyListCArray; MyListCArray MyList_getArray(MyList &l) { CArrayMember<std::string> *data=static_cast<CArrayMember<std::string> *>(l.getData()); return boost::python::indexing::iterator_pair<CArrayMember<std::string> *> (data, data+100000); // Issue if l is near the 4Gb mark } BOOST_PYTHON_MODULE(TestCArrays) { boost::python::implicitly_convertible<std::string, CArrayMember<std::string> >(); boost::python::class_< MyListCArray, boost::noncopyable>("MyListCArray", boost::python::init<CArrayMember<std::string> *, CArrayMember<std::string> *>()) .def(boost::python::indexing::container_suite< MyListCArray >()); boost::python::class_< MyList, boost::noncopyable >("MyList") .def("getData", &MyList_getArray) ; } -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP4d9/8EcvDLFGKbPEQLYxwCfSIKfJ6mtqNtS76pbNYxTF4OvZZUAoL+3 4O1w8HK0sgRIaFPbxZ5WXbfV =d8TG -----END PGP SIGNATURE-----

5 22

Extension DLLs nonfunctioning with MSVC 7.1 (beta)
by Raoul Gough Nov. 26, 2003

Nov. 26, 2003

When I build the Python tests with MSVC (7.1 beta, version 13.10.2292) I get non-functioning DLLs. With a debug build, importing an extension module into Python aborts silently, and with the release builds it reports "ImportError: DLL load failed: Invalid access to memory location." I'm reasonably sure this was working a couple of weeks ago. I can report more details if necessary, but maybe somebody already has experience with this happening? A sample link and test run follows (lines manually wrapped). I'm using the indexing_v2 branch in boost/python/suite/indexing and libs/python, and the CVS head everywhere else. The problem occurs with the new indexing tests and the existing tests I've tried as well (e.g. crossmod_exception.py). D:\CVS\boost\boost\libs\python\test>..\..\..\tools\build\jam_src\ bin.ntx86.msvc\bjam -sTOOLS=vc7.1 -d2 -sBUILD="release" -sVC71_ROOT= "D:\Program Files\Microsoft Visual Studio .NET 2003\VC7" test ...patience... ...found 3831 targets... ...updating 765 targets... [snip] "link" /nologo /INCREMENTAL:NO /DLL /subsystem:console /out:"..\..\..\bin\boost\libs\python\test\test_indexing_const_ext.pyd\ vc7.1\release\test_indexing_const_ext.pyd" /IMPLIB:"..\..\..\bin\boost\libs\python\test\test_indexing_const_ext.pyd\ vc7.1\release\test_indexing_const_ext.lib" /LIBPATH:"f:\Python22\libs" /LIBPATH:"..\..\..\bin\boost\libs\python\build\boost_python.dll\vc7.1\release" /LIBPATH:"D:\Program Files\Microsoft Visual Studio .NET 2003\VC7\lib" "python22.lib" "boost_python.lib" @"..\..\..\bin\boost\libs\python\test\test_indexing_const_ext.pyd \vc7.1\release\test_indexing_const_ext.CMD" Creating library ..\..\..\bin\boost\libs\python\test\test_indexing_const_ext. pyd\vc7.1\release\test_indexing_const_ext.lib and object ..\..\..\bin\boost\ libs\python\test\test_indexing_const_ext.pyd\vc7.1\release\ test_indexing_const_ext.exp LINK : warning LNK4089: all references to 'dh.o' discarded by /OPT:REF LINK : warning LNK4089: all references to 'ds00101.o' discarded by /OPT:REF LINK : warning LNK4089: all references to 'ds00162.o' discarded by /OPT:REF LINK : warning LNK4089: all references to 'ds00166.o' discarded by /OPT:REF LINK : warning LNK4089: all references to 'ds00222.o' discarded by /OPT:REF LINK : warning LNK4089: all references to 'ds00236.o' discarded by /OPT:REF LINK : warning LNK4089: all references to 'ds00243.o' discarded by /OPT:REF LINK : warning LNK4089: all references to 'ds00257.o' discarded by /OPT:REF LINK : warning LNK4089: all references to 'ds00385.o' discarded by /OPT:REF LINK : warning LNK4089: all references to 'ds00457.o' discarded by /OPT:REF LINK : warning LNK4089: all references to 'ds00475.o' discarded by /OPT:REF LINK : warning LNK4089: all references to 'ds00710.o' discarded by /OPT:REF python-test-target ..\..\..\bin\boost\libs\python\test\ test_indexing_const.test\vc7.1\release\test_indexing_const.test set PATH="f:\Python22\libs;..\..\..\bin\boost\libs\python\build\ boost_python.dll\vc7.1\release;..\..\..\bin\boost\libs\python\test\ test_indexing_const_ext.pyd\vc7.1\release;";%PATH% set PYTHONPATH=f:\Python22\libs;..\..\..\bin\boost\libs\python\ build\boost_python.dll\vc7.1\release;..\..\..\bin\boost\libs\python\ test\test_indexing_const_ext.pyd\vc7.1\release;..\..\..\libs\python\test;; "f:/Python22\python.exe" "test_indexing_const.py" running... ***************************************************************** Failure in example: from test_indexing_const_ext import * from line #0 of __main__ Exception raised: Traceback (most recent call last): File "f:\Python22\lib\doctest.py", line 430, in _run_examples_inner compileflags, 1) in globs File "<string>", line 1, in ? ImportError: DLL load failed: Invalid access to memory location. -- Raoul Gough. (setq dabbrev-case-fold-search nil)

4 8

function::argument_error / overloads & docstrings
by Nikolay Mladenov Nov. 18, 2003

Nov. 18, 2003

I had to change function::argument_error because it was throwing exception (MSVC6.5 built) $ cvs diff function.cpp Index: function.cpp =================================================================== RCS file: /boost/boost/libs/python/src/object/function.cpp,v retrieving revision 1.36 diff -r1.36 function.cpp 266c266 < str(s[n].basename) + (s[n].lvalue ? " {lvalue}" : "") --- > str(s[n].basename) + (s[n].lvalue ? str(" {lvalue}") : istr("")) Then I played a bit and end up with this: $ cvs diff function.cpp Index: function.cpp =================================================================== RCS file: /boost/boost/libs/python/src/object/function.cpp,v retrieving revision 1.36 diff -r1.36 function.cpp 256c256,257 < --- > > bool f_has_keywords = f->m_arg_names.ptr()!= Py_None && PyTuple_Size(f->m_arg_names.ptr()) != 0; 263,267c264,281 < } < < formal.append( < str(s[n].basename) + (s[n].lvalue ? " {lvalue}" : "") < ); --- > } > > object arg(s[n].lvalue ? str(" {lvalue}") : str("")); > if( f_has_keywords ){ > PyObject* kv = PyTuple_GET_ITEM(f->m_arg_names.ptr(), n-1); > if(kv != Py_None) > if(PyTuple_Size(kv) == 1) > arg = " %s"% object(handle<>(incref(kv))); > else{ > if(PyString_CheckExact(PyTuple_GET_ITEM(kv, 1))) > arg = " %s=\"%s\""% object(handle<>(incref(kv))); > else > arg = " %s=%s"% object(handle<>(incref(kv))); > } > } > formal.append( > str(s[n].basename) + arg > ); It formats the functions to include the arg names and the default arg values if available. Like that: >>> kwd.Foo(.0) Traceback (most recent call last): File "<stdin>", line 1, in ? Boost.Python.ArgumentError: Python argument types in Foo.__init__(Foo, float) did not match C++ signature: __init__(struct _object *, int a=0, double b=0.0, class _STL::basic_string<c har,struct std::char_traits<char>,class _STL::allocator<char> > n="") >>> kwd.Bar(.0) Traceback (most recent call last): File "<stdin>", line 1, in ? Boost.Python.ArgumentError: Python argument types in Bar.__init__(Bar, float) did not match C++ signature: __init__(struct _object *, int a=0, double b=0.0, struct Foo n=<keywords.Foo object at 0x007B73A0>) >>> What do you think about it. Is it a useful patch. I am thinking that something like that can be done for the document strings when there are function overloads. It is probably possible to print the list of the overloads with the corresponding docstrings instead of just printing one docstring. Nikolay Mladenov

4 28

boost::python::range and duplicate comdat under MSVC 6
by Raoul Gough Nov. 12, 2003

Nov. 12, 2003

Thanks once again to Ralf, I'm working with indexing_v2 under MSVC6. I have succeeded in compiling one of the test programs (testnonlinear) but in the process noticed a bug that seems to crop up whenever a module defines two or more instances of boost::python::range with the same call policies. It results in a link-time error like the following: iterator.obj : fatal error LNK1179: invalid or corrupt file: duplicate comdat "?registration@?$shared_ptr_from_python@U?$iterator_range@U?$return_value_policy@Ureturn_by_value@python@boost@@$D" Neither dumpbin nor undname make any sense of the identifier, and I haven't tracked down where the symbol is getting defined. I can only think that there's a template getting instantiated without the iterator_range template arguments, and therefore comes out as the same "decorated" symbol in all cases... Any ideas what's really going on here? Demo program (heavily edited libs/python/test/iterator.cpp) -------8<------------------- #include <boost/python/module.hpp> #include <boost/python/class.hpp> #include <boost/python/iterator.hpp> #include <list> typedef std::list<int> list_int; typedef std::list<double> list_double; list_int::iterator begin_list_int (list_int& x) { return x.begin(); } list_int::iterator end_list_int (list_int& x) { return x.end(); } list_double::iterator begin_list_double (list_double& x) { return x.begin(); } list_double::iterator end_list_double (list_double& x) { return x.end(); } BOOST_PYTHON_MODULE(iterator_ext) { using namespace boost::python; class_<list_int>("list_int") .def("__iter__", range (&begin_list_int, &end_list_int)) ; class_<list_double>("list_double") .def("__iter__", range (begin_list_double, end_list_double)) ; } -------8<------------------- -- Raoul Gough. (setq dabbrev-case-fold-search nil)

3 11

boost.python on OS X 10.3 (Panther)
by Sean Spicer Nov. 5, 2003

Nov. 5, 2003

Hi Everyone, I've just managed to get boost.python built on Mac OS X 10.3 (Panther) using the default Xcode tools that shipped with with the OS. To do so however, I've had to do a nasty hack, and I'm wondering if someone can point me to a better way of doing things. Namely, the hack involves modifying the (CVS head) <boostroot>/tools/build/darwin-tools.jam file so that lines 160 & 172 read: -framework Python instead of -framework$(_)$FRAMEWORKS This was the only thing that allowed me to avoid the following link line when compiling: -framework /System/Library/Frameworks/Python.framework/Versions/2.3/Python which does not exist. I tried the command line option to bjam, e.g.... bjam "-sTOOLS=darwin <framework>Python" to no avail. Anyone have any hints as to how to avoid this nastiness ? cheers, sean _______________________________________________________________________ Sean A. Spicer pgp key fingerprint: 8CED 19B7 3A3A BF54 B8E8 FB11 E044 F6B8 1585 9D54 pgp public key available at www.keyserver.net or pgp.mit.edu (KEY ID: 15859D54)

8 62

BPL on MSVC7.1 -w3 warnings
by Mike Rovner Nov. 4, 2003

Nov. 4, 2003

Dave, are you aware of warnings: class.cpp \boost\libs\python\src\object\class.cpp(320) : warning C4146: unary minus operator applied to unsigned type, result still unsigned builtin_converters.cpp \boost\libs\python\src\converter\builtin_converters.cpp(78) : warning C4244: 'initializing' : conversion from 'double' to 'float', possible loss of data \boost\libs\python\src\converter\builtin_converters.cpp(71) : while compiling class-template member function 'void boost::python::converter::`anonymous-namespace'::slot_rvalue_from_python<T,S lotPolicy>::construct(PyObject *,boost::python::converter::rvalue_from_python_stage1_data *)' with [ T=float, SlotPolicy=boost::python::converter::`anonymous-namespace'::float_rvalue_fro m_python ] \boost\libs\python\src\converter\builtin_converters.cpp(397) : see reference to class template instantiation 'boost::python::converter::`anonymous-namespace'::slot_rvalue_from_python<T, SlotPolicy>' being compiled with [ T=float, SlotPolicy=boost::python::converter::`anonymous-namespace'::float_rvalue_fro m_python ] \boost\python\converter\builtin_converters.hpp(114) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data \boost\python\converter\builtin_converters.hpp(116) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data Regards, Mike

2 6