Re: [C++-sig] 'numpy' test broken?
Hello, using fresh CVS state, I get failure of the 'numpy' test. I run:
bjam -sPYTHON_ROOT=/usr -sPYTHON_VERSION=2.3 numpy
and get error. The interesting part of the test output is:
I just checked in a workaround (numpy.py in test directory): # Unfortunately the doctest module works differently in Python versions # 2.2, 2.3, and 2.4. Newer versions evaluate all docstrings, even that # of objects with names starting with an underscore. To portably disable # tests based on the availability of Numeric and Numpy, the corresponding # test functions are simply deleted below if necessary. It is not a perfect fix since newer versions of Python's doctest module examine functions that we do not want to have examined, leading to spurious output, but that's all I have time for and the nasty long error messages are gone at least. Cheers, Ralf __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/
1 2 testing testing. thank you, you may now proceed. there have been problems with subscribing to c++-sig with gmx.net because gmx doesnt think that ++ belongs into an email address, so this is a check whether everything is working fine before i start writing anything important ;)
i'm currently running into an issue with exporting interface methods that have been declared as __stdcall. i found two mails relating to that issue, http://mail.python.org/pipermail/c++-sig/2005-February/008556.html and http://mail.python.org/pipermail/c++-sig/2003-April/003811.html has a solution been found for this yet? is there a standard solution for that problem? i have no chance of changing the calling convention. best regards, leonard
"Leonard \"paniq\" Ritter" <paniq@paniq.org> writes:
http://mail.python.org/pipermail/c++-sig/2005-February/008556.html
and
http://mail.python.org/pipermail/c++-sig/2003-April/003811.html
has a solution been found for this yet?
is there a standard solution for that problem? i have no chance of changing the calling convention.
The solution is fairly well-known, but may require large-scale hacking at Boost.Python. It needs a great many overloads added. I don't think I can find the time for it right now; maybe someone else can do it. -- Dave Abrahams Boost Consulting www.boost-consulting.com
i see there are easy methods of exporting operators that deal with values and mathematical operations, but is there any chance of exporting pointer-to operators? in this particular case i am exporting a custom interface pointer class to python. in c++ i can use such a smart pointer like this: Ptr<View> view(L"µ.Sandoz.View"); if (view) { view->Attach(hWnd, true); ... where Ptr<T> exposes its member T _object using InterfaceType* operator->() { return _object; } i'm exposing Ptr<View> as "View" and the View interface as "ViewInterface" to python. what i'd like to write in python would be something along the lines of view = View("µ.Sandoz.View") view.Attach(self.window, true) can i realize this without much trouble?
"Leonard \"paniq\" Ritter" <paniq@paniq.org> writes:
i see there are easy methods of exporting operators that deal with values and mathematical operations, but is there any chance of exporting pointer-to operators?
in this particular case i am exporting a custom interface pointer class to python.
in c++ i can use such a smart pointer like this:
Ptr<View> view(L"µ.Sandoz.View"); if (view) { view->Attach(hWnd, true);
...
where Ptr<T> exposes its member T _object using
InterfaceType* operator->() { return _object; }
i'm exposing Ptr<View> as "View" and the View interface as "ViewInterface" to python.
what i'd like to write in python would be something along the lines of
view = View("µ.Sandoz.View") view.Attach(self.window, true)
can i realize this without much trouble?
Yeah, just export View using Ptr<View> as the HeldType. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Yeah, just export View using Ptr<View> as the HeldType.
as if it were that easy! ;) i followed the manual for that and exposed Ptr<T> as a pointee using namespace boost { namespace python { template <typename T> struct pointee< Mu::Ptr<T> > { typedef T type; }; } } in a macro that exposes the class to python, class_ is instantiated like this class_<ClassType, bases<BaseClassType>, Ptr<ClassType>, boost::noncopyable > exportedClass(interfaceName, no_init) where ClassType is an interface class. the compiler gives me: p:\MuFramework\Shared\Code\boost\boost\python\object\make_ptr_instance.hpp(30) : error C2784: 'T *boost::python::get_pointer(const boost::python::handle<T> &)' : could not deduce template argument for 'const boost::python::handle<T> &' from 'const boost::python::objects::class_metadata<T,X1,X2,X3>::held_type' with [ T=ClassType, X1=boost::python::bases<BaseClassType>, X2=Mu::Ptr<ClassType>, X3=boost::noncopyable ] p:\MuFramework\Shared\Code\boost\boost\python\handle.hpp(143) : see declaration of 'boost::python::get_pointer' p:\MuFramework\Shared\Code\boost\boost\python\object\make_instance.hpp(26) : see reference to function template instantiation 'PyTypeObject *boost::python::objects::make_ptr_instance<T,Holder>::get_class_object<Arg>(const Ptr &)' being compiled with [ T=ClassType, Holder=boost::python::objects::pointer_holder<boost::python::objects::class_metadata<ClassType,boost::python::bases<BaseClassType>,Mu::Ptr<ClassType>,boost::noncopyable>::held_type,ClassType>, Arg=boost::python::objects::class_metadata<ClassType,boost::python::bases<BaseClassType>,Mu::Ptr<ClassType>,boost::noncopyable>::held_type, Ptr=boost::python::objects::class_metadata<ClassType,boost::python::bases<BaseClassType>,Mu::Ptr<ClassType>,boost::noncopyable>::held_type ] p:\MuFramework\Shared\Code\boost\boost\python\object\class_wrapper.hpp(36) : see reference to function template instantiation 'PyObject *boost::python::objects::make_instance_impl<T,Holder,Derived>::execute<Src>(Arg &)' being compiled with [ T=ClassType, Holder=boost::python::objects::pointer_holder<boost::python::objects::class_metadata<ClassType,boost::python::bases<BaseClassType>,Mu::Ptr<ClassType>,boost::noncopyable>::held_type,ClassType>, Derived=boost::python::objects::make_ptr_instance<ClassType,boost::python::objects::pointer_holder<boost::python::objects::class_metadata<ClassType,boost::python::bases<BaseClassType>,Mu::Ptr<ClassType>,boost::noncopyable>::held_type,ClassType>>, Src=boost::python::objects::class_metadata<ClassType,boost::python::bases<BaseClassType>,Mu::Ptr<ClassType>,boost::noncopyable>::held_type, Arg=boost::python::objects::class_metadata<ClassType,boost::python::bases<BaseClassType>,Mu::Ptr<ClassType>,boost::noncopyable>::held_type ] p:\MuFramework\Shared\Code\boost\boost\python\object\class_wrapper.hpp(35) : while compiling class-template member function 'PyObject *boost::python::objects::class_value_wrapper<Src,MakeInstance>::convert(Src)' with [ Src=boost::python::objects::class_metadata<ClassType,boost::python::bases<BaseClassType>,Mu::Ptr<ClassType>,boost::noncopyable>::held_type, MakeInstance=boost::python::objects::make_ptr_instance<ClassType,boost::python::objects::pointer_holder<boost::python::objects::class_metadata<ClassType,boost::python::bases<BaseClassType>,Mu::Ptr<ClassType>,boost::noncopyable>::held_type,ClassType>> ] p:\MuFramework\Shared\Code\boost\boost\python\object\class_metadata.hpp(237) : see reference to class template instantiation 'boost::python::objects::class_value_wrapper<Src,MakeInstance>' being compiled with [ Src=boost::python::objects::class_metadata<ClassType,boost::python::bases<BaseClassType>,Mu::Ptr<ClassType>,boost::noncopyable>::held_type, MakeInstance=boost::python::objects::make_ptr_instance<ClassType,boost::python::objects::pointer_holder<boost::python::objects::class_metadata<ClassType,boost::python::bases<BaseClassType>,Mu::Ptr<ClassType>,boost::noncopyable>::held_type,ClassType>> ] p:\MuFramework\Shared\Code\boost\boost\python\object\class_metadata.hpp(221) : see reference to function template instantiation 'void boost::python::objects::class_metadata<T,X1,X2,X3>::maybe_register_pointer_to_python<T2>(T2 *,boost::mpl::false_ *,boost::mpl::false_ *)' being compiled with [ T=ClassType, X1=boost::python::bases<BaseClassType>, X2=Mu::Ptr<ClassType>, X3=boost::noncopyable, T2=ClassType ] p:\MuFramework\Shared\Code\boost\boost\python\object\class_metadata.hpp(208) : see reference to function template instantiation 'void boost::python::objects::class_metadata<T,X1,X2,X3>::register_aux2<T,boost::mpl::bool_<C_>>(T2 *,Callback)' being compiled with [ T=ClassType, X1=boost::python::bases<BaseClassType>, X2=Mu::Ptr<ClassType>, X3=boost::noncopyable, C_=false, T2=ClassType, Callback=boost::mpl::bool_<false> ] p:\MuFramework\Shared\Code\boost\boost\python\object\class_metadata.hpp(206) : while compiling class-template member function 'void boost::python::objects::class_metadata<T,X1,X2,X3>::register_aux(void *)' with [ T=ClassType, X1=boost::python::bases<BaseClassType>, X2=Mu::Ptr<ClassType>, X3=boost::noncopyable ] p:\MuFramework\Shared\Code\boost\boost\python\class.hpp(174) : see reference to class template instantiation 'boost::python::objects::class_metadata<T,X1,X2,X3>' being compiled with [ T=ClassType, X1=boost::python::bases<BaseClassType>, X2=Mu::Ptr<ClassType>, X3=boost::noncopyable ] p:\MuFramework\Shared\Code\boost\boost\python\class.hpp(592) : see reference to class template instantiation 'boost::python::class_<W,X1,X2,X3>::id_vector' being compiled with [ W=ClassType, X1=boost::python::bases<BaseClassType>, X2=Mu::Ptr<ClassType>, X3=boost::noncopyable ] c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\deque(19) : while compiling class-template member function 'boost::python::class_<W,X1,X2,X3>::class_(const char *,boost::python::no_init_t)' with [ W=ClassType, X1=boost::python::bases<BaseClassType>, X2=Mu::Ptr<ClassType>, X3=boost::noncopyable ] p:\MuFramework\Libraries\MuPython\MuPython.Sandoz.h(37) : see reference to class template instantiation 'boost::python::class_<W,X1,X2,X3>' being compiled with [ W=ClassType, X1=boost::python::bases<BaseClassType>, X2=Mu::Ptr<ClassType>, X3=boost::noncopyable ] any idea?
"Leonard \"paniq\" Ritter" <paniq@paniq.org> writes:
Yeah, just export View using Ptr<View> as the HeldType.
as if it were that easy! ;)
i followed the manual for that and exposed Ptr<T> as a pointee using
namespace boost { namespace python { template <typename T> struct pointee< Mu::Ptr<T> > { typedef T type; }; } }
You also need namespace Mu { template <class T> T* get_pointer(Ptr<T> const& p) { return p.get(); // or something } } -- Dave Abrahams Boost Consulting www.boost-consulting.com
You also need
namespace Mu { template <class T> T* get_pointer(Ptr<T> const& p) { return p.get(); // or something } }
in my case GetObject() which needed to be const. assuming the problem was that i have not defined const cast operators i declared various flavors of cast operators in Ptr<>, but without luck. only adding get_pointer would make it work. is the requirement of get_pointer somewhere mentioned in the documentation? i was unable to find it.
"Leonard \"paniq\" Ritter" <paniq@paniq.org> writes:
You also need
namespace Mu { template <class T> T* get_pointer(Ptr<T> const& p) { return p.get(); // or something } }
in my case GetObject() which needed to be const. assuming the problem was that i have not defined const cast operators i declared various flavors of cast operators in Ptr<>, but without luck. only adding get_pointer would make it work.
is the requirement of get_pointer somewhere mentioned in the documentation? i was unable to find it.
It's in the description of the Dereferenceable concept, which is referenced in the place where you found a reference to pointee<>. -- Dave Abrahams Boost Consulting www.boost-consulting.com
appending i should say that the code compiled, but i still had no access on View's methods. i modified the code so that the export of Ptr<> was removed (i assume it was not needed anymore), and so i'm left with an abstract class export with a custom smart pointer that doesnt give me any benefit because i dont have access to the smart pointers constructor (which a shortcut to looking up the library from the class id, loading it, resolving the factory function and obtaining a new object) - that means using Ptr<> as HeldType does not seem to let me use the interface instantiations in the fashion i wanted to from python. given that Ptr<> itself exports a few nice methods i want to use from python (such as factory constructors and interface querying methods), is there any chance of exposing these?
You also need
namespace Mu { template <class T> T* get_pointer(Ptr<T> const& p) { return p.get(); // or something } }
"Leonard \"paniq\" Ritter" <paniq@paniq.org> writes:
appending i should say that the code compiled, but i still had no access on View's methods. i modified the code so that the export of Ptr<> was removed (i assume it was not needed anymore), and so i'm left with an abstract class export with a custom smart pointer that doesnt give me any benefit because i dont have access to the smart pointers constructor
Use make_constructor to register the constructor for the smart pointer in the View export.
(which a shortcut to looking up the library from the class id, loading it, resolving the factory function and obtaining a new object) - that means using Ptr<> as HeldType does not seem to let me use the interface instantiations in the fashion i wanted to from python.
given that Ptr<> itself exports a few nice methods i want to use from python (such as factory constructors and interface querying methods), is there any chance of exposing these?
Sure; just make thin wrapper functions that take a Ptr<View>& as the first argument and then def them. In fact, I don't think you need the thin wrappers and you can just .def("foo", &Ptr<View>::foo) in your class_<View,...> construct. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Use make_constructor to register the constructor for the smart pointer in the View export.
exportedClass.def("__init__",make_constructor(New<ClassType>)); did it, rox. thanks again! this gives me plenty of ideas to solve other comfortability-issues as well. :)
Sure; just make thin wrapper functions that take a Ptr<View>& as the first argument and then def them. In fact, I don't think you need the thin wrappers and you can just
.def("foo", &Ptr<View>::foo)
in your class_<View,...> construct.
will try that when time comes and give feedback
followup (heh): to get the syntax i wished for i wrote a function that went like template<typename T> Ptr<T> New(const String& objectClassName) { return Ptr<T>(objectClassName); } and exposed it via def("View",New<View>), and that works due to boost.pythons magical ptr conversion wizardry ;) the class itself is now exposed as "ViewInterface" which is not _perfect_, but its sufficient since type names dont play a big role in python anyway. thank you dave for the help, boost.python rocks again :) Leonard "paniq" Ritter wrote:
appending i should say that the code compiled, but i still had no access on View's methods. i modified the code so that the export of Ptr<> was removed (i assume it was not needed anymore), and so i'm left with an abstract class export with a custom smart pointer that doesnt give me any benefit because i dont have access to the smart pointers constructor (which a shortcut to looking up the library from the class id, loading it, resolving the factory function and obtaining a new object) - that means using Ptr<> as HeldType does not seem to let me use the interface instantiations in the fashion i wanted to from python.
given that Ptr<> itself exports a few nice methods i want to use from python (such as factory constructors and interface querying methods), is there any chance of exposing these?
You also need namespace Mu { template <class T> T* get_pointer(Ptr<T> const& p) { return p.get(); // or something } }
_______________________________________________ C++-sig mailing list C++-sig@python.org http://mail.python.org/mailman/listinfo/c++-sig
"Leonard \"paniq\" Ritter" <paniq@paniq.org> writes:
followup (heh):
to get the syntax i wished for i wrote a function that went like
template<typename T> Ptr<T> New(const String& objectClassName) { return Ptr<T>(objectClassName); }
and exposed it via def("View",New<View>), and that works due to boost.pythons magical ptr conversion wizardry ;) the class itself is now exposed as "ViewInterface" which is not _perfect_, but its sufficient since type names dont play a big role in python anyway.
Okay, but you could use make_constructor; it will get you the interface you want.
thank you dave for the help, boost.python rocks again :)
Sure. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Here's my quick fix, but as I couldn't make it work for member functions I can't be sure its right (but it does compile & run my simple test case). In python/signature.hpp, add the following just after the first definition of the template function get_signature Its an exact copy of the first get_signature function , except for the "__stdcall" addition. template < class RT BOOST_PP_ENUM_TRAILING_PARAMS_Z(1, N, class T)> inline BOOST_PYTHON_LIST_INC(N)< RT BOOST_PP_ENUM_TRAILING_PARAMS_Z(1, N, T)> get_signature(RT(__stdcall * )(BOOST_PP_ENUM_PARAMS_Z(1, N, T)), void* = 0) { return BOOST_PYTHON_LIST_INC(N)< RT BOOST_PP_ENUM_TRAILING_PARAMS_Z(1, N, T) >(); } I tried in a similar vain for the 2 member functions variants that appear later in the same file. However, I had no success, hence the reason for my caution. Regards, Mike ----- Original Message ----- From: "Leonard "paniq" Ritter" <paniq@paniq.org> To: "Development of Python/C++ integration" <c++-sig@python.org> Sent: Saturday, March 12, 2005 8:12 PM Subject: [C++-sig] exporting __stdcall methods
i'm currently running into an issue with exporting interface methods that have been declared as __stdcall.
i found two mails relating to that issue,
http://mail.python.org/pipermail/c++-sig/2005-February/008556.html
and
http://mail.python.org/pipermail/c++-sig/2003-April/003811.html
has a solution been found for this yet?
is there a standard solution for that problem? i have no chance of changing the calling convention.
best regards, leonard _______________________________________________ C++-sig mailing list C++-sig@python.org http://mail.python.org/mailman/listinfo/c++-sig
I tried in a similar vain for the 2 member functions variants that appear later in the same file. However, I had no success, hence the reason for my caution.
yes, it works for functions but not for methods. when adding something similar for __stdcall i get boost\python\detail\invoke.hpp(75) : error C2064: term does not evaluate to a function taking 2 arguments where my confusion does not permit me to make anymore assumptions on how to fix this ;)
"Leonard \"paniq\" Ritter" <paniq@paniq.org> writes:
I tried in a similar vain for the 2 member functions variants that appear later in the same file. However, I had no success, hence the reason for my caution.
yes, it works for functions but not for methods. when adding something similar for __stdcall i get
boost\python\detail\invoke.hpp(75) : error C2064: term does not evaluate to a function taking 2 arguments
where my confusion does not permit me to make anymore assumptions on how to fix this ;)
Files like boost/type_traits/detail/is_mem_fun_pointer_tester.hpp which are outside the Boost.Python library would need to be enhanced to deal with __stdcall, etc. -- Dave Abrahams Boost Consulting www.boost-consulting.com
in search of whether i could implement submodules in one .pyd using boost.python i found some old posts on the c++ sig that conclude with "well, it currently does not work" is this still true?
despite being a regular visitor of the faq i simply overlooked the manual given there. do not reply ;) Leonard "paniq" Ritter wrote:
in search of whether i could implement submodules in one .pyd using boost.python i found some old posts on the c++ sig that conclude with "well, it currently does not work"
is this still true? _______________________________________________ C++-sig mailing list C++-sig@python.org http://mail.python.org/mailman/listinfo/c++-sig
Ralf W. Grosse-Kunstleve wrote:
Hello, using fresh CVS state, I get failure of the 'numpy' test. I run:
bjam -sPYTHON_ROOT=/usr -sPYTHON_VERSION=2.3 numpy
and get error. The interesting part of the test output is:
I just checked in a workaround (numpy.py in test directory): # Unfortunately the doctest module works differently in Python versions # 2.2, 2.3, and 2.4. Newer versions evaluate all docstrings, even that # of objects with names starting with an underscore. To portably disable # tests based on the availability of Numeric and Numpy, the corresponding # test functions are simply deleted below if necessary.
It is not a perfect fix since newer versions of Python's doctest module examine functions that we do not want to have examined, leading to spurious output, but that's all I have time for and the nasty long error messages are gone at least.
Thank you! - Volodya
participants (5)
-
David Abrahams -
Leonard "paniq" Ritter -
Mike -
Ralf W. Grosse-Kunstleve -
Vladimir Prus