From Holger.Joukl at LBBW.de  Fri Apr  1 18:01:15 2011
From: Holger.Joukl at LBBW.de (Holger Joukl)
Date: Fri, 1 Apr 2011 18:01:15 +0200
Subject: [C++-sig] BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS with default args
 dumps core
Message-ID: <OFB2E21249.36D8F4B1-ONC1257865.00561E44-C1257865.005801A9@LBBW.de>


Hi all,

I'm having trouble wrapping a very simple member function with Boost.Python
using the
BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS macro, getting a segmentation fault.

I run into the problem both with Boost 1.44.0 and 1.46.1, running on
Solaris 10/Sparc
using gcc 4.5.1 and Python 2.7.1.

What's a bit strange is that I can run the offending Python code snippet
successfully
iff there is a Boost.Python induced exception raised before this code gets
invoked,
i.e. there are reproducable situations where the same code does not suffer
the segfault;
see "##### test runs" below.


##### wrapped class
$ cat default_arguments_class.hpp

class DefaultArgs {
 public: // member functions
    int foo(int arg1=100, int arg2=10) { return arg1 - arg2; };
};


##### wrapper code
$ cat default_arguments_wrap.cpp

// file default_arguments_wrap.cpp

#include <boost/python.hpp>
#include "default_arguments_class.hpp"

namespace bp = boost::python;


BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS(DefaultArgs_foo_overloads,
DefaultArgs::foo, 0, 2)

BOOST_PYTHON_MODULE(defaultargs)
{
    bp::class_<DefaultArgs>("DefaultArgs", "DefaultArgs class docstring")
        .def("foo", &DefaultArgs::foo, (bp::arg("arg1")=100,
bp::arg("arg2")=10))
        .def("foo_macro", &DefaultArgs::foo, DefaultArgs_foo_overloads())
        .def("foo_macro_a1_a2_with_defaults", &DefaultArgs::foo,
DefaultArgs_foo_overloads((bp::arg("arg1")=100, bp::arg("arg2")=10)))
        .def("foo_macro_a2", &DefaultArgs::foo,
DefaultArgs_foo_overloads((bp::arg("arg2"))))
    ;
};


##### the Jamroot file
$ cat Jamroot

# get the environment variable "USER"
import os ;
local _USER = [ os.environ USER ] ;
#ECHO $(_USER) ;

local _BOOST_ROOT = /var/tmp/$(_USER)/boost_apps/boost ;
local _BOOST_VERSION = boost_1_46_1 ;
#local _BOOST_VERSION = boost_1_44_0 ;
#ECHO $(_BOOST_ROOT) ;


use-project boost : $(_BOOST_ROOT)/$(_BOOST_VERSION) ;


# Set up the project-wide requirements that everything uses the
# boost_python library from the project whose global ID is
# /boost/python.


project minimal
        : requirements <library>/boost/python//boost_python

<dll-path><variant>debug:$(_BOOST_ROOT)/build/$(_BOOST_VERSION)/py2.7/stage/debug/lib

<dll-path><variant>release:$(_BOOST_ROOT)/build/$(_BOOST_VERSION)/py2.7/stage/release/lib
        ;

python-extension defaultargs
        : # sources + // Add all files here otherwise we get undefined
symbol errors like
        default_arguments_wrap.cpp

        : # requirements *
        : # default-build *
        : # usage-requirements *
        ;


##### simple test script
$ cat test_defaultargs2.py

#!/apps/local/gcc/4.5.1/bin/python2.7

import os
import sys
import argparse

_USER=os.getenv("USER")
parser = argparse.ArgumentParser()
parser.add_argument(
    '--path', type=str,
    help='lib installation base path (default: %(default)s)',
    default='/var/tmp/%s/boost_apps/boost/build/boost_1_44_0/py2.7/'
    'minimal/gcc-4.5.1' % (_USER),)
parser.add_argument(
    '--variant', type=str, default='debug',
    help='lib installation path variant (default: %(default)s)')
parser.add_argument(
    '--with-exception', action='store_true',
    help='prepend a test with successful Boost exception')
args = parser.parse_args()


EXPATH = os.path.join(args.path, args.variant)

sys.path.insert(1, EXPATH)

try:
    import defaultargs
except:
    print "sys.path set correctly?", sys.path
    raise


d = defaultargs.DefaultArgs()

if args.with_exception:
    try:
        print "d.foo_macro_a2(1, 2, 3):", d.foo_macro_a2(1, 2, 3)
    except Exception, e:
        print e

print "d.foo_macro_a2(arg2=60):", d.foo_macro_a2(arg2=60)

##### Test run

$ ./test_defaultargs2.py
--path=/var/tmp/lb54320/boost_apps/boost/build/boost_1_44_0/py2.7/minimal/gcc-4.5.1
 --with-exception
d.foo_macro_a2(1, 2, 3): Python argument types in
    DefaultArgs.foo_macro_a2(DefaultArgs, int, int, int)
did not match C++ signature:
    foo_macro_a2(DefaultArgs {lvalue})
    foo_macro_a2(DefaultArgs {lvalue}, int)
    foo_macro_a2(DefaultArgs {lvalue}, int, int arg2)
d.foo_macro_a2(arg2=60):
Traceback (most recent call last):
  File "./test_defaultargs2.py", line 42, in <module>
    print "d.foo_macro_a2(arg2=60):", d.foo_macro_a2(arg2=60)
Boost.Python.ArgumentError: Python argument types in
    DefaultArgs.foo_macro_a2(DefaultArgs)
did not match C++ signature:
    foo_macro_a2(DefaultArgs {lvalue})
    foo_macro_a2(DefaultArgs {lvalue}, int)
    foo_macro_a2(DefaultArgs {lvalue}, int, int arg2)

1 $ ./test_defaultargs2.py
--path=/var/tmp/lb54320/boost_apps/boost/build/boost_1_44_0/py2.7/minimal/gcc-4.5.1

Segmentation Fault (core dumped)

139  $ /apps/local/gcc/4.5.1/bin/gdb /apps/local/gcc/4.5.1/bin/python2.7 -c
core
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.10".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /apps/local/gcc/4.5.1/bin/python2.7...done.

