From avibahra at googlemail.com  Tue Jan  3 11:54:46 2012
From: avibahra at googlemail.com (Avi Bahra)
Date: Tue, 3 Jan 2012 10:54:46 +0000
Subject: [C++-sig] [ boost.python] problems with python 2.7 on AIX,
	boost 1.45 and vacpp v11.1
Message-ID: <CAHwHRFHqACuwXb0U7FGHTv+7SaiqZuFeVSCLEzS2DWnrS0MyFA@mail.gmail.com>

I have a crash when importing my boost python
extension. With the following configuration.
   - python 2.7
   - boost 1.45
   - vacpp 11.1
   - AIX 5.3
The problem can be reproduced with boost python examples as well.

Currently I have a working solution using python 2.54.

This is what the core dump shows:

boost::python::incref<_object>,
boost::python::api::object::object,
boost::python::api::slice_nil::slice_nil,
__init__0,
...2femos_5fesuite_2femos_5fdata_2fsms_2fecflow_5f2_5f0_5f22_2fPyext_2fsrc_2fBoostPythonUtil_2ecpp,
FP=fffffffffff3d00
     .initialize_one_library__Fi,
     .initialize_libs__FPii,
     .load_libs__FPcPFv_iT1,
     .loadAndInit,
     .dlopen,
     ._PyImport_GetDynLoadFunc,
     ._PyImport_LoadDynamicModule,
     .initimp,
     .initimp,
     .initimp,
     .initimp,
     .PyImport_ImportModuleLevel,
     .fgets,

Here is the code associated with the stack dump above;

----------------------------------------------------------------
template <class T>
 inline T* incref(T* p)
 {
     Py_INCREF(python::upcast<PyObject>(p));
     return p;
 }
------------------------------------------------------------
inline object::object()
     : object_base(python::incref(Py_None))
 {}

