From fraca7 at free.fr  Tue Jun  7 09:40:25 2011
From: fraca7 at free.fr (=?ISO-8859-1?Q?J=E9r=F4me_Laheurte?=)
Date: Tue, 07 Jun 2011 09:40:25 +0200
Subject: [C++-sig] A very strange behaviour of Boost (Mingw, gcc 4.5)
Message-ID: <4DEDD5E9.1090107@free.fr>

Hello. I already asked this on StackOverflow but it doesn't seem to 
inspire many people. I managed to reduce my problem to a trivial 
extension module:

#include <Python.h>
#include <boost/python.hpp>

using namespace boost::python ;
using namespace boost;

class PyTest
{
public:
     PyTest();
};

PyTest::PyTest()
{
     PyErr_SetString(PyExc_RuntimeError, "FOO");
     throw_error_already_set();
}

BOOST_PYTHON_MODULE(testmod)
{
     class_<PyTest>("Test", init<>())
         ;
}

On Windows XP SP3, if I build Boost 1.46.1 and then this extension with 
GCC 3.4.5 from an older version of Mingw, everything behaves as expected:

 >>> import testmod
 >>> testmod.Test()
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
RuntimeError: FOO

Now if I rebuild both Boost and the module using a newer Mingw, with GCC 
4.5.2, this happens:

 >>> import testmod
 >>> testmod.Test()

This application has requested the Runtime to terminate it in an unusual 
way.
Please contact the application's support team for more information.

Putting a break on abort in GDB and printing the stack gives this:

(gdb) bt
#0  0x77c36bb3 in msvcrt!abort () from C:\WINDOWS\system32\msvcrt.dll
#1  0x69acfdb2 in testmod!_Unwind_SetGR () from C:\Python22\DLLs\testmod.pyd
#2  0x69b2a45d in 
testmod!_ZNK5boost6python7objects23caller_py_function_implINS0
_6detail6callerIPFvP7_objectENS0_21default_call_policiesENS_3mpl7vector2IvS6_EEE
EE9signatureEv () from C:\Python22\DLLs\testmod.pyd
#3  0x6e9544a3 in libgcc_s_dw2-1!__trunctfxf2 ()
    from C:\WINDOWS\system32\libgcc_s_dw2-1.dll
#4  0x6e954877 in libgcc_s_dw2-1!_Unwind_RaiseException ()
    from C:\WINDOWS\system32\libgcc_s_dw2-1.dll
#5  0x6fcbc6e2 in libstdc++-6!__cxa_throw ()
    from C:\WINDOWS\system32\libstdc++-6.dll
#6  0x63455d4c in boost::python::throw_error_already_set() ()
    from C:\WINDOWS\system32\libboost_python-mgw45-mt-1_46_1.dll
#7  0x69ac12de in testmod!_ZN6PyTestC2Ev () from 
C:\Python22\DLLs\testmod.pyd
#8  0x69adbbf1 in 
testmod!_ZN5boost6python7objects11make_holderILi0EE5applyINS1_
12value_holderI6PyTestEENS_3mpl7vector0IN4mpl_2naEEEE7executeEP7_object ()
    from C:\Python22\DLLs\testmod.pyd
#9  0x69adbde9 in 
testmod!_ZN5boost6python7objects23caller_py_function_implINS0_
6detail6callerIPFvP7_objectENS0_21default_call_policiesENS_3mpl7vector2IvS6_EEEE
EclES6_S6_ () from C:\Python22\DLLs\testmod.pyd
#10 0x63450031 in boost::python::objects::function::call(_object*, 
_object*) con
st () from C:\WINDOWS\system32\libboost_python-mgw45-mt-1_46_1.dll
#11 0x634501fb in 
boost::detail::function::void_function_ref_invoker0<boost::pyt
hon::objects::(anonymous namespace)::bind_return, 
void>::invoke(boost::detail::f
unction::function_buffer&) ()
    from C:\WINDOWS\system32\libboost_python-mgw45-mt-1_46_1.dll
#12 0x63455e5a in 
boost::python::handle_exception_impl(boost::function0<void>)
     () from C:\WINDOWS\system32\libboost_python-mgw45-mt-1_46_1.dll
#13 0x634512be in function_call ()
    from C:\WINDOWS\system32\libboost_python-mgw45-mt-1_46_1.dll
#14 0x1e006ccc in python22!PyObject_Call ()
    from C:\WINDOWS\system32\python22.dll
#15 0x0089d138 in ?? ()
#16 0x63469420 in boost::python::docstring_options::show_py_signatures_ ()
    from C:\WINDOWS\system32\libboost_python-mgw45-mt-1_46_1.dll
#17 0x0084d0f0 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

It looks like the error_already_set exception is somewhat not catched as 
it should be. In my actual use case, the class has several methods. This 
only happens with some of them; I couldn't find any difference between 
the methods for which the mechanism works and the other ones (same 
number and type of parameters, same exception type)...

Any hint would be greatly appreciated.

From zao at acc.umu.se  Tue Jun  7 09:59:27 2011
From: zao at acc.umu.se (Lars Viklund)
Date: Tue, 7 Jun 2011 09:59:27 +0200
Subject: [C++-sig] A very strange behaviour of Boost (Mingw, gcc 4.5)
In-Reply-To: <4DEDD5E9.1090107@free.fr>
References: <4DEDD5E9.1090107@free.fr>
Message-ID: <20110607075925.GG278722@lenin.acc.umu.se>

On Tue, Jun 07, 2011 at 09:40:25AM +0200, J?r?me Laheurte wrote:
> Hello. I already asked this on StackOverflow but it doesn't seem to  
> inspire many people. I managed to reduce my problem to a trivial  
> extension module:

> On Windows XP SP3, if I build Boost 1.46.1 and then this extension with  
> GCC 3.4.5 from an older version of Mingw, everything behaves as expected:

> Now if I rebuild both Boost and the module using a newer Mingw, with GCC  
> 4.5.2, this happens:

> Any hint would be greatly appreciated.

Typically, you need to use the same major flavor of toolchain to build
Boost.Python and your extension as was used to build your Python.

If the runtimes (and exception handling) differ, you'll get ODR
violations on things like FILE* and error handling.

What you're observing there is probably console output crashing when an
error is printed. If the runtimes have different ideas of what
constitutes a FILE* (which output is done through), you blow up good.
This also includes using static runtimes to some extent.

-- 
Lars Viklund | zao at acc.umu.se

From fraca7 at free.fr  Tue Jun  7 10:27:46 2011
From: fraca7 at free.fr (=?UTF-8?B?SsOpcsO0bWUgTGFoZXVydGU=?=)
Date: Tue, 07 Jun 2011 10:27:46 +0200
Subject: [C++-sig] A very strange behaviour of Boost (Mingw, gcc 4.5)
In-Reply-To: <20110607075925.GG278722@lenin.acc.umu.se>
References: <4DEDD5E9.1090107@free.fr>
	<20110607075925.GG278722@lenin.acc.umu.se>
Message-ID: <4DEDE102.9030903@free.fr>

On 06/07/2011 09:59 AM, Lars Viklund wrote:

> On Tue, Jun 07, 2011 at 09:40:25AM +0200, J?r?me Laheurte wrote:
>> Hello. I already asked this on StackOverflow but it doesn't seem to
>> inspire many people. I managed to reduce my problem to a trivial
>> extension module:
>
>> On Windows XP SP3, if I build Boost 1.46.1 and then this extension with
>> GCC 3.4.5 from an older version of Mingw, everything behaves as expected:
>
>> Now if I rebuild both Boost and the module using a newer Mingw, with GCC
>> 4.5.2, this happens:
>
>> Any hint would be greatly appreciated.
>
> Typically, you need to use the same major flavor of toolchain to build
> Boost.Python and your extension as was used to build your Python.
>
> If the runtimes (and exception handling) differ, you'll get ODR
> violations on things like FILE* and error handling.
>
> What you're observing there is probably console output crashing when an
> error is printed. If the runtimes have different ideas of what
> constitutes a FILE* (which output is done through), you blow up good.
> This also includes using static runtimes to some extent.

So the old Mingw 3.x runtime was compatible with the Visual 6 one but 
not the 4.5 one... Thanks for the suggestion; I'll try to get Python to 
build with GCC 4.5 and see if it fixes the issue.

Thanks!

From fraca7 at free.fr  Fri Jun 10 14:15:35 2011
From: fraca7 at free.fr (=?UTF-8?B?SsOpcsO0bWUgTGFoZXVydGU=?=)
Date: Fri, 10 Jun 2011 14:15:35 +0200
Subject: [C++-sig] A very strange behaviour of Boost (Mingw, gcc 4.5)
In-Reply-To: <20110607075925.GG278722@lenin.acc.umu.se>
References: <4DEDD5E9.1090107@free.fr>
	<20110607075925.GG278722@lenin.acc.umu.se>