warning: core file may not match specified executable file.
[New LWP 1]
Reading symbols from /lib/libsocket.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib/libsocket.so.1
Reading symbols from /lib/libnsl.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libdl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.1
Reading symbols from /lib/libm.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.2
Reading symbols from /lib/libc.so.1...(no debugging symbols found)...done.
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
Loaded symbols for /lib/libc.so.1
Reading symbols from /lib/libaio.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib/libaio.so.1
Reading symbols from /lib/libmd.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libmd.so.1
Reading symbols from /platform/SUNW,Sun-Fire-V490/lib/libc_psr.so.1...(no
debugging symbols found)...done.
Loaded symbols for /platform/SUNW,Sun-Fire-V490/lib/libc_psr.so.1
Reading symbols from
/usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.3...(no debugging
symbols found)...done.
Loaded symbols for /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.3
Reading symbols from /apps/local/gcc/4.5.1
/lib/python2.7/lib-dynload/strop.so...done.
Loaded symbols for /apps/local/gcc/4.5.1/lib/python2.7/lib-dynload/strop.so
Reading symbols from /apps/prod/gcc/4.5.1/lib/libgcc_s.so.1...done.
Loaded symbols for /apps/prod/gcc/4.5.1/lib/libgcc_s.so.1
Reading symbols from /apps/local/gcc/4.5.1
/lib/python2.7/lib-dynload/operator.so...done.
Loaded symbols for /apps/local/gcc/4.5.1
/lib/python2.7/lib-dynload/operator.so
Reading symbols from /apps/local/gcc/4.5.1
/lib/python2.7/lib-dynload/_functools.so...done.
Loaded symbols for /apps/local/gcc/4.5.1
/lib/python2.7/lib-dynload/_functools.so
Reading symbols from /apps/local/gcc/4.5.1
/lib/python2.7/lib-dynload/_locale.so...done.
Loaded symbols for /apps/local/gcc/4.5.1
/lib/python2.7/lib-dynload/_locale.so
Reading symbols from /apps/prod/gcc/4.5.1/lib/libintl.so.8...done.
Loaded symbols for /apps/prod/gcc/4.5.1/lib/libintl.so.8
Reading symbols from /apps/prod/gcc/4.5.1/lib/libiconv.so.2...done.
Loaded symbols for /apps/prod/gcc/4.5.1/lib/libiconv.so.2
Reading symbols from /lib/libsec.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib/libsec.so.1
Reading symbols from /lib/libavl.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib/libavl.so.1
Reading symbols from /apps/local/gcc/4.5.1
/lib/python2.7/lib-dynload/_struct.so...done.
Loaded symbols for /apps/local/gcc/4.5.1
/lib/python2.7/lib-dynload/_struct.so
Reading symbols from
/var/tmp/lb54320/boost_apps/boost/build/boost_1_44_0/py2.7/minimal/gcc-4.5.1
/debug/defaultargs.so...done.
Loaded symbols for
/var/tmp/lb54320/boost_apps/boost/build/boost_1_44_0/py2.7/minimal/gcc-4.5.1
/debug/defaultargs.so
Reading symbols from
/var/tmp/lb54320/boost_apps/boost/build/boost_1_44_0/py2.7/stage/debug/lib/libboost_python.so.1.44.0...done.

Loaded symbols for
/var/tmp/lb54320/boost_apps/boost/build/boost_1_44_0/py2.7/stage/debug/lib/libboost_python.so.1.44.0

