From pbienst at MIT.EDU  Mon Apr  1 18:34:59 2002
From: pbienst at MIT.EDU (Peter Bienstman)
Date: 01 Apr 2002 11:34:59 -0500
Subject: [C++-sig] playing with V2
Message-ID: <1017678900.15480.11.camel@hunsmac.mit.edu>

Hi,

I want to start playing with V2 again, and I have a couple of questions
related to the lack of transparency that Jam files currently have for
me:

* If I want to build a separate project outside of the Jam build system,
is it enough if I include headers from <boost_root>/boost/python and
link with libbpl.so in order to avoid picking up any V1 stuff? Do I have
to define any preprocessor variables?

* What's the easiest way to actually run the included tests? Building
them seems to work fine, running them is hard because the *.so files are
buried deep within the bin directory.

Thanks,

Peter






From david.abrahams at rcn.com  Mon Apr  1 20:01:38 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 1 Apr 2002 13:01:38 -0500
Subject: [C++-sig] playing with V2
References: <1017678900.15480.11.camel@hunsmac.mit.edu>
Message-ID: <06c401c1d9a7$a986bcb0$0202a8c0@boostconsulting.com>

----- Original Message -----
From: "Peter Bienstman" <pbienst at MIT.EDU>
To: <c++-sig at python.org>
Sent: Monday, April 01, 2002 11:34 AM
Subject: [C++-sig] playing with V2


> Hi,
>
> I want to start playing with V2 again, and I have a couple of
questions
> related to the lack of transparency that Jam files currently have for
> me:
>
> * If I want to build a separate project outside of the Jam build
system,
> is it enough if I include headers from <boost_root>/boost/python and
> link with libbpl.so in order to avoid picking up any V1 stuff? Do I
have
> to define any preprocessor variables?

There should be no problem with picking up the v1 stuff; the headers
coexist, so you should put the boost root in your #include path and use

    #include <boost/python/...>

You need <define>BOOST_PYTHON_DYNAMIC_LIB <define>BOOST_PYTHON_V2.
However, the easiest way to get things right is as follows:


project-root ;

# bring in the rules for python
SEARCH on <module@>python.jam = $(BOOST_BUILD_PATH) ;
include <module@>python.jam ;

local PYTHON_PROPERTIES = $(BOOST_PYTHON_V2_PROPERTIES) ;

extension my_module : my_source1.cpp my_source2.cpp my_source3.cpp ...
                      <library-file>path/to/bpl.so
                    ;


> * What's the easiest way to actually run the included tests? Building
> them seems to work fine, running them is hard because the *.so files
are
> buried deep within the bin directory.

go to boost/libs/python/test

    jam test

If you want to see lots of output,

    jam -sPYTHON_TEST_ARGS=-v test

HTH,
Dave

Please let me know if you run into difficulties.




From pbienst at MIT.EDU  Mon Apr  1 21:29:25 2002
From: pbienst at MIT.EDU (Peter Bienstman)
Date: 01 Apr 2002 14:29:25 -0500
Subject: [C++-sig] V2 enum convertors
Message-ID: <1017689366.15479.17.camel@hunsmac.mit.edu>

OK, I've got V2 to work on a small subset of my project, but now I'm
wondering if there is already equivalent V2 functionality for

 template class boost::python::enum_as_int_converters<Limit>;

and then inside the module:

  m.add(boost::python::make_ref(Plus), "Plus");
  m.add(boost::python::make_ref(Min),  "Min");

Thanks,

Peter





From david.abrahams at rcn.com  Mon Apr  1 22:01:07 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 1 Apr 2002 15:01:07 -0500
Subject: [C++-sig] V2 enum convertors
References: <1017689366.15479.17.camel@hunsmac.mit.edu>
Message-ID: <072a01c1d9b7$f7b60bb0$0202a8c0@boostconsulting.com>

----- Original Message -----
From: "Peter Bienstman" <pbienst at MIT.EDU>

> OK, I've got V2 to work on a small subset of my project,

Wonderful!

> but now I'm
> wondering if there is already equivalent V2 functionality for
>
>  template class boost::python::enum_as_int_converters<Limit>;
>
> and then inside the module:
>
>   m.add(boost::python::make_ref(Plus), "Plus");
>   m.add(boost::python::make_ref(Min),  "Min");


I'm afraid the answer at the moment is no.

The code is stabilized to the point where I would consider doing it,
now. If you are interested in trying yourself, you can look at
boost/libs/python/src/converter/builtin_converters.cpp and
boost/boost/python/converter/builtin_converters.hpp.

However, I'm not completely sure what the best interface would be. In
particular, should enums really be exposed as Python Ints? Wouldn't it
be better to expose a Python subclass of Int whose str() and repr()
functions return user-friendly names?

I'd like to consider these things (and would love some feedback) before
implementing enum support.

-Dave





From pbienst at MIT.EDU  Mon Apr  1 22:40:55 2002
From: pbienst at MIT.EDU (Peter Bienstman)
Date: 01 Apr 2002 15:40:55 -0500
Subject: [C++-sig] V2 enum convertors
Message-ID: <1017693656.15479.19.camel@hunsmac.mit.edu>

>However, I'm not completely sure what the best interface would be. In
>particular, should enums really be exposed as Python Ints? Wouldn't it
>be better to expose a Python subclass of Int whose str() and repr()
>functions return user-friendly names?

Well, I think the latter is definitely much better from the end user's
point of view.

However, if I had to implement it myself right here and right now, I'd
settle for the first option at the moment, because of my lack of
familiarity with the code ;-)

Peter







From david.abrahams at rcn.com  Mon Apr  1 22:48:08 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 1 Apr 2002 15:48:08 -0500
Subject: [C++-sig] V2 enum convertors
References: <1017693656.15479.19.camel@hunsmac.mit.edu>
Message-ID: <077c01c1d9be$93a7dcf0$0202a8c0@boostconsulting.com>

So, let's discuss the interface. Seems to me something like class_<>
would be good:

enum MyEnum { one = 1, two, three };

module("m")
    .add(enum_<MyEnum>("MyEnum")
            .value("one", one)
            .value("two", two)
            .value("three", three)
    )

    ...

----- Original Message -----
From: "Peter Bienstman" <pbienst at MIT.EDU>
To: <c++-sig at python.org>
Sent: Monday, April 01, 2002 3:40 PM
Subject: [C++-sig] V2 enum convertors


>
> >However, I'm not completely sure what the best interface would be. In
> >particular, should enums really be exposed as Python Ints? Wouldn't
it
> >be better to expose a Python subclass of Int whose str() and repr()
> >functions return user-friendly names?
>
> Well, I think the latter is definitely much better from the end user's
> point of view.
>
> However, if I had to implement it myself right here and right now, I'd
> settle for the first option at the moment, because of my lack of
> familiarity with the code ;-)
>
> Peter
>
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig




From pbienst at MIT.EDU  Mon Apr  1 22:59:23 2002
From: pbienst at MIT.EDU (Peter Bienstman)
Date: 01 Apr 2002 15:59:23 -0500
Subject: [C++-sig] V2 enum convertors
Message-ID: <1017694764.15479.21.camel@hunsmac.mit.edu>

>So, let's discuss the interface. Seems to me something like class_<>
>would be good:

>enum MyEnum { one = 1, two, three };

>module("m")
>    .add(enum_<MyEnum>("MyEnum")
>            .value("one", one)
>            .value("two", two)
>            .value("three", three)
>    )


No objections here. This is probably as concise and as clear as you can
get.

Peter







From david.abrahams at rcn.com  Mon Apr  1 23:47:29 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 1 Apr 2002 16:47:29 -0500
Subject: [C++-sig] V2 enum convertors
References: <1017694764.15479.21.camel@hunsmac.mit.edu>
Message-ID: <07b301c1d9c6$d407af70$0202a8c0@boostconsulting.com>

OK, are you ready to implement it?

I'm not, quite yet.

I'll help you in any way I can...

-Dave

----- Original Message -----
From: "Peter Bienstman" <pbienst at MIT.EDU>
To: <c++-sig at python.org>
Sent: Monday, April 01, 2002 3:59 PM
Subject: [C++-sig] V2 enum convertors


>
> >So, let's discuss the interface. Seems to me something like class_<>
> >would be good:
>
> >enum MyEnum { one = 1, two, three };
>
> >module("m")
> >    .add(enum_<MyEnum>("MyEnum")
> >            .value("one", one)
> >            .value("two", two)
> >            .value("three", three)
> >    )
>
>
> No objections here. This is probably as concise and as clear as you
can
> get.
>
> Peter
>
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig




From pbienst at MIT.EDU  Mon Apr  1 23:58:48 2002
From: pbienst at MIT.EDU (Peter Bienstman)
Date: 01 Apr 2002 16:58:48 -0500
Subject: [C++-sig] V2 enum convertors
Message-ID: <1017698329.15480.23.camel@hunsmac.mit.edu>

>OK, are you ready to implement it?
>
>I'm not, quite yet.
>
>I'll help you in any way I can...

If I find sufficient free time, I might have a go at it, but I don't
commit to anything...

Peter







From david.abrahams at rcn.com  Tue Apr  2 08:02:10 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 2 Apr 2002 01:02:10 -0500
Subject: [C++-sig] Boost.Python - March 2002 Progress Report
Message-ID: <00c101c1da0b$ee7bf100$0202a8c0@boostconsulting.com>

Last month's progress report is available in the CVS repository at
libs/python/doc/v2/Mar2002.html, and at
http://makeashorterlink.com/?L2F152E9 for easy viewing. I will publish
the February report as soon as I can make a reasonable conversion from
MS-Word to HTML ;-)

Enjoy,
Dave

+---------------------------------------------------------------+
                  David Abrahams
      C++ Booster (http://www.boost.org)               O__  ==
      Pythonista (http://www.python.org)              c/ /'_ ==
  resume: http://users.rcn.com/abrahams/resume.html  (*) \(*) ==
          email: david.abrahams at rcn.com
+---------------------------------------------------------------+





From pbienst at MIT.EDU  Tue Apr  2 21:54:29 2002
From: pbienst at MIT.EDU (Peter Bienstman)
Date: 02 Apr 2002 14:54:29 -0500
Subject: [C++-sig] V2: adding new functions to class
Message-ID: <1017777269.23101.18.camel@hunsmac.mit.edu>

In V2, can I already add functions to a C++ class which were not part of
the original class definition? Something like

class A{};

f();

...
 .add(
  class_<A>("A")
  .def("f", f)
  )
...


These constructs give me compiler errors, like 'cannot convert pointer
to function to PyObject*

Peter 






From epo011 at yahoo.com  Tue Apr  2 21:57:23 2002
From: epo011 at yahoo.com (Epo Dada)
Date: Tue, 2 Apr 2002 11:57:23 -0800 (PST)
Subject: [C++-sig] help with this program
Message-ID: <20020402195723.26654.qmail@web20804.mail.yahoo.com>

Write a function

vector<int> merge_sorted(vector<int> a, vector<int> b)

that merges two sorted arrays, producing a new sorted
array. Keep an index into each array, indicating how
much of it has been processed already. Each time,
append the smallest unprocessed element from either
array, then advance to the next index. For example, if
a is

1   4   9   16

and b is

4   7   9   9   11

then merge_sorted returns the array (vector)

1   4   4   7   9   9   9   11   


__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://http://taxes.yahoo.com/



From david.abrahams at rcn.com  Tue Apr  2 23:12:35 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 2 Apr 2002 16:12:35 -0500
Subject: [C++-sig] V2: adding new functions to class
References: <1017777269.23101.18.camel@hunsmac.mit.edu>
Message-ID: <038701c1da8b$1ec91b10$0202a8c0@boostconsulting.com>

Sorry, that was a bug.
Try with the latest CVS.

-Dave

BTW, f() still needs an initial A cv* or A cv& argument below

----- Original Message -----
From: "Peter Bienstman" <pbienst at MIT.EDU>


> In V2, can I already add functions to a C++ class which were not part
of
> the original class definition? Something like
>
> class A{};
>
> f();
>
> ...
>  .add(
>   class_<A>("A")
>   .def("f", f)
>   )
> ...
>
>
> These constructs give me compiler errors, like 'cannot convert pointer
> to function to PyObject*
>
> Peter





From pbienst at MIT.EDU  Tue Apr  2 23:47:42 2002
From: pbienst at MIT.EDU (Peter Bienstman)
Date: 02 Apr 2002 16:47:42 -0500
Subject: [C++-sig] V2: adding new functions to class
Message-ID: <1017784062.23100.25.camel@hunsmac.mit.edu>

It compiles now, thanks for the quick fix!

Peter

>Sorry, that was a bug.
>Try with the latest CVS.
>
>-Dave







From david.abrahams at rcn.com  Wed Apr  3 00:20:50 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 2 Apr 2002 17:20:50 -0500
Subject: [C++-sig] [ANN] Boost.Python v2: CallPolicies support for constructors
Message-ID: <045001c1da94$b8e49e50$0202a8c0@boostconsulting.com>

class_<...>.def_init(...) now supports an optional CallPolicies argument
which can be used to control the lifetime of constructor arguments. An
example can be found in libs/python/test/test_pointer_adoption.*.

Regards,
Dave

+---------------------------------------------------------------+
                  David Abrahams
      C++ Booster (http://www.boost.org)               O__  ==
      Pythonista (http://www.python.org)              c/ /'_ ==
  resume: http://users.rcn.com/abrahams/resume.html  (*) \(*) ==
          email: david.abrahams at rcn.com
+---------------------------------------------------------------+




From pbienst at MIT.EDU  Wed Apr  3 01:02:50 2002
From: pbienst at MIT.EDU (Peter Bienstman)
Date: 02 Apr 2002 18:02:50 -0500
Subject: [C++-sig] V2: corner case bug?
Message-ID: <1017788573.23101.29.camel@hunsmac.mit.edu>

OK, this odd combination of abstract base classes, referencing existing
objects and adding new functions to a class does not compile.

Wrapping the 'inside' functions goes fine, wrapping the similar
'outside' functions doesn't compile because the compiler wants to
instantiate the abstract class, although it's marked noncopyable. 

#define BOOST_PYTHON_DYNAMIC_LIB
#define BOOST_PYTHON_V2

#include <boost/python/module.hpp>
#include <boost/python/class.hpp>
#include <boost/python/reference_existing_object.hpp>
#include <boost/python/return_value_policy.hpp>

struct A {};

struct V 
{

 virtual void f() = 0;

 const A* inside() {return &a;}

 A a;
};

const A* outside(const V& v) {return &v.a;}

BOOST_PYTHON_MODULE_INIT(m)
{
  using namespace boost::python;
  using boost::shared_ptr;
  using boost::python::return_value_policy;
  using boost::python::reference_existing_object;

  module m("m");
  
  m
    .add(class_<A, shared_ptr<A> >("A"))

    .add(
      class_<V, boost::noncopyable>("V")
      .def("inside", &V::inside, 
           return_value_policy<reference_existing_object>())
      .def("outside", outside, 
           return_value_policy<reference_existing_object>())
      )
    ;
}






From pbienst at MIT.EDU  Wed Apr  3 18:07:43 2002
From: pbienst at MIT.EDU (Peter Bienstman)
Date: 03 Apr 2002 11:07:43 -0500
Subject: [C++-sig] another V2 bug
Message-ID: <1017850063.23100.41.camel@hunsmac.mit.edu>

Adding a second argument to an otherwise identical function fails to
compile:

#define BOOST_PYTHON_DYNAMIC_LIB
#define BOOST_PYTHON_V2

#include <boost/python/module.hpp>
#include <boost/python/class.hpp>

struct C {};

struct FE {};

struct MWG
{
   const FE fe (const C&)           {return FE();}
   const FE fe2(const C&, const C&) {return FE();}
};

BOOST_PYTHON_MODULE_INIT(m)
{
  using namespace boost::python;

  module m("m");
  
  m
    .add(class_<C>("C"))
    .add(class_<FE>("FE"))
    .add(
      class_<MWG>("MWG")
      .def("fe",  &MWG::fe)  // this compiles.
      .def("fe2", &MWG::fe2) // this doesn't.
      )
    ;
}


Compiler output:

pbienst at hunsmac:~/tmp$ g++ -I/home/pbienst/boost_cvs/boost
-I/home/pbienst/local/include/python2.2 -shared boost_test.cpp
/home/pbienst/boost_cvs/boost/boost/python/detail/member_function_cast.hpp: In
   static member function `static boost::python::detail::cast_helper<S,
R
   (T::*)(A0, A1)>
   boost::python::detail::member_function_cast_impl<T>::stage1(R
(S::*)(A0,
   A1)) [with S = MWG, R = const FE, A0 = const C&, A1 = const C&, T =
MWG]':
/home/pbienst/boost_cvs/boost/boost/python/class.hpp:99:   instantiated
from `boost::python::class_<T, X1, X2, X3>& boost::python::class_<T, X1,
X2, X3>::def(const char*, F) [with F = const FE (MWG::*)(const C&, const
C&), T = MWG, X1 = boost::python::detail::not_specified, X2 =
boost::python::detail::not_specified, X3 =
boost::python::detail::not_specified]'
boost_test.cpp:30:   instantiated from here
/home/pbienst/boost_cvs/boost/boost/python/detail/member_function_cast.hpp:68: conversion
   from `boost::python::detail::cast_helper<const FE (MWG::*)(const C&,
const
   C&), const FE (MWG::*)(const C&, const C&)>' to non-scalar type
   `boost::python::detail::cast_helper<MWG, const FE (MWG::*)(const C&,
const
   C&)>' requested





From david.abrahams at rcn.com  Wed Apr  3 19:31:54 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 3 Apr 2002 12:31:54 -0500
Subject: [C++-sig] another V2 bug
References: <1017850063.23100.41.camel@hunsmac.mit.edu>
Message-ID: <01a101c1db35$749e5e10$1101a8c0@boostconsulting.com>

Fixed, thanks!

----- Original Message ----- 
From: "Peter Bienstman" <pbienst at MIT.EDU>
To: <c++-sig at python.org>
Sent: Wednesday, April 03, 2002 11:07 AM
Subject: [C++-sig] another V2 bug


> Adding a second argument to an otherwise identical function fails to
> compile:
> 
> #define BOOST_PYTHON_DYNAMIC_LIB
> #define BOOST_PYTHON_V2
> 
> #include <boost/python/module.hpp>
> #include <boost/python/class.hpp>
> 
> struct C {};
> 
> struct FE {};
> 
> struct MWG
> {
>    const FE fe (const C&)           {return FE();}
>    const FE fe2(const C&, const C&) {return FE();}
> };
> 
> BOOST_PYTHON_MODULE_INIT(m)
> {
>   using namespace boost::python;
> 
>   module m("m");
>   
>   m
>     .add(class_<C>("C"))
>     .add(class_<FE>("FE"))
>     .add(
>       class_<MWG>("MWG")
>       .def("fe",  &MWG::fe)  // this compiles.
>       .def("fe2", &MWG::fe2) // this doesn't.
>       )
>     ;
> }
> 






From pbienst at MIT.EDU  Wed Apr  3 21:55:29 2002
From: pbienst at MIT.EDU (Peter Bienstman)
Date: 03 Apr 2002 14:55:29 -0500
Subject: [C++-sig] V2 bug resurfaces
Message-ID: <1017863729.23100.45.camel@hunsmac.mit.edu>

A slightly modified version of my previous bug report, now with more
than 2 arguments, fails in a similar way.

#define BOOST_PYTHON_DYNAMIC_LIB
#define BOOST_PYTHON_V2

#include <boost/python/module.hpp>
#include <boost/python/class.hpp>

struct C {};

struct FE {};

struct MWG
{
   const FE fe (const C&)           {return FE();}
   const FE fe2(const C&, const C&,int,int,int,int,int,int,int,int)
{return FE();}
};

BOOST_PYTHON_MODULE_INIT(m)
{
  using namespace boost::python;

  module m("m");
  
  m
    .add(class_<C>("C"))
    .add(class_<FE>("FE"))
    .add(
      class_<MWG>("MWG")
      .def("fe",  &MWG::fe)  // this compiles.
      .def("fe2", &MWG::fe2) // this doesn't.
      )
    ;
}







From david.abrahams at rcn.com  Wed Apr  3 23:42:47 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 3 Apr 2002 16:42:47 -0500
Subject: [C++-sig] V2 bug resurfaces
References: <1017863729.23100.45.camel@hunsmac.mit.edu>
Message-ID: <023801c1db58$e60b74c0$1101a8c0@boostconsulting.com>

Well, there's currently a limit on the number of supported arguments
(6), and you've exceeded it. When I get a chance (in the next few days)
I'll be using the Preprocessor lib. to generate support for an arbitrary
number of args... or you could do it; patches welcome.

----- Original Message -----
From: "Peter Bienstman" <pbienst at MIT.EDU>
To: <c++-sig at python.org>
Sent: Wednesday, April 03, 2002 2:55 PM
Subject: [C++-sig] V2 bug resurfaces


> A slightly modified version of my previous bug report, now with more
> than 2 arguments, fails in a similar way.
>
> #define BOOST_PYTHON_DYNAMIC_LIB
> #define BOOST_PYTHON_V2
>
> #include <boost/python/module.hpp>
> #include <boost/python/class.hpp>
>
> struct C {};
>
> struct FE {};
>
> struct MWG
> {
>    const FE fe (const C&)           {return FE();}
>    const FE fe2(const C&, const C&,int,int,int,int,int,int,int,int)
> {return FE();}
> };
>
> BOOST_PYTHON_MODULE_INIT(m)
> {
>   using namespace boost::python;
>
>   module m("m");
>
>   m
>     .add(class_<C>("C"))
>     .add(class_<FE>("FE"))
>     .add(
>       class_<MWG>("MWG")
>       .def("fe",  &MWG::fe)  // this compiles.
>       .def("fe2", &MWG::fe2) // this doesn't.
>       )
>     ;
> }
>
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>





From david.abrahams at rcn.com  Thu Apr  4 02:16:59 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 3 Apr 2002 19:16:59 -0500
Subject: [C++-sig] V2: corner case bug?
References: <1017788573.23101.29.camel@hunsmac.mit.edu>
Message-ID: <035001c1db6e$863a7cb0$1101a8c0@boostconsulting.com>

Hi Peter,

Thanks for uncovering this!

Here's what's going on:
* In C++, a const& argument can bind to a temporary rvalue.
* Various from_python converters create the equivalent of temporaries.
For example, a converter which produces a std::vector from a Python
tuple must create a value which won't persist past the call being
executed.
* When the library detects that it can bind a temporary of type T to a
given argument, it must produce storage into which that temporary can be
constructed.
* To do so, it asks what boost::aligmnent_of<T>::value is.

Unfortunately, detecting the alignment of T can only compile when T
doesn't have unimplemented pure virtual functions.

I spent all day thinking that we'd need one or both of the following:

    1. A way to tell the library not to do that for T. I think this
    amounts to a user-specializable is_abstract<T> traits class.

    Upside:
    Users could stop specifying noncopyable as an optional
    class_<> parameter if they specialized is_abstract<T>.

    Downside:
    This is a cumbersome interface technique for users, requiring
closing
    their namespace and opening namespace boost::python. It's prone to
    errors: users may not expose the traits specialization to all
    modules converting T parameters, especially in designs where
    wrapping is an independent, non-intrusive layer from the code being
    wrapped. We could mitigate some of the encumberance by asking a user
    to declare a function like:

        bool operator==(T const&, boost::python::abstract);

    in her own namespace to indicate abstract-ness. However, that idiom
    is not exactly transparent, and doesn't fix the error-prone-ness.


    2. A way to tell the library not to do that for a particular
    argument. In other words, "do NOT bind this argument to an rvalue".
    One way for the user to approximate this is to wrap a forwarding
    function taking a T& argument. Having this capability in the library
    would undoubtedly be useful, but it would be non-trivial to
implement
    and I'm not sure the added complexity is a good idea, either for
    the implementation or for the interface.

Fortunately, there is an alternative which I just thought of:

    3. instead of asking for the alignment of T, I can simply produce
    my best guess at maximally-aligned storage. Downsides: more stack
    memory used per wrapped C++ function (trivial). Can never check that
    the storage is in fact appropriately aligned, whether or not T is
    abstract (because I'll get errors if T /is/ abstract). Upsides:
    simplicity for users. Easy to implement. I can check my alignment
    asumptions when T is exposed as a class, as long as noncopyable
    isn't specified.

I'm planning to implement 3 unless I hear otherwise from people.

-Dave

----- Original Message -----
From: "Peter Bienstman" <pbienst at MIT.EDU>
To: <c++-sig at python.org>
Sent: Tuesday, April 02, 2002 6:02 PM
Subject: [C++-sig] V2: corner case bug?


> OK, this odd combination of abstract base classes, referencing
existing
> objects and adding new functions to a class does not compile.
>
> Wrapping the 'inside' functions goes fine, wrapping the similar
> 'outside' functions doesn't compile because the compiler wants to
> instantiate the abstract class, although it's marked noncopyable.
>
> #define BOOST_PYTHON_DYNAMIC_LIB
> #define BOOST_PYTHON_V2
>
> #include <boost/python/module.hpp>
> #include <boost/python/class.hpp>
> #include <boost/python/reference_existing_object.hpp>
> #include <boost/python/return_value_policy.hpp>
>
> struct A {};
>
> struct V
> {
>
>  virtual void f() = 0;
>
>  const A* inside() {return &a;}
>
>  A a;
> };
>
> const A* outside(const V& v) {return &v.a;}
>
> BOOST_PYTHON_MODULE_INIT(m)
> {
>   using namespace boost::python;
>   using boost::shared_ptr;
>   using boost::python::return_value_policy;
>   using boost::python::reference_existing_object;
>
>   module m("m");
>
>   m
>     .add(class_<A, shared_ptr<A> >("A"))
>
>     .add(
>       class_<V, boost::noncopyable>("V")
>       .def("inside", &V::inside,
>            return_value_policy<reference_existing_object>())
>       .def("outside", outside,
>            return_value_policy<reference_existing_object>())
>       )
>     ;
> }
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>





From david.abrahams at rcn.com  Thu Apr  4 18:13:14 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 4 Apr 2002 11:13:14 -0500
Subject: [C++-sig] V2: corner case bug?
References: <1017788573.23101.29.camel@hunsmac.mit.edu>
Message-ID: <07d801c1dbf3$a5907c10$1101a8c0@boostconsulting.com>

This bug is now fixed in the CVS. Thanks for the report, Peter!

----- Original Message -----
From: "Peter Bienstman" <pbienst at MIT.EDU>


> OK, this odd combination of abstract base classes, referencing
existing
> objects and adding new functions to a class does not compile.
>
> Wrapping the 'inside' functions goes fine, wrapping the similar
> 'outside' functions doesn't compile because the compiler wants to
> instantiate the abstract class, although it's marked noncopyable.
>
> #define BOOST_PYTHON_DYNAMIC_LIB
> #define BOOST_PYTHON_V2
>
> #include <boost/python/module.hpp>
> #include <boost/python/class.hpp>
> #include <boost/python/reference_existing_object.hpp>
> #include <boost/python/return_value_policy.hpp>
>
> struct A {};
>
> struct V
> {
>
>  virtual void f() = 0;
>
>  const A* inside() {return &a;}
>
>  A a;
> };
>
> const A* outside(const V& v) {return &v.a;}
>
> BOOST_PYTHON_MODULE_INIT(m)
> {
>   using namespace boost::python;
>   using boost::shared_ptr;
>   using boost::python::return_value_policy;
>   using boost::python::reference_existing_object;
>
>   module m("m");
>
>   m
>     .add(class_<A, shared_ptr<A> >("A"))
>
>     .add(
>       class_<V, boost::noncopyable>("V")
>       .def("inside", &V::inside,
>            return_value_policy<reference_existing_object>())
>       .def("outside", outside,
>            return_value_policy<reference_existing_object>())
>       )
>     ;
> }
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>





From pbienst at MIT.EDU  Thu Apr  4 18:55:55 2002
From: pbienst at MIT.EDU (Peter Bienstman)
Date: 04 Apr 2002 11:55:55 -0500
Subject: [C++-sig] V2: corner case bug?
In-Reply-To: <07d801c1dbf3$a5907c10$1101a8c0@boostconsulting.com>
References: <1017788573.23101.29.camel@hunsmac.mit.edu> 
	<07d801c1dbf3$a5907c10$1101a8c0@boostconsulting.com>
Message-ID: <1017939356.23100.52.camel@hunsmac.mit.edu>

On Thu, 2002-04-04 at 11:13, David Abrahams wrote:
> This bug is now fixed in the CVS. Thanks for the report, Peter!

Thanks for the quick fix!

There is also another case were this issue manifests itself: in passing
abstract base classes to constructors:


#define BOOST_PYTHON_DYNAMIC_LIB
#define BOOST_PYTHON_V2

#include <boost/python/module.hpp>
#include <boost/python/class.hpp>
#include <boost/mpl/type_list.hpp>

struct V 
{
 virtual void f() = 0;
};

struct B 
{
    B(const V&) {}    
};

BOOST_PYTHON_MODULE_INIT(m)
{
  using namespace boost::python;
  using boost::mpl::type_list;

  module m("m");
  
  m

    .add(
      class_<V, boost::noncopyable>("V")
      )

    .add(
      class_<B>("B")
      .def_init(type_list<const V&>())
      )
    ;
}







From peter.bienstman at rug.ac.be  Thu Apr  4 20:33:29 2002
From: peter.bienstman at rug.ac.be (Peter Bienstman)
Date: 04 Apr 2002 13:33:29 -0500
Subject: [C++-sig] fun V2 segfault
Message-ID: <1017945210.2157.4.camel@h00d0597a1e9f>

OK, here's a fun transcript of a python session. Bienstman1_ext can be
any V2 module, and Numeric can be any other Python extension module:

pbienst at hunsmac:~/boost_cvs/boost/libs/python/test/bin/bienstman1_ext.so/gcc/debug/runtime-link-dynamic/shared-linkable-true$ python
Python 2.2 (#1, Apr  1 2002, 10:37:59)
[GCC 3.0.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from Numeric import *
>>> from bienstman1_ext import *
>>>

Everything OK!

pbienst at hunsmac:~/boost_cvs/boost/libs/python/test/bin/bienstman1_ext.so/gcc/debug/runtime-link-dynamic/shared-linkable-true$ python
Python 2.2 (#1, Apr  1 2002, 10:37:59)
[GCC 3.0.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from bienstman1_ext import *
>>> from Numeric import *
Segmentation fault

Stacktracing this shows up some stuff related to GC and timing, I think.

Peter





From david.abrahams at rcn.com  Thu Apr  4 23:15:54 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 4 Apr 2002 16:15:54 -0500
Subject: [C++-sig] V2: corner case bug?
References: <1017788573.23101.29.camel@hunsmac.mit.edu> <07d801c1dbf3$a5907c10$1101a8c0@boostconsulting.com> <1017939356.23100.52.camel@hunsmac.mit.edu>
Message-ID: <08b101c1dc1e$4d528db0$1101a8c0@boostconsulting.com>

Now cut that out! (just kidding: keep 'em coming).

Fixed in CVS.

----- Original Message -----
From: "Peter Bienstman" <pbienst at MIT.EDU>


> On Thu, 2002-04-04 at 11:13, David Abrahams wrote:
> > This bug is now fixed in the CVS. Thanks for the report, Peter!
>
> Thanks for the quick fix!
>
> There is also another case were this issue manifests itself: in
passing
> abstract base classes to constructors:
>
>
> #define BOOST_PYTHON_DYNAMIC_LIB
> #define BOOST_PYTHON_V2
>
> #include <boost/python/module.hpp>
> #include <boost/python/class.hpp>
> #include <boost/mpl/type_list.hpp>
>
> struct V
> {
>  virtual void f() = 0;
> };
>
> struct B
> {
>     B(const V&) {}
> };
>
> BOOST_PYTHON_MODULE_INIT(m)
> {
>   using namespace boost::python;
>   using boost::mpl::type_list;
>
>   module m("m");
>
>   m
>
>     .add(
>       class_<V, boost::noncopyable>("V")
>       )
>
>     .add(
>       class_<B>("B")
>       .def_init(type_list<const V&>())
>       )
>     ;
> }
>
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>





From peter.bienstman at rug.ac.be  Fri Apr  5 00:11:54 2002
From: peter.bienstman at rug.ac.be (Peter Bienstman)
Date: 04 Apr 2002 17:11:54 -0500
Subject: [C++-sig] V2 runtime error
Message-ID: <1017958315.2630.0.camel@h00d0597a1e9f>

By popular demand, another problem report ;-)

This code gives a run time error:

RuntimeError: extension class wrapper for base class 3MWG has not been
created yet

The testcase is distilled from my code, but there, I don't get a runtime
error, but strange runtime results (for creation of subsequent P
objects, a bogus m object is used, which is always the same regardless
of the actual argument.) Not sure if it's the same problem, though.

Peter

#define BOOST_PYTHON_DYNAMIC_LIB
#define BOOST_PYTHON_V2

#include <boost/python/module.hpp>
#include <boost/python/class.hpp>
#include <boost/mpl/type_list.hpp>

#include <iostream>
using namespace std;

struct BM {virtual void f() = 0;};
struct M : public BM {void f() {}};

struct WG {virtual void g() = 0;};
struct MWG : public WG {};
struct P : public MWG
{
    P(M& m_) : m(&m_) {cout << m << endl;}
    void g() {}
    M* m;
};


BOOST_PYTHON_MODULE_INIT(m)
{
  using namespace boost::python;
  using boost::mpl::type_list;
  

  module m("m");
  
  m
    .add(class_<BM, boost::noncopyable>("BM"))
    .add(class_<M, bases<BM> >("M"))
    .add(class_<WG, boost::noncopyable>("WG"))
    .add(class_<MWG, bases<WG>, boost::noncopyable >("MWG"))
    .add(class_<P, bases<MWG> >("P")
         .def_init(type_list<M&>()));
}








From david.abrahams at rcn.com  Fri Apr  5 00:25:10 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 4 Apr 2002 17:25:10 -0500
Subject: [C++-sig] V2 runtime error
References: <1017958315.2630.0.camel@h00d0597a1e9f>
Message-ID: <08c701c1dc27$9af446e0$1101a8c0@boostconsulting.com>

This is an order-of-evaluation/sequence point issue.
In order to guarantee that

    class_<MWG, bases<WG>, boost::noncopyable >("MWG")

is executed before

    class_<P, bases<MWG> >("P")
          .def_init(type_list<M&>())

you must add() them in separate expressions:

    m.add(class_<MWG, bases<WG>, boost::noncopyable >("MWG"))

    m.add(class_<P, bases<MWG> >("P")
          .def_init(type_list<M&>()))

Maybe someday I will be able to defer the class creation until m.add()
is executed, however that would be a nontrivial change.

Sorry for the inconvenience,
Dave

----- Original Message -----
From: "Peter Bienstman" <peter.bienstman at rug.ac.be>


> By popular demand, another problem report ;-)
>
> This code gives a run time error:
>
> RuntimeError: extension class wrapper for base class 3MWG has not been
> created yet
>
> The testcase is distilled from my code, but there, I don't get a
runtime
> error, but strange runtime results (for creation of subsequent P
> objects, a bogus m object is used, which is always the same regardless
> of the actual argument.) Not sure if it's the same problem, though.
>
> Peter
>
> #define BOOST_PYTHON_DYNAMIC_LIB
> #define BOOST_PYTHON_V2
>
> #include <boost/python/module.hpp>
> #include <boost/python/class.hpp>
> #include <boost/mpl/type_list.hpp>
>
> #include <iostream>
> using namespace std;
>
> struct BM {virtual void f() = 0;};
> struct M : public BM {void f() {}};
>
> struct WG {virtual void g() = 0;};
> struct MWG : public WG {};
> struct P : public MWG
> {
>     P(M& m_) : m(&m_) {cout << m << endl;}
>     void g() {}
>     M* m;
> };
>
>
> BOOST_PYTHON_MODULE_INIT(m)
> {
>   using namespace boost::python;
>   using boost::mpl::type_list;
>
>
>   module m("m");
>
>   m
>     .add(class_<BM, boost::noncopyable>("BM"))
>     .add(class_<M, bases<BM> >("M"))
>     .add(class_<WG, boost::noncopyable>("WG"))
>     .add(class_<MWG, bases<WG>, boost::noncopyable >("MWG"))
>     .add(class_<P, bases<MWG> >("P")
>          .def_init(type_list<M&>()));
> }
>
>
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>





From david.abrahams at rcn.com  Fri Apr  5 00:48:09 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 4 Apr 2002 17:48:09 -0500
Subject: [C++-sig] fun V2 segfault
References: <1017945210.2157.4.camel@h00d0597a1e9f>
Message-ID: <08e701c1dc2a$d96470a0$1101a8c0@boostconsulting.com>

----- Original Message -----
From: "Peter Bienstman" <peter.bienstman at rug.ac.be>

>
pbienst at hunsmac:~/boost_cvs/boost/libs/python/test/bin/bienstman1_ext.so
/gcc/debug/runtime-link-dynamic/shared-linkable-true$ python
> Python 2.2 (#1, Apr  1 2002, 10:37:59)
> [GCC 3.0.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from bienstman1_ext import *
> >>> from Numeric import *
> Segmentation fault
>
> Stacktracing this shows up some stuff related to GC and timing, I
think.

Well, I'm not reproducing this here on Win32. Can you send a stacktrace?
I will try it elsewhere, too...

Also, do you know how to build a version of Numeric that has the Python
memory debugging stuff enabled? That would be a help. I can't find any
such option in distutils.

-Dave






From peter.bienstman at rug.ac.be  Fri Apr  5 01:20:08 2002
From: peter.bienstman at rug.ac.be (Peter Bienstman)
Date: 04 Apr 2002 18:20:08 -0500
Subject: [C++-sig] fun V2 segfault
In-Reply-To: <08e701c1dc2a$d96470a0$1101a8c0@boostconsulting.com>
References: <1017945210.2157.4.camel@h00d0597a1e9f> 
	<08e701c1dc2a$d96470a0$1101a8c0@boostconsulting.com>
Message-ID: <1017962411.2630.2.camel@h00d0597a1e9f>

This is the stacktrace. I don't know how to build Numeric with debugging
enabled, sorry.. However, it's not restricted to Numeric. Dislin and
plplot e.g have the same problems.

Peter

#0  0x080a3bae in visit_move (op=0x40966e60, tolist=0xbfffc4a0)
    at Modules/gcmodule.c:96
#1  0x080622e7 in tupletraverse (o=0x81a627c, visit=0x80a3b70
<visit_move>,
    arg=0xbfffc4a0) at Objects/tupleobject.c:403
#2  0x080a2d33 in collect (young=0x8136aa0, old=0x8136aac)
    at Modules/gcmodule.c:223
#3  0x080a3408 in collect_generations () at Modules/gcmodule.c:486
#4  0x080a39a8 in _PyObject_GC_New (tp=0x81791a0) at
Modules/gcmodule.c:843
#5  0x080fc3c9 in PyFunction_New (code=0x81e6d60, globals=0x81f7d9c)
    at Objects/funcobject.c:12
#6  0x0807e1ac in eval_frame (f=0x81be9bc) at Python/ceval.c:2076
#7  0x0807ed5c in PyEval_EvalCodeEx (co=0x81f8350, globals=0x81f7d9c,
    locals=0x81f7d9c, args=0x0, argcount=0, kws=0x0, kwcount=0,
defs=0x0,
    defcount=0, closure=0x0) at Python/ceval.c:2574
#8  0x08081425 in PyEval_EvalCode (co=0x81f8350, globals=0x81f7d9c,
    locals=0x81f7d9c) at Python/ceval.c:483
#9  0x080945fe in PyImport_ExecCodeModuleEx (name=0xbfffd020 "string",
    co=0x81f8350,
    pathname=0xbfffc710 "/home/pbienst/local/lib/python2.2/string.pyc")
    at Python/import.c:506
#10 0x08094a64 in load_source_module (name=0xbfffd020 "string",
    pathname=0xbfffcb90 "/home/pbienst/local/lib/python2.2/string.py",
    fp=0x81e4538) at Python/import.c:776#11 0x080953c1 in load_module
(name=0xbfffd020 "string", fp=0x81e4538,
    buf=0xbfffcb90 "/home/pbienst/local/lib/python2.2/string.py",
type=1)
    at Python/import.c:1360
#12 0x08096092 in import_submodule (mod=0x812bbdc,
    subname=0xbfffd020 "string", fullname=0xbfffd020 "string")
    at Python/import.c:1899
#13 0x08095c5d in load_next (mod=0x812bbdc, altmod=0x812bbdc,
    p_name=0xbfffd450, buf=0xbfffd020 "string", p_buflen=0xbfffd01c)
    at Python/import.c:1755
#14 0x08095884 in import_module_ex (name=0x0, globals=0x81e5174,
    locals=0x81e5174, fromlist=0x812bbdc) at Python/import.c:1606
#15 0x08096fca in PyImport_ImportModuleEx (name=0x81f028c "string",
    globals=0x81e5174, locals=0x81e5174, fromlist=0x812bbdc)
    at Python/import.c:1647
#16 0x0810d615 in builtin___import__ (self=0x0, args=0x81e59a4)
    at Python/bltinmodule.c:44
#17 0x08109aeb in PyCFunction_Call (func=0x8188b80, arg=0x81e59a4,
kw=0x0)
    at Objects/methodobject.c:69