Message-ID: <4DF20AE7.2060904@free.fr>

On 06/07/2011 09:59 AM, Lars Viklund wrote:

> On Tue, Jun 07, 2011 at 09:40:25AM +0200, J?r?me Laheurte wrote:
>> Hello. I already asked this on StackOverflow but it doesn't seem to
>> inspire many people. I managed to reduce my problem to a trivial
>> extension module:
>
>> On Windows XP SP3, if I build Boost 1.46.1 and then this extension with
>> GCC 3.4.5 from an older version of Mingw, everything behaves as expected:
>
>> Now if I rebuild both Boost and the module using a newer Mingw, with GCC
>> 4.5.2, this happens:
>
>> Any hint would be greatly appreciated.
>
> Typically, you need to use the same major flavor of toolchain to build
> Boost.Python and your extension as was used to build your Python.
>
> If the runtimes (and exception handling) differ, you'll get ODR
> violations on things like FILE* and error handling.
>
> What you're observing there is probably console output crashing when an
> error is printed. If the runtimes have different ideas of what
> constitutes a FILE* (which output is done through), you blow up good.
> This also includes using static runtimes to some extent.

Alas, this does not seem to be the case. I managed to rebuild Python 
with GCC 4.5 after some minor modifications of the interpreter code, 
then rebuilt boost and my extension. The same thing happens (except that 
the call stack is more detailed since the "upper" layers now have GCC 
debugging symbols).

Besides, if I replace throw_error_already_set() by PyErr_Print(), the 
message is properly displayed; and on the other hand in my actual use 
case, it works with some methods.

Still lost...

From fraca7 at free.fr  Fri Jun 10 14:16:19 2011
From: fraca7 at free.fr (=?UTF-8?B?SsOpcsO0bWUgTGFoZXVydGU=?=)
Date: Fri, 10 Jun 2011 14:16:19 +0200
Subject: [C++-sig] A very strange behaviour of Boost (Mingw, gcc 4.5)
In-Reply-To: <20110607075925.GG278722@lenin.acc.umu.se>
References: <4DEDD5E9.1090107@free.fr>
	<20110607075925.GG278722@lenin.acc.umu.se>
Message-ID: <4DF20B13.9040403@free.fr>

On 06/07/2011 09:59 AM, Lars Viklund wrote:

> On Tue, Jun 07, 2011 at 09:40:25AM +0200, J?r?me Laheurte wrote:
>> Hello. I already asked this on StackOverflow but it doesn't seem to
>> inspire many people. I managed to reduce my problem to a trivial
>> extension module:
>
>> On Windows XP SP3, if I build Boost 1.46.1 and then this extension with
>> GCC 3.4.5 from an older version of Mingw, everything behaves as expected:
>
>> Now if I rebuild both Boost and the module using a newer Mingw, with GCC
>> 4.5.2, this happens:
>
>> Any hint would be greatly appreciated.
>
> Typically, you need to use the same major flavor of toolchain to build
> Boost.Python and your extension as was used to build your Python.
>
> If the runtimes (and exception handling) differ, you'll get ODR
> violations on things like FILE* and error handling.
>
> What you're observing there is probably console output crashing when an
> error is printed. If the runtimes have different ideas of what
> constitutes a FILE* (which output is done through), you blow up good.
> This also includes using static runtimes to some extent.

Alas, this does not seem to be the case. I managed to rebuild Python 
with GCC 4.5 after some minor modifications of the interpreter code, 
then rebuilt boost and my extension. The same thing happens (except that 
the call stack is more detailed since the "upper" layers now have GCC 
debugging symbols).

Besides, if I replace throw_error_already_set() by PyErr_Print(), the 
message is properly displayed; and on the other hand in my actual use 
case, it works with some methods.

Still lost...

From s_sourceforge at nedprod.com  Fri Jun 10 14:48:47 2011
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 10 Jun 2011 13:48:47 +0100
Subject: [C++-sig] A very strange behaviour of Boost (Mingw, gcc 4.5)
In-Reply-To: <4DF20B13.9040403@free.fr>
References: <4DEDD5E9.1090107@free.fr>,
	<20110607075925.GG278722@lenin.acc.umu.se>,
	<4DF20B13.9040403@free.fr>
Message-ID: <4DF212AF.25640.DBDD0267@s_sourceforge.nedprod.com>

Might this be a symbol visibility problem?

Niall


On 10 Jun 2011 at 14:16, J?r?me Laheurte wrote:

> On 06/07/2011 09:59 AM, Lars Viklund wrote:
> 
> > On Tue, Jun 07, 2011 at 09:40:25AM +0200, J?r?me Laheurte wrote:
> >> Hello. I already asked this on StackOverflow but it doesn't seem to
> >> inspire many people. I managed to reduce my problem to a trivial
> >> extension module:
> >
> >> On Windows XP SP3, if I build Boost 1.46.1 and then this extension with
> >> GCC 3.4.5 from an older version of Mingw, everything behaves as expected:
> >
> >> Now if I rebuild both Boost and the module using a newer Mingw, with GCC
> >> 4.5.2, this happens:
> >
> >> Any hint would be greatly appreciated.
> >
> > Typically, you need to use the same major flavor of toolchain to build
> > Boost.Python and your extension as was used to build your Python.
> >
> > If the runtimes (and exception handling) differ, you'll get ODR
> > violations on things like FILE* and error handling.
> >
> > What you're observing there is probably console output crashing when an
> > error is printed. If the runtimes have different ideas of what
> > constitutes a FILE* (which output is done through), you blow up good.
> > This also includes using static runtimes to some extent.
> 
> Alas, this does not seem to be the case. I managed to rebuild Python 
> with GCC 4.5 after some minor modifications of the interpreter code, 
> then rebuilt boost and my extension. The same thing happens (except that 
> the call stack is more detailed since the "upper" layers now have GCC 
> debugging symbols).
> 
> Besides, if I replace throw_error_already_set() by PyErr_Print(), the 
> message is properly displayed; and on the other hand in my actual use 
> case, it works with some methods.
> 
> Still lost...
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig


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




From fraca7 at free.fr  Fri Jun 10 16:03:37 2011
From: fraca7 at free.fr (=?ISO-8859-1?Q?J=E9r=F4me_Laheurte?=)
Date: Fri, 10 Jun 2011 16:03:37 +0200
Subject: [C++-sig] A very strange behaviour of Boost (Mingw, gcc 4.5)
In-Reply-To: <4DF212AF.25640.DBDD0267@s_sourceforge.nedprod.com>
References: <4DEDD5E9.1090107@free.fr>,
	<20110607075925.GG278722@lenin.acc.umu.se>,
	<4DF20B13.9040403@free.fr>
	<4DF212AF.25640.DBDD0267@s_sourceforge.nedprod.com>
Message-ID: <4DF22439.2010607@free.fr>

On 06/10/2011 02:48 PM, Niall Douglas wrote:

> Might this be a symbol visibility problem?

How can I check that ? I just tried #defining 
BOOST_PYTHON_USE_GCC_SYMBOL_VISIBILITY in boost/python/detail/config.hpp 
and rebuilt the whole stuff but there's no difference.

Thanks
J?r?me Laheurte

From s_sourceforge at nedprod.com  Fri Jun 10 17:00:53 2011
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 10 Jun 2011 16:00:53 +0100
Subject: [C++-sig] A very strange behaviour of Boost (Mingw, gcc 4.5)
In-Reply-To: <4DF22439.2010607@free.fr>
References: <4DEDD5E9.1090107@free.fr>,
	<4DF212AF.25640.DBDD0267@s_sourceforge.nedprod.com>,
	<4DF22439.2010607@free.fr>
Message-ID: <4DF231A5.1675.DC55F5E7@s_sourceforge.nedprod.com>

On 10 Jun 2011 at 16:03, J?r?me Laheurte wrote:

> > Might this be a symbol visibility problem?
> 
> How can I check that ? I just tried #defining 
> BOOST_PYTHON_USE_GCC_SYMBOL_VISIBILITY in boost/python/detail/config.hpp 
> and rebuilt the whole stuff but there's no difference.

I have little experience of Mingw personally. If I want to build for 
Windows, I use MSVC :)

On POSIX, older versions of the GCC runtime require you to always 
keep symbols which are used to throw exceptions as default visibility 
as they compare symbols by address not content. Newer GCC runtimes 
finally do what I said they should have done from the beginning which 
is to string compare the mangled symbol.