Reading symbols from /apps/local/gcc/4.5.1/lib//libstdc++.so.6...done.
Loaded symbols for /apps/local/gcc/4.5.1/lib//libstdc++.so.6
Reading symbols from /apps/local/gcc/4.5.1/lib//libgcc_s.so.1...done.
Loaded symbols for /apps/local/gcc/4.5.1/lib//libgcc_s.so.1
Reading symbols from /platform/SUNW,Sun-Fire-V490/lib/libmd_psr.so.1...(no
debugging symbols found)...done.
Loaded symbols for /platform/SUNW,Sun-Fire-V490/lib/libmd_psr.so.1
Reading symbols from /lib/ld.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/ld.so.1
Core was generated by `/apps/local/gcc/4.5.1/bin/python2.7
./test_defaultargs2.py --path=/var/tmp/lb54'.
Program terminated with signal 11, Segmentation fault.
#0  0xfed05ee0 in boost::python::objects::find_instance_impl
(inst=0x33e3a0,
    type=..., null_shared_ptr_only=false) at
libs/python/src/object/class.cpp:485
485           if (Py_TYPE(Py_TYPE(inst)) != &class_metatype_object)
(gdb) where
#0  0xfed05ee0 in boost::python::objects::find_instance_impl
(inst=0x33e3a0,
    type=..., null_shared_ptr_only=false) at
libs/python/src/object/class.cpp:485
#1  0xfecf9fd8 in boost::python::converter::rvalue_from_python_stage1 (
    source=0x33e3a0, converters=...) at
libs/python/src/converter/from_python.cpp:46
#2  0xfedc0dc0 in
boost::python::converter::arg_rvalue_from_python<int>::arg_rvalue_from_python
 (this=0xffbfed80, obj=0x33e3a0)
    at
/var/tmp/lb54320/boost_apps/boost/boost_1_44_0/boost/python/converter/arg_from_python.hpp:299
#3  0xfedc02fc in boost::python::arg_from_python<int>::arg_from_python (
    this=0xffbfed80, source=0x33e3a0)
    at
/var/tmp/lb54320/boost_apps/boost/boost_1_44_0/boost/python/arg_from_python.hpp:70
#4  0xfedbf288 in impl<int (*)(DefaultArgs&, int),
boost::python::default_call_policies, boost::mpl::vector3<int,
DefaultArgs&, int> >::operator() (this=0x1efdfc,
    args_=0x33e370)
    at
/var/tmp/lb54320/boost_apps/boost/boost_1_44_0/boost/preprocessor/iteration/detail/local.hpp:37
#5  0xfedbe9cc in
boost::python::objects::caller_py_function_impl<boost::python::detail::caller<int
 (*)(DefaultArgs&, int), boost::python::default_call_policies,
boost::mpl::vector3<int, DefaultArgs&, int> > >::operator() (this=0x1efdf8,
args=0x33e370,
    kw=0x341270)
    at
/var/tmp/lb54320/boost_apps/boost/boost_1_44_0/boost/python/object/py_function.hpp:38
#6  0xfed0ca48 in boost::python::objects::py_function::operator()
(this=0x2053b0,
    args=0x33e370, kw=0x341270) at
./boost/python/object/py_function.hpp:143
#7  0xfed0996c in boost::python::objects::function::call (this=0x2640c0,
    args=0x33e370, keywords=0x341270) at
libs/python/src/object/function.cpp:226
#8  0xfed0b748 in boost::python::objects::(anonymous
namespace)::bind_return::operator() (this=0xffbff198) at
libs/python/src/object/function.cpp:585
#9  0xfed0c564 in
boost::detail::function::void_function_ref_invoker0<boost::python::objects::<unnamed>::bind_return,
 void>::invoke(boost::detail::function::function_buffer &)
(function_obj_ptr=...) at ./boost/function/function_template.hpp:188
#10 0xfed294e4 in boost::function0<void>::operator() (this=0xffbff124)
    at ./boost/function/function_template.hpp:1013
#11 0xfed288d0 in boost::python::handle_exception_impl (f=...)
    at libs/python/src/errors.cpp:25
#12 0xfed0c070 in
boost::python::handle_exception<boost::python::objects::<unnamed>::bind_return>(boost::python::objects::(anonymous
 namespace)::bind_return) (f=Cannot access memory at address 0x0
)
    at ./boost/python/errors.hpp:29
#13 0xfed0b850 in boost::python::objects::function_call (func=0x2640c0,
    args=0x33e370, kw=0x341270) at libs/python/src/object/function.cpp:626
#14 0x0002aa14 in PyObject_Call (func=0x2640c0, arg=0x33e370, kw=0x341270)
    at Objects/abstract.c:2529
#15 0x000b26a0 in do_call (f=0x2da2f8, throwflag=<value optimized out>)
    at Python/ceval.c:4230
#16 call_function (f=0x2da2f8, throwflag=<value optimized out>) at
Python/ceval.c:4035
---Type <return> to continue, or q <return> to quit---


Any hints appreciated. Should I report this as a Boost.Python bug?

Best regards,
Holger

Landesbank Baden-Wuerttemberg
Anstalt des oeffentlichen Rechts
Hauptsitze: Stuttgart, Karlsruhe, Mannheim, Mainz
HRA 12704
Amtsgericht Stuttgart


From Holger.Joukl at LBBW.de  Fri Apr  1 18:09:20 2011
From: Holger.Joukl at LBBW.de (Holger Joukl)
Date: Fri, 1 Apr 2011 18:09:20 +0200
Subject: [C++-sig] BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS with default args
 dumps core
Message-ID: <OF837E8AA3.0CDF5ED6-ONC1257865.00584888-C1257865.0058BA05@LBBW.de>


[ 2nd try due to user stupidity, please ignore if this is being delivered
twice ]

Hi all,

I'm having trouble wrapping a very simple member function with Boost.Python
using the
BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS macro, getting a segmentation fault.

I run into the problem both with Boost 1.44.0 and 1.46.1, running on
Solaris 10/Sparc
using gcc 4.5.1 and Python 2.7.1.

What's a bit strange is that I can run the offending Python code snippet
successfully
iff there is a Boost.Python induced exception raised before this code gets
invoked,
i.e. there are reproducable situations where the same code does not suffer
the segfault;
see "##### test runs" below.


##### wrapped class
$ cat default_arguments_class.hpp

class DefaultArgs {
 public: // member functions
    int foo(int arg1=100, int arg2=10) { return arg1 - arg2; };
};


##### wrapper code
$ cat default_arguments_wrap.cpp

// file default_arguments_wrap.cpp

#include <boost/python.hpp>
#include "default_arguments_class.hpp"

namespace bp = boost::python;


BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS(DefaultArgs_foo_overloads,
DefaultArgs::foo, 0, 2)

BOOST_PYTHON_MODULE(defaultargs)
{
    bp::class_<DefaultArgs>("DefaultArgs", "DefaultArgs class docstring")
        .def("foo", &DefaultArgs::foo, (bp::arg("arg1")=100,
bp::arg("arg2")=10))
        .def("foo_macro", &DefaultArgs::foo, DefaultArgs_foo_overloads())
        .def("foo_macro_a1_a2_with_defaults", &DefaultArgs::foo,
DefaultArgs_foo_overloads((bp::arg("arg1")=100, bp::arg("arg2")=10)))
        .def("foo_macro_a2", &DefaultArgs::foo,
DefaultArgs_foo_overloads((bp::arg("arg2"))))
    ;
};


##### the Jamroot file
$ cat Jamroot

# get the environment variable "USER"
import os ;
local _USER = [ os.environ USER ] ;
#ECHO $(_USER) ;

local _BOOST_ROOT = /var/tmp/$(_USER)/boost_apps/boost ;
local _BOOST_VERSION = boost_1_46_1 ;
#local _BOOST_VERSION = boost_1_44_0 ;
#ECHO $(_BOOST_ROOT) ;


use-project boost : $(_BOOST_ROOT)/$(_BOOST_VERSION) ;


# Set up the project-wide requirements that everything uses the
# boost_python library from the project whose global ID is
# /boost/python.


project minimal
        : requirements <library>/boost/python//boost_python

<dll-path><variant>debug:$(_BOOST_ROOT)/build/$(_BOOST_VERSION)/py2.7/stage/debug/lib

<dll-path><variant>release:$(_BOOST_ROOT)/build/$(_BOOST_VERSION)/py2.7/stage/release/lib
        ;

python-extension defaultargs
        : # sources + // Add all files here otherwise we get undefined
symbol errors like
        default_arguments_wrap.cpp

        : # requirements *
        : # default-build *
        : # usage-requirements *
        ;


##### simple test script
$ cat test_defaultargs2.py

#!/apps/local/gcc/4.5.1/bin/python2.7

import os
import sys
import argparse

_USER=os.getenv("USER")
parser = argparse.ArgumentParser()
parser.add_argument(
    '--path', type=str,
    help='lib installation base path (default: %(default)s)',
    default='/var/tmp/%s/boost_apps/boost/build/boost_1_44_0/py2.7/'
    'minimal/gcc-4.5.1' % (_USER),)
parser.add_argument(
    '--variant', type=str, default='debug',
    help='lib installation path variant (default: %(default)s)')
parser.add_argument(
    '--with-exception', action='store_true',
    help='prepend a test with successful Boost exception')
args = parser.parse_args()


EXPATH = os.path.join(args.path, args.variant)

sys.path.insert(1, EXPATH)

try:
    import defaultargs
except:
    print "sys.path set correctly?", sys.path
    raise


d = defaultargs.DefaultArgs()

if args.with_exception:
    try:
        print "d.foo_macro_a2(1, 2, 3):", d.foo_macro_a2(1, 2, 3)
    except Exception, e:
        print e

print "d.foo_macro_a2(arg2=60):", d.foo_macro_a2(arg2=60)

##### Test run

$ ./test_defaultargs2.py
--path=/var/tmp/lb54320/boost_apps/boost/build/boost_1_44_0/py2.7/minimal/gcc-4.5.1
 --with-exception
d.foo_macro_a2(1, 2, 3): Python argument types in
    DefaultArgs.foo_macro_a2(DefaultArgs, int, int, int)
did not match C++ signature:
    foo_macro_a2(DefaultArgs {lvalue})
    foo_macro_a2(DefaultArgs {lvalue}, int)
    foo_macro_a2(DefaultArgs {lvalue}, int, int arg2)
d.foo_macro_a2(arg2=60):
Traceback (most recent call last):
  File "./test_defaultargs2.py", line 42, in <module>
    print "d.foo_macro_a2(arg2=60):", d.foo_macro_a2(arg2=60)
Boost.Python.ArgumentError: Python argument types in
    DefaultArgs.foo_macro_a2(DefaultArgs)
did not match C++ signature:
    foo_macro_a2(DefaultArgs {lvalue})
    foo_macro_a2(DefaultArgs {lvalue}, int)
    foo_macro_a2(DefaultArgs {lvalue}, int, int arg2)

1 $ ./test_defaultargs2.py
--path=/var/tmp/lb54320/boost_apps/boost/build/boost_1_44_0/py2.7/minimal/gcc-4.5.1

Segmentation Fault (core dumped)

139  $ /apps/local/gcc/4.5.1/bin/gdb /apps/local/gcc/4.5.1/bin/python2.7 -c
core
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <
http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.10".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /apps/local/gcc/4.5.1/bin/python2.7...done.

warning: core file may not match specified executable file.
[New LWP 1]
Reading symbols from /lib/libsocket.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib/libsocket.so.1
Reading symbols from /lib/libnsl.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libdl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.1
Reading symbols from /lib/libm.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.2
Reading symbols from /lib/libc.so.1...(no debugging symbols found)...done.
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
Loaded symbols for /lib/libc.so.1
Reading symbols from /lib/libaio.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib/libaio.so.1
Reading symbols from /lib/libmd.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libmd.so.1
Reading symbols from /platform/SUNW,Sun-Fire-V490/lib/libc_psr.so.1...(no
debugging symbols found)...done.
Loaded symbols for /platform/SUNW,Sun-Fire-V490/lib/libc_psr.so.1
Reading symbols from
/usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.3...(no debugging
symbols found)...done.
Loaded symbols for /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.3
Reading symbols from /apps/local/gcc/4.5.1
/lib/python2.7/lib-dynload/strop.so...done.
Loaded symbols for /apps/local/gcc/4.5.1/lib/python2.7/lib-dynload/strop.so
Reading symbols from /apps/prod/gcc/4.5.1/lib/libgcc_s.so.1...done.
Loaded symbols for /apps/prod/gcc/4.5.1/lib/libgcc_s.so.1
Reading symbols from /apps/local/gcc/4.5.1
/lib/python2.7/lib-dynload/operator.so...done.
Loaded symbols for /apps/local/gcc/4.5.1
/lib/python2.7/lib-dynload/operator.so
Reading symbols from /apps/local/gcc/4.5.1
/lib/python2.7/lib-dynload/_functools.so...done.
Loaded symbols for /apps/local/gcc/4.5.1
/lib/python2.7/lib-dynload/_functools.so
Reading symbols from /apps/local/gcc/4.5.1
/lib/python2.7/lib-dynload/_locale.so...done.
Loaded symbols for /apps/local/gcc/4.5.1
/lib/python2.7/lib-dynload/_locale.so
Reading symbols from /apps/prod/gcc/4.5.1/lib/libintl.so.8...done.
Loaded symbols for /apps/prod/gcc/4.5.1/lib/libintl.so.8
Reading symbols from /apps/prod/gcc/4.5.1/lib/libiconv.so.2...done.
Loaded symbols for /apps/prod/gcc/4.5.1/lib/libiconv.so.2
Reading symbols from /lib/libsec.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib/libsec.so.1
Reading symbols from /lib/libavl.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib/libavl.so.1
Reading symbols from /apps/local/gcc/4.5.1
/lib/python2.7/lib-dynload/_struct.so...done.
Loaded symbols for /apps/local/gcc/4.5.1
/lib/python2.7/lib-dynload/_struct.so
Reading symbols from
/var/tmp/lb54320/boost_apps/boost/build/boost_1_44_0/py2.7/minimal/gcc-4.5.1
/debug/defaultargs.so...done.
Loaded symbols for
/var/tmp/lb54320/boost_apps/boost/build/boost_1_44_0/py2.7/minimal/gcc-4.5.1
/debug/defaultargs.so
Reading symbols from
/var/tmp/lb54320/boost_apps/boost/build/boost_1_44_0/py2.7/stage/debug/lib/libboost_python.so.1.44.0...done.

Loaded symbols for
/var/tmp/lb54320/boost_apps/boost/build/boost_1_44_0/py2.7/stage/debug/lib/libboost_python.so.1.44.0

Reading symbols from /apps/local/gcc/4.5.1/lib//libstdc++.so.6...done.
Loaded symbols for /apps/local/gcc/4.5.1/lib//libstdc++.so.6
Reading symbols from /apps/local/gcc/4.5.1/lib//libgcc_s.so.1...done.
Loaded symbols for /apps/local/gcc/4.5.1/lib//libgcc_s.so.1
Reading symbols from /platform/SUNW,Sun-Fire-V490/lib/libmd_psr.so.1...(no
debugging symbols found)...done.
Loaded symbols for /platform/SUNW,Sun-Fire-V490/lib/libmd_psr.so.1
Reading symbols from /lib/ld.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/ld.so.1
Core was generated by `/apps/local/gcc/4.5.1/bin/python2.7
./test_defaultargs2.py --path=/var/tmp/lb54'.
Program terminated with signal 11, Segmentation fault.
#0  0xfed05ee0 in boost::python::objects::find_instance_impl
(inst=0x33e3a0,
    type=..., null_shared_ptr_only=false) at