#18 0x080e82a2 in PyObject_Call (func=0x8188b80, arg=0x81e59a4, kw=0x0)
    at Objects/abstract.c:1665
#19 0x08080c4b in PyEval_CallObjectWithKeywords (func=0x8188b80,
    arg=0x81e59a4, kw=0x0) at Python/ceval.c:3038
#20 0x0807db04 in eval_frame (f=0x81b26a4) at Python/ceval.c:1828#21
0x0807ed5c in PyEval_EvalCodeEx (co=0x81e62c0, globals=0x81e5174,
    locals=0x81e5174, args=0x0, argcount=0, kws=0x0, kwcount=0,
defs=0x0,
    defcount=0, closure=0x0) at Python/ceval.c:2574
#22 0x08081425 in PyEval_EvalCode (co=0x81e62c0, globals=0x81e5174,
    locals=0x81e5174) at Python/ceval.c:483
#23 0x080945fe in PyImport_ExecCodeModuleEx (name=0xbfffdff0
"Precision",
    co=0x81e62c0,
    pathname=0xbfffd6e0
"/home/pbienst/local/lib/python2.2/site-packages/Numeric/Precision.pyc")
at Python/import.c:506
#24 0x08094a64 in load_source_module (name=0xbfffdff0 "Precision",
    pathname=0xbfffdb60
"/home/pbienst/local/lib/python2.2/site-packages/Numeric/Precision.py",
fp=0x81e00d0) at Python/import.c:776
#25 0x080953c1 in load_module (name=0xbfffdff0 "Precision",
fp=0x81e00d0,
    buf=0xbfffdb60
"/home/pbienst/local/lib/python2.2/site-packages/Numeric/Precision.py",
type=1) at Python/import.c:1360
#26 0x08096092 in import_submodule (mod=0x812bbdc,
    subname=0xbfffdff0 "Precision", fullname=0xbfffdff0 "Precision")
    at Python/import.c:1899
#27 0x08095c5d in load_next (mod=0x812bbdc, altmod=0x812bbdc,
    p_name=0xbfffe420, buf=0xbfffdff0 "Precision", p_buflen=0xbfffdfec)
    at Python/import.c:1755
#28 0x08095884 in import_module_ex (name=0x0, globals=0x81f62cc,
    locals=0x81f62cc, fromlist=0x81df29c) at Python/import.c:1606
#29 0x08096fca in PyImport_ImportModuleEx (name=0x81f57bc "Precision",
    globals=0x81f62cc, locals=0x81f62cc, fromlist=0x81df29c)
    at Python/import.c:1647
#30 0x0810d615 in builtin___import__ (self=0x0, args=0x81f6274)
    at Python/bltinmodule.c:44
#31 0x08109aeb in PyCFunction_Call (func=0x8188b80, arg=0x81f6274,
kw=0x0)
    at Objects/methodobject.c:69
#32 0x080e82a2 in PyObject_Call (func=0x8188b80, arg=0x81f6274, kw=0x0)
    at Objects/abstract.c:1665
#33 0x08080c4b in PyEval_CallObjectWithKeywords (func=0x8188b80,
    arg=0x81f6274, kw=0x0) at Python/ceval.c:3038
#34 0x0807db04 in eval_frame (f=0x81aada4) at Python/ceval.c:1828
#35 0x0807ed5c in PyEval_EvalCodeEx (co=0x81f5fb0, globals=0x81f62cc,
    locals=0x81f62cc, args=0x0, argcount=0, kws=0x0, kwcount=0,
defs=0x0,
    defcount=0, closure=0x0) at Python/ceval.c:2574
#36 0x08081425 in PyEval_EvalCode (co=0x81f5fb0, globals=0x81f62cc,
    locals=0x81f62cc) at Python/ceval.c:483
#37 0x080945fe in PyImport_ExecCodeModuleEx (name=0xbfffefc0 "Numeric",
    co=0x81f5fb0,
    pathname=0xbfffe6b0
"/home/pbienst/local/lib/python2.2/site-packages/Numeric/Numeric.pyc")
at Python/import.c:506
#38 0x08094a64 in load_source_module (name=0xbfffefc0 "Numeric",
    pathname=0xbfffeb30
"/home/pbienst/local/lib/python2.2/site-packages/Numeri
#39 0x080953c1 in load_module (name=0xbfffefc0 "Numeric", fp=0x81b8820,
    buf=0xbfffeb30
"/home/pbienst/local/lib/python2.2/site-packages/Numeric/Numeric.py",
type=1) at Python/import.c:1360
#40 0x08096092 in import_submodule (mod=0x812bbdc,
    subname=0xbfffefc0 "Numeric", fullname=0xbfffefc0 "Numeric")
    at Python/import.c:1899
#41 0x08095c5d in load_next (mod=0x812bbdc, altmod=0x812bbdc,
    p_name=0xbffff3f0, buf=0xbfffefc0 "Numeric", p_buflen=0xbfffefbc)
    at Python/import.c:1755
#42 0x08095884 in import_module_ex (name=0x0, globals=0x8194ed4,
    locals=0x8194ed4, fromlist=0x81971a4) at Python/import.c:1606
#43 0x08096fca in PyImport_ImportModuleEx (name=0x819816c "Numeric",
    globals=0x8194ed4, locals=0x8194ed4, fromlist=0x81971a4)
    at Python/import.c:1647
#44 0x0810d615 in builtin___import__ (self=0x0, args=0x818e0bc)
    at Python/bltinmodule.c:44
#45 0x08109aeb in PyCFunction_Call (func=0x8188b80, arg=0x818e0bc,
kw=0x0)
    at Objects/methodobject.c:69
#46 0x080e82a2 in PyObject_Call (func=0x8188b80, arg=0x818e0bc, kw=0x0)
    at Objects/abstract.c:1665
#47 0x08080c4b in PyEval_CallObjectWithKeywords (func=0x8188b80,
    arg=0x818e0bc, kw=0x0) at Python/ceval.c:3038
#48 0x0807db04 in eval_frame (f=0x819bed4) at Python/ceval.c:1828
#49 0x0807ed5c in PyEval_EvalCodeEx (co=0x81973e8, globals=0x8194ed4,
    locals=0x8194ed4, args=0x0, argcount=0, kws=0x0, kwcount=0,
defs=0x0,
    defcount=0, closure=0x0) at Python/ceval.c:2574
#50 0x08081425 in PyEval_EvalCode (co=0x81973e8, globals=0x8194ed4,
    locals=0x8194ed4) at Python/ceval.c:483
#51 0x0809e44b in run_node (n=0x818b440, filename=0xbffff8d6 "order.py",
    globals=0x8194ed4, locals=0x8194ed4, flags=0xbffff69c)
    at Python/pythonrun.c:1083
#52 0x0809cb6f in PyRun_SimpleFileExFlags (fp=0x81852a8,
    filename=0xbffff8d6 "order.py", closeit=1, flags=0xbffff69c)
    at Python/pythonrun.c:689
#53 0x08055d9a in Py_Main (argc=2, argv=0xbffff774) at
Modules/main.c:369
#54 0x08055849 in main (argc=2, argv=0xbffff774) at Modules/python.c:10
#55 0x402e75b0 in __libc_start_main () from /lib/libc.so.6