If BPL is throwing an exception and the catch handler isn't being 
found like it ought to be, this suggests they've broken the above in 
the Mingw port of GCC somehow. It could also be a problem of stack 
corruption causing the unwind records to get corrupted. I can't be 
any more definite because how PE binaries use symbols differently to 
ELF kinda suggests that GCC surely isn't copying the POSIX GCC 
exception type matching system anyway.

If you're really keen on continuing to use Mingw, I'd first suggest 
you see if you can duplicate the problem in Cygwin. If you can you'll 
get a much bigger audience. Then you'll need a very reduced example 
exhibiting the bug, one not including Boost. Then you'll need to come 
up with a patch to PE GCC to fix it and wait the whatever number of 
weeks to get it into mainline.

Or you could stick with an older version of Mingw and wait till 
someone else fixes the problem. Or use MSVC.

BTW, debugging exception throws is a royal PITA. There ought to be 
some debug code in the GCC runtime if I remember, you could try 
turning that on and it will print each stage of what it does when you 
throw and/or rethrow an exception.

HTH,
Niall

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




From fraca7 at free.fr  Fri Jun 10 18:07:43 2011
From: fraca7 at free.fr (=?iso-8859-1?Q?J=E9r=F4me_Laheurte?=)
Date: Fri, 10 Jun 2011 18:07:43 +0200
Subject: [C++-sig] A very strange behaviour of Boost (Mingw, gcc 4.5)
In-Reply-To: <4DF231A5.1675.DC55F5E7@s_sourceforge.nedprod.com>
References: <4DEDD5E9.1090107@free.fr>,
	<4DF212AF.25640.DBDD0267@s_sourceforge.nedprod.com>,
	<4DF22439.2010607@free.fr>
	<4DF231A5.1675.DC55F5E7@s_sourceforge.nedprod.com>
Message-ID: <7317A796-61B6-43F7-A250-E8EDB0EDDD2B@free.fr>


Le 10 juin 2011 ? 17:00, Niall Douglas a ?crit :

> On 10 Jun 2011 at 16:03, J?r?me Laheurte wrote:
> 
>>> Might this be a symbol visibility problem?
>> 
>> How can I check that ? I just tried #defining
>> BOOST_PYTHON_USE_GCC_SYMBOL_VISIBILITY in boost/python/detail/config.hpp
>> and rebuilt the whole stuff but there's no difference.
> 
> I have little experience of Mingw personally. If I want to build for
> Windows, I use MSVC :)
> 
> On POSIX, older versions of the GCC runtime require you to always
> keep symbols which are used to throw exceptions as default visibility
> as they compare symbols by address not content. Newer GCC runtimes
> finally do what I said they should have done from the beginning which
> is to string compare the mangled symbol.
> 
> If BPL is throwing an exception and the catch handler isn't being
> found like it ought to be, this suggests they've broken the above in
> the Mingw port of GCC somehow. It could also be a problem of stack
> corruption causing the unwind records to get corrupted. I can't be
> any more definite because how PE binaries use symbols differently to
> ELF kinda suggests that GCC surely isn't copying the POSIX GCC
> exception type matching system anyway.
> 
> If you're really keen on continuing to use Mingw, I'd first suggest
> you see if you can duplicate the problem in Cygwin. If you can you'll
> get a much bigger audience. Then you'll need a very reduced example
> exhibiting the bug, one not including Boost. Then you'll need to come
> up with a patch to PE GCC to fix it and wait the whatever number of
> weeks to get it into mainline.
> 
> Or you could stick with an older version of Mingw and wait till
> someone else fixes the problem. Or use MSVC.

Not really an option; GCC 4 gave us a factor 3 performance improvement over GCC 3, which we really need, and we're not really MSVC people.

> 
> BTW, debugging exception throws is a royal PITA. There ought to be
> some debug code in the GCC runtime if I remember, you could try
> turning that on and it will print each stage of what it does when you
> throw and/or rethrow an exception.

OK Thanks for all the tips. Basically, this is not a Boost issue so I'll have to follow the GCC bug track :)

J?r?me Laheurte


From s_sourceforge at nedprod.com  Fri Jun 10 19:47:55 2011
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Fri, 10 Jun 2011 18:47:55 +0100
Subject: [C++-sig] A very strange behaviour of Boost (Mingw, gcc 4.5)
In-Reply-To: <7317A796-61B6-43F7-A250-E8EDB0EDDD2B@free.fr>
References: <4DEDD5E9.1090107@free.fr>,
	<4DF231A5.1675.DC55F5E7@s_sourceforge.nedprod.com>,
	<7317A796-61B6-43F7-A250-E8EDB0EDDD2B@free.fr>
Message-ID: <4DF258CB.8475.DCEEE2E3@s_sourceforge.nedprod.com>

> > Or you could stick with an older version of Mingw and wait till
> > someone else fixes the problem. Or use MSVC.
> 
> Not really an option; GCC 4 gave us a factor 3 performance improvement
> over GCC 3, which we really need, and we're not really MSVC people. 

Ah that's a useful clue - I patched symbol visibility into what 
became GCC v4.0. I bet what's happened is that the PE outputting GCC 
doesn't have support for this new feature, or it's been borked.

BTW MSVC is little different to GCC when used via the command line 
e.g. using Boost Jam, Makefiles or scons. It's also free of cost via 
Visual Studio Express.

> > BTW, debugging exception throws is a royal PITA. There ought to be
> > some debug code in the GCC runtime if I remember, you could try
> > turning that on and it will print each stage of what it does when you
> > throw and/or rethrow an exception.
> 
> OK Thanks for all the tips. Basically, this is not a Boost issue so I'll
> have to follow the GCC bug track :) 

Last time I was involved with GCC the PE backend was definitely low 
priority. I hope it's changed since, but since Visual Studio became 
free of charge a lot of fire has vanished from PE producing GCC.

Best of luck,
Niall

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




From jon at mcauliffe.com  Fri Jun 10 01:10:55 2011
From: jon at mcauliffe.com (Jon McAuliffe)
Date: Thu, 9 Jun 2011 16:10:55 -0700
Subject: [C++-sig] c++ exception stack trace
Message-ID: <C45EC212-3363-4827-B76E-47723550998F@mcauliffe.com>


hello,

when a thrown c++ exception is translated to the python layer
and ultimately printed out by the python interpreter, is there
an easy way to print out the corresponding c++-layer stack trace
as well?

thanks
jon.


From s_sourceforge at nedprod.com  Sat Jun 11 12:36:49 2011
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Sat, 11 Jun 2011 11:36:49 +0100
Subject: [C++-sig] c++ exception stack trace
In-Reply-To: <C45EC212-3363-4827-B76E-47723550998F@mcauliffe.com>
References: <C45EC212-3363-4827-B76E-47723550998F@mcauliffe.com>
Message-ID: <4DF34541.2499.E08A8FB4@s_sourceforge.nedprod.com>

On 9 Jun 2011 at 16:10, Jon McAuliffe wrote:

> when a thrown c++ exception is translated to the python layer
> and ultimately printed out by the python interpreter, is there
> an easy way to print out the corresponding c++-layer stack trace
> as well?

Easier on GCC than MSVC. See FXException::init() at:

https://github.com/ned14/tnfox/blob/master/src/FXException.cxx#L304

HTH,
Niall

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




From jon at mcauliffe.com  Mon Jun 13 01:31:56 2011
From: jon at mcauliffe.com (Jon McAuliffe)
Date: Sun, 12 Jun 2011 16:31:56 -0700
Subject: [C++-sig] c++ exception stack trace
In-Reply-To: <4DF34541.2499.E08A8FB4@s_sourceforge.nedprod.com>
References: <C45EC212-3363-4827-B76E-47723550998F@mcauliffe.com>
	<4DF34541.2499.E08A8FB4@s_sourceforge.nedprod.com>
Message-ID: <3C5915A8-E9E5-406C-92A2-4E575E6A7F79@mcauliffe.com>


this is great, thanks niall.

jon.


On Jun 11, 2011, at 3:36 AM, Niall Douglas wrote:

> On 9 Jun 2011 at 16:10, Jon McAuliffe wrote:
> 
>> when a thrown c++ exception is translated to the python layer
>> and ultimately printed out by the python interpreter, is there
>> an easy way to print out the corresponding c++-layer stack trace
>> as well?
> 
> Easier on GCC than MSVC. See FXException::init() at:
> 
> https://github.com/ned14/tnfox/blob/master/src/FXException.cxx#L304
> 
> HTH,
> Niall


From wichert at wiggy.net  Mon Jun 13 23:21:12 2011
From: wichert at wiggy.net (Wichert Akkerman)
Date: Mon, 13 Jun 2011 23:21:12 +0200
Subject: [C++-sig] BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS default args
 core dump