libs/python/src/object/class.cpp:485
485           if (Py_TYPE(Py_TYPE(inst)) != &class_metatype_object)
(gdb) where
#0  0xfed05ee0 in boost::python::objects::find_instance_impl
(inst=0x33e3a0,
    type=..., null_shared_ptr_only=false) at
libs/python/src/object/class.cpp:485
#1  0xfecf9fd8 in boost::python::converter::rvalue_from_python_stage1 (
    source=0x33e3a0, converters=...) at
libs/python/src/converter/from_python.cpp:46
#2  0xfedc0dc0 in
boost::python::converter::arg_rvalue_from_python<int>::arg_rvalue_from_python
 (this=0xffbfed80, obj=0x33e3a0)
    at
/var/tmp/lb54320/boost_apps/boost/boost_1_44_0/boost/python/converter/arg_from_python.hpp:299
#3  0xfedc02fc in boost::python::arg_from_python<int>::arg_from_python (
    this=0xffbfed80, source=0x33e3a0)
    at
/var/tmp/lb54320/boost_apps/boost/boost_1_44_0/boost/python/arg_from_python.hpp:70
#4  0xfedbf288 in impl<int (*)(DefaultArgs&, int),
boost::python::default_call_policies, boost::mpl::vector3<int,
DefaultArgs&, int> >::operator() (this=0x1efdfc,
    args_=0x33e370)
    at
/var/tmp/lb54320/boost_apps/boost/boost_1_44_0/boost/preprocessor/iteration/detail/local.hpp:37
#5  0xfedbe9cc in
boost::python::objects::caller_py_function_impl<boost::python::detail::caller<int
 (*)(DefaultArgs&, int), boost::python::default_call_policies,