On Thu, 2002-04-04 at 17:48, David Abrahams wrote:
> 
> ----- Original Message -----
> From: "Peter Bienstman" <peter.bienstman at rug.ac.be>
> 
> >
> pbienst at hunsmac:~/boost_cvs/boost/libs/python/test/bin/bienstman1_ext.so
> /gcc/debug/runtime-link-dynamic/shared-linkable-true$ python
> > Python 2.2 (#1, Apr  1 2002, 10:37:59)
> > [GCC 3.0.1] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> from bienstman1_ext import *
> > >>> from Numeric import *
> > Segmentation fault
> >
> > Stacktracing this shows up some stuff related to GC and timing, I
> think.
> 
> Well, I'm not reproducing this here on Win32. Can you send a stacktrace?
> I will try it elsewhere, too...
> 
> Also, do you know how to build a version of Numeric that has the Python
> memory debugging stuff enabled? That would be a help. I can't find any
> such option in distutils.
> 
> -Dave
> 
> 
> 
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig






From david.abrahams at rcn.com  Fri Apr  5 01:40:03 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 4 Apr 2002 18:40:03 -0500
Subject: [C++-sig] fun V2 segfault
References: <1017945210.2157.4.camel@h00d0597a1e9f> <08e701c1dc2a$d96470a0$1101a8c0@boostconsulting.com> <1017962411.2630.2.camel@h00d0597a1e9f>
Message-ID: <092801c1dc32$9d5148b0$1101a8c0@boostconsulting.com>

----- Original Message -----
From: "Peter Bienstman" <peter.bienstman at rug.ac.be>


> This is the stacktrace. I don't know how to build Numeric with
debugging
> enabled, sorry.. However, it's not restricted to Numeric. Dislin and
> plplot e.g have the same problems.

I don't have either of those packages on my system and I can't reproduce
the bug, so I may have to ask for your help tracking it down. The last
time I saw this, it turned out that I had the wrong flags in
libs/python/src/object/class.cpp. You can still see that
Py_TPFLAGS_HAVE_GC is commented out there. What Python does when you
don't fill in a field explicitly but you inherit from a builtin is
dependent on flags and some "magic" logic in typeobject.c. I'm still not
sure we have everything right.

A recent discussion about memory allocation protocols is here:
http://mail.python.org/pipermail/python-dev/2002-April/022150.html

I'll do as much investigation as possible here on my system,
meanwhile...

-Dave






From david.abrahams at rcn.com  Fri Apr  5 06:09:13 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 4 Apr 2002 23:09:13 -0500
Subject: [C++-sig] fun V2 segfault
References: <1017945210.2157.4.camel@h00d0597a1e9f>
Message-ID: <09a801c1dc57$a8427e40$1101a8c0@boostconsulting.com>

I've checked in a change which I hope will fix this problem.
Peter, I'd very much appreciate a report from you on whether it
succeeded.

Thanks,
Dave

----- Original Message -----
From: "Peter Bienstman" <peter.bienstman at rug.ac.be>


> OK, here's a fun transcript of a python session. Bienstman1_ext can be
> any V2 module, and Numeric can be any other Python extension module:
>
>
pbienst at hunsmac:~/boost_cvs/boost/libs/python/test/bin/bienstman1_ext.so
/gcc/debug/runtime-link-dynamic/shared-linkable-true$ python
> Python 2.2 (#1, Apr  1 2002, 10:37:59)
> [GCC 3.0.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from Numeric import *
> >>> from bienstman1_ext import *
> >>>
>
> Everything OK!
>
>
pbienst at hunsmac:~/boost_cvs/boost/libs/python/test/bin/bienstman1_ext.so
/gcc/debug/runtime-link-dynamic/shared-linkable-true$ python
> Python 2.2 (#1, Apr  1 2002, 10:37:59)
> [GCC 3.0.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from bienstman1_ext import *
> >>> from Numeric import *
> Segmentation fault
>
> Stacktracing this shows up some stuff related to GC and timing, I
think.
>
> Peter
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From pbienst at MIT.EDU  Fri Apr  5 17:54:05 2002
From: pbienst at MIT.EDU (Peter Bienstman)
Date: 05 Apr 2002 10:54:05 -0500
Subject: [C++-sig] fun V2 segfault
In-Reply-To: <09a801c1dc57$a8427e40$1101a8c0@boostconsulting.com>
References: <1017945210.2157.4.camel@h00d0597a1e9f> 
	<09a801c1dc57$a8427e40$1101a8c0@boostconsulting.com>
Message-ID: <1018022045.3190.0.camel@hunsmac.mit.edu>

Problem solved, thanks!

You know, V2 is now getting frightfully close to being useable for real
work.

Peter

On Thu, 2002-04-04 at 23:09, David Abrahams wrote:
> I've checked in a change which I hope will fix this problem.
> Peter, I'd very much appreciate a report from you on whether it
> succeeded.
> 
> Thanks,
> Dave






From david.abrahams at rcn.com  Fri Apr  5 18:26:23 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 5 Apr 2002 11:26:23 -0500
Subject: [C++-sig] fun V2 segfault
References: <1017945210.2157.4.camel@h00d0597a1e9f> <09a801c1dc57$a8427e40$1101a8c0@boostconsulting.com> <1018022045.3190.0.camel@hunsmac.mit.edu>
Message-ID: <00d201c1dcbf$2d8c7ad0$6401a8c0@boostconsulting.com>

----- Original Message -----
From: "Peter Bienstman" <pbienst at MIT.EDU>


> Problem solved, thanks!
>
> You know, V2 is now getting frightfully close to being useable for
real
> work.

:)







From pbienst at MIT.EDU  Fri Apr  5 18:47:17 2002
From: pbienst at MIT.EDU (Peter Bienstman)
Date: 05 Apr 2002 11:47:17 -0500
Subject: [C++-sig] V2: conversions through constructors?
Message-ID: <1018025237.3190.6.camel@hunsmac.mit.edu>

Hi,

I know V2 supports the implicitly_convertible() construct for the case
of implicitly defined conversion operators, but is there something
similar for the case of a constructor A(B), rather than a conversion
operator B->A?

Just wrapping the constructor doesn't seem to do the trick...

Peter







From david.abrahams at rcn.com  Fri Apr  5 18:48:55 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 5 Apr 2002 11:48:55 -0500
Subject: [C++-sig] V2: conversions through constructors?
References: <1018025237.3190.6.camel@hunsmac.mit.edu>
Message-ID: <011b01c1dcc1$c8926240$6401a8c0@boostconsulting.com>

----- Original Message -----
From: "Peter Bienstman" <pbienst at MIT.EDU>


> Hi,
>
> I know V2 supports the implicitly_convertible() construct for the case
> of implicitly defined conversion operators, but is there something
> similar for the case of a constructor A(B), rather than a conversion
> operator B->A?
>
> Just wrapping the constructor doesn't seem to do the trick...

You use the same mechanism:

    implicitly_convertible<B,A>();

see libs/python/test/implicit.*. It shows implicit conversion from
int->X.

    >>> x_value(42)
    42

-Dave






From pbienst at MIT.EDU  Fri Apr  5 22:52:40 2002
From: pbienst at MIT.EDU (Peter Bienstman)
Date: 05 Apr 2002 15:52:40 -0500
Subject: [C++-sig] V2 type_from_python question
Message-ID: <1018039961.3187.10.camel@hunsmac.mit.edu>

OK, one of the final hurdles. I'm trying to convert a Numerical Python
array to a C++ array type. For that I try

struct cVector_from_python
{
  static cVector execute(PyArrayObject& o)
  {
    // do stuff
    return cVector(/* some params */);
  }
};

type_from_python<&PyArray_Type, cVector_from_python>();

This gives compiler errors: 

/home/pbienst/boost_cvs/boost/boost/python/type_from_python.hpp: In
constructor
   `boost::python::type_from_python<python_type,
Extractor>::type_from_python()
   [with const PyTypeObject*python_type = (&PyArray_Type), Extractor =
   cVector_from_python]':
/home/pbienst/camfr_work/camfr/camfr_wrap2.cpp:434:   instantiated from
here
/home/pbienst/boost_cvs/boost/boost/python/type_from_python.hpp:86: no
matching
   function for call to `extractor_type_id(cVector (*)(PyArrayObject&))'

Looking more closely at the examples, I see that all of the 'execute'
functions return a reference, which is of course not an option in my
case.

Am I doing something wrong?

Thanks,

Peter







From pbienst at MIT.EDU  Fri Apr  5 23:03:24 2002
From: pbienst at MIT.EDU (Peter Bienstman)
Date: 05 Apr 2002 16:03:24 -0500
Subject: [C++-sig] V2: conversions through constructors?
In-Reply-To: <011b01c1dcc1$c8926240$6401a8c0@boostconsulting.com>
References: <1018025237.3190.6.camel@hunsmac.mit.edu> 
	<011b01c1dcc1$c8926240$6401a8c0@boostconsulting.com>
Message-ID: <1018040604.3190.12.camel@hunsmac.mit.edu>

> You use the same mechanism:
> 
>     implicitly_convertible<B,A>();
> 
> see libs/python/test/implicit.*. It shows implicit conversion from
> int->X.
> 
>     >>> x_value(42)
>     42
> 

Well, something like this doesn't seem to work:


#define BOOST_PYTHON_DYNAMIC_LIB
#define BOOST_PYTHON_V2

#include <boost/python/module.hpp>
#include <boost/python/class.hpp>
#include <boost/python/implicit.hpp>
#include <boost/mpl/type_list.hpp>

struct T1 {};

struct Term {Term(T1&) {} };

struct Expression {void add(Term&) {} };

BOOST_PYTHON_MODULE_INIT(m)
{
  using namespace boost::python;
  using boost::mpl::type_list;

  implicitly_convertible<T1,Term>();

  module m("m");
  
  m
    .add(class_<Expression>("Expression")
         .def("add", &Expression::add))
    .add(class_<T1>("T1"))
    .add(class_<Term>("Term")
         .def_init(type_list<T1&>()))
    ;
  
}

>>> from m import *
>>> t1 = T1()
>>> e = Expression()
>>> e.add(t1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: bad argument type for built-in operation






From david.abrahams at rcn.com  Sat Apr  6 01:07:38 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 5 Apr 2002 18:07:38 -0500
Subject: [C++-sig] V2 type_from_python question
References: <1018039961.3187.10.camel@hunsmac.mit.edu>
Message-ID: <028801c1dcf6$b047b700$6401a8c0@boostconsulting.com>

----- Original Message -----
From: "Peter Bienstman" <pbienst at MIT.EDU>
To: <c++-sig at python.org>
Sent: Friday, April 05, 2002 3:52 PM
Subject: [C++-sig] V2 type_from_python question


> OK, one of the final hurdles. I'm trying to convert a Numerical Python
> array to a C++ array type. For that I try
>
> struct cVector_from_python
> {
>   static cVector execute(PyArrayObject& o)
>   {
>     // do stuff
>     return cVector(/* some params */);
>   }
> };
>
> type_from_python<&PyArray_Type, cVector_from_python>();
>
> This gives compiler errors:
>
> /home/pbienst/boost_cvs/boost/boost/python/type_from_python.hpp: In
> constructor
>    `boost::python::type_from_python<python_type,
> Extractor>::type_from_python()
>    [with const PyTypeObject*python_type = (&PyArray_Type), Extractor =
>    cVector_from_python]':
> /home/pbienst/camfr_work/camfr/camfr_wrap2.cpp:434:   instantiated
from
> here
> /home/pbienst/boost_cvs/boost/boost/python/type_from_python.hpp:86: no
> matching
>    function for call to `extractor_type_id(cVector
(*)(PyArrayObject&))'
>
> Looking more closely at the examples, I see that all of the 'execute'
> functions return a reference, which is of course not an option in my
> case.
>
> Am I doing something wrong?

You need an rvalue from_python converter. All the examples show lvalue
converters. Some examples of rvalue converters are in
libs/python/src/converter/builtin_converters.cpp.

-Dave

P.S. I plan to do something to make that easier, if I can find a few
minutes... my monthly report shows that I intend to make generalized
sequence converters.






From david.abrahams at rcn.com  Sat Apr  6 01:24:13 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 5 Apr 2002 18:24:13 -0500
Subject: [C++-sig] V2: conversions through constructors?
References: <1018025237.3190.6.camel@hunsmac.mit.edu> <011b01c1dcc1$c8926240$6401a8c0@boostconsulting.com> <1018040604.3190.12.camel@hunsmac.mit.edu>
Message-ID: <029a01c1dcf9$00ec5420$6401a8c0@boostconsulting.com>

----- Original Message -----
From: "Peter Bienstman" <pbienst at MIT.EDU>

> Well, something like this doesn't seem to work:
>
>
> #define BOOST_PYTHON_DYNAMIC_LIB
> #define BOOST_PYTHON_V2
>
> #include <boost/python/module.hpp>
> #include <boost/python/class.hpp>
> #include <boost/python/implicit.hpp>
> #include <boost/mpl/type_list.hpp>
>
> struct T1 {};
>
> struct Term {Term(T1&) {} };
>
> struct Expression {void add(Term&) {} };
>
> BOOST_PYTHON_MODULE_INIT(m)
> {
>   using namespace boost::python;
>   using boost::mpl::type_list;
>
>   implicitly_convertible<T1,Term>();
>
>   module m("m");
>
>   m
>     .add(class_<Expression>("Expression")
>          .def("add", &Expression::add))
>     .add(class_<T1>("T1"))
>     .add(class_<Term>("Term")
>          .def_init(type_list<T1&>()))
>     ;
>
> }
>
> >>> from m import *
> >>> t1 = T1()
> >>> e = Expression()
> >>> e.add(t1)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: bad argument type for built-in operation


The corresponding C++ doesn't work either:

    T1 t1;
    Expression e;
    e.add(t1); // error

Because your arguments are non-const references, you're telling the
library that they don't bind to temporaries. Thus, they require lvalue
converters, and the converters generated by implicitly_convertible<> are
always rvalue converters.

If you change your add() function to accept a Term const&, everything
will work.


-Dave






From pbienst at MIT.EDU  Mon Apr  8 16:33:35 2002
From: pbienst at MIT.EDU (Peter Bienstman)
Date: 08 Apr 2002 10:33:35 -0400
Subject: [C++-sig] V2: conversions through constructors?
In-Reply-To: <029a01c1dcf9$00ec5420$6401a8c0@boostconsulting.com>
References: <1018025237.3190.6.camel@hunsmac.mit.edu>
	<011b01c1dcc1$c8926240$6401a8c0@boostconsulting.com>
	<1018040604.3190.12.camel@hunsmac.mit.edu> 
	<029a01c1dcf9$00ec5420$6401a8c0@boostconsulting.com>
Message-ID: <1018276415.14336.2.camel@hunsmac.mit.edu>

I changed 'add' to accept const Term&, but still the same behaviour..


#define BOOST_PYTHON_DYNAMIC_LIB
#define BOOST_PYTHON_V2

#include <boost/python/module.hpp>
#include <boost/python/class.hpp>
#include <boost/python/implicit.hpp>
#include <boost/mpl/type_list.hpp>

struct T1 {};

struct Term {Term(T1&) {} };

struct Expression {void add(const Term&) {} };

BOOST_PYTHON_MODULE_INIT(m)
{
  using namespace boost::python;
  using boost::mpl::type_list;

  implicitly_convertible<T1,Term>();

  module m("m");
  
  m
    .add(class_<Expression>("Expression")
         .def("add", &Expression::add))
    .add(class_<T1>("T1"))
    .add(class_<Term>("Term")
         .def_init(type_list<T1&>()))
    ;
  
}

On Fri, 2002-04-05 at 18:24, David Abrahams wrote:
> 
> ----- Original Message -----
> From: "Peter Bienstman" <pbienst at MIT.EDU>
> 
> > Well, something like this doesn't seem to work:
> > >>> from m import *
> > >>> t1 = T1()
> > >>> e = Expression()
> > >>> e.add(t1)
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> > TypeError: bad argument type for built-in operation
> 
> 
> The corresponding C++ doesn't work either:
> 
>     T1 t1;
>     Expression e;
>     e.add(t1); // error
> 
> Because your arguments are non-const references, you're telling the
> library that they don't bind to temporaries. Thus, they require lvalue
> converters, and the converters generated by implicitly_convertible<> are
> always rvalue converters.
> 
> If you change your add() function to accept a Term const&, everything
> will work.
> 
> 
> -Dave






From david.abrahams at rcn.com  Tue Apr  9 17:57:44 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Tue, 9 Apr 2002 10:57:44 -0500
Subject: [C++-sig] V2: conversions through constructors?
References: <1018025237.3190.6.camel@hunsmac.mit.edu><011b01c1dcc1$c8926240$6401a8c0@boostconsulting.com><1018040604.3190.12.camel@hunsmac.mit.edu> <029a01c1dcf9$00ec5420$6401a8c0@boostconsulting.com> <1018276415.14336.2.camel@hunsmac.mit.edu>
Message-ID: <03b401c1dfdf$4b83e280$6601a8c0@boostconsulting.com>

Hi Peter,

What you forgot was to explicitly define the default __init__ functions
for your types. Please see bienstman4.cpp in the CVS for an example.

The __init__ function is the mechanism that actually creates the C++
object within the Python object, and none of the member functions of
Expression can work on a Python object until there is a C++ Expression
instance. I have some ideas about how this might be made automatic, but
in the meantime, you need to add def_init() to your class.

Regards,
Dave

P.S. I also plan to improve the error reporting for cases like this ;-)

----- Original Message -----
From: "Peter Bienstman" <pbienst at MIT.EDU>
To: <c++-sig at python.org>
Sent: Monday, April 08, 2002 9:33 AM
Subject: Re: [C++-sig] V2: conversions through constructors?


> I changed 'add' to accept const Term&, but still the same behaviour..
>
>
> #define BOOST_PYTHON_DYNAMIC_LIB
> #define BOOST_PYTHON_V2
>
> #include <boost/python/module.hpp>
> #include <boost/python/class.hpp>
> #include <boost/python/implicit.hpp>
> #include <boost/mpl/type_list.hpp>
>
> struct T1 {};
>
> struct Term {Term(T1&) {} };
>
> struct Expression {void add(const Term&) {} };
>
> BOOST_PYTHON_MODULE_INIT(m)
> {
>   using namespace boost::python;
>   using boost::mpl::type_list;
>
>   implicitly_convertible<T1,Term>();
>
>   module m("m");
>
>   m
>     .add(class_<Expression>("Expression")
>          .def("add", &Expression::add))
>     .add(class_<T1>("T1"))
>     .add(class_<Term>("Term")
>          .def_init(type_list<T1&>()))
>     ;
>
> }
>
> On Fri, 2002-04-05 at 18:24, David Abrahams wrote:
> >
> > ----- Original Message -----
> > From: "Peter Bienstman" <pbienst at MIT.EDU>
> >
> > > Well, something like this doesn't seem to work:
> > > >>> from m import *
> > > >>> t1 = T1()
> > > >>> e = Expression()
> > > >>> e.add(t1)
> > > Traceback (most recent call last):
> > >   File "<stdin>", line 1, in ?
> > > TypeError: bad argument type for built-in operation
> >
> >
> > The corresponding C++ doesn't work either:
> >
> >     T1 t1;
> >     Expression e;
> >     e.add(t1); // error
> >
> > Because your arguments are non-const references, you're telling the
> > library that they don't bind to temporaries. Thus, they require
lvalue
> > converters, and the converters generated by implicitly_convertible<>
are
> > always rvalue converters.
> >
> > If you change your add() function to accept a Term const&,
everything
> > will work.
> >
> >
> > -Dave
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From randre at pppl.gov  Tue Apr  9 21:42:39 2002
From: randre at pppl.gov (Robert Andre)
Date: Tue, 9 Apr 2002 15:42:39 -0400 (EDT)
Subject: [C++-sig] my experiences with boost/python so far
Message-ID: <200204091942.PAA20657@neptune.pppl.gov>

I am relatively new to the boost/python library so I thought I would relate 
some of my experiences with using boost on a dual processor, 
linux mandrake 8.0, 2.2 kernel with gcc 3.0.4:

1) building requires a magic command.  I probably missed the documentation somewhere
   but my magic command turned out to be

     jam -sBOOST_ROOT=/home/randre/cvs/boost -sTOOLS="gcc" -sPYTHON_ROOT="/usr/local" \
         -sPYTHON_VERSION=2.2 -sPYTHON_LIB_PATH="/usr/local/lib/python2.2"

   If I leave off the PYTHON_LIB_PATH I get the failure,

Couldn't find Python 2.2 installation in /usr/local
skipping Boost.Python library build
You can configure the location of your python installation, by setting:
PYTHON_ROOT - currently "/usr/local"
PYTHON_VERSION - currently "2.2"
PYTHON_INCLUDES - configured from PYTHON_ROOT, currently "/usr/local/include/python2.2"
PYTHON_LIB_PATH - configured from PYTHON_ROOT, currently "/usr/local/lib/python2.2/config"
...found 402 targets...

   To test, I had to add -sGCC_ROOT_DIRECTORY=/usr/local with the target 'test' because
   I use LD_LIBRARY_PATH (I know I shouldn't) and it gets reset by the test.  The pickle
   tests always seem to fail for me.

   Is there a way to see what  gcc-C++-action  and  gcc-Link-action are doing? 

2) I've had no luck in compiling boost on any system with gcc 2.9* because of the
   template instantiation support -- so much for Mac OS X.

3) creating a single module worked fine but when I started using two modules built
   with boost I would get seg faults deep within stringstream -- something to do with a
   missing character_trait used in double conversions.  I'm guessing a compiler bug or
   I built my gcc incorrectly. I finally had to force the use of the deprecated 
   strstream in  operators.hpp.

4) I created an exception class derived from std::exception.  Generally this works but
   sometimes the exception type gets lost somehow and I end up with the python
   message 'RuntimeError: unidentifiable C++ exception' instead of my nice error
   message.  Exceptions were very unstable until I compiled gcc with the 
   --enable-sjlj-exceptions option.

5) The function overloading and cross module support are really really cool.

6) I'm not totally sure of what I am doing when I make to_python() and from_python()
   functions.  The reference class looks good but I have to study it to
   figure out what is going on with the reference counting.  The to_python(PyObject*)
   does not transfer ownership the way I thought it would for ordinary functions so I 
   ended up wrapping a PyObject* in my own TransferPyObject class with a 
   to_python(TransferPyObject) which transfers ownership.  There's probably a better way.

7) Overall I am very impressed with the ease of building a C++ extension but I am never
   quite sure what will happen when I run the extensions and I haven't stressed tested
   them.  I'm hoping gcc 3.1 solves some of my issues because solid linux support is
   required for what I am doing.  Are there any other compilers for linux which work with 
   boost/python or do other gcc users not have these problems?   I've got a few other 
   unix architectures which I will eventually test it on.

rob andre




From rwgk at yahoo.com  Tue Apr  9 22:36:42 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Tue, 9 Apr 2002 13:36:42 -0700 (PDT)
Subject: [C++-sig] my experiences with boost/python so far
In-Reply-To: <200204091942.PAA20657@neptune.pppl.gov>
Message-ID: <20020409203642.91624.qmail@web20207.mail.yahoo.com>

--- Robert Andre <randre at pppl.gov> wrote:
> 
> I am relatively new to the boost/python library so I thought I would relate 
> some of my experiences with using boost on a dual processor, 
> linux mandrake 8.0, 2.2 kernel with gcc 3.0.4:
> 
> 1) building requires a magic command.  I probably missed the documentation
> somewhere
>    but my magic command turned out to be
> 
>      jam -sBOOST_ROOT=/home/randre/cvs/boost -sTOOLS="gcc"
> -sPYTHON_ROOT="/usr/local" \
>          -sPYTHON_VERSION=2.2 -sPYTHON_LIB_PATH="/usr/local/lib/python2.2"
> 
>    If I leave off the PYTHON_LIB_PATH I get the failure,
> 
> Couldn't find Python 2.2 installation in /usr/local
> skipping Boost.Python library build
> You can configure the location of your python installation, by setting:
> PYTHON_ROOT - currently "/usr/local"
> PYTHON_VERSION - currently "2.2"
> PYTHON_INCLUDES - configured from PYTHON_ROOT, currently
> "/usr/local/include/python2.2"
> PYTHON_LIB_PATH - configured from PYTHON_ROOT, currently
> "/usr/local/lib/python2.2/config"
> ...found 402 targets...
> 
>    To test, I had to add -sGCC_ROOT_DIRECTORY=/usr/local with the target
> 'test' because
>    I use LD_LIBRARY_PATH (I know I shouldn't) and it gets reset by the test. 

I am working with Boost.Python V1 under Linux (RedHat 7.1) all the time.
The only problem is that 2.95.x exception handling is seriously buggy.
However, most extensions work if compiled with -g. gcc 3.0.4 does not
seem to have this problem.
I am also using LD_LIBRARY_PATH, both with gcc 2.95.x and 3.0.4.
I am using my own makefiles for building the extensions. See
boost/libs/python/build/linux_gcc.mak for an example.

> The pickle
>    tests always seem to fail for me.

This problem is fixed in Python 2.2.1c2 (and therefore hopefully 2.2.1 final).
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502085&group_id=5470

> 2) I've had no luck in compiling boost on any system with gcc 2.9* because of
> the
>    template instantiation support -- so much for Mac OS X.

As indicated above, in general 2.95.x should work for Boost.Python.
However, somehow Apple managed to break the OS X derivative of
the compiler. It reports "missing symbols" at the link stage.
I do not know of a fix or work-around. 

> 3) creating a single module worked fine but when I started using two modules
> built
>    with boost I would get seg faults deep within stringstream -- something to
> do with a
>    missing character_trait used in double conversions.  I'm guessing a
> compiler bug or
>    I built my gcc incorrectly. I finally had to force the use of the
> deprecated 
>    strstream in  operators.hpp.

I am puzzled. But my CVS snapshot is a couple of weeks behind...

> 4) I created an exception class derived from std::exception.  Generally this
> works but
>    sometimes the exception type gets lost somehow and I end up with the
> python
>    message 'RuntimeError: unidentifiable C++ exception' instead of my nice
> error
>    message.  Exceptions were very unstable until I compiled gcc with the 
>    --enable-sjlj-exceptions option.

I am puzzled again. gcc 3.0.4 installed with ./configure; make bootstrap
seems to work for us.
 
> 6) I'm not totally sure of what I am doing when I make to_python() and
> from_python()
>    functions.  The reference class looks good but I have to study it to
>    figure out what is going on with the reference counting.  The
> to_python(PyObject*)
>    does not transfer ownership the way I thought it would for ordinary
> functions so I 
>    ended up wrapping a PyObject* in my own TransferPyObject class with a 
>    to_python(TransferPyObject) which transfers ownership.  There's probably a
> better way.

Did you look at the examples, in particular do_it_yourself_convts.cpp?

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/




From pbienst at MIT.EDU  Wed Apr 10 17:02:42 2002
From: pbienst at MIT.EDU (Peter Bienstman)
Date: 10 Apr 2002 11:02:42 -0400
Subject: [C++-sig] V2 and icc 5.0 for Linux
Message-ID: <1018450963.3338.2.camel@hunsmac.mit.edu>

Is the Intel Compiler V5 for Linux supported with BPL V2? The tests seem
to compile fine, but for my own project, I get tons of errors like this:
(Unfortunately, it's doesn't give me a line number in my own code, so
it's hard to distill a test case)

BTW: gcc worked fine

"/home/pbienst/boost_cvs/boost/boost/bind.hpp", line 298: error: "arg"
is ambiguous
      A2 operator[] (arg<2>) const { return a2_; }
                     ^
          detected during:
            instantiation of class "boost::_bi::list4<A1, A2, A3, A4>
[with A1=boost::_bi::list_av_4<void (*)(Real={double}), boost::arg<1>,
boost::arg<2>, boost::python::default_call_policies>::B1,
A2=boost::_bi::list_av_4<void (*)(Real={double}), boost::arg<1>,
boost::arg<2>, boost::python::default_call_policies>::B2,
A3=boost::_bi::list_av_4<void (*)(Real={double}), boost::arg<1>,
boost::arg<2>, boost::python::default_call_policies>::B3,
A4=boost::_bi::list_av_4<void (*)(Real={double}),
                      boost::arg<1>, boost::arg<2>,
boost::python::default_call_policies>::B4]" at line 157 of
"/home/pbienst/boost_cvs/boost/boost/bind/bind_template.hpp"
            instantiation of class "boost::_bi::bind_t<R, F, L> [with
R=PyObject *, F=boost::python::detail::caller,
L=boost::_bi::list4<boost::_bi::list_av_4<void (*)(Real={double}),
boost::arg<1>, boost::arg<2>, boost::python::default_call_policies>::B1,
boost::_bi::list_av_4<void (*)(Real={double}), boost::arg<1>,
boost::arg<2>, boost::python::default_call_policies>::B2,
boost::_bi::list_av_4<void (*)(Real={double}), boost::arg<1>,
boost::arg<2>, boost::python::default_call_policies>::B3,
                      boost::_bi::list_av_4<void (*)(Real={double}),
boost::arg<1>, boost::arg<2>,
boost::python::default_call_policies>::B4>]" at line 1171
            instantiation of "boost::_bi::bind_t<R, F,
boost::_bi::list_av_4<A1, A2, A3, A4>::type>
boost::bind<R,F,A1,A2,A3,A4>(F, A1, A2, A3, A4) [with R=PyObject *,
F=boost::python::detail::caller, A1=void (*)(Real={double}),
A2=boost::arg<1>, A3=boost::arg<2>,
A4=boost::python::default_call_policies]" at line 25 of
"/home/pbienst/boost_cvs/boost/boost/python/make_function.hpp"
            instantiation of "boost::python::objects::function
*boost::python::make_function(F) [with F=void (*)(Real={double})]" at
line 41 of "/home/pbienst/boost_cvs/boost/boost/python/module.hpp"
            instantiation of "boost::python::module
&boost::python::module::def(const char *, Fn) [with Fn=void
(*)(Real={double})]" 

"/home/pbienst/boost_cvs/boost/boost/bind.hpp", line 298: error: cannot
overload functions distinguished by return type alone
      A2 operator[] (arg<2>) const { return a2_; }
         ^
          detected during:
            instantiation of class "boost::_bi::list4<A1, A2, A3, A4>
[with A1=boost::_bi::list_av_4<void (*)(Real={double}), boost::arg<1>,
boost::arg<2>, boost::python::default_call_policies>::B1,
A2=boost::_bi::list_av_4<void (*)(Real={double}), boost::arg<1>,
boost::arg<2>, boost::python::default_call_policies>::B2,
A3=boost::_bi::list_av_4<void (*)(Real={double}), boost::arg<1>,
boost::arg<2>, boost::python::default_call_policies>::B3,
A4=boost::_bi::list_av_4<void (*)(Real={double}),
                      boost::arg<1>, boost::arg<2>,
boost::python::default_call_policies>::B4]" at line 157 of
"/home/pbienst/boost_cvs/boost/boost/bind/bind_template.hpp"
            instantiation of class "boost::_bi::bind_t<R, F, L> [with