In-Reply-To: <594832.17022.qm@web111402.mail.gq1.yahoo.com>
References: <OF5B146FC1.00BEF1D9-ONC125788B.004DE804-C125788B.0053BD30@LBBW.de>
	<594832.17022.qm@web111402.mail.gq1.yahoo.com>
Message-ID: <4DF67F48.5090900@wiggy.net>

On 2011-5-9 18:34, Ralf W. Grosse-Kunstleve wrote:
> Hi Holger,
>
> You don't need the BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS macro if you support keyword arguments (which is usually best). It should be as simple as:
>
> .def("foo",&DefaultArgs::foo, (bp::arg("arg1")=100, bp::arg("arg2")=10))

Nice, I had not discovered that anywhere in the documentation. Is there 
a similar construction that works for constructors as well?

Wichert.

-- 
Wichert Akkerman <wichert at wiggy.net>   It is simple to make things.
http://www.wiggy.net/                  It is hard to make things simple.

From rwgrosse-kunstleve at lbl.gov  Mon Jun 13 23:59:51 2011
From: rwgrosse-kunstleve at lbl.gov (Ralf Grosse-Kunstleve)
Date: Mon, 13 Jun 2011 14:59:51 -0700
Subject: [C++-sig] BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS default args
 core dump
In-Reply-To: <4DF67F48.5090900@wiggy.net>
References: <OF5B146FC1.00BEF1D9-ONC125788B.004DE804-C125788B.0053BD30@LBBW.de>
	<594832.17022.qm@web111402.mail.gq1.yahoo.com>
	<4DF67F48.5090900@wiggy.net>
Message-ID: <BANLkTinFJduuYsK8wozUw8UHo5yTbuztew@mail.gmail.com>

Hi Wichert,

Yes, it also works for constructors. For example:

http://cci.lbl.gov/cctbx_sources/scitbx/r3_utils_ext.cpp

Ralf

On Mon, Jun 13, 2011 at 2:21 PM, Wichert Akkerman <wichert at wiggy.net> wrote:

> On 2011-5-9 18:34, Ralf W. Grosse-Kunstleve wrote:
>
>> Hi Holger,
>>
>> You don't need the BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS macro if you
>> support keyword arguments (which is usually best). It should be as simple
>> as:
>>
>> .def("foo",&DefaultArgs::foo, (bp::arg("arg1")=100, bp::arg("arg2")=10))
>>
>
> Nice, I had not discovered that anywhere in the documentation. Is there a
> similar construction that works for constructors as well?
>
> Wichert.
>
> --
> Wichert Akkerman <wichert at wiggy.net>   It is simple to make things.
> http://www.wiggy.net/                  It is hard to make things simple.
>
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20110613/76592f7d/attachment.html>

From fraca7 at free.fr  Wed Jun 15 12:46:11 2011
From: fraca7 at free.fr (=?ISO-8859-1?Q?J=E9r=F4me_Laheurte?=)
Date: Wed, 15 Jun 2011 12:46:11 +0200
Subject: [C++-sig] A very strange behaviour of Boost (Mingw, gcc 4.5)
In-Reply-To: <4DF258CB.8475.DCEEE2E3@s_sourceforge.nedprod.com>
References: <4DEDD5E9.1090107@free.fr>,
	<4DF231A5.1675.DC55F5E7@s_sourceforge.nedprod.com>,
	<7317A796-61B6-43F7-A250-E8EDB0EDDD2B@free.fr>
	<4DF258CB.8475.DCEEE2E3@s_sourceforge.nedprod.com>
Message-ID: <4DF88D73.8020402@free.fr>

On 06/10/2011 07:47 PM, Niall Douglas wrote:

>>> Or you could stick with an older version of Mingw and wait till
>>> someone else fixes the problem. Or use MSVC.
>>
>> Not really an option; GCC 4 gave us a factor 3 performance improvement
>> over GCC 3, which we really need, and we're not really MSVC people.
>
> Ah that's a useful clue - I patched symbol visibility into what
> became GCC v4.0. I bet what's happened is that the PE outputting GCC
> doesn't have support for this new feature, or it's been borked.
>
> BTW MSVC is little different to GCC when used via the command line
> e.g. using Boost Jam, Makefiles or scons. It's also free of cost via
> Visual Studio Express.

I guess the simplest workaround would be VS. We even have licences for 
VS 2008 because we use it for other .NET stuff, so it would be 
relatively painless. I'm still gonna take a few days to try to get a 
minimal case.

>>> BTW, debugging exception throws is a royal PITA. There ought to be
>>> some debug code in the GCC runtime if I remember, you could try
>>> turning that on and it will print each stage of what it does when you
>>> throw and/or rethrow an exception.
>>
>> OK Thanks for all the tips. Basically, this is not a Boost issue so I'll
>> have to follow the GCC bug track :)
>
> Last time I was involved with GCC the PE backend was definitely low
> priority. I hope it's changed since, but since Visual Studio became
> free of charge a lot of fire has vanished from PE producing GCC.

OK. Thanks for the tips.

J?r?me Laheurte

From smith.charles75 at yahoo.co.uk  Mon Jun 20 11:20:43 2011
From: smith.charles75 at yahoo.co.uk (charles75)
Date: Mon, 20 Jun 2011 02:20:43 -0700 (PDT)
Subject: [C++-sig] Alignment problem when returning lists from C++ to Python
Message-ID: <1308561643269-3610860.post@n4.nabble.com>

Hi,

OS: UBUNTU 11.04

Could someone please help me out here.

I'm using boost-python.  I have written a C++ program that returns a list
back to Python.
The problem I'm having is that the returned data seems to be misaligned.
When I run the C++ program on its own and print out the structure all seems
well.
However when I copy the structure into the list and return this to Python
the data is corrupted, and I've been told
that this is an alignment issue, but I can't find a way to resolve this
issue.

Thanks in advance for any help.

--
View this message in context: http://boost.2283326.n4.nabble.com/Alignment-problem-when-returning-lists-from-C-to-Python-tp3610860p3610860.html
Sent from the Python - c++-sig mailing list archive at Nabble.com.

From s_sourceforge at nedprod.com  Mon Jun 20 14:20:09 2011
From: s_sourceforge at nedprod.com (Niall Douglas)
Date: Mon, 20 Jun 2011 13:20:09 +0100
Subject: [C++-sig] Alignment problem when returning lists from C++ to
	Python
In-Reply-To: <1308561643269-3610860.post@n4.nabble.com>
References: <1308561643269-3610860.post@n4.nabble.com>
Message-ID: <4DFF3AF9.31720.F4283FF@s_sourceforge.nedprod.com>

You're going to have to give a lot more information than this for 
anyone to help you. In particular, a highly reduced and short example 
of code exhibiting the problem would be very helpful.

Niall

On 20 Jun 2011 at 2:20, charles75 wrote:

> Hi,
> 
> OS: UBUNTU 11.04
> 
> Could someone please help me out here.
> 
> I'm using boost-python.  I have written a C++ program that returns a list
> back to Python.
> The problem I'm having is that the returned data seems to be misaligned.
> When I run the C++ program on its own and print out the structure all seems
> well.
> However when I copy the structure into the list and return this to Python
> the data is corrupted, and I've been told
> that this is an alignment issue, but I can't find a way to resolve this
> issue.
> 
> Thanks in advance for any help.
> 
> --
> View this message in context: http://boost.2283326.n4.nabble.com/Alignment-problem-when-returning-lists-from-C-to-Python-tp3610860p3610860.html
> Sent from the Python - c++-sig mailing list archive at Nabble.com.
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig


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




From smith.charles75 at yahoo.co.uk  Wed Jun 22 17:04:16 2011
From: smith.charles75 at yahoo.co.uk (charles75)
Date: Wed, 22 Jun 2011 08:04:16 -0700 (PDT)
Subject: [C++-sig] Clearing lists in boost-python
Message-ID: <1308755056306-3617273.post@n4.nabble.com>

Hi,

I've been trying to clear a list of dictionaries from a list without
success.
The code below is a simple example of what I'm trying to achieve.

dict a, b;
list mylist;

mylist.append(a);
mylist.append(b);

mylist.clear();
When I type in the last statement I get the error below from the linker  
?class boost::python::list? has no member named ?clear?.

Is there another way of clearing the list?

Thanks in advance for any help.


--
View this message in context: http://boost.2283326.n4.nabble.com/Clearing-lists-in-boost-python-tp3617273p3617273.html
Sent from the Python - c++-sig mailing list archive at Nabble.com.

From stefan at seefeld.name  Wed Jun 22 17:15:30 2011
From: stefan at seefeld.name (Stefan Seefeld)
Date: Wed, 22 Jun 2011 11:15:30 -0400
Subject: [C++-sig] Clearing lists in boost-python
In-Reply-To: <1308755056306-3617273.post@n4.nabble.com>
References: <1308755056306-3617273.post@n4.nabble.com>
Message-ID: <4E020712.2050001@seefeld.name>