boost::mpl::vector3<int, DefaultArgs&, int> > >::operator() (this=0x1efdf8,
args=0x33e370,
    kw=0x341270)
    at
/var/tmp/lb54320/boost_apps/boost/boost_1_44_0/boost/python/object/py_function.hpp:38
#6  0xfed0ca48 in boost::python::objects::py_function::operator()
(this=0x2053b0,
    args=0x33e370, kw=0x341270) at
./boost/python/object/py_function.hpp:143
#7  0xfed0996c in boost::python::objects::function::call (this=0x2640c0,
    args=0x33e370, keywords=0x341270) at
libs/python/src/object/function.cpp:226
#8  0xfed0b748 in boost::python::objects::(anonymous
namespace)::bind_return::operator() (this=0xffbff198) at
libs/python/src/object/function.cpp:585
#9  0xfed0c564 in
boost::detail::function::void_function_ref_invoker0<boost::python::objects::<unnamed>::bind_return,
 void>::invoke(boost::detail::function::function_buffer &)
(function_obj_ptr=...) at ./boost/function/function_template.hpp:188
#10 0xfed294e4 in boost::function0<void>::operator() (this=0xffbff124)
    at ./boost/function/function_template.hpp:1013
#11 0xfed288d0 in boost::python::handle_exception_impl (f=...)
    at libs/python/src/errors.cpp:25
#12 0xfed0c070 in
boost::python::handle_exception<boost::python::objects::<unnamed>::bind_return>(boost::python::objects::(anonymous
 namespace)::bind_return) (f=Cannot access memory at address 0x0
)
    at ./boost/python/errors.hpp:29
#13 0xfed0b850 in boost::python::objects::function_call (func=0x2640c0,
    args=0x33e370, kw=0x341270) at libs/python/src/object/function.cpp:626
#14 0x0002aa14 in PyObject_Call (func=0x2640c0, arg=0x33e370, kw=0x341270)
    at Objects/abstract.c:2529
#15 0x000b26a0 in do_call (f=0x2da2f8, throwflag=<value optimized out>)
    at Python/ceval.c:4230
#16 call_function (f=0x2da2f8, throwflag=<value optimized out>) at
Python/ceval.c:4035
---Type <return> to continue, or q <return> to quit---


Any hints appreciated. Should I report this as a Boost.Python bug?

Best regards,
Holger

Landesbank Baden-Wuerttemberg
Anstalt des oeffentlichen Rechts
Hauptsitze: Stuttgart, Karlsruhe, Mannheim, Mainz
HRA 12704
Amtsgericht Stuttgart


From murrayc at murrayc.com  Thu Apr  7 16:02:47 2011
From: murrayc at murrayc.com (Murray Cumming)
Date: Thu, 07 Apr 2011 16:02:47 +0200
Subject: [C++-sig] Avoiding implicit boost::python::extract<> conversions
Message-ID: <1302184967.2458.22.camel@murrayc-desktop>

It looks like boost::python::extract<bool>::check() will happily succeed
on an int python object, and boost::python::extract<int>::check() will
likewise succeed on a bool python object.

Is there an easy way to discover the actual python type so I can really
get the data I want in the correct type?

-- 
murrayc at murrayc.com
www.murrayc.com
www.openismus.com


From hans_meine at gmx.net  Thu Apr  7 16:11:51 2011
From: hans_meine at gmx.net (Hans Meine)
Date: Thu, 7 Apr 2011 16:11:51 +0200
Subject: [C++-sig] Avoiding implicit boost::python::extract<> conversions
In-Reply-To: <1302184967.2458.22.camel@murrayc-desktop>
References: <1302184967.2458.22.camel@murrayc-desktop>
Message-ID: <201104071611.51319.hans_meine@gmx.net>

Am Donnerstag, 7. April 2011, um 16:02:47 schrieb Murray Cumming:
> It looks like boost::python::extract<bool>::check() will happily succeed
> on an int python object, and boost::python::extract<int>::check() will
> likewise succeed on a bool python object.
> 
> Is there an easy way to discover the actual python type so I can really
> get the data I want in the correct type?

Sure, you can use the Python/C API (PyBool_Check etc.)

HTH
  Hans

From rwgk at yahoo.com  Thu Apr  7 19:12:38 2011
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 7 Apr 2011 10:12:38 -0700 (PDT)
Subject: [C++-sig] Avoiding implicit boost::python::extract<> conversions
Message-ID: <131972.96626.qm@web111414.mail.gq1.yahoo.com>

If you add the undocumented (sorry) define

-DBOOST_PYTHON_BOOL_INT_STRICT

Boost.Python will not convert bool to int and vice versa.
I have been working with this define for a couple years now
with a good experience.

(The main reason for the define to be undocumented is that
the tests need to be adjusted, which I never found the time for.)




----- Original Message -----
> From:Murray Cumming <murrayc at murrayc.com>
> To:cplusplus-sig at python.org
> Cc:
> Sent:Thursday, April 7, 2011 7:02 AM
> Subject:[C++-sig] Avoiding implicit boost::python::extract<> conversions
> 
> It looks like boost::python::extract<bool>::check() will happily succeed
> on an int python object, and boost::python::extract<int>::check() will
> likewise succeed on a bool python object.
> 
> Is there an easy way to discover the actual python type so I can really
> get the data I want in the correct type?
> 
> -- 
> murrayc at murrayc.com
> www.murrayc.com
> www.openismus.com
> 
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig


From charlessolar at gmail.com  Mon Apr 18 02:56:45 2011
From: charlessolar at gmail.com (Charles Solar)
Date: Sun, 17 Apr 2011 19:56:45 -0500
Subject: [C++-sig] C++ chain method works unexpectedly in Python
Message-ID: <BANLkTikJGsrL_-L+n_u7EoUR72wbRJnVVQ@mail.gmail.com>

I have a python module written in C++, and the C++ code has a few instances
that involve method chaining.  I was experimenting with python support for
these methods and I found something odd.
However it seems this is more a python eccentricity than Boost Python,
consider the following code sample.

class Test():
    def __init__( self ):
            print "Init"
    def __del__( self ):
            print "Del"
    def foo( self ):
            print "Foo"
            return self
    def bar( self ):
            print "Bar"
            return self

And some sample uses:

>> Test().foo().bar()
Init
Foo
Bar
<__main__.Test instance at 0x2aef40e33998>
>>

Note that __del__ was never called, the object still exists somewhere..
There is another odd thing though, if I repeat the same line, the previous
version gets destroyed and replaced by the new version, but only after the
chain methods are done, eg:

>>> Test().foo().bar()
Init
Foo
Bar
Del                      <-- Old one, NOT the current instance
<__main__.Test instance at 0x2b72bc78d998>
>>

However if I do:

def Tester():
    Test().foo().bar()
    # To make sure del is not called by the function returning
    while True:
            pass