R=PyObject *, F=boost::python::detail::caller,
L=boost::_bi::list4<boost::_bi::list_av_4<void (*)(Real={double}),
boost::arg<1>, boost::arg<2>, boost::python::default_call_policies>::B1,
boost::_bi::list_av_4<void (*)(Real={double}), boost::arg<1>,
boost::arg<2>, boost::python::default_call_policies>::B2,
boost::_bi::list_av_4<void (*)(Real={double}), boost::arg<1>,
boost::arg<2>, boost::python::default_call_policies>::B3,
                      boost::_bi::list_av_4<void (*)(Real={double}),
boost::arg<1>, boost::arg<2>,
boost::python::default_call_policies>::B4>]" at line 1171
            instantiation of "boost::_bi::bind_t<R, F,
boost::_bi::list_av_4<A1, A2, A3, A4>::type>
boost::bind<R,F,A1,A2,A3,A4>(F, A1, A2, A3, A4) [with R=PyObject *,
F=boost::python::detail::caller, A1=void (*)(Real={double}),
A2=boost::arg<1>, A3=boost::arg<2>,
A4=boost::python::default_call_policies]" at line 25 of
"/home/pbienst/boost_cvs/boost/boost/python/make_function.hpp"
            instantiation of "boost::python::objects::function
*boost::python::make_function(F) [with F=void (*)(Real={double})]" at
line 41 of "/home/pbienst/boost_cvs/boost/boost/python/module.hpp"
            instantiation of "boost::python::module
&boost::python::module::def(const char *, Fn) [with Fn=void
(*)(Real={double})]"  







From david.abrahams at rcn.com  Wed Apr 10 17:20:55 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 10 Apr 2002 10:20:55 -0500
Subject: [C++-sig] V2 and icc 5.0 for Linux
References: <1018450963.3338.2.camel@hunsmac.mit.edu>
Message-ID: <042a01c1e0a3$8904f8a0$6801a8c0@boostconsulting.com>

----- Original Message -----
From: "Peter Bienstman" <pbienst at MIT.EDU>
To: <c++-sig at python.org>
Sent: Wednesday, April 10, 2002 10:02 AM
Subject: [C++-sig] V2 and icc 5.0 for Linux


> Is the Intel Compiler V5 for Linux supported with BPL V2?

> The tests seem
> to compile fine, but for my own project, I get tons of errors like
this:
> (Unfortunately, it's doesn't give me a line number in my own code, so
> it's hard to distill a test case)

Hmm, I've been testing it with Intel 5 for Windows; I haven't installed
Intel 5 on my Linux box yet. However, if as you say all the test cases
compile fine, I doubt that would make much difference. If you have any
reproducible case (even a big one) it might help. You might also ask
Peter Dimov if he's seen issues with bind and this compiler.

Just out of curiosity, do you have a template called "arg" defined
somewhere? It's possible a bug in the compiler causes it to collide with
boost::arg<>.

-Dave

------

BTW: gcc worked fine

"/home/pbienst/boost_cvs/boost/boost/bind.hpp", line 298: error: "arg"
is ambiguous
      A2 operator[] (arg<2>) const { return a2_; }
                     ^
          detected during:
            instantiation of class "boost::_bi::list4<A1, A2, A3, A4>
[with A1=boost::_bi::list_av_4<void (*)(Real={double}), boost::arg<1>,
boost::arg<2>, boost::python::default_call_policies>::B1,
A2=boost::_bi::list_av_4<void (*)(Real={double}), boost::arg<1>,
boost::arg<2>, boost::python::default_call_policies>::B2,
A3=boost::_bi::list_av_4<void (*)(Real={double}), boost::arg<1>,
boost::arg<2>, boost::python::default_call_policies>::B3,
A4=boost::_bi::list_av_4<void (*)(Real={double}),
                      boost::arg<1>, boost::arg<2>,
boost::python::default_call_policies>::B4]" at line 157 of
"/home/pbienst/boost_cvs/boost/boost/bind/bind_template.hpp"
            instantiation of class "boost::_bi::bind_t<R, F, L> [with
R=PyObject *, F=boost::python::detail::caller,
L=boost::_bi::list4<boost::_bi::list_av_4<void (*)(Real={double}),
boost::arg<1>, boost::arg<2>, boost::python::default_call_policies>::B1,
boost::_bi::list_av_4<void (*)(Real={double}), boost::arg<1>,
boost::arg<2>, boost::python::default_call_policies>::B2,
boost::_bi::list_av_4<void (*)(Real={double}), boost::arg<1>,
boost::arg<2>, boost::python::default_call_policies>::B3,
                      boost::_bi::list_av_4<void (*)(Real={double}),
boost::arg<1>, boost::arg<2>,
boost::python::default_call_policies>::B4>]" at line 1171
            instantiation of "boost::_bi::bind_t<R, F,
boost::_bi::list_av_4<A1, A2, A3, A4>::type>
boost::bind<R,F,A1,A2,A3,A4>(F, A1, A2, A3, A4) [with R=PyObject *,
F=boost::python::detail::caller, A1=void (*)(Real={double}),
A2=boost::arg<1>, A3=boost::arg<2>,
A4=boost::python::default_call_policies]" at line 25 of
"/home/pbienst/boost_cvs/boost/boost/python/make_function.hpp"
            instantiation of "boost::python::objects::function
*boost::python::make_function(F) [with F=void (*)(Real={double})]" at
line 41 of "/home/pbienst/boost_cvs/boost/boost/python/module.hpp"
            instantiation of "boost::python::module
&boost::python::module::def(const char *, Fn) [with Fn=void
(*)(Real={double})]"

"/home/pbienst/boost_cvs/boost/boost/bind.hpp", line 298: error: cannot
overload functions distinguished by return type alone
      A2 operator[] (arg<2>) const { return a2_; }
         ^
          detected during:
            instantiation of class "boost::_bi::list4<A1, A2, A3, A4>
[with A1=boost::_bi::list_av_4<void (*)(Real={double}), boost::arg<1>,
boost::arg<2>, boost::python::default_call_policies>::B1,
A2=boost::_bi::list_av_4<void (*)(Real={double}), boost::arg<1>,
boost::arg<2>, boost::python::default_call_policies>::B2,
A3=boost::_bi::list_av_4<void (*)(Real={double}), boost::arg<1>,
boost::arg<2>, boost::python::default_call_policies>::B3,
A4=boost::_bi::list_av_4<void (*)(Real={double}),
                      boost::arg<1>, boost::arg<2>,
boost::python::default_call_policies>::B4]" at line 157 of
"/home/pbienst/boost_cvs/boost/boost/bind/bind_template.hpp"
            instantiation of class "boost::_bi::bind_t<R, F, L> [with
R=PyObject *, F=boost::python::detail::caller,
L=boost::_bi::list4<boost::_bi::list_av_4<void (*)(Real={double}),
boost::arg<1>, boost::arg<2>, boost::python::default_call_policies>::B1,
boost::_bi::list_av_4<void (*)(Real={double}), boost::arg<1>,
boost::arg<2>, boost::python::default_call_policies>::B2,
boost::_bi::list_av_4<void (*)(Real={double}), boost::arg<1>,
boost::arg<2>, boost::python::default_call_policies>::B3,
                      boost::_bi::list_av_4<void (*)(Real={double}),
boost::arg<1>, boost::arg<2>,
boost::python::default_call_policies>::B4>]" at line 1171
            instantiation of "boost::_bi::bind_t<R, F,
boost::_bi::list_av_4<A1, A2, A3, A4>::type>
boost::bind<R,F,A1,A2,A3,A4>(F, A1, A2, A3, A4) [with R=PyObject *,
F=boost::python::detail::caller, A1=void (*)(Real={double}),
A2=boost::arg<1>, A3=boost::arg<2>,
A4=boost::python::default_call_policies]" at line 25 of
"/home/pbienst/boost_cvs/boost/boost/python/make_function.hpp"
            instantiation of "boost::python::objects::function
*boost::python::make_function(F) [with F=void (*)(Real={double})]" at
line 41 of "/home/pbienst/boost_cvs/boost/boost/python/module.hpp"
            instantiation of "boost::python::module
&boost::python::module::def(const char *, Fn) [with Fn=void
(*)(Real={double})]"









From david.abrahams at rcn.com  Wed Apr 10 19:38:50 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 10 Apr 2002 12:38:50 -0500
Subject: [C++-sig] my experiences with boost/python so far
References: <200204091942.PAA20657@neptune.pppl.gov>
Message-ID: <04bf01c1e0b6$9b60b300$6801a8c0@boostconsulting.com>

----- Original Message -----
From: "Robert Andre" <randre at pppl.gov>


>
> I am relatively new to the boost/python library so I thought I would
relate
> some of my experiences with using boost on a dual processor,
> linux mandrake 8.0, 2.2 kernel with gcc 3.0.4:
>
> 1) building requires a magic command.  I probably missed the
documentation somewhere

Probably not; we're running behind in that department.

>    but my magic command turned out to be
>
>





jam -sBOOST_ROOT=/home/randre/cvs/boost -sTOOLS="gcc" -sPYTHON_ROOT="/us
r/local" \
>          -sPYTHON_VERSION=2.2 -sPYTHON_LIB_PATH="/usr/local/lib/python
2.2"
>
>    If I leave off the PYTHON_LIB_PATH I get the failure,
>
> Couldn't find Python 2.2 installation in /usr/local
> skipping Boost.Python library build
> You can configure the location of your python installation, by
setting:
> PYTHON_ROOT - currently "/usr/local"
> PYTHON_VERSION - currently "2.2"
> PYTHON_INCLUDES - configured from PYTHON_ROOT, currently
"/usr/local/include/python2.2"
> PYTHON_LIB_PATH - configured from PYTHON_ROOT, currently
"/usr/local/lib/python2.2/config"
> ...found 402 targets...

Hmm. I may have to have another look at the defaults. Thanks for
reporting this.

>    To test, I had to add -sGCC_ROOT_DIRECTORY=/usr/local with the
target 'test' because
>    I use LD_LIBRARY_PATH (I know I shouldn't)

Why not?

>    and it gets reset by the test.

Hmm, it is supposed to get *extended* by the test.

>    The pickle
>    tests always seem to fail for me.
>
>    Is there a way to see what  gcc-C++-action  and  gcc-Link-action
are doing?

Yes, add -d+2 to your command-line, before the first target.

> 2) I've had no luck in compiling boost on any system with gcc 2.9*
because of the
>    template instantiation support -- so much for Mac OS X.

Weird; it's working for me with MinGW 2.95.3
I just checked in some changes last night which should make that
healthier, though. Please try again at your convenience.

> 3) creating a single module worked fine but when I started using two
modules built
>    with boost I would get seg faults deep within stringstream --
something to do with a
>    missing character_trait used in double conversions.  I'm guessing a
compiler bug or
>    I built my gcc incorrectly. I finally had to force the use of the
deprecated
>    strstream in  operators.hpp.

This one doesn't sound like it has anything to do with Boost.Python.

> 4) I created an exception class derived from std::exception.
Generally this works but
>    sometimes the exception type gets lost somehow and I end up with
the python
>    message 'RuntimeError: unidentifiable C++ exception' instead of my
nice error
>    message.  Exceptions were very unstable until I compiled gcc with
the
>    --enable-sjlj-exceptions option.

Exception support in GCCs prior to 3.0.1 was notoriously erratic.

> 5) The function overloading and cross module support are really really
cool.
>
> 6) I'm not totally sure of what I am doing when I make to_python() and
from_python()
>    functions.  The reference class looks good but I have to study it
to
>    figure out what is going on with the reference counting.  The
to_python(PyObject*)
>    does not transfer ownership the way I thought it would for ordinary
functions so I
>    ended up wrapping a PyObject* in my own TransferPyObject class with
a
>    to_python(TransferPyObject) which transfers ownership.  There's
probably a better way.

Boost.Python v2 will be smoother ;-)

> 7) Overall I am very impressed with the ease of building a C++
extension but I am never
>    quite sure what will happen when I run the extensions and I haven't
stressed tested
>    them.  I'm hoping gcc 3.1 solves some of my issues because solid
linux support is
>    required for what I am doing.  Are there any other compilers for
linux which work with
>    boost/python or do other gcc users not have these problems?   I've
got a few other
>    unix architectures which I will eventually test it on.

Ralf has been using v1 on a bunch of different Unices. We've been
testing v2 on Linux and OSF with GCC, KCC, and Compaq Tru64 CXX (several
versions).

Thanks for using Boost.Python!

-Dave





From pbienst at MIT.EDU  Wed Apr 10 19:51:09 2002
From: pbienst at MIT.EDU (Peter Bienstman)
Date: 10 Apr 2002 13:51:09 -0400
Subject: [C++-sig] V2 and icc 5.0 for Linux
In-Reply-To: <042a01c1e0a3$8904f8a0$6801a8c0@boostconsulting.com>
References: <1018450963.3338.2.camel@hunsmac.mit.edu> 
	<042a01c1e0a3$8904f8a0$6801a8c0@boostconsulting.com>
Message-ID: <1018461069.5125.0.camel@hunsmac.mit.edu>

> Just out of curiosity, do you have a template called "arg" defined
> somewhere? It's possible a bug in the compiler causes it to collide with
> boost::arg<>.

After some reading through the preprocessed source, it turns out that
the Intel header files for <complex> define just such a template.

That'll teach me to write 'using namespace std;' without thinking....

Thanks,

Peter





From RaoulGough at yahoo.co.uk  Wed Apr 10 18:46:16 2002
From: RaoulGough at yahoo.co.uk (Raoul Gough)
Date: Wed, 10 Apr 2002 17:46:16 +0100
Subject: [C++-sig] Re: my experiences with boost/python so far
References: <20020410160006.12722.43476.Mailman@mail.python.org>
Message-ID: <00bb01c1e0c2$4f03f060$0100a8c0@albert>

> Date: Tue, 9 Apr 2002 15:42:39 -0400 (EDT)
> From: Robert Andre <randre at pppl.gov>

[snip]
> 3) creating a single module worked fine but when I started using two
modules built
>    with boost I would get seg faults deep within stringstream -- something
to do with a
>    missing character_trait used in double conversions.  I'm guessing a
compiler bug or
>    I built my gcc incorrectly. I finally had to force the use of the
deprecated
>    strstream in  operators.hpp.

That sounds slightly familiar to me. Maybe my experiences will give you some
ideas:

I use the STLport library and mingw (with gcc 2.95.3-5) and started getting
problems with ostream numeric conversions. It turned out to be very simple -
I had switched to compiling the client code with --ansi, which among other
things eliminates support for long long. Unfortunately, I had compiled the
STLport libraries *without* --ansi, so they did have long long support. The
result was that some object files thought there were n numeric output
methods, and the other modules thought there were n+2. This caused a
mismatch in a virtual function table lookup within the iostreams numeric
formatting code, and it took me a while to figure out why it had happened.

Other than that, I once got into trouble with a --fvtable-thunks option
mismatch, which (IIRC) initially showed up somewhere in an uninitialised
locale being used. The joys of keeping multiple versions of a library around
:-)

Regards,
Raoul Gough.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com





From Peter.Bienstman at rug.ac.be  Thu Apr 11 15:52:54 2002
From: Peter.Bienstman at rug.ac.be (Peter Bienstman)
Date: Thu, 11 Apr 2002 09:52:54 -0400
Subject: [C++-sig] V2 jam problem
Message-ID: <200204110953.03413.Peter.Bienstman@rug.ac.be>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OK, this should be really easy:

I'm trying to build V2 BPL under Windows using Intel beta 6 on top of VS .NET 
with Python 2.2 from ActiveState

This is my jam command:

jam -d+2 -sTOOLS="intel-win32" -sBUILD=debug -sBOOST_ROOT=d:/boost_cvs/boost/ 
- -sPYTHON_VERSION=2.2 -sPYTHON_ROOT=c:/progra~1/python22

Which fail like this

D:\boost_cvs\boost\libs\python>jam -d+2 -sTOOLS="intel-win32" -sBUILD=debug 
- -sBOOST_ROOT=d:/boost_cvs/boost/ -sPYTHON_VERSION=2.2 
- -sPYTHON_ROOT=c:/progra~1/python22
don't know how to make <python-library@>python22.lib


     /Zm400 -nologo -GX -c  -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_V2 
- -DBOOST
_PYTHON_SOURCE  /Z7 /Od /Ob0 /GX /GR /MDd   -I"..\..\libs\python" -I"." 
- -I"d:\bo
ost_cvs\boost" -I"c:\progra~1\python22\include" -I"c:\progra~1\python22\PC"  
- -I"
C:\Program\include" -I"Files\Microsoft\include" -I"Visual\include" 
- -I"Studio\inc
lude" -I".NET\VC7\include" -I"../include"   
- -Fo"..\..\libs\python\bin\bpl.dll\in
tel-win32\debug\runtime-link-dynamic\from_python.obj"  
- -Tp"src/converter\from_py
thon.cpp"

...

Because /Zm100 is of course not a valid executable name.

Any idea?

Thanks,

Peter



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8tZU/4dgPAIjyquoRAlDHAKDewnFBS7bXP3mHYeQwTNN4pXIK9gCg+1/+
a5+RafUgAVo5JQDJFQ7YCfM=
=CBqn
-----END PGP SIGNATURE-----





From david.abrahams at rcn.com  Thu Apr 11 16:16:45 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 11 Apr 2002 09:16:45 -0500
Subject: [C++-sig] V2 jam problem
References: <200204110953.03413.Peter.Bienstman@rug.ac.be>
Message-ID: <00ed01c1e164$15fe2180$6801a8c0@boostconsulting.com>

Pleae update tools/build/python.jam and try again.

I am doing the following to configure my intel compiler running atop
vc7:

set INTEL_LICENSE_FILE=c:\tools\Intel\Licenses
set INTEL_PATH=c:\tools\Intel\Compiler60\ia32
set INTEL_BASE_MSVC_TOOLSET=vc7
set VC7_ROOT=c:\tools\vc7

HTH,
Dave

----- Original Message -----
From: "Peter Bienstman" <Peter.Bienstman at rug.ac.be>
To: <c++-sig at python.org>
Sent: Thursday, April 11, 2002 8:52 AM
Subject: [C++-sig] V2 jam problem


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OK, this should be really easy:

I'm trying to build V2 BPL under Windows using Intel beta 6 on top of VS
.NET
with Python 2.2 from ActiveState

This is my jam command:

jam -d+2 -sTOOLS="intel-win32" -sBUILD=debug -sBOOST_ROOT=d:/boost_cvs/b
oost/
- -sPYTHON_VERSION=2.2 -sPYTHON_ROOT=c:/progra~1/python22

Which fail like this

D:\boost_cvs\boost\libs\python>jam -d+2 -sTOOLS="intel-win32" -sBUILD=de
bug
- -sBOOST_ROOT=d:/boost_cvs/boost/ -sPYTHON_VERSION=2.2
- -sPYTHON_ROOT=c:/progra~1/python22
don't know how to make <python-library@>python22.lib


     /Zm400 -nologo -GX -c  -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_V2
- -DBOOST
_PYTHON_SOURCE  /Z7 /Od /Ob0 /GX /GR /MDd   -I"..\..\libs\python" -I"."
- -I"d:\bo
ost_cvs\boost" -I"c:\progra~1\python22\include" -I"c:\progra~1\python22\
PC"
- -I"
C:\Program\include" -I"Files\Microsoft\include" -I"Visual\include"
- -I"Studio\inc
lude" -I".NET\VC7\include" -I"../include"
- -Fo"..\..\libs\python\bin\bpl.dll\in
tel-win32\debug\runtime-link-dynamic\from_python.obj"
- -Tp"src/converter\from_py
thon.cpp"

...

Because /Zm100 is of course not a valid executable name.

Any idea?

Thanks,

Peter



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8tZU/4dgPAIjyquoRAlDHAKDewnFBS7bXP3mHYeQwTNN4pXIK9gCg+1/+
a5+RafUgAVo5JQDJFQ7YCfM=
=CBqn
-----END PGP SIGNATURE-----



_______________________________________________
C++-sig mailing list
C++-sig at python.org
http://mail.python.org/mailman/listinfo/c++-sig





From Peter.Bienstman at rug.ac.be  Fri Apr 12 00:54:39 2002
From: Peter.Bienstman at rug.ac.be (Peter Bienstman)
Date: Fri, 12 Apr 2002 00:54:39 +0200 (MEST)
Subject: [C++-sig] V2 jam problem
In-Reply-To: <00ed01c1e164$15fe2180$6801a8c0@boostconsulting.com>
Message-ID: <Pine.GSO.4.31.0204120044510.19043-100000@allserv.rug.ac.be>

I updated from CVS and tried

set INTEL_LICENSE_FILE=C:\Progra~1\Intel\Licenses
set INTEL_PATH=C:\Progra~1\Intel\Compiler60\IA32
set INTEL_BASE_MSVC_TOOLSET=vc7
set VC7_ROOT=C:\Progra~1\Micros~1.NET\Vc7

jam -d+2 -sTOOLS="intel-win32" -sBUILD=debug
-sBOOST_ROOT=D:\boost_cvs\boost\ -sPYTHON_VERSION=2.2
-sPYTHON_ROOT=C:\progra~1\python22

This time, I get:

    "C:\Progra~1\Intel\Compiler60\IA32/bin/icl"  /Zm400 -nologo -GX -c
-DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_V2 -DBOOST_PYTHON_SOURCE  /Z7
/Od /Ob0 /GX /GR /MDd   -I"..\..\libs\python" -I"." -I"D:\boost_cvs\boost"
-I"C:\progra~1\python22\include" -I"C:\progra~1\python22\PC"
-I"C:\Program\include" -I"Files\Microsoft\include" -I"Visual\include"
-I"Studio\include" -I".NET\VC7\include" -I"../include"
-Fo"..\..\libs\python\bin\bpl.dll\intel-win32\debug\runtime-link-dynamic\from_python.obj"
-Tp"src/converter\from_python.cpp"

The input line is too long



Closer, but not quite there yet. Note how it's having trouble with the
spaces in the path to the VC headers.

Peter

On Thu, 11 Apr 2002, David Abrahams wrote:

> Pleae update tools/build/python.jam and try again.
>
> I am doing the following to configure my intel compiler running atop
> vc7:
>
> set INTEL_LICENSE_FILE=c:\tools\Intel\Licenses
> set INTEL_PATH=c:\tools\Intel\Compiler60\ia32
> set INTEL_BASE_MSVC_TOOLSET=vc7
> set VC7_ROOT=c:\tools\vc7
>
> HTH,
> Dave
>
> ----- Original Message -----
> From: "Peter Bienstman" <Peter.Bienstman at rug.ac.be>
> To: <c++-sig at python.org>
> Sent: Thursday, April 11, 2002 8:52 AM
> Subject: [C++-sig] V2 jam problem
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> OK, this should be really easy:
>
> I'm trying to build V2 BPL under Windows using Intel beta 6 on top of VS
> .NET
> with Python 2.2 from ActiveState
>
> This is my jam command:
>
> jam -d+2 -sTOOLS="intel-win32" -sBUILD=debug -sBOOST_ROOT=d:/boost_cvs/b
> oost/
> - -sPYTHON_VERSION=2.2 -sPYTHON_ROOT=c:/progra~1/python22
>
> Which fail like this
>
> D:\boost_cvs\boost\libs\python>jam -d+2 -sTOOLS="intel-win32" -sBUILD=de
> bug
> - -sBOOST_ROOT=d:/boost_cvs/boost/ -sPYTHON_VERSION=2.2
> - -sPYTHON_ROOT=c:/progra~1/python22
> don't know how to make <python-library@>python22.lib
>
>
>      /Zm400 -nologo -GX -c  -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_V2
> - -DBOOST
> _PYTHON_SOURCE  /Z7 /Od /Ob0 /GX /GR /MDd   -I"..\..\libs\python" -I"."
> - -I"d:\bo
> ost_cvs\boost" -I"c:\progra~1\python22\include" -I"c:\progra~1\python22\
> PC"
> - -I"
> C:\Program\include" -I"Files\Microsoft\include" -I"Visual\include"
> - -I"Studio\inc
> lude" -I".NET\VC7\include" -I"../include"
> - -Fo"..\..\libs\python\bin\bpl.dll\in
> tel-win32\debug\runtime-link-dynamic\from_python.obj"
> - -Tp"src/converter\from_py
> thon.cpp"
>
> ...
>
> Because /Zm100 is of course not a valid executable name.
>
> Any idea?
>
> Thanks,
>
> Peter
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE8tZU/4dgPAIjyquoRAlDHAKDewnFBS7bXP3mHYeQwTNN4pXIK9gCg+1/+
> a5+RafUgAVo5JQDJFQ7YCfM=
> =CBqn
> -----END PGP SIGNATURE-----
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>





From david.abrahams at rcn.com  Fri Apr 12 07:22:21 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 12 Apr 2002 00:22:21 -0500
Subject: [C++-sig] [ANN] arbitrary arity support / new callback interface
Message-ID: <063701c1e1e2$082474f0$6801a8c0@boostconsulting.com>

Boost.Python v2 has been updated to support arbitrary numbers of
function arguments. Due to limitations of the EDG preprocessor (it's
*slow*), the default limit is 10 arguments on EDG-based compilers, and
12 arguments elsewhere (the "this" pointer counts as an argument in
member functions).