On 2011-06-22 11:04, charles75 wrote:
> Hi,
>
> I've been trying to clear a list of dictionaries from a list without
> success.
> The code below is a simple example of what I'm trying to achieve.
>
> dict a, b;
> list mylist;
>
> mylist.append(a);
> mylist.append(b);
>
> mylist.clear();
> When I type in the last statement I get the error below from the linker
> ?class boost::python::list? has no member named ?clear?.

Right, and neither does the Python 'list' type have such a method.

> Is there another way of clearing the list?

In Python you'd probably do something like

   del mylist[:]

The equivalent of that in C++ is

   del(mylist[slice()]);

     Stefan

-- 

       ...ich hab' noch einen Koffer in Berlin...


From smith.charles75 at yahoo.co.uk  Wed Jun 22 17:38:22 2011
From: smith.charles75 at yahoo.co.uk (charles75)
Date: Wed, 22 Jun 2011 08:38:22 -0700 (PDT)
Subject: [C++-sig] Clearing lists in boost-python
In-Reply-To: <4E020712.2050001@seefeld.name>
References: <1308755056306-3617273.post@n4.nabble.com>
	<4E020712.2050001@seefeld.name>
Message-ID: <1308757102931-3617362.post@n4.nabble.com>

Thanks Stefan.

I did try your suggestion but unfortunately the linker gave me errors
regarding del and slice.

Thanks anyway.

--
View this message in context: http://boost.2283326.n4.nabble.com/Clearing-lists-in-boost-python-tp3617273p3617362.html
Sent from the Python - c++-sig mailing list archive at Nabble.com.

From stefan at seefeld.name  Wed Jun 22 17:44:47 2011
From: stefan at seefeld.name (Stefan Seefeld)
Date: Wed, 22 Jun 2011 11:44:47 -0400
Subject: [C++-sig] Clearing lists in boost-python
In-Reply-To: <1308757102931-3617362.post@n4.nabble.com>
References: <1308755056306-3617273.post@n4.nabble.com>	<4E020712.2050001@seefeld.name>
	<1308757102931-3617362.post@n4.nabble.com>
Message-ID: <4E020DEF.10308@seefeld.name>

On 2011-06-22 11:38, charles75 wrote:
> Thanks Stefan.
>
> I did try your suggestion but unfortunately the linker gave me errors
> regarding del and slice.

Without more details it's impossible to help further, sorry.

     Stefan

-- 

       ...ich hab' noch einen Koffer in Berlin...


From llwaeva at gmail.com  Sat Jun 25 08:15:13 2011
From: llwaeva at gmail.com (EVA LIN)
Date: Sat, 25 Jun 2011 14:15:13 +0800
Subject: [C++-sig] about compiling Boost.Python code in MSVC 10 and python
	3.1
Message-ID: <BANLkTi=7jsfR3kZkPXgSGabMK0LT74egFA@mail.gmail.com>

Hi all,
  I am new to Boost.Python. Following the instruction in the help, I try to
compile the quickstart example but there are lots of error

I am using MSVC++ 2010, python 3.1 and Boost.Python 1.46.1

As stated in the help, I first install the boost.build and set the
user-config.jam so the path of my python are visible to the builder

using python : 3.1 : D:/Applications/Python : D:/Applications/Python/include
: D:/Applications/Python/libs ;


Then, by running the command

bjam toolset=msvc --verbose-test test

Some issues are pop out


D:\Programs\BOOSTS\BoostPython\libs\python\example\MyProject\GetStatistics>bjam
toolset=msvc --verbose-test test
...patience...
...patience...
...found 1572 targets...
...updating 21 targets...
common.mkdir bin\test_ext.test
common.mkdir bin\test_ext.test\msvc-10.0
common.mkdir bin\test_ext.test\msvc-10.0\debug
common.mkdir bin\test_ext.test\msvc-10.0\debug\threading-multi
copy test_extending.py
Invalid Command

    copy /b  + this-file-does-not-exist-A698EE7806899E69 "test_extending.py"
"bi
n\test_ext.test\msvc-10.0\debug\threading-multi\test_extending.py"

...failed copy test_extending.py
bin\test_ext.test\msvc-10.0\debug\threading-mul
ti\test_extending.py...
...removing test_extending.py


function.obj : error LNK2019: unresolved external symbol
__imp__PyObject_SetAttr
 referenced in function "public: static void __cdecl
boost::python::objects::fun
ction::add_to_namespace(class boost::python::api::object const &,char const
*,cl
ass boost::python::api::object const &,char const *)"
(?add_to_namespace at functio
n at objects@python at boost@@SAXABVobject at api@34 at PBD01@Z)
object_protocol.obj : error LNK2001: unresolved external symbol
__imp__PyObject_
SetAttr
function.obj : error LNK2001: unresolved external symbol
__imp__PyStaticMethod_T
ype
function.obj : error LNK2019: unresolved external symbol
__imp__PyObject_GetItem
 referenced in function "public: static void __cdecl
boost::python::objects::fun
ction::add_to_namespace(class boost::python::api::object const &,char const
*,cl
ass boost::python::api::object const &,char const *)"
(?add_to_namespace at functio
n at objects@python at boost@@SAXABVobject at api@34 at PBD01@Z)
object_protocol.obj : error LNK2001: unresolved external symbol
__imp__PyObject_
GetItem
function.obj : error LNK2019: unresolved external symbol __imp__PyMethod_New
ref
erenced in function _function_descr_get
function.obj : error LNK2019: unresolved external symbol
__imp__PyUnicode_Intern
FromString referenced in function _function_get_name
function.obj : error LNK2001: unresolved external symbol
__imp__PyCFunction_Type

life_support.obj : error LNK2019: unresolved external symbol
__imp__PyWeakref_Ne
wRef referenced in function "struct _object * __cdecl
boost::python::objects::ma
ke_nurse_and_patient(struct _object *,struct _object *)"
(?make_nurse_and_patien
t at objects@python at boost@@YAPAU_object@@PAU4 at 0@Z)
life_support.obj : error LNK2019: unresolved external symbol
__imp___PyObject_Ne
w referenced in function "struct _object * __cdecl
boost::python::objects::make_
nurse_and_patient(struct _object *,struct _object *)"
(?make_nurse_and_patient at o
bjects at python@boost@@YAPAU_object@@PAU4 at 0@Z)
errors.obj : error LNK2001: unresolved external symbol
__imp__PyExc_ValueError
errors.obj : error LNK2001: unresolved external symbol
__imp__PyExc_IndexError
errors.obj : error LNK2001: unresolved external symbol
__imp__PyExc_OverflowErro
r
errors.obj : error LNK2019: unresolved external symbol __imp__PyErr_NoMemory
ref
erenced in function __catch$?handle_exception_impl at python@boost@
@YA_NV?$function
0 at X@2@@Z$0
module.obj : error LNK2019: unresolved external symbol
__imp__PyModule_Create2 r
eferenced in function "struct _object * __cdecl
boost::python::detail::init_modu
le(struct PyModuleDef &,void (__cdecl*)(void))" (?init_module at detail
@python at boos
t@@YAPAU_object@@AAUPyModuleDef@@P6AXXZ at Z)
builtin_converters.obj : error LNK2019: unresolved external symbol
__imp___PyUni
code_AsString referenced in function "void * __cdecl
boost::python::converter::`
anonymous namespace'::convert_to_cstring(struct _object *)"
(?convert_to_cstring
@?A0x05677deb at converter@python at boost@@YAPAXPAU_object@@@Z)
builtin_converters.obj : error LNK2019: unresolved external symbol
__imp__PyUnic
odeUCS2_FromEncodedObject referenced in function _encode_string_unaryfunc
builtin_converters.obj : error LNK2001: unresolved external symbol
__imp__PyBool
_Type
builtin_converters.obj : error LNK2001: unresolved external symbol
__imp__PyFloa
t_Type
builtin_converters.obj : error LNK2001: unresolved external symbol
__imp__PyComp
lex_Type
builtin_converters.obj : error LNK2019: unresolved external symbol
__imp__PyLong
_AsLongLong referenced in function "public: static __int64 __cdecl
boost::python
::converter::`anonymous
namespace'::long_long_rvalue_from_python::extract(struct
 _object *)" (?extract at long_long_rvalue_from_python@?A0x05677deb at converter