------------------------------------------------------------
#ifndef SLICE_NIL_DWA2002620_HPP
 # define SLICE_NIL_DWA2002620_HPP

 # include <boost/python/detail/prefix.hpp>
 # include <boost/python/object_core.hpp>

 namespace boost { namespace python { namespace api {

 class slice_nil : public object
 {
  public:
     slice_nil() : object() {}
 };

 # ifndef _ // Watch out for GNU gettext users, who #define _(x)
 static const slice_nil _ = slice_nil();
 # endif

===========================================

Total view shows that p(i.e Py_None) is NULL/0

It appears that when the static slice_nil is created at
module import time. We end up with Py_None being
 NULL/0.
Could this be a problem with the way the python 2.7 was
installed/set up.

Any help would be greatly appreciated.


   Best regards,
Ta,
    Avi

From helferthomas at free.fr  Fri Jan 13 09:13:29 2012
From: helferthomas at free.fr (helferthomas at free.fr)
Date: Fri, 13 Jan 2012 09:13:29 +0100 (CET)
Subject: [C++-sig] trouble using vector of shared_ptr using boost python
In-Reply-To: <44cd436b-5edc-434c-9655-0a75432ee222@zimbra70-e12.priv.proxad.net>
Message-ID: <c457358f-c3ba-483f-8f24-718e0d73e36d@zimbra70-e12.priv.proxad.net>

Hi,

In the following test, we wrap a class "A" (and the class shared_ptr<A> using boost python facilites) and a function returning a vector of shared_ptr of this class (see test.cxx). The class "A" provides a display method. Creating an object of type "A" and calling the display method just works as expected.

The trouble (see test.py) is that calling the "display" method when iterating over the elements of the vector (of shared_ptr...) leads to the following message :

Traceback (most recent call last):
  File "test.py", line 5, in <module>
    i.display()
Boost.Python.ArgumentError: Python argument types in
    A.display(A)
did not match C++ signature:
    display(A {lvalue})

Can anybody tell me if I misused the library ?

Sincerely,

Helfer Thomas

P.S. : This has been tested on Debian squeeze using python 2.6, boost 1.46 and 1.48.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.cxx
Type: text/x-c++src
Size: 903 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20120113/bb65a271/attachment.cxx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.py
Type: text/x-python
Size: 64 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20120113/bb65a271/attachment.py>

From talljimbo at gmail.com  Fri Jan 13 17:15:27 2012
From: talljimbo at gmail.com (Jim Bosch)
Date: Fri, 13 Jan 2012 11:15:27 -0500
Subject: [C++-sig] trouble using vector of shared_ptr using boost python
In-Reply-To: <c457358f-c3ba-483f-8f24-718e0d73e36d@zimbra70-e12.priv.proxad.net>
References: <c457358f-c3ba-483f-8f24-718e0d73e36d@zimbra70-e12.priv.proxad.net>
Message-ID: <4F10589F.9070705@gmail.com>

On 01/13/2012 03:13 AM, helferthomas at free.fr wrote:
> Hi,
>
> In the following test, we wrap a class "A" (and the class shared_ptr<A>  using boost python facilites) and a function returning a vector of shared_ptr of this class (see test.cxx). The class "A" provides a display method. Creating an object of type "A" and calling the display method just works as expected.
>
> The trouble (see test.py) is that calling the "display" method when iterating over the elements of the vector (of shared_ptr...) leads to the following message :
>
> Traceback (most recent call last):
>    File "test.py", line 5, in<module>
>      i.display()
> Boost.Python.ArgumentError: Python argument types in
>      A.display(A)
> did not match C++ signature:
>      display(A {lvalue})
>
> Can anybody tell me if I misused the library ?
>

It looks like vector_indexing_suite isn't smart enough to figure out it 
shouldn't return a proxy object for a vector of shared_ptr.

This snippet should solve your problem:

class_<vector<shared_ptr<A> > >("AVector")
   .def(vector_indexing_suite<vector<shared_ptr<A> >, true >());
                                                      ^^^^

That sets the vector_indexing_suite's NoProxy template parameter to 
"true".  I believe those proxies only exist to keep the container's 
elements from becoming dangling references in Python, which isn't 
necessary for containers of shared_ptr.

Jim

From helferthomas at free.fr  Fri Jan 13 23:00:55 2012
From: helferthomas at free.fr (helferthomas at free.fr)
Date: Fri, 13 Jan 2012 23:00:55 +0100 (CET)
Subject: [C++-sig] trouble using vector of shared_ptr using boost python
In-Reply-To: <4F10589F.9070705@gmail.com>
Message-ID: <0bd0abcf-a387-4336-bd59-0683e629c8e3@zimbra70-e12.priv.proxad.net>

Thanks, it works flawlessly.

Sincerly,

Helfer Thomas

----- Mail original -----
De: "Jim Bosch" <talljimbo at gmail.com>
?: cplusplus-sig at python.org
Envoy?: Vendredi 13 Janvier 2012 17:15:27
Objet: Re: [C++-sig] trouble using vector of shared_ptr using boost python

On 01/13/2012 03:13 AM, helferthomas at free.fr wrote:
> Hi,
>
> In the following test, we wrap a class "A" (and the class shared_ptr<A>  using boost python facilites) and a function returning a vector of shared_ptr of this class (see test.cxx). The class "A" provides a display method. Creating an object of type "A" and calling the display method just works as expected.
>
> The trouble (see test.py) is that calling the "display" method when iterating over the elements of the vector (of shared_ptr...) leads to the following message :
>
> Traceback (most recent call last):
>    File "test.py", line 5, in<module>
>      i.display()
> Boost.Python.ArgumentError: Python argument types in
>      A.display(A)
> did not match C++ signature:
>      display(A {lvalue})
>
> Can anybody tell me if I misused the library ?
>

It looks like vector_indexing_suite isn't smart enough to figure out it 
shouldn't return a proxy object for a vector of shared_ptr.

This snippet should solve your problem:

class_<vector<shared_ptr<A> > >("AVector")
   .def(vector_indexing_suite<vector<shared_ptr<A> >, true >());
                                                      ^^^^

That sets the vector_indexing_suite's NoProxy template parameter to 
"true".  I believe those proxies only exist to keep the container's 
elements from becoming dangling references in Python, which isn't 
necessary for containers of shared_ptr.

Jim
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig at python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

From super24bitsound at hotmail.com  Sat Jan 14 07:08:06 2012
From: super24bitsound at hotmail.com (Jay Riley)
Date: Sat, 14 Jan 2012 01:08:06 -0500
Subject: [C++-sig] Exposing Multi-Level Inheritance with virtual functions
Message-ID: <BAY158-W110C709851D1673E6EA1A5B49D0@phx.gbl>


I've been looking around and I can find tons of information about how to wrap shallow inheritance hierarchys with virtual/pure virtual functions, but none of them show how to do multi level inheritance. I'm unsure if I'm supposed to inherit from the wrapper or the base class for the virtual functions. Essentially, I'm asking what the best way to wrap this, the various methods I've tried usually result in error messages about the wrapper not being available
For Instance I have this hierarchy:
class DrawInterface	{	public:		DrawInterface(int drawPriority = 0, bool drawing = true) : DrawPriority(drawPriority), Drawing(drawing)		{
		}		bool IsDrawing() const		{			return Drawing;		}		void SetDrawing(const bool value)		{			Drawing = value;		}		virtual void Draw(sf::RenderWindow &window) = 0;		virtual void Draw(sf::RenderWindow &window, sf::Shader &shader) = 0;		int GetDrawPriority() const		{			return DrawPriority;		}	private:		bool Drawing;		int DrawPriority;	};
class AnimatedDraw : public DrawInterface	{	public:		AnimatedDraw(bool paused = false, int drawPriority = 0) : DrawInterface(drawPriority), Paused(paused)		{		}				virtual void Update(const sf::Uint32 time, const float TimeScale = 1.0) = 0;		virtual void Update(const float time, const float TimeScale = 1.0) = 0;		virtual void SetPause(const bool value)		{			Paused = value;		}		virtual bool GetPause() const		{			return Paused;		}	protected:		bool Paused;	private:	};
class InputInterface	{	public:		InputInterface(bool acceptingInputs = true) : AcceptingInputs(acceptingInputs)		{
		}		bool IsAcceptingInputs() const		{			return AcceptingInputs;		}		void SetAcceptingInputs(const bool value)		{			AcceptingInputs = value;		}		virtual bool HandleKeyPressed(const sf::Uint32 time, const ::Input::InputModule* inputModule, ::Input::PlayerInput pInput, ::Input::InputAction& action) { return false;}		virtual bool HandleKeyReleased(const sf::Uint32 time, const ::Input::InputModule* inputModule, ::Input::PlayerInput pInput, ::Input::InputAction& action) { return false;}	private:		bool AcceptingInputs;	};
class Screen : public ::Input::InputInterface, public AnimatedDraw		{		public:			Screen(const std::string& name, ::Engine* engine, int id);			int GetID() const;			const std::string& GetScreenName() const;			void SetScreenName(const std::string& name);
			bool AddOwner(const std::string& name, ScreenStack* stack);			bool RemoveOwner(const std::string& name);			bool HasOwner(const std::string& name) const;			const boost::unordered_map<std::string, ScreenStack*>& GetOwners() const;
			bool operator==(const Screen& screen) const;			bool operator!=(const Screen& screen) const;		private:			Engine* engine;			int ScreenID;			std::string ScreenName;			sf::Uint32 LastUpdate;			boost::unordered_map<std::string, ScreenStack*> OwningStacks;
			friend class ScreenManager;		};
I want to be able to create various types of screens in Python so obviously I need to expose/wrap all the base classes, but this is where I get a little unclear about if I should be inheriting from the wrappers or the base classes, and how I should be representing these clases in python. My initial attempt at wrapping looked something like this:
class DrawInterfaceWrap : public DrawInterface	{	public:		DrawInterfaceWrap(PyObject* self, int priority = 0, bool drawing = true) : self(self), DrawInterface(priority, drawing)		{
		}		DrawInterfaceWrap(PyObject* self, const DrawInterface& src) : self(self), DrawInterface(src)		{
		}		void Draw(sf::RenderWindow &window) override		{			call_method<void>(self, "Draw", boost::ref(window));		}		void Draw(sf::RenderWindow &window, sf::Shader& shader) override		{			call_method<void>(self, "Draw", boost::ref(window), boost::ref(shader));		}	private:		PyObject* self;	};
	class AnimatedDrawWrap : public AnimatedDraw	{	public:		AnimatedDrawWrap(PyObject* self, int priority = 0, bool paused = true) : self(self), AnimatedDraw(paused, priority)		{
		}		//??? not sure how to do ta proper copy construction on self		AnimatedDrawWrap(PyObject* self, const AnimatedDraw& src) : self(self), AnimatedDraw(src)		{
		}		void Update(const sf::Uint32 time, const float TimeScale = 1.0) override		{			call_method<void>(self, "Update", time, TimeScale);		}		void Update(float time, const float TimeScale = 1.0) override		{			call_method<void>(self, "Update", time, TimeScale);					}	private:		PyObject* self;	};
class_<DrawInterfaceWrap>("DrawInterface", init<boost::python::optional<int, bool> >())			.def(init<const DrawInterface&>())			.def("Draw", pure_virtual((void (DrawInterface::*)(sf::RenderWindow&))&DrawInterface::Draw))			.def("Draw", pure_virtual((void (DrawInterface::*)(sf::RenderWindow&, sf::Shader&))&DrawInterface::Draw))			.def("IsDrawing", &DrawInterface::IsDrawing)			.def("SetDrawing", &DrawInterface::SetDrawing)			.def("GetDrawPriority", &DrawInterface::GetDrawPriority)			;		class_<AnimatedDrawWrap, bases<DrawInterfaceWrap> >("AnimatedDraw", init<boost::python::optional<int, bool> >())			.def(init<const AnimatedDraw&>())			.def(init<const AnimatedDrawWrap&>())			.def("Update", pure_virtual((void (AnimatedDraw::*)(const sf::Uint32, const float))&AnimatedDraw::Update))			.def("Update", pure_virtual((void (AnimatedDraw::*)(const float, const float))&AnimatedDraw::Update))			.def("GetPause", &AnimatedDraw::GetPause)			.def("SetPause", &AnimatedDraw::SetPause)			;
class InputInterfaceWrap : public ::Input::InputInterface	{	public:		InputInterfaceWrap(PyObject* self, bool acceptingInputs = true) : self(self), ::Input::InputInterface(acceptingInputs)		{		}
		virtual bool HandleKeyPressed(const sf::Uint32 time, const ::Input::InputModule* inputModule, ::Input::PlayerInput pInput, ::Input::InputAction& action) override		{			return call_method<bool>(self, "HandleKeyPressed", time, ptr(inputModule), pInput, boost::ref(action));		}		virtual bool HandleKeyReleased(const sf::Uint32 time, const ::Input::InputModule* inputModule, ::Input::PlayerInput pInput, ::Input::InputAction& action) override		{			return call_method<bool>(self, "HandleKeyReleased", time, ptr(inputModule), pInput, boost::ref(action));		}	private:		PyObject* self;	};
class_<InputInterfaceWrap, boost::noncopyable>("InputInteface", init<boost::python::optional<bool> >())			.def("HandleKeyPressed", pure_virtual(&::Input::InputInterface::HandleKeyPressed))			.def("HandleKeyReleased", pure_virtual(&::Input::InputInterface::HandleKeyReleased))			.def("IsAcceptingInputs", &::Input::InputInterface::IsAcceptingInputs)			.def("SetAcceptingInputs", &::Input::InputInterface::SetAcceptingInputs)			;
class_<Screen, bases<Graphics::AnimatedDraw, ::Input::InputInterface> >("Screen", init<const std::string&, ::Engine*, int>())			.def("GetID", &Screen::GetID)			.def("GetScreenName", &Screen::GetScreenName, return_value_policy<reference_existing_object>())			.def("HasOwner", &Screen::HasOwner)			.def("RemoveOwner", &Screen::RemoveOwner)			.def("SetScreenName", &Screen::SetScreenName)			;
I cant export this wrapping because boost python won't let me have initializers for abstract classes. I attempted to fix this by changing all the pure virtual functions to virtual functions, and adding a Default method for each virtual function in the wrapper. I was able to compile like this, but python hits a runtime error saying a wrapper is unavailable for base class AnimatedDraw, so obviously my exports are sstill incorrect. I'm looking for advice on how to export this hierarchy. Can I keep these functions pure virtual and have initializers or will I need to add a default implementation? Further to that, should I be inheriting from the wrappers and not the base classes? I really just want this to work where I can inherit from Screen and implement Update, Draw and HandleKeys for each screen.
I had an additional question. How do you correctly implement a copy constructors on the wrapper classes?for instance this:AnimatedDrawWrap(PyObject* self, const AnimatedDraw& src) : self(self), AnimatedDraw(src)		{
		}
I assume is incorrect since I'm not making a proper copy of the self pointer. What's the correct way to do this?
My last question is more a sylistic one. I've seen multiple ways to implement the virtual function override. I've chosen the call_method form:
void Update(const sf::Uint32 time, const float TimeScale = 1.0) override		{			call_method<void>(self, "Update", time, TimeScale);		}
just because that's what I'm used to. Is there a "better" or more correct way to do this? or is it a purely stylistic choice?
Sorry for the cluster of code, I hope my questions are clear. I can clean out some parts of the code that I don't think are relevant, but since the classes are fairly small to begin with, I figured it'd be okay.
Thanks on advance for any help :) 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20120114/2e4ec896/attachment-0001.html>

From johan.rade at gmail.com  Wed Jan 18 11:59:50 2012
From: johan.rade at gmail.com (=?ISO-8859-1?Q?Johan_R=E5de?=)
Date: Wed, 18 Jan 2012 11:59:50 +0100
Subject: [C++-sig] path and tuple translators
Message-ID: <jf68n6$hl0$1@dough.gmane.org>

Does Boost.Python have translators for boost::filesystem::path and 
boost::tuple?
If not, are there any plans to add this functionality?

Thanks,
Johan R?de


From talljimbo at gmail.com  Wed Jan 18 16:59:57 2012
From: talljimbo at gmail.com (Jim Bosch)
Date: Wed, 18 Jan 2012 10:59:57 -0500
Subject: [C++-sig] path and tuple translators
In-Reply-To: <jf68n6$hl0$1@dough.gmane.org>
References: <jf68n6$hl0$1@dough.gmane.org>
Message-ID: <4F16EC7D.3060403@gmail.com>

On 01/18/2012 05:59 AM, Johan R?de wrote:
> Does Boost.Python have translators for boost::filesystem::path and
> boost::tuple?
> If not, are there any plans to add this functionality?
>

There are none in Boost.Python proper currently.

You can find converters for Boost.Fusion in the python_extensions 
package in the Boost sandbox; along with Fusion's adapters for 
boost::tuple (see the Fusion docs), that should give you what you need:

https://svn.boost.org/svn/boost/sandbox/python_extensions/

You can probably just pull out the header files you want 
(to_python/boost_fusion.hpp and from_python/boost_fusion.hpp) rather 
than use the whole extensions package.  The std_pair.hpp converters in 
python_extensions may also be helpful as examples, as they use the 
Fusion converters with Fusion's adapters for std::pair.

I also have converters for filesystem::path (just maps to a Python str), 
attached - they should probably go in python_extensions, too, but I've 
gotten lazy about keeping that current.

Jim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: filesystem.hpp
Type: text/x-c++hdr
Size: 2419 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20120118/63894b06/attachment.hpp>

From johan.rade at gmail.com  Wed Jan 18 17:57:40 2012
From: johan.rade at gmail.com (=?ISO-8859-1?Q?Johan_R=E5de?=)
Date: Wed, 18 Jan 2012 17:57:40 +0100
Subject: [C++-sig] path and tuple translators
In-Reply-To: <4F16EC7D.3060403@gmail.com>
References: <jf68n6$hl0$1@dough.gmane.org> <4F16EC7D.3060403@gmail.com>
Message-ID: <jf6tm5$qtv$1@dough.gmane.org>

On 1/18/2012 4:59 PM, Jim Bosch wrote:
> On 01/18/2012 05:59 AM, Johan R?de wrote:
>> Does Boost.Python have translators for boost::filesystem::path and
>> boost::tuple?
>> If not, are there any plans to add this functionality?
>>
>
> There are none in Boost.Python proper currently.
>
> You can find converters for Boost.Fusion in the python_extensions
> package in the Boost sandbox; along with Fusion's adapters for
> boost::tuple (see the Fusion docs), that should give you what you need:
>
> https://svn.boost.org/svn/boost/sandbox/python_extensions/
>
> You can probably just pull out the header files you want
> (to_python/boost_fusion.hpp and from_python/boost_fusion.hpp) rather
> than use the whole extensions package. The std_pair.hpp converters in
> python_extensions may also be helpful as examples, as they use the
> Fusion converters with Fusion's adapters for std::pair.
>
> I also have converters for filesystem::path (just maps to a Python str),
> attached - they should probably go in python_extensions, too, but I've
> gotten lazy about keeping that current.
>
> Jim
>
>
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig

I will test the tuple converters.

Concerning path, I need support for unicode paths.
Currently I manually convert from PyObject* to filesystem::path as follows:

     BOOST_STATIC_ASSERT(sizeof(wchar_t) == sizeof(Py_UNICODE));
     if(PyString_Check(obj))
         return path(PyString_AsString(obj));
     else if(PyUnicode_Check(obj))
         return path(PyUnicode_AsUnicode(obj));
     else
         ... throw some exception ....

This code is not fully portable, but suffices for my current 
application. A more robust implementation might use PyUnicode_AsWideChar 
instead of PyUnicode_AsUnicode.

--Johan


From babakage at gmail.com  Thu Jan 19 20:08:39 2012
From: babakage at gmail.com (babak)
Date: Thu, 19 Jan 2012 11:08:39 -0800 (PST)
Subject: [C++-sig] Iterating over small objects
Message-ID: <1327000119558-4311109.post@n4.nabble.com>

Hi guys,

Has anyone encountered (what feels like) quite slow iteration when looping
over small containers ? I'm in a situation where I'm iterating over 100000+
3d vectors and its taking much longer than I'd expect. The vector type is
bound via boost::python and has an iter method which uses range(being, end)
for the iteration. 

I've attached a simple example binding and python test to illustrate what I
mean more clearly. I'm under the impression that in a situation like this
the overhead of creating the iterator is greater than the actual iteration,
but thats just a guess. Alternatively my perspective on what the iteration
speed should be might be completely skewed, so any help in clarifying what's
going on here would be greatly appreciated.

thanks
Babak

http://boost.2283326.n4.nabble.com/file/n4311109/source.cpp source.cpp 
http://boost.2283326.n4.nabble.com/file/n4311109/test.py test.py 

--
View this message in context: http://boost.2283326.n4.nabble.com/Iterating-over-small-objects-tp4311109p4311109.html
Sent from the Python - c++-sig mailing list archive at Nabble.com.

From talljimbo at gmail.com  Thu Jan 19 20:37:53 2012
From: talljimbo at gmail.com (Jim Bosch)
Date: Thu, 19 Jan 2012 14:37:53 -0500
Subject: [C++-sig] Iterating over small objects
In-Reply-To: <1327000119558-4311109.post@n4.nabble.com>
References: <1327000119558-4311109.post@n4.nabble.com>
Message-ID: <4F187111.3010308@gmail.com>

On 01/19/2012 02:08 PM, babak wrote:
> Hi guys,
>
> Has anyone encountered (what feels like) quite slow iteration when looping
> over small containers ? I'm in a situation where I'm iterating over 100000+
> 3d vectors and its taking much longer than I'd expect. The vector type is
> bound via boost::python and has an iter method which uses range(being, end)
> for the iteration.
>
> I've attached a simple example binding and python test to illustrate what I
> mean more clearly. I'm under the impression that in a situation like this
> the overhead of creating the iterator is greater than the actual iteration,
> but thats just a guess. Alternatively my perspective on what the iteration
> speed should be might be completely skewed, so any help in clarifying what's
> going on here would be greatly appreciated.
>

My sense is that this is something that really can't be expected to be 
efficient across the C++/Python boundary.  There is some overhead 
associated with creating the exposures, and there's also some overhead 
in converting the types, especially if those vectors aren't builtin 
numeric types.

If you can redesign the C++/Python boundary to convert your vectors 
directly into Python lists or tuples instead of wrapped C++ vectors, I 
expect you'll see an improvement, because you'll be able to take 
advantage of whatever optimization the Python developers have put into 
iteration over those classes.  Of course, it's best by far to do 
whatever iteration you can in C++ if performance is important, but I'm 
guessing that's not an option here.

Jim


From johan.rade at gmail.com  Fri Jan 20 08:11:14 2012
From: johan.rade at gmail.com (=?ISO-8859-1?Q?Johan_R=E5de?=)
Date: Fri, 20 Jan 2012 08:11:14 +0100
Subject: [C++-sig] path and tuple translators
In-Reply-To: <4F16EC7D.3060403@gmail.com>
References: <jf68n6$hl0$1@dough.gmane.org> <4F16EC7D.3060403@gmail.com>
Message-ID: <jfb42g$ctb$1@dough.gmane.org>


> You can find converters for Boost.Fusion in the python_extensions
> package in the Boost sandbox; along with Fusion's adapters for
> boost::tuple (see the Fusion docs), that should give you what you need:
>
> https://svn.boost.org/svn/boost/sandbox/python_extensions/
>
 > ...
 >
> Jim

Hi Jim,

I have tested your code. I used it to convert from Python sequence to 
std::vector and to boost::tuple. Everything works fine. Your code would 
be a valuable addition to the Boost.Python library.

A few comments:

1. Many application developers use boost::tuple or std::tuple but have 
never heard of Boost.Fusion. For their benefit you might add a header 
that handles boost::tuple and std::tuple while hiding the Boost.Fusion 
stuff.
Something like the following should suffice

     // boost/python/from_python/tuple.hpp

     #ifndef BOOST_PYTHON_FROM_PYTHON_TUPLE_HPP
     #define BOOST_PYTHON_FROM_PYTHON_TUPLE_HPP

     #include <boost/fusion/include/tuple.hpp>
     #include <boost/fusion/include/boost_tuple.hpp>
     #include <boost/python/from_python/boost_fusion.hpp>

     namespace boost { namespace python {

         template <typename Sequence>
         struct tuple_from_python
       : boost_fusion_from_python<Sequence> {};

     }}

     #endif


2. If you change boost/python/from_python/container.hpp line 46 from

      } catch (error_already_set & err) {

to

      } catch (error_already_set &) {

then you get rid of a compiler warning (on MSVS 2010).


3. I feel the naming of some of the headers and classes is a bit 
inconsistent. Why

     boost::python::tuple_from_python

and

     boost::python::container_from_python_sequence

Both convert from Python sequences.


4. I also tested with std::tuple (on MSVS 2010) and that did not work.
I got the error message

1>C:\Libraries\Boost\boost_1_48_0\boost/mpl/for_each.hpp(95): error 
C2664: 'boost::mpl::assertion_failed' : cannot convert parameter 1 from 
'boost::mpl::failed ************boost::mpl::is_sequence<T>::* 
***********' to 'boost::mpl::assert<false>::type'
1>          with
1>          [
1>              T=std::tr1::tuple<std::string,double,bool>
1>          ]
1>          No constructor could take the source type, or constructor 
overload resolution was ambiguous

--Johan





From mdevico at qualcomm.com  Sat Jan 21 17:40:03 2012
From: mdevico at qualcomm.com (DeVico, Mike)
Date: Sat, 21 Jan 2012 16:40:03 +0000
Subject: [C++-sig] Boost converter for passing std::vector object by
 reference into a function??
Message-ID: <3D98DFAFDAF0DF4AB6643AF7394426720CFDA290@nasanexd02b.na.qualcomm.com>

Hello,

I would like to wrap a class that looks like below (taken from an example I found on another site)

#include <boost/python.hpp>
#include <boost/python/suite/indexing/vector_indexing_suite.hpp>
#include <boost/python/suite/indexing/map_indexing_suite.hpp>

typedef std::vector<std::string> MyList;
class MyClass {
public:
  MyList myFuncGet()
  {
     return MyList();
  }
  void myFuncSet(MyList& list)
  {
    list.push_back("Hello");
  }
  //       stuff
};

BOOST_PYTHON_MODULE(MyModule)
{
    class_<MyList>("MyList")
        .def(vector_indexing_suite<MyList>() );

    class_<MyClass>("MyClass")
        .def("myFuncGet", &MyClass::myFuncGet)
        .def("myFuncSet", &MyClass::myFuncSet)
        ;
}

However, this is what I get when I try to use it from python:

Python 2.7.2 (default, Jun 12 2011, 14:24:46) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from MyModule import *
>>> mc = MyClass()
>>> p = []
>>> mc.myFuncSet(p)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
Boost.Python.ArgumentError: Python argument types in
    MyClass.myFuncSet(MyClass, list)
did not match C++ signature:
    myFuncSet(MyClass {lvalue}, std::vector<std::string, std::allocator<std::string> > {lvalue})
>>>

I know I'm missing a converter function, but I'm new to boost and I don't know what the converter
should  look like in this case.

I've found lots of working examples of how to return a vector, but I want to be able to pass the vector
into the function by reference and modify it.

I would really appreciate it if someone could complete the example by adding the necessary converter
code.

Thanks in advance.
--Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20120121/2382b37d/attachment.html>

From jbosch at astro.princeton.edu  Sat Jan 21 18:10:47 2012
From: jbosch at astro.princeton.edu (Jim Bosch)
Date: Sat, 21 Jan 2012 12:10:47 -0500
Subject: [C++-sig] Boost converter for passing std::vector object by
 reference into a function??
In-Reply-To: <3D98DFAFDAF0DF4AB6643AF7394426720CFDA290@nasanexd02b.na.qualcomm.com>
References: <3D98DFAFDAF0DF4AB6643AF7394426720CFDA290@nasanexd02b.na.qualcomm.com>
Message-ID: <4F1AF197.20909@astro.princeton.edu>

Your Boost.Python usage is fine.  It's the Python code that inherently 
won't work:

 >> from MyModule import *
 >> mc = MyClass()
 >> p = []
 >> mc.myFuncSet(p)

Here, 'p' doesn't actually have a std::vector in it - it's a regular 
Python list, so Boost.Python can't get a std::vector reference out of it.

Instead you can do:

 >> from MyModule import *
 >> mc = MyClass()
 >> p = MyList()
 >> mc.myFuncSet(p)

One could imagine writing a fancy converter that would allow the first 
form by making a temporary std::vector, passing that to the C++ 
function, and then copying the elements in the vector back into the 
Python list.  But that's potentially a very expensive sequence of 
operations, and it's actually impossible to do that through a registered 
converter in Boost.Python.  If you really want that Python syntax to 
work, you'll have to write a C++ function that takes a 
boost::python::list argument and calls the actual C++ function that 
operates on std::vector.

Jim



On 01/21/2012 11:40 AM, DeVico, Mike wrote:
> Hello,
>
> I would like to wrap a class that looks like below (taken from an
> example I found on another site)
>
> #include <boost/python.hpp>
>
> #include <boost/python/suite/indexing/vector_indexing_suite.hpp>
>
> #include <boost/python/suite/indexing/map_indexing_suite.hpp>
>
> typedef std::vector<std::string> MyList;
>
> class MyClass {
>
> public:
>
> MyList myFuncGet()
>
> {
>
> return MyList();
>
> }
>
> void myFuncSet(MyList& list)
>
> {
>
> list.push_back("Hello");
>
> }
>
> // stuff
>
> };
>
> BOOST_PYTHON_MODULE(MyModule)
>
> {
>
> class_<MyList>("MyList")
>
> .def(vector_indexing_suite<MyList>() );
>
> class_<MyClass>("MyClass")
>
> .def("myFuncGet", &MyClass::myFuncGet)
>
> .def("myFuncSet", &MyClass::myFuncSet)
>
> ;
>
> }
>
> However, this is what I get when I try to use it from python:
>
> Python 2.7.2 (default, Jun 12 2011, 14:24:46) [MSC v.1500 64 bit
> (AMD64)] on win32
>
> Type "help", "copyright", "credits" or "license" for more information.
>
>> >> from MyModule import *
>
>> >> mc = MyClass()
>
>> >> p = []
>
>> >> mc.myFuncSet(p)
>
> Traceback (most recent call last):
>
> File "<stdin>", line 1, in <module>
>
> Boost.Python.ArgumentError: Python argument types in
>
> MyClass.myFuncSet(MyClass, list)
>
> did not match C++ signature:
>
> myFuncSet(MyClass {lvalue}, std::vector<std::string,
> std::allocator<std::string> > {lvalue})
>
>> >>
>
> I know I?m missing a converter function, but I?m new to boost and I
> don?t know what the converter
>
> should look like in this case.
>
> I?ve found lots of working examples of how to return a vector, but I
> want to be able to pass the vector
>
> into the function by reference and modify it.
>
> I would really appreciate it if someone could complete the example by
> adding the necessary converter
>
> code.
>
> Thanks in advance.
>
> --Mike
>
>
>
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig


From babakage at gmail.com  Mon Jan 23 16:07:09 2012
From: babakage at gmail.com (Babak Khataee)
Date: Mon, 23 Jan 2012 15:07:09 +0000
Subject: [C++-sig] Iterating over small objects
In-Reply-To: <4F187111.3010308@gmail.com>
References: <1327000119558-4311109.post@n4.nabble.com>
	<4F187111.3010308@gmail.com>
Message-ID: <CAMc9Tbm6TqKq3KGcoiPC_bgKYp5z=DOJ+O8W=X37nQqY3G=M3w@mail.gmail.com>

Okay cool thanks your input.

For any one else has a similar problem - writing a simple iterator function
in python (which is a generator) and assigning that to the __iter__ member
works well as an alternative. For me this turned out to be considerably
faster than using a c++ iterator/getitem iteration.

On 19 January 2012 19:37, Jim Bosch <talljimbo at gmail.com> wrote:

> On 01/19/2012 02:08 PM, babak wrote:
>
>> Hi guys,
>>
>> Has anyone encountered (what feels like) quite slow iteration when looping
>> over small containers ? I'm in a situation where I'm iterating over
>> 100000+
>> 3d vectors and its taking much longer than I'd expect. The vector type is
>> bound via boost::python and has an iter method which uses range(being,
>> end)
>> for the iteration.
>>
>> I've attached a simple example binding and python test to illustrate what
>> I
>> mean more clearly. I'm under the impression that in a situation like this
>> the overhead of creating the iterator is greater than the actual
>> iteration,
>> but thats just a guess. Alternatively my perspective on what the iteration
>> speed should be might be completely skewed, so any help in clarifying
>> what's
>> going on here would be greatly appreciated.
>>
>>
> My sense is that this is something that really can't be expected to be
> efficient across the C++/Python boundary.  There is some overhead
> associated with creating the exposures, and there's also some overhead in
> converting the types, especially if those vectors aren't builtin numeric
> types.
>
> If you can redesign the C++/Python boundary to convert your vectors
> directly into Python lists or tuples instead of wrapped C++ vectors, I
> expect you'll see an improvement, because you'll be able to take advantage
> of whatever optimization the Python developers have put into iteration over
> those classes.  Of course, it's best by far to do whatever iteration you
> can in C++ if performance is important, but I'm guessing that's not an
> option here.
>
> Jim
>
>
> ______________________________**_________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/**mailman/listinfo/cplusplus-sig<http://mail.python.org/mailman/listinfo/cplusplus-sig>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20120123/53ae4e2a/attachment.html>

From jensen.bo at gmail.com  Mon Jan 23 20:35:15 2012
From: jensen.bo at gmail.com (Bo Jensen)
Date: Mon, 23 Jan 2012 20:35:15 +0100
Subject: [C++-sig]  A few questions on Boost.Python
Message-ID: <CAOq_XjN+nAihtUKrUbSedV8CjVrZZbzydzMjcfnTcWPUKRQqmA@mail.gmail.com>

Hi,

I have been looking into the best way for me to make a python wrapper for a
C++ library. Boost.Python looks nice and seem to fit my needs, but I have a
few questions before I dig in deep and do the implementation.

What I want to do :

I have a very thin header only C++ library, which is an extension on top of
a c library i.e some of the C++ functions call functions in a C dll/so. So
the C++ library only provides a nice way of using the C library with
operators and overloading etc. For this library I want to make an python
interface, which only should mimic the C++ classes and functions i.e there
will be a 1:1 mapping.

Questions :

1) Would Boost.Python be suited for such a task ?

2) What kind of speed can I expect ? I read somewhere that cython was much
faster (but it seems to be less portable and flexible).

3) Will I experience problems with types like wchar or long long ?

4) How do I link to my C library ?

5) I also read that Boost.Python is not thread safe, is that true and if
yes can it be fixed/hacked ?

6) Regarding portability, will I have to recompile for each python version ?

7) 64 bit is supported right ?

Thanks to anybody providing some insight.

/Bo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20120123/fe5aeafe/attachment.html>

From talljimbo at gmail.com  Mon Jan 23 21:03:03 2012
From: talljimbo at gmail.com (Jim Bosch)
Date: Mon, 23 Jan 2012 15:03:03 -0500
Subject: [C++-sig] A few questions on Boost.Python
In-Reply-To: <CAOq_XjN+nAihtUKrUbSedV8CjVrZZbzydzMjcfnTcWPUKRQqmA@mail.gmail.com>
References: <CAOq_XjN+nAihtUKrUbSedV8CjVrZZbzydzMjcfnTcWPUKRQqmA@mail.gmail.com>
Message-ID: <4F1DBCF7.7040009@gmail.com>

On 01/23/2012 02:35 PM, Bo Jensen wrote:
> Hi,
>
> I have been looking into the best way for me to make a python wrapper for a
> C++ library. Boost.Python looks nice and seem to fit my needs, but I have a
> few questions before I dig in deep and do the implementation.
>
> What I want to do :
>
> I have a very thin header only C++ library, which is an extension on top of
> a c library i.e some of the C++ functions call functions in a C dll/so. So
> the C++ library only provides a nice way of using the C library with
> operators and overloading etc. For this library I want to make an python
> interface, which only should mimic the C++ classes and functions i.e there
> will be a 1:1 mapping.
>
> Questions :
>
> 1) Would Boost.Python be suited for such a task ?
>

Almost definitely.  For this sort of task most people use Boost.Python, 
SWIG, or the raw Python C-API.

Boost.Python is my favorite, and probably the favorite of most people on 
this list.  The Python C-API (what I think you're calling "cython") is a 
lot less automatic; you'll find yourself writing a lot more code, and 
doing a lot more memory management.  SWIG can be much more automatic if 
your C/C++ interface is sufficiently simple, but it's generally less 
safe w.r.t. memory management, it chokes on complex C++, and I find it 
much more difficult to debug.

> 2) What kind of speed can I expect ? I read somewhere that cython was much
> faster (but it seems to be less portable and flexible).
>

Note that none of these tools will work with Python interpreters other 
than the standard C one - no Jython, no IronPython.

The performance of any of these wrapper tools is largely determined by 
how often you cross the C++/Python boundary.  If you have a huge number 
of types, you may see more of a performance hit with Boost.Python or 
SWIG, because type conversions involve traversing a registry of all the 
types.  I wouldn't worry about performance of the wrapper layer unless 
you have a good reason to think you need to.

> 3) Will I experience problems with types like wchar or long long ?
>

I don't think wchar* will be automatically converted to Python str or 
unicode, the way char* is.

I'm pretty sure long long will be fine, but I have't really tested it much.

> 4) How do I link to my C library ?
>

Any of these tools will create a shared library (.dll, .so, .dylib, etc) 
that you link normally with other shared libraries.  Python will load 
that library when you import your wrapped module.

> 5) I also read that Boost.Python is not thread safe, is that true and if
> yes can it be fixed/hacked ?
>

Other people on this list know a lot more than I do about this topic.  I 
believe the answer depends on whether the multithreaded programming 
crosses the C++/Python boundary.

> 6) Regarding portability, will I have to recompile for each python version ?
>

Yes, for Python major releases (2.6 -> 2.7).  No for minor releases 
(2.7.2 -> 2.7.3).  I believe this will be more or less the same for any 
Python wrapper tool.

> 7) 64 bit is supported right ?
>

Absolutely.

> Thanks to anybody providing some insight.
>

Sure.  Good luck!

Jim

From anders.e.e.wallin at gmail.com  Tue Jan 24 08:32:44 2012
From: anders.e.e.wallin at gmail.com (Anders Wallin)
Date: Tue, 24 Jan 2012 09:32:44 +0200
Subject: [C++-sig] A few questions on Boost.Python
In-Reply-To: <4F1DBCF7.7040009@gmail.com>
References: <CAOq_XjN+nAihtUKrUbSedV8CjVrZZbzydzMjcfnTcWPUKRQqmA@mail.gmail.com>
	<4F1DBCF7.7040009@gmail.com>
Message-ID: <CAPnVNRWEztUWe0=zuyM+Bcc4ybwX28hcVAEDbQ7uaK2uHx8Jgw@mail.gmail.com>

>> 5) I also read that Boost.Python is not thread safe, is that true and if
>> yes can it be fixed/hacked ?
>>
>
> Other people on this list know a lot more than I do about this topic. ?I
> believe the answer depends on whether the multithreaded programming crosses
> the C++/Python boundary.


FWIW, it is quite straightforward to write C++ code that uses e.g.
OpenMP to do work in multiple threads, and then returns results to
python.
I've only done a case where we wait in python for the c++
function(that potentially uses OpenMP or other threading libs) to
finish before continuing.

AW

From s_sourceforge at nedprod.com  Tue Jan 24 09:38:54 2012
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Tue, 24 Jan 2012 08:38:54 -0000
Subject: [C++-sig] A few questions on Boost.Python
In-Reply-To: <CAPnVNRWEztUWe0=zuyM+Bcc4ybwX28hcVAEDbQ7uaK2uHx8Jgw@mail.gmail.com>
References: <CAOq_XjN+nAihtUKrUbSedV8CjVrZZbzydzMjcfnTcWPUKRQqmA@mail.gmail.com>,
	<4F1DBCF7.7040009@gmail.com>,
	<CAPnVNRWEztUWe0=zuyM+Bcc4ybwX28hcVAEDbQ7uaK2uHx8Jgw@mail.gmail.com>
Message-ID: <4F1E6E1E.26217.47510935@s_sourceforge.nedprod.com>

On 24 Jan 2012 at 9:32, Anders Wallin wrote:

> >> 5) I also read that Boost.Python is not thread safe, is that true and if
> >> yes can it be fixed/hacked ?

Not thread *aware* would be more accurate.

> > Other people on this list know a lot more than I do about this topic. ?I
> > believe the answer depends on whether the multithreaded programming crosses
> > the C++/Python boundary.
> 
> FWIW, it is quite straightforward to write C++ code that uses e.g.
> OpenMP to do work in multiple threads, and then returns results to
> python.
> I've only done a case where we wait in python for the c++
> function(that potentially uses OpenMP or other threading libs) to
> finish before continuing.

Sure that ought to work. Whatever you do though, do NOT call into 
python from within an OpenMP expanded piece of code as you'll run 
into GIL problems - unless you handle the GIL manually.

Niall

-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 
472909.




From wichert at wiggy.net  Tue Jan 24 09:47:41 2012
From: wichert at wiggy.net (Wichert Akkerman)
Date: Tue, 24 Jan 2012 09:47:41 +0100
Subject: [C++-sig] A few questions on Boost.Python
In-Reply-To: <4F1DBCF7.7040009@gmail.com>
References: <CAOq_XjN+nAihtUKrUbSedV8CjVrZZbzydzMjcfnTcWPUKRQqmA@mail.gmail.com>
	<4F1DBCF7.7040009@gmail.com>
Message-ID: <4F1E702D.1090704@wiggy.net>

On 01/23/2012 09:03 PM, Jim Bosch wrote:
> On 01/23/2012 02:35 PM, Bo Jensen wrote:
>> Hi,
>>
>> I have been looking into the best way for me to make a python wrapper 
>> for a
>> C++ library. Boost.Python looks nice and seem to fit my needs, but I 
>> have a
>> few questions before I dig in deep and do the implementation.
>>
>> What I want to do :
>>
>> I have a very thin header only C++ library, which is an extension on 
>> top of
>> a c library i.e some of the C++ functions call functions in a C 
>> dll/so. So
>> the C++ library only provides a nice way of using the C library with
>> operators and overloading etc. For this library I want to make an python
>> interface, which only should mimic the C++ classes and functions i.e 
>> there
>> will be a 1:1 mapping.
>>
>> Questions :
>>
>> 1) Would Boost.Python be suited for such a task ?
>>
>
> Almost definitely.  For this sort of task most people use 
> Boost.Python, SWIG, or the raw Python C-API.
>
> Boost.Python is my favorite, and probably the favorite of most people 
> on this list.  The Python C-API (what I think you're calling "cython") 
> is a lot less automatic; you'll find yourself writing a lot more code, 
> and doing a lot more memory management.  SWIG can be much more 
> automatic if your C/C++ interface is sufficiently simple, but it's 
> generally less safe w.r.t. memory management, it chokes on complex 
> C++, and I find it much more difficult to debug.

Cython is something entirely different: see http://cython.org/ . If you 
are basically wrapping a C library I suspect using cython is simpler and 
faster. If C++ support in cython is further improved it will be a 
serious alternative to boost.python.

Regards,
Wichert.

From dave at boostpro.com  Wed Jan 25 16:37:59 2012
From: dave at boostpro.com (Dave Abrahams)
Date: Wed, 25 Jan 2012 10:37:59 -0500
Subject: [C++-sig] langbinding questions
In-Reply-To: <4F137E4A.7050403@gmail.com> (Jim Bosch's message of "Sun, 15 Jan
	2012 20:32:58 -0500")
References: <4F137E4A.7050403@gmail.com>
Message-ID: <m24nvj94iw.fsf@pluto.luannocracy.com>


Hi Jim,

Sorry this is so late.  Sick, work, sick, work... you know how it can
be.

on Sun Jan 15 2012, Jim Bosch <talljimbo-AT-gmail.com> wrote:

> I've been trying to wrap my head around some Boost.Langbinding
> concepts as part of my (slow, but not dead) work on an eventual
> Boost.Python v3. I've got some questions - and if there are others who
> I should be sending this email to, please let me know and/or forward.

Yeah, you should send it to the langbinding list and/or Cc: Daniel
Wallin.

> As I understand it, the basic idea is:
>
> 1) We build a language-agnostic front-end "module definition" data
> structure that gets stored in a static object.

I don't know what you mean by "static object," but the rest is dead on.

> 2) That data structure hides all the type information somehow

Hides it at compile-time; represents it at runtime.

> - I'm imagining a polymorphic non-template base class with templated
> derived classes, or something equivalent.  But I get the sense that
> this may be an incorrect assumption.

I don't know why; sounds like a classic type erasure pattern.

> 3) We pass in a target-language-specific "module builder" to the
> "module definition", which goes through itself and calls visit member
> functions on the "module builder", which in turn creates the
> target-language wrapper.

That sounds right.

> I can see, roughly, how this would work if there's only one module
> builder class (i.e. one target language).  The polymorphic classes in
> the module definition would have virtual functions that just take a
> module_builder instance, and then they can call templated visit member
> functions on the module_builder.
>
> But I don't think that model is what was intended - it doesn't scale
> well to multiple target languages, 

In what way?

> and it doesn't explain why the module_builder classes in the proposal
> (I'm looking here: http://www.boostpro.com/writing/oopsla04.html) use
> CRTP.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

From adam.preble at gmail.com  Sat Jan 28 00:43:10 2012
From: adam.preble at gmail.com (Adam Preble)
Date: Fri, 27 Jan 2012 17:43:10 -0600
Subject: [C++-sig] Properly handling prints and feedback when automatically
	executing a script
Message-ID: <CAE-m0_nqvbj_iJK3BctTL6icEjmha0aFHGB_iWPv=ENxMzsOdA@mail.gmail.com>

I have opted to have my C++ main call an autoexec.py script by default when
compiled to support the interpreter.  Ultimately, I will want to run some
Python code w/o user intervention to do it.  I have come up with this
somewhat naive implementation:

http://pastebin.com/NTytF6iQ

It starts the script but isn't handling prints inside the script.  They
just get completely suppressed.  How can I get them to come out to the
console?

For this matter, this naive implementation just runs in a console.  I'd
love to be able to embed a prettier UI element but it looks like I'd have
to come up with a lot of code myself.  I'm trying to do this for a 3d
project, so it would make some sense to have a console UI embedded in I
could tilde into.  Ultimately, I'd want to be able to autoexec the script,
while having this other console for similarly manipulating state--with
appropriate concurrency controls.  Is there a known path for doing that
kind of thing?

The only place I really saw something like this happening at all was with
Blender, and the code for doing that in particularly didn't just pop right
out at me, and in the IRC channel I wasn't given any other hints than to
look at the code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20120127/62e29b5b/attachment.html>

From talljimbo at gmail.com  Sun Jan 29 18:21:56 2012
From: talljimbo at gmail.com (Jim Bosch)
Date: Sun, 29 Jan 2012 12:21:56 -0500
Subject: [C++-sig] langbinding questions
In-Reply-To: <m27h0gdctm.fsf@pluto.luannocracy.com>
References: <4F137E4A.7050403@gmail.com> <m27h0gdctm.fsf@pluto.luannocracy.com>
Message-ID: <4F258034.3010305@gmail.com>

Thanks...it sounds like I understand things better than I thought I did. 
  Though I'm still worried that I'm confusing which is the "accept" and 
which is the "visit" class somehow.  More questions/replies below.

>> As I understand it, the basic idea is:
>>
>> 1) We build a language-agnostic front-end "module definition" data
>> structure that gets stored in a static object.
>
> I don't know what you mean by "static object," but the rest is dead on.
>

I just meant a namespace-scope variable, static data member, or static 
function-scope variable.  Is there a good catch-all term for such variables?

>> I can see, roughly, how this would work if there's only one module
>> builder class (i.e. one target language).  The polymorphic classes in
>> the module definition would have virtual functions that just take a
>> module_builder instance, and then they can call templated visit member
>> functions on the module_builder.
>>
>> But I don't think that model is what was intended - it doesn't scale
>> well to multiple target languages,
>
> In what way?
>

In the sense that all the frontend classes seem to need to enumerate all 
the possible backends, because they each have a different module_builder 
class.  Some super-simplified code for what I'm imagining:

class frontend_function {
public:
   virtual visit(python_builder & b) = 0;
   virtual visit(lua_builder & b) = 0;
};

template <typename FunctionPointer>
class frontend_function_t : public frontend_function {
public:
   virtual visit(python_builder & b) {
     b.wrap_function(m_name, m_func);
   }
   virtual visit(lua_builder & b) {
     b.wrap_function(m_name, m_func);
   }
private:
   std::string m_name;
   FunctionPointer m_func;
};

class python_builder : public module_builder {
public:
   template <typename FunctionPointer>
   void wrap_function(std::string const & name, FunctionPointer p);
};

This isn't horrible, and "doesn't scale" is the wrong phrase, but it 
doesn't allow you to add new backends without modifying the core 
library, and I had (perhaps naively) assumed that was part of the design.

>> and it doesn't explain why the module_builder classes in the proposal
>> (I'm looking here: http://www.boostpro.com/writing/oopsla04.html) use
>> CRTP.
>
> I don't see any CRTP.  There's some prototype code in SVN that might explain
> details such as module_builder's template parameter.
>

It's probably just a red-herring of some sort, but the section 3.2 of 
the above doc starts with "Module builders must be instances of a class 
derived from a CRTP base class".  I've looked at the langbinding code in 
the boost svn sandbox, and I'm it seem to be mostly utility code at the 
moment (though I admit I don't understand how a lot of it fits together, 
so maybe I'm missing the forrest for the trees).

Thanks!

Jim


From josh.davidson at lmco.com  Mon Jan 30 02:21:49 2012
From: josh.davidson at lmco.com (Davidson, Josh)
Date: Mon, 30 Jan 2012 01:21:49 +0000
Subject: [C++-sig] Odd dlopen behavior
Message-ID: <86299D4CFE2C1248AA41ACF782B0D143117DD654@HDXDSP33.us.lmco.com>

I'm wrapping a C++ project with Py++/Boost.Python under Windows and Linux.  Everything in Windows is working fine, but I'm a bit confused over the behavior in Linux.  The C++ project is built into a single shared library called libsimif, but I'd like to split it up into 3 separate extension modules.  For simplicity, I'll only discuss two of them, since the behavior for the third is identical.  The first, called storage contains definitions of data structures.  It has no dependencies on anything defined in either of the other two extension modules.  The second module, control, uses data structures that are defined in storage.   On the C++ side of things, the headers and source files for storage and control are in entirely different directories.  I've tried a number of different configurations to build the extensions, but one thing that has remained consistent is that for storage, I am only generating Py++ wrappers for the headers included in the storage directory and only building source files in that directory along with the Py++ generated sources.  Ditto for the control extension.

The current configuration that I am using that works passes in libsimif as a library to the distutils.Extension constructor.  Then before starting Python, I need to ensure that libsimif is found in LD_LIBRARY_PATH.  Then I can launch Python and import either module (or from them) and everything works as-expected.   Here is some sample output from this working configuration:
>>> import ast.simif.model_io.storage as storage
>>> import ast.simif.model_io.control as control
>>> dir(storage)
['DiscreteStore', 'PulseStore', 'RtStore', 'SerialStore', 'SharedMemoryBuilder', 'SharedMemoryDeleter', 'SpaceWireStore', '__doc__', '__file__', '__name__', '__package__']
>>> dir(control)
['DiscreteController', 'ModelIoController', 'PulseController', 'RtController', 'SerialController', 'SpaceWireController', '__doc__', '__file__', '__name__', '__package__']
>>> storage.__file__
'ast/simif/model_io/storage.so'
>>> control.__file__
'ast/simif/model_io/control.so'


As you can see, both modules have their own shared library and unique set of symbols.  Now here is why I am confused.  In Linux, we've always set the dlopen flags to include RTLD_NOW and RTLD_GLOBAL.  If I do that, this is what happens:
>>> import sys
>>> import DLFCN
>>> sys.setdlopenflags(DLFCN.RTLD_NOW | DLFCN.RTLD_GLOBAL)
>>> import ast.simif.model_io.storage as storage
>>> import ast.simif.model_io.control as control
__main__:1: RuntimeWarning: to-Python converter for DiscreteStore::FrameData already registered; second conversion method ignored.
__main__:1: RuntimeWarning: to-Python converter for PulseStore::FrameData already registered; second conversion method ignored.
__main__:1: RuntimeWarning: to-Python converter for RtStore::Link already registered; second conversion method ignored.
__main__:1: RuntimeWarning: to-Python converter for RtStore::FrameData already registered; second conversion method ignored.
__main__:1: RuntimeWarning: to-Python converter for RtStore::RtData already registered; second conversion method ignored.
__main__:1: RuntimeWarning: to-Python converter for SerialStore::FrameData already registered; second conversion method ignored.
__main__:1: RuntimeWarning: to-Python converter for SharedMemoryBuilder already registered; second conversion method ignored.
__main__:1: RuntimeWarning: to-Python converter for SharedMemoryDeleter already registered; second conversion method ignored.
>>> dir(storage)
['DiscreteStore', 'PulseStore', 'RtStore', 'SerialStore', 'SharedMemoryBuilder', 'SharedMemoryDeleter', 'SpaceWireStore', '__doc__', '__file__', '__name__', '__package__']
>>> dir(control)
['DiscreteStore', 'PulseStore', 'RtStore', 'SerialStore', 'SharedMemoryBuilder', 'SharedMemoryDeleter', '__doc__', '__file__', '__name__', '__package__']
>>> storage.__file__
'ast/simif/model_io/storage.so'
>>> control.__file__
'ast/simif/model_io/control.so'

So, here storage imports ok, but control complains about a bunch of duplicate registrations.  Then when inspecting the modules, control is completely wrong.  It's like it tried to import storage twice even though __file__ reports the correct shared libraries.   Perhaps not surprising, if  I change the import order and import control ahead of storage, this is what happens:

>>> import sys
>>> import DLFCN
>>> sys.setdlopenflags(DLFCN.RTLD_NOW | DLFCN.RTLD_GLOBAL)
>>> import ast.simif.model_io.control as control
>>> dir(control)
['DiscreteController', 'ModelIoController', 'PulseController', 'RtController', 'SerialController', 'SpaceWireController', '__doc__', '__file__', '__name__', '__package__']
>>> import ast.simif.model_io.storage as storage
__main__:1: RuntimeWarning: to-Python converter for DiscreteController already registered; second conversion method ignored.
__main__:1: RuntimeWarning: to-Python converter for PulseController already registered; second conversion method ignored.
__main__:1: RuntimeWarning: to-Python converter for RtController already registered; second conversion method ignored.
__main__:1: RuntimeWarning: to-Python converter for SerialController already registered; second conversion method ignored.
__main__:1: RuntimeWarning: to-Python converter for SpaceWireController already registered; second conversion method ignored.
>>> dir(storage)
['DiscreteController', 'ModelIoController', 'PulseController', 'RtController', 'SerialController', 'SpaceWireController', 'SpaceWireStore', '__doc__', '__file__', '__name__', '__package__']

Similar behavior, but now the storage import is FUBAR.  Does anyone understand what is going on here?

I'm using x64 Python 2.6.6 on x64 RHEL 6.  Gcc version 4.4.6.

Thanks,
Josh




From s_sourceforge at nedprod.com  Mon Jan 30 10:34:37 2012
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Mon, 30 Jan 2012 09:34:37 -0000
Subject: [C++-sig] Odd dlopen behavior
In-Reply-To: <86299D4CFE2C1248AA41ACF782B0D143117DD654@HDXDSP33.us.lmco.com>
References: <86299D4CFE2C1248AA41ACF782B0D143117DD654@HDXDSP33.us.lmco.com>
Message-ID: <4F26642D.301.666A4AEF@s_sourceforge.nedprod.com>

On 30 Jan 2012 at 1:21, Davidson, Josh wrote:

> Similar behavior, but now the storage import is FUBAR.  Does anyone
> understand what is going on here? 
> 
> I'm using x64 Python 2.6.6 on x64 RHEL 6.  Gcc version 4.4.6.

It's never popular for me to say this, but shared libraries really 
aren't implemented well in ELF. It's always more unnecessary work 
there due to its bad design.

Have you applied symbol visibility as per 
http://www.nedprod.com/programs/gccvisibility.html? It should be a 
cinch if you already have windows support in there.

On the wider issue, BPL has no concept of DLL/SO type ownership, so 
if DLL A defines a class Foo and DLL B defines a class Foo with a 
completely different definition, all BPL can do is complain when it 
sees the type's registration code being duplicated without knowing if 
it's serious or not. Needless to say, any binary generated here can't 
work reliably unless one disables one or the other of class Foo.

Now regarding your issue, Py++ has to make the assumption that thunk 
code must be generated for each type for each module output even 
though those can't be combined without runtime warnings. If you've 
implemented the GCC visibility stuff above and you still have a 
problem, you need to start marking the clashing symbols as weak or 
inline so GNU ld elides the duplicates at runtime.

I'm sure Py++ can insert the required markup automagically - Roman 
might be able to help here.

If that isn't a runner, start chopping out sections of API mirrored 
into the Python space, or if you need that section then break your 
common DLL/SO into its own python module and have that be imported by 
the modules using that common DLL/SO. Remember that you can split a 
large DLL/SO in multiple Python module representations as needed.

HTH,
Niall

-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 
472909.




From themiwi at users.sourceforge.net  Mon Jan 30 15:32:23 2012
From: themiwi at users.sourceforge.net (Michael Wild)
Date: Mon, 30 Jan 2012 15:32:23 +0100
Subject: [C++-sig] Boost.Python property definition question
Message-ID: <4F26A9F7.2070604@users.sourceforge.net>

Hi all

I can't seem to figure out how to wrap this in Boost.Python without the
need for auxiliary functions:


#include <string>
#include <boost/python.hpp>

using std::string;
using namespace boost::python;

class A
{
  string m_s;
public:
  A(string const& s) : m_s(s) {}
  // read-only access (
  string const& s() const { return m_s; }
  // read-write access
  string& s() { return m_s; }
};

BOOST_PYTHON_MODULE(A)
{
  class_<A> ("A", init<std::string const&>())
    .add_property("s",
      // this getter works fine
      make_function(
        (string const&(A::*)()const)&A::s,
        return_value_policy<copy_const_reference>()),
      // this setter fails
      make_function(
        (string&(A::*)())&A::s,
        return_internal_reference<>()))
    ;
}

When I try to run the following:

import A
a = A.A("Hello")
a.s = "World!"

I get below error message:

ArgumentError: Python argument types in
    None.None(A, str)
did not match C++ signature:
    None(A {lvalue})


How do I solve this problem?

Thanks for any advice


Michael

From talljimbo at gmail.com  Mon Jan 30 16:58:07 2012
From: talljimbo at gmail.com (Jim Bosch)
Date: Mon, 30 Jan 2012 10:58:07 -0500
Subject: [C++-sig] Boost.Python property definition question
In-Reply-To: <4F26A9F7.2070604@users.sourceforge.net>
References: <4F26A9F7.2070604@users.sourceforge.net>
Message-ID: <4F26BE0F.1010903@gmail.com>

On 01/30/2012 09:32 AM, Michael Wild wrote:
> Hi all
>
> I can't seem to figure out how to wrap this in Boost.Python without the
> need for auxiliary functions:
>

<snip>

>    string&  s() { return m_s; }

The second argument to add_property should be an actual setter, not a 
non-const-reference getter.  In this case, you can write another free 
function that delegates to the non-const-getter, then wrap that:

void set_s(A & a, std::string const & s) { a.s() = s; }

...

.add_property("s",
     make_function(
        (string const&(A::*)()const)&A::s,
        return_value_policy<copy_const_reference>()),
     make_function(&set_set)
)



HTH

Jim Bosch

From themiwi at users.sourceforge.net  Mon Jan 30 18:11:07 2012
From: themiwi at users.sourceforge.net (Michael Wild)
Date: Mon, 30 Jan 2012 18:11:07 +0100
Subject: [C++-sig] Boost.Python property definition question
In-Reply-To: <4F26BE0F.1010903@gmail.com>
References: <4F26A9F7.2070604@users.sourceforge.net>
	<4F26BE0F.1010903@gmail.com>
Message-ID: <4F26CF2B.7060404@users.sourceforge.net>

On 01/30/2012 04:58 PM, Jim Bosch wrote:
> On 01/30/2012 09:32 AM, Michael Wild wrote:
>> Hi all
>>
>> I can't seem to figure out how to wrap this in Boost.Python without the
>> need for auxiliary functions:
>>
> 
> <snip>
> 
>>    string&  s() { return m_s; }
> 
> The second argument to add_property should be an actual setter, not a
> non-const-reference getter.  In this case, you can write another free
> function that delegates to the non-const-getter, then wrap that:
> 
> void set_s(A & a, std::string const & s) { a.s() = s; }
> 
> ...
> 
> .add_property("s",
>     make_function(
>        (string const&(A::*)()const)&A::s,
>        return_value_policy<copy_const_reference>()),
>     make_function(&set_set)
> )
> 
> 
> 
> HTH
> 
> Jim Bosch

That's what I've been referring to as "auxiliary" functions. If
possible, I'd like to avoid them because I don't fancy writing hundreds
of those... I could live with calling a template. However, so far I
haven't been able to come up with one that is sufficiently easy to use...

So far I came up with the this:

template<class ArgType, class T, T&(C::*method)()>
void set_helper(T& self, ArgType& arg)
{
  (self.*method)() = arg;
}

But it is a bit cumbersome to use, as it doesn't deduce its first two
template arguments on its own. Is there any way to achieve that feat?

Michael

From talljimbo at gmail.com  Mon Jan 30 19:28:05 2012
From: talljimbo at gmail.com (Jim Bosch)
Date: Mon, 30 Jan 2012 13:28:05 -0500
Subject: [C++-sig] Boost.Python property definition question
In-Reply-To: <4F26CF2B.7060404@users.sourceforge.net>
References: <4F26A9F7.2070604@users.sourceforge.net>
	<4F26BE0F.1010903@gmail.com>
	<4F26CF2B.7060404@users.sourceforge.net>
Message-ID: <4F26E135.2090407@gmail.com>

On 01/30/2012 12:11 PM, Michael Wild wrote:
> That's what I've been referring to as "auxiliary" functions. If
> possible, I'd like to avoid them because I don't fancy writing hundreds
> of those... I could live with calling a template. However, so far I
> haven't been able to come up with one that is sufficiently easy to use...
>
> So far I came up with the this:
>
> template<class ArgType, class T, T&(C::*method)()>
> void set_helper(T&  self, ArgType&  arg)
> {
>    (self.*method)() = arg;
> }
>
> But it is a bit cumbersome to use, as it doesn't deduce its first two
> template arguments on its own. Is there any way to achieve that feat?
>

If you're up for playing with Boost.FunctionTypes, you should be able to 
write a wrapper for make_function that deduces those types for you:

namespace bp = boost::python;

template <typename A, typename T, A&(T::*method)()>
void set_helper(T & self, A const & arg) {
     (self.*method)() = arg;
}

template <class F>
bp::object make_set_helper(F f) {
     // F is the member function type; use Boost.FunctionTypes to
     // figure out A and T, then...
     return bp::make_function(&set_helper<A,T,f>);
}


I'll leave it to you to fill in the details.  I haven't tried it myself, 
but I think it would work.


Jim

From themiwi at users.sourceforge.net  Tue Jan 31 06:41:27 2012
From: themiwi at users.sourceforge.net (Michael Wild)
Date: Tue, 31 Jan 2012 06:41:27 +0100
Subject: [C++-sig] Boost.Python property definition question
In-Reply-To: <4F26E135.2090407@gmail.com>
References: <4F26A9F7.2070604@users.sourceforge.net>
	<4F26BE0F.1010903@gmail.com>
	<4F26CF2B.7060404@users.sourceforge.net>
	<4F26E135.2090407@gmail.com>
Message-ID: <4F277F07.1000105@users.sourceforge.net>

On 01/30/2012 07:28 PM, Jim Bosch wrote:
> On 01/30/2012 12:11 PM, Michael Wild wrote:
>> That's what I've been referring to as "auxiliary" functions. If
>> possible, I'd like to avoid them because I don't fancy writing hundreds
>> of those... I could live with calling a template. However, so far I
>> haven't been able to come up with one that is sufficiently easy to use...
>>
>> So far I came up with the this:
>>
>> template<class ArgType, class T, T&(C::*method)()>
>> void set_helper(T&  self, ArgType&  arg)
>> {
>>    (self.*method)() = arg;
>> }
>>
>> But it is a bit cumbersome to use, as it doesn't deduce its first two
>> template arguments on its own. Is there any way to achieve that feat?
>>
> 
> If you're up for playing with Boost.FunctionTypes, you should be able to
> write a wrapper for make_function that deduces those types for you:
> 
> namespace bp = boost::python;
> 
> template <typename A, typename T, A&(T::*method)()>
> void set_helper(T & self, A const & arg) {
>     (self.*method)() = arg;
> }
> 
> template <class F>
> bp::object make_set_helper(F f) {
>     // F is the member function type; use Boost.FunctionTypes to
>     // figure out A and T, then...
>     return bp::make_function(&set_helper<A,T,f>);
> }
> 
> 
> I'll leave it to you to fill in the details.  I haven't tried it myself,
> but I think it would work.
> 
> 
> Jim

Thanks for that hint, I'll certainly take a look. The only think that
would bother me with this solution is that I would need to disambiguate
between the non-const and const functions with the casting operator again.

Michael

From josh.davidson at lmco.com  Tue Jan 31 17:44:16 2012
From: josh.davidson at lmco.com (Davidson, Josh)
Date: Tue, 31 Jan 2012 16:44:16 +0000
Subject: [C++-sig] EXTERNAL: Re:  Odd dlopen behavior
In-Reply-To: <4F26642D.301.666A4AEF@s_sourceforge.nedprod.com>
References: <86299D4CFE2C1248AA41ACF782B0D143117DD654@HDXDSP33.us.lmco.com>
	<4F26642D.301.666A4AEF@s_sourceforge.nedprod.com>
Message-ID: <86299D4CFE2C1248AA41ACF782B0D143117DDA5B@HDXDSP33.us.lmco.com>

Ok, well I did figure out the discrepancy between these extensions and previous extensions that have been built that required setting RTLD_GLOBAL.  What I'm doing for these extensions is instead of building in all of the original C++ code AND the Py++ generated code into the extension, I'm only building in the Py++ generated sources  and linking an existing shared library containing the original C++ definitions.  Is this non-standard or bad practice?  

One issue with this is I'm now forced to deliver both the Python extension shared libraries and the original shared libraries.  Not a huge deal, but it does add a little work on the deployment and maintenance end.


On 30 Jan 2012 at 1:21, Davidson, Josh wrote:

> Similar behavior, but now the storage import is FUBAR.  Does anyone 
> understand what is going on here?
> 
> I'm using x64 Python 2.6.6 on x64 RHEL 6.  Gcc version 4.4.6.

It's never popular for me to say this, but shared libraries really aren't implemented well in ELF. It's always more unnecessary work there due to its bad design.

Have you applied symbol visibility as per http://www.nedprod.com/programs/gccvisibility.html? It should be a cinch if you already have windows support in there.

On the wider issue, BPL has no concept of DLL/SO type ownership, so if DLL A defines a class Foo and DLL B defines a class Foo with a completely different definition, all BPL can do is complain when it sees the type's registration code being duplicated without knowing if it's serious or not. Needless to say, any binary generated here can't work reliably unless one disables one or the other of class Foo.

Now regarding your issue, Py++ has to make the assumption that thunk code must be generated for each type for each module output even though those can't be combined without runtime warnings. If you've implemented the GCC visibility stuff above and you still have a problem, you need to start marking the clashing symbols as weak or inline so GNU ld elides the duplicates at runtime.

I'm sure Py++ can insert the required markup automagically - Roman might be able to help here.

If that isn't a runner, start chopping out sections of API mirrored into the Python space, or if you need that section then break your common DLL/SO into its own python module and have that be imported by the modules using that common DLL/SO. Remember that you can split a large DLL/SO in multiple Python module representations as needed.

HTH,
Niall

--
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 
472909.



_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig at python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

From talljimbo at gmail.com  Tue Jan 31 17:56:54 2012
From: talljimbo at gmail.com (Jim Bosch)
Date: Tue, 31 Jan 2012 11:56:54 -0500
Subject: [C++-sig] Boost.Python property definition question
In-Reply-To: <4F277F07.1000105@users.sourceforge.net>
References: <4F26A9F7.2070604@users.sourceforge.net>
	<4F26BE0F.1010903@gmail.com>
	<4F26CF2B.7060404@users.sourceforge.net>
	<4F26E135.2090407@gmail.com>
	<4F277F07.1000105@users.sourceforge.net>
Message-ID: <4F281D56.9030405@gmail.com>

On 01/31/2012 12:41 AM, Michael Wild wrote:
> On 01/30/2012 07:28 PM, Jim Bosch wrote:
>> On 01/30/2012 12:11 PM, Michael Wild wrote:
>>> That's what I've been referring to as "auxiliary" functions. If
>>> possible, I'd like to avoid them because I don't fancy writing hundreds
>>> of those... I could live with calling a template. However, so far I
>>> haven't been able to come up with one that is sufficiently easy to use...
>>>
>>> So far I came up with the this:
>>>
>>> template<class ArgType, class T, T&(C::*method)()>
>>> void set_helper(T&   self, ArgType&   arg)
>>> {
>>>     (self.*method)() = arg;
>>> }
>>>
>>> But it is a bit cumbersome to use, as it doesn't deduce its first two
>>> template arguments on its own. Is there any way to achieve that feat?
>>>
>>
>> If you're up for playing with Boost.FunctionTypes, you should be able to
>> write a wrapper for make_function that deduces those types for you:
>>
>> namespace bp = boost::python;
>>
>> template<typename A, typename T, A&(T::*method)()>
>> void set_helper(T&  self, A const&  arg) {
>>      (self.*method)() = arg;
>> }
>>
>> template<class F>
>> bp::object make_set_helper(F f) {
>>      // F is the member function type; use Boost.FunctionTypes to
>>      // figure out A and T, then...
>>      return bp::make_function(&set_helper<A,T,f>);
>> }
>>
>>
>> I'll leave it to you to fill in the details.  I haven't tried it myself,
>> but I think it would work.
>>
>>
>> Jim
>
> Thanks for that hint, I'll certainly take a look. The only think that
> would bother me with this solution is that I would need to disambiguate
> between the non-const and const functions with the casting operator again.
>

You might be able to address that by having two make_helper functions, 
using enable_if/disable_if to select one when the return type is const 
and the other when it isn't.  The one invoked for const returns would 
just call make_function directly to make a getter, while the non-const 
one would be like make_set_helper above.


Jim

From talljimbo at gmail.com  Tue Jan 31 18:02:44 2012
From: talljimbo at gmail.com (Jim Bosch)
Date: Tue, 31 Jan 2012 12:02:44 -0500
Subject: [C++-sig] Properly handling prints and feedback when
 automatically executing a script
In-Reply-To: <CAE-m0_nqvbj_iJK3BctTL6icEjmha0aFHGB_iWPv=ENxMzsOdA@mail.gmail.com>
References: <CAE-m0_nqvbj_iJK3BctTL6icEjmha0aFHGB_iWPv=ENxMzsOdA@mail.gmail.com>
Message-ID: <4F281EB4.1040702@gmail.com>

On 01/27/2012 06:43 PM, Adam Preble wrote:
> I have opted to have my C++ main call an autoexec.py script by default when
> compiled to support the interpreter.  Ultimately, I will want to run some
> Python code w/o user intervention to do it.  I have come up with this
> somewhat naive implementation:
>
> http://pastebin.com/NTytF6iQ
>
> It starts the script but isn't handling prints inside the script.  They
> just get completely suppressed.  How can I get them to come out to the
> console?
>

I think this is essentially a Python C-API problem that has nothing to 
do with Boost.Python, so this probably isn't the best list to get help 
on that question (the cplusplus-sig is perhaps a lot 
Boost.Python-focused than the name would suggest).

> For this matter, this naive implementation just runs in a console.  I'd
> love to be able to embed a prettier UI element but it looks like I'd have
> to come up with a lot of code myself.  I'm trying to do this for a 3d
> project, so it would make some sense to have a console UI embedded in I
> could tilde into.  Ultimately, I'd want to be able to autoexec the script,
> while having this other console for similarly manipulating state--with
> appropriate concurrency controls.  Is there a known path for doing that
> kind of thing?
>
> The only place I really saw something like this happening at all was with
> Blender, and the code for doing that in particularly didn't just pop right
> out at me, and in the IRC channel I wasn't given any other hints than to
> look at the code.
>

It sounds to me like you're trying to do something very complex...to the 
extent that looking at the Blender code may not be a terrible starting 
point, even if you do have to wade through a lot of unrelated code.  In 
any case, I very much doubt you'll find a packaged solution or even much 
in the way of examples that do all of the above without being part of a 
larger system.

Sorry I couldn't be more helpful.

Jim

From sponage at yahoo.com  Tue Jan 31 19:00:09 2012
From: sponage at yahoo.com (Cromwell Enage)
Date: Tue, 31 Jan 2012 10:00:09 -0800 (PST)
Subject: [C++-sig]  Python 3
Message-ID: <1328032809.7204.YahooMailNeo@web162004.mail.bf1.yahoo.com>

Hi, everyone!
On my Mac OS X 10.7.2, I had to edit the bootstrap-generated project-config.jam file so that it contained the following directive:

using python
??? : 3.2
??? : /Library/Frameworks/Python.framework/Versions/3.2/bin/python3.2
??? : /Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/
??? : /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/
??? ;


When running "sudo ./b2 install --with-python --debug-configuration", I read errors stating that bjam (still) couldn't find the Python header files.


Do I have to install Python 3.2 differently from how the GUI package works?

Cromwell D. Enage

From themiwi at users.sourceforge.net  Tue Jan 31 20:52:45 2012
From: themiwi at users.sourceforge.net (Michael Wild)
Date: Tue, 31 Jan 2012 20:52:45 +0100
Subject: [C++-sig] Boost.Python property definition question
In-Reply-To: <4F281D56.9030405@gmail.com>
References: <4F26A9F7.2070604@users.sourceforge.net>
	<4F26BE0F.1010903@gmail.com>
	<4F26CF2B.7060404@users.sourceforge.net>
	<4F26E135.2090407@gmail.com>
	<4F277F07.1000105@users.sourceforge.net>
	<4F281D56.9030405@gmail.com>
Message-ID: <4F28468D.8010104@users.sourceforge.net>

On 01/31/2012 05:56 PM, Jim Bosch wrote:
> On 01/31/2012 12:41 AM, Michael Wild wrote:
>> On 01/30/2012 07:28 PM, Jim Bosch wrote:
>>> On 01/30/2012 12:11 PM, Michael Wild wrote:
>>>> That's what I've been referring to as "auxiliary" functions. If
>>>> possible, I'd like to avoid them because I don't fancy writing hundreds
>>>> of those... I could live with calling a template. However, so far I
>>>> haven't been able to come up with one that is sufficiently easy to
>>>> use...
>>>>
>>>> So far I came up with the this:
>>>>
>>>> template<class ArgType, class T, T&(C::*method)()>
>>>> void set_helper(T&   self, ArgType&   arg)
>>>> {
>>>>     (self.*method)() = arg;
>>>> }
>>>>
>>>> But it is a bit cumbersome to use, as it doesn't deduce its first two
>>>> template arguments on its own. Is there any way to achieve that feat?
>>>>
>>>
>>> If you're up for playing with Boost.FunctionTypes, you should be able to
>>> write a wrapper for make_function that deduces those types for you:
>>>
>>> namespace bp = boost::python;
>>>
>>> template<typename A, typename T, A&(T::*method)()>
>>> void set_helper(T&  self, A const&  arg) {
>>>      (self.*method)() = arg;
>>> }
>>>
>>> template<class F>
>>> bp::object make_set_helper(F f) {
>>>      // F is the member function type; use Boost.FunctionTypes to
>>>      // figure out A and T, then...
>>>      return bp::make_function(&set_helper<A,T,f>);
>>> }
>>>
>>>
>>> I'll leave it to you to fill in the details.  I haven't tried it myself,
>>> but I think it would work.
>>>
>>>
>>> Jim
>>
>> Thanks for that hint, I'll certainly take a look. The only think that
>> would bother me with this solution is that I would need to disambiguate
>> between the non-const and const functions with the casting operator
>> again.
>>
> 
> You might be able to address that by having two make_helper functions,
> using enable_if/disable_if to select one when the return type is const
> and the other when it isn't.  The one invoked for const returns would
> just call make_function directly to make a getter, while the non-const
> one would be like make_set_helper above.
> 
> 
> Jim

Sorry, I think you'll have to expand a bit on that. Do you mean that I
can use enable_if/disable_if to select between the two implementations?

Michael

From talljimbo at gmail.com  Tue Jan 31 21:11:03 2012
From: talljimbo at gmail.com (Jim Bosch)
Date: Tue, 31 Jan 2012 15:11:03 -0500
Subject: [C++-sig] Boost.Python property definition question
In-Reply-To: <4F28468D.8010104@users.sourceforge.net>
References: <4F26A9F7.2070604@users.sourceforge.net>
	<4F26BE0F.1010903@gmail.com>
	<4F26CF2B.7060404@users.sourceforge.net>
	<4F26E135.2090407@gmail.com>
	<4F277F07.1000105@users.sourceforge.net>
	<4F281D56.9030405@gmail.com>
	<4F28468D.8010104@users.sourceforge.net>
Message-ID: <4F284AD7.3020500@gmail.com>

On 01/31/2012 02:52 PM, Michael Wild wrote:

>> You might be able to address that by having two make_helper functions,
>> using enable_if/disable_if to select one when the return type is const
>> and the other when it isn't.  The one invoked for const returns would
>> just call make_function directly to make a getter, while the non-const
>> one would be like make_set_helper above.
>>
>>
>> Jim
>
> Sorry, I think you'll have to expand a bit on that. Do you mean that I
> can use enable_if/disable_if to select between the two implementations?
>

I think so; again, I haven't tested.

Here's the idea:

template <typename F>
typename boost::enable_if<
     boost::is_const<
         typename boost::function_types::result_type<F>::type
     >,
     bp::object
 >::type
make_helper(F f) {
     // deduce A and T ...
     return bp::make_function(
         (A const & (T::*() const))f,
         bp::return_value_policy<copy_const_reference>()
     );
}

template <typename F>
typename boost::disable_if<
     boost::is_const<
         typename boost::function_types::result_type<F>::type
     >,
     bp::object
 >::type
make_helper(F f) {
     // deduce A and T ...
     return bp::make_function(&set_helper<A,T,f>);
}

Hope that works!

Jim