If you need support for more arguments, you can #define
BOOST_PYTHON_MAX_ARITY to whatever number > 10 you need. Be aware that
with most EDG-based compilers, increasing the max arity in this fashion
will slow compilation down a lot. A number of new files
(boost/python/preprocessed/*.hpp) contain expanded versions of the
functions for up to 10 arguments; these can be regenerated using the
preprocessor to get support for more without incurring a speed penalty.

The interface for calling back into Python (e.g. in virtual functions)
has changed a bit: see libs/python/test/virtual_functions.cpp and
libs/python/test/callbacks.cpp for examples. Basically, instead of
writing:

    returning<ReturnType>::call_method(self, "method_name", arg1, arg2,
arg3...)
  or
    returning<ReturnType>::call(callable, arg1, arg2, arg3...)

You now write:

    call_method<ReturnType>(self, "method_name", arg1, arg2, arg3...)
  or
    call<ReturnType>(callable, arg1, arg2, arg3...)

[If ReturnType is void, it may be ommitted.]

Unfortunately, gcc-2.95.3 (MinGW, but likely on Linux also) generates
incorrect exception-handling code for this construct, so the library's
checking for your erroneous code may not work so well with that
compiler. I'll be looking into alternatives which the compiler will be
happier with. In the meantime, just don't make mistakes ;-)

Regards,
Dave


+---------------------------------------------------------------+
                  David Abrahams
      C++ Booster (http://www.boost.org)               O__  ==
      Pythonista (http://www.python.org)              c/ /'_ ==
  resume: http://users.rcn.com/abrahams/resume.html  (*) \(*) ==
          email: david.abrahams at rcn.com
+---------------------------------------------------------------+





From toon.knapen at si-lab.org  Fri Apr 12 10:37:33 2002
From: toon.knapen at si-lab.org (Toon Knapen)
Date: Fri, 12 Apr 2002 10:37:33 +0200
Subject: [C++-sig] [ANN] arbitrary arity support / new callback interface
In-Reply-To: <063701c1e1e2$082474f0$6801a8c0@boostconsulting.com>
References: <063701c1e1e2$082474f0$6801a8c0@boostconsulting.com>
Message-ID: <E16vwer-0001YV-00@bigglesworth.mail.be.easynet.net>

On Friday 12 April 2002 07:22, David wrote:

[snip]
>Unfortunately, gcc-2.95.3 (MinGW, but likely on Linux also) generates
>incorrect exception-handling code for this construct, so the library's
>checking for your erroneous code may not work so well with that
>compiler. I'll be looking into alternatives which the compiler will be
>happier with. In the meantime, just don't make mistakes ;-)

I figure it's not really worth spending too much time supporting gcc-2.95.3.
gcc-3.0.4 is almost on the same level as 2.95.3 so it will become obsolete 
soon. (just worried about your load-level ;)

toon




From Peter.Bienstman at rug.ac.be  Fri Apr 12 15:09:31 2002
From: Peter.Bienstman at rug.ac.be (Peter Bienstman)
Date: Fri, 12 Apr 2002 15:09:31 +0200 (MEST)
Subject: [C++-sig] V2 windows build problems update
Message-ID: <Pine.GSO.4.31.0204121503150.28596-100000@allserv.rug.ac.be>

OK, if I manaully create a build script by editing and correcting the
output from jam, I now get as far as the linking stage which fails like
this:


D:\boost_cvs\boost\libs\python>xilink  /nologo /INCREMENTAL:NO  /DEBUG
/DLL
/out:"..\..\libs\python\bin\bpl.dll\intel-win32\debug\runtime-link-dynamic\bpl.dll"
/IMPLIB:..\..\libs\python\bin\bpl.dll\intel-win32\debug\runtime-link-dynamic\bpl.lib
/LIBPATH:C:\progra~1\python22\libs
"..\..\libs\python\bin\bpl.dll\intel-win32\debug\runtime-link-dynamic\*.obj"
C:\progra~1\python22\libs\python22.lib
LINK : fatal error LNK1104: cannot open file 'libmmdd.lib'

This library is nowhere to be found on my system...

Peter






From pearu at cens.ioc.ee  Fri Apr 12 15:17:12 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Fri, 12 Apr 2002 16:17:12 +0300 (EEST)
Subject: [C++-sig] [ANN] arbitrary arity support / new callback interface
In-Reply-To: <E16vwer-0001YV-00@bigglesworth.mail.be.easynet.net>
Message-ID: <Pine.LNX.4.21.0204121600390.28076-100000@cens.ioc.ee>

On Fri, 12 Apr 2002, Toon Knapen wrote:

> On Friday 12 April 2002 07:22, David wrote:
> 
> [snip]
> >Unfortunately, gcc-2.95.3 (MinGW, but likely on Linux also) generates
> >incorrect exception-handling code for this construct, so the library's
> >checking for your erroneous code may not work so well with that
> >compiler. I'll be looking into alternatives which the compiler will be
> >happier with. In the meantime, just don't make mistakes ;-)
> 
> I figure it's not really worth spending too much time supporting gcc-2.95.3.
> gcc-3.0.4 is almost on the same level as 2.95.3 so it will become obsolete 
> soon. (just worried about your load-level ;)

Note that some of us (numeric crunchers) are stuck to 2.95.x because, for
example, gcc-3.x.x built ATLAS library is known to be slower to when using
2.95.x and therefore 2.95.x compiler will not be obsolete for some time.

I am far from asking full support for gcc-2.95.x of BPL as on can always
keep two compilers around for different software but it is a bit
inconvinient...

I am looking forward to use BPL V2, I have had very good experience
with BPL V1.

Thanks,
	Pearu






From toon.knapen at si-lab.org  Fri Apr 12 15:46:38 2002
From: toon.knapen at si-lab.org (Toon Knapen)
Date: Fri, 12 Apr 2002 15:46:38 +0200
Subject: [C++-sig] [ANN] arbitrary arity support / new callback interface
Message-ID: <E16w1Tz-0004O8-00@bigglesworth.mail.be.easynet.net>

> Note that some of us (numeric crunchers) are stuck to 2.95.x because, for
> example, gcc-3.x.x built ATLAS library is known to be slower to when using
> 2.95.x and therefore 2.95.x compiler will not be obsolete for some time.
I did not know it had such a big effect on ATLAS (thanks for the info). 
gcc-3.0.3 should be overall faster (e.g. due to type-based alias analysis), 
but still is less performant on loop-unrolling etc. In my last simple test, 
gcc-3.0.4 almost obtained similar performance as 2.95.3 on numerical codes 
to. So I guess 3.1 should definitly (hopefully) make it obsolete.
BTW, since Intel is stopping the KAI Compiler, Los Alomos apparantly is 
heavily interested again in gcc which can only boost gcc's performance (heard 
it on the POOMA ml)

> I am far from asking full support for gcc-2.95.x of BPL as on can always
> keep two compilers around for different software but it is a bit
> inconvinient...
I also have 2.95.3 still around for numerical performance reasons. But for 
this area, exception handling is'nt super important anyway.

t




From Peter.Bienstman at rug.ac.be  Fri Apr 12 16:07:43 2002
From: Peter.Bienstman at rug.ac.be (Peter Bienstman)
Date: Fri, 12 Apr 2002 16:07:43 +0200 (MEST)
Subject: [C++-sig] V2 dllimport problems
Message-ID: <Pine.GSO.4.31.0204121604570.8747-100000@allserv.rug.ac.be>

Trying to compile my code (Intel V6) under Windows fails with

D:\\boost_cvs\\boost\\libs/python/src/converter/builtin_converters.cpp(235):
error #698: the modifier "dllimport" is not allowed on this declaration
  BOOST_PYTHON_DECL PyObject* do_call_to_python(char x)
                              ^

D:\\boost_cvs\\boost\\libs/python/src/converter/builtin_converters.cpp(240):
error #698: the modifier "dllimport" is not allowed on this declaration
  BOOST_PYTHON_DECL PyObject* do_call_to_python(char const* x)
                              ^

D:\\boost_cvs\\boost\\libs/python/src/converter/builtin_converters.cpp(245):
error #698: the modifier "dllimport" is not allowed on this declaration
  BOOST_PYTHON_DECL PyObject* do_call_to_python(PyObject* x)
                              ^

D:\\boost_cvs\\boost\\libs/python/src/converter/builtin_converters.cpp(250):
error #698: the modifier "dllimport" is not allowed on this declaration
  BOOST_PYTHON_DECL PyObject* do_callback_to_python(PyObject* x)
                              ^
Note that I'm building my code outside of jam. Do I perhaps need to define
additional macro's?

Thanks,

Peter





From david.abrahams at rcn.com  Fri Apr 12 16:20:26 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 12 Apr 2002 09:20:26 -0500
Subject: [C++-sig] V2 jam problem
References: <Pine.GSO.4.31.0204120044510.19043-100000@allserv.rug.ac.be>
Message-ID: <066001c1e22d$34223fb0$6801a8c0@boostconsulting.com>

----- Original Message -----
From: "Peter Bienstman" <Peter.Bienstman at rug.ac.be>


>
> I updated from CVS and tried
>
> set INTEL_LICENSE_FILE=C:\Progra~1\Intel\Licenses
> set INTEL_PATH=C:\Progra~1\Intel\Compiler60\IA32
> set INTEL_BASE_MSVC_TOOLSET=vc7
> set VC7_ROOT=C:\Progra~1\Micros~1.NET\Vc7
>
> jam -d+2 -sTOOLS="intel-win32" -sBUILD=debug
> -sBOOST_ROOT=D:\boost_cvs\boost\ -sPYTHON_VERSION=2.2
> -sPYTHON_ROOT=C:\progra~1\python22
>
> This time, I get:
>
>     "C:\Progra~1\Intel\Compiler60\IA32/bin/icl"  /Zm400 -nologo -GX -c
> -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_V2 -DBOOST_PYTHON_SOURCE
/Z7
> /Od /Ob0 /GX /GR
/MDd   -I"..\..\libs\python" -I"." -I"D:\boost_cvs\boost"
> -I"C:\progra~1\python22\include" -I"C:\progra~1\python22\PC"
> -I"C:\Program\include" -I"Files\Microsoft\include" -I"Visual\include"
> -I"Studio\include" -I".NET\VC7\include" -I"../include"
> -Fo"..\..\libs\python\bin\bpl.dll\intel-win32\debug\runtime-link-dynam
ic\from_python.obj"
> -Tp"src/converter\from_python.cpp"
>
> The input line is too long

> Closer, but not quite there yet. Note how it's having trouble with the
> spaces in the path to the VC headers.

That's very strange. Did you update everything, including the
tools/build directory? I tried the very same test and everything came
out as expected. Please try again with the Jam executable at
http://groups.yahoo.com/group/jamboost/files/jam.exe.

If that doesn't work I'm going to ask you to add -d+5 to your command
line and send me the output (compressed, please!)

-Dave





From david.abrahams at rcn.com  Fri Apr 12 16:28:53 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 12 Apr 2002 09:28:53 -0500
Subject: [C++-sig] [ANN] arbitrary arity support / new callback interface
References: <063701c1e1e2$082474f0$6801a8c0@boostconsulting.com> <E16vwer-0001YV-00@bigglesworth.mail.be.easynet.net>
Message-ID: <069c01c1e22e$9b33a2b0$6801a8c0@boostconsulting.com>

----- Original Message -----
From: "Toon Knapen" <toon.knapen at si-lab.org>
>
> I figure it's not really worth spending too much time supporting
gcc-2.95.3.
> gcc-3.0.4 is almost on the same level as 2.95.3 so it will become
obsolete
> soon. (just worried about your load-level ;)

That's very nice of you. However, 2.95.x is still the default in MANY
installations, including cygwin and mingw for what it's worth.

-Dave






From david.abrahams at rcn.com  Fri Apr 12 17:17:10 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 12 Apr 2002 10:17:10 -0500
Subject: [C++-sig] [ANN] arbitrary arity support / new callback interface
References: <E16w1Tz-0004O8-00@bigglesworth.mail.be.easynet.net>
Message-ID: <072a01c1e235$b038efb0$6801a8c0@boostconsulting.com>

----- Original Message -----
From: "Toon Knapen" <toon.knapen at si-lab.org>

> > I am far from asking full support for gcc-2.95.x of BPL as on can
always
> > keep two compilers around for different software but it is a bit
> > inconvinient...
> I also have 2.95.3 still around for numerical performance reasons. But
for
> this area, exception handling is'nt super important anyway.

It gets important at the Python interface boundary. When Python errors
occur, they are propagated through C++ as exceptions. My position is
that Python users shouldn't have to worry about crashing, even if they
misuse things.

-Dave






From david.abrahams at rcn.com  Fri Apr 12 17:22:26 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 12 Apr 2002 10:22:26 -0500
Subject: [C++-sig] V2 dllimport problems
References: <Pine.GSO.4.31.0204121604570.8747-100000@allserv.rug.ac.be>
Message-ID: <074d01c1e236$63c571c0$6801a8c0@boostconsulting.com>

I think perhaps that we need to get Jam working for you ;-)

You may need BOOST_PYTHON_DYNAMIC_LIB

-Dave

----- Original Message -----
From: "Peter Bienstman" <Peter.Bienstman at rug.ac.be>
To: <c++-sig at python.org>
Sent: Friday, April 12, 2002 9:07 AM
Subject: [C++-sig] V2 dllimport problems


> Trying to compile my code (Intel V6) under Windows fails with
>
>
D:\\boost_cvs\\boost\\libs/python/src/converter/builtin_converters.cpp(2
35):
> error #698: the modifier "dllimport" is not allowed on this
declaration
>   BOOST_PYTHON_DECL PyObject* do_call_to_python(char x)
>                               ^
>
>
D:\\boost_cvs\\boost\\libs/python/src/converter/builtin_converters.cpp(2
40):
> error #698: the modifier "dllimport" is not allowed on this
declaration
>   BOOST_PYTHON_DECL PyObject* do_call_to_python(char const* x)
>                               ^
>
>
D:\\boost_cvs\\boost\\libs/python/src/converter/builtin_converters.cpp(2
45):
> error #698: the modifier "dllimport" is not allowed on this
declaration
>   BOOST_PYTHON_DECL PyObject* do_call_to_python(PyObject* x)
>                               ^
>
>
D:\\boost_cvs\\boost\\libs/python/src/converter/builtin_converters.cpp(2
50):
> error #698: the modifier "dllimport" is not allowed on this
declaration
>   BOOST_PYTHON_DECL PyObject* do_callback_to_python(PyObject* x)
>                               ^
> Note that I'm building my code outside of jam. Do I perhaps need to
define
> additional macro's?
>
> Thanks,
>
> Peter
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
>





From stoy at sinistergames.com  Fri Apr 12 18:56:56 2002
From: stoy at sinistergames.com (Christopher M Stoy)
Date: Fri, 12 Apr 2002 12:56:56 -0400
Subject: [C++-sig] Porting Python to different platforms
In-Reply-To: <069c01c1e22e$9b33a2b0$6801a8c0@boostconsulting.com>
Message-ID: <001001c1e243$0f7b2760$40fea8c0@jarjar>

Hey all,

I'm not sure if this is the place to ask this, but I need some help
porting Python to another platform.  I would also like to build Python
without some of the extra features I don't need (like most of the
extension libraries) as a static-link library on Windows.  Yes, I know
there is a DLL, but I don't want to use it since I a need a totally
self-contained solution (ok, it's part of a game engine.)

It seems most info on building is for Unix systems and I can't find any
info on what source files I need to provide the basic interpreter.

Please, any help on this would be most appreciated.

Thanks.

Chris.





From david.abrahams at rcn.com  Fri Apr 12 19:27:17 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 12 Apr 2002 12:27:17 -0500
Subject: [C++-sig] Porting Python to different platforms
References: <001001c1e243$0f7b2760$40fea8c0@jarjar>
Message-ID: <07cf01c1e247$b7713690$6801a8c0@boostconsulting.com>

----- Original Message -----
From: "Christopher M Stoy" <stoy at sinistergames.com>
To: <c++-sig at python.org>
Sent: Friday, April 12, 2002 11:56 AM
Subject: [C++-sig] Porting Python to different platforms


> Hey all,
>
> I'm not sure if this is the place to ask this

I think it isn't. Please try python-dev or comp.lang.python.

> , but I need some help
> porting Python to another platform.  I would also like to build Python






From david.abrahams at rcn.com  Fri Apr 12 19:29:19 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 12 Apr 2002 12:29:19 -0500
Subject: [C++-sig] Warning
Message-ID: <07d001c1e247$b7a84c20$6801a8c0@boostconsulting.com>

The checkin I reported doing last night never happened apparently, and
since I am currently in the middle of fixing the problems with
gcc-2.95.x I can't just check in last night's state. So, the CVS state
of Boost.Python v2 is broken until further notice (should only be a few
hours at most).

Regards,
Dave

+---------------------------------------------------------------+
                  David Abrahams
      C++ Booster (http://www.boost.org)               O__  ==
      Pythonista (http://www.python.org)              c/ /'_ ==
  resume: http://users.rcn.com/abrahams/resume.html  (*) \(*) ==
          email: david.abrahams at rcn.com
+---------------------------------------------------------------+





From david.abrahams at rcn.com  Fri Apr 12 20:55:11 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 12 Apr 2002 13:55:11 -0500
Subject: [C++-sig] Problems fixed
Message-ID: <085801c1e254$291f6c60$6801a8c0@boostconsulting.com>

CVS updated; EH problems with GCC-2.95.x are fixed, and as a bonus no
funky workarounds are required for MSVC and Intel compilers for
callbacks returning non-const reference results. The downside?
call<void> and call_method<void> must have the void return type
explicitly specified (as opposed to writing "call<>"). A small price to
pay, IMO.

-Dave

+---------------------------------------------------------------+
                  David Abrahams
      C++ Booster (http://www.boost.org)               O__  ==
      Pythonista (http://www.python.org)              c/ /'_ ==
  resume: http://users.rcn.com/abrahams/resume.html  (*) \(*) ==
          email: david.abrahams at rcn.com
+---------------------------------------------------------------+





From Peter.Bienstman at rug.ac.be  Fri Apr 12 21:52:22 2002
From: Peter.Bienstman at rug.ac.be (Peter Bienstman)
Date: Fri, 12 Apr 2002 15:52:22 -0400
Subject: [C++-sig] V2: another run time error
Message-ID: <200204121552.26629.Peter.Bienstman@rug.ac.be>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This one is for the record. It's a run time error using Intel V6 under Linux. 
This platform/compiler combo is less important to me, because gcc works fine 
there, so I'm not losing any sleep over this. It could also very well be 
Intel's fault ;-)

Peter

#define BOOST_PYTHON_DYNAMIC_LIB
#define BOOST_PYTHON_V2

#include <boost/python/module.hpp>
#include <boost/python/class.hpp>
#include <boost/mpl/type_list.hpp>

#include <complex>

struct M {M(const std::complex<double>&) {} };

BOOST_PYTHON_MODULE_INIT(m)
{
  using namespace boost::python;
  using boost::mpl::type_list;

  module m("m");
  
  m
    .add(class_<M>("M")
         .def_init(type_list<std::complex<double>&>()))
    ;
  
}

pbienst at hunsmac:~/tmp$ more crash.py
from m import *
M(1j)

Stacktrace

#0  0x4001cab1 in 
boost::python::converter::reference_from_python<std::complex<double>&>::reference_from_python(_object*) 
() from ./m.so
#1  0x4001d843 in 
boost::python::from_python<std::complex<double>&>::from_python(_object*) () 
from ./m.so
#2  0x4001e15d in _object* 
boost::python::detail::returning<void>::call<boost::python::default_call_policies, 
_object*, std::complex<double>&>(void (*)(_object*, std::complex<double>&), 
_object*, _object*, boost::python::default_call_policies const*) () from 
./m.so
#3  0x4001dc99 in 
boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<_object*, 
boost::python::detail::caller, boost::_bi::list4<boost::_bi::value<void 
(*)(_object*, std::complex<double>&)>, boost::arg<1>, boost::arg<2>, 
boost::_bi::value<boost::python::default_call_policies> > >, _object*, 
_object*, _object*>::invoke(boost::detail::function::any_pointer, _object*, 
_object*) () from ./m.so
#4  0x404b353e in operator() (this=0x81a67b8, a0=0x81a65cc, a1=0x0)
    at function_template.hpp:302
#5  0x40491e29 in call (this=0x81a67b0, args=0x81a65cc, keywords=0x0)
    at src/object/function.cpp:42
#6  0x404b36f2 in operator() (this=0xbffff308) at src/object/function.cpp:129
#7  0x404b3185 in invoke (function_obj_ptr=
      {obj_ptr = 0xbffff308, const_obj_ptr = 0xbffff308, func_ptr = 
0xbffff308})
    at function_template.hpp:128
#8  0x404cf3d7 in operator() (this=0xbffff2c4) at function_template.hpp:300
#9  0x40493493 in boost::python::handle_exception_impl (f=0xbffff2c4)
    at src/errors.cpp:20
#10 0x404b37e5 in boost::python::handle_exception (f=
      {m_result = @0xbffff318, m_f = 0x81a67b0, m_args = 0x81a65cc, m_keywords 
= 0x0})
    at errors.hpp:28
#11 0x40492398 in boost::python::objects::function_call (func=0x81a67b0, 
args=0x81a65cc,
    kw=0x0) at src/object/function.cpp:161
#12 0x080e82a2 in PyObject_Call (func=0x81a67b0, arg=0x81a65cc, kw=0x0)
    at Objects/abstract.c:1665
#13 0x080f0117 in instancemethod_call (func=0x81a67b0, arg=0x81a5e4c, kw=0x0)
    at Objects/classobject.c:2276
#14 0x080e82a2 in PyObject_Call (func=0x81934e4, arg=0x81a5e4c, kw=0x0)
    at Objects/abstract.c:1665
#15 0x0806c734 in slot_tp_init (self=0x81a6804, args=0x81a5e4c, kwds=0x0)
    at Objects/typeobject.c:3344
#16 0x0806a801 in type_call (type=0x81ce02c, args=0x81a5e4c, kwds=0x0)
    at Objects/typeobject.c:159
#17 0x080e82a2 in PyObject_Call (func=0x81ce02c, arg=0x81a5e4c, kw=0x0)
    at Objects/abstract.c:1665
#18 0x0808152d in do_call (func=0x81ce02c, pp_stack=0xbffff534, na=1, nk=0)
    at Python/ceval.c:3251
#19 0x0807e034 in eval_frame (f=0x819bed4) at Python/ceval.c:2016
#20 0x0807ed5c in PyEval_EvalCodeEx (co=0x81aacb8, globals=0x8194ed4, 
locals=0x8194ed4,
    args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0)
    at Python/ceval.c:2574
#21 0x08081425 in PyEval_EvalCode (co=0x81aacb8, globals=0x8194ed4, 
locals=0x8194ed4)
    at Python/ceval.c:483
#22 0x0809e44b in run_node (n=0x81aa4f0, filename=0xbffff8e3 "crash.py",
    globals=0x8194ed4, locals=0x8194ed4, flags=0xbffff6ac) at 
Python/pythonrun.c:1083
#23 0x0809cb6f in PyRun_SimpleFileExFlags (fp=0x81852a8, filename=0xbffff8e3 
"crash.py",
    closeit=1, flags=0xbffff6ac) at Python/pythonrun.c:689
#24 0x08055d9a in Py_Main (argc=2, argv=0xbffff784) at Modules/main.c:369
#25 0x08055849 in main (argc=2, argv=0xbffff784) at Modules/python.c:10
#26 0x402e75b0 in __libc_start_main () from /lib/libc.so.6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8tzr64dgPAIjyquoRAgQKAKDKCyGRSbkESbIXz6WRr+wNDSzWxgCePmtG
N/T4NxcQM5d0WlHb7hefl7s=
=e6Qb
-----END PGP SIGNATURE-----





From casado2 at llnl.gov  Fri Apr 12 22:47:18 2002
From: casado2 at llnl.gov (Martin Casado)
Date: Fri, 12 Apr 2002 13:47:18 -0700
Subject: [C++-sig] Boost iterators
In-Reply-To: <1017694764.15479.21.camel@hunsmac.mit.edu>
References: <1017694764.15479.21.camel@hunsmac.mit.edu>
Message-ID: <02041213471800.16363@avalanche.llnl.gov>

Hi,

  I've been working on iterator support with boost.  The basic
  functionality I would like to have would be something like.

  >>>for element in myobject.nodes:
  >>>    print element
 
 I've written a simple class template:

 template <typename T>
 class PyIter{}

 Which when constructed with a container object, or two
 const_iterators,  behaves like an iterator at the python
 level.

 I've wrapped this class with BPL, and defined the following
 symbols:
 __iter__,__getitem__,next,__len__

 where __iter__ returns a pointer to self, and the rest
 function as expected.

 I have two questions:

 1. How can I get an exception to Python without causing Boost to barf?
    To signify that the iterator has reached the end of the container 
    I must set, StopIteration, but boost assumes the following is
    an internal error.

     PyErr_SetString(PyExc_StopIteration,"done iterating");          

     and  prints the following:

    XXX undetected error
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    StopIteration: done iterating

 2. Currently, I have to add a function in my C++ class to return a newly
    constructed PyIter.  Is there a way to have boost create the
    type given an accessor method to the container or the container itself?

 Any ideas would be greatly appreciated.

                           Cheers,
                          ~~martin






From david.abrahams at rcn.com  Fri Apr 12 22:54:58 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 12 Apr 2002 15:54:58 -0500
Subject: [C++-sig] V2: another run time error
References: <200204121552.26629.Peter.Bienstman@rug.ac.be>
Message-ID: <08c001c1e264$500e3580$6801a8c0@boostconsulting.com>

Peter,

The crash is a bug in the intel compiler's EH implementation. It should
report an error (with, at this stage, a cryptic error message --
TypeError: bad argument type for built-in operation). The problem is
that you're requesting that the result of an rvalue conversion (Python
complex -> C++ complex) be bound to a non-const reference. If you change
your intialization to:

  m
    .add(class_<M>("M")
         .def_init(args<std::complex<double> const&>()))
    ;

the code will work.

----- Original Message -----
From: "Peter Bienstman" <Peter.Bienstman at rug.ac.be>
To: <c++-sig at python.org>
Sent: Friday, April 12, 2002 2:52 PM
Subject: [C++-sig] V2: another run time error


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This one is for the record. It's a run time error using Intel V6 under
Linux.
This platform/compiler combo is less important to me, because gcc works
fine
there, so I'm not losing any sleep over this. It could also very well be
Intel's fault ;-)

Peter

#define BOOST_PYTHON_DYNAMIC_LIB
#define BOOST_PYTHON_V2

#include <boost/python/module.hpp>
#include <boost/python/class.hpp>
#include <boost/mpl/type_list.hpp>

#include <complex>

struct M {M(const std::complex<double>&) {} };

BOOST_PYTHON_MODULE_INIT(m)
{
  using namespace boost::python;
  using boost::mpl::type_list;

  module m("m");

  m
    .add(class_<M>("M")
         .def_init(type_list<std::complex<double>&>()))
    ;

}

pbienst at hunsmac:~/tmp$ more crash.py
from m import *
M(1j)

Stacktrace

#0  0x4001cab1 in
boost::python::converter::reference_from_python<std::complex<double>&>::
reference_from_python(_object*)
() from ./m.so
#1  0x4001d843 in
boost::python::from_python<std::complex<double>&>::from_python(_object*)
()
from ./m.so
#2  0x4001e15d in _object*
boost::python::detail::returning<void>::call<boost::python::default_call
_policies,
_object*, std::complex<double>&>(void (*)(_object*,
std::complex<double>&),
_object*, _object*, boost::python::default_call_policies const*) () from
./m.so
#3  0x4001dc99 in
boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<_objec
t*,
boost::python::detail::caller, boost::_bi::list4<boost::_bi::value<void
(*)(_object*, std::complex<double>&)>, boost::arg<1>, boost::arg<2>,
boost::_bi::value<boost::python::default_call_policies> > >, _object*,
_object*, _object*>::invoke(boost::detail::function::any_pointer,
_object*,
_object*) () from ./m.so
#4  0x404b353e in operator() (this=0x81a67b8, a0=0x81a65cc, a1=0x0)
    at function_template.hpp:302
#5  0x40491e29 in call (this=0x81a67b0, args=0x81a65cc, keywords=0x0)
    at src/object/function.cpp:42
#6  0x404b36f2 in operator() (this=0xbffff308) at
src/object/function.cpp:129
#7  0x404b3185 in invoke (function_obj_ptr=
      {obj_ptr = 0xbffff308, const_obj_ptr = 0xbffff308, func_ptr =
0xbffff308})
    at function_template.hpp:128
#8  0x404cf3d7 in operator() (this=0xbffff2c4) at
function_template.hpp:300
#9  0x40493493 in boost::python::handle_exception_impl (f=0xbffff2c4)
    at src/errors.cpp:20
#10 0x404b37e5 in boost::python::handle_exception (f=
      {m_result = @0xbffff318, m_f = 0x81a67b0, m_args = 0x81a65cc,
m_keywords
= 0x0})
    at errors.hpp:28
#11 0x40492398 in boost::python::objects::function_call (func=0x81a67b0,
args=0x81a65cc,
    kw=0x0) at src/object/function.cpp:161
#12 0x080e82a2 in PyObject_Call (func=0x81a67b0, arg=0x81a65cc, kw=0x0)
    at Objects/abstract.c:1665
#13 0x080f0117 in instancemethod_call (func=0x81a67b0, arg=0x81a5e4c,
kw=0x0)
    at Objects/classobject.c:2276
#14 0x080e82a2 in PyObject_Call (func=0x81934e4, arg=0x81a5e4c, kw=0x0)
    at Objects/abstract.c:1665
#15 0x0806c734 in slot_tp_init (self=0x81a6804, args=0x81a5e4c,
kwds=0x0)
    at Objects/typeobject.c:3344
#16 0x0806a801 in type_call (type=0x81ce02c, args=0x81a5e4c, kwds=0x0)
    at Objects/typeobject.c:159
#17 0x080e82a2 in PyObject_Call (func=0x81ce02c, arg=0x81a5e4c, kw=0x0)
    at Objects/abstract.c:1665
#18 0x0808152d in do_call (func=0x81ce02c, pp_stack=0xbffff534, na=1,
nk=0)
    at Python/ceval.c:3251
#19 0x0807e034 in eval_frame (f=0x819bed4) at Python/ceval.c:2016
#20 0x0807ed5c in PyEval_EvalCodeEx (co=0x81aacb8, globals=0x8194ed4,
locals=0x8194ed4,
    args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0,
closure=0x0)
    at Python/ceval.c:2574
#21 0x08081425 in PyEval_EvalCode (co=0x81aacb8, globals=0x8194ed4,
locals=0x8194ed4)
    at Python/ceval.c:483
#22 0x0809e44b in run_node (n=0x81aa4f0, filename=0xbffff8e3 "crash.py",
    globals=0x8194ed4, locals=0x8194ed4, flags=0xbffff6ac) at
Python/pythonrun.c:1083
#23 0x0809cb6f in PyRun_SimpleFileExFlags (fp=0x81852a8,
filename=0xbffff8e3
"crash.py",
    closeit=1, flags=0xbffff6ac) at Python/pythonrun.c:689
#24 0x08055d9a in Py_Main (argc=2, argv=0xbffff784) at
Modules/main.c:369
#25 0x08055849 in main (argc=2, argv=0xbffff784) at Modules/python.c:10
#26 0x402e75b0 in __libc_start_main () from /lib/libc.so.6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8tzr64dgPAIjyquoRAgQKAKDKCyGRSbkESbIXz6WRr+wNDSzWxgCePmtG
N/T4NxcQM5d0WlHb7hefl7s=
=e6Qb
-----END PGP SIGNATURE-----



_______________________________________________
C++-sig mailing list
C++-sig at python.org
http://mail.python.org/mailman/listinfo/c++-sig






From david.abrahams at rcn.com  Fri Apr 12 23:02:30 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 12 Apr 2002 16:02:30 -0500
Subject: [C++-sig] Boost iterators
References: <1017694764.15479.21.camel@hunsmac.mit.edu> <02041213471800.16363@avalanche.llnl.gov>
Message-ID: <08cc01c1e265$5da2a900$6801a8c0@boostconsulting.com>

----- Original Message -----
From: "Martin Casado" <casado2 at llnl.gov>

>  I have two questions:
>
>  1. How can I get an exception to Python without causing Boost to
barf?
>     To signify that the iterator has reached the end of the container
>     I must set, StopIteration, but boost assumes the following is
>     an internal error.
>
>      PyErr_SetString(PyExc_StopIteration,"done iterating");
>
>      and  prints the following:
>
>     XXX undetected error
>     Traceback (most recent call last):
>       File "<stdin>", line 1, in ?
>     StopIteration: done iterating

It's not boost reporting "undetected error", but Python. Try the
following:

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

    PyErr_SetString(PyExc_StopIteration,"done iterating");
    throw boost::python::error_already_set();


>  2. Currently, I have to add a function in my C++ class to return a
newly
>     constructed PyIter.  Is there a way to have boost create the
>     type given an accessor method to the container or the container
itself?

Could you be more specific? What did you have in mind?

-Dave





From Peter.Bienstman at rug.ac.be  Fri Apr 12 23:16:26 2002
From: Peter.Bienstman at rug.ac.be (Peter Bienstman)
Date: Fri, 12 Apr 2002 23:16:26 +0200 (MEST)
Subject: [C++-sig] V2: another run time error
In-Reply-To: <08c001c1e264$500e3580$6801a8c0@boostconsulting.com>
Message-ID: <Pine.GSO.4.31.0204122313580.2742-100000@allserv.rug.ac.be>

On Fri, 12 Apr 2002, David Abrahams wrote:

> Peter,
>
> The crash is a bug in the intel compiler's EH implementation. It should
> report an error (with, at this stage, a cryptic error message --
> TypeError: bad argument type for built-in operation). The problem is
> that you're requesting that the result of an rvalue conversion (Python
> complex -> C++ complex) be bound to a non-const reference. If you change
> your intialization to:
>
>   m
>     .add(class_<M>("M")
>          .def_init(args<std::complex<double> const&>()))
>     ;
>
> the code will work.

I'm sorry to disappoint you, but it doesn't work. I even tried changing
type_list to args, but no effect...

BTW: the same code worked perfectly with gcc3 (unless there have been some
drastic changes in bpl in the last 2 days)

Peter





From casado2 at llnl.gov  Fri Apr 12 23:28:58 2002
From: casado2 at llnl.gov (Martin Casado)
Date: Fri, 12 Apr 2002 14:28:58 -0700
Subject: [C++-sig] Boost iterators
In-Reply-To: <08cc01c1e265$5da2a900$6801a8c0@boostconsulting.com>
References: <1017694764.15479.21.camel@hunsmac.mit.edu> <02041213471800.16363@avalanche.llnl.gov> <08cc01c1e265$5da2a900$6801a8c0@boostconsulting.com>
Message-ID: <02041214285802.16363@avalanche.llnl.gov>

>
> #include <boost/python/errors.hpp>
> ...
>
>     PyErr_SetString(PyExc_StopIteration,"done iterating");
>     throw boost::python::error_already_set();

  works marvelously, thanks

>
> >  2. Currently, I have to add a function in my C++ class to return a
>
> newly
>
> >     constructed PyIter.  Is there a way to have boost create the
> >     type given an accessor method to the container or the container
>
> itself?
>
> Could you be more specific? What did you have in mind?

given

struct Foo{
  vector<int> v;
 
  const vector<int>& getV(){return v;}
}

I think it would be tres cool if you could say something like..

           .def("v", &Foo::getV, 
return_value_policy<create_iterator_from<vector<int> >())

  which would construct a PyIter object under the covers:  

  PyIter<vector<int> >(obj->getV());

  and return it to python.

  so:

  v = myfoo.v()

  for i in v:
    print i

  currently I have to declare a function in class foo() which returns a
  const PyIter<vector<int> >& which I would like to avoid.

  Or even better, I would like to be able to create an attribute "v"
  that has the same functionality (using the same mechanics)

  I would be happy to take a stab at writing the new return policy if you
  would affirm that it is possible and not extremely complicated.

  Thanks, :-)

                            ~~m





From david.abrahams at rcn.com  Fri Apr 12 23:50:24 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 12 Apr 2002 16:50:24 -0500
Subject: [C++-sig] V2: another run time error
References: <Pine.GSO.4.31.0204122313580.2742-100000@allserv.rug.ac.be>
Message-ID: <08f401c1e26c$395d84a0$6801a8c0@boostconsulting.com>

----- Original Message -----
From: "Peter Bienstman" <Peter.Bienstman at rug.ac.be>


> On Fri, 12 Apr 2002, David Abrahams wrote:
>
> > Peter,
> >
> > The crash is a bug in the intel compiler's EH implementation. It
should
> > report an error (with, at this stage, a cryptic error message --
> > TypeError: bad argument type for built-in operation). The problem is
> > that you're requesting that the result of an rvalue conversion
(Python
> > complex -> C++ complex) be bound to a non-const reference. If you
change
> > your intialization to:
> >
> >   m
> >     .add(class_<M>("M")
> >          .def_init(args<std::complex<double> const&>()))
-------------------------------------------------^^^^^
> >     ;
> >
> > the code will work.
>
> I'm sorry to disappoint you, but it doesn't work. I even tried
changing
> type_list to args, but no effect...

Maybe there are other bugs in the intel6 compiler for Linux, then...
Since I haven't installed it yet, I can't say for sure.

> BTW: the same code worked perfectly with gcc3 (unless there have been
some
> drastic changes in bpl in the last 2 days)

Your code as written didn't work for me with any compiler, including
gcc-3.0.3. Adding the const pointed out above was absolutely required
for me, as I would expect. It would really surprise me if it worked for
you without the const.

-Dave





From andy.elvey at paradise.net.nz  Sat Apr 13 00:12:14 2002
From: andy.elvey at paradise.net.nz (Andy Elvey)
Date: Sat, 13 Apr 2002 10:12:14 +1200
Subject: [C++-sig] Boost iterators
References: <1017694764.15479.21.camel@hunsmac.mit.edu> <02041213471800.16363@avalanche.llnl.gov> <08cc01c1e265$5da2a900$6801a8c0@boostconsulting.com> <02041214285802.16363@avalanche.llnl.gov>
Message-ID: <005401c1e26f$1a471d80$1a454fcb@andyelve>

----- Original Message -----
From: Martin Casado <casado2 at llnl.gov>
To: <c++-sig at python.org>
Sent: Saturday, April 13, 2002 9:28 AM
Subject: Re: [C++-sig] Boost iterators

<Snip>

> given
>
> struct Foo{
>   vector<int> v;
>
>   const vector<int>& getV(){return v;}
> }
>
> I think it would be tres cool if you could say something like..
>
>            .def("v", &Foo::getV,
> return_value_policy<create_iterator_from<vector<int> >())
>
>   which would construct a PyIter object under the covers:
>
>   PyIter<vector<int> >(obj->getV());
>
>   and return it to python.
>
>   so:
>
>   v = myfoo.v()
>
>   for i in v:
>     print i
>
>   currently I have to declare a function in class foo() which returns a
>   const PyIter<vector<int> >& which I would like to avoid.
>
>   Or even better, I would like to be able to create an attribute "v"
>   that has the same functionality (using the same mechanics)
>
>   I would be happy to take a stab at writing the new return policy if you
>   would affirm that it is possible and not extremely complicated.

   Hmm ....  I wonder if the new (and very promising) C++ package "sigslot"
  (which I came across 2-3 days ago) may be able to help here.
  ( http://sourceforge.net/projects/sigslot ) .

  I'm nowhere near "guru-level" enough to be able to say exactly how it may
help, but I have
 a suspicion that it may , as it seems to take "abstraction" to new levels
..... :-) .   This package uses the same signal-slot paradigm as the Qt
library, and (even better), it is "public domain" .  Looks to be
_beautifully_
  designed.   Apologies if I'm "off-beam" in thinking this package
  may help . Just a thought (and my 2c worth .... :-)








From rwgk at yahoo.com  Sat Apr 13 00:25:07 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 12 Apr 2002 15:25:07 -0700 (PDT)
Subject: [C++-sig] V1 trouble with gcc 2.95.3
Message-ID: <20020412222507.73980.qmail@web20209.mail.yahoo.com>

I am using:
- The latest CVS snapshot of boost
- RedHat 7.1
- Python 2.2.1
- gcc 2.95.3, gcc 2.96, gcc 3.0.4
- compiling: g++ -fPIC -ftemplate-depth-50  -g -c
- linking: g++ -shared

Compilation of the V1 comprehensive test and all the examples
goes smoothly with all compilers.
All the tests work fine with gcc 2.96 and 3.0.4, but some test
are broken with gcc 2.95.3 (output attached).

The debugger output for one simplified example is also attached.
What could be wrong?

Thanks,
        Ralf


PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python comprehensive.py
make: *** [test] Aborted
PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python test_abstract.py
PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python test_getting_started1.py
PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python test_getting_started2.py
PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python test_simple_vector.py
make: *** [test] Aborted
PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python
test_do_it_yourself_convts.py
PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python test_nested.py
PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python test_pickle1.py
PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python test_pickle2.py
make: *** [test] Aborted
PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python test_pickle3.py
PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python test_cross_module.py
PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python test_richcmp1.py
make: *** [test] Aborted
PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python test_richcmp2.py
make: *** [test] Aborted
PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python test_richcmp3.py
make: *** [test] Aborted


% gdb /usr/local_cci/Python-2.2.1/bin/python
GNU gdb 5.0rh-5 Red Hat Linux 7.1
This GDB was configured as "i386-redhat-linux"...
(gdb) run
Starting program: /usr/local_cci/Python-2.2.1/bin/python 
Python 2.2.1 (#1, Apr 10 2002, 12:59:38) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-81)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import simple_vector
>>> v=simple_vector.vector_double(5)

Program received signal SIGABRT, Aborted.
0x40085801 in __kill () from /lib/i686/libc.so.6
(gdb) where
#0  0x40085801 in __kill () from /lib/i686/libc.so.6
#1  0x400855da in raise (sig=6) at ../sysdeps/posix/raise.c:27
#2  0x40086d82 in abort () at ../sysdeps/generic/abort.c:88
#3  0x402b86eb in __default_terminate () from ./simple_vector.so
#4  0x402b870c in __terminate () from ./simple_vector.so
#5  0x402b9044 in throw_helper (eh=0x4031430c, pc=0xffffffff, 
    my_udata=0xbfffe508, offset_p=0xbfffe504) from ./simple_vector.so
#6  0x402b91fc in __throw () from ./simple_vector.so
(gdb) 


__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/




From Peter.Bienstman at rug.ac.be  Sat Apr 13 00:46:35 2002
From: Peter.Bienstman at rug.ac.be (Peter Bienstman)
Date: Sat, 13 Apr 2002 00:46:35 +0200 (MEST)
Subject: [C++-sig] V2: another run time error
In-Reply-To: <08f401c1e26c$395d84a0$6801a8c0@boostconsulting.com>
Message-ID: <Pine.GSO.4.31.0204130044360.10179-100000@allserv.rug.ac.be>

> > BTW: the same code worked perfectly with gcc3 (unless there have been
> some
> > drastic changes in bpl in the last 2 days)
>
> Your code as written didn't work for me with any compiler, including
> gcc-3.0.3. Adding the const pointed out above was absolutely required
> for me, as I would expect. It would really surprise me if it worked for
> you without the const.

Oops, I was referring to the original project from which I derived the
testcase, which did have the const. In distilling the testcase, I forget
the const.

I guess we can qualify the crash then as an Intel bug...

Thanks,

Peter





From david.abrahams at rcn.com  Sat Apr 13 00:56:53 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 12 Apr 2002 17:56:53 -0500
Subject: [C++-sig] V1 trouble with gcc 2.95.3
References: <20020412222507.73980.qmail@web20209.mail.yahoo.com>
Message-ID: <093701c1e275$58425e00$6801a8c0@boostconsulting.com>

Ralf,

I am seeing the same problem on Cygwin.
Not sure yet what the cause might be... hmm, it appears to be an
uncaught exception. Can you set a breakpoint in __throw()? I'm not sure
that I'm set up to debug this one here at the moment...

Please let me know if you find any clues.

-Dave

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
To: <c++-sig at python.org>
Sent: Friday, April 12, 2002 5:25 PM
Subject: [C++-sig] V1 trouble with gcc 2.95.3


> I am using:
> - The latest CVS snapshot of boost
> - RedHat 7.1
> - Python 2.2.1
> - gcc 2.95.3, gcc 2.96, gcc 3.0.4
> - compiling: g++ -fPIC -ftemplate-depth-50  -g -c
> - linking: g++ -shared
>
> Compilation of the V1 comprehensive test and all the examples
> goes smoothly with all compilers.
> All the tests work fine with gcc 2.96 and 3.0.4, but some test
> are broken with gcc 2.95.3 (output attached).
>
> The debugger output for one simplified example is also attached.
> What could be wrong?
>
> Thanks,
>         Ralf
>
>
> PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python comprehensive.py
> make: *** [test] Aborted
> PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python test_abstract.py
> PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python
test_getting_started1.py
> PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python
test_getting_started2.py
> PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python
test_simple_vector.py
> make: *** [test] Aborted
> PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python
> test_do_it_yourself_convts.py
> PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python test_nested.py
> PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python test_pickle1.py
> PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python test_pickle2.py
> make: *** [test] Aborted
> PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python test_pickle3.py
> PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python
test_cross_module.py
> PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python test_richcmp1.py
> make: *** [test] Aborted
> PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python test_richcmp2.py
> make: *** [test] Aborted
> PYTHONPATH=. /usr/local_cci/Python-2.2.1/bin/python test_richcmp3.py
> make: *** [test] Aborted
>
>
> % gdb /usr/local_cci/Python-2.2.1/bin/python
> GNU gdb 5.0rh-5 Red Hat Linux 7.1
> This GDB was configured as "i386-redhat-linux"...
> (gdb) run
> Starting program: /usr/local_cci/Python-2.2.1/bin/python
> Python 2.2.1 (#1, Apr 10 2002, 12:59:38)
> [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-81)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import simple_vector
> >>> v=simple_vector.vector_double(5)
>
> Program received signal SIGABRT, Aborted.
> 0x40085801 in __kill () from /lib/i686/libc.so.6
> (gdb) where
> #0  0x40085801 in __kill () from /lib/i686/libc.so.6
> #1  0x400855da in raise (sig=6) at ../sysdeps/posix/raise.c:27
> #2  0x40086d82 in abort () at ../sysdeps/generic/abort.c:88
> #3  0x402b86eb in __default_terminate () from ./simple_vector.so
> #4  0x402b870c in __terminate () from ./simple_vector.so
> #5  0x402b9044 in throw_helper (eh=0x4031430c, pc=0xffffffff,
>     my_udata=0xbfffe508, offset_p=0xbfffe504) from ./simple_vector.so
> #6  0x402b91fc in __throw () from ./simple_vector.so
> (gdb)
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Tax Center - online filing with TurboTax
> http://taxes.yahoo.com/
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From rwgk at yahoo.com  Sat Apr 13 05:03:36 2002
From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve)
Date: Fri, 12 Apr 2002 20:03:36 -0700 (PDT)
Subject: [C++-sig] V1 trouble with gcc 2.95.3
In-Reply-To: <093701c1e275$58425e00$6801a8c0@boostconsulting.com>
Message-ID: <20020413030336.77542.qmail@web20205.mail.yahoo.com>

> I am seeing the same problem on Cygwin.
> Not sure yet what the cause might be... hmm, it appears to be an
> uncaught exception. Can you set a breakpoint in __throw()? I'm not sure
> that I'm set up to debug this one here at the moment...

I didn't get anywhere with gdb.

> Please let me know if you find any clues.

I resorted to my "CheckPoint" debugging technique:

1. Insert the CheckPoint define as shown below.

2. Insert two Checkpoints in simple_vector.h:

    vector_double_wrapper(PyObject* self)
      : std::vector<double>() {
CheckPoint;
      }

    vector_double_wrapper(PyObject* self, int n)
      : std::vector<double>(n) {
CheckPoint;
    }

Result:

>>> import simple_vector
>>> v=simple_vector.vector_double()
simple_vector.cpp(22)
>>> v=simple_vector.vector_double(5)
Abort

3. Comment out the binding for the default constructor:

    //vector_double.def(python::constructor<>());

Result:

>>> import simple_vector
>>> v=simple_vector.vector_double(5)
simple_vector.cpp(27)

This seems to be very similar to the problem that I reported six weeks
ago. Only simpler because this time the cross_module.hpp header file is
not involved. The old message is attached.

Ralf


Date: Fri, 1 Mar 2002 17:22:28 -0800 (PST)
From: "Ralf W. Grosse-Kunstleve" <rwgk at cci.lbl.gov>
To: david.abrahams at rcn.com
Subject: BPL V1 problem: overload resolution & cross-module

Hi David,

Using the latest boost CVS snapshot and a static V1 libboost_python.a,
I am experiencing problems with overloaded functions such as:

    this_module.def(show_complex, "show");
    this_module.def(show_real, "show");

with:

  typedef std::vector<double> shared_real_array;
  typedef std::vector<std::complex<double> > shared_complex_array;

  void show_complex(shared_complex_array a);
  void show_real(shared_real_array a);

In Python:

from cctbx.arraytbx import std_vector ### similar to example/simple_vector.cpp
import debug2 ### the source code is attached
vd = std_vector.double(2)
debug2.show(vd)

This script works on the Alpha and on Windows (both VC60 and Codewarrior),
but crashes while executing the last line when using Linux/gcc-3.0.4
or SGI/CC (it crashes before getting to the first "CheckPoint").

It works everywhere if the .defs are swapped:

    this_module.def(show_real, "show");
    this_module.def(show_complex, "show");

There also is no problem if the "show" .defs are moved to the module
that exports the std_vector bindings.

I am guessing that there is a problem with the combination of
overload resolution and the use of the cross-module facilities.
This used to work in the past. I still have a Linux/gcc test-output
from January 8. I first discovered the problem with a cvs snapshot
from February 14. Would you have any clues that could help to
fix my problem?

Thanks,
        Ralf


#include <boost/python/cross_module.hpp>
#include <vector>

#include <iostream>
#define CheckPoint std::cout << __FILE__ << "(" << __LINE__ << ")" << std::endl
<< std::flush

namespace {

  typedef std::vector<double> shared_real_array;
  typedef std::vector<std::complex<double> > shared_complex_array;

  void show_complex(shared_complex_array a) {
CheckPoint;
    std::cout << a.size() << std::endl;
CheckPoint;
  }

  void show_real(shared_real_array a) {
CheckPoint;
    std::cout << a.size() << std::endl;
CheckPoint;
  }

#   include <cctbx/basic/from_bpl_import.h>

  void init_module(python::module_builder& this_module)
  {
    const std::string Revision = "$Revision: 1.14 $";
    this_module.add(ref(to_python(
        Revision.substr(11, Revision.size() - 11 - 2))), "__version__");

    python::import_converters<std::vector<double> >
    py_shared_double(
      "cctbx.arraytbx.std_vector", "double");

    python::import_converters<std::vector<std::complex<double> > >
    py_shared_complex_double(
      "cctbx.arraytbx.std_vector", "complex_double");

    this_module.def(show_complex, "show");
    this_module.def(show_real, "show");
  }

}

BOOST_PYTHON_MODULE_INIT(debug2)
{
  boost::python::module_builder this_module("debug2");
  init_module(this_module);
}


__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/




From david.abrahams at rcn.com  Sat Apr 13 05:09:23 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 12 Apr 2002 22:09:23 -0500
Subject: [C++-sig] V1 trouble with gcc 2.95.3
References: <20020412222507.73980.qmail@web20209.mail.yahoo.com>
Message-ID: <0a5e01c1e298$d21c9740$6801a8c0@boostconsulting.com>

From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
with gcc 2.95.3 (output attached).
>
> The debugger output for one simplified example is also attached.
> What could be wrong?
>
> Thanks,
>         Ralf


Ralf, I think I have solved the problem, at least on Windows. It appears
GCC is unable to deal with exception-handling across shared library
boundaries. The solution (which should result in smaller code anyway) is
to replace all instances of throw some_exception(); with
throw_some_exception();, which is a function exported from the Shared
lib.

Unfortunately, it looks like MinGW has some kind of codegen bug which
causes the comprehensive test to crash (I believe it's a refcounting
problem). But cygwin gcc-3.0.4 is working nicely.

I'll be checking in a fix within the hour. Let me know how it plays on
your end.

-Dave






From david.abrahams at rcn.com  Sat Apr 13 06:28:41 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 12 Apr 2002 23:28:41 -0500
Subject: [C++-sig] V1 trouble with gcc 2.95.3
References: <20020412222507.73980.qmail@web20209.mail.yahoo.com>
Message-ID: <0a9a01c1e2a4$21306c20$6801a8c0@boostconsulting.com>

Hi Ralf.

Please try again. If it still doesn't work, I just don't know: I have to
conclude it's a codegen bug in the compiler :(

-Dave

----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>


> I am using:
> - The latest CVS snapshot of boost
> - RedHat 7.1
> - Python 2.2.1
> - gcc 2.95.3, gcc 2.96, gcc 3.0.4
> - compiling: g++ -fPIC -ftemplate-depth-50  -g -c
> - linking: g++ -shared
>
> Compilation of the V1 comprehensive test and all the examples
> goes smoothly with all compilers.
> All the tests work fine with gcc 2.96 and 3.0.4, but some test
> are broken with gcc 2.95.3 (output attached).







From david.abrahams at rcn.com  Sat Apr 13 18:41:38 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Sat, 13 Apr 2002 11:41:38 -0500
Subject: [C++-sig] Re: [boost] export_converters() in vc7
References: <000001c1e2f3$7dfb0e20$0b00010a@tunguska>
Message-ID: <0c1b01c1e30a$7b800490$6801a8c0@boostconsulting.com>

I have fixed Boost.Python v1 in CVS so that all tests pass with VC7.

----- Original Message -----
From: "David GD Wilson" <firestar at thenorth.org>


> > Ralf W. Grosse-Kunstleve wrote:
> > --- David GD Wilson <firestar at thenorth.org> wrote:
> > > Hi,
> > >
> > > I am trying to export a C++ class (CVector) defined in a
> boost.python
> > > module to use in another boost.python module, however I get the
> compile
> > > error:
> > >
> > > c:\sdk\boost_1_27_0\boost\python\cross_module.hpp(215): error
C2665:
> > > 'boost::python::from_python' : none of the 59 overloads can
convert
> > > parameter 2 from type 'boost::python::type<T>'
> > >         with
> > >         [
> > >             T=boost::shared_ptr<CVector> &
> > >         ]
> >
> > The cross-module support definitely works with VC6, but I have not
> > tried VC7.
> > Questions:
> > - Can you compile all the examples? You can quickly try this using
> >   vc60.mak in the build directory.
>
> Building the dvect example (by creating a project with just dvect.cpp
in
> it), I get the same type of error:
>
> c:\sdk\boost_1_27_0\boost\python\cross_module.hpp(215): error C2665:
> 'boost::python::from_python' : none of the 72 overloads can convert
> parameter 2 from type 'boost::python::type<T>'
>         with
>         [
>             T=boost::shared_ptr<vects::dvect> &
>         ]
>
> And something very similar for ivect.
>
> > - Does your code compile if you remove the export_converters()
> >   statement?
>
> Yes it does.
>
> > - If yes, create a dummy function with a boost::shared_ptr<CVector>
&
> >   argument and core_module.def(dummy, "dummy"). Does this compile
> >   (try with gcc first)?
>
> This does not compile either.
>
> Note that other boost::python things appear to not work properly in
> VC7...
>
> Using the make file I get this error:
> NMAKE : fatal error U1073: don't know how to make 'classes.obj'
> Stop.
>
> Building the test project in the IDE, I get:
>
> c:\sdk\boost_1_27_0\boost\python\conversions.hpp(268): error C2065:
> 'smart_ptr_from_python' : undeclared identifier
>
> Which is being called from this part of conversions.hpp:
>
> #if !defined(BOOST_MSVC6_OR_EARLIER)
> template <class T>
> boost::shared_ptr<T> from_python(PyObject*p,
> boost::python::type<boost::shared_ptr<T> >)
> {
>     return smart_ptr_from_python(p,
> boost::python::type<boost::shared_ptr<T> >(),
boost::python::type<T>());
> }
> #endif
>
> and here BOOST_MSVC6_OR_EARLIER is not defined.
>
> Building the example1 project, I get link errors:
>
> example1 error LNK2019: unresolved external symbol "bool __cdecl
> boost::python::handle_exception_impl(class
boost::function0<void,struct
> boost::empty_function_policy,struct boost::empty_function_mixin,int>)"
>
(?handle_exception_impl at python@boost@@YA_NV?$function0 at XUempty_function_
> policy at boost@@Uempty_function_mixin at 2@H at 2@@Z) referenced in function
> "bool __cdecl boost::python::handle_exception(void (__cdecl*)(void))"
> (?handle_exception at python@boost@@YA_NP6AXXZ at Z)
>
> example1 error LNK2001: unresolved external symbol "struct _object *
> __cdecl boost::python::expect_non_null(struct _object *)"
> (?expect_non_null at python@boost@@YAPAU_object@@PAU3@@Z)
>
> - David
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost





From david.abrahams at rcn.com  Mon Apr 15 20:57:15 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 15 Apr 2002 13:57:15 -0500
Subject: [C++-sig] Boost iterators
References: <1017694764.15479.21.camel@hunsmac.mit.edu> <02041213471800.16363@avalanche.llnl.gov> <08cc01c1e265$5da2a900$6801a8c0@boostconsulting.com> <02041214285802.16363@avalanche.llnl.gov>
Message-ID: <118901c1e4af$7f5214e0$6801a8c0@boostconsulting.com>

----- Original Message -----
From: "Martin Casado" <casado2 at llnl.gov>

> given
>
> struct Foo{
>   vector<int> v;
>
>   const vector<int>& getV(){return v;}
> }
>
> I think it would be tres cool if you could say something like..
>
>            .def("v", &Foo::getV,
> return_value_policy<create_iterator_from<vector<int> >())

That's a very interesting idea. However, you shouldn't have to name the
return type:

        .def("v", &Foo::getV, return_value_policy<create_iterator>() )

should be sufficient. And now that I look at it, I ask myself what the
point is, since presumably you want to expose vector<int> as a Python
iterator anyway. It seems to me that you really want

        .def("v", &Foo::getV,
return_value_policy<return_internal_reference>() )

so that the iterator keeps the Foo object alive?

>   currently I have to declare a function in class foo() which returns
a
>   const PyIter<vector<int> >& which I would like to avoid.
>
>   Or even better, I would like to be able to create an attribute "v"
>   that has the same functionality (using the same mechanics)
>
>   I would be happy to take a stab at writing the new return policy if
you
>   would affirm that it is possible and not extremely complicated.

It shouldn't be too hard, but it doesn't seem like the right approach to
me.

-Dave





From david.abrahams at rcn.com  Thu Apr 18 06:46:31 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Wed, 17 Apr 2002 23:46:31 -0500
Subject: [C++-sig] Boost.Python v2: Arbitrary arity handling updated
Message-ID: <008c01c1e694$03d9d3c0$6501a8c0@boostconsulting.com>

The Kull group reported some problems with the arbitrary arity support
today; they've been fixed. The default arity support is for up to 15
arguments for EDG compilers now; 17 arguments for all others. In order
to avoid confusion, the "this" pointer of member functions no longer
counts as one of the arguments when computing arity.

Caveat: if you use any mpl sequence other than boost::python::args<...>
in your calls to def_init(), compilation will be SLOW on EDG compilers.
Don't say I didn't warn you.

-Dave

+---------------------------------------------------------------+
                  David Abrahams
      C++ Booster (http://www.boost.org)               O__  ==
      Pythonista (http://www.python.org)              c/ /'_ ==
  resume: http://users.rcn.com/abrahams/resume.html  (*) \(*) ==
          email: david.abrahams at rcn.com
+---------------------------------------------------------------+





From casado2 at llnl.gov  Thu Apr 18 22:21:28 2002
From: casado2 at llnl.gov (Martin Casado)
Date: Thu, 18 Apr 2002 13:21:28 -0700
Subject: [C++-sig] Boost iterators
In-Reply-To: <118901c1e4af$7f5214e0$6801a8c0@boostconsulting.com>
References: <1017694764.15479.21.camel@hunsmac.mit.edu> <02041214285802.16363@avalanche.llnl.gov> <118901c1e4af$7f5214e0$6801a8c0@boostconsulting.com>
Message-ID: <0204181321280N.12560@avalanche.llnl.gov>

>
> > given
> >
> > struct Foo{
> >   vector<int> v;
> >
> >   const vector<int>& getV(){return v;}
> > }
> >
> > I think it would be tres cool if you could say something like..
> >
> >            .def("v", &Foo::getV,
> > return_value_policy<create_iterator_from<vector<int> >())
>
> That's a very interesting idea. However, you shouldn't have to name the
> return type:
>
>         .def("v", &Foo::getV, return_value_policy<create_iterator>() )
>
> should be sufficient. And now that I look at it, I ask myself what the
> point is, since presumably you want to expose vector<int> as a Python
> iterator anyway. It seems to me that you really want
>
>         .def("v", &Foo::getV,
> return_value_policy<return_internal_reference>() )
>
> so that the iterator keeps the Foo object alive?

What I was intending to do was expose all types that look like stl
containers, as iterators in python.  Or more specifically, any type
that defines begin() and end() which return references to  random accessible 
const iterators.  

so what I probably really want is..

    .def("foo",&FOO:getfoo,
return_value_policy<create_iterator_from<myclass,return_internal_reference>())



                        ~~martin




From david.abrahams at rcn.com  Thu Apr 18 22:59:44 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 18 Apr 2002 15:59:44 -0500
Subject: [C++-sig] Boost iterators
References: <1017694764.15479.21.camel@hunsmac.mit.edu> <02041214285802.16363@avalanche.llnl.gov> <118901c1e4af$7f5214e0$6801a8c0@boostconsulting.com> <0204181321280N.12560@avalanche.llnl.gov>
Message-ID: <038d01c1e71c$781ef5c0$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Martin Casado" <casado2 at llnl.gov>

>
> What I was intending to do was expose all types that look like stl
> containers, as iterators in python.  Or more specifically, any type
> that defines begin() and end() which return references to  random
accessible
> const iterators.
>
> so what I probably really want is..
>
>     .def("foo",&FOO:getfoo,
>
return_value_policy<create_iterator_from<myclass,return_internal_referen
ce>())

My point was this: All you need to do is expose vector<int> such that it
acts like an iterator. Then you don't need to say
"create_iterator_from<...". Just write:

    .add(class_<vector<int> >("int_vector")
            .def("__iter__", /* whatever */))