@pytho
n at boost@@SA_JPAU_object@@@Z)
builtin_converters.obj : error LNK2019: unresolved external symbol
__imp__PyLong
_AsUnsignedLongLong referenced in function "public: static unsigned __int64
__cd
ecl boost::python::converter::`anonymous
namespace'::unsigned_long_long_rvalue_f
rom_python::extract(struct _object *)"
(?extract at unsigned_long_long_rvalue_from_
python@?A0x05677deb at converter@python at boost@@SA_KPAU_object@@@Z)
builtin_converters.obj : error LNK2019: unresolved external symbol
__imp__PyComp
lex_RealAsDouble referenced in function "public: static class
std::complex<doubl
e> __cdecl boost::python::converter::`anonymous
namespace'::complex_rvalue_from_
python::extract(struct _object *)" (?extract at complex_rvalue_from_python
@?A0x0567
7deb at converter@python at boost@@SA?AV?$complex at N@std@@PAU_object@@@Z)
builtin_converters.obj : error LNK2019: unresolved external symbol
__imp__PyComp
lex_ImagAsDouble referenced in function "public: static class
std::complex<doubl
e> __cdecl boost::python::converter::`anonymous
namespace'::complex_rvalue_from_
python::extract(struct _object *)" (?extract at complex_rvalue_from_python
@?A0x0567
7deb at converter@python at boost@@SA?AV?$complex at N@std@@PAU_object@@@Z)
builtin_converters.obj : error LNK2019: unresolved external symbol
__imp__PyUnic
odeUCS2_AsWideChar referenced in function "public: static class
std::basic_strin
g<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> >
__cde
cl boost::python::converter::`anonymous
namespace'::wstring_rvalue_from_python::
extract(struct _object *)" (?extract at wstring_rvalue_from_python
@?A0x05677deb at con
verter at python@boost@@SA?AV?$basic_string at _WU?$char_traits at _W@std
@@V?$allocator at _
W at 2@@std@@PAU_object@@@Z)
builtin_converters.obj : error LNK2019: unresolved external symbol
__imp__PyByte
s_AsString referenced in function "public: static class
std::basic_string<char,s
truct std::char_traits<char>,class std::allocator<char> > __cdecl
boost::python:
:converter::`anonymous namespace'::string_rvalue_from_python::extract(struct
_ob
ject *)" (?extract at string_rvalue_from_python@?A0x05677deb at converter
@python at boost
@@SA?AV?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@
@PAU_object@@
@Z)
builtin_converters.obj : error LNK2019: unresolved external symbol
__imp__PyByte
s_Size referenced in function "public: static class
std::basic_string<char,struc
t std::char_traits<char>,class std::allocator<char> > __cdecl
boost::python::con
verter::`anonymous namespace'::string_rvalue_from_python::extract(struct
_object
 *)" (?extract at string_rvalue_from_python@?A0x05677deb at converter@python at boost
@@SA
?AV?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@PAU_object@
@@Z)
builtin_converters.obj : error LNK2019: unresolved external symbol
__imp__PyLong
_AsUnsignedLong referenced in function "public: static unsigned char __cdecl
boo
st::python::converter::`anonymous
namespace'::unsigned_int_rvalue_from_python<un
signed char>::extract(struct _object *)" (?extract@
?$unsigned_int_rvalue_from_py
thon at E@?A0x05677deb at converter@python at boost@@SAEPAU_object@@@Z)
builtin_converters.obj : error LNK2019: unresolved external symbol
__imp__PyUnic
odeUCS2_AsUTF8String referenced in function "void __cdecl
boost::python::convert
er::`anonymous namespace'::`dynamic initializer for
'py_unicode_as_string_unaryf
unc''(void)" (??__Epy_unicode_as_string_unaryfunc@?A0x05677deb at converter
@python@
boost@@YAXXZ)
iterator.obj : error LNK2001: unresolved external symbol
__imp__PyExc_StopIterat
ion
stl_iterator.obj : error LNK2019: unresolved external symbol
__imp__PyIter_Next
referenced in function "public: void __thiscall
boost::python::objects::stl_inpu
t_iterator_impl::increment(void)" (?increment at stl_input_iterator_impl
@objects at py
thon at boost@@QAEXXZ)
object_protocol.obj : error LNK2019: unresolved external symbol
__imp__PyObject_
GetAttr referenced in function "class boost::python::api::object __cdecl
boost::
python::api::getattr(class boost::python::api::object const &,class
boost::pytho
n::api::object const &)" (?getattr at api@python at boost@@YA?AVobject at 123
@ABV4123 at 0@Z
)
object_protocol.obj : error LNK2019: unresolved external symbol
__imp__PyErr_Exc
eptionMatches referenced in function "class boost::python::api::object
__cdecl b
oost::python::api::getattr(class boost::python::api::object const &,class
boost:
:python::api::object const &,class boost::python::api::object const &)"
(?getatt
r at api@python at boost@@YA?AVobject at 123@ABV4123 at 00@Z)
object_protocol.obj : error LNK2019: unresolved external symbol
__imp__PyObject_
SetItem referenced in function "void __cdecl
boost::python::api::setitem(class b
oost::python::api::object const &,class boost::python::api::object const
&,class
 boost::python::api::object const &)" (?setitem at api@python at boost
@@YAXABVobject at 1
23 at 00@Z)
object_protocol.obj : error LNK2019: unresolved external symbol
__imp__PyObject_
DelItem referenced in function "void __cdecl
boost::python::api::delitem(class b
oost::python::api::object const &,class boost::python::api::object const &)"
(?d
elitem at api@python at boost@@YAXABVobject at 123@0 at Z)
object_operators.obj : error LNK2019: unresolved external symbol
__imp__PyObject
_RichCompare referenced in function "class boost::python::api::object
__cdecl bo
ost::python::api::operator>(class boost::python::api::object const &,class
boost
::python::api::object const &)" (??Oapi at python@boost@@YA?AVobject at 012
@ABV3012 at 0@
Z)
object_operators.obj : error LNK2019: unresolved external symbol
__imp__PyNumber
_Add referenced in function "class boost::python::api::object __cdecl
boost::pyt
hon::api::operator+(class boost::python::api::object const &,class
boost::python
::api::object const &)" (??Hapi at python@boost@@YA?AVobject at 012@ABV3012 at 0@Z)
object_operators.obj : error LNK2019: unresolved external symbol
__imp__PyNumber
_Subtract referenced in function "class boost::python::api::object __cdecl
boost
::python::api::operator-(class boost::python::api::object const &,class
boost::p
ython::api::object const &)" (??Gapi at python@boost@@YA?AVobject at 012@ABV3012 at 0
@Z)
object_operators.obj : error LNK2019: unresolved external symbol
__imp__PyNumber
_Multiply referenced in function "class boost::python::api::object __cdecl
boost
::python::api::operator*(class boost::python::api::object const &,class
boost::p
ython::api::object const &)" (??Dapi at python@boost@@YA?AVobject at 012@ABV3012 at 0
@Z)
object_operators.obj : error LNK2019: unresolved external symbol
__imp__PyNumber
_FloorDivide referenced in function "class boost::python::api::object
__cdecl bo
ost::python::api::operator/(class boost::python::api::object const &,class
boost
::python::api::object const &)" (??Kapi at python@boost@@YA?AVobject at 012
@ABV3012 at 0@
Z)
object_operators.obj : error LNK2019: unresolved external symbol
__imp__PyNumber
_Remainder referenced in function "class boost::python::api::object __cdecl
boos
t::python::api::operator%(class boost::python::api::object const &,class
boost::
python::api::object const &)" (??Lapi at python@boost@@YA?AVobject at 012
@ABV3012 at 0@Z)