>> Tester()
Init
Foo
Bar
Del
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 4, in Tester
KeyboardInterrupt
>>

That time __del__ was called immediately ( as intended ).

Is there something I should be aware of here?  Some sort of difference
between the global instances and ones defined in a function?  Can I do
anything so global instances are cleaned up immediately like they are inside
functions?

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

From stefan at seefeld.name  Mon Apr 18 03:06:35 2011
From: stefan at seefeld.name (Stefan Seefeld)
Date: Sun, 17 Apr 2011 21:06:35 -0400
Subject: [C++-sig] C++ chain method works unexpectedly in Python
In-Reply-To: <BANLkTikJGsrL_-L+n_u7EoUR72wbRJnVVQ@mail.gmail.com>
References: <BANLkTikJGsrL_-L+n_u7EoUR72wbRJnVVQ@mail.gmail.com>
Message-ID: <4DAB8E9B.1000509@seefeld.name>

On 2011-04-17 20:56, Charles Solar wrote:
>
> Is there something I should be aware of here?

Just that Python uses garbage collection and you mustn't rely on your 
objects being destroyed at a particular point in the program flow. :-)

>   Some sort of difference between the global instances and ones 
> defined in a function?  Can I do anything so global instances are 
> cleaned up immediately like they are inside functions?

No idea, sorry.

     Stefan


-- 

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


From charlessolar at gmail.com  Mon Apr 18 03:50:57 2011
From: charlessolar at gmail.com (Charles Solar)
Date: Sun, 17 Apr 2011 20:50:57 -0500
Subject: [C++-sig] C++ chain method works unexpectedly in Python
In-Reply-To: <4DAB8E9B.1000509@seefeld.name>
References: <BANLkTikJGsrL_-L+n_u7EoUR72wbRJnVVQ@mail.gmail.com>
	<4DAB8E9B.1000509@seefeld.name>
Message-ID: <BANLkTi=qKmygp8cLg+w3dmmBagXOMjvsyw@mail.gmail.com>

Well I know python uses ref counting, so I was hoping the support for chain
methods would be near identical to C++'s since python would not have any
reference to hold onto for Test().  It works great when inside a function,
but not so well in the global namespace. :(

On Sun, Apr 17, 2011 at 8:06 PM, Stefan Seefeld <stefan at seefeld.name> wrote:

> On 2011-04-17 20:56, Charles Solar wrote:
>
>>
>> Is there something I should be aware of here?
>>
>
> Just that Python uses garbage collection and you mustn't rely on your
> objects being destroyed at a particular point in the program flow. :-)
>
>
>   Some sort of difference between the global instances and ones defined in
>> a function?  Can I do anything so global instances are cleaned up
>> immediately like they are inside functions?
>>
>
> No idea, sorry.
>
>    Stefan
>
>
> --
>
>      ...ich hab' noch einen Koffer in Berlin...
>
> _______________________________________________
> 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/20110417/dffb61c0/attachment.html>

From songofacandy at gmail.com  Mon Apr 18 04:07:40 2011
From: songofacandy at gmail.com (INADA Naoki)
Date: Mon, 18 Apr 2011 11:07:40 +0900
Subject: [C++-sig] C++ chain method works unexpectedly in Python
In-Reply-To: <BANLkTikJGsrL_-L+n_u7EoUR72wbRJnVVQ@mail.gmail.com>
References: <BANLkTikJGsrL_-L+n_u7EoUR72wbRJnVVQ@mail.gmail.com>
Message-ID: <BANLkTinLhweZAun+K9-pJtpFkbvcKtR11Q@mail.gmail.com>

Python Interactive shell stores result of an expression to a variable
named '__builtin__._'.
So, ``del _`` may help you.

This behavior is only on interactive shell. When running script, '_'
is not used and Python
may acts you expect.


On Mon, Apr 18, 2011 at 9:56 AM, Charles Solar <charlessolar at gmail.com> wrote:
> I have a python module written in C++, and the C++ code has a few instances
> that involve method chaining.? I was experimenting with python support for
> these methods and I found something odd.
> However it seems this is more a python eccentricity than Boost Python,
> consider the following code sample.
>
> class Test():
> ??? def __init__( self ):
> ??????????? print "Init"
> ??? def __del__( self ):
> ??????????? print "Del"
> ??? def foo( self ):
> ??????????? print "Foo"
> ??????????? return self
> ??? def bar( self ):
> ??????????? print "Bar"
> ??????????? return self
>
> And some sample uses:
>
>>> Test().foo().bar()
> Init
> Foo
> Bar
> <__main__.Test instance at 0x2aef40e33998>
>>>
>
> Note that __del__ was never called, the object still exists somewhere..
> There is another odd thing though, if I repeat the same line, the previous
> version gets destroyed and replaced by the new version, but only after the
> chain methods are done, eg:
>
>>>> Test().foo().bar()
> Init
> Foo
> Bar
> Del ? ? ? ? ? ? ? ? ? ?? <-- Old one, NOT the current instance
> <__main__.Test instance at 0x2b72bc78d998>
>>>
>
> However if I do:
>
> def Tester():
> ??? Test().foo().bar()
> ??? # To make sure del is not called by the function returning
> ??? while True:
> ??????????? pass
>
>>> Tester()
> Init
> Foo
> Bar
> Del
> Traceback (most recent call last):
> ? File "<stdin>", line 1, in <module>
> ? File "<stdin>", line 4, in Tester
> KeyboardInterrupt
>>>
>
> That time __del__ was called immediately ( as intended ).
>
> Is there something I should be aware of here?? Some sort of difference
> between the global instances and ones defined in a function?? Can I do
> anything so global instances are cleaned up immediately like they are inside
> functions?
>
> Thanks
>
>
>
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
>



-- 
INADA Naoki? <songofacandy at gmail.com>

From charlessolar at gmail.com  Mon Apr 18 04:18:25 2011
From: charlessolar at gmail.com (Charles Solar)
Date: Sun, 17 Apr 2011 21:18:25 -0500
Subject: [C++-sig] C++ chain method works unexpectedly in Python
In-Reply-To: <BANLkTinLhweZAun+K9-pJtpFkbvcKtR11Q@mail.gmail.com>
References: <BANLkTikJGsrL_-L+n_u7EoUR72wbRJnVVQ@mail.gmail.com>
	<BANLkTinLhweZAun+K9-pJtpFkbvcKtR11Q@mail.gmail.com>
Message-ID: <BANLkTi=o-aH6Hewoe5t4U6tEbtPga0pvZA@mail.gmail.com>

Ahh very cool, exactly what I was looking for.
I did not know about __builtin__._  Figured it was something funny like
that, glad its just a shell thing.
Thank you

On Sun, Apr 17, 2011 at 9:07 PM, INADA Naoki <songofacandy at gmail.com> wrote:

> Python Interactive shell stores result of an expression to a variable
> named '__builtin__._'.
> So, ``del _`` may help you.
>
> This behavior is only on interactive shell. When running script, '_'
> is not used and Python
> may acts you expect.
>
>
> On Mon, Apr 18, 2011 at 9:56 AM, Charles Solar <charlessolar at gmail.com>
> wrote:
> > I have a python module written in C++, and the C++ code has a few
> instances
> > that involve method chaining.  I was experimenting with python support
> for
> > these methods and I found something odd.
> > However it seems this is more a python eccentricity than Boost Python,
> > consider the following code sample.
> >
> > class Test():
> >     def __init__( self ):
> >             print "Init"
> >     def __del__( self ):
> >             print "Del"
> >     def foo( self ):
> >             print "Foo"
> >             return self
> >     def bar( self ):
> >             print "Bar"
> >             return self
> >
> > And some sample uses:
> >
> >>> Test().foo().bar()
> > Init
> > Foo
> > Bar
> > <__main__.Test instance at 0x2aef40e33998>
> >>>
> >
> > Note that __del__ was never called, the object still exists somewhere..
> > There is another odd thing though, if I repeat the same line, the
> previous
> > version gets destroyed and replaced by the new version, but only after
> the
> > chain methods are done, eg:
> >
> >>>> Test().foo().bar()
> > Init
> > Foo
> > Bar
> > Del                      <-- Old one, NOT the current instance
> > <__main__.Test instance at 0x2b72bc78d998>
> >>>
> >
> > However if I do:
> >
> > def Tester():
> >     Test().foo().bar()
> >     # To make sure del is not called by the function returning
> >     while True:
> >             pass
> >
> >>> Tester()
> > Init
> > Foo
> > Bar
> > Del
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in <module>
> >   File "<stdin>", line 4, in Tester
> > KeyboardInterrupt
> >>>
> >
> > That time __del__ was called immediately ( as intended ).
> >
> > Is there something I should be aware of here?  Some sort of difference
> > between the global instances and ones defined in a function?  Can I do
> > anything so global instances are cleaned up immediately like they are
> inside
> > functions?
> >
> > Thanks
> >
> >
> >
> > _______________________________________________
> > Cplusplus-sig mailing list
> > Cplusplus-sig at python.org
> > http://mail.python.org/mailman/listinfo/cplusplus-sig
> >
>
>
>
> --
> INADA Naoki  <songofacandy at gmail.com>
> _______________________________________________
> 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/20110417/d334ed65/attachment-0001.html>

From wichert at wiggy.net  Mon Apr 18 09:35:46 2011
From: wichert at wiggy.net (Wichert Akkerman)
Date: Mon, 18 Apr 2011 09:35:46 +0200
Subject: [C++-sig] C++ chain method works unexpectedly in Python
In-Reply-To: <BANLkTi=qKmygp8cLg+w3dmmBagXOMjvsyw@mail.gmail.com>
References: <BANLkTikJGsrL_-L+n_u7EoUR72wbRJnVVQ@mail.gmail.com>	<4DAB8E9B.1000509@seefeld.name>
	<BANLkTi=qKmygp8cLg+w3dmmBagXOMjvsyw@mail.gmail.com>
Message-ID: <4DABE9D2.4050405@wiggy.net>

On 2011-4-18 03:50, Charles Solar wrote:
> Well I know python uses ref counting, so I was hoping the support for
> chain methods would be near identical to C++'s since python would not
> have any reference to hold onto for Test().

That is true for CPython, but may not be true for other python 
implementations.

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 jean.felder at gmail.com  Thu Apr 21 15:48:51 2011
From: jean.felder at gmail.com (Jean Felder)
Date: Thu, 21 Apr 2011 15:48:51 +0200
Subject: [C++-sig] inspect module and Boost.Python.function
Message-ID: <BANLkTincf9zh3JBqw+QKLwbzYi6R2qQhJg@mail.gmail.com>

Hi all,

I would like to get a list of the arguments of some Boost Python functions
in a python program.
So, I was thinking of using the inspect module and the getargspec function.
However, I get an error: "arg is not a Python function".
I'm using python 2.6 and boost python 1.42.

Is it possible to combine inspect and boost python function ?
Is there a way to get the arguments of a Boost Python function in a python
program ?

Thanks,

Jean Felder
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20110421/4c429aab/attachment.html>

From rwgk at yahoo.com  Thu Apr 21 17:40:00 2011
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Thu, 21 Apr 2011 08:40:00 -0700 (PDT)
Subject: [C++-sig] inspect module and Boost.Python.function
In-Reply-To: <BANLkTincf9zh3JBqw+QKLwbzYi6R2qQhJg@mail.gmail.com>
References: <BANLkTincf9zh3JBqw+QKLwbzYi6R2qQhJg@mail.gmail.com>
Message-ID: <843211.48223.qm@web111415.mail.gq1.yahoo.com>

You can use

help(your_function)

to get information about the arguments.

The signature with default arguments is in the docstring (unless you
turn this feature off).

Boost.Python supports overloads; the inspect module is not aware of
this.

Ralf


To: cplusplus-sig at python.org
>Sent: Thursday, April 21, 2011 6:48 AM
>Subject: Re: [C++-sig] inspect module and Boost.Python.function
>
>
>Hi all,
>
>I would like to get a list of the arguments of some Boost Python functions in a python program.
>So, I was thinking of using the inspect module and the getargspec function.
>However, I get an error: "arg is not a Python function".
>I'm using python 2.6 and boost python 1.42.
>
>Is it possible to combine inspect and boost python function ?
>Is there a way to get the arguments of a Boost Python function in a python program ?
>
>Thanks,
>
>Jean Felder
>
>_______________________________________________
>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/20110421/1ab9dd4d/attachment.html>

From amundson at fnal.gov  Thu Apr 21 18:04:44 2011
From: amundson at fnal.gov (James Amundson)
Date: Thu, 21 Apr 2011 11:04:44 -0500
Subject: [C++-sig] group meeting today
Message-ID: <4DB0559C.8090101@fnal.gov>

Today we will have another technical group meeting. Alex and I will 
discuss approaches to canonical transformations and Lorentz boosts in 
space charge calculations.

--Jim


From jean.felder at gmail.com  Thu Apr 21 20:39:31 2011
From: jean.felder at gmail.com (Jean Felder)
Date: Thu, 21 Apr 2011 20:39:31 +0200
Subject: [C++-sig] inspect module and Boost.Python.function
In-Reply-To: <843211.48223.qm@web111415.mail.gq1.yahoo.com>
References: <BANLkTincf9zh3JBqw+QKLwbzYi6R2qQhJg@mail.gmail.com>
	<843211.48223.qm@web111415.mail.gq1.yahoo.com>
Message-ID: <BANLkTimMNt=moH=MNHs=MUbJM3DcTdLGGA@mail.gmail.com>