in some module. Then you can expose getV as

            .def("v", &Foo::getV,
return_value_policy<return_internal_reference>())

You can expose as many vector<int>-returning functions as you like this
way, without writing "create_iterator_from" explicitly each time.

-Dave






From casado2 at llnl.gov  Thu Apr 18 23:43:55 2002
From: casado2 at llnl.gov (Martin Casado)
Date: Thu, 18 Apr 2002 14:43:55 -0700
Subject: [C++-sig] Boost iterators
In-Reply-To: <038d01c1e71c$781ef5c0$6501a8c0@boostconsulting.com>
References: <1017694764.15479.21.camel@hunsmac.mit.edu> <0204181321280N.12560@avalanche.llnl.gov> <038d01c1e71c$781ef5c0$6501a8c0@boostconsulting.com>
Message-ID: <0204181443550P.12560@avalanche.llnl.gov>

On Thursday 18 April 2002 13:59, you wrote:
> ----- Original Message -----
> From: "Martin Casado" <casado2 at llnl.gov>
>
> > What I was intending to do was expose all types that look like stl
> > containers, as iterators in python.  Or more specifically, any type
> > that defines begin() and end() which return references to  random
>
> accessible
>
> > const iterators.
> >
> > so what I probably really want is..
> >
> >     .def("foo",&FOO:getfoo,
>
> return_value_policy<create_iterator_from<myclass,return_internal_referen
> ce>())
>
> My point was this: All you need to do is expose vector<int> such that it
> acts like an iterator. Then you don't need to say
> "create_iterator_from<...". Just write:
>
>     .add(class_<vector<int> >("int_vector")
>             .def("__iter__", /* whatever */))
>
> in some module. Then you can expose getV as
>
>             .def("v", &Foo::getV,
> return_value_policy<return_internal_reference>())
>
> You can expose as many vector<int>-returning functions as you like this
> way, without writing "create_iterator_from" explicitly each time.