object_operators.obj : error LNK2019: unresolved external symbol
__imp__PyNumber
_Lshift referenced in function "class boost::python::api::object __cdecl
boost::
python::api::operator<<(class boost::python::api::object const &,class
boost::py
thon::api::object const &)" (??6api at python@boost@@YA?AVobject at 012@ABV3012 at 0
@Z)
object_operators.obj : error LNK2019: unresolved external symbol
__imp__PyNumber
_Rshift referenced in function "class boost::python::api::object __cdecl
boost::
python::api::operator>>(class boost::python::api::object const &,class
boost::py
thon::api::object const &)" (??5api at python@boost@@YA?AVobject at 012@ABV3012 at 0
@Z)
object_operators.obj : error LNK2019: unresolved external symbol
__imp__PyNumber
_And referenced in function "class boost::python::api::object __cdecl
boost::pyt
hon::api::operator&(class boost::python::api::object const &,class
boost::python
::api::object const &)" (??Iapi at python@boost@@YA?AVobject at 012@ABV3012 at 0@Z)
object_operators.obj : error LNK2019: unresolved external symbol
__imp__PyNumber
_Xor referenced in function "class boost::python::api::object __cdecl
boost::pyt
hon::api::operator^(class boost::python::api::object const &,class
boost::python
::api::object const &)" (??Tapi at python@boost@@YA?AVobject at 012@ABV3012 at 0@Z)
object_operators.obj : error LNK2019: unresolved external symbol
__imp__PyNumber
_Or referenced in function "class boost::python::api::object __cdecl
boost::pyth
on::api::operator|(class boost::python::api::object const &,class
boost::python:
:api::object const &)" (??Uapi at python@boost@@YA?AVobject at 012@ABV3012 at 0@Z)
object_operators.obj : error LNK2019: unresolved external symbol
__imp__PyNumber
_InPlaceAdd referenced in function "class boost::python::api::object &
__cdecl b
oost::python::api::operator+=(class boost::python::api::object &,class
boost::py
thon::api::object const &)" (??Yapi at python@boost@@YAAAVobject at 012
@AAV3012 at ABV301
2@@Z)
object_operators.obj : error LNK2019: unresolved external symbol
__imp__PyNumber
_InPlaceSubtract referenced in function "class boost::python::api::object &
__cd
ecl boost::python::api::operator-=(class boost::python::api::object &,class
boos
t::python::api::object const &)" (??Zapi at python@boost@@YAAAVobject at 012
@AAV3012 at A
BV3012@@Z)
object_operators.obj : error LNK2019: unresolved external symbol
__imp__PyNumber
_InPlaceMultiply referenced in function "class boost::python::api::object &
__cd
ecl boost::python::api::operator*=(class boost::python::api::object &,class
boos
t::python::api::object const &)" (??Xapi at python@boost@@YAAAVobject at 012
@AAV3012 at A
BV3012@@Z)
object_operators.obj : error LNK2019: unresolved external symbol
__imp__PyNumber
_InPlaceFloorDivide referenced in function "class boost::python::api::object
& _
_cdecl boost::python::api::operator/=(class boost::python::api::object
&,class b
oost::python::api::object const &)" (??_0api at python@boost@@YAAAVobject at 012
@AAV30
12 at ABV3012@@Z)
object_operators.obj : error LNK2019: unresolved external symbol
__imp__PyNumber
_InPlaceRemainder referenced in function "class boost::python::api::object &
__c
decl boost::python::api::operator%=(class boost::python::api::object &,class
boo
st::python::api::object const &)" (??_1api at python@boost@@YAAAVobject at 012
@AAV3012
@ABV3012@@Z)
object_operators.obj : error LNK2019: unresolved external symbol
__imp__PyNumber
_InPlaceLshift referenced in function "class boost::python::api::object &
__cdec
l boost::python::api::operator<<=(class boost::python::api::object &,class
boost
::python::api::object const &)" (??_3api at python@boost@@YAAAVobject at 012
@AAV3012 at A
BV3012@@Z)
object_operators.obj : error LNK2019: unresolved external symbol
__imp__PyNumber
_InPlaceRshift referenced in function "class boost::python::api::object &
__cdec
l boost::python::api::operator>>=(class boost::python::api::object &,class
boost
::python::api::object const &)" (??_2api at python@boost@@YAAAVobject at 012
@AAV3012 at A
BV3012@@Z)
object_operators.obj : error LNK2019: unresolved external symbol
__imp__PyNumber
_InPlaceAnd referenced in function "class boost::python::api::object &
__cdecl b
oost::python::api::operator&=(class boost::python::api::object &,class
boost::py
thon::api::object const &)" (??_4api at python@boost@@YAAAVobject at 012
@AAV3012 at ABV30
12@@Z)
object_operators.obj : error LNK2019: unresolved external symbol
__imp__PyNumber
_InPlaceXor referenced in function "class boost::python::api::object &
__cdecl b
oost::python::api::operator^=(class boost::python::api::object &,class
boost::py
thon::api::object const &)" (??_6api at python@boost@@YAAAVobject at 012
@AAV3012 at ABV30
12@@Z)
object_operators.obj : error LNK2019: unresolved external symbol
__imp__PyNumber
_InPlaceOr referenced in function "class boost::python::api::object &
__cdecl bo
ost::python::api::operator|=(class boost::python::api::object &,class
boost::pyt
hon::api::object const &)" (??_5api at python@boost@@YAAAVobject at 012
@AAV3012 at ABV301
2@@Z)
wrapper.obj : error LNK2019: unresolved external symbol
__imp__PyDict_GetItemStr
ing referenced in function "protected: class boost::python::override
__thiscall
boost::python::detail::wrapper_base::get_override(char const *,struct
_typeobjec
t *)const " (?get_override at wrapper_base@detail at python@boost@
@IBE?AVoverride at 34@P
BDPAU_typeobject@@@Z)
wrapper.obj : error LNK2001: unresolved external symbol __imp__PyMethod_Type
import.obj : error LNK2019: unresolved external symbol
__imp__PyImport_ImportMod
ule referenced in function "class boost::python::api::object __cdecl
boost::pyth
on::import(class boost::python::str)" (?import at python@boost@@YA?AVobject at api
@12@
Vstr at 12@@Z)
exec.obj : error LNK2019: unresolved external symbol
__imp__PyRun_StringFlags re
ferenced in function "class boost::python::api::object __cdecl
boost::python::ev
al(class boost::python::str,class boost::python::api::object,class
boost::python
::api::object)" (?eval at python@boost@@YA?AVobject at api@12 at Vstr@12 at V3412@1 at Z)
exec.obj : error LNK2019: unresolved external symbol
__imp__PyEval_GetGlobals re
ferenced in function "class boost::python::api::object __cdecl
boost::python::ev
al(class boost::python::str,class boost::python::api::object,class
boost::python
::api::object)" (?eval at python@boost@@YA?AVobject at api@12 at Vstr@12 at V3412@1 at Z)
exec.obj : error LNK2019: unresolved external symbol
__imp__PyRun_FileExFlags re
ferenced in function "class boost::python::api::object __cdecl
boost::python::ex
ec_file(class boost::python::str,class boost::python::api::object,class
boost::p
ython::api::object)" (?exec_file at python@boost@@YA?AVobject at api@12 at Vstr
@12 at V3412@
1 at Z)
D:\Programs\BOOSTS\BoostPython\bin.v2\libs\python\build\msvc-10.0\debug\threadin
g-multi\boost_python-vc100-mt-gd-1_46_1.dll : fatal error LNK1120: 130
unresolve
d externals

        call "d:\Applications\MSVC\VC\vcvarsall.bat" x86 >nul
link /NOLOGO /INCREMENTAL:NO /DLL /DEBUG /MACHINE:X86 /subsystem:console
/out:"D
:\Programs\BOOSTS\BoostPython\bin.v2\libs\python\build\msvc-10.0\debug\threading
-multi\boost_python-vc100-mt-gd-1_46_1.dll"
/IMPLIB:"D:\Programs\BOOSTS\BoostPyt
hon\bin.v2\libs\python\build\msvc-10.0\debug\threading-multi\boost_python-vc100-
mt-gd-1_46_1.lib" /LIBPATH:"D:\Applications\Python\libs"
@"D:\Programs\BOOSTS\
BoostPython\bin.v2\libs\python\build\msvc-10.0\debug\threading-multi\boost_pytho
n-vc100-mt-gd-1_46_1.dll.rsp"
        if %ERRORLEVEL% NEQ 0 EXIT %ERRORLEVEL%

...failed msvc.link.dll
D:\Programs\BOOSTS\BoostPython\bin.v2\libs\python\build\
msvc-10.0\debug\threading-multi\boost_python-vc100-mt-gd-1_46_1.dll
D:\Programs\
BOOSTS\BoostPython\bin.v2\libs\python\build\msvc-10.0\debug\threading-multi\boos
t_python-vc100-mt-gd-1_46_1.lib
D:\Programs\BOOSTS\BoostPython\bin.v2\libs\pytho
n\build\msvc-10.0\debug\threading-multi\boost_python-vc100-mt-gd-1_46_1.pdb...
...removing
D:\Programs\BOOSTS\BoostPython\bin.v2\libs\python\build\msvc-10.0\de
bug\threading-multi\boost_python-vc100-mt-gd-1_46_1.lib
...removing
D:\Programs\BOOSTS\BoostPython\bin.v2\libs\python\build\msvc-10.0\de
bug\threading-multi\boost_python-vc100-mt-gd-1_46_1.pdb
...skipped <pbin\msvc-10.0\debug\threading-multi>extending.pyd for lack of
<pD:\
Programs\BOOSTS\BoostPython\bin.v2\libs\python\build\msvc-10.0\debug\threading-m
ulti>boost_python-vc100-mt-gd-1_46_1.lib...
...skipped <pbin\msvc-10.0\debug\threading-multi>extending.lib for lack of
<pD:\
Programs\BOOSTS\BoostPython\bin.v2\libs\python\build\msvc-10.0\debug\threading-m
ulti>boost_python-vc100-mt-gd-1_46_1.lib...
...skipped <pbin\msvc-10.0\debug\threading-multi>extending.pdb for lack of
<pD:\
Programs\BOOSTS\BoostPython\bin.v2\libs\python\build\msvc-10.0\debug\threading-m
ulti>boost_python-vc100-mt-gd-1_46_1.lib...
...skipped <pbin\test_ext.test\msvc-10.0\debug\threading-multi>test_ext for
lack
 of <pbin\test_ext.test\msvc-10.0\debug\threading-multi>test_extending.py...