Thanks. I will use it.

Jean

2011/4/21 Ralf W. Grosse-Kunstleve <rwgk at yahoo.com>
>
> You can use
>
> help(your_function)
>
> to get information about the arguments.
>
> The signature with default arguments is in the docstring (unless you
> turn this feature off).
>
> Boost.Python supports overloads; the inspect module is not aware of
> this.
>
> Ralf
>
> To: cplusplus-sig at python.org
> Sent: Thursday, April 21, 2011 6:48 AM
> Subject: Re: [C++-sig] inspect module and Boost.Python.function
>
> Hi all,
>
> I would like to get a list of the arguments of some Boost Python functions in a python program.
> So, I was thinking of using the inspect module and the getargspec function.
> However, I get an error: "arg is not a Python function".
> I'm using python 2.6 and boost python 1.42.
>
> Is it possible to combine inspect and boost python function ?
> Is there a way to get the arguments of a Boost Python function in a python program ?
>
> Thanks,
>
> Jean Felder
>
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
>
>
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig

From amundson at fnal.gov  Thu Apr 21 22:21:41 2011
From: amundson at fnal.gov (James Amundson)
Date: Thu, 21 Apr 2011 15:21:41 -0500
Subject: [C++-sig] group meeting today
In-Reply-To: <4DB0559C.8090101@fnal.gov>
References: <4DB0559C.8090101@fnal.gov>
Message-ID: <4DB091D5.6020408@fnal.gov>

I apologize for my clumsy fingers. This message was meant for a 
different mailing list.

On 04/21/2011 11:04 AM, James Amundson wrote:
> Today we will have another technical group meeting. Alex and I will 
> discuss approaches to canonical transformations and Lorentz boosts in 
> space charge calculations.
>
> --Jim
>
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig


From zebbey at gmail.com  Fri Apr 29 09:14:27 2011
From: zebbey at gmail.com (zeb)
Date: Fri, 29 Apr 2011 00:14:27 -0700 (PDT)
Subject: [C++-sig] help on abstract class export
Message-ID: <1304061267759-3483090.post@n4.nabble.com>

Hi, I'm trying to export the following code to python, but failed. Please
help me!
Here is the code:
--------------
c++ code:
--------------
class IWorker {
public:
	virtual int getData() = 0;
};

class Worker : public IWorker {
public:
	int getData() {
		return 100;
	}
};

extern "C" {
	IWorker* createWorker();
}

--------------
py++ code:
--------------
mb.free_fun('createWorker').call_policies =
call_policies.return_value_policy(call_policies.return_pointee_value)

--------------
In python:
--------------
>>> w = createWorker()

I got 'TypeError: No to_python (by-value) converter found for C++ type:
class IWorker

I found that if the IWorker class is not abstract, for example:
class IWorker {
public:
	virtual int getData() { return 0; }
};

Python doesn't report that error, but the result of the following code is
not expected(I think it should be 100).
>>> w = createWorker()
>>> w.getData()
0

How to solve this problem? Please give some advise.
THANK YOU.





--
View this message in context: http://boost.2283326.n4.nabble.com/help-on-abstract-class-export-tp3483090p3483090.html
Sent from the Python - c++-sig mailing list archive at Nabble.com.

From roman.yakovenko at gmail.com  Fri Apr 29 11:07:13 2011
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Fri, 29 Apr 2011 12:07:13 +0300
Subject: [C++-sig] help on abstract class export
In-Reply-To: <1304061267759-3483090.post@n4.nabble.com>
References: <1304061267759-3483090.post@n4.nabble.com>
Message-ID: <BANLkTik4cNtST67v2j3TUxHSp_a1Y0ONpQ@mail.gmail.com>

On Fri, Apr 29, 2011 at 10:14 AM, zeb <zebbey at gmail.com> wrote:
> Hi, I'm trying to export the following code to python, but failed. Please
> help me!
> Here is the code:
> --------------
> c++ code:
> --------------
> class IWorker {
> public:
> ? ? ? ?virtual int getData() = 0;
> };
>
> class Worker : public IWorker {
> public:
> ? ? ? ?int getData() {
> ? ? ? ? ? ? ? ?return 100;
> ? ? ? ?}
> };
>
> extern "C" {
> ? ? ? ?IWorker* createWorker();
> }
>
> --------------
> py++ code:
> --------------
> mb.free_fun('createWorker').call_policies =
> call_policies.return_value_policy(call_policies.return_pointee_value)

If createWorker is implemented as "return new Worker(....);", then you
should use "return_value_policy<manage_new_object>"
( http://www.boost.org/doc/libs/1_46_1/libs/python/doc/tutorial/doc/html/python/functions.html#python.call_policies
)

If you change the function return type to "std::auto_ptr<...>" then
you don't need to specify the call policies.

HTH

From zebbey at gmail.com  Fri Apr 29 11:16:09 2011
From: zebbey at gmail.com (zeb)
Date: Fri, 29 Apr 2011 02:16:09 -0700 (PDT)
Subject: [C++-sig] help on abstract class export
In-Reply-To: <BANLkTik4cNtST67v2j3TUxHSp_a1Y0ONpQ@mail.gmail.com>
References: <1304061267759-3483090.post@n4.nabble.com>
	<BANLkTik4cNtST67v2j3TUxHSp_a1Y0ONpQ@mail.gmail.com>
Message-ID: <1304068569531-3483251.post@n4.nabble.com>

Thank you very much. It works!

--
View this message in context: http://boost.2283326.n4.nabble.com/help-on-abstract-class-export-tp3483090p3483251.html
Sent from the Python - c++-sig mailing list archive at Nabble.com.

From kubol at kormoran.net  Fri Apr 29 12:02:29 2011
From: kubol at kormoran.net (Jakub Zytka)
Date: Fri, 29 Apr 2011 12:02:29 +0200
Subject: [C++-sig] help on abstract class export
In-Reply-To: <1304061267759-3483090.post@n4.nabble.com>
References: <1304061267759-3483090.post@n4.nabble.com>
Message-ID: <4DBA8CB5.4030700@kormoran.net>

On 04/29/11 09:14, zeb wrote:
> mb.free_fun('createWorker').call_policies =
> call_policies.return_value_policy(call_policies.return_pointee_value)
you do not want to have *value* of an abstract class.

> I found that if the IWorker class is not abstract, for example:
> class IWorker {
> public:
> 	virtual int getData() { return 0; }
> };
>
> Python doesn't report that error, but the result of the following code is
> not expected(I think it should be 100).
You expectancy is wrong. If you keep IWorker by value there will be no dynamic 
dispatch.
This is not related to py++, python or boost::python. Its just the same as in 
c++. If you wrote a c++ function that takes IWorker parameter by value you'd get 
the same behavior.

Basic rule of thumb: if you're dealing with inheritance, do not pass object by 
value.