I'm not sure how you would expose vector to act like an iterator since
interators need to know the current position, so when you call next()
the position is incremented, bounds are checked, and the correct
exception is thrown if the bounds are overrun.  It seems to me that you
would have to write a C++ wrapper around vector<int> and any other type you
would want to expose as an iterator to provide this functionality.  Or
add a method, __iter__() which returns a type (like the one I created)
that provides the functionality.

Wouldn't it be simple to have this done within boost so you don't have
to modify the C++ classes?

    ~~Martin




From pearu at cens.ioc.ee  Fri Apr 19 00:44:21 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Fri, 19 Apr 2002 01:44:21 +0300 (EEST)
Subject: [C++-sig] V2: Segmentation fault with gcc-2.95.4 but not with gcc-3.0.4
Message-ID: <Pine.LNX.4.21.0204190118430.3242-100000@cens.ioc.ee>

Hi!

I am getting segmentation faults when trying to import gcc-2.95.4
compiled extension module (the source is included at the end of this
message) while gcc-3.0.4 compiled module works fine. I am using latest BPL
V2 from CVS on Debian Woody, Python 2.2.1c. gdb shows

(gdb) run
Starting program: /usr/bin/python2.2 
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...[New Thread 1024 (LWP 5716)]
(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
Python 2.2.1c1 (#1, Mar 15 2002, 08:13:47) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(no debugging symbols found)...(no debugging symbols found)...
>>> import gs1
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 5716)]
0x400ce64b in PyModule_Type () from /usr/lib/libpython2.2.so.0.0


Compilation flags for gcc:
 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -ftemplate-depth-20
Compiling with gcc, linking with g++.

Any ideas?

Note that I would not mind using gcc-3.x but then for my application I
would need to recompile a bunch of libraries (ginac,cln) that otherwise
come with the distribution and are compiled with gcc-2.95.4. Therefore, I
would first like to try to get BPL V2 working with gcc-2.95.x, if
possible.

Thanks,
	Pearu

//     File gs1.cpp
#include <string>
#define BOOST_PYTHON_DYNAMIC_LIB
#define BOOST_PYTHON_V2
#include <boost/python/module.hpp>

namespace {
  std::string greet() { return "hello, world"; }
  int square(int number) { return number * number; }
}

BOOST_PYTHON_MODULE_INIT(gs1)
{
  using namespace boost::python;

  module m("gs1");
  m
    .def("greet", greet)
    .def("square", square) 
    ;
}






From david.abrahams at rcn.com  Fri Apr 19 03:18:18 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 18 Apr 2002 20:18:18 -0500
Subject: [C++-sig] Boost iterators
References: <0204181735240U.12560@avalanche.llnl.gov>
Message-ID: <043901c1e740$53b8d5b0$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Martin Casado" <casado2 at llnl.gov>
> I'm not sure how you would expose vector to act like an iterator since
> interators need to know the current position, so when you call next()
> the position is incremented, bounds are checked, and the correct
> exception is thrown if the bounds are overrun.

Yeah, good point.

> It seems to me that you
> would have to write a C++ wrapper around vector<int> and any other
type you
> would want to expose as an iterator to provide this functionality.  Or
> add a method, __iter__() which returns a type (like the one I created)
> that provides the functionality.
>
> Wouldn't it be simple to have this done within boost so you don't have
> to modify the C++ classes?

Sure; I'm just disputing the approach.

Rather than adding cruft to each function which returns a vector<int>,
What I think you want is a def_iterator() function on class_<>. Then you
just write:

    .add(class_<std::vector<int> >("int_vector")
            .def_iterator())

or possibly a container_class<...> template derived from class_<...>
which does the def_iterator thing for you. If you write this once, you
should be able to return and accept vector<int> in many functions.

-Dave






From david.abrahams at rcn.com  Fri Apr 19 05:14:06 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 18 Apr 2002 22:14:06 -0500
Subject: [C++-sig] V2: Segmentation fault with gcc-2.95.4 but not with gcc-3.0.4
References: <Pine.LNX.4.21.0204190118430.3242-100000@cens.ioc.ee>
Message-ID: <046b01c1e750$4fd20b50$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Pearu Peterson" <pearu at cens.ioc.ee>


>
> Hi!
>
> I am getting segmentation faults when trying to import gcc-2.95.4
> compiled extension module (the source is included at the end of this
> message) while gcc-3.0.4 compiled module works fine. I am using latest
BPL
> V2 from CVS on Debian Woody, Python 2.2.1c. gdb shows
>
> (gdb) run
> Starting program: /usr/bin/python2.2
> (no debugging symbols found)...(no debugging symbols found)...
> (no debugging symbols found)...[New Thread 1024 (LWP 5716)]
> (no debugging symbols found)...
> (no debugging symbols found)...(no debugging symbols found)...
> Python 2.2.1c1 (#1, Mar 15 2002, 08:13:47)
> [GCC 2.95.4 20011002 (Debian prerelease)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> (no debugging symbols found)...(no debugging symbols found)...
> >>> import gs1
> (no debugging symbols found)...(no debugging symbols found)...
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1024 (LWP 5716)]
> 0x400ce64b in PyModule_Type () from /usr/lib/libpython2.2.so.0.0
>
>
> Compilation flags for gcc:
>  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -ftemplate-depth-20
> Compiling with gcc, linking with g++.
>
> Any ideas?

<snip>

> Note that I would not mind using gcc-3.x but then for my application I
> would need to recompile a bunch of libraries (ginac,cln) that
otherwise
> come with the distribution and are compiled with gcc-2.95.4.
Therefore, I
> would first like to try to get BPL V2 working with gcc-2.95.x, if
> possible.

Considering you're using a non-release version of gcc with a non-release
version of Python, I'd say all bets are off. The official releases of
gcc are here: http://gcc.gnu.org/releases.html.

HTH,
Dave






From Andranik_Araratyan at credence.am  Fri Apr 19 17:16:01 2002
From: Andranik_Araratyan at credence.am (Andranik Araratyan)
Date: Fri, 19 Apr 2002 19:16:01 +0400
Subject: [C++-sig] memory leaks when writing Python extension in MSVC6
Message-ID: <00c701c1e7b5$1e6a3be0$df64a8c0@credence.am>

Hi

I am writing an extension module for Python 2.2.1 with MSVC6.0
, WinNT.  I get memory leaks after only importing that module in 
Python. This doesn't depend on what you're doing inside the module.
I tried to localize the problem to the following

If we take just the following example module 
(the only source file of that module DLL)
===================================

#include "stdafx.h"
#include "Python.h"

static PyObject* ex_foo(PyObject *self, PyObject *args)
{
 printf("Hello, world\n");
 Py_INCREF(Py_None);
 return Py_None;
}

static PyMethodDef example_methods[] =
{
 {"foo", ex_foo, 1, "foo() doc string"},
 {NULL, NULL}
};

extern"C" void initexample(void)
{
  Py_InitModule("example", example_methods);
}
==========================================

and after just calling the Python's "import example" directive (the loading
is successful) and closing it, I got an impressive amount of memory leaks,
which disappear if you just exclude #include "stdafx.h" line from above
text.
Actually, if you even create an empty DLL file from single source file, 
containing just that single line #include "stdafx.h" and nothing more, you 
get the same memory leaks (of course, with the difference that Python 
"import" statement fails in this case).

Is there any way to create an extension module with MFC support not to
produce those memory leaks?







From pearu at cens.ioc.ee  Fri Apr 19 22:16:48 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Fri, 19 Apr 2002 23:16:48 +0300 (EEST)
Subject: [C++-sig] V2: Segmentation fault with gcc-2.95.4 but not with
 gcc-3.0.4
In-Reply-To: <046b01c1e750$4fd20b50$6501a8c0@boostconsulting.com>
Message-ID: <Pine.LNX.4.21.0204192258220.2783-100000@cens.ioc.ee>

Hi,

On Thu, 18 Apr 2002, David Abrahams wrote:

<snip>

> Considering you're using a non-release version of gcc with a non-release
> version of Python, I'd say all bets are off. The official releases of
> gcc are here: http://gcc.gnu.org/releases.html.

Now I have