common.mkdir bin\test_embed.test
common.mkdir bin\test_embed.test\msvc-10.0
common.mkdir bin\test_embed.test\msvc-10.0\debug
common.mkdir bin\test_embed.test\msvc-10.0\debug\threading-multi
...skipped
<pbin\test_embed.test\msvc-10.0\debug\threading-multi>test_embed.exe
for lack of
<pD:\Programs\BOOSTS\BoostPython\bin.v2\libs\python\build\msvc-10.0\
debug\threading-multi>boost_python-vc100-mt-gd-1_46_1.lib...
...skipped
<pbin\test_embed.test\msvc-10.0\debug\threading-multi>test_embed.pdb
for lack of
<pD:\Programs\BOOSTS\BoostPython\bin.v2\libs\python\build\msvc-10.0\
debug\threading-multi>boost_python-vc100-mt-gd-1_46_1.lib...
...skipped
<pbin\test_embed.test\msvc-10.0\debug\threading-multi>test_embed.run
for lack of
<pbin\test_embed.test\msvc-10.0\debug\threading-multi>test_embed.exe
...
...failed updating 4 targets...
...skipped 9 targets...
...updated 8 targets...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20110625/b4bd32da/attachment-0001.html>

From super24bitsound at hotmail.com  Sat Jun 25 20:40:35 2011
From: super24bitsound at hotmail.com (Jay Riley)
Date: Sat, 25 Jun 2011 14:40:35 -0400
Subject: [C++-sig] Using boost::tuple from python
Message-ID: <BAY158-w58A33112F6A957BAD8E27EB4550@phx.gbl>


I've been trying to figure out how to expose a property in my class that is a boost::tuple. The tuple is defined as follows:

    typedef boost::shared_ptr<Action> action_ptr;
    typedef boost::tuple<BattleCharacter*, action_ptr > ActionTargetTuple;

It's contained with a class defined as follows:

    class Action : public Cloneable<Action>
    {
         public:
              //Irrelevant Code Omitted
              std::vector<ActionTargetTuple> Targets;
    }

I've seen numerous articles while I was searching about how to convert a boost::tuple into a python tuple, but that's not what I'm looking to do. I want to be able to access the tuple as it exists on the Action class. (I know how to do the vector part). The action class is exposed as follows:

    class_<Action>("Action")
            .def("Targets", &Action::Targets)
        ;

 I figured I might be able to expose the tuple by some variation on the below:

     class_<ActionTargetTuple>("ActionTargetTuple")
            .def("get", &ActionTargetTuple::get<int>, return_value_policy<reference_existing_object>())
            ;

then use get from python, but if it is doable in this way, I'm not sure what the set up needs to be. Does anyone know how to do this/could suggest an alternative?

Thanks 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20110625/796e28b7/attachment.html>

From talljimbo at gmail.com  Sat Jun 25 22:06:34 2011
From: talljimbo at gmail.com (Jim Bosch)
Date: Sat, 25 Jun 2011 13:06:34 -0700
Subject: [C++-sig] Using boost::tuple from python
In-Reply-To: <BAY158-w58A33112F6A957BAD8E27EB4550@phx.gbl>
References: <BAY158-w58A33112F6A957BAD8E27EB4550@phx.gbl>
Message-ID: <4E063FCA.8080803@gmail.com>

On 06/25/2011 11:40 AM, Jay Riley wrote:
> I figured I might be able to expose the tuple by some variation on the
> below:
>
> class_<ActionTargetTuple>("ActionTargetTuple")
> .def("get", &ActionTargetTuple::get<int>,
> return_value_policy<reference_existing_object>())
> ;
>
> then use get from python, but if it is doable in this way, I'm not sure
> what the set up needs to be. Does anyone know how to do this/could
> suggest an alternative?

tuple::get is templated on the number you want - it doesn't take that as 
an argument.  I don't think there's a way to do this without writing 
your own "get" with a switch statement or a lot of template 
metaprogramming (I don't think get<int> will compile):

object get(ActionTargetTuple & self, int n) {
     switch (n) {
     case 0:
         return object(self.get<0>());
     case 1:
         return object(self.get<1>());
     default:
         PyErr_SetString(PyExc_IndexError, "Index out of range");
         throw_error_already_set();
     }
}

class<ActionTargetTuple>("ActionTargetTuple")
     .def("get", &get);


I think that's roughly what you need.


Jim

From lists at informa.tiker.net  Sun Jun 26 18:37:36 2011
From: lists at informa.tiker.net (Andreas Kloeckner)
Date: Sun, 26 Jun 2011 12:37:36 -0400
Subject: [C++-sig] Wrapper for bytes type?
Message-ID: <87iprsy2en.fsf@grizzly.selfip.net>

Hi there,

Since boost.python provides a wrapper for str, it should likely also
provide bytes if it's on Python version 3 and newer.

Andreas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20110626/98b47348/attachment.pgp>

From austin.bingham at gmail.com  Sun Jun 26 19:10:40 2011
From: austin.bingham at gmail.com (Austin Bingham)
Date: Sun, 26 Jun 2011 19:10:40 +0200
Subject: [C++-sig] Wrapper for bytes type?
In-Reply-To: <87iprsy2en.fsf@grizzly.selfip.net>
References: <87iprsy2en.fsf@grizzly.selfip.net>
Message-ID: <BANLkTi=GNridu1g1j3pwM3kaCv3SUk_71A@mail.gmail.com>

boost.python should definitely have things like that. Until then, you
might check out ackward:

  http://code.google.com/p/ackward/

The ackward::core library has wrappers for bytes and bytearray (among
other things.)

Austin

On Sun, Jun 26, 2011 at 6:37 PM, Andreas Kloeckner
<lists at informa.tiker.net> wrote:
> Hi there,
>
> Since boost.python provides a wrapper for str, it should likely also
> provide bytes if it's on Python version 3 and newer.
>
> Andreas
>
>
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
>

From stefan at seefeld.name  Sun Jun 26 19:50:00 2011
From: stefan at seefeld.name (Stefan Seefeld)
Date: Sun, 26 Jun 2011 13:50:00 -0400
Subject: [C++-sig] Wrapper for bytes type?
In-Reply-To: <87iprsy2en.fsf@grizzly.selfip.net>
References: <87iprsy2en.fsf@grizzly.selfip.net>
Message-ID: <4E077148.7070808@seefeld.name>

Hi Andreas,

On 2011-06-26 12:37, Andreas Kloeckner wrote:
> Hi there,
>
> Since boost.python provides a wrapper for str, it should likely also
> provide bytes if it's on Python version 3 and newer.

Definitely, good idea. Can you please file an enhancement request on 
https://svn.boost.org/trac/boost/ for this ?

Thanks,
         Stefan

-- 

       ...ich hab' noch einen Koffer in Berlin...


From avibahra at googlemail.com  Thu Jun 30 12:24:15 2011
From: avibahra at googlemail.com (Avi Bahra)
Date: Thu, 30 Jun 2011 11:24:15 +0100
Subject: [C++-sig] boost python extensions & <dll-path> on HPUX/AIX ?
Message-ID: <BANLkTimyB902p6Q-AsU9boOkfiUknpd-iw@mail.gmail.com>

I have built boost python  extension. I have used the <dll-path>
to embed the path to boost python shared library.
This avoids users of my extension from having to set
LD_LIBRARY_PATH when using my extension

python-extension ecflow : [ glob src/*.cpp ]
    ....
    :   <dll-path>$(PYTHON_INSTALL_DIR)
    ;

In my Jamroot.jam:

install install-py
        : Pyext//ecflow
        : <install-dependencies>on
          <install-type>PYTHON_EXTENSION
          <install-type>SHARED_LIB
          <dll-path>$(PYTHON_INSTALL_DIR)
          <location>$(PYTHON_INSTALL_DIR)
        ;


This all works like a charm on Linux:

However on HPUX, I find that embedded path, is always the development path
and not $(PYTHON_INSTALL_DIR)
On AIX it seems to be ignored.

Does any one know if <dll-path> feature is known to work on HPUX/AIX ?

   Best regards,
Ta,
    Avi