- gcc version 2.95.3 20010315 (release)
- Python 2.2.1 (#1, Apr 13 2002, 02:15:38) 
  [GCC 2.95.4 20011002 (Debian prerelease)] on linux2

and the following code gives still a segmentation fault when importing gs1

#define BOOST_PYTHON_DYNAMIC_LIB
#define BOOST_PYTHON_V2
#include <boost/python/module.hpp>
BOOST_PYTHON_MODULE_INIT(gs1)
{
  using namespace boost::python;
  module m("gs1");
}

A gdb session is given below. 
Idea-less'ly
	Pearu

> gdb python2.2
GNU gdb 5.1.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-linux"...(no debugging symbols found)...
(gdb) run
Starting program: /usr/bin/python2.2 
(no debugging symbols found)...(no debugging symbols found)...[New Thread
1024 (LWP 22252)]

(no debugging symbols found)...(no debugging symbols found)...
Python 2.2.1 (#1, Apr 13 2002, 02:15:38) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
>>> import gs1
(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 22252)]
0x080f3718 in PyModule_Type ()
(gdb) The program is running.  Exit anyway? (y or n) y






From pearu at cens.ioc.ee  Sat Apr 20 23:16:19 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Sun, 21 Apr 2002 00:16:19 +0300 (EEST)
Subject: Solved: Re: [C++-sig] V2: Segmentation fault with gcc-2.95.4 but
 not with gcc-3.0.4
In-Reply-To: <Pine.LNX.4.21.0204192258220.2783-100000@cens.ioc.ee>
Message-ID: <Pine.LNX.4.21.0204210009280.646-100000@cens.ioc.ee>

Hi again,

I finally got V2 working with gcc-3.0.4. I am not sure what was the exact
reason for the failures but "a major clean up and starting over" was
helpful.

Thanks,
	Pearu







From pearu at cens.ioc.ee  Sun Apr 21 12:40:49 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Sun, 21 Apr 2002 13:40:49 +0300 (EEST)
Subject: [C++-sig] V2: coerce method howto?
Message-ID: <Pine.LNX.4.21.0204211329250.27661-100000@cens.ioc.ee>

Hi,

Consider the following coerce method template

boost::python::tuple ex_coerce(const GiNaC::ex & left,
                               boost::python::ref right) {
  return boost::python::tuple(left,right);
}

but when trying to compile it I get

boost/boost/python/objects.hpp: In member function `void 
   boost::python::tuple::set_item(unsigned int, const T&) [with T = 
   GiNaC::ex]':
boost/boost/python/objects.hpp:74:   instantiated from
`boost::python::tuple::tuple(const First&, const Second&) [with First =
GiNaC::ex, Second = boost::python::ref]'
src/_ginac.cpp:29:   instantiated from here
boost/boost/python/objects.hpp:100: `make_ref' undeclared (first use this 
   function)
boost/boost/python/objects.hpp:100: (Each undeclared identifier is
reported 
   only once for each function it appears in.)
interrupted

I guess that it is an issue of not-implemented-feature but I am not sure.
So, what is the recommended way to implement coerce method within BPL V2?

Pearu





From pearu at cens.ioc.ee  Sun Apr 21 21:43:14 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Sun, 21 Apr 2002 22:43:14 +0300 (EEST)
Subject: [C++-sig] V2: coerce method howto?
In-Reply-To: <Pine.LNX.4.21.0204211329250.27661-100000@cens.ioc.ee>
Message-ID: <Pine.LNX.4.21.0204212229520.3295-100000@cens.ioc.ee>

I have managed to put together a working coerce method (shown at the end
of this message) but then to my surprise I found that it has no effect:

>>> coerce(ex(1),2.3)
(ex(numeric('1')), ex(numeric('2.2999999999999998224')))
>>> ex(1).__add__(ex(2))
ex(numeric('3'))
>>> ex(1)+2.3 
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: bad argument type for built-in operation

Any ideas?

Pearu

PS: I hope that I am not too annoying with my experiments with V2 ;)

---------------
#define EX_TO_PYTHON(e) boost::python::to_python_value<const GiNaC::ex &>()(e)
#define BASIC_FROM_PYTHON(o) boost::python::converter::reference_from_python<const GiNaC::basic &>(o)(o)

  PyObject* ex_coerce(const GiNaC::ex & left,
		      PyObject* right) {
     PyObject* v = PyTuple_New(2);
     PyTuple_SetItem(v,0,EX_TO_PYTHON(left));
     if (PyInt_Check(right))
       PyTuple_SetItem(v,1,EX_TO_PYTHON(*(new
          GiNaC::ex(PyInt_AS_LONG(right)))));
     else if (PyFloat_Check(right))
       PyTuple_SetItem(v,1,EX_TO_PYTHON(*(new 
          GiNaC::ex(PyFloat_AS_DOUBLE(right)))));
     else if (PyObject_IsInstance(right,
(PyObject*)boost::python::objects::class_object<GiNaC::ex>::reference)) {
       Py_INCREF(right);
       PyTuple_SetItem(v,1,right);
     } else if (PyObject_IsInstance(right,
(PyObject*)boost::python::objects::class_object<GiNaC::basic>::reference)) {
       PyTuple_SetItem(v,1,EX_TO_PYTHON(*(new
         GiNaC::ex(BASIC_FROM_PYTHON(right)))));
     } else {
       Py_DECREF(v);
       Py_INCREF(Py_None);
       return Py_None;
     }
     return v;
  }







From david.abrahams at rcn.com  Mon Apr 22 16:35:15 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 22 Apr 2002 09:35:15 -0500
Subject: Solved: Re: [C++-sig] V2: Segmentation fault with gcc-2.95.4 but not with gcc-3.0.4
References: <Pine.LNX.4.21.0204210009280.646-100000@cens.ioc.ee>
Message-ID: <0aef01c1ea0b$3dc7f920$6501a8c0@boostconsulting.com>

I thought your problem was always with 2.95.x, not with 3.0.4, as per
the message title. Am I mistaken?

-Dave

----- Original Message -----
From: "Pearu Peterson" <pearu at cens.ioc.ee>
To: <c++-sig at python.org>
Sent: Saturday, April 20, 2002 4:16 PM
Subject: Solved: Re: [C++-sig] V2: Segmentation fault with gcc-2.95.4
but not with gcc-3.0.4


>
> Hi again,
>
> I finally got V2 working with gcc-3.0.4. I am not sure what was the
exact
> reason for the failures but "a major clean up and starting over" was
> helpful.
>
> Thanks,
> Pearu
>
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig





From pearu at cens.ioc.ee  Mon Apr 22 16:56:47 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 22 Apr 2002 17:56:47 +0300 (EEST)
Subject: Solved: Re: [C++-sig] V2: Segmentation fault with gcc-2.95.4
 but not with gcc-3.0.4
In-Reply-To: <0aef01c1ea0b$3dc7f920$6501a8c0@boostconsulting.com>
Message-ID: <Pine.LNX.4.21.0204221745260.22215-100000@cens.ioc.ee>

On Mon, 22 Apr 2002, David Abrahams wrote:

> I thought your problem was always with 2.95.x, not with 3.0.4, as per
> the message title. Am I mistaken?

The problem started with 2.95.x and while solving it by trying out
different compilers, also 3.0.4 got broken. Now, when both were
broken, they had very similar behaviour, so I concluded that the initial
issue with 2.95.x must have been (but not verified) related to software
(compiler, C++ libraries, boost) installation, and not to boost or
compiler itself.
Currently I am happy with 3.0.4 as I have recompiled other C++ libraries
that I needed with 3.0.4. Later I might try 2.95.x again.

Regards,
	Pearu





From david.abrahams at rcn.com  Mon Apr 22 17:48:33 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 22 Apr 2002 10:48:33 -0500
Subject: [C++-sig] V2: coerce method howto?
References: <Pine.LNX.4.21.0204212229520.3295-100000@cens.ioc.ee>
Message-ID: <0be201c1ea15$54907290$6501a8c0@boostconsulting.com>

Hi Pearu,

----- Original Message -----
From: "Pearu Peterson" <pearu at cens.ioc.ee>


> I have managed to put together a working coerce method (shown at the
end
> of this message) but then to my surprise I found that it has no
effect:
>
> >>> coerce(ex(1),2.3)
> (ex(numeric('1')), ex(numeric('2.2999999999999998224')))
> >>> ex(1).__add__(ex(2))
> ex(numeric('3'))
> >>> ex(1)+2.3
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: bad argument type for built-in operation
>
> Any ideas?

Yes, as a matter of fact:

Python 2.2 (#28, Mar 13 2002, 23:18:18) [MSC 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> coerce
<built-in function coerce>
>>> class ex(object):
...     def __init__(self, v):
...             self.v = v
...     def __coerce__(self, other):
...             return self, ex(other)
...     def __add__(self, rhs):
...             return ex(self.v + rhs.v)
...     def __repr__(self):
...             return 'ex(' + repr(self.v) + ')'
...
>>> ex(3)
ex(3)
>>> coerce(ex(1),2.3)
(ex(1), ex(2.2999999999999998))
>>> ex(1).__add__(ex(2))
ex(3)
>>> ex(1)+2.3
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 9, in __add__
AttributeError: 'float' object has no attribute 'v'

Which is reminiscent of the following:

http://aspn.activestate.com/ASPN/Mail/Message/1168234.

I think a bug report to sourceforge might be appropriate. I've asked
about this on python-dev and post the bug to the SF bug tracker if
nobody tells me I'm crazy.

> Pearu
>
> PS: I hope that I am not too annoying with my experiments with V2 ;)

No, please keep them coming!
BTW I think we want coerce support much more like what is provided by
Boost.Python v1, so you shouldn't have to write those functions
manually.

-Dave





From david.abrahams at rcn.com  Mon Apr 22 20:19:04 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 22 Apr 2002 13:19:04 -0500
Subject: [C++-sig] V2: coerce method howto?
References: <Pine.LNX.4.21.0204212229520.3295-100000@cens.ioc.ee>
Message-ID: <0d5901c1ea2a$30e89740$6501a8c0@boostconsulting.com>

I think you will find your answer here. In some ways I find it to be an
immense relief:

http://aspn.activestate.com/ASPN/Mail/Message/python-dev/1178205


The upshot is that you can ignore coerce and just overload your __add__
and __radd__ method to work with floats.

-Dave

----- Original Message -----
From: "Pearu Peterson" <pearu at cens.ioc.ee>
To: <c++-sig at python.org>
Sent: Sunday, April 21, 2002 2:43 PM
Subject: Re: [C++-sig] V2: coerce method howto?


>
> I have managed to put together a working coerce method (shown at the
end
> of this message) but then to my surprise I found that it has no
effect:
>
> >>> coerce(ex(1),2.3)
> (ex(numeric('1')), ex(numeric('2.2999999999999998224')))
> >>> ex(1).__add__(ex(2))
> ex(numeric('3'))
> >>> ex(1)+2.3
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: bad argument type for built-in operation
>
> Any ideas?
>
> Pearu
>
> PS: I hope that I am not too annoying with my experiments with V2 ;)
>
> ---------------
> #define EX_TO_PYTHON(e) boost::python::to_python_value<const GiNaC::ex
&>()(e)
> #define BASIC_FROM_PYTHON(o)
boost::python::converter::reference_from_python<const GiNaC::basic
&>(o)(o)
>
>   PyObject* ex_coerce(const GiNaC::ex & left,
>       PyObject* right) {
>      PyObject* v = PyTuple_New(2);
>      PyTuple_SetItem(v,0,EX_TO_PYTHON(left));
>      if (PyInt_Check(right))
>        PyTuple_SetItem(v,1,EX_TO_PYTHON(*(new
>           GiNaC::ex(PyInt_AS_LONG(right)))));
>      else if (PyFloat_Check(right))
>        PyTuple_SetItem(v,1,EX_TO_PYTHON(*(new
>           GiNaC::ex(PyFloat_AS_DOUBLE(right)))));
>      else if (PyObject_IsInstance(right,
>
(PyObject*)boost::python::objects::class_object<GiNaC::ex>::reference))
{
>        Py_INCREF(right);
>        PyTuple_SetItem(v,1,right);
>      } else if (PyObject_IsInstance(right,
>
(PyObject*)boost::python::objects::class_object<GiNaC::basic>::reference
)) {
>        PyTuple_SetItem(v,1,EX_TO_PYTHON(*(new
>          GiNaC::ex(BASIC_FROM_PYTHON(right)))));
>      } else {
>        Py_DECREF(v);
>        Py_INCREF(Py_None);
>        return Py_None;
>      }
>      return v;
>   }
>
>
>
>
>
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig






From pearu at cens.ioc.ee  Mon Apr 22 21:57:51 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 22 Apr 2002 22:57:51 +0300 (EEST)
Subject: [C++-sig] V2: to_python/from_python questions
In-Reply-To: <0d5901c1ea2a$30e89740$6501a8c0@boostconsulting.com>
Message-ID: <Pine.LNX.4.21.0204222222460.32358-100000@cens.ioc.ee>

Hi Dave,

On Mon, 22 Apr 2002, David Abrahams wrote:

> I think you will find your answer here. In some ways I find it to be an
> immense relief:

Yes, I can understand it.

> The upshot is that you can ignore coerce and just overload your __add__
> and __radd__ method to work with floats.

Instead of defining a punch of add methods like

const GiNaC::ex ex_add(const GiNaC::ex&,double);
const GiNaC::ex ex_add(const GiNaC::ex&,int);
const GiNaC::ex ex_add(const GiNaC::ex&,const GiNaC::ex&);
const GiNaC::ex ex_add(const GiNaC::ex&,const GiNaC::basic&);
const GiNaC::ex ex_add(const GiNaC::ex&,complex);

I am thinking of having a single one

const GiNaC::ex ex_add(const GiNaC::ex&,PyObject*);

It ignores V2 overloading stuff. Is there any downside of doing this
except having my own bugs?


And I am a bit confused about to_python and from_python that, I think,
understand from V1 perspective. Is there a simple correspondence between
these facilities in V1 and V2?

In V2 I have used, for example

  boost::python::to_python_value<const GiNaC::ex&>()(e)

to construct a PyObject of e. Is this the correct way? 

There is also to_python_indirect and to_python_converter. When one should
use them and how?


Also I have used

  boost::python::converter::reference_from_python<const GiNaC::basic&>(obj)(obj)

to get GiNaC::basic& from PyObject obj. This looks clumsy (using two
times obj). Is there a more appropriate way for getting C++ objects for
Python objects? 

I see that there are also from_python, value_from_python.
How and when they should be used?

It took some time for me to figure out how to use this
reference_from_python and I am still not sure that I am using it
correctly.

Pearu





From burley at tabq.com.au  Tue Apr 23 02:09:50 2002
From: burley at tabq.com.au (Greg Burley)
Date: 23 Apr 2002 10:09:50 +1000
Subject: Solved: Re: [C++-sig] V2: Segmentation fault with gcc-2.95.4 but not with gcc-3.0.4
In-Reply-To: <Pine.LNX.4.21.0204221745260.22215-100000@cens.ioc.ee>
References: <Pine.LNX.4.21.0204221745260.22215-100000@cens.ioc.ee>
Message-ID: <l6n0vvp969.fsf@pc601.tabq.com.au>

Pearu Peterson <pearu at cens.ioc.ee> writes:

> 
> The problem started with 2.95.x and while solving it by trying out
> different compilers, also 3.0.4 got broken. Now, when both were
> broken, they had very similar behaviour, so I concluded that the initial
> issue with 2.95.x must have been (but not verified) related to software
> (compiler, C++ libraries, boost) installation, and not to boost or
> compiler itself.
> Currently I am happy with 3.0.4 as I have recompiled other C++ libraries
> that I needed with 3.0.4. Later I might try 2.95.x again.
> 

allegedly, it is advised to avoid mixing 2.95.x and 3.0.x libraries and
executables, which seems to be what has happened here.  Maybe a rebuild
of each component you are interested in on a strictly 2.95.x installed
machine will yield the results you require.  (Aside: Even the gcc front
end is not compatible and -V is not guaranteed to work. I guess the
major version increment is a hint to potential problems ;-) 

hth
greg





From randre at pppl.gov  Wed Apr 24 18:00:54 2002
From: randre at pppl.gov (Robert Andre)
Date: Wed, 24 Apr 2002 12:00:54 -0400 (EDT)
Subject: [C++-sig] crash with gcc 3.0.4
Message-ID: <200204241600.MAA24442@neptune.pppl.gov>

I had previously posted a message which contained some problems I had
been experiencing with boost/gcc/linux.  The suggestion of using the
latest python 2.2 release fixed the pickle test failures - thanks.  
The other two problems are not boost related but irritating nonetheless:
  1) exceptions sometimes loose their type information so error
     messages are lost (weird).
  2) segmentation fault in ostringstream called from boost when using
     cross module support.

I can't seem to reduce the first to a simple test case but the segmentation
fault wasn't too hard.  It fails on both a linux mandrake kernel 2.2/gcc 3.0.4
and linux redhat 7.1/gcc 3.0.2 (rpm), both dual processor machines.  For 
anybody who is interested in it I posted a small set of files on 
http://w3.pppl.gov/~randre/bomb.tgz  which builds two shared libraries and 
two dynamic libraries.  You have to change a couple of lines in the makefile 
to reflect the location of your includes and library.  One python script runs 
(ok.py) and the other crashes (bomb.py) depending on the order of loading of 
the external modules.

rob




From casado2 at llnl.gov  Thu Apr 25 01:00:36 2002
From: casado2 at llnl.gov (Martin Casado)
Date: Wed, 24 Apr 2002 16:00:36 -0700
Subject: [C++-sig] Boost iterators
In-Reply-To: <043901c1e740$53b8d5b0$6501a8c0@boostconsulting.com>
References: <0204181735240U.12560@avalanche.llnl.gov> <043901c1e740$53b8d5b0$6501a8c0@boostconsulting.com>
Message-ID: <02042416003607.02974@avalanche.llnl.gov>

> Rather than adding cruft to each function which returns a vector<int>,
> What I think you want is a def_iterator() function on class_<>. Then you
> just write:
>
>     .add(class_<std::vector<int> >("int_vector")
>             .def_iterator())

Dave,

  I've had some more time to look into iterator support.  I've written a
  function template which accepts an stl container conforming type and
  returns a PyIterator thingy like so..

  template <typename T>
  PyIter<vector<int> > foo(T& t)
  {
      return PyIter<vector<int> >(t.begin(),t.end());
  }

  I then simply add this to my class with def(..)

    class_<vector<int> >("vector_int")
       .def_init()
       .def("__iter__",static_cast<PyIter<vector<int> > 
(*)(vector<int>&)>(foo)) >
       .def("push_back",&vector<int>::push_back)

  I've hacked class.hpp to add a .def_iterator() which does exactly that
  in the background so now all I have to do is:

  class_<goo>("goo").def_iterator()

  This all seems to work fine however I do have a couple of concerns 

  1. The return value maintins references to the container's iterators.
  Is there a way to keep the container alive as long as the python
  iterator object is alive?  Something like return_internal_reference(),
  but handles values which maintain internal references. 

  2. For each PyIter< > instance used, I have to create a class within
  boost. Such as:

  class_<PyIter<vector<int> > >
  
  Would it be possible to do this on the fly, like during calls
  to .def_iterator()?

  Any ideas would be greatly appreciated.


                            ~~m




From david.abrahams at rcn.com  Thu Apr 25 15:17:57 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 25 Apr 2002 08:17:57 -0500
Subject: [C++-sig] Re: operator[]
References: <3CC74FEF.40D33773@llnl.gov>
Message-ID: <13f701c1ec5b$a03ee4e0$6501a8c0@boostconsulting.com>

__getitem__ can be used directly, but the signature for __setitem__ is:

    __setitem__(self, key, value):

so you need a wrapper function:

    template <class Self, class Key, class Value>
    setitem(Self& self, Key const& key, Value const& value)
    {
        self[key] = value;
    }

    ...


    .def("__setitem__", &setitem<Vector2d,int,double>)

----- Original Message -----
From: "chuzo okuda" <okuda1 at llnl.gov>
To: "David Abrahams" <david.abrahams at rcn.com>
Cc: "Martin Casado" <casado2 at llnl.gov>; "Susan Hazlett"
<shazlett at llnl.gov>; "Kathleen McCandless" <mccandless2 at llnl.gov>
Sent: Wednesday, April 24, 2002 7:38 PM
Subject: operator[]


> Dave,
> Now, I have problem with operator[].
>
> class Vector2d {
> public:
>    Vector2d():x(0.0),y(0.0) {}
>    Vector2d(const double xval, const double yval): x(xval),y(yval) {}
>    ~Vector2d() {}
>    double getX() {return x;}
>    double getY() {return y;}
>    double& operator[](int i) {return i==0 ? x : y;}
>
> protected:
>    double x, y;
> };
>
> int main(int argc, char** argv) {
>    Vector2d v = Vector2d(1.0,2.0);
>    cout << v[0] << "; " << v[1] << endl;
>    v[0] = 5.0; v[1] = 9.0;
>    cout << v[0] << "; " << v[1] << endl;
> }
>
> And operator[] in C++ support both read and write operation.
> It is not clear how to write "__setitem__" and "__getitem__" like:
>
> .def("__setitem__", &Vector2d::operator[])
> .def("__getitem__", &Vector2d::operator[])





From david.abrahams at rcn.com  Thu Apr 25 21:29:11 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Thu, 25 Apr 2002 14:29:11 -0500
Subject: [C++-sig] Boost iterators
References: <0204181735240U.12560@avalanche.llnl.gov> <043901c1e740$53b8d5b0$6501a8c0@boostconsulting.com> <02042416003607.02974@avalanche.llnl.gov>
Message-ID: <154401c1ed1e$cd7197a0$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Martin Casado" <casado2 at llnl.gov>
To: "David Abrahams" <david.abrahams at rcn.com>
Cc: "pysig" <c++-sig at python.org>
Sent: Wednesday, April 24, 2002 6:00 PM
Subject: Re: Re: [C++-sig] Boost iterators


> > Rather than adding cruft to each function which returns a
vector<int>,
> > What I think you want is a def_iterator() function on class_<>. Then
you
> > just write:
> >
> >     .add(class_<std::vector<int> >("int_vector")
> >             .def_iterator())
>
> Dave,
>
>   I've had some more time to look into iterator support.  I've written
a
>   function template which accepts an stl container conforming type and
>   returns a PyIterator thingy like so..
>
>   template <typename T>
>   PyIter<vector<int> > foo(T& t)
>   {
>       return PyIter<vector<int> >(t.begin(),t.end());
>   }
>
>   I then simply add this to my class with def(..)
>
>     class_<vector<int> >("vector_int")
>        .def_init()
>        .def("__iter__",static_cast<PyIter<vector<int> >
> (*)(vector<int>&)>(foo)) >


I don't understand why you need the cast here; it seems as though
&foo<vector<int> > would do just as well.

>        .def("push_back",&vector<int>::push_back)
>
>   I've hacked class.hpp to add a .def_iterator() which does exactly
that
>   in the background so now all I have to do is:
>
>   class_<goo>("goo").def_iterator()

Cool!

>   This all seems to work fine however I do have a couple of concerns
>
>   1. The return value maintins references to the container's
iterators.
>   Is there a way to keep the container alive as long as the python
>   iterator object is alive?  Something like
return_internal_reference(),
>   but handles values which maintain internal references.

How about with_custodian_and_ward<0,1>() should handle it, right? You
want the self argument (argument 1) to stay alive as long as the return
value.

>
>   2. For each PyIter< > instance used, I have to create a class within
>   boost. Such as:
>
>   class_<PyIter<vector<int> > >
>
>   Would it be possible to do this on the fly, like during calls
>   to .def_iterator()?

Well, the Python object for the iterator type could be attached to the
class being defined, instead of the module, if that's what you mean.

    self& def_iterator()
    {
        class_<PyIter<T> > iter_class("iterator");

        // now the iterator class is stored in an attribute of the
container class
        Py_SetAttrString(this->object().get(), "iterator",
iter_class.object().get());

        ...
    }

-Dave






From david.abrahams at rcn.com  Fri Apr 26 16:27:01 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Fri, 26 Apr 2002 09:27:01 -0500
Subject: [C++-sig] crash with gcc 3.0.4
References: <200204241600.MAA24442@neptune.pppl.gov>
Message-ID: <16b101c1ed2e$9e11cdd0$6501a8c0@boostconsulting.com>

----- Original Message -----
From: "Robert Andre" <randre at pppl.gov>

> I had previously posted a message which contained some problems I had
> been experiencing with boost/gcc/linux.  The suggestion of using the
> latest python 2.2 release fixed the pickle test failures - thanks.
> The other two problems are not boost related but irritating
nonetheless:
>   1) exceptions sometimes loose their type information so error
>      messages are lost (weird).

It's a long-standing issue with Boost.Python that there is no
generalized mechanism for C++ -> Python exception translation. The only
way to be sure that /some/ information will be preserved is to derive
C++ exceptions from std::exception, and to make sure the what() string
gives you some useful information. I plan to address this problem for
Boost.Python v2 in Q3 of this year.

Shot in the dark: if you are having trouble with exceptions thrown
across shared library boundaries, it might help if the shared libs were
explicitly linked to one another.

>   2) segmentation fault in ostringstream called from boost when using
>      cross module support.
>
> I can't seem to reduce the first to a simple test case but the
segmentation
> fault wasn't too hard.  It fails on both a linux mandrake kernel
2.2/gcc 3.0.4
> and linux redhat 7.1/gcc 3.0.2 (rpm), both dual processor machines.
For
> anybody who is interested in it I posted a small set of files on
> http://w3.pppl.gov/~randre/bomb.tgz  which builds two shared libraries
and
> two dynamic libraries.

?? What's the difference between a shared and a dynamic library ??

> You have to change a couple of lines in the makefile
> to reflect the location of your includes and library.  One python
script runs
> (ok.py) and the other crashes (bomb.py) depending on the order of
loading of
> the external modules.

The Boost.Python v1 cross-module support is somewhat ad-hoc, and
development is proceeding full-speed on Boost.Python v2. Rather than
trying to address this kind of problem in the v1 sources, I plan to
release v2 as a replacement for v1.

-Dave





From randre at pppl.gov  Fri Apr 26 19:14:14 2002
From: randre at pppl.gov (Robert Andre)
Date: Fri, 26 Apr 2002 13:14:14 -0400 (EDT)
Subject: [C++-sig] crash with gcc 3.0.4
References: <20020426160017.30172.74277.Mailman@mail.python.org>
Message-ID: <200204261714.NAA24452@neptune.pppl.gov>

>>   1) exceptions sometimes loose their type information so error
>>      messages are lost (weird).
>
>It's a long-standing issue with Boost.Python that there is no
>generalized mechanism for C++ -> Python exception translation. The only
>way to be sure that /some/ information will be preserved is to derive
>C++ exceptions from std::exception, and to make sure the what() string
>gives you some useful information. I plan to address this problem for
>Boost.Python v2 in Q3 of this year.

The weird part is that I do derive from std::exception but the information
that it is derived from std::exception is somehow lost while unwrapping 
the call stack.  This only happens with cross modules and only for some
of the exceptions.

>Shot in the dark: if you are having trouble with exceptions thrown
>across shared library boundaries, it might help if the shared libs were
>explicitly linked to one another.

That's an idea though slightly contrary to the purpose of cross modules.

>?? What's the difference between a shared and a dynamic library ??

on linux (or elf systems) none as far as I know, on mac osx the shared
libraries are different then the dynamically loadable kind which are
called bundles -- not sure about other systems.

>The Boost.Python v1 cross-module support is somewhat ad-hoc, and
>development is proceeding full-speed on Boost.Python v2. Rather than
>trying to address this kind of problem in the v1 sources, I plan to
>release v2 as a replacement for v1.

ok, my guess is that the segfault problem I am having has to do with
either how I am building the libraries or more likely a bug in gcc
stringstream or the fact that I am compiling with gcc3 on systems
setup for gcc2.  I've seen it crash in instringstream also so it's
not a boost thing.  I'm just surprised nobody else has encountered it.

We haven't really decided whether to go the boost.python, jython, swig or
some other route yet but in case we do use boost it would be helpful
if you could keep the strstream option available in v2,v3... so that
we can support gcc 3.0 users.

thanks dave,

rob





From casado2 at llnl.gov  Fri Apr 26 21:42:01 2002
From: casado2 at llnl.gov (Martin Casado)
Date: Fri, 26 Apr 2002 12:42:01 -0700
Subject: [C++-sig] Boost iterators
In-Reply-To: <154401c1ed1e$cd7197a0$6501a8c0@boostconsulting.com>
References: <0204181735240U.12560@avalanche.llnl.gov> <02042416003607.02974@avalanche.llnl.gov> <154401c1ed1e$cd7197a0$6501a8c0@boostconsulting.com>
Message-ID: <0204261242010L.02974@avalanche.llnl.gov>

> >
> >   I then simply add this to my class with def(..)
> >
> >     class_<vector<int> >("vector_int")
> >        .def_init()
> >        .def("__iter__",static_cast<PyIter<vector<int> >
> > (*)(vector<int>&)>(foo)) >
>
> I don't understand why you need the cast here; it seems as though
> &foo<vector<int> > would do just as well.
>


You don't need the cast for nontemplate methods, however without
the cast on a templated method I get the following error with KCC

 line 72: error: no instance of overloaded function
          "boost::python::class_<T, X1, X2, X3>::def [with T=std::vector<int,
          std::allocator<int>>, X1=boost::python::detail::not_specified,
          X2=boost::python::detail::not_specified,
          X3=boost::python::detail::not_specified]" matches the argument list
            argument types are: (char [9], <unknown-type>)
                  .def("__iter__",&foo<vector<int> >)

It works fine with the cast however.

> >   1. The return value maintins references to the container's
>
> iterators.
>
> >   Is there a way to keep the container alive as long as the python
> >   iterator object is alive?  Something like
>
> return_internal_reference(),
>
> >   but handles values which maintain internal references.
>
> How about with_custodian_and_ward<0,1>() should handle it, right? You
> want the self argument (argument 1) to stay alive as long as the return
> value.



Thats what I figured but I haven't been able to get
with_costudian_and_ward<0,1>() to work in this case.  Given the
following simple setup..

class A{ };
class B { };
 
A getA(const B& b)
{ return A(); }


 This works fine: 
   class_<B>("B").def("getA",getA) ;

 However, this doesn't

  .def("getA",getA,with_custodian_and_ward<0,1>())  


Specifically I get the following error..

"/usr/dnta/kull/developers/thirdPartySoftware/boost-chuzo/boost/boost/python/with_custodian_and_ward.hpp", 
line 33: error:
          incomplete type is not allowed
      BOOST_STATIC_ASSERT(custodian > 0);

and the following warning:

"/usr/dnta/kull/developers/thirdPartySoftware/boost-chuzo/boost/boost/python/with_custodian_and_ward.hpp", 
line 38: warning:
          integer conversion resulted in truncation
      PyObject* nurse = PyTuple_GetItem(args_, custodian - 1);


                        ~~m




From pearu at cens.ioc.ee  Sat Apr 27 19:48:20 2002
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Sat, 27 Apr 2002 20:48:20 +0300 (EEST)
Subject: [C++-sig] V2: wrapping int/double bug(?)
Message-ID: <Pine.LNX.4.21.0204272023330.23424-100000@cens.ioc.ee>

Hi,

It seems that V2 does not distinguish between python int and
float types.

For example, if one defines (note the ordering of int and double methods)

  m.add(
    	 boost::python::class_<GiNaC::ex>("ex")

    	 .def_init(boost::python::args<int>())
    	 .def_init(boost::python::args<double const>())

	 .def("__add__",ex_add_double)
	 .def("__add__",ex_add_int)
  );

where

  const GiNaC::ex ex_add_int(const GiNaC::ex& lh,int const rh);
  const GiNaC::ex ex_add_double(const GiNaC::ex& lh,double const rh);

then in python:

>>> ex(2)
ex(numeric('2'))
>>> ex(2.3)
ex(numeric('2'))   <--- bug: float was converted to int
>>> ex(0)+2  
ex(numeric('2.0')) <--- bug: int was converted to float
>>> ex(0)+2.3
ex(numeric('2.2999999999999998224'))

That is, definitions
     .def_init(boost::python::args<double const>())
and
     .def("__add__",ex_add_int)
are ignored.

Any ideas how to fix this?

Regards,
	Pearu





From david.abrahams at rcn.com  Tue Apr 30 05:48:11 2002
From: david.abrahams at rcn.com (David Abrahams)
Date: Mon, 29 Apr 2002 22:48:11 -0500
Subject: [C++-sig] crash with gcc 3.0.4
References: <20020426160017.30172.74277.Mailman@mail.python.org> <200204261714.NAA24452@neptune.pppl.gov>
Message-ID: <00e401c1effa$3c855cc0$6401a8c0@boostconsulting.com>

----- Original Message -----
From: "Robert Andre" <randre at pppl.gov>

> >The Boost.Python v1 cross-module support is somewhat ad-hoc, and
> >development is proceeding full-speed on Boost.Python v2. Rather than
> >trying to address this kind of problem in the v1 sources, I plan to
> >release v2 as a replacement for v1.
>
> ok, my guess is that the segfault problem I am having has to do with
> either how I am building the libraries or more likely a bug in gcc
> stringstream or the fact that I am compiling with gcc3 on systems
> setup for gcc2.  I've seen it crash in instringstream also so it's
> not a boost thing.  I'm just surprised nobody else has encountered it.
>
> We haven't really decided whether to go the boost.python, jython, swig
or
> some other route yet but in case we do use boost it would be helpful
> if you could keep the strstream option available in v2,v3... so that
> we can support gcc 3.0 users.

[aside: I don't see how jython can help you with a C++ binding... is
there interesting jython technology for that purpose?]

Boost.Python doesn't do anything to rule in or rule out the use of
strstream with any version of gcc. There's nothing special about
Boost.Python extension modules that makes them different from other
shared libraries w.r.t. strstream.


HTH,
